Протокол udp

Какие порты обычно открыты по умолчанию?

Есть много портов. Номер порта может быть любым от 0 до 65535! Это не означает, что любое приложение может просто выбрать любой порт. Существуют установленные стандарты и диапазоны, которые помогают нам разобраться с шумом.

Порты 0-1023 связаны с некоторыми из наиболее важных и основных сетевых служб. Это имеет смысл, поскольку порты с меньшими номерами были назначены первыми. Например, протокол SMTP для электронной почты используется исключительно портом 25.

Порты 1024-49151 известны как «зарегистрированные порты» и назначаются важным общим службам, таким как OpenVPN на порт 1194 или Microsoft SQL на портах 1433 и 1434.

Остальные номера портов известны как «динамические» или «частные» порты. Эти порты не зарезервированы, и любой может использовать их в сети для поддержки определенного сервиса. Единственная проблема возникает, когда две или более службы в одной сети используют один и тот же порт.

Хотя невозможно перечислить все важные порты, эти общие порты полезно знать наизусть:

Поскольку существует много тысяч общих номеров портов, самый простой подход – запомнить диапазоны. Который скажет вам, если данный порт зарезервирован или нет. Благодаря Google вы также можете быстро узнать, какие службы используют определенный порт.

Различные приложения TCP и UDP

Просмотр веб-страниц, электронная почта и передача файлов — это обычные приложения, использующие TCP. TCP используется для управления размером сегмента, скоростью обмена данными, управлением потоком и перегрузкой сети. TCP предпочтительнее там, где требуются средства исправления ошибок на уровне сетевого интерфейса. UDP в основном используется приложениями, чувствительными ко времени, а также серверами, которые отвечают на небольшие запросы от огромного количества клиентов. UDP совместим с широковещательной рассылкой пакетов — отправкой всем в сети и многоадресной рассылкой — отправкой всем подписчикам. UDP обычно используется в системе доменных имен, передаче голоса по IP, протоколе простой передачи файлов и онлайн-играх.

TCP против UDP для игровых серверов

Для массовых многопользовательских сетевых (MMO) игр разработчикам часто приходится делать архитектурный выбор между использованием постоянных соединений UDP или TCP. Преимущества TCP — постоянные соединения, надежность и возможность использовать пакеты произвольного размера. Самая большая проблема с TCP в этом сценарии — его алгоритм управления перегрузкой, который рассматривает потерю пакетов как признак ограничения полосы пропускания и автоматически регулирует отправку пакетов. В сетях 3G или Wi-Fi это может вызвать значительную задержку.

Опытный разработчик Кристоффер Лернё взвесил все за и против и рекомендует следующие критерии, чтобы выбрать, использовать ли в вашей игре TCP или UDP:

• Используйте HTTP через TCP для выполнения случайных инициируемых клиентом запросов без сохранения состояния, когда допустима случайная задержка.
• Используйте постоянные простые TCP-сокеты, если и клиент, и сервер независимо отправляют пакеты, но случайная задержка допустима (например, онлайн-покер, многие MMO).
• Используйте UDP, если и клиент, и сервер могут независимо отправлять пакеты и периодические задержки не подходят (например, большинство многопользовательских экшн-игр, некоторые MMO).

Что такое порты TCP и UDP?

Два современных типа портов в современных сетях известны как порты TCP и UDP. Это протокол управления передачей и протокол дейтаграмм пользователя соответственно. Таким образом, эти два типа портов используют разные сетевые протоколы.

Которые вы можете считать отличительными наборами правил для того, как биты информации должны быть отправлены и получены. Оба типа портов построены на фундаментальном протокол Интернета (IP), который делает интернет и домашние сети, ну, Работа, Тем не менее, они подходят для различных применений.

Большая разница в том, что когда вы отправляете информацию по UDP, отправителю не нужно сначала устанавливать соединение с получателем перед началом разговора. Это похоже на отправку письма. Вы не знаете, получил ли ваше сообщение другое лицо, и у вас нет гарантии, что вы получите какой-либо отзыв.

TCP, с другой стороны, больше похож на телефонный звонок. Приемник должен «установить» соединение, и существует поток информации, пока кто-то намеренно не положит трубку.

