Tcp протокол

Содержание

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


Основная статья: Транспортный уровень

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

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

Упорядоченность — если два сообщения последовательно отправлены, первое сообщение достигнет приложения-получателя первым. Если участки данных прибывают в неверном порядке, TCP отправляет неупорядоченные данные в буфер до тех пор, пока все данные не могут быть упорядочены и переданы приложению.

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

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

UDP — более простой, основанный на сообщениях протокол без установления соединения. Протоколы такого типа не устанавливают выделенного соединения между двумя хостами. Связь достигается путём передачи информации в одном направлении от источника к получателю без проверки готовности или состояния получателя. В приложениях для голосовой связи через интернет-протокол (Voice over IP, TCP/IP) UDP имеет преимущество над TCP, в котором любое «рукопожатие» помешало бы хорошей голосовой связи. В VoIP считается, что конечные пользователи в реальном времени предоставят любое необходимое подтверждение о получении сообщения.

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

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

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

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

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

IP-адрес

Каждый узел в сети TCP/IP может быть идентифицирован 32-битным IP-адресом. Обычно IP-адрес представляется четырьмя десятичными значениями в таком виде: 192.168.0.1. Каждое из этих чисел представляет собой один байт IP-адреса и может находиться в пределах от 0 до 255.

IP-адрес содержит две части: сетевую часть и часть хоста. В зависимости от класса сети сетевая часть состоит из одного, двух или трех байтов:

Класс Байт 1 Байт 2 Байт 3 Байт 4
A Сеть (1—126) Хост (0-255) Хост (0—255) Хост (0—255)
B Сеть (128—191) Сеть (0—255) Хост (0—255) Хост (0—255)
C Сеть (192—223) Сеть (0—255) Сеть (0—255) Хост (0—255)

Первый бит адреса сети класса А должен быть 0, поэтому первый байт для сети класса А имеет двоичные значения в пределах от 00000001 (1) до 01111110 (126). Остальные три байта служат для идентификации узлов в сети, позволяя соединить в сети класса А более 16 млн. устройств.

Заметим, что в приведенной таблице адреса с числом 127 в первом байте пропущены, поскольку это зарезервированный диапазон адресов. Адрес 127.0.0.1 — это всегда адрес локального хоста, а 127.0.0.0 — адрес локальной обратной связи. Обратная связь используется для тестирования стека сетевых протоколов на одной машине, без прохода через сетевую интерфейсную плату.

В IP-адресе для сети класса В первые два бита всегда имеют значение 10, что дает диапазон от 10000000 (128) до 10111111 (191). Второй байт продолжает идентификацию сети значением от 0 до 255, оставляя два последних байта для идентификации узлов сети, всего до 65 534 устройств.

Сети класса С отличаются IP-адресом, в котором в первых трех битах установлено значение 110, разрешая значения в диапазоне от 11000000 (192) до 11011111 (223). В сети этого типа лишь один байт оставлен для идентификации узлов, поэтому к ней можно подсоединить только 254 устройства.

Число устройств, которое можно подсоединить к сети каждого из этих классов с особыми IP-адресами, обратно пропорционально числу возможных сетей этого типа. Например, сеть класса А, допуская 16 млн. хостов, оставляет только часть первого байта для идентификации сети. В результате во всем мире может существовать лишь 126 сетей класса А. Только крупные компании, подобные AT & Т, IBM, Xerox и HP, имеют такой сетевой адрес. Когда компания запрашивает IP-сеть в органе, ведающем сетями, обычно она получает сеть класса С.

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

Сетевые адреса классов А, В и С оставляют свободными адреса, имеющие в первом байте значения от 224 до 255.

Агентство IANA выделяет номера сетей и публикует их перечень на странице http://www.iana.org/assignments/ipv4-adclress-space. Почти во всех странах есть региональные регистрационные ведомства, выдающие по запросам номера сетей. Региональные ведомства получают диапазон сетей от IANA.

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

Структура пакета

UDP не предоставляет никаких гарантий доставки сообщения для вышестоящего протокола и не сохраняет состояния отправленных сообщений. По этой причине UDP иногда называют Unreliable Datagram Protocol (англ. — Ненадёжный протокол датаграмм).

