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

2. Функции транспортного уровня

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

Порты нумеруются положительными целыми 16-битовыми числами. Разные протоколы транспортного уровня нумерую свои порты независимо, то есть, например, порт 20 протокола TCP и порт 20 протокола UDP совершенно не связаны друг с другом.

Некоторые номера портов заданы стандартами. Эти номера выделяются организацией IANA (англ. Internet Assigned Numbers Authority). В настоящее время под стандартные порты отведен диапазон от 0 до 1023 (ранее -- до 255).Остальные порты могут свободно использоваться прикладными процессами. Порты в диапазоне от 1024 до 5000 называются временными (англ. ephemeral). Назначение этих портов не стандартизовано, но IANA поддерживает информацию об их использовании.

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

Как правило, все протоколы, начиная с транспортного уровня и выше, реализуются программными средствами конечных узлов сети - компонентами их сетевых операционных систем. В качестве примера транспортных протоколов можно привести протоколы TCP и UDP стека TCP/IP и протокол SPX стека Novell.

В семействе протоколов TCP/IP используются два существенно различных транспортных протокола:

1. TCP (Transmission Control Protocol - протокол управления передачей данных)

2. UDP (User Datagram Protocol - протокол дейтаграмм пользователя).

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

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

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

Протокол UDP

Официальная спецификация UDP приведена в RFC 768 [Postel 1980].

Сообщение протокола UDP называется пользовательской дейтаграммой (англ. User datagram).

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

· Поле source port - номер порта процесса-отправителя.

· Поле destination port - номер порта процесса-получателя.

· Поле message length - длина UDP-пакета в байтах.

· Поле checksum - контрольная сумма UDP-пакета.

Не все поля UDP-пакета обязательно должны быть заполнены. Например, если посылаемая дейтаграмма не предполагает ответа, то на месте адреса отправителя могут помещаться нули.

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

UDP является ненадежным протоколом: он отправляет дейтаграммы, которые приложение пишет в IP уровень, однако не существует гарантии того, что они достигнут конечного пункта назначения.

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

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

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

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

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

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

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

Рис. 1. Инкапсуляция UDP дейтаграммы.

Номер протокола UDP (в заголовке IP) -17.

Формат заголовка UDP дейтаграммы приведен на рисунке ниже.

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

Поле длины UDP содержит длину в байтах UDP заголовка и UDP данных. Минимальное значение для этого поля составляет 8 байт. Допускается отправка UDP дейтаграммы с нулевой длиной данных.

Область использования UDP:

· UDP подходит для процессов, которые требует простой связи типа "запрос - ответ", использующих короткие сообщения.

· UDP подходит для процессов с внутренним механизмом управления потоком и контролем ошибок. Например, тривиальный протокол передачи файлов (Trivial File Transfer Protocol -- TFTP) включает в себя механизмы управления потоком и контроля ошибок. Он может просто использовать UDP.

· UDP подходит как транспортный протокол для многоадресного и широковещательного распространения. Многоадресные и широковещательные возможности вставлены в програмное обеспечение UDP, но их нет в программном обеспечении TCP

· UDP может использоваться в случае. Когда скорость отправляемого потока данных задана источником и практически не меняется (управление потоком не требуется).

Протокол TCP

Протокол TCP (Transmission Control Protocol) обеспечивает сквозную доставку данных между прикладными процессами, запущенными на узлах, взаимодействующих по сети. Стандартное описание TCP содержится в RFC-793. Позднее появились исправления и добавления - RFC 1122, расширения - RFC 1323 - TCP Extensions for High Performance, RFC 2883-SACK, RFC-2923-MTU.

TCP - надежный байт-ориентированный (byte-stream) протокол с установлением соединения. TCP находится на транспортном уровне стека TCP/IP, между протоколом IP и собственно приложением. Протокол IP занимается пересылкой дейтаграмм по сети, никак не гарантируя доставку, целостность, порядок прибытия информации и готовность получателя к приему данных; все эти задачи возложены на протокол TCP.

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

