Сидни Фейт - TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security)

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

TCP доказал свою гибкость, работая в сетях со скоростью обмена в сотни или миллионы бит за секунду. Этот протокол позволил достичь хороших результатов в современных локальных сетях с топологиями Ethernet, Token-Ring и Fiber Distributed Data Interface (FDDI), а также для низкоскоростных линий связи или соединений на дальние расстояния (подобных спутниковым связям).

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

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

■ Максимальный размер сегмента приемника — 1 Кбайт.

■ Приемное окно — 4 Кбайт.

■ Полоса пропускания позволяет пересылать по два сегмента за 1 с.

■ Принимающее приложение поглощает данные по мере их поступления.

■ Сообщения ACK прибывают через 2 с.

Отправитель способен посылать данные непрерывно. Ведь когда выделенный для окна объем будет заполнен, прибывает ACK, разрешающий отправку другого сегмента:

SEND SEGMENT 1.

SEND SEGMENT 2.

SEND SEGMENT 3.

SEND SEGMENT 4.

Через 2 с:

RECEIVE ACK OF SEGMENT 1, CAN SEND SEGMENT 5.

RECEIVE ACK OF SEGMENT 2, CAN SEND SEGMENT 6.

RECEIVE ACK OF SEGMENT 3, CAN SEND SEGMENT 7.

RECEIVE ACK OF SEGMENT 4, CAN SEND SEGMENT 8.

Еще через 2 с:

RECEIVE ACK OF SEGMENT 5, CAN SEND SEGMENT 9.

. . .

Если приемное окно было только в 2 Кбайт, отправитель будет вынужден ждать одну секунду из каждых двух перед отправкой следующих данных. Фактически, чтобы удержать непрерывный поток данных, приемное окно должно иметь размер не менее:

Окно = Полоса пропускания×Время цикла

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

Теперь рассмотрим, что происходит с высокоскоростными соединениями. Например, если полоса пропускания и скорость пересылки измеряются 10 млн. бит в секунду, но время цикла составляет 100 мс (1/10 секунды), то для непрерывного потока приемное окно должно хранить, по крайней мере, 1 000 000 бит, т.е. 125 000 байт. Но наибольшее число, которое можно записать в поле заголовка для приемного окна TCP, равно 65 536.

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

Сейчас активно проводятся новые исследования для улучшения TCP/IP и устранения упомянутых выше препятствий.

Данная глава посвящена многочисленным функциям TCP. Ниже перечислены основные из них:

■ Связывание портов с соединениями

■ Инициализация соединений посредством трехшагового подтверждения

■ Выполнение медленного старта, исключающего перегрузку сети

■ Сегментация данных при пересылке

■ Нумерация данных

■ Обработка поступающих дублированных сегментов

■ Вычисление контрольных сумм

■ Регулирование потока данных через приемное окно и окно отправки

■ Завершение соединения установленным способом

■ Прерывание соединения

■ Пересылка срочных данных

■ Положительное подтверждение повторной пересылки

■ Вычисление тайм-аута повторной пересылки

■ Снижение обратного трафика при перегрузке сети

■ Сигнализация поступления сегментов не по порядку

■ Зондирование закрытия приемного окна

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

Ниже мы кратко рассмотрим типичную смену состояний сервера и клиента, расположенных на разных концах соединения. Мы не ставим целью дать исчерпывающее описание всех возможных состояний при пересылке данных. Оно приведено в RFC 793 и документе Host Requirements .

Во время установки соединений сервер и клиент проходят схожие последовательности состояний. Состояния сервера показаны в таблице 10.3, а состояния клиента — в таблице 10.4.

Таблица 10.3 Последовательность состояний сервера

Таблица 10.4 Последовательность состояний клиента

Если бы партнеры одновременно пытались установить соединение друг с другом (что случается крайне редко), каждый прошел бы через состояния CLOSED, SYN-SENT, SYN-RECEIVED и ESTABLISHED.

Конечные стороны соединения остаются в состоянии ESTABLISHED, пока одна из сторон не приступит к закрытию соединения, послав сегмент FIN. В процессе обычного закрытия сторона, инициирующая это закрытие, проходит через состояния, показанные в таблице 10.5. Ее партнер проходит через состояния, представленные в таблице 10.6.