Транспортный уровень. Протоколы TCP и UDP

      На транспортном уровне используется два основных транспортных протокола UDP — User Datagram Protocol, RFC 768 (протокол пользовательских дейтаграмм) и TCP — Transmission Control Protocol, RFC 793 (протокол управления передачей).

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

Протокол UDP

      Данный протокол иногда называют протоколом ненадёжной доставки. Этот протокол предоставляет прикладным процессам транспортные услуги, которые немногим отличаются от услуг протокола IP (сетевого уровня).

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

      Формат UDP-дейтаграммы имеет следующий вид:

      Видно, что формат протокола UDP размещается в поле данных IP-пакета (или после заголовка IP-пакета) и содержит следующие поля:

      Поле «Порт источника» (Source Port) указывает порт процесса источника, куда может быть адресован ответ на данное сообщение.

      Поле «Порт получателя» (Destination Port) идентифицирует принимающий процесс.

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

      В поле «Длина» (Length) указывается размер данной дейтаграммы с учётом длины заголовка в байтах.

      Поле «Контрольная сумма» (Checksum) обеспечивает контроль правильности данных и заголовка. Суммируются все контролируемые 16-битные слова (с циклическим переносом из старшего разряда в младший). Инвертированное значение результата записывается в поле контрольной суммы. Если UDP-дейтаграмма содержит нечетное число байтов, то недостающий последний байт в таких случаях считается нулевым. Этот байт не передается в области данных.

      При подсчете контрольной суммы протокол UDP учитывает 12-байтовый псевдозаголовок (pseudo header). Псевдозаголовок включает в себя: IP-адрес источника, IP-адрес приемника, протокол (код 17) и длину UDP-дейтаграммы.

      Если источник проставил контрольную сумму, а адресат при ее проверке обнаружил ошибку, то UDP-дейтаграмма "молчаливо отбрасывается" - не генерируется никакого сообщения об ошибке.

      UDP-данные могут отсутствовать.

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

Номера портов, используемые в протоколе UDP
Номер порта Идентификатор в стандарте Идентификатор в UNIX Описание
7 ECHO echo Эхо
15 - netstat Программа выдачи состояния сети
37 TIME time Текущее время
42 NAMESERVER name Сервер имен хостов
43 NICNAME whois Информация о пользователе
53 DOMAIN nameserver Сервер доменных имен (DNS)
67 BOOTPS bootps Сервер BOOTP или DHCP
68 BOOTPC bootpc Клиент BOOTP или DHCP
69 TFTP tftp Простейший протокол передачи файлов (TFTP)
88 KERBEROS kerberos Служба аутентификации Kerberos
123 NTP ntp Протокол синхронизации сетевого времени (NTP)
161 - snmp Простой протокол сетевого управления (SNMP)
162 - snmp-trap Прерывания протокола SNMP
512 - biff Сервер UNIX comsat

      Более подробную информацию о протоколе UDP можно найти в RFC-768.

Пример вычисления контрольной суммы (UDP checksum) UDP-дейтаграммы



Протокол TCP

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

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

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

