Настройки: это машина с четырьмя процессорами, достаточно мощная, совсем не загруженная (ни ЦП, ни сеть), клиент - 64-битная Windows Server 2008, сервер - Linux.
У меня есть четыре потока, которые запускают HTTP-запросы одновременно. Соединения инициируются с IP-адресами X, X, Y, Z (два соединения с X, одно с Y и Z). Все цели находятся в локальной сети.
Я вижу, что соединения с X, Y и Z формируются (SYN-SYN / ACK), а второе соединение с X выполняется с задержкой 100 мс. Это означает, что машина не отправляет второй SYN в X в течение полных 100 мс.
Может ли это быть связано с Механизм разгрузки TCP? Что еще может быть причиной этой задержки?
редактировать - Другой подозреваемый - это клиентский код - он написан на Java, использует HttpURLConnection.
Сетевая трассировка (например, Wireshark) покажет, ожидает ли задержка ответа. Это также указывало бы на другие «обходные пути», такие как предложение о DNS. Похоже, вы уже это сделали, но вы не сказали.
Другая возможность: ограничение Windows XP SP2 на исходящие полуоткрытые соединения, которое по умолчанию равно 10. Я не уверен, как вы видите, сколько соединений находится в этом состоянии, но я считаю, что если сработает этот ограничитель скорости, он покажет вверх в журналах ошибок.
Должен ли он выполнять поиск в DNS для каждого запроса? Это ограничивает скорость?
Первоначальное соединение проходит нормально, но в очередь ставится второе соединение. Я бы рассмотрел реализацию клиента в программном обеспечении, я не знаю, внесли ли более свежие JDK больше изменений, но раньше было так, что даже если вы сделали отдельные HttpUrlConnections, базовый обработчик протокола все равно повторно использовал бы соединение сокета.
Вы должны зарегистрироваться в Переполнение стека и посмотрите, сталкивались ли некоторые из них с этой проблемой раньше.
Хорошо, есть МНОГО возможных мест, где что-то может пойти не так. Вы упомянули механизм разгрузки TCP, и это разумное подозрение (особенно если у вас есть сетевые адаптеры Broadcom), поэтому давайте исключим его и отключим (обратитесь к документации по этому поводу).
После этого вы хотите начать сокращать количество других возможных кандидатов, поэтому обратите внимание на коммутаторы, сетевые кабели и так далее. Если можете, подключите источник к цели через кроссовер и посмотрите, сможете ли вы воспроизвести его там.
Также стоит попробовать, дорогой старый ping - Судя по его звукам, вы должны иметь возможность воспроизвести ненормальное поведение с 4 одновременными пингами.
Но все сводится к тому, что нет смысла подозревать что-нибудь на этой ранней стадии, поскольку существует слишком много мест, где что-то может пойти не так (включая ваше приложение).
Вы проверили настройки брандмауэра? Возможно, что-то в настройках брандмауэра ограничивает скорость соединения.
Есть ли у вас какие-то специальные настройки sysctl для сервера? Есть много мелких настроек, которые можно сделать для работы в сети в sysctl.
Вы проверяли на разных серверах / клиентах? Это помогает изолировать причину проблемы - будь то конкретный сервер, клиент или и то, и другое.