Мне сложно понять это концептуально.
Почему TCP Reno сокращает свое окно перегрузки вдвое, когда он обнаруживает тройное дублирование ACK и сокращает свое окно до 1 сегмента по истечении времени ожидания?
Я понимаю, что это делает Рино, но не совсем понимаю Зачем. Любая помощь?
Краткий ответ
Длинный ответ
Сравнить с TCP Tahoe, который имеет всего два состояния Slow Start и Congestion Avoidance, TCP Reno есть другое государство, называемое Fast Recovery.
На тройном дубликате Ack,TCP Reno переходы к Fast Recovery.
в Fast Recovery состояние, он переходит обратно в Congestion
Avoidance когда он получает новый Ack, сбрасывая окно перегрузки до половины размера окна перегрузки при переходе на Fast Recovery штат.
По истечении времени он возвращается к Slow Start так же, как в Congestion
Avoidance.
При получении дубликата Ack, окно перегрузки увеличивается на 1. (Инфляция окна перегрузки)
Причина не въезда Slow Start состояние (что означает уменьшение окна перегрузки до 1) из-за получения дубликатов Ack сообщает TCP, что был потерян не только пакет. Получатель может только сгенерировать дубликат Ack когда получен другой сегмент, этот сегмент покинул сеть и находится в буфере получателя.
Таким образом, данные по-прежнему текут между двумя концами, и TCP Reno не хочет внезапно уменьшать поток.
Уменьшая вдвое окно заторов, оставаясь в Congestion Avoidance штат, TCP Reno улучшает производительность сети.
Вы можете увидеть простой тест на производительность TCP Reno и TCP Tahoe в этом ссылка на сайт.
Прибытие дублированных ACK указывает на то, что что-то покинуло канал, и указывает на «не столь серьезную перегрузку», и есть пакеты, буферизованные и, возможно, находящиеся в полете, поэтому мы хотим, так сказать, поддерживать поток. Уменьшение окна перегрузки до половины сокращает время, в течение которого канал пуст (и есть варианты контроля перегрузки, которые не уменьшаются настолько сильно).
Тайм-аут - это признак чего-то более серьезного, поэтому более подходящим ответом было бы гораздо большее уменьшение окна.
Если вы ищете обоснование для коэффициента мультипликативного уменьшения 0,5 (в отличие, например, от аддитивного уменьшения или большей мультипликативной константы, такой как 0,9), в приложении D к Эта бумага по Ван Якобсон, один из разработчиков оригинальных алгоритмов контроля перегрузки TCP.