Операционная система UNIX - Андрей Робачевский

User Datagram Protocol (UDP)

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

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

Рис. 6.9. Заголовок UDP

Первые два поля, каждое из которых занимает по 2 октета, адресуют соответственно порты источника и получателя. Указание порта источника является необязательным и это поле может быть заполнено нулями. Поле Length содержит длину датаграммы, которая не может быть меньше 8 октетов. Поле Checksum используется для хранения контрольной суммы и используется только если протокол верхнего уровня требует этого. Если контрольная сумма не используется, это поле заполняется нулями. В противном случае она вычисляется по псевдозаголовку, содержащему IP-адреса источника и получателя датаграммы и поле Protocol из IP-заголовка. Вид псевдозаголовка представлен на рис. 6.10. То, что вычисление контрольной суммы включает IP-адреса, гарантирует, что полученная датаграмма доставлена требуемому адресату. Заметим, что для протокола UDP значение поля Protocol равно 17.

Рис. 6.10. Псевдозаголовок UDP

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

□ Протокол взаимодействия с сервером доменных имен DNS, порт 53.

□ Протокол синхронизации времени Network Time Protocol, порт 123.

□ Протокол удаленной загрузки BOOTP, порты 67 и 68 для клиента и сервера соответственно.

□ Протокол удаленного копирования Trivial FTP (TFTP), порт 69.

□ Удаленный вызов процедур RPC, порт 111.

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

Transmission Control Protocol (TCP)

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

Протокол TCP характеризуется следующими возможностями, делающими его привлекательным для приложений:

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

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

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

□ Доставка экстренных данных.

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

TCP-канал представляет собой двунаправленный поток данных между соответствующими объектами обмена — источником и получателем. Данные могут передаваться в виде пакетов различной длины, называемых сегментами. Каждый TCP-сегмент предваряется заголовком, за которым следуют данные, инкапсулирующие протоколы уровня приложения. Вид заголовка TCP-сегмента представлен на рис. 6.11.

Рис. 6.11. Формат TCP-сегмента

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

И порядковый номер, и номер подтверждения занимают по 32 бита в заголовке TCP-сегмента, таким образом, их максимальное значение составляет (2³² - 1), за которым следует 0. При установлении связи стороны договариваются о начальных значениях порядковых номеров (Initial Sequence Number, ISN) в каждом из направлений. Впоследствии первый октет переданных данных будет иметь номер (ISN+1).

Управление потоком данных осуществляется с помощью метода скользящего окна (sliding window). Каждый TCP-заголовок содержит также поле Window, которое указывает на количество данных, которое адресат готов принять, начиная с октета, указанного в поле Acknowledgement Number.

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

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

Значение этого поля измеряется в 32-битных словах. Таким образом, при минимальном размере заголовка поле Offset будет равно 5.

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

URG Указывает, что сегмент содержит экстренные данные, и поле Urgent pointer заголовка определяет их положение в сегменте. ACK Указывает, что заголовок содержит подтверждение полученных данных В поле Acknowledgement Number. PSH Указывает, что данные должны быть переданы немедленно, не ожидая заполнения сегмента максимального размера. RST Указывает на необходимость уничтожения канала. SYN Указывает, что сегмент представляет собой управляющее сообщение, являющееся частью "тройного рукопожатия" для синхронизации порядковых номеров при создании канала. FIN Указывает, что сторона прекращает передачу данных и желает закрыть виртуальный канал.

Поле контрольной суммы Checksum используется для защиты от ошибок. Контрольная сумма вычисляется на основании 12-октетного псевдозаголовка, содержащего, в частности IP-адреса источника и получателя, а также номер протокола. Цель включения в контрольную сумму части заголовка IP та же, что и для протокола UDP — дополнительно защитить данные от получения не тем адресатом.

Поле Urgent Pointer позволяет указать расположение экстренных данных внутри сегмента. Это поле используется при установленном флаге URG и содержит порядковый номер октета, следующего за экстренными данными.

В конце заголовка располагается поле Options переменной длины, которое может содержать различные опции, например, максимальный размер сегмента (MSS). Это поле дополняется нулями (Padding) для того, чтобы заголовок всегда заканчивался на границе 32 бит.

Состояния TCP-сеанса