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

Могу ли я заставить сеанс TCP / IP работать менее 60 секунд?

Наш сервер перегружен сессиями 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. Непонятно, что вы имеете в виду под "занимает сокет" - сервер уже давно должен closed сокет в этой точке. Система должна быть способна обрабатывать десятки тысяч соединений в состоянии TIME_WAIT.