UDP обеспечивает многоканальную передачу (с помощью номеров портов) и проверку целостности (с помощью контрольных сумм) заголовка и существенных данных. Надёжная передача в случае необходимости должна реализовываться пользовательским приложением.

Биты 0 — 15 16-31
0-31 Порт отправителя (Source port) Порт получателя (Destination port)
32-63 Длина датаграммы (Length) Контрольная сумма (Checksum)
64-… Данные (Data)

Заголовок UDP состоит из четырёх полей, каждое по 2 байта (16 бит). Два из них необязательны к использованию в IPv4 (розовые ячейки в таблице), в то время как в IPv6 необязателен только порт отправителя.

Порт отправителя

В этом поле указывается номер порта отправителя. Предполагается, что это значение задаёт порт, на который при необходимости будет посылаться ответ. В противном же случае, значение должно быть равным 0. Если хостом-источником является клиент, то номер порта будет, скорее всего, динамическим. Если источником является сервер, то его порт будет одним из «хорошо известных».

Порт получателя

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

Длина датаграммы

Поле, задающее длину всей датаграммы (заголовка и данных) в байтах. Минимальная длина равна длине заголовка — 8 байт. Теоретически, максимальный размер поля — 65535 байт для UDP-датаграммы (8 байт на заголовок и 65527 на данные). Фактический предел для длины данных при использовании IPv4 — 65507 (помимо 8 байт на UDP-заголовок требуется ещё 20 на IP-заголовок).

На практике также следует учитывать, что если длина IPv4 пакета с UDP будет превышать MTU (для Ethernet по умолчанию 1500 байт), то отправка такого пакета может вызвать его фрагментацию, что может привести к тому, что он вообще не сможет быть доставлен, если промежуточные маршрутизаторы или конечный хост не будут поддерживать фрагментированные IP пакеты. Также в RFC791 указывается минимальная длина IP пакета 576 байт, которую должны поддерживать все участники, и рекомендуется отправлять IP пакеты большего размера только в том случае если вы уверены, что принимающая сторона может принять пакеты такого размера. Следовательно, чтобы избежать фрагментации UDP пакетов (и возможной их потери), размер данных в UDP не должен превышать: MTU — (Max IP Header Size) — (UDP Header Size) = 1500 — 60 — 8 = 1432 байт. Для того чтобы быть уверенным, что пакет будет принят любым хостом, размер данных в UDP не должен превышать: (минимальная длина IP пакета) — (Max IP Header Size) — (UDP Header Size) = 576 — 60 — 8 = 508 байт.

В Jumbogram’мах IPv6 пакеты UDP могут иметь больший размер. Максимальное значение составляет 4 294 967 295 байт (232 — 1), из которых 8 байт соответствуют заголовку, а остальные 4 294 967 287 байт — данным.

Следует заметить, что большинство современных сетевых устройств отправляют и принимают пакеты IPv4 длиной до 10000 байт без их разделения на отдельные пакеты. Неофициально такие пакеты называют «Jumbo-пакетами», хотя понятие Jumbo официально относится к IPv6. Тем не менее, «Jumbo-пакеты» поддерживают не все устройства и перед организацией связи с помощью UDP/IP IPv4 посылок с длиной превышающей 1500 байт нужно проверять возможность такой связи опытным путём на конкретном оборудовании.

Контрольная сумма

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

Версия 4


Основная статья: IPv4

В современной сети Интернет используется IP четвёртой версии, также известный как IPv4. В протоколе IP этой версии каждому узлу сети ставится в соответствие IP-адрес длиной 4 октета (4 байта). При этом компьютеры в подсетях объединяются общими начальными битами адреса. Количество этих бит, общее для данной подсети, называется маской подсети (ранее использовалось деление пространства адресов по классам — A, B, C; класс сети определялся диапазоном значений старшего октета и определял число адресуемых узлов в данной сети, сейчас используется бесклассовая адресация).

