Фаза передачи данных

Фаза установления соединения.

Фаза установления соединения, предшествующая фазе передачи данных, содержит следующие действия.

1. Хост А отправляет хосту Б запрос соединения посредством установки флага SYN и инициализирует значение начального номера нумерующей последовательности (Seq_no = m).

2. Хост Б отвечает на этот запрос установкой флага ACK и определяет поле «Порядковый номер подтверждения» значением на единицу большим m (Ack_no = m+1); одновременно, хост Б в своем ответе А отправляетзапрос соединения (SYN) и также инициализирует значение начального номера своей нумерующей последовательности (Seq_no = k).

3. Хост А отвечает на запрос соединения от хоста Б установкой флага ACK и подтверждением ожидания следующего байта данных с порядковым номером k+1 (Ack_no = k+1); при этом, значение поля «Порядковый номер сегмента» устанавливается в значение m+1 (Seq_no = m+1).

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

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

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

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

Пусть в момент t₀ ТСР-модуль хоста В объявил величину своего окна равной 2048 байт и номер следующего ожидаемого байта 2000. Такой размер окна позволяет хосту А отправить без подтверждения 2 Кбайта данных, однако в его выходном буфере имеется лишь 1024 байта данных. Хост А отправляет эти данные нумеруя байты начиная с 2000. Одновременно, он объявляет величину своего окна равной 1024 байта и подтверждает, что номер ожидаемого первого байта от хоста Б должен быть равен 1. Хост Б задерживает выдачу подтверждения на прибывший сегмент данных, полагая, что у него появятся данные для отправки хосту А, вместе с которыми он отправит и подтверждение. Тем временем, в момент t₂ модуль ТСР хоста А снова получил от своего приложения 1024 байт данных и передал их хосту Б. После этого величина окна отправки на хосте А стала равной нулю и дальнейшая отправка им данных до получения подтверждения от хоста Б оказывается невозможной. В момент t₃ модуль ТСР хоста Б получил 128 байт данных для отправки; вместе с ними он отправляет подтверждение получения от хоста А двух сегментов данных, указывая Ack_no=4048. К этому моменту в буферной памяти модуля ТСР хоста Б оказывается свободными лишь 512 байт, поэтому он объявляет величину своего окна приема равной 512. Когда хост А получит этот сегмент, он установит величину окна отсылки равной 512 байт и, несмотря на то, что в момент t₄ в его буфере имеется 2048 байт данных, он сможет отослать только 512 байт и не перегрузит буфер хоста Б.

Предыдущее рассмотрение показывает, что задержка отправки подтверждения позволяет более экономно использовать пропускную способность канала. Это особенно актуально в ситуациях, подобных login-сессиям, когда пользователь вводит свои аутентификационные данные по одному символу. Пересылка каждого из них, сама по себе весьма затратна (на один байт информации приходится не менее 40 байтов заголовков TCP и IP уровней), а выдача подтверждения на каждый такой сегмент еще более усугубляет ситуацию. Решение, экономящее пропускную способность канала связи, было предложено Нейглом (Nagle). Идея алгоритма достаточно проста. Когда интерактивное приложение требует отсылки символа, модуль ТСР отправляет его и ждет подтверждения. Поступающие в этот период времени от приложения символы не передаются, а буферизируются; они отправляются все вместе в одном сегменте после получения подтверждения на первый отправленный символ. В локальных сетях, где задержки доставки сегментов относительно малы и каналы связи являются достаточно широкополосными, применение рассмотренного алгоритма является нецелесообразным.

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

Рассмотрим еще проблему зацикливания нумерующей последовательности, характерную для работы протокола ТСР в высокоскоростных средах. Исходная спецификация протокола предполагала, что максимальное время жизни сегмента составляет 2 минуты. Последовательность из 2³² номеров способна пронумеровать 4294967296 байт. Для их передачи по линии с пропускной способностью 2048 Кбит/с потребуется (2³² х 8)/(2,048х10⁶) = 4,5 часа, а по линии ОС-48 (2,4 Гбит/с) всего 14 секунд. Ясно, что на современных высокоскоростных линиях протокол TCP может терять работоспособность. Решение этой проблемы было найдено посредством определения в опциональном поле заголовка сегмента 4-х байтовой временной метки. Приемный модуль включает ее в свой ACK-сегмент, и таким образом объединяются два способа разметки последовательности отправляемых сегментов. Это увеличивает период нумерующей последовательности до 2⁶⁴. Ясно, что для реализации этого механизма таймер временных меток должен изменять свое значение, по крайней мере, один раз за время необходимое для отправки 2³¹ байт (максимальное значение окна передачи). Это требование определяет нижнюю границу частоты этого таймера. Эта частота не должна быть и настолько высокой, чтобы полный цикл показаний таймера был пройден за время, меньшее максимального времени жизни сегмента. Значения в диапазоне от 1 Гц до 1 кГц удовлетворяют этим ограничениям. Например, при частоте в 1кГц протокол будет успешно работать на линиях с пропускной способностью до 8 Тбит/с. [RFC 1323].