Сообщения UDP обычно передаются по сети любому, кто прослушивает указанный порт UDP. Это делает его идеальным для сообщений служебного типа, которые касаются работы самой сети. Он также идеально подходит для потоковой передачи голоса по IP, онлайн-видеоигр и потокового вещания.

Почему? Эти приложения извлекают выгоду из низкой задержки UDP и постоянного потока информации, который не обязательно должен быть идеальным, чтобы быть полезным

В конце концов, небольшое искажение в вашем чате Skype гораздо менее важно, чем небольшое отставание

TCP гораздо более распространен, чем UDP, и он гарантирует, что все данные будут получены без ошибок. Почти все, что не нуждается в особых преимуществах UDP, использует вместо этого TCP.

Различия в функциях передачи данных

TCP обеспечивает надежную и упорядоченную доставку потока байтов от пользователя к серверу или наоборот. UDP не предназначен для сквозных соединений, и связь не проверяет готовность получателя.

Надежность

TCP является более надежным, поскольку управляет подтверждением сообщений и повторной передачей в случае потери частей. Таким образом, нет абсолютно никаких недостающих данных. UDP не гарантирует, что связь достигнута получателем, поскольку отсутствуют концепции подтверждения, тайм-аута и повторной передачи.

Заказ

TCP передачи отправляются в последовательности, и они принимаются в той же последовательности. В случае поступления сегментов данных в неправильном порядке TCP меняет порядок и доставляет приложение. В случае UDP, последовательность отправленных сообщений может не поддерживаться, когда они попадут в принимающее приложение. Абсолютно невозможно предсказать порядок, в котором будет получено сообщение.

Подключение

TCP представляет собой тяжелое соединение, требующее трех пакетов для сокетного соединения и обеспечивающее контроль перегрузки и надежность. UDP это легкий транспортный уровень, разработанный поверх IP. Нет отслеживания подключений или упорядочивания сообщений.

Способ перевода

TCP считывает данные как поток байтов, и сообщение передается на границы сегмента. UDP сообщения — это пакеты, которые отправляются индивидуально и по прибытии проверяются на их целостность. Пакеты имеют определенные границы, а поток данных — нет.

Обнаружение ошибок

UDP работает по принципу «максимальных усилий». Протокол поддерживает обнаружение ошибок с помощью контрольной суммы, но при обнаружении ошибки пакет отбрасывается. Повторная передача пакета для восстановления после этой ошибки не выполняется. Это связано с тем, что UDP обычно используется для чувствительных ко времени приложений, таких как игры или передача голоса. Восстановление после ошибки было бы бессмысленным, потому что к тому времени, когда повторно переданный пакет будет получен, он уже не будет использоваться.

TCP использует как обнаружение ошибок, так и исправление ошибок. Ошибки обнаруживаются с помощью контрольной суммы, и если пакет ошибочный, он не подтверждается получателем, что вызывает повторную передачу отправителем. Этот рабочий механизм называется положительным подтверждением с повторной передачей (PAR).

Недостатки UDP

По сравнению с TCP UDP имеет следующие недостатки:

• Отсутствие сигналов квитирования. Перед отправкой пакета UDP, отправляющая сторона не обменивается с получающей стороной квитирующими сигналами. Следовательно, у отправителя нет способа узнать, достигла ли дейтаграмма конечной системы. В результате UDP не может гарантировать, что данные будут действительно доставлены адресату (например, если не работает конечная система или сеть).

  Напротив, протокол TCP ориентирован на установление соединений и обеспечивает взаимодействие между подключенными к сети хостами, используя пакеты. В TCP применяются сигналы квитирования, позволяющие проверить успешность транспортировки данных.

• Использование сессий. Ориентированность TCP на соединения поддерживается сеансами между хостами. TCP использует идентификатор сеанса, позволяющий отслеживать соединения между двумя хостами. UDP не имеет поддержки сеансов из-за своей природы, не ориентированной на соединения.

• Надежность. UDP не гарантирует, что адресату будет доставлена только одна копия данных. Чтобы отправить конечной системе большой объем данных, UDP разбивает его на небольшие части. UDP не гарантирует, что эти части будут доставлены по назначению в том же порядке, в каком они создавались в источнике. Напротив, TCP вместе с номерами портов использует порядковые номера и регулярно отправляемые подтверждения, гарантирующие упорядоченную доставку данных.

