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

9539 connection accepts

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 Кбайт.

■ Полоса пропускания позволяет пересылать по два сегмента за 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 и устранения упомянутых выше препятствий.

10.16 Функции TCP

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

10.17 Состояния TCP

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

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

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

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

Состояние сервера Событие Описание CLOSED (закрыто) Фиктивное состояние перед началом установки соединения. Пассивное открытие серверным приложением. LISTEN (отслеживание) Сервер ожидает соединения с клиентом. Сервер TCP получает SYN и посылает SYN/ACK. Сервер получил SYN и послал SYN/ACK. Переходит к ожиданию ACK. SYN-RECEIVED Сервер TCP получает ACK. ESTABLISHED (установлено) Получен ACK, открыто соединение.

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

Состояние сервера Событие Описание CLOSED Фиктивное состояние перед началом соединения. Клиентское приложение запрашивает соединение. Клиент TCP посылает SYN. SYN-SENT Клиент TCP послал SYN серверу. Клиент TCP получает SYN/ACK и посылает ACK. Клиент получил SYN/ACK от сервера и отправил обратно ACK. ESTABLISHED (установлено) Можно перейти к пересылке данных.

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