Единицей данных протокола TCP является сегмент. Информация, поступающая к протоколу TCP в рамках логического соединения от протоколов более высокого уровня, рассматривается протоколом TCP как неструктурированный поток байт. Поступающие данные буферизуются средствами TCP. Для передачи на сетевой уровень из буфера "вырезается" некоторая непрерывная часть данных, которая и называется сегментом. Сегменты состоят из заголовка и блока данных. Заголовок сегмента имеет следующие поля:

· Порт источника (SOURS PORT) занимает 2 байта, идентифицирует процесс-отправитель;

· Порт назначения (DESTINATION PORT) занимает 2 байта, идентифицирует процесс-получатель;

· Последовательный номер (SEQUENCE NUMBER) занимает 4 байта, указывает номер байта, который определяет смещение сегмента относительно потока отправляемых данных;

· Подтвержденный номер (ACKNOWLEDGEMENT NUMBER) занимает 4 байта, содержит максимальный номер байта в полученном сегменте, увеличенный на единицу; именно это значение используется в качестве квитанции;

· Длина заголовка (HLEN) занимает 4 бита, указывает длину заголовка сегмента TCP, измеренную в 32-битовых словах. Длина заголовка не фиксирована и может изменяться в зависимости от значений, устанавливаемых в поле Опции;

· Резерв (RESERVED) занимает 6 битов, поле зарезервировано для последующего использования;

· Кодовые биты (CODE BITS) занимают 6 битов, содержат служебную информацию о типе данного сегмента, задаваемую установкой в единицу соответствующих бит этого поля:

o URG - срочное сообщение;

o ACK - квитанция на принятый сегмент;

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

o RST - запрос на восстановление соединения;

o SYN - сообщение, используемое для синхронизации счетчиков переданных данных при установлении соединения;

o FIN - признак достижения передающей стороной последнего байта в потоке передаваемых данных.

· Окно (WINDOW) занимает 2 байта, содержит объявляемое значение размера окна в байтах;

· Контрольная сумма (CHECKSUM) занимает 2 байта, рассчитывается по сегменту;

· Указатель срочности (URGENT POINTER) занимает 2 байта, используется совместно с кодовым битом URG, указывает на конец данных, которые необходимо срочно принять, несмотря на переполнение буфера;

· Опции (OPTIONS) - это поле имеет переменную длину и может вообще отсутствовать, максимальная величина поля 3 байта; используется для решения вспомогательных задач, например, при выборе максимального размера сегмента;

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

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

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

Формат заголовка TCP сегмента с некоторыми пояснениями приведен на рисунке 3

Рис. 3. Формат заголовка TCP сегмента.

Номер последовательности - Sequence Number (SN) - порядковый номер первого октета в поле данных сегмента среди всех октетов потока данных для текущего соединения, то есть если в сегменте пересылаются октеты с 2001-го по 3000-й, то SN=2001. Если в заголовке сегмента установлен бит SYN (фаза установления соединения), то в поле SN записывается начальный номер (ISN), например, 0. Номер первого октета данных, посылаемых после завершения фазы установления соединения, равен ISN+1.

Номер подтверждения - Acknowledgment Number (ACK) - если установлен бит ACK, то это поле содержит порядковый номер октета, который отправитель данного сегмента желает получить. Это означает, что все предыдущие октеты (с номерами от ISN+1 до ACK-1 включительно) были успешно получены.

TCP флаги

URG - поле указателя срочности (Urgent Pointer) задействовано;

ACK - поле номера подтверждения (Acknowledgment Number) задействовано;

PSH - осуществить “проталкивание” - если модуль TCP получает сегмент с установленным флагом PSH, то он немедленно передает все данные из буфера приема процессу-получателю для обработки, даже если буфер не был заполнен; RST - перезагрузка текущего соединения; SYN - запрос на установление соединения; FIN - нет больше данных для передачи. В настоящее время 2 из зарезервированных ранее 6 бит используются в алгоритме раннего предупреждения о перегрузках (совместно с полем ECN в заголовке IP пакета).

Новые флаги

CWR - Congestion Window Reduced

ECE - ECN - Echo

Опции (часто используемые)

MSS - максимальный размер сегмента (Maximum Segment Size).