• Безопасность. TCP более защищен, чем UDP. Во многих организациях брандмауэры и маршрутизаторы не пропускают пакеты UDP. Это связано с тем, что хакеры могут воспользоваться портами UDP, не устанавливая явных соединений.

• Управление потоком. В UDP управление потоком отсутствует, в результате плохо спроектированное UDP-приложение может захватить значительную часть пропускной способности сети.

Как работают TCP и UDP

TCP-соединение устанавливается посредством трехстороннего рукопожатия, которое представляет собой процесс инициации и подтверждения соединения. Как только соединение установлено, передача данных может начаться. После передачи соединение прерывается закрытием всех установленных виртуальных каналов.

UDP использует простую модель передачи без неявных диалогов рукопожатия для обеспечения надежности, упорядочения или целостности данных. Таким образом, UDP предоставляет ненадежный сервис, и дейтаграммы могут приходить из строя, дублироваться или пропадать без уведомления. UDP предполагает, что проверка и исправление ошибок либо не нужны, либо выполняются в приложении, что позволяет избежать накладных расходов на такую ​​обработку на уровне сетевого интерфейса. В отличие от TCP, UDP совместим с пакетной рассылкой (отправка всем по локальной сети) и многоадресной рассылкой (отправка всем подписчикам).

TCP vs self-made UDP. Final fighting

• Send/recv buffer: для своего протокола можно делать mutable buffer, с TCP будут проблемы с buffer bloat.
• Congestion control вы можете использовать существующие. У UDP они любые. 
• Новый Congestion control трудно добавить в TCP, потому что нужно модифицировать acknowledgement, вы не можете это сделать на клиенте.
• Мультиплексирование — критичная проблема. Случается head-of-line blocking, при потере пакета вы не можете мультиплексировать в TCP. Поэтому HTTP2.0 по TCP не должен давать серьезного прироста.
• Случаи, когда вы можете получить установку соединения за 0-RTT в TCP крайне редки, порядка 5 %, и порядка 97 % для self-made UDP.

• IP Migration — не такая важная фича, но в случае сложных подписок и хранения состояния на сервере она однозначно нужна, но в TCP никак не реализована.
• Nat unbinding не в пользу UDP. В этом случае в UDP надо часто делать ping-pong пакеты.
• Packet pacing в UDP простой, пока нет оптимизации, в TCP эта опция не работает.
•  MTU и исправление ошибок и там, и там примерно сравнимы.
• По скорости TCP, конечно, быстрее, чем UDP сейчас, если вы раздаете тонну трафика. Но зато какие-то оптимизации очень долго доставляются.

Выбираем UDP!

Приложения

Многие ключевые интернет-приложения используют UDP, в том числе: систему доменных имен (DNS), где запросы должны быть быстрыми и состоять только из одного запроса, за которым следует один пакет ответа, простой протокол управления сетью (SNMP), протокол информации о маршрутизации ( RIP) и протокол динамической конфигурации хоста (DHCP).

Голосовой и видеотрафик обычно передается по протоколу UDP. Протоколы потоковой передачи видео и аудио в реальном времени предназначены для обработки случайных потерянных пакетов, поэтому при повторной передаче потерянных пакетов происходит только небольшое ухудшение качества, а не большие задержки. Поскольку и TCP, и UDP работают в одной и той же сети, многие компании обнаруживают, что недавнее увеличение трафика UDP из этих приложений реального времени снижает производительность приложений, использующих TCP, таких как точки продаж , системы бухгалтерского учета и базы данных. Когда TCP обнаруживает потерю пакета, он ограничивает использование скорости передачи данных. Поскольку для бизнеса важны как приложения реального времени, так и бизнес-приложения, некоторые считают высокое качество обслуживания критически важным.

Некоторые системы VPN , такие как OpenVPN, могут использовать UDP и выполнять проверку ошибок на уровне приложений при реализации надежных соединений.

QUIC — это транспортный протокол, построенный на основе UDP. QUIC обеспечивает надежное и безопасное соединение. HTTP / 3 использует QUIC в отличие от более ранних версий HTTPS, которые используют комбинацию TCP и TLS для обеспечения надежности и безопасности соответственно. Это означает, что HTTP / 3 использует одно рукопожатие для установки соединения, а не два отдельных рукопожатия для TCP и TLS, а это означает, что общее время установления соединения сокращается.

