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

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

 повторной отправки, что указывает на потерянное соединение.

1048 persist timeouts Тайм-ауты по зондированию

 нулевого окна.

535 keepalive timeouts Тайм-ауты по проверке

 неработающего соединения.

472 connections dropped by keepalive

10.14 Соответствие требованиям разработчика

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

Что произойдет при установке системы, которая не придерживается твердо этих стандартов? Она не сможет обеспечить должную производительность для собственных пользователей, и будет плохим соседом для других систем сети, препятствуя восстановлению нормальной работы после временной перегрузки и создавая чрезмерный трафик, приводящий к отбрасыванию датаграмм.