Блог

Я тестирую радиопрограмму GNU, которая может туннелировать TCP-трафик по беспроводной линии. При тестировании мы получаем несколько странных результатов, и в поисках виновника мне стало любопытно узнать о несогласованной задержке.

Как несогласованная задержка может повлиять на приложения TCP? Под несогласованностью я подразумеваю сильно отличающийся RTT для ACKS в соединении. Некоторое время подтверждения, кажется, поступают с нормальной скоростью, затем они исчезают, и у нас есть повторные передачи, за которыми следует «отложенное» подтверждение.

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

Теперь, более конкретно, как RTTS для ACKS, которые переключаются между быстрым и медленным, могут повлиять на TCP-соединение?

С учетом сказанного, есть ли какой-либо способ настроить стек IP для лучшей работы в этой среде?

TCP поддерживает сглаженный RTT (SRTT), чтобы сообщить ему, насколько быстра промежуточная сеть, то есть насколько быстро она может передавать. Если SRTT повышается, TCP замедляется. Если SRTT отключится, TCP ускорится. Если фактический RTT резко увеличивается и уменьшается, TCP может реагировать недостаточно быстро из-за сглаживания и передавать слишком быстро, что приведет к потере пакетов, что, в свою очередь, вызывает повторную передачу, которая тратит впустую полосу пропускания, используемую потерянными пакетами. Сглаживание RTT выполняется с помощью экспоненциального спада с коэффициентом усиления, я думаю, 0,2, поэтому старое значение SRTT в четыре раза превышает вес текущего RTT при вычислении нового значения SRTT.