Что может привести к тому, что TCP/IP будет отбрасывать пакеты без разрыва соединения?

Вы абсолютно уверены, что сервер успешно отправил ответ клиентам, которые, похоже, отказали? Под этим я подразумеваю, что сервер отправил ответ, и клиент подтвердил этот ответ обратно на сервер. Вы должны увидеть это, используя wireshark на стороне сервера. Если вы уверены, что это произошло на стороне сервера, а клиент по-прежнему ничего не видит, вам нужно смотреть дальше по цепочке от сервера. Используются ли какие-либо прокси/обратные прокси-серверы или NAT?

Транспорт TCP считается надежным протоколом, но он не гарантирует доставку. Стек TCP/IP вашей ОС будет очень стараться передать пакеты на другой конец, используя повторную передачу TCP. Вы должны увидеть это в wirehark на стороне сервера, если это происходит. Если вы видите чрезмерные повторные передачи TCP, обычно это проблема сетевой инфраструктуры, то есть плохое или неправильно настроенное оборудование/интерфейсы. Повторные передачи TCP отлично работают при коротких прерываниях сети, но плохо работают в сети с более длительными прерываниями. Это связано с тем, что стек TCP/IP будет отправлять повторные передачи только после истечения таймера. Этот таймер обычно удваивается после каждой неудачной повторной передачи. Это сделано для того, чтобы избежать переполнения и без того проблемной сети повторными передачами. Как вы можете себе представить, это обычно вызывает у приложений всевозможные проблемы с тайм-аутом.

В зависимости от топологии вашей сети вам также может понадобиться разместить probes/wireshark/tcpdump в других промежуточных местах в сети. Вероятно, потребуется некоторое время, чтобы выяснить, куда ушли пакеты.

На вашем месте я бы продолжал отслеживать с помощью wireshark на всех концах, пока проблема не возникнет снова. Скорее всего будет. Но, похоже, вы в конечном итоге обнаружите то, о чем уже упоминали, — ненадежное оборудование. Если об исправлении ненадежного оборудования не может быть и речи, вам может потребоваться просто создать дополнительные тайм-ауты на уровне приложения и повторные попытки, чтобы попытаться решить проблему в программном обеспечении. Похоже, вы начали идти по этому пути.

Я не видел этого как такового, но я видел аналогичные проблемы с большими дейтаграммами UDP, вызывающими фрагментацию IP, что приводит к перегрузке и, в конечном итоге, к потере кадров Ethernet. Поскольку это TCP/IP, я не ожидаю, что фрагментация IP будет большой проблемой, поскольку это протокол на основе потоков.

Я замечу одну вещь: TCP не гарантирует доставку! Не может. Это гарантирует, что если вы отправите байт A, за которым следует байт B, то вы никогда не получите байт B до тех пор, пока не получите байт А.

С учетом сказанного я бы подключил клиентскую машину и машину мониторинга к концентратору. Запустите Wireshark на машине мониторинга, и вы сможете увидеть, что происходит. Я столкнулся с проблемами, связанными как с обработкой пробелов между HTTP-запросами, так и с неправильными размерами блоков HTTP. Обе проблемы были связаны с написанным вручную стеком HTTP, поэтому это проблема только в том случае, если вы используете ненадежный стек.

Если вы забудете сбросить или закрыть сокет на стороне хоста, это может периодически иметь такой эффект для коротких ответов в зависимости от времени, на которое может повлиять наличие любого механизма мониторинга.

В частности, если забыть закрыть, сокет останется висящим до тех пор, пока сборщик мусора не восстановит его и не вызовет finalize().

Если вы используете длительно работающие GET, вы должны установить тайм-аут на стороне клиента в два раза больше, чем тайм-аут сервера, как вы обнаружили.

В TCP, где клиент отправляет сообщение и ожидает ответа, если сервер выйдет из строя и перезапустится (скажем, для примеров), тогда клиент все равно будет ждать в сокете, чтобы получить ответ от сервера еще сервер больше не слушает этот сокет.

Клиент обнаружит, что сокет закрыт на стороне сервера, только когда он отправит больше данных в этот сокет, а сервер отклонит эти новые данные и закроет сокет.

Вот почему у вас должны быть тайм-ауты на стороне клиента для запросов.

Но поскольку ваш сервер не дает сбоев, если сервер был многопоточным, а сокет потока для этого клиента закрыт, но в это время (минуты продолжительности) у клиента произошел сбой подключения, то рукопожатие конечного сокета может быть потеряно, и поскольку вы не отправляете больше данных на сервер от клиента, ваш клиент снова остается висящим. Это будет связано с вашим наблюдением за ненадежным соединением.

Могут ли на этих компьютерах быть установлены вирусы/вредоносные программы? При использовании wireshark устанавливается winpcap (http://www.winpcap.org/), который может переопределять изменения, внесенные созданное вредоносное ПО (или вредоносное ПО может просто обнаружить, что за ним наблюдают, и не предпринимать никаких подозрительных действий).

Если вы теряете данные, скорее всего, это связано с программной ошибкой либо в библиотеке чтения, либо в библиотеке записи.