Транспортные протоколы Интернет

Транспортными здесь называются протоколы Интернет, чьи пакеты вкладываются в IP-дейтаграммы. В этот перечень вошли UDP, все модификации TCP.

2.1. Протокол UDP

Протокол UDP (User Datagram Protocol, RFC-768) является одним из основных и старейших, расположенных непосредственно над IP. Он предоставляет прикладным процессам транспортные услуги, немногим отличающиеся от услуг протокола IP. Протокол UDP обеспечивает доставку дейтаграмм, но не требует подтверждения их получения. Он также не требует соединения с удаленным модулем UDP ("бессвязный" протокол). К заголовку IP-пакета UDP добавляет поля порт отправителя и порт получателя, которые обеспечивают мультиплексирование информации между различными прикладными процессами, а также поля длина UDP-дейтаграммы и контрольная сумма, позволяющие поддерживать целостность данных. Таким образом, если на уровне IP для определения места доставки пакета используется адрес, то на уровне UDP - номер порта.

Примерами сетевых приложений, применяющих UDP, являются NFS (Network File System), TFTP (Trivial File Transfer protocol, RFC-1350), RPC (Remote Procedure Call, RFC-1057) и SNMP (Simple Network Management Protocol, RFC-1157). Малые накладные расходы, связанные с форматом UDP, а также отсутствие необходимости подтверждения получения пакета делают этот протокол наиболее популярным при реализации приложений мультимедиа, но главное его место работы - локальные сети и мультимедиа.

Хотя протокол UDP не гарантирует доставки, по умолчанию предполагается, что вероятность потери пакета достаточно мала.

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

Например, сервер SNMP всегда ожидает сообщения, адресованного в порт 161. Если клиент SNMP желает получить услугу, он посылает запрос в UDP-порт 161 на машину, где работает сервер. На каждой машине может быть только один агент SNMP, т.к. существует только один порт 161. Данный номер порта является общеизвестным, т.е. фиксированным номером, официально выделенным в сети Internet для услуг SNMP.

Таблицы для стандартных значений номеров портов можно найти по адресу: http://book.itep.ru/4/44/udp_442.htm.

Данные, отправляемые прикладным процессом через модуль UDP, достигают места назначения как единое целое. Например, если процесс--отправитель производит 5 записей в порт, то процесс--получатель должен будет сделать 5 чтений. Размер каждого записанного сообщения будет совпадать с размером каждого прочитанного. Протокол UDP сохраняет границы сообщений, определяемые прикладным процессом. Он никогда не объединяет несколько сообщений в одно и не делит одно сообщение на части. Формат UDP-сообщений представлен ниже на рис. 2.1:

Рис. 2.1. Формат UDP-дейтаграмм

Длина сообщения равна числу байт в UDP-дейтаграмме, включая заголовок. Поле UDP контрольная сумма содержит код, полученный в результате контрольного суммирования UDP-заголовка и поля данные. Нетрудно видеть, что этот протокол использует заголовок минимального размера (8 байт). Номера портов от 0 до 1024 стандартизованы. Они предназначены для серверов и использовать их в прикладных задачах не рекомендуется. С номерами портов >1024 могут работать клиенты, но и здесь нужно проявлять осторожность, так как некоторые номера портов заняты стандартными сервисами, поэтому, прежде чем использовать какой--то порт в своей программе, следует заглянуть в соответствующую базу данных IANA (http://www.iana.org/).

Модуль IP передает поступающий IP-пакет модулю UDP, если в заголовке этого пакета указан код протокола UDP. Когда модуль UDP получает дейтаграмму от модуля IP, он проверяет контрольную сумму, содержащуюся в ее заголовке. Если контрольная сумма равна нулю, это означает, что отправитель ее не подсчитал. ICMP, IGMP, UDP и TCP протоколы имеют один и тот же алгоритм вычисления контрольной суммы (RFC-1071; по модулю 1). Но вычисление контрольной суммы для UDP имеет некоторые особенности. Во--первых, длина UDP-дейтаграммы может содержать нечетное число байт, в этом случае к ней добавляется нулевой байт, который служит лишь для унификации алгоритма и никуда не пересылается. Во--вторых, при расчете контрольной суммы для UDP и TCP добавляются 12-байтные псевдозаголовки, содержащие IP-адреса отправителя и получателя, код протокола и длину дейтаграммы, которые берутся из IP-дейтаграммы (см. рис. 2.2). Как и в случае IP-дейтаграммы, если вычисленная контрольная сумма равна нулю, в соответствующее поле будет записан код 65535.

Рис. 2.2. Псевдозаголовок, используемый при расчете контрольной суммы

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

Так как максимальная длина IP-дейтаграммы равна 65535 байтам, максимальная протяженность информационного поля UDP-дейтаграммы составляет 65507 байт. На практике большинство систем работает с UDP-дейтаграммами с длиной 8192 байта или менее (если, например, мы имеем дело с Ethernet, то менее 1500 байт). Детальное описание форматов, полей пакетов и пр. читатель может найти в RFC-768.