16. Протокол tcp, udp. Работа протоколов. Форматы заголовков.

В данном разделе будет рассмотрен протокол TCP в общих чертах. В следующем

разделе мы обсудим заголовок протокола, поле за полем.

Ключевым свойством TCP, определяющим всю структуру протокола, являет-

ся то, что в TCP-соединении у каждого байта есть свой 32-разрядный порядко-

вый номер. В первые годы существования Интернета базовая скорость передачи

данных между маршрутизаторами по выделенным линиям составляла 56 Кбит/с.

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

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

нынешних скоростях порядковые номера могут кончиться очень быстро, об этом

еще будет сказано позже. Отдельные 32-разрядные порядковые номера исполь-

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

дет сказано позже.

Отправляющая и принимающая TCP-сущности обмениваются данными в ви-

де сегментов. Сегмент состоит из фиксированного 20-байтового заголовка (плюс

необязательная часть), за которой могут следовать байты данных. Размер сег-

ментов определяется программным обеспечением TCP. Оно может объединять

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

или, наоборот, распределять результат одной записи между несколькими сегмен-

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

мент, включая TCP-заголовок, должен помещаться в 65 515-байтное поле полез-

ной нагрузки IP-пакета. Во-вторых, в каждой сети есть максимальная единица

передачи (MTU, Maximum Transfer Unit), и каждый сегмент должен помещаться

в MTU. На практике размер максимальной единицы передачи составляет обыч-

но 1500 байт (что соответствует размеру поля полезной нагрузки Ethernet), и та-

ким образом определяется верхний предел размера сегмента.

Основным протоколом, используемым TCP-сущностями, является протокол

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

сегмент прибывает в пункт назначения, принимающая TCP-сущность посылает

обратно сегмент (с данными, если есть что посылать, или без данных) с номером

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

Если время ожидания подтверждения истекает, отправитель посылает сегмент

еще раз.

Хотя этот протокол кажется простым, в нем имеется несколько деталей, кото-

рые следует рассмотреть подробнее. Сегменты могут приходить в неверном по-

рядке. Так, например, возможна ситуация, в которой байты с 3072-го по 4095-й

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

с 2048-го по 3071-й еще не получены. К тому же сегменты могут задерживаться в

сети так долго, что у отправителя истечет время ожидания и он передаст их сно-

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

фрагментов, поэтому потребуется очень аккуратное администрирование для оп-

ределения номеров байтов, которые уже были приняты корректно. Тем не менее,

поскольку каждый байт в потоке единственным образом определяется по своему

сдвигу, эта задача оказывается реальной.

Протокол TCP должен уметь справляться с этими проблемами и решать их

эффективно. На оптимизацию производительности TCP-потоков было потраче-

но много сил. В следующем разделе мы обсудим несколько алгоритмов, исполь-

зуемых в различных реализациях протокола TCP.__

Протокол UDP

UDP (англ. User Datagram Protocol — протокол пользовательских датаграмм) — это транспортный протокол для передачи данных в сетях IPбез установления соединения. Он является одним из самых простых протоколов транспортного уровня модели OSI. Его IP-идентификатор — 11₁₆ (17).

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

Состав UDP-датаграммы

Первые 64 бита (8 байт) датаграммы представляют собой UDP-заголовок, остальные биты — данные сообщения:

Биты	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
0-31	Порт отправителя (Source port)																Порт получателя (Destination port)
32-63	Длина датаграммы (Length)																Контрольная сумма (Checksum)
64-...	Данные (Data)

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

[править]Максимальная длина данных

Для вычисления максимальной длины данных в UDP-сообщении при передаче в IP сетях необходимо учесть, что UDP-сообщение в свою очередь является содержимым области данных IP-сообщения. Максимальная длина IP-сообщения (с учетом заголовка) равна 65535 октетов. Потому максимальная длина UDP-сообщения (за вычетом минимального IP-заголовка) равна 65535 − 20 = 65515 октетов. Длина заголовка UDP-сообщения равна 8 октетам, следовательно, максимальная длина данных в UDP-сообщении равна 65515 − 8 = 65507 октетов. На практике нерационально использовать максимальную величину IP пакета, так как такой размер превышает MTU основных протоколов канального уровня, и следовательно требует фрагментации IP пакета, поэтому обычно используется размер, соотнесенный с MTU используемого канального протокола.

Октеты	IP-сообщение
65535	20	Минимальный IP-заголовок
	65515	Данные IP-сообщения: UDP-сообщение 8 UDP-заголовок 65507 Данные UDP-сообщения

[править]Псевдозаголовок

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

Биты	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
0-31	IP-адрес отправителя (Source address)
32-63	IP-адрес получателя (Destination address)
64-95	0	0	0	0	0	0	0	0	Протокол (Protocol)								Длина UDP-датаграммы (UDP length)

Поле «протокол» содержит в себе значение 17 (00010001 в двоичном виде, 11 — в шестнадцатеричном) — идентификатор UDP-протокола. Поле «длина UDP-датаграммы» содержит в себе длину UDP-сообщения без псевдозаголовка в октетах, то есть совпадает с одноименным полем в UDP-заголовке.

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