Часто используемые стандартные номера портов протокола TCP
Номер порта Идентификатор в Internet Идентификатор в UNIX Описание
7 ECHO echo Эхо
20 FTP-DATA ftp-data Данные протокола передачи файлов (FTP)
21 FTP ftp Протокол передачи файлов (FTP)
23 TELNET telnet Подключение к терминалу
25 SMTP smtp Простой протокол передачи электронной почты (SMTP)
37 TIME time Текущее время
43 NICNAME whois Информация о пользователе
53 DOMAIN nameserver Сервер доменных имен (DNS)
67 BOOTPS bootps Сервер BOOTP или DHCP
80 WWW www Сервер World Wide Web
88 KERBEROS kerberos Служба аутентификации Kerberos
101 HOSTNAME hostname Сервер NIC имен хостов
103 X400 x400 Почтовая служба X.400
104 X400-SND x400-snd Отправитель почты X.400
113 AUTH auth Служба аутентификации
117 UUCP-PATH uucp-path Служба путей протокола UUCP
119 NNTP nntp Протокол передачи сетевых новостей Usenet (NNTP)
123 NTP ntp Протокол синхронизации сетевого времени (NTP)
161 SNMP snmp Простой протокол сетевого управления (SNMP)

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

      Протокол ТСР требует, чтобы все отправленные сегменты данных были подтверждены с приёмного конца, т.е. используется алгоритм обратной связи. Для повышения эффективности работы используются механизм скользящего окна, тайм-ауты и повторные передачи для обеспечения надёжной доставки. Каждая из принимающих сторон может управлять потоком данных от передающего модуля, чем предотвращается возможность переполнения буферов приёмников. Пользователь при установлении соединения может устанавливать категорию срочности и безопасности. Эти признаки учитываются не только при работе с TCP-сегментами, но и дублируются в поле «Тип сервиса» IP-пакета.

      Формат ТСР-сегмента включает заголовок и данные и имеет следующий вид:

      Поля «Порт источника» и «Порт получателя» указывают номера портов в TCP-модулях (идентифицируют взаимодействующие приложения). Порт источника идентифицирует порт, с которого отправлен пакет. Порт получателя (порт назначения) идентифицирует порт, на который отправлен пакет.

      В поле «Последовательный номер (Позиционный номер)» содержится номер, который указывает в потоке данных от источника до конечного получателя место первого байта данных, содержащихся в этом сегменте.
      В начальном сегменте, посылаемом при установлении соединения, присутствует флаг SYN, а в поле «Позиционный номер» содержится начальный позиционный номер ISN (initial sequence number), выбранный данным хостом для этого нового соединения. Первому байту данных, переданному хостом по новому соединению, будет присвоен позиционный номер, равный ISN+1.
      Если SYN не установлен, первый байт данных — номер последовательности.

      Поле «Номер подтверждения (Квитанция)» при установленном флаге АСК содержит значение последовательного номера, который отправитель данного сегмента собирается принимать, то есть помечает этот сегмент как подтверждение получения. (Этот номер всегда на единицу больше номера последнего успешно принятого байта). После установления виртуального соединения это поле обязательно заполняется. С помощью этого поля отмечается байт, с которого начнется окно приёма данных от источника (механизм скользящего окна).
      TCP предоставляет приложениям сервис полнодуплексной передачи. Это означает, что данные могут передаваться в обоих направлениях независимыми потоками. В процессе двусторонней передачи каждая из сторон должна вести учет позиционных номеров передаваемых и принимаемых ею байтов.

      Поле «Смещение данных (Размер заголовка)» определяет число 32-разрядных слов в заголовке TCP-сегмента. Минимальный размер составляет 5 слов, а максимальный — 15, то есть 20 и 60 байт соответственно. Смещение считается от начала заголовка TCP.

      В поле «Резерв» все разряды устанавливаются равными 0.

      Содержимое «Поля управляющих флагов»: URG (urgency) - указатель срочности; АСК (acknowledgement) - подтверждение; PSH (push) - указатель немедленной выдачи на верхний уровень; RST (reset) - немедленный сброс соединения; SYN (synchronization) - синхронизация последовательных номеров; FIN (final) - завершение соединения.

      Поле «Окно» содержит число байт, равное длине окна, т.е. период времени в байтах, когда отправитель ожидает информацию от приёмника.

      Поле «Проверочная сумма». Проверочная сумма подсчитывается для всего ТСР сегмента, при этом определяется 16-битное дополнение суммы всех 16-битных слов в заголовке и в поле данных. Если сегмент содержит нечетное количество байтов, то он будет дополнен нулями справа до образования 16-битного слова. Этот выравнивающий байт не передается с сегментом по сети, так как может быть "восстановлен" получателем.
      Проверочная сумма учитывает также 96-битный псевдозаголовок, который ставится перед заголовком протокола ТСР. Подзаголовок включает следующие поля из заголовка протокола IP: IP-адреса отправителя и получателя, протокол (код 6) и длину сегмента.
      С помощью добавления псевдозаголовка протокол ТСР защищает самого себя от ошибочной доставки протоколов IP. Так, если протокол IP доставляет сегмент, не предназначенный данному работающему приложению, то модуль протокола ТСР на принимающей стороне обнаружит некорректность доставки.

      Поле «Указатель срочности (Указатель границы срочных данных)» указывает последовательный номер байта, которым заканчиваются срочные данные. Если установлен флаг URG и это поле равно 0, то весь сегмент считается срочным.

      Поле «Модификаторы (Опции)» указывает на дополнительные услуги и может иметь переменную длину, кратную байту.

      Поле «Заполнитель» имеет переменную длину и дополняет заголовок до целого числа 32-разрядных слов. Поле заполняется нулями.

      Рассмотрим типовой диалог между двумя объектами прикладного уровня с использованием протокола ТСР.

N(S) - номер байта, с которого начнёт передавать передатчик (ПРД), например, 55;

N(R) - номер байта, с которого будет передавать приёмник (ПРМ), например, 202.

      Для открытия виртуального соединения посылается флаг SYN в сегменте, с которого начнется передача (N(S)=55). Приёмник отвечает сегменту, в котором флаг АСК установлен в 1 и указывает номер байта, с которого он начнёт передавать (N(R)=202). В заголовке этого же сегмента в поле «Номер подтверждения» приёмник указывает, что он ожидает от передатчика байт с номером 56. Здесь же передаётся флаг синхронизации SYN. Передатчик (модуль А), получив этот сегмент с подтверждением о готовности приёмника работать, также отвечает сегментом с подтверждением АСК, и в поле «Номер подтверждения» передатчик указывает, что он ожидает от приёмника байт с номером 203.

      После этого виртуальное соединение установлено, о чем модули ТСР извещают свои прикладные процессы.

