Протоколы транспортного уровня tcp и udp

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

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

Любое обращение к процессу в удаленной ЭВМ осуществляется при помощи адреса, состоящего из двух частей: IP адреса, идентифицирующего ЭВМ, и номера порта, идентифицирующего процесс.

Все задачи можно условно разделить на две большие группы: известные всем (wellknown) и прочие. К известным относятся задачи (или услуги), получившие повсеместное распространение. Для них существуют заранее определенные порты, закрепленные в стандартах INTERNET. Это так называемые хорошо известные номера (wellknown numbers). Выделением номеров заранее определенных портов занимается организация IANA (Internet Assigned Numbers Authority).

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

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

Определение получателя — одна из главных задач транспортных протоколов в INTERNET. В семействе TCP/IP таких протоколов два.

Протокол UDP

UDP (RFC768) является дейтаграммным протоколом, не гарантирующим доставку и не сохраняющим порядок поступления дейтаграмм.

Сообщение протокола UDP называют абонентской дейтаграммой (user datagram). Оно состоит из заголовка и блока данных. Заголовок пользовательской дейтаграммы состоит из четырех 16битовых полей (рис. 39).

Рис. 39 — Формат заголовка дейтаграммы протокола UDP

Поля «Адрес порта процесса отправителя» и «Адрес порта процесса получателя» определяют адреса портов процесса отпра-вителя и процесса получателя. Поле «Адрес порта процесса отправителя» имеет конкретное значение только в том случае, если процесс отправитель должен получить ответное сообщение, в противном случае оно заполняется нулями.

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

Поле «Контрольная сумма» содержит контрольную сумму. При ее расчете учитываются также сетевые адреса. В целом расчет контрольной суммы производится следующим образом:

1. Блок данных сообщения дополняется нулями до целого числа 16 битовых слов.

1. Поле «Контрольная сумма» заполняется нулями.

2. Перед сообщением помещается псевдозаголовок, структура которого показана на рис. 40.

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

0 7	8 15	16	23	24	31
Адрес IP отправителя
Адрес IP получателя
00000000	Код протокола (для1ЮР»17»)	Длина сообщения

Рис. 40 — Формат псевдозаголовка дейтаграммы протокола UDP

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

Расчет контрольной суммы операция необязательная. В случае, если поле «Контрольная сумма» заполнено нулями, то оно воспринимается как отказ от расчета контрольной суммы. Для случая (редкого, но возможного), когда рассчитанная контрольная сумма равна нулю, все биты поля «Контрольная сумма» устанавливаются в состояние «1».

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

Протокол TCP

В отличие от UDP протокол TCP (RFC793 и RFC761) обеспечивает полноценную транспортную службу. Транспортная служба TCP:

• обеспечивает доставку данных (при этом процесс передает протоколу данные в виде целостного файла);

• обрабатывает данные (не накладывает никаких ограничений на структуру данных);

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

• обеспечивает срочную передачу данных (даже одного байта);

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

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

Логическая характеристика протокола TCP

Блок TCP состоит из заголовка и поля данных. Заголовок блока TCP показан на рис. 41.

Рис. 41 — Формат заголовка блока TCP

Поля «Адрес порта процесса отправителя» и «Адрес порта процесса получателя» используются для определения адресов портов процесса отправителя и процесса получателя сообщения.

Поле «Номер последнего передаваемого байта в данном блоке сообщения TCP» определяет номер последнего октета в передаваемом блоке и служит для контроля Порядка следования блоков и правильного восстановления последовательности блоков получателем.

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

Поле «Длина заголовка блока» (6 битов) определяет длину заголовка блока TCP, измеренную в 32битовых словах. Длина заголовка блока может изменяться в зависимости от значений, устанавливаемых в поле «Услуги».

Поле «Зарезервировано» содержит резервные биты (4 бита) для последующего использования.

Поле «Тип сообщения» содержит служебные биты (6 битов), определяющие тип сообщения, которые расположены слева направо и означают(устанавливаются в «1»):

