TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security)
Шрифт:
10.14 Соответствие требованиям разработчика
Текущий стандарт TCP требует, чтобы реализации твердо придерживались процедуры медленного старта при инициализации соединения и использовали алгоритмы Керна и Джекобсона для оценки тайм-аута повторной отправки данных и управления нагрузкой. Тесты показали, что эти механизмы приводят к значительному повышению производительности.
Что произойдет при установке системы, которая не придерживается твердо этих стандартов? Она не сможет обеспечить должную производительность для собственных пользователей, и будет плохим
10.15 Барьеры для производительности
TCP доказал свою гибкость, работая в сетях со скоростью обмена в сотни или миллионы бит за секунду. Этот протокол позволил достичь хороших результатов в современных локальных сетях с топологиями Ethernet, Token-Ring и Fiber Distributed Data Interface (FDDI), а также для низкоскоростных линий связи или соединений на дальние расстояния (подобных спутниковым связям).
TCP разработан так, чтобы реагировать на экстремальные условия, например на перегрузки в сети. Однако в текущей версии протокола имеются особенности, ограничивающие производительность в перспективных технологиях, которые предлагают полосу пропускания в сотни и тысячи мегабайт. Чтобы понять возникающие проблемы, рассмотрим простой (хотя и нереалистичный) пример.
Предположим, что при перемещении файла между двумя системами необходимо выполнять обмен непрерывным потоком настолько эффективно, насколько это возможно. Допустим, что:
■ Максимальный размер сегмента приемника — 1 Кбайт.
■ Приемное окно — 4 Кбайт.
■ Полоса пропускания позволяет пересылать по два сегмента за 1 с.
■ Принимающее приложение поглощает данные по мере их поступления.
■ Сообщения ACK прибывают через 2 с.
Отправитель способен посылать данные непрерывно. Ведь когда выделенный для окна объем будет заполнен, прибывает ACK, разрешающий отправку другого сегмента:
Через 2 с:
Еще через 2 с:
Если приемное окно было только в 2 Кбайт, отправитель будет вынужден ждать одну секунду из каждых двух перед отправкой следующих данных. Фактически, чтобы удержать непрерывный поток данных, приемное окно должно иметь размер не менее:
Окно = Полоса пропускания×Время цикла
Хотя пример несколько преувеличен (для обеспечения более простых чисел), малое окно может привести к проблемам при соединениях через спутниковые
Теперь рассмотрим, что происходит с высокоскоростными соединениями. Например, если полоса пропускания и скорость пересылки измеряются 10 млн. бит в секунду, но время цикла составляет 100 мс (1/10 секунды), то для непрерывного потока приемное окно должно хранить, по крайней мере, 1 000 000 бит, т.е. 125 000 байт. Но наибольшее число, которое можно записать в поле заголовка для приемного окна TCP, равно 65 536.
Другая проблема возникает при высоких скоростях обмена, поскольку порядковые номера очень быстро закончатся. Если по соединению можно будет пересылать данные со скоростью 4 Гбайт/с, то порядковые номера должны обновляться в течение каждой секунды. Не будет возможности различить старые дублирующие датаграммы, которые были отсрочены более чем на секунду при перемещении по Интернету, от свежих новых данных.
Сейчас активно проводятся новые исследования для улучшения TCP/IP и устранения упомянутых выше препятствий.
10.16 Функции TCP
Данная глава посвящена многочисленным функциям TCP. Ниже перечислены основные из них:
■ Связывание портов с соединениями
■ Инициализация соединений посредством трехшагового подтверждения
■ Выполнение медленного старта, исключающего перегрузку сети
■ Сегментация данных при пересылке
■ Нумерация данных
■ Обработка поступающих дублированных сегментов
■ Вычисление контрольных сумм
■ Регулирование потока данных через приемное окно и окно отправки
■ Завершение соединения установленным способом
■ Прерывание соединения
■ Пересылка срочных данных
■ Положительное подтверждение повторной пересылки
■ Вычисление тайм-аута повторной пересылки
■ Снижение обратного трафика при перегрузке сети
■ Сигнализация поступления сегментов не по порядку
■ Зондирование закрытия приемного окна
10.17 Состояния TCP
Соединение TCP проходит несколько стадий: устанавливается соединение посредством обмена сообщениями, затем пересылаются данные, а далее соединение закрывается с помощью обмена специальными сообщениями. Каждый шаг в работе соединения соответствует определенному состоянию этого соединения. Программное обеспечение TCP на каждом конце соединения постоянно отслеживает текущее состояние другой стороны соединения.
Ниже мы кратко рассмотрим типичную смену состояний сервера и клиента, расположенных на разных концах соединения. Мы не ставим целью дать исчерпывающее описание всех возможных состояний при пересылке данных. Оно приведено в RFC 793 и документе Host Requirements.
Во время установки соединений сервер и клиент проходят схожие последовательности состояний. Состояния сервера показаны в таблице 10.3, а состояния клиента — в таблице 10.4.
Таблица 10.3 Последовательность состояний сервера