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

Граница – 1/2 minimum (текущее нагрузочное окно, приемное окно партнера)

Если полученная величина будет более двух сегментов, ее используют как границу. Иначе размер границы устанавливается равным двум сегментам. Полный алгоритм восстановления требует:

■ Установить размер нагрузочного окна в один сегмент.

■ Для каждого полученного ACK увеличивать размер нагрузочного окна на один сегмент, пока не будет достигнута граница (что очень напоминает механизм медленного старта).

■ После этого с каждым полученным ACK к нагрузочному окну добавлять меньшее значение, которое выбирается на основе скорости увеличения по одному сегменту для времени цикла (увеличение вычисляется как MSS/N, где N — размер нагрузочного окна в сегментах).

Сценарий для идеального варианта может упрощенно представить работу механизма восстановления. Предположим, что приемное окно партнера (и текущее нагрузочное окно) имело до выявления тайм-аута размер в 8 сегментов, а граница определена в 4 сегмента. Если принимающее приложение мгновенно читает данные из буфера, размер приемного окна останется равным 8 сегментам.

■ Отправляется 1 сегмент (нагрузочное окно = 1 сегмент).

■ Получен ACK — отправляется 2 сегмента.

■ Получен ACK для 2 сегментов — посылается 4 сегмента, (достигается граница).

■ Получен ACK для 4 сегментов. Посылается 5 сегментов.

■ Получен ACK для 5 сегментов. Посылается 6 сегментов.

■ Получен ACK для 6 сегментов. Посылается 7 сегментов.

■ Получен ACK для 7 сегментов. Посылается 8 сегментов (нагрузочное окно по размеру снова стало равно приемному окну).

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

Рис. 10.20.Ограничение скорости пересылки во время перегрузки

В некоторых реализациях применяется необязательная возможность — так называемая быстрая повторная пересылка (fast retransmit) — с целью ускорить повторную отправку данных при определенных условиях. Ее основная идея связана с отправкой получателем дополнительных ACK, указывающих на пробел в принятых данных.

Принимая сегмент, поступивший не по порядку, получатель отсылает обратно ACK, указывающий на первый байт потерянных данных (см. рис. 10.21).

Рис. 10.21.Дублированные ACK

Отправитель не выполняет мгновенной повторной пересылки данных, поскольку IP может и в нормальном режиме доставлять данные получателю без последовательности отправки. Но когда получено несколько дополнительных ACK на дублирование данных (например, три), то отсутствующий сегмент будет отправлен, не дожидаясь завершения тайм-аута.

Отметим, что каждый дублирующий ACK указывает на получение сегмента данных. Несколько дублирующих ACK позволяют понять, что сеть способна доставлять достаточный объем данных, следовательно, не слишком сильно нагружена. Как часть общего алгоритма выполняется небольшое сокращение размера нагрузочного окна при реальном увеличении сетевого трафика. В данном случае процесс радикального изменения размера при восстановлении работы не применяется.

В соответствии со стандартом Host Requirements (требования к хостам) TCP должен выполнять тот же самый медленный старт, как это описано выше, при подавлении источника (source quench). Однако сообщение об этом не является целенаправленным или эффективным, поскольку получившее это сообщение соединение может и не создавать слишком большого трафика. Текущая спецификация Router Requirements (требования к маршрутизаторам) указывает, что маршрутизаторы не должны посылать сообщений о подавлении источника.

Наконец, давайте рассмотрим статистические сообщения команды netstat, чтобы увидеть в работе многие из описанных выше механизмов.

tcp:

1301644 packets sent Пакетами именуются сегменты.

879137 data packets (226966295 bytes)

21815 data packets (8100927 bytes) retransmitted Повторная пересылка.

132957 ack-only packets (104216 delayed) Отметим большое количество

задержанных ACK.

4 URG only packets

1038 window probe packets Зондирование открытия окна

нулевого размера.

248582 window update packets

22413 control packets Это сообщения SYN и FIN.

2012869 packets received

762469 acks (for 226904227 bytes)

35803 duplicate acks Сигнал о пакетах, прибывших

вне последовательности.

0 acks for unsent data

1510769 packets (314955304 bytes)

received in-sequence

9006 completely duplicate packets (867042 bytes) Результат тайм-аута при реальной

доставке данных.

74 packets with some dup. data (12193 bytes duped)С целью большей эффективности

некоторые данные при повторной отправке были перепакетированы для включения дополнительных байт.

13452 out-of-order packets (2515087 bytes)

530 packets (8551 bytes) of data after window Возможно, эти данные были

включены в сообщения зондирования.

526 window probes

14158 window update packets

402 packets received after close Это последующие повторные

отправки.

108 discarded for bad checksums Неверная контрольная сумма TCP.

0 discarded for bad header offset fields

7 discarded because packet too short

6378 connection requests

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

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