При устранении еще одной проблемы я заметил странную схему закрытия TCP.
Пакеты: http://www.cloudshark.org/captures/7590ec4e6bef
Происходит то, что по какой-то странной причине последние несколько пакетов близкой последовательности повторно передаются. Шаблон есть в ссылке cloudshark, но для потомков вот краткое изложение:
Что-то в системе назначения ожидает 200 мс перед повторной отправкой пакета Fin / Ack. Это довольно последовательно для нескольких транзакций. Что еще более ужасно, этот шаблон реплицируется на обеих сторонах транзакции: он обнаруживается в захватах на обоих хостах. Это не так просто, как куда-то сбросить пакет Fin / Ack и повторно передать его. Или, может быть, он падает, но на уровне выше где tcpdump работает.
Задержка в 200 мс заставляет меня думать, что здесь задействован TCP Delayed Ack, но я не могу понять, почему это произошло.
Является выше tcpdump даже вещь?
Это нормальная схема подключения для систем RHEL6?
Обратите внимание, что пакет PSH / ACK в кадре № 2 вашего захвата содержит 37 байтов данных. Это не ответ на запрос FIN от 10.232.16.133. Ответ следует в кадре №3, ACK - в кадре №5.
Кажется, что сейчас происходит то, что этот последний ACK не доходит до пункта назначения, поэтому FIN / ACK, отправленный в кадре № 3, повторно передается в кадре № 6. Задержка ~ 200 мс, которую вы видите здесь, не является отложенным подтверждением, а, скорее, таймаутом повторной передачи. Вы должны иметь возможность проверить это, посмотрев на захват пакета с другой стороны соединения, где вы никогда не должны видеть последний приходящий ACK.
Если вы видите такое поведение последовательно во всех соединениях (и, возможно, в обоих направлениях), мне приходит в голову объяснение, что какой-то фильтр пакетов с сохранением состояния на пути проглатывает последний ACK.