(Используется только в SYN-сегментах на этапе установки соединения).

WS - масштаб окна (window scale)

SACK - выборочное подтверждение (Selective Acknowledgement).

В протоколе TCP, также, как и в UDP, для связи с прикладными процессами используются порты. Порты, соответствующие наиболее популярным сервисам приведены на рисунке 4.

Рис. 4. Порты

Основные функции протокола:

* Управление соединениями и базовая передача данных:

Соединение в протоколе TCP идентифицируется парой полных адресов обоих взаимодействующих процессов (оконечных точек). Адрес каждой из оконечных точек включает IP-адрес (номер сети и номер компьютера) и номер порта. Одна оконечная точка может участвовать в нескольких соединениях.

Чтобы установить TCP соединение, необходимо:

1. Запрашивающая сторона (которая, как правило, называется клиент) отправляет SYN сегмент, указывая номер порта сервера, к которому клиент хочет подсоединиться, и исходный номер последовательности клиента ISN. Это сегмент номер 1.

2. Сервер отвечает своим сегментом SYN, содержащим исходный номер последовательности сервера (сегмент 2). Сервер также подтверждает приход SYN клиента с использованием ACK (ISN клиента плюс один). На SYN используется один номер последовательности.

3. Клиент должен подтвердить приход SYN от сервера с использованием ACK (ISN сервера плюс один, сегмент 3).

Когда каждая сторона отправила свой SYN чтобы установить соединение, она выбирает исходный номер последовательности (ISN) для этого соединения. ISN должен меняться каждый раз, поэтому каждое соединение имеет свой, отличный от других ISN. Соединение в TCP позволяет вести передачу данных одновременно в обе стороны, то есть полнодуплексную передачу. Сеанс обмена данными заканчивается процедурой разрыва соединения, которая аналогична процедуре установки, с той разницей, что вместо SYN для разрыва используется служебный бит FIN (“данных для отправки больше не имею”), который устанавливается в заголовке последнего сегмента с данными, отправляемого узлом. Хотя TCP-соединения являются дуплексными, чтобы понять, как происходит их разъединение, лучше считать их парами симплексных соединений. Каждое симплексное соединение разрывается независимо от своей пары. Чтобы разорвать соединение, любая из сторон может послать ТСР-сегмент с установленным в единицу битом FIN, что означает, что у него больше нет данных для передачи. Когда этот ТСР-сегмент получает подтверждение, это направление передачи закрывается. Тем не менее, данные могут продолжать передаваться неопределенно долго в противоположном направлении. Соединение разрывается, когда оба направления закрываются. Обычно для разрыва соединения требуются четыре ТСР-сегмента: по одному с битом FIN и по одному с битом АСК в каждом направлении. Первый бит АСК и второй бит FIN могут также содержаться в одном ТСР-сегменте, что уменьшит количество сегментов до трех.

* Обеспечение достоверности:

TCP обеспечивает защиту от повреждения, потери, дублирования и нарушения очередности получения данных. Все байты в потоке данных сквозным образом пронумерованы в возрастающем порядке. Для защиты от потерь протокол использует механизм подтверждений (квитанций). При удачном приеме байта данных принимающий модуль посылает отправителю подтверждение о приеме - номер удачно принятого октета. Если в течение некоторого времени отправитель не получит подтверждения, считается, что байт не дошел или был поврежден, и он посылается снова. Этот механизм контроля надежности называется PAR (Positive Acknowledgment with Retransmission). В протоколе TCP реализована разновидность алгоритма квитирования с использованием окна. Особенность этого алгоритма состоит в том, что, хотя единицей передаваемых данных является сегмент, окно определено на множестве нумерованных байт неструктурированного потока данных, поступающих с верхнего уровня и буферизуемых протоколом TCP.

Нумерация октетов используется также для упорядочения данных в порядке очередности и обнаружения дубликатов (которые могут быть посланы из-за большой задержки при передаче подтверждения или потери подтверждения).

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

* Разделение (мультиплексирование) каналов

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

* Управление потоком

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

