Архитектура Аудит Военная наука Иностранные языки Медицина Металлургия Метрология
Образование Политология Производство Психология Стандартизация Технологии 


Адаптационные механизмы протокола TCP




Надежный потоковый сервис протокол ТСР обеспечивает посредством специальных адаптационных механизмов. Напомним, что этот протокол предполагает наличие сетевой среды, в которой пакеты могут теряться, дублироваться, приходить в узел назначения с нарушением порядка их отправки. Для идентификации таких нарушений в протоколе введена последовательная нумерация байтов сегмента. Порядковый номер первого байта сегмента передается в его заголовке и он считается порядковым номером сегмента. Номер первого байта для каждого соединениявыбирается случайным образом в период установления соединения. Поскольку каждый байт сегмента оказывается пронумерованным, то легко решается задача опознания на приемной стороне нарушений порядка их доставки. Механизм подтверждения приема носит накопительный характер, т.е. подтверждение приема байта с номером N, означает, что байты с номерами N-1, N-2, … успешно получены. Диапазон возможных номеров байтов ограничен числами от 0 до 231-1. Заметим, что при скорости передачи в 100 Мбит/с полный цикл использования всего допустимого диапазона номеров составляет 5,4 минуты, что вполне достаточно для того, чтобы любой сегмент был получен приемной станцией, а все его дубли были уничтожены.

 

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

 

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

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-соединения.

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

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

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



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

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

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

 





Рекомендуемые страницы:


Читайте также:



Последнее изменение этой страницы: 2016-05-30; Просмотров: 619; Нарушение авторского права страницы


lektsia.com 2007 - 2021 год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! (0.009 с.) Главная | Обратная связь