TCP vs self-made UDP. Final fighting

• Send/recv buffer: для своего протокола можно делать mutable buffer, с TCP будут проблемы с buffer bloat.
• Congestion control вы можете использовать существующие. У UDP они любые. 
• Новый Congestion control трудно добавить в TCP, потому что нужно модифицировать acknowledgement, вы не можете это сделать на клиенте.
• Мультиплексирование — критичная проблема. Случается head-of-line blocking, при потере пакета вы не можете мультиплексировать в TCP. Поэтому HTTP2.0 по TCP не должен давать серьезного прироста.
• Случаи, когда вы можете получить установку соединения за 0-RTT в TCP крайне редки, порядка 5 %, и порядка 97 % для self-made UDP.

• IP Migration — не такая важная фича, но в случае сложных подписок и хранения состояния на сервере она однозначно нужна, но в TCP никак не реализована.
• Nat unbinding не в пользу UDP. В этом случае в UDP надо часто делать ping-pong пакеты.
• Packet pacing в UDP простой, пока нет оптимизации, в TCP эта опция не работает.
•  MTU и исправление ошибок и там, и там примерно сравнимы.
• По скорости TCP, конечно, быстрее, чем UDP сейчас, если вы раздаете тонну трафика. Но зато какие-то оптимизации очень долго доставляются.

Выбираем UDP!

SOCK_STREAM vs SOCK_DGRAM¶

См.также

• UDP
• TCP

Потоковый (SOCK_STREAM)	Дейтаграммный (SOCK_DGRAM)
Устанавливает соединение	Нет
Гарантирует доставку данных	Нет в случае UDP
Гарантирует порядок доставки пакетов	Нет в случае UDP
Гарантирует целостность пакетов	Тоже
Разбивает сообщение на пакеты	Нет
Контролирует поток данных	Нет

TCP гарантирует доставку пакетов, их очередность, автоматически разбивает
данные на пакеты и контролирует их передачу, в отличии от UDP.
Но при этом TCP работает медленнее за счет повторной передачи потерянных
пакетов и большему количеству выполняемых операций над пакетами. Поэтому
там где требуется гарантированная доставка (Веб-браузер, telnet, почтовый клиент) используется TCP, если же требуется передавать данные в реальном
времени (многопользовательские игры, видео, звук) используют UDP.

Сетевые протоколы UDP, TCP, ICMP

В рамках протокола TCP/IP для передачи данных используются протоколы — TCP и UDP. Многие наверняка слышали, что есть порты как TCP, так и UDP, но не все знают в чем разница и что это вообще. И так..

Передача данных по протоколу TCP (Transmission Control Protocol — Протокол Управления Передачей) предусматривает наличие подтверждений получения информации. «-Ну, мол, — получил? -Получил!» Если же передающая сторона не получит в установленные сроки необходимого подтверждения, то данные будут переданы повторно. Поэтому протокол TCP относят к протоколам, предусматривающим соединение, а UDP (User Datagram Protocol — Протокол Пользовательских Датаграмм) — нет. UDP применяется в тех случаях, когда не требуется подтверждения приема (например, DNS-запросы или IP-телефония (яркий представитель которой, — Skype) ). То есть разница заключается в наличии подтверждения приема. Казалось бы «Всего то!», но на практике это играет важную роль.

Есть еще так же протокол ICMP (Internet Control Message Protocol — межсетевой протокол управляющих сообщений), который используется для передачи данных о параметрах сети. Он включает в себя служебные типы пакетов, таки как ping, distination unreachable, TTL и пр.

Заголовок TCP

• Порядковый номер выполняет две задачи:
• • Если установлен флаг SYN, то это начальное значение номера последовательности — ISN (Initial Sequence Number), и первый байт данных, которые будут переданы в следующем пакете, будет иметь номер последовательности, равный ISN + 1.
  • В противном случае, если SYN не установлен, первый байт данных, передаваемый в данном пакете, имеет этот номер последовательности.
