Мы запускаем Debian с ядром 2.6.16 и включенным iptables. В системе работает настроенный HTTP-прокси, который подвергается небольшой нагрузке (отлично работает с такой же нагрузкой на других сайтах). Система состоит из 4 серверов, которым предшествует балансировщик нагрузки с виртуальным IP, которому предшествует массив из 4 машин ISA 2004, поэтому базовая топология такова:
Клиент -> ISA [1-4] -> Балансировщик нагрузки -> Наш прокси [1-4] -> Интернет
Иногда ISA отправляет нам SYN-пакет, на который не отправляется SYN-ACK. Он попытается снова через 3 секунды и в третий раз еще через 6 секунд, после чего сообщит о неработающем прокси-сервере и переключится на прямое соединение. В течение этого времени, то есть до, между и после этих 3-х SYN, приходят другие SYN-запросы от того же ISA, на которые успешно отвечают.
Об очень похожей проблеме сообщают другие (однако без решения):
Все это происходит из разновидности Linux под названием CentOS. Особенность в том, что iptables включен по умолчанию.
http://www.linuxhelpforum.com/showthread.php?t=931912&mode=linearhttp://www.centos.org/modules/newbb/viewtopic.php?topic_id=16147
Практически то же самое: но немного другое: http://www.linuxquestions.org/questions/linux-networking-3/tcp-handshake-fails-synack-ignored-by-system.-637171/
Также кажется актуальным: http://groups.google.com/group/comp.os.linux.networking/browse_thread/thread/b1c000e2d65e0034
Я подозреваю, что в этом виноват iptables, но любые дополнительные отзывы будут приветствоваться.





Посмотрите на второй параметр вызова listen, как указано в первой опубликованной вами ссылке. Это максимальное количество ожидающих (еще не принятых) подключений. Согласно справочной странице listen (2), если протокол поддерживает повторную передачу (TCP делает), запрос на соединение будет отброшен, когда очередь будет заполнена (ожидается более поздняя повторная передача, которая создаст соединение, если в очереди снова будет достаточно места. ).
Другим запросам, вероятно, повезет, и они поступят после того, как очередь немного опустеет (то есть после того, как сервер принял некоторые из ожидающих соединений).
Тогда пришел бы следующий SYN или следующий за ним - но если один останется без ответа, все три останутся без ответа. Мне сложно объяснить это просто удачей.
«... трудно объяснить глупым везением». Итак, увеличьте глубину очереди на прослушивание, и вы узнаете.
Действительно, iptables оказался виновником правила, которое отбрасывало НЕВЕРНЫЕ пакеты. Мы до сих пор не знаем наверняка, что заставило iptables счесть эти SYN недействительными (точно нет TIME_WAIT, поскольку у нас не было трафика с теми же исходными портами в течение как минимум 30 минут до отбрасывания).
Это не объясняет, что другие запросы к тому же порту выполняются успешно, а они терпят неудачу.