Наш сервер перегружен сессиями TCP / IP, их у нас 1200-1500. Большинство из них зависают в состоянии TIME_OUT. Оказывается, соединение в состоянии TIME_OUT занимает сокет, пока не истечет 60-секундный тайм-аут.
Проблема в том, что сервер не отвечает, и многие клиенты не обслуживаются.
Я провел простой тест: загрузите XML-файл с сервера с Internet Explorer 8.0. Загрузка завершается за доли секунды. Но потом я вижу, что соединение TCP / IP зависает в состоянии TIME_OUT в течение 60 секунд.
Есть ли способ избавиться от ожидания TIME_OUT или уменьшить его, чтобы освободить сокет для новых подключений?
Я понимаю, почему соединение TCP / IP переходит в состояние TIME_OUT, но не понимаю, почему Internet Explorer не закрывает соединение после завершения загрузки файла XML.
Детали.
На нашем сервере работает веб-сервис, написанный на Perl (mod-perl). Сервис предоставляет клиентам данные о погоде. Клиент - это приложение Flash (фактически элемент управления Flash ActiveX, встроенный в приложение Windows).
ОС: Ubuntu
Параметр Apache "Keep Alive" установлен на 0
Это параметр в вашем стеке TCP. Поскольку мы не знаем, на какой платформе вы находитесь, мы не можем точно сказать, как она называется и как ее изменить.
Итак, вы используете Ubuntu. Ты можешь использовать sysctl
уменьшить net.inet.tcp.msl
значение вдвое меньше желаемого TIME_WAIT
продолжительность (в миллисекундах - см. man -S 4 tcp
), например sysctl net.inet.tcp.msl=2500
. Остерегайтесь последствий этого для блуждающих пакетов, которые могут прибыть после TIME_WAIT
срок истекает.
Я полагаю вы имеете в виду TIME_WAIT
. Пир, который инициирует активное закрытие, входит в TIME_WAIT
(см. диаграмму перехода состояний Вот), поэтому, если ваш клиент может закрыть соединение, вы переместите TIME_WAIT
к клиенту. Видеть этот ответ для более подробной информации и ссылку на хорошую статью о TIME_WAIT
проблемы и способы их решения.
Другой альтернативой, если вы не можете сделать так, чтобы клиент запускал активное закрытие, является сброс соединения, установив для задержки значение false перед его закрытием. Это вызывает RST
быть отправленным, а не FIN
.
Сервер, который не отвечает, скорее всего, не имеет ничего общего с количеством подключений в состоянии TIME_WAIT. Непонятно, что вы имеете в виду под "занимает сокет" - сервер уже давно должен close
d сокет в этой точке. Система должна быть способна обрабатывать десятки тысяч соединений в состоянии TIME_WAIT.