• Номер подтверждения — если установлен флаг ACK, то это поле содержит номер последовательности, ожидаемый получателем в следующий раз. Помечает этот сегмент как подтверждение получения.
• Длина заголовка — задается словами по 32бита.
• Размер окна — количество байт, которые готов принять получатель без подтверждения.
• Контрольная сумма — включает псевдо заголовок, заголовок и данные.
• Указатель срочности — указывает последний байт срочных данных, на которые надо немедленно реагировать.
• URG — флаг срочности, включает поле «Указатель срочности», если =0 то поле игнорируется.
• ACK — флаг подтверждение, включает поле «Номер подтверждения, если =0 то поле игнорируется.
• PSH — флаг требует выполнения операции push, модуль TCP должен срочно передать пакет программе.
• RST — флаг прерывания соединения, используется для отказа в соединении
• SYN — флаг синхронизация порядковых номеров, используется при установлении соединения.
• FIN — флаг окончание передачи со стороны отправителя

Рассмотрим структуру  заголовка TCP с помощью сетевого анализатора Wireshark:

TCP порты

Так как на одном и том же компьютере могут быть запущены несколько программ, то для доставки TCP-пакета конкретной программе, используется уникальный идентификатор каждой программы или номер порта.

Номер порта — это условное 16-битное число от 1 до 65535, указывающее, какой программе предназначается пакет.

TCP порты используют определенный порт программы для доставки данных, передаваемых с помощью протокола управления передачей (TCP). TCP порты являются более сложными и работают иначе, чем порты UDP. В то время как порт UDP работает как одиночная очередь сообщений и как точка входа для UDP-соединения, окончательной точкой входа для всех соединений TCP является уникальное соединение. Каждое соединение TCP однозначно идентифицируется двумя точками входа.

Каждый отдельный порт сервера TCP может предложить общий доступ к нескольким соединениям, потому что все TCP соединения идентифицируются двумя значениями: IP-адресом и TCP портом (сокет).

Все номера портов TCP, которые меньше чем 1024 — зарезервированы и зарегистрированы в Internet Assigned Numbers Authority (IANA).

Номера портов UDP и TCP не пересекаются.

TCP программы используют зарезервированные или хорошо известные номера портов, как показано на следующем рисунке.

Некоторые порты могут использоваться для чего угодно, в то время как другие имеют давно установленные цели

Протокол управления передачей (TCP) использует набор каналов связи, называемых портами, для управления системным обменом сообщениями между несколькими различными приложениями, работающими на одном физическом устройстве. В отличие от физических портов на компьютерах, таких как USB-порты или Ethernet-порты, TCP-порты являются виртуально программируемыми записями, пронумерованными от 0 до 65535.

Большинство портов TCP являются каналами общего назначения, которые могут вызываться при необходимости, но в остальном бездействуют. Однако некоторые порты с меньшими номерами предназначены для определенных приложений. Хотя многие TCP-порты принадлежат приложениям, которые больше не существуют, некоторые из них очень популярны.

TCP порт 0

TCP фактически не использует порт 0 для сетевого взаимодействия, но этот порт хорошо известен сетевым программистам. Программы сокетов TCP используют порт 0 по соглашению, чтобы запросить доступный порт, который будет выбран и выделен операционной системой. Это избавляет программиста от необходимости выбирать («жесткий код») номер порта, который может не сработать в данной ситуации.

TCP-порты 20 и 21

FTP-серверы используют TCP-порт 21 для управления своей стороной сеансов FTP. Сервер прослушивает команды FTP, поступающие на этот порт, и отвечает соответствующим образом. В активном режиме FTP сервер дополнительно использует порт 20 для инициирования передачи данных обратно клиенту FTP.

TCP-порт 22

Secure Shell использует порт 22. Серверы SSH прослушивают на этом порту входящие запросы на вход от удаленных клиентов. Из-за характера такого использования порт 22 любого общедоступного сервера часто проверяется сетевыми хакерами и является предметом тщательного изучения в сообществе по сетевой безопасности. Некоторые защитники рекомендуют администраторам перенести установку SSH на другой порт, чтобы избежать этих атак, в то время как другие утверждают, что это лишь незначительный обходной путь.

TCP-порт 23

Порт 23 управляет telnet , текстовой системой для входа в удаленные системы. Хотя современные подходы к удаленному доступу основаны на Secure Shell на порте 22, порт 23 остается зарезервированным для более старого и менее безопасного приложения telnet.

TCP-порты 25, 110 и 143