TCP vs self-made UDP

  • С перегрузками, когда пакетов очень много и некоторые из них дропаются из-за перегрузки каналов или оборудования.
  • Высокоскоростные с большими round-trip (например когда сервер располагается относительно далеко).
  • Странные — когда в сети вроде бы ничего не происходит, но пакеты все равно пропадают просто потому-что Wi-Fi точка доступа находится за стенкой.
  • Профиль Видео, когда вы подключаетесь и стримите тот или иной контент. Скорость соединения увеличивается, как на верхнем графике. Требования к этому протоколу: низкие задержки и адаптация битрейта.
  • Вариант просмотра Ленты: импульсная загрузка данных, фоновые запросы, промежутки простоя. Требования к этому протоколу: получаемые данные мультиплексируются и приоритизируются, приоритет пользовательского контента выше фоновых процессов, есть отмена загрузки.

Отличия HTTP 2.0

  • бинарный, сжатие заголовков;
  • мультиплексирование данных;
  • приоритизация;
  • возможна отмена загрузки;
  • server push

Высокоприоритетный контент загружается раньше.Server pushReset stream

  • Профилях сети: Wi-Fi, 3G, LTE.
  • Профилях потребления: cтриминг (видео), мультиплексирование и приоритизация с отменой загрузки (HTTP/2) для получения контента ленты. 

Размер буфера

  • пакеты 1 и 2 уже отправлены, для них получено подтверждение;
  • пакеты 3, 4, 5, 6 отправлены, но результат доставки неизвестен (on-the-fly packets);
  • остальные пакеты находятся в очереди.

Вывод:

Congestion control

  • Flow control — это некий механизм защиты от перегрузки. Получатель говорит, на какое количество данных у него реально есть место в буфере, чтобы он был готов их принять. Если передать сверх flow control или recv window, то эти пакеты просто будут выкинуты. Задача flow control — это back pressure от нагрузки, то есть просто кто-то не успевает вычитывать данные.
  • У congestion control совершенно другая задача. Механизмы схожие, но задача — спасти сеть от перегрузки.
  • Если TCP window = 1, то данные передаются как на схеме слева: дожидаемся acknowledgement, отправляем следующий пакет и т.д. 
  • Если TCP window = 4, то отправляем сразу пачку из четырех пакетов, дожидаемся acknowledgement и дальше работаем.
  • На верхней схеме сеть, в которой все хорошо. Пакеты отправляются с заданной частотой, с такой же частотой возвращаются подтверждения. 
  • Во второй строке начинается перегруз сети: пакеты идут чаще, acknowledgements приходят с задержкой. 
  • Данные копятся в буферах на маршрутизаторах и других устройствах и в какой-то момент начинают пропускать пакеты, acknowledgements на эти пакеты не приходят (нижняя схема).
  • Cubic — дефолтный Congestion Control с Linux 2.6. Именно он используется чаще всего и работает примитивно: потерял пакет — схлопнул окно.
  • BBR — более сложный Congestion Control, который придумали в Google в 2016 году. Учитывает размер буфера.

BBR Congestion Control

  • BBR понимает, что идет переполнение буфера, и пытается схлопнуть окно, уменьшить нагрузку на маршрутизатор. 
  • Cubic дожидается потери пакета и после этого схлопывает окно.

jitter

Какой Congestion control выбрать

Выводы про congestion control:

  • Для видео всегда хорош BBR. 
  • В остальных случаях, если мы используем свой UDP-протокол, можно взять congestion control с собой.
  • С точки зрения TCP можно использовать только congestion control, который есть в ядре. Если хотите реализовать свой congestion control в ядро, нужно обязательно соответствовать спецификации TCP. Невозможно раздуть acknowledgement, сделать изменения, потому что просто их нет на клиенте.

Управление таймером

TCP использует различные типы таймеров для управления и управления различными задачами:

Таймер сохранения:

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

Таймер повторной передачи:

  • Этот таймер поддерживает сеанс передачи данных с сохранением состояния.
  • Если подтверждение отправленных данных не будет получено в течение времени повторной передачи, сегмент данных будет отправлен снова.

