TCP DUP ACK

Тут представлен пример как не должен работать http сервер. Одна из характерных ошибок случившаяся на начальном этапе внедрения LWIP в наш проект.

Стрелками показаны реально принятые сервером пакеты (остальные потеряны), поэтому и возникает retransmission (повторные передачи от клиента). Но это нормально . Это говорит о том , что наш сервер очень тормозной (оно и неудивительно это на контроллере с ОЗУ 128К).

фотка 1

Пакет retransmission (повторный) ничем не должен отличается от основного , никакими опциями. Но у нас есть огромный непонятный нюанс (должно ли так быть?) : всего 2 пакета надо было передать (содержание 1460 + 885) , клиент делает повторную передачу этих двух пакетов , но содержание их теперь другое (1460 + 1460)... Причем сначала 1460 (это от конца 885:2345) и потом 1460 (это с начала 0:1460). Если еще учесть ,что в первом retransmission Seq=886 Ack=1 , а во втором Seq=886 Ack=1, то можно предположить , что это не ошибка клиента и на стороне сервера можно таки собрать содержание передаваемых пакетов корректно. Но LWIP 1.4.1 или 2.1.2 этого не поддерживают (как я понял).

Дальше по коду наш сервер почему-то решает передать на первый пакет в ответ tcp_send_empty_ack , хотя с SYN/ACK мы клиенту указали MSS 2920 , то способны принять 1460*2 (два полноценных пакета) БЕЗ ПОДТВЕРЖДЕНИЯ. Где логика?

Вот тут проблема

Мы (сервер) передаем tcp_send_empty_ack с параметрами Seq=1 Ack=1 и это точно что-то неправильное. Поэтому WinShark помечает этот пакет TCP DUP ACK.

Это надо понимать так : сервер и клиент установили уже соединение (3 первых пакета) . Потом клиент посылает данные 1460+885 (два пакета). Но сервер отвечает ACK с нулевой длиной , что я получил данные с Seq =1. То есть я сервер получил 1 байт. Какой 1 байт непонятно....