Я использую программу Java для размещения некоторых XML-данных с удаленного клиентского компьютера на один из наших серверов. Я проверил отдельные компоненты всей системы самостоятельно и выяснил, что:
- Клиент может успешно получить ответ на запрос GET на тот же сервер. Таким образом, проблемы, связанные с разрешением имен, могут быть исключены.
- Код клиента в других сетях может отправлять данные на наш сервер. Итак, код сервера работает нормально.
- Попытка отправить те же данные на другой сервер с одного и того же клиента успешна. Более того, системы в других сетях работают под управлением той же версии клиента. Итак, клиентский код тоже работает.
- Я попытался опубликовать файл XML через CURL, используя:
curl --header 'content-type: text/xml;charset=UTF-8' --data @5.xml -X POST http://myserver.com/updates
но это тоже зависло. Итак, я пришел к выводу, что проблема не в части Java, а в самой сети.
- Выполнение netstat -ntavp показывает следующий вывод:
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp6 0 6250 192.168.1.50:32771 www.xxx.yyy.zzz:80 ESTABLISHED
И клиентская система долгое время остается в этом состоянии, показывая несколько тысяч байтов в очереди на отправку. В то же время я проверил журнал сервера, и там нет ни одного байта, ожидающего чтения. Состояние также отображается как ESTABLISHED, и поэтому я должен сделать вывод, что рукопожатие TCP прошло успешно. Я вроде застрял здесь.
Куда еще я могу обратиться, чтобы узнать, что является причиной этой проблемы? Операционная система на клиенте и сервере - Ubuntu 10.04
.
Обновление:
Видимо, проблема не ограничивается сообщениями HTTP. Я поместил XML-часть запроса в файл и попытался скопировать ее с помощью FTP и SCP на сервер. Обе эти попытки также провалились. Итак, текущая ситуация такова:
- Клиент может отправлять запросы и файлы на другие серверы.
- Сервер может обрабатывать HTTP-запросы и загрузки файлов от других клиентов.
- Файлы фактически передаются на сервер с клиента, но соединение, похоже, не закрывается.
- Я перехватил пакеты на сервере с помощью tcpdump и обнаружил, что контрольные суммы для некоторых пакетов, исходящих с сервера, были неверными.
Обновление 2
Пожалуйста, не обращайте внимания на обновление контрольных сумм, когда я наткнулся на http://www.ethereal.com/faq.html#q11.1 и проверил, что клиент действительно получает TCP-пакеты с правильной контрольной суммой.