Постоянный таймер:

  • Сеанс TCP может быть приостановлен хостом, отправив Размер окна 0.
  • Чтобы возобновить сеанс, хосту необходимо отправить размер окна с некоторым большим значением.
  • Если этот сегмент никогда не достигнет другого конца, оба конца могут ждать друг друга в течение бесконечного времени.
  • Когда таймер Persist истекает, хост повторно отправляет свой размер окна, чтобы узнать другой конец. Persist Timer помогает избежать взаимоблокировок в общении.

Timed-Wait:

  • После освобождения соединения один из хостов ждет времени с пометкой времени, чтобы полностью завершить соединение.
  • Это делается для того, чтобы убедиться, что другой конец получил подтверждение своего запроса о завершении соединения.
  • Выдержка может быть не более 240 секунд (4 минуты).

Мультиплексирование

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

Используя TCP Multiplexing, клиент может взаимодействовать с несколькими различными процессами приложения за один сеанс. Например, клиент запрашивает веб-страницу, которая, в свою очередь, содержит различные типы данных (HTTP, SMTP, FTP и т. Д.), Тайм-аут сеанса TCP увеличивается, и сеанс остается открытым на более длительное время, так что накладные расходы на трехстороннюю рукопожатие могут избегать.

Это позволяет клиентской системе получать несколько соединений по одному виртуальному соединению. Эти виртуальные соединения не подходят для серверов, если тайм-аут слишком длинный.

Что есть MAC-адрес

Дело в том, что пересылаемые пакеты в сети адресуются компьютерам не по их именам и не на IP-адрес. Пакет предназначается устройству с конкретным адресом, который и называется MAC-адресом.


MAC-адрес — это уникальный адрес сетевого устройства, который заложен в него изготовителем оборудования, т.е. это этакий проштампованный номер Вашей сетевой карты. Первая половина MAC-адрес представляет собой идентификатор изготовителя, вторая — уникальный номер данного устройства.

Как правило MAC-адрес бывает требуется для идентификации, скажем, у провайдера (если провайдер использует привязку по мак-адресу вместо логина-пароля) или при настройке маршрутизатора.

Сетевые протоколы 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 и пр.

Приложения

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

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

Служебные порты

Основная статья: Порт (TCP/IP)

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

IANA разбила номера портов на три группы.

  • Порты с номерами от 0 до 1023 используются для обычных, хорошо известных служб. В Unix-подобных операционных системах для использования таких портов необходимо разрешение суперпользователя.
  • Порты с номерами от 1024 до 49151 предназначены для зарегистрированных IANA служб.
  • Порты с 49152 по 65535 могут быть использованы для любых целей, поскольку официально не разработаны для какой-то определённой службы. Они также используются как динамические (временные) порты, которые запущенное на хосте программное обеспечение может случайным образом выбрать для самоопределения. По сути, они используются как временные порты в основном клиентами при связи с серверами.

Надёжность и решения проблемы перегрузок

Из-за недостатка надёжности приложения UDP должны быть готовы к некоторым потерям, ошибкам и дублированиям. Некоторые из них (например, TFTP) могут при необходимости добавить элементарные механизмы обеспечения надёжности на прикладном уровне.

Но чаще такие механизмы не используются UDP-приложениями и даже мешают им. Потоковые медиа, многопользовательские игры в реальном времени и VoIP — примеры приложений, часто использующих протокол UDP. В этих конкретных приложениях потеря пакетов обычно не является большой проблемой. Если приложению необходим высокий уровень надёжности, то можно использовать другой протокол (TCP) или воспользоваться методами помехоустойчивого кодирования (Erasure code<span title=»Статья «Erasure code» в русском разделе отсутствует»>ru</span>en).

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

Сетевые механизмы были предназначены для того, чтобы свести к минимуму возможные эффекты от перегрузок при неконтролируемых, высокоскоростных нагрузках. Такие сетевые элементы, как маршрутизаторы, использующие пакетные очереди и техники сброса, часто являются единственным доступным инструментом для замедления избыточного UDP-трафика. DCCP (англ. Datagram Congestion Control Protocol — протокол контроля за перегрузками датаграмм) разработан как частичное решение этой потенциальной проблемы с помощью добавления конечному хосту механизмов для отслеживания перегрузок для высокоскоростных UDP-потоков вроде потоковых медиа.

