Семейство протоколов TCP/IP. Протоколы транспортного уровня Internet

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

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

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

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

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

•  UDP User Datagram Protocol ;

•  TCP Transmission Control Protocol .

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

•  Синхронизация процесса;

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

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

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

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

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

Таблица 2.10.1.

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

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

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

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

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

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

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

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

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

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

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

•  Неструктурированный поток;

•  Обмен в режиме полного дуплекса.

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

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

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

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

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

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

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

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

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

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

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

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

•  Управление скоростью передачи данных;

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

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

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

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

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

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

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

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

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

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

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

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