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

10.13.7 Вычисления после повторной отправки

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

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

10.13.8 Действия после повторной пересылки

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

■ Снижение скорости повторной пересылки

■ Борьба с перегрузкой сети с помощью сокращения общего трафика

10.13.9 Экспоненциальное торможение

После повторной пересылки удваивается интервал тайм-аута. Однако что произойдет при повторном переполнении таймера? Данные будут оправлены еще раз, а период повторной пересылки снова удвоится. Этот процесс называется экспоненциальным торможением (exponential backoff).

Если продолжает проявляться неисправность сети, период тайм-аута будет удваиваться до достижения предустановленного максимального значения (обычно — 1 мин). После тайм-аута может быть отправлен только один сегмент. Тайм-аут наступает и при превышении заранее установленного значения для количества пересылок данных без получения ACK.

10.13.10 Снижение перегрузок за счет уменьшения пересылаемых по сети данных

Сокращение объема пересылаемых данных несколько сложнее, чем рассмотренные выше механизмы. Оно начинает работать, как и уже упомянутый медленный старт. Но, поскольку устанавливается граница для уровня трафика, который может в начальный момент привести к проблемам, будет реально замедляться скорость обмена вследствие увеличения размера нагрузочного окна по одному сегменту. Нужно установить значения границы для реального сокращения скорости отправки. Сначала вычисляется граница опасности (danger threshold):

Граница – 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. Ограничение скорости пересылки во время перегрузки

10.13.11 Дублированные ACK

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

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

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

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

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

10.13.12 Что делается после подавления источника?

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

10.13.13 Статистика TCP

Наконец, давайте рассмотрим статистические сообщения команды 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           Последующие неудачные попытки