URG (urgent) срочное сообщение;

АСК (acknowledgment) квитанция на принятый блок данных;

PSH (push) требование отправки сообщения без ожидания заполнения буфера;

RST (reset) запрос на повторное соединение;

SYN (synchronization) синхронизация счетчиков (используется при установлении соединения);

FIN (finish) указывает, что передан последний байт.

Поле «Размер длины (в октетах) «скользящего окна», служит для декларации приемного окна (размер «кредита»).

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

Поле «Указатель окончания передачи срочных данных» используется совместно с управляющим битом URG. Число, помещаемое в это поле, указывает на конец срочных данных. Срочные данные передаются вне очереди (вне потока out of band).

Поле «Услуги» используется для предоставлена дополнительных услуг, например, таких, как оптимизация передачи путем выбора максимального размера блока (maximum segment size, MSS).

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

Процедурная характеристика протокола TCP

Процедурная характеристика протокола TCP (рис. 41) включает три фазы информационного обмена: установление соединения, передача данных и разъединение. Важной особенностью процедурной характеристики TCP является то, что на всех этапах обмена сообщениями используется только один формат блока, рассмотренный выше. Различие этапов определяется с помощью кодирования поля «Тип сообщения».

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

Механизм простого квитирования. Использование тайм-аута. В процессе доставки данные могут быть утеряны или искажены, поэтому получатель, если он принял блок, проверяет его корректность путем расчета контрольной суммы. Если последняя правильна (данные получены без искажений), то адресат отправляет квитанцию подтверждения приема; если контрольная сумма не сходится, то квитанция не высылается.

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

Механизм оптимизации длительности таймаута

В INTERNET (ввиду глобальности сети) нельзя заранее принять конкретное усредненное значение длительности тайм-аута. Если тайм-аут настроен на задержку, оптимальную для локальной сети, то скорее всего он будет слишком коротким для информационного обмена через глобальные сети. Большое же время ожидания снижает эффективность использования пропускной способности сети, поскольку отправитель может слишком долго ждать подтверждений.

В основе механизма оптимизации длительности тайм-аута лежит измерение протоколом TCP (после отправки блока) времени до прихода квитанции (RTT, Round Trip Time время двойного прохода). Результаты измерений усредняются с более ранними значениями RTT.

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

Чтобы избежать этого, используется следующий прием: отправителю разрешается послать некоторое количество, например, N единиц информации (блоков) до получения квитанции на первый блок. После получения квитанции на первый блок разрешается отправить блок N+1 и т.д. Такая схема передачи данных называется методом скользящего окна, а число блоков N, передаваемых в сеть до получения квитанции на первый блок, размером окна, или просто окном. Протокол TCP реализует оконное управление квитированием на уровне байтов. На основе метода скользящего окна работает механизм группового квитирования, заключающийся в следующем. При установлении соединения счетчики последовательностей блоков у отправителя и получателя устанавливаются в одинаковые состояния (синхронизируются). Получатель, приняв подряд несколько следующих блоков, в ответном сообщении квитанции передает отправителю номер следующего байта данных, который он намерен принять (номер последнего байта в последнем корректно принятом блоке плюс единица).

Размер TCP-окна равен произведению полосы пропускания канала и RTT.

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

Защита от перегрузок

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

Этот механизм используется протоколом TCP для решения двух совершенно разнородных задач защиты сети от перегрузок.

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

Вторая задача — защита от перегрузки буфера самого протокола TCP, принимающего данные. Получатель, квитируя некоторую последовательность блоков, сообщает отправителю, какое количество байтов информации он готов бесконфликтно принять. Тем самым обеспечивается защита приемного устройства от перегрузки (особенно это важно в случаях, когда производительность источника и приемника информации существенно различаются). Этот метод называется декларацией приемного окна (window advertisement). Если отправитель «не справляется» с входящим потоком, то он может декларировать окно нулевого размера, отказываясь от приема информации.