Взаимодействие узлов в режиме «прикладной уровень – ТСР»

            Передатчик по созданному виртуальному соединению передаёт данные (30 байт), начиная с байта под номером 56. Приёмник ожидает байт данных именно с этим номером, поэтому после приёма данных приёмник выдаёт сегмент с флагом подтверждения АСК и номером следующего ожидаемого байта N(S)=56+30=86, кроме того, приёмник отсылает в сторону передатчика 100 байт данных, начиная с номера 203, что и ожидает передатчик. Получив 100 байт от приёмника, передатчик выдаёт сегмент с флагом АСК и номером следующего ожидаемого байта N(R)=203+100=303.

      В фазе "передача данных" работают механизмы обеспечения надёжной доставки.

      Различают три варианта обратной связи:

  1. РОС ОЖ. Это наиболее простой вариант.

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

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

          На каждый передающийся сегмент ожидается получение квитанции (ACK=1 и номер следующего запрашиваемого октета). Включается таймер ожидания. Если квитанция не приходит до истечения таймера, то осуществляется повторная передача.

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

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

          Существует 2 механиза определения времени двойного пробега:

    1. Тестирование сети и оценка в режиме «пингования» временной задержки на каждом сегменте. Затем осуществляется набор статистики и её обработка. Для определения времени ожидания квитанции к среднему времени задержки добавляются 4 среднеквадратических отклонения времени задержки от его математического ожидания. Именно за это время и должна придти квитанция. Если квитанция приходит после истечения таймера, передающая сторона считает пакет утерянным.
    2. Динамический способ определения таймера. Время двойного пробега определяется в процессе передачи. Первоначально передаются сегменты по одному в режиме РОС ОЖ и определяется время пробега. Время таймера увеличивается до тех пор, пока квитанции не станут не успевать приходить.

          К плюсам РОС ОЖ можно отнести простоту реализации. К минусам - непроизводительное использование пропускной способности и, следовательно, - низкую эффективную скорость ПД.

  2. Оконный режим переспроса. Для данного режима характерно некоторое число сегментов, передаваемых непрерывно без ожидания квитанции. Оконный режим использует принцип конвеерной передачи. Таймер включается после передачи последнего сегмента.

          Октеты 1 и 2 успешно доставлены получателю; октеты 3-6 посланы в сеть, но подтверждение об их доставке еще не получено; октеты 7-9 еще не отправлены, но могут быть отправлены без всяких задержек; октеты с номерами 10 и выше не могут быть посланы в сеть до тех пор, пока не попадут внутрь окна.

          Возможны 2 режима окна: фиксированное и скользящее.

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

    Движущееся окно, внутрь которого помещено 8 пакетов (а); при получении подтверждения о приеме пакета 1 окно сдвигается на один пакет вправо, и в сеть отправляется 9-й пакет (б). Если для какого-либо пакета, попавшего в окно, не получен сигнал подтверждения, то выполняется повторная передача этого пакета

      Режим окна определяется во вспомогательных параметрах ТСР заголовка.

 

      Для плавного завершения соединения передатчик отправляет сегмент с флагом FIN и номером байта N(S)=86. Приёмник выдаёт сегмент с флагом подтверждения АСК и номером ожидаемого байта N(S)=87, но у приёмника ещё остались данные для передачи, которые он и отправляет (150 байт), начиная с байта под номером N(R)=303. Передатчик отвечает сегментом с флагом подтверждения АСК и номером ожидаемого байта 454 (303+150+1).

      На этом виртуальное соединение прикладного уровня разрывается, но остается ещё виртуальное соединение транспортного уровня. Для его разрушения приёмник посылает сегмент с флагом FIN и номером ожидаемого байта N(R)=454. Передатчик отвечает подтверждением, на что приёмник также отвечает сегментом подтверждения АСК. На этом виртуальное соединение на транспортном уровне разрушается.

      Более подробное описание протокола TCP можно найти в RFC-793, RFC-1180.

Пример вычисления контрольной суммы (TCP checksum) TCP-сегмента



      Контрольные вопросы:

      1. Опишите услуги протокола UDP.

      2. Назначение транспортного протокола ТСР.

      3. Опишите назначение полей формата TCP-сегмента.

      4. Объясните взаимодействие объектов прикладного уровня с помощью ТСР.