Я понимаю процесс предотвращения перегрузки, когда вы пытаетесь контролировать уровень перегрузки в сети и избегать потери пакетов. Но как может быть три подтверждения, даже если одно потеряно при передаче и, наконец, достигнет пункта назначения после тайм-аута, конечно, пакет будет отброшен, если он истек, а не просто продолжил свой путь и дублировал x количество раз во время перегрузки.
Дублированные ACK являются частью системы повторной передачи / выборочного подтверждения. Без поддержки SACK вы получите дубликаты ACK, когда пакет потерян, а получатель сообщает отправителю, что он виден, с точностью до порядкового номера ACKed. ACK будет отправляться для каждого полученного пакета вне очереди, поэтому вы увидите повторяющиеся ACK, а иногда и многие из них, если диаметр сети достаточно велик, а размер окна достаточно велик.
Сначала мы должны понять, что ACK не говорят, что мы видели конкретный порядковый номер - они фактически говорят, что мы не видели этот конкретный порядковый номер, но мы видели все предыдущие.
Из RFC 793:
Сегменты также несут номер подтверждения, который является порядковым номером следующего ожидаемого октета данных при передаче в обратном направлении.
ACK является дублированным ACK, если среди других критериев (RFC 5681)
номер подтверждения равен наибольшему подтверждению, полученному на данном соединении
Повторяющиеся ACK - это признаки того, что получатель что-то получил, а не правильный порядковый номер. После трех повторяющихся ACK (обычно 3) отправитель повторно передает сегмент. Это называется быстрой ретрансляцией и, следовательно, быстрее, чем повторная передача на основе тайм-аута, упомянутая в вашем вопросе.