Принципы надежной передачи данных

Надежная передача данных по совершенно надежному каналу

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

Надежная передача данных по каналу с возможными ошибками

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

В таком случае применяются механизмы:

  • обнаружения ошибки;
  • обратной связи;
  • повторной передачи.

Протоколы надежной передачи данных, обладающие подобными механизмами многократного повторения передачи, называются протоколами с автоматическим запросом повторной передачи (Automatic Repeat reQuest, ARQ). Дополнительно, стоит предусмотреть возможность ошибок и в квитанциях, когда принимающая сторона не получит никакой информации о результатах передачи последнего пакета. Решение этой задачи, используемое в том числе в TCP, состоит в добавлении в пакет данных нового поля, содержащего порядковый номер пакета.

Надежная передача данных по ненадежному каналу, допускающему искажение и потерю пакетов

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

  • определения факта потери пакетов;
  • повторной доставки потерянных пакетов принимающей стороне.

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

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

  • контрольными суммами;
  • порядковыми номерами пакетов;
  • таймерами;
  • положительными и отрицательными квитанциями.

Но и это не все!

Протокол надежной передачи данных с конвейеризацией


В том варианте, который мы уже рассмотрели, протокол надежной доставки очень неэфективен. Он начинает «тормозить» передачу, обеспечиваемую каналом связи, при увеличении RTT. Для повышения его эффективности, лучшей утилизации пропускной способности канала связи применяют конвейеризацию.

Применение конвейеризации приводит к:

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

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

  • возвращение на N пакетов назад;
  • выборочное повторение.

Возвращение на N пакетов назад — протокол скользящего окна

Отправитель должен поддерживать три типа событий:

  • вызов протоколом более высокого уровня. Когда «сверху» вызывается функция отправки данных, передающая сторона сначала проверяет степень заполнения окна (то есть наличие N посланных сообщений, ожидающих получения квитанций). Если окно оказывается незаполненным, новый пакет формируется и передается, а значения переменных обновляются. В противном случае передающая сторона возвращает данные верхнему уровню, и это является неявным указанием, что окно заполнено. Обычно верхний уровень предпринимает повторную попытку передачи данных через некоторое время. В реальном приложении отправитель, скорее всего, либо буферизовал бы данные (вместо немедленной отсылки), либо имел механизм синхронизации (например, семафор или флаг), который позволял бы вышестоящему уровню вызывать функцию отправки данных только при незаполненном окне.
  • получение подтверждения. В протоколе для пакета с порядковым номером N выдается общая квитанция, указывающая на то, что все пакеты с порядковыми номерами, предшествующими N, успешно приняты.
  • истечение интервала ожидания. Для определения фактов потерь и задержек пакетов и квитанций протокол использует таймер. Если интервал ожидания истекает, передающая сторона повторно отправляет все посланные неподтвержденные пакеты.

Выборочное повторение

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

Расчёт контрольной суммы

Метод для вычисления контрольной суммы определён в RFC 1071.

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

Для расчёта контрольной суммы псевдозаголовок и UDP-сообщение разбивается на двухбайтные слова. Затем рассчитывается сумма всех слов в арифметике обратного кода (то есть кода, в котором отрицательное число получается из положительного инверсией всех разрядов числа и существует два нуля: 0х0000 (обозначается +0) и (обозначается −0)). Результат записывается в соответствующее поле в UDP-заголовке.

Значение контрольной суммы, равное 0х0000 (+0 в обратном коде), зарезервировано и означает, что для посылки контрольная сумма не вычислялась. В случае, если контрольная сумма вычислялась и получилась равной 0х0000, то в поле контрольной суммы заносят значение (-0 в обратном коде).

При получении сообщения получатель считает контрольную сумму заново (уже учитывая поле контрольной суммы), и, если в результате получится −0 (то есть ), то контрольная сумма считается сошедшейся. Если сумма не сходится (данные были повреждены при передаче, либо контрольная сумма неверно посчитана на передающей стороне), то решение о дальнейших действиях принимает принимающая сторона. Как правило, в большинстве современных устройств, работающих с UDP/IP-пакетами имеются настройки, позволяющие либо игнорировать такие пакеты, либо пропускать их на дальнейшую обработку, невзирая на неправильность контрольной суммы.

