Назад | Перейти на главную страницу

Несогласованная длина тайм-аута TCP-соединения в Linux

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

В качестве теста был настроен простой сценарий, который просто пытается подключиться по telnet к несуществующему удаленному порту в бесконечном цикле.

При большинстве попыток подключения мы мгновенно получаем что-то вроде следующего:

telnet remoteHost 12345
Trying 192.168.1.1...
telnet: connect to address 192.168.1.1: Connection refused

Однако с довольно регулярным интервалом соединение, кажется, зависает на несколько секунд, прежде чем перейти к следующей попытке подключения, которая снова станет почти мгновенной. Просто будет сидеть на этапе "Примерка":

telnet remoteHost 12345
Trying 192.168.1.1...

Обычно это не было бы такой большой проблемой, но в приложении, которое выполняет тысячи операций каждую секунду между ~ 100 серверами, эти случайные замедления начинают становиться проблемой. Кто-нибудь знает, что движет этой длиной или временем или почему это может быть непоследовательным?

Если это важно, вот некоторая системная информация:

uname -r           -> 2.6.16.60-0.39.3-smp
uname -m           -> x86_64
cat /etc/*-release -> SUSE Linux Enterprise Server 10 (x86_64)
                     VERSION = 10
                     PATCHLEVEL = 2

Похоже, ваша техника сканирования напоминает сканирование портов, поэтому возможно ли, что серверы настроены на отбрасывание SYN-пакетов в ответ на предполагаемое сканирование порта? Любые настройки брандмауэра на серверах, аналогичные тем, что указаны в №8 из 10 правил iptables, которые помогут защитить ваш Linux-сервер?