повторной пересылки (в стандартах RFC эту величину именуют Retransmission TimeOut — RTO) дает следующая формула с ограничением сглаженного отклонения (SDEV):
Т = Тайм-аут повторной пересылки = SRTT + 2×SDEV
Именно эта формула рекомендована в RFC 1122. Однако некоторые реализации используют другую:
Т = SRTT + 4×SDEV
Для вычисления SDEV сначала определяют абсолютное значение текущего отклонения:
DEV = | Последнее время цикла – старое SRTT |
Затем используют формулу сглаживания, чтобы учесть последнее значение:
Новое SDEV = 3/4×старое SDEV + 1/4×DEV
Остается один вопрос — какие взять начальные значения? Рекомендуется:
Начальный тайм-аут = 3 с
Начальный SRTT = 0
Начальный SDEV = 1,5 с
Ван Джекобсон определил быстрый алгоритм, который очень эффективно вычисляет тайм-аут повторной пересылки данных.
10.13.6 Пример статистики
Насколько успешно будет работать вычисленный выше тайм-аут? При реализации полученного значения наблюдались значительные повышения производительности. Примером могут служить статистические данные команды
tcp:
1301644 packets sent
879137 data packets (226966295 bytes)
21815 data packets (8100927 bytes) retransmitted
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)
Системой
10.13.7 Вычисления после повторной отправки
В представленных выше формулах используется значение времени цикла как интервала между отправкой сегмента и получением подтверждения его приема. Однако предположим, что в течение периода тайм-аута подтверждение не получено и данные должны быть оправлены повторно.
Алгоритм Керна предполагает, что в этом случае не следует изменять время цикла. Текущее сглаженное значение времени цикла и
10.13.8 Действия после повторной пересылки
Но что происходит до получения подтверждения? После повторной пересылки поведение TCP радикально меняется в основном из-за потери данных от перегрузки в сети. Следовательно, реакцией на повторную отправку данных будет:
■ Снижение скорости повторной пересылки
■ Борьба с перегрузкой сети с помощью сокращения общего трафика
10.13.9 Экспоненциальное торможение
После повторной пересылки удваивается интервал тайм-аута. Однако что произойдет при повторном переполнении таймера? Данные будут оправлены еще раз, а период повторной пересылки снова удвоится. Этот процесс называется
Если продолжает проявляться неисправность сети, период тайм-аута будет удваиваться до достижения предустановленного максимального значения (обычно — 1 мин). После тайм-аута может быть отправлен только один сегмент. Тайм-аут наступает и при превышении заранее установленного значения для количества пересылок данных без получения ACK.
10.13.10 Снижение перегрузок за счет уменьшения пересылаемых по сети данных
Сокращение объема пересылаемых данных несколько сложнее, чем рассмотренные выше механизмы. Оно начинает работать, как и уже упомянутый медленный старт. Но, поскольку устанавливается граница для уровня трафика, который может в начальный момент привести к проблемам, будет реально замедляться скорость обмена вследствие увеличения размера нагрузочного окна по одному сегменту. Нужно установить значения границы для реального сокращения скорости отправки. Сначала вычисляется граница опасности (danger threshold):
Если полученная величина будет более двух сегментов, ее используют как границу. Иначе размер границы устанавливается равным двум сегментам. Полный алгоритм восстановления требует:
■ Установить размер нагрузочного окна в один сегмент.
■ Для каждого полученного ACK увеличивать размер нагрузочного окна на один сегмент, пока не будет достигнута граница (что очень напоминает механизм медленного старта).
■ После этого с каждым полученным ACK к нагрузочному окну добавлять меньшее значение, которое выбирается на основе скорости увеличения по одному сегменту для времени цикла (увеличение