Пример расчёта контрольной суммы

Для примера рассчитаем контрольную сумму нескольких 16-битных слов: .

Для этого можно сначала сложить попарно числа, рассматривая их как 16-разрядные беззнаковые числа с последующим приведением к дополнительному коду путём прибавления единицы к результату, если при сложении произошёл перенос в старший (17-й) разряд (то есть де-факто, этой операцией мы переводим отрицательное число из дополнительного в обратный код). Или, что равноценно, можно считать, что перенос прибавляется к младшему разряду числа.

0x398a + 0xf802 = 0x1318c → 0x318d (перенос в старший разряд)
0x318d + 0x14b2 = 0x0463f → 0x463f (число положительное)
0x463f + 0xc281 = 0x108c0 → 0x08c1

В конце выполняется инверсия всех битов получившегося числа

или, иначе — . Это и есть искомая контрольная сумма.

В документе RFC 1071 приведены и другие способы расчёта контрольной суммы, в частности, с использованием 32х-разрядной арифметики.

TCP— Transmission Control Protocol

Обмен данными, ориентированный на соединения, может использовать надежную связь, для обеспечения которой протокол уровня 4 посылает подтверждения о получении данных и запрашивает повторную передачу, если данные не получены или искажены. Протокол TCP использует именно такую надежную связь. TCP используется в таких прикладных протоколах, как HTTP, FTP, SMTP и Telnet.

Протокол TCP требует, чтобы перед отправкой сообщения было открыто соединение. Серверное приложение должно выполнить так называемое пассивное открытие (passive open), чтобы создать соединение с известным номером порта, и, вместо того чтобы отправлять вызов в сеть, сервер переходит в ожидание поступления входящих запросов. Клиентское приложение должно выполнить активное открытие (active open), отправив серверному приложению синхронизирующий порядковый номер (SYN), идентифицирующий соединение. Клиентское приложение может использовать динамический номер порта в качестве локального порта.

Сервер должен отправить клиенту подтверждение (ACK) вместе с порядковым номером (SYN) сервера. В свою очередь клиент отвечает АСК, и соединение устанавливается.

После этого может начаться процесс отправки и получения сообщений. При получении сообщения в ответ всегда отправляется сообщение АСК. Если до получения АСК отправителем истекает тайм-аут, сообщение помещается в очередь на повторную передачу.

Поля заголовка TCP перечислены в следующей таблице:

Заголовок TCP
Поле Длина Описание
Порт источника 2 байта Номер порта источника
Порт назначения 2 байта Номер порта назначения
Последовательный номер 4 байта Последовательный номер генерируется источником и используется назначением, чтобы переупорядочить пакеты для создания исходного сообщения и отправить подтверждение источнику.
Номер подтверждения 4 байта Если установлен бит АСК поля «Управление», в данном поле содержится следующий ожидаемый последовательный номер.
Смещение данных 4 бита Информация о начале пакета данных.
Резерв 6 битов Резервируются для будущего использования.
Управление 6 битов Биты управления содержат флаги, указывающие, верны ли поля подтверждения (АСК), указателя срочности (URG), следует ли сбрасывать соединение (RST), послан ли синхронизирующий последовательный номер (SYN) и т. д.
Размер окна 2 байта В этом поле указывается размер приемного буфера. Используя подтверждающие сообщения, получатель может информировать отправителя о максимальном размере данных, которые тот может отправить.
Контрольная сумма 2 байта Контрольная сумма заголовка и данных; по ней определяется, был ли искажен пакет.
Указатель срочности 2 байта В этом поле целевое устройство получает информацию о срочности данных.
Опции переменная Необязательные значения, которые указываются при необходимости.
Дополнение переменная В поле дополнения добавляется столько нулей, чтобы заголовок заканчивался на 32-битной границе.

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

Протокол TCP имеет встроенную возможность надежной доставки. Если сообщение не отправлено корректно, мы получим сообщение об ошибке. Протокол TCP определен в RFC 793.


С этим читают