время от времени приложение windows / .net игнорирует флаг tcp fin
Я столкнулся с сетевой проблемой, которую не могу решить. на некоторых компьютерах под управлением Windows 8.1 и обменивающихся данными с http-сервером linux tcp-соединения болтаются на стороне Windows, а не закрываются должным образом.
после ответа [фрагментирован на несколько, подтвержден окнами, tcp-пакетами] Linux-сервер - 10.14.11.59 - отправляет tcp-пакет, содержащий установленные флаги FIN и ACK. 
это подтверждается машиной Windows - 10.14.10.195 - с пакетом, имеющим только установленный флаг ACK. 
Linux повторно отправляет пакеты с флагами FIN и ACK несколько раз, в то время как машина Windows - по какой-то причине соединение все еще остается открытым; пакеты с флагом RST никогда не отправляются машиной Windows. 
если это произойдет, приложение Windows ждет и в конечном итоге истечет время ожидания. это происходит случайным образом где-то между 10-50% попыток.
трафик между двумя машинами не фильтруется; брандмауэры на основе хоста были отключены. чтобы избежать потенциальных проблем, я отключил разгрузку tcp в Linux и Windows. Кроме того, в Windows выполнялись следующие операции и перезагружалась машина:
netsh int tcp set global chimney=disabled
netsh int tcp set global autotuninglevel=disabled
netsh int tcp set global rss=disabled
захват пакета: Вот.
любые мысли будут оценены по достоинству!
мы выяснили, что виной всему была безопасность конечных точек eset, работающая на клиентских машинах.
недостаточно было отключить брандмауэр; но его удаление полностью решило проблему.
мои коллеги нашли описание похожей проблемы Вот; очевидно, обновление до последней версии eset также решило проблему.
Я предполагаю, что первому сегменту в вашем tcpdump предшествует FIN от клиента.
Я считаю, что это правильное поведение клиента, так как проиллюстрировано этой схемой ASCII из исходного RFC
Завершающий клиент, получив FIN,ACK с сервера сокет переходит из FIN-WAIT1 к TIME-WAIT и остается в этом состоянии в течение 2-х кратного максимального времени жизни сегмента в сети, после чего отправляет FIN назад, чтобы закрыть соединение.
Windows отменяет TIME-WAIT продолжительность с именем значения реестра TcpTimedWaitDelay, изначально реализовано со значением по умолчанию 240 секунд (по умолчанию MSL составляет 120 секунд). В Windows XP / Server 2003 и выше значение по умолчанию снижено до 120 секунд.
Я считаю, что вы можете решить эту проблему, закрыв базовый сокет на сервере, когда вы отправили ответ, но обязательно прочтите и этот ответ, примерно на тот же вопрос, но с точки зрения сервера