Протоколы транспортного уровня Internet

Назначение и основные разновидности протоколов транспортного уровня

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

Сегментирующие протоколы  транспортного  уровня, разбивают исходное сообщение на блоки данных транспортного уровня — сегменты.

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

В качестве протоколов транспортного уровня в сети Internet могут быть использованы два протокола:

• UDP User Datagram Protocol
• TCP Transmission Control Protocol

Идентификация процессов на транспортном уровне

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

• Синхронизация процесса
• Буферизация поступающих данных

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

Перечень номеров назначенных портов приведен в документе IETF STD 2

Транспортный протокол UDP

Описание принципов построения протокола UDP  приведено в RFC 768. Для передачи сообщений UDP используются пакеты IP. Сообщения UDP в данном случае размещаются в поле данных переносящего их пакета.

Формат сообщения UDP

Дейтаграммы UDP имеют переменную длину и состоят из заголовка сообщения UDP header и собственно сообщения UDP Data. На рисунке приведена структура заголовка сообщения UDP.

Поле UDP DESTINATION PORT

В этом поле должен быть размещен номер порта процесса, которому предназначено  данное сообщение.

Поле UDP SOURCE PORT

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

Поле UDP MRSSAGE LENGTH

В  поле UDP MRSSAGE LENGTH размещается выраженная в байтах длина сообщения UDP. Сообщение минимальной длины – 8 байт состоит из одного заголовка.

UDP SOURCE PORT	UDP DESTINATION PORT
UDP MRSSAGE LENGTH	UDP CHECKSUM
DATA

Поле UDP CHECKSUM

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

Использование  протокола UDP

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

Транспортный протокол TCP

Протокол TCP используется для обеспечения надежного информационного обмена на транспортном уровне в сетях Internet. Первое описание протокола приведено в RFC 793.

Особенности реализации информационного обмена TCP

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

Надежный информационный обмен предполагает следующие возможности:

• Потоковый обмен
• Использование виртуальных соединений
• Буферизированная передача данных
• Неструктурированный поток
• Обмен в режиме полного дуплекса

Потоковый обмен

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

Использование виртуальных соединений

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

 Буферизированная передача данных

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

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

Методы обеспечения надежного  информационного взаимодействия в TCP.

Для обеспечения гарантированной доставки сообщений протокол TCP использует аппарат  позитивного квитирования с повторной передачей (positive acknowledgement with retransmission). Обычно при использовании данной схемы получатель информации посылает специальный сигнал ACK в подтверждение ее получения. Дальнейшее выполнение информационного обмена может быть выполнено только в том случае, если передающая сторона получит это подтверждение.

Простая процедура квитирования

Передающая сторона приостанавливает передачу очередного сегмента до получения подтверждения о приеме предыдущего сегмента. Интервал ожидания устанавливается равным значению задержки повторной передачи – retransmit timer. Если в течение этого интервала времени не будет получено подтверждение о приеме переданного сегмента, передача данного сегмента выполняется повторно.

Квитирование с использованием скользящего окна

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

Максимальное число сегментов, которые передающая сторона может передать до получения  подтверждения приема первого из них, называется ОКНОМ

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

Процедуры управления потоком TCP

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

Описанный в предыдущем параграфе метод скользящего окна используется протоколом TCP для обеспечения выполнения двух функций:

• Управление скоростью  передачи данных
• Обеспечение надежной доставки передаваемых данных

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

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

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

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

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

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

Использование скользящего окна для управления информационным потоком делает ненужным использование дополнительных механизмов для управления переполнением.

Особенности практической реализации протокола TCP

Синдром неоптимального окна

При использовании протокола TCP на линиях, пропускная способность которых была различной в различных направлениях, пользователи могли наблюдать возникновение ситуации, которая получила название синдром неоптимального окна – silly window syndrome — SWS. Данная ситуация характеризуется тем, что одно из взаимодействующих приложений «А» может передавать  данные с существенно большей скоростью, чем другое — «В». Если изначально сторона «В» установила размер своего окна равным величине своего буфера, вполне может получиться так, что сторона «А» заполнит весь буфер до того, как получит первое уведомление об изменении размера окна.  Исчерпав лимит байтов, установленный для передачи, сторона «А» перейдет в режим ожидания подтверждения. Когда сторона «В» начнет обработку поступивших данных, она сможет освободить некоторую часть буфера и передаст уведомление о соответствующем изменении размера приемного окна. Сторона «А» быстро заполнит освободившееся место в буфере и опять перейдет в режим ожидания.   Наиболее неприятным следствием возникновения такой ситуации  будет то, что канал передачи данных в направлении от «А» к «В» будет использоваться крайне неэффективно, поскольку сегменты TCP будут использоваться для переноса небольших объемов данных (до 1 байта). Соотношение долей полезной нагрузки и служебной информации в данном случае будет крайне неудачным. Для того, чтобы избежать возникновения SWS в практической реализации протокола TCP используются несколько различных способов.

Способы предотвращение появления SWS на приемной стороне

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

Другим способом, который также может быть использован на приемной стороне для предотвращения возникновения эффекта SWS, является процедура задержки подтверждений. Этот метод  довольно прост для реализации и в тоже время достаточно эффективен. Действительно, задержка ответа на некоторое постоянное время, позволит избежать SWS и одновременно повысить эффективность использования канала передачи данных – поскольку на все сегменты, которые поступят на приемник в течение интервала задержки, будет сформировано только одно подтверждение. Использование фиксированной задержки подтверждения рекомендовано стандартом для предотвращения SWS. Следует, однако, иметь в виду, что выбор слишком большого времени задержки может привести к повторной передаче сегмента.

Способы предотвращение появления SWS на передающей стороне

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

Источник : lectures.net.ru/tcpip/10/