TCP DUP ACK отправляется для повторно переданного пакета
У меня есть клиент под управлением Ubuntu 14.0.4, и я наблюдаю проблему с TCP-подключениями к этому клиентскому узлу. Подтверждение TCP от клиента сбрасывается, и сервер повторно передает пакет клиенту. Теперь клиент отправляет DUP ACK серверу, когда он получает повторную передачу. Я предполагаю, что отправлено DUP ACK только когда пакет получен не по порядку, а не если вы получили повторную передачу уже полученного пакета
Это скриншот: 
Кто-нибудь знает, почему TCP так себя ведет?
Дублирующиеся ACK могут быть сгенерированы двумя способами, часто из-за потери пакетов:
- При отправке сегмента отправитель не получает ACK в течение заданного интервала (200 мс - очень распространенное явление, но это часто настраивается), он повторно передает этот сегмент, дублируя ACK, содержащийся в этом сегменте.
- При получении получен неожиданный номер сегмента; заставляя принимающую сторону повторно подтвердить ожидаемый порядковый номер. Это уведомляет отправляющую сторону о том, что, вероятно, необходима повторная передача. что произойдет дальше, зависит от Selective-ACKs, что выходит за рамки этого ответа.
- При получении получить сегмент, который уже был подтвержден.
Первый и третий пули связаны. Если причина, по которой отправитель не получил свой ACK, заключается в том, что ACK был съеден гремлинами, повторная передача на основе таймера будет повторять сегмент при повторной передаче. Получатель, уже подтвердивший это, повторно выполнит Dup-ACK и будет ждать следующего сегмента. Если гремлины не съедят этот Dup-ACK, отправитель продолжит передачу.
В вашем случае тайминги пакетов предполагают, что dup-ACK на основе таймера здесь не играет. Самый большой RTT составляет 14 мс. Это предполагает ошибочную повторную передачу со стороны отправителя, запускающую Dup-ACK. Я видел такое поведение из-за ошибок в сетевых драйверах и даже прошивки сетевого адаптера в случае механизмов разгрузки TCP. Хотя не все так в последнее время.