На принимающей стороне порт 110 управляет протоколом почтовой связи версии 3, а порт 143 выделен для протокола доступа к почте через Интернет. POP3 и IMAP контролируют поток электронной почты с сервера вашего провайдера на ваш почтовый ящик.

Безопасные версии SMTP и IMAP различаются в зависимости от конфигурации, но порты 465 и 587 являются общими.

UDP порты 67 и 68

Серверы протокола динамической конфигурации хоста используют UDP-порт 67 для прослушивания запросов, в то время как клиенты DHCP обмениваются данными через UDP-порт 68.

TCP-порты 80 и 443

Возможно, самый известный порт в Интернете – TCP-порт 80 – это значение по умолчанию, которое веб-серверы HyperText Transfer Protocol прослушивают для запросов веб-браузера.

Порт 443 по умолчанию для безопасного HTTP.

UDP-порты 161 и 162

По умолчанию простой протокол управления сетью использует UDP-порт 161 для отправки и получения запросов в управляемой сети. Он использует UDP-порт 162 по умолчанию для получения прерываний SNMP от управляемых устройств.

TCP-порт 194

Несмотря на то, что такие инструменты, как приложения для обмена сообщениями на смартфонах, такие как Slack и Microsoft Teams, стали использовать Internet Relay Chat, IRC по-прежнему пользуется популярностью среди людей по всему миру. По умолчанию IRC использует порт 194.

Порты выше 1023

Номера портов TCP и UDP между 1024 и 49151 называются зарегистрированными портами . Управление по присвоению номеров в Интернете ведет список услуг, использующих эти порты, чтобы минимизировать конфликты при использовании.

В отличие от портов с меньшими номерами, разработчики новых служб TCP/UDP могут выбирать определенный номер для регистрации в IANA, а не назначать им номер. Использование зарегистрированных портов также позволяет избежать дополнительных ограничений безопасности, которые операционные системы накладывают на порты с меньшими номерами.

Обзор OSI и TCP / IP

Сетевая архитектура OSI и TCP / IP — две известные эталонные модели сети. Модель OSI была разработана Международной организацией по стандартизации (ISO). В 1984 году она была принята в качестве эталонной модели. Модель OSI в основном определяет семиуровневый канал связи между системой. Эти уровни функционируют таким образом, чтобы предоставлять услуги более высокому уровню. Функции этих уровней кратко описаны ниже:

Физический уровень — его основная функция заключается в передаче битов данных на физическом носителе, таком как кабели, сетевые карты, концентраторы и т.д.

Уровень канала передачи данных DLL кодирует биты данных в пакеты перед их передачей. Данные декодируются обратно в биты на приемнике. Другие функции включают управление логическим соединением, обнаружение ошибок, надежную передачу данных и т.д.

Сетевой уровень — отвечает за маршрутизацию пакетов данных в двух разных сетях с использованием IP (Интернет-протокола). Уровень канала данных направляет данные только в локальную сеть.

Транспортный уровень — транспортный уровень обеспечивает надежную и прозрачную передачу данных между сквозными устройствами. Помимо сегментации данных, транспортный уровень определяет тип услуги, которая должна быть предоставлена ​​вышележащим и нижним уровням.

Сеансовый уровень — он связан с такими аспектами управления соединением, как установление и завершение соединения, продолжительность сеанса, синхронизация данных между конечными устройствами с использованием контрольных точек.

Уровень представления — он форматирует данные таким образом, чтобы их могла использовать принимающая сторона. Другие функции, которые здесь работают, — это сжатие и шифрование данных и т.д.

Уровень приложения — он содержит различные службы связи, такие как передача файлов, SMTP, SSH, FTP и электронная почта. Он действует как интерфейс между пользовательскими приложениями, такими как браузеры, удаленный вход и т.д.

TCP / IP — это комбинация двух протоколов: протокола управления передачей и Интернет-протокола. Это основа современного Интернета. Целью TCP является обеспечение надежной передачи пакетов данных путем предоставления механизма контроля ошибок и проверки доставки пакетов данных в последовательности. TCP использует IP для разделения больших потоков данных на более мелкие пакеты и маршрутизации этих пакетов. Есть небольшие различия между уровнями модели OSI и модели TCP / IP. Например, уровни представления и сеанса объединены в его прикладной уровень в TCP / IP. Интернет-уровень соответствует сетевому уровню в модели OSI. Протокол IP является основной частью этого уровня. Кроме того, TCP / IP объединяет канал передачи данных OSI и физические уровни в один уровень, называемый уровнем доступа к сети.

Найти открытые порты в Windows

Теперь, когда мы получили все базовые знания о портах TCP и UDP, пришло время приступить к поиску, какие порты открыты и используются на вашем компьютере.

Хорошей новостью является то, что в Windows встроена довольно полезная команда, которая покажет вам, какие порты в настоящее время используются на вашем компьютере различными приложениями и службами.

Первое, что вы хотите сделать, это открыть меню «Пуск» и выполнить поиск CMD.

Теперь щелкните правой кнопкой мыши на CMD и запустите от имени администратора.

В открытой командной строке введите:

Netstat -ab

• Не беспокойтесь о длинном списке прокрутки информации быстрее, чем вы можете его прочитать. Вы можете просто использовать CTRL + C и CTRL + V, чтобы скопировать и вставить информацию в Блокнот или любой другой текстовый редактор.
• Информация в скобках – это название программы, которая использует порт. TCP или UDP относится к протоколу, используемому на этом порту. Номер состоит из IP-адреса, а затем номера порта после двоеточия.

accept()¶

См.также

• http://unixhelp.ed.ac.uk/CGI/man-cgi?accept+2

Используется для принятия запроса на установление соединения от удаленного хоста. Принимает следующие аргументы:

1. sockfd — дескриптор слушающего сокета на принятие соединения.
2. cliaddr — указатель на структуру sockaddr, для принятия информации об адресе клиента.
3. addrlen — указатель на socklen_t, определяющее размер структуры, содержащей клиентский адрес и переданной в accept(). Когда accept() возвращает некоторое значение, socklen_t указывает сколько байт структуры cliaddr использовано в данный момент.

Примечание

Функция возвращает дескриптор сокета, связанный с принятым соединением, или −1 в случае возникновения ошибки.

Пример на Си

#include <sys/types.h>
#include <sys/socket.h>
int accept(int sockfd, struct sockaddr *cliaddr, socklen_t *addrlen);

Пример на Python

Different Applications of TCP and UDP

TCP vs. UDP for Game Servers

For massively multiplayer online (MMO) games, developers often have to make an architectural choice between using UDP or TCP persistent connections. The advantages of TCP are persistent connections, reliability, and being able to use packets of arbitrary sizes. The biggest problem with TCP in this scenario is its congestion control algorithm, which treats packet loss as a sign of bandwidth limitations and automatically throttles the sending of packets. On 3G or Wi-Fi networks, this can cause a significant latency.

Experienced developer Christoffer Lernö weighed the pros and cons and recommends the following criteria to choose whether to use TCP or UDP for your game:

• Use HTTP over TCP for making occasional, client-initiated stateless queries when it’s OK to have an occasional delay.
• Use persistent plain TCP sockets if both client and server independently send packets but an occasional delay is OK (e.g. Online Poker, many MMOs).
• Use UDP if both client and server may independently send packets and occasional lag is not OK (e.g. Most multiplayer action games, some MMOs).

Протоколы и порты

Каждому устройству или компьютеру в Интернете присвоен свой уникальный номер, известный как IP-адрес. Это для конкретного компьютера, который должен быть идентифицирован, когда вы находитесь в Интернете. Информация, передаваемая через Интернет с компьютера, теперь принимается с помощью портов. Как и TCP, UDP также имеет свои специфические функции и порты. Ниже приведены некоторые из наиболее часто используемых для UDP.

Система доменных имен (DNS RFC 1034-1035: порт 53)

Протокол DNS является одним из широко используемых протоколов как в публичных, так и в частных сетях. Его основной целью является преобразование доменных имен в IP-адреса для маршрутизации по сети.
широко используется в публичном интернете и частных сетях для преобразования доменных имен в IP-адреса, обычно для маршрутизации сети. DNS-серверы могут быть настроены внутри частной сети, не будучи частью глобальной системы.

Протокол динамической конфигурации хоста (DHCP RFC 2131: порт 67/68)

Этот протокол в основном используется в сетях, не использующих статические назначения IP-адресов. Сервер может быть настроен либо инженером, либо администратором, у которого есть доступный для назначения пул адресов.
Клиент может включить устройство и запросить IP-адрес с локального DHCP-сервера, когда есть доступный адрес, он будет назначен устройству. Однако это не является постоянным назначением и истекает через определенный промежуток времени. Срок действия договора аренды истекает, если не подается запрос на продление, и он будет возвращен в пул для передачи другим устройствам.

Тривиальный протокол передачи файлов (TFP RFC 1350: порт 69)

Этот протокол, в отличие от обычного протокола передачи файлов, используемого в TCP, предлагает метод передачи данных без создания сеанса. Использование протокола TFTP не гарантирует, что передача файлов была выполнена должным образом. Этот протокол в основном используется для обновления микропрограммного обеспечения и программного обеспечения устройств.

Простой протокол сетевого управления (SNMP RFC 1901-1908, 3411-3418: порт 161-/162)

Этот протокол используется для управления сетью. Возможность мониторинга, настройки и управления сетевыми устройствами — это некоторые из возможностей SNMP. Ловушки также настраиваются таким образом, чтобы уведомлять о необходимости принятия конкретных мер и осуществлять дальнейший поиск источника события.

Протокол сетевого времени (NTP RFC 5905: порт 123)

Основной целью NTP является синхронизация устройств в Интернете, и считается одним из наиболее игнорируемых протоколов. Для поддержания точных часов в большинстве современных операционных систем используется протокол NTP

Устройство позволяет без особых усилий устранять неполадки на разных устройствах, поскольку часы точны, что делает NTP жизненно важной частью сетевых систем

В заключение хочу сказать, что на сегодняшний день UDP выполняет свою собственную задачу вместе с различными интернет-протоколами. Он все еще используется во многих основных приложениях, которые мы используем каждый день, например, для потоковой передачи видео и видеоконференций.

Задний план

UDT был разработан Юнхонг Гу во время его учебы в докторантуре Национального центра интеллектуального анализа данных (NCDM) Университета Иллинойса в Чикаго в лаборатории доктора Роберта Гроссмана. Доктор Гу продолжает поддерживать и улучшать протокол после окончания учебы.

Проект UDT стартовал в 2001 году, когда стали популярными недорогие оптические сети, которые спровоцировали более широкое осознание проблем эффективности TCP в высокоскоростных глобальных сетях. Первая версия UDT, также известная как SABUL (Simple Available Bandwidth Utility Library), была разработана для поддержки массовой передачи данных для перемещения научных данных по частным сетям. SABUL использовал UDP для передачи данных и отдельное TCP-соединение для управляющих сообщений.

В октябре 2003 года NCDM достиг скорости передачи 6,8 гигабит в секунду из Чикаго , США, в Амстердам , Нидерланды . Во время 30-минутного теста они передали примерно 1,4 терабайта данных.

Позднее SABUL был переименован в UDT, начиная с версии 2.0, выпущенной в 2004 году. UDT2 удалил управляющее соединение TCP в SABUL и использовал UDP как для данных, так и для управляющей информации. UDT2 также представил новый алгоритм управления перегрузкой, который позволил протоколу работать «справедливо и дружелюбно» с одновременными потоками UDT и TCP.

UDT3 (2006) распространил использование протокола на бытовой Интернет. Контроль перегрузки также был настроен для поддержки относительно низкой пропускной способности. UDT3 также значительно сократил использование системных ресурсов (ЦП и памяти). Кроме того, UDT3 позволяет пользователям легко определять и устанавливать свои собственные алгоритмы управления перегрузкой.

UDT4 (2007) представил несколько новых функций для лучшей поддержки высокой степени параллелизма и обхода межсетевого экрана. UDT4 позволял нескольким UDT-соединениям связываться с одним и тем же UDP-портом, а также поддерживал настройку рандеву-соединения для упрощения пробивки отверстий UDP .

Пятая версия протокола в настоящее время находится на стадии планирования. Возможные функции включают возможность поддержки нескольких независимых сеансов через одно соединение.

Более того, поскольку отсутствие функции безопасности для UDT было проблемой при ее первоначальном внедрении в коммерческую среду, Бернардо (2011) разработал архитектуру безопасности для UDT в рамках своих докторских исследований. Однако эта архитектура подвергается усовершенствованию для поддержки UDT в различных сетевых средах (например, оптических сетях).