14677 connections established (including accepts)
18929 connections closed (including 643 drops)
4100 embryonic connections dropped
572187 segments updated rtt (of 587397 attempts) Неудачные попытки изменения
времени цикла, поскольку ACK не успел прийти до завершения тайм-аута,
11014 retransmit timeouts
26 connections dropped by rexmit timeout Последующие неудачные попытки
повторной отправки, что указывает на потерянное соединение.
1048 persist timeouts Тайм-ауты по зондированию
нулевого окна.
535 keepalive timeouts Тайм-ауты по проверке
неработающего соединения.
472 connections dropped by keepalive
10.14 Соответствие требованиям разработчика
Текущий стандарт TCP требует, чтобы реализации твердо придерживались процедуры медленного старта при инициализации соединения и использовали алгоритмы Керна и Джекобсона для оценки тайм- аута повторной отправки данных и управления нагрузкой. Тесты показали, что эти механизмы приводят к значительному повышению производительности.
Что произойдет при установке системы, которая не придерживается твердо этих стандартов? Она не сможет обеспечить должную производительность для собственных пользователей, и будет плохим соседом для других систем сети, препятствуя восстановлению нормальной работы после временной перегрузки и создавая чрезмерный трафик, приводящий к отбрасыванию датаграмм.
10.15 Барьеры для производительности
TCP доказал свою гибкость, работая в сетях со скоростью обмена в сотни или миллионы бит за секунду. Этот протокол позволил достичь хороших результатов в современных локальных сетях с топологиями Ethernet, Token-Ring и Fiber Distributed Data Interface (FDDI), а также для низкоскоростных линий связи или соединений на дальние расстояния (подобных спутниковым связям).
TCP разработан так, чтобы реагировать на экстремальные условия, например на перегрузки в сети. Однако в текущей версии протокола имеются особенности, ограничивающие производительность в перспективных технологиях, которые предлагают полосу пропускания в сотни и тысячи мегабайт. Чтобы понять возникающие проблемы, рассмотрим простой (хотя и нереалистичный) пример.
Предположим, что при перемещении файла между двумя системами необходимо выполнять обмен непрерывным потоком настолько эффективно, насколько это возможно. Допустим, что:
■ Максимальный размер сегмента приемника — 1 Кбайт.
■ Приемное окно — 4 Кбайт.
■
■ Принимающее приложение поглощает данные по мере их поступления.
■ Сообщения ACK прибывают через 2 с.
Отправитель способен посылать данные непрерывно. Ведь когда выделенный для окна объем будет заполнен, прибывает ACK, разрешающий отправку другого сегмента:
SEND SEGMENT 1.
SEND SEGMENT 2.
SEND SEGMENT 3.
SEND SEGMENT 4.
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.
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 и устранения упомянутых выше препятствий.
10.16 Функции TCP
Данная глава посвящена многочисленным функциям TCP. Ниже перечислены основные из них:
■ Связывание портов с соединениями
■ Инициализация соединений посредством трехшагового подтверждения
■ Выполнение медленного старта, исключающего перегрузку сети
■ Сегментация данных при пересылке
■ Нумерация данных
■ Обработка поступающих дублированных сегментов
■ Вычисление контрольных сумм
■ Регулирование потока данных через приемное окно и окно отправки
■ Завершение соединения установленным способом
■ Прерывание соединения
■ Пересылка срочных данных
■ Положительное подтверждение повторной пересылки
