Udp протокол

Subnetting

Сеть TCP/IP класса A, B или C может быть дополнительно разделена системным администратором или подсети. Это становится необходимым при согласовании логической адресной схемы Интернета (абстрактного мира IP-адресов и подсетей) с физическими сетями, которые используются в реальном мире.

Системный администратор, которому выделен блок IP-адресов, может управлять сетями, которые не организованы таким образом, чтобы легко вписываться в эти адреса. Например, у вас есть широкая сеть с 150 хостами в трех сетях (в разных городах), подключенных маршрутизатором TCP/IP. Каждая из этих трех сетей имеет 50 хостов. Вам выделена сеть класса C 192.168.123.0. (Для иллюстрации этот адрес на самом деле из диапазона, который не выделяется в Интернете.) Это означает, что для 150 хостов можно использовать адреса 192.168.123.1 по 192.168.123.254.

Два адреса, которые не могут использоваться в вашем примере, являются 192.168.123.0 и 192.168.123.255, так как двоичные адреса с хост-частью всех и все нули недействительны. Нулевой адрес недействителен, так как используется для указания сети без указания хоста. 255-й адрес (в двоичной нотации— хост-адрес всех) используется для передачи сообщения каждому хосту в сети. Просто помните, что первый и последний адрес в любой сети или подсети не может быть назначен любому отдельному хосту.

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

В этом случае вы разделите сеть на четыре подсети, используя подсетевую маску, которая делает сетевой адрес больше и возможный диапазон адресов хостов меньше. Другими словами, вы «заимствуете» некоторые биты, используемые для хост-адреса, и используете их для сетевой части адреса. Подсетевая маска 255.255.255.192 предоставляет четыре сети по 62 хостов каждая. Он работает, так как в двоичной нотации 255.255.255.192 то же самое, что и 11111111.1111111.110000000. Первые две цифры последнего октета становятся сетевыми адресами, поэтому вы получаете дополнительные сети 00000000 (0), 010000000 (64), 10000000 (128) и 110000000 (192). (Некоторые администраторы будут использовать только две подсети с использованием 255.255.255.192 в качестве маски подсети. Дополнительные сведения по этому вопросу см. в разделе RFC 1878.) В этих четырех сетях последние шесть двоичных цифр можно использовать для хост-адресов.

Используя подсетевую маску 255.255.255.192, сеть 192.168.123.0 становится четырьмя сетями 192.168.123.0, 192.168.123.64, 192.168.123.128 и 192.168.123.192. Эти четыре сети будут иметь допустимые хост-адреса:

192.168.123.1-62 192.168.123.65-126 192.168.123.129-190 192.168.123.193-254

Помните, что двоичные хост-адреса со всеми или всеми нулями являются недействительными, поэтому нельзя использовать адреса с последним октетом 0, 63, 64, 127, 128, 191, 192 или 255.

Вы можете увидеть, как это работает, глядя на два хост-адреса, 192.168.123.71 и 192.168.123.133. Если используется маска подсети класса C по умолчанию 255.255.255.0, оба адреса находятся в сети 192.168.123.0. Однако, если вы используете подсетевую маску 255.255.255.192, они находятся в разных сетях; 192.168.123.71 на сети 192.168.123.64, 192.168.123.133 — на сети 192.168.123.128.

Оценка возможных механизмов безопасности

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

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

Чтобы проанализировать механизмы безопасности, они проводят формальное доказательство правильности, чтобы помочь им определить их применимость с помощью логики композиции протокола (PCL). Этот подход является модульным, включает отдельное подтверждение каждого раздела протокола и дает представление о сетевой среде, в которой каждый раздел может быть надежно использован. Более того, доказательство справедливо для множества стратегий восстановления после сбоев и других вариантов реализации и конфигурации. Они заимствуют свою технику из PCL по TLS и Kerberos в литературе. Они работают над разработкой и проверкой его архитектуры безопасности с использованием систем перезаписи и автоматов.

Результатом их работы, которая является первым в литературе, является более надежное теоретическое и практическое представление архитектуры безопасности UDT, пригодное для работы с другими высокоскоростными сетевыми протоколами.

Задний план

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 в различных сетевых средах (например, оптических сетях).

Протокол UDP: что это и как работает?

Была основана Протокол UDP (протокол пользовательских дейтаграмм) является одним из основных протоколов в Интернете, он позволяет приложениям обмениваться данными с гарантиями независимо от нижних уровней модели TCP / IP. Это означает, что маршрутизаторы (сетевой уровень в модели TCP / IP) должны отправлять только дейтаграммы (единица измерения в UDP). UDP поддерживает несколько протоколов прикладного уровня, например, популярный DNS и даже протокол DHCP для автоматического получения (и предоставления) IP-адресации.

основные черты

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

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

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

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

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

Заголовок UDP

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

Давайте сначала поговорим об UDP

Давайте посмотрим на заголовок UDP

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

Следовательно, UDP похож на монаха, без желаний и желаний, и он очень прост, но имеет следующие три характеристики:

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

Наконец, давайте поговорим об основных сценариях применения UDP.

1. Интрасеть с небольшим количеством ресурсов и стабильными сетевыми условиями или приложения, не чувствительные к потере пакетов, такие как DHCP, основаны на протоколе UDP.
2. Для установления соединения нет необходимости в личном общении, а требуется приложение, которое может транслировать. Поскольку он не ориентирован на соединение, он может работать по принципу «один ко многим» и использовать протоколы широковещательной или многоадресной рассылки.
3. Он должен обрабатываться быстро и может допускать потерю пакетов, но даже если сеть перегружена, он не сокращается назад и никогда не продвигается вперед.

Наконец, несколько примеров на основе UDP

1. Прямой эфир. Прямая трансляция предъявляет относительно высокие требования к производительности в реальном времени. Она скорее потеряет пакеты, чем зависнет, поэтому многие приложения для прямой трансляции реализовали свои собственные протоколы передачи видео на основе UDP.
2. Игры в реальном времени. Игра также отличается высокой производительностью в реальном времени. В этом случае использование настраиваемого и надежного протокола UDP и настраиваемой стратегии повторной передачи может минимизировать задержку и снизить влияние сетевых проблем на игру.
3. Интернет вещей. С одной стороны, в области Интернета вещей мало ресурсов для прерывания, и вполне вероятно, что знания о встроенной системе очень малы, а стоимость поддержки протокола TCP слишком велика; с другой стороны, Интернет вещей предъявляет особенно высокие требования к производительности в реальном времени. Например, группа Google Nest Resume Thread Group запустила протокол передачи данных Интернета вещей Thread, который основан на протоколе UDP.

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

Каждому устройству или компьютеру в Интернете присвоен свой уникальный номер, известный как 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 выполняет свою собственную задачу вместе с различными интернет-протоколами. Он все еще используется во многих основных приложениях, которые мы используем каждый день, например, для потоковой передачи видео и видеоконференций.

Приложения

Многие ключевые интернет-приложения используют 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?

Для протокола TCP порт с номером 0 зарезервирован и не может использоваться. Для протокола UDP указание порта процесса-отправителя («обратного» порта) не является обязательным, и порт с номером 0 означает отсутствие порта. Таким образом, номер порта — число в диапазоне от 1 до 216-1=65 535.

Соединение TCP

Чтобы установить соединение между двумя процессами на разных компьютерах сети, необходимо знать не только интернет-адреса компьютеров, но и номера тех ТСР-портов (sockets), которые процессы используют на этих компьютерах. Любое TCP-соединение в сети Интернет однозначно идентифицируется двумя IP-адресами и двумя номерами ТСР-портов.

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

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

Сокеты TCP

Активные TCP соединения с интернетом (w/o servers)

# netstat -nt
Proto Recv-Q Send-Q Local Address Foreign Address State      
tcp        0      0 192.26.95.251:56981     10.161.85.55:22        ESTABLISHED
tcp        0      0 10.26.95.251:44596      10.26.95.226:2193       ESTABLISHED

Для сокетов TCP допустимы следующие значения состояния:

CLOSED 	        Закрыт. Сокет не используется.
LISTEN 	        Сокет ожидает входящих соединений.
SYN_SENT 	Активно пытается установить соединение. Cокет в процессе установки соединения.
SYN_RECEIVED (SYN_RCVD)	Идет начальная синхронизация соединения. Был принят запрос установки соединения из сети.
ESTABLISHED 	Соединение установлено.
CLOSE_WAIT 	Удаленная сторона отключилась; ожидание закрытия сокета.
FIN_WAIT_1 	Сокет закрыт; соединение закрывается.
CLOSING 	Сокет закрыт, затем удаленная сторона отключилась; ожидание подтверждения.
LAST_ACK 	Удаленная сторона отключилась, затем сокет закрыт; ожидание подтверждения.
FIN_WAIT_2 	Сокет закрыт; ожидание отключения удаленной стороны.
TIME_WAIT 	Сокет закрыт, но ожидает пакеты, ещё находящиеся в сети для обработки
UNKNOWN         Статус сокета неизвестен.

Что такое TCP RST?

TCP RST – это сегмент TCP (обратите внимание, что TCP посылает сообщения сегментами, а НЕ пакетами, что часто неправильно употребляется в среде сетевых администраторов), который показывает, что с соединением что-то не так. RST посылается в следующих случаях:

• Посылается SYN для несуществующего сервера.
• TCP хочет прервать соединение.
• Получен сегмент, для которого не существует соединения.

Применение TCP

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

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

bind()¶

См.также

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

Связывает сокет с конкретным адресом. Когда сокет создается при помощи socket(), он ассоциируется с некоторым семейством адресов, но не с конкретным адресом. До того как сокет сможет принять входящие соединения, он должен быть связан с адресом. bind() принимает три аргумента:

1. sockfd — дескриптор, представляющий сокет при привязке
2. serv_addr — указатель на структуру sockaddr, представляющую адрес, к которому привязываем.
3. addrlen — поле socklen_t, представляющее длину структуры sockaddr.

Примечание

Возвращает 0 при успехе и −1 при возникновении ошибки.

Пример на Си

#include <sys/types.h>
#include <sys/socket.h>

int bind(int sockfd, const struct sockaddr *my_addr, socklen_t addrlen);

Пример на Python

server_address = ('localhost', 8080)
sock_obj.bind(server_address)  # Привязка адреса и порта к сокету.

Автоматическое получение имени хоста.

Сравнение UDP и TCP

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

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

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

• Ненадежный — при отправке сообщения UDP нельзя узнать, достигнет ли оно места назначения; он мог потеряться по пути. Нет концепции подтверждения, повторной передачи или тайм-аута.
• Не упорядочено — если два сообщения отправлены одному и тому же получателю, порядок их доставки не может быть гарантирован.
• Легковесный — сообщения не упорядочиваются, не отслеживаются соединения и т. Д. Это очень простой транспортный уровень, разработанный поверх IP.
• Датаграммы — пакеты отправляются индивидуально и проверяются на целостность по прибытии. Пакеты имеют определенные границы, которые соблюдаются при получении; операция чтения в сокете-получателе даст все сообщение в том виде, в котором оно было изначально отправлено.
• Нет контроля перегрузки — UDP сам по себе не предотвращает перегрузку. Меры по контролю за перегрузкой должны быть реализованы на уровне приложений или в сети.
• Широковещательные рассылки — протокол UDP не требует установления соединения — отправленные пакеты могут быть адресованы для приема всеми устройствами в подсети.
• Многоадресная рассылка — поддерживается режим многоадресной рассылки, при котором один пакет дейтаграммы может автоматически маршрутизироваться без дублирования группе подписчиков.

SOCK_STREAM vs SOCK_DGRAM¶

См.также

• UDP
• TCP

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

Заголовок 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 программы используют зарезервированные или хорошо известные номера портов, как показано на следующем рисунке.

Надежность и контроль перегрузок

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

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

Протокол TCP

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

Передача информации через TCP протокол начинается с установления соединения с получателем. Он должен известить о том, что готов получить информацию. Только после этого начинается передача данных. С TCP протоколом вы можете быть уверены, что получатель реален и он готов получить информацию от вас. Это увеличивает надежность передаваемых данных. После завершения процесса, отправитель должен сообщить, что больше информация поступать не будет. Получатель же должен ответить, что он понял это и получил все данные.

Информация передается пакетами. Каждый пакет нумеруется и передается в связи со своим порядковым номером. К тому же после передачи нескольких пакетов, TCP протокол запросит подтверждение получателя о том, что они были получены. Если ответа не последовало, то операция передачи повторяется. И так происходит несколько раз. Если все попытки так и не увенчались успехом, то TCP протокол разрывает соединение. При этом, если сеть между узлами слабая, то запросы о получении будут происходить чаще. В этом и заключается особенность TCP соединения

Он готов работать с любыми сетями, не обращая внимание на их надежность

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