В протоколе TCP также, как и в UDP, для связи с прикладными процессами используются порты. Номера портам присваиваются аналогичным образом: имеются стандартные, зарезервированные номера (например, номер 21 закреплен за сервисом FTP, 23 - за telnet), а менее известные приложения пользуются произвольно выбранными локальными номерами.

Однако в протоколе TCP порты используются несколько иным способом. Для организации надежной передачи данных предусматривается установление логического соединения между двумя прикладными процессами. Когда прикладной процесс начинает использовать TCP, то модуль TCP на машине клиента и модуль TCP на машине сервера начинают общаться. Эти два оконечных модуля TCP поддерживают информацию о состоянии соединения, называемого виртуальным каналом. Этот виртуальный канал потребляет ресурсы обоих оконечных модулей TCP. Канал является дуплексным: данные могут одновременно передаваться в обоих направлениях. Один прикладной процесс пишет данные в TCP-порт, они проходят по сети, и другой прикладной процесс читает их из своего TCP-порта. В рамках соединения осуществляется обязательное подтверждение правильности приема для всех переданных сообщений, и при необходимости выполняется повторная передача.

Установление соединения выполняется в следующей последовательности:

· При установлении соединения одна из сторон является инициатором. Она посылает запрос к протоколу TCP на открытие порта для передачи (active open).

· После открытия порта протокол TCP на стороне процесса-инициатора посылает запрос процессу, с которым требуется установить соединение.

· Протокол TCP на приемной стороне открывает порт для приема данных (passive open) и возвращает квитанцию, подтверждающую прием запроса.

· Для того чтобы передача могла вестись в обе стороны, протокол на приемной стороне также открывает порт для передачи (active port) и также передает запрос к противоположной стороне.

· Сторона-инициатор открывает порт для приема и возвращает квитанцию.

· Соединение считается установленным. Далее происходит обмен данными в рамках данного соединения.

Концепция квитирования

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

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

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

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

Во втором методе для повышения коэффициента использования линии источнику разрешается передать некоторое количество кадров в непрерывном режиме, то есть в максимально возможном для источника темпе, без получения на эти кадры ответных квитанций. Таким образом, между отправленными и подтвержденными данными существует окно уже отправленных, но еще неподтвержденных данных. Количество кадров, которые разрешается передавать, таким образом, называется размером окна. Как правило, размер окна устанавливается в стартовых файлах сетевого программного обеспечения. Рисунок 5 иллюстрирует данный метод для размера окна в W кадров. Обычно кадры при обмене нумеруются циклически, от 1 до W. При отправке кадра с номером 1 источнику разрешается передать еще W-1 кадров до получения квитанции на кадр 1. Если же за это время квитанция на кадр 1 так и не пришла, то процесс передачи приостанавливается, и по истечению некоторого тайм-аута кадр 1 считается утерянным (или квитанция на него утеряна) и он передается снова.

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

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

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

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

В качестве квитанции получатель сегмента отсылает ответное сообщение (сегмент), в которое помещает число, на единицу превышающее максимальный номер байта в полученном сегменте. Если размер окна равен W, а последняя квитанция содержала значение N, то отправитель может посылать новые сегменты до тех пор, пока в очередной сегмент не попадет байт с номером N+W. Этот сегмент выходит за рамки окна, и передачу в таком случае необходимо приостановить до прихода следующей квитанции.

Выбор тайм-аута

Выбор времени ожидания (тайм-аута) очередной квитанции является важной задачей, результат решения которой влияет на производительность протокола TCP.

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

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

Реакция на перегрузку сети

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

При переполнении приемного буфера конечного узла "перегруженный" протокол TCP, отправляя квитанцию, помещает в нее новый, уменьшенный размер окна. Если он совсем отказывается от приема, то в квитанции указывается окно нулевого размера. Однако даже после этого приложение может послать сообщение на отказавшийся от приема порт. Для этого, сообщение должно сопровождаться пометкой "срочно" (бит URG в запросе установлен в 1). В такой ситуации порт обязан принять сегмент, даже если для этого придется вытеснить из буфера уже находящиеся там данные.

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

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

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

Содержание