Отношения между состоянием TCP активная TIME_WAIT & HTTP
Каковы отношения между активным на Запросе HTTP и сокетом tcp в TIME_WAIT - они должны коррелироваться?
Кроме того, если система и настройки веб-сервера выровненные, например. server.max-keep-alive-idle = 60? Согласно тому, Как сократить количество сокетов в TIME_WAIT? в Linux состояние TIME_WAIT является hardcoded в 60 секунд (по крайней мере, для значений Ubuntu/Debain Linux).
В lighttpd значение по умолчанию server.max-keep-alive-idle = 5 и они рекомендуют еще ниже для высокой загрузки. Это кажется отходами для закрытия запроса HTTP после 5 секунд, если сокет tcp доступен - предполагающий, конечно, что установка net.ipv4.tcp_tw_reuse = 1 делает то, что это говорит относительно олова.
Этот связанный вопрос - Как tcp поддерживает соединение? [закрытый] затрагивает проблему, но не полностью отвечает на это для меня.
TCP - это уровень 4, HTTP уровень 7.
В HTTP 1.0 HTTP Keep-Alive используется на уровне 7 для имитации постоянных соединений с использованием заголовка Connection . 1258] В HTTP 1.1 соединения считаются постоянными по умолчанию, а затем полагаются на TCP только для выполнения этой работы. Запросы могут быть конвейеризованы в одном и том же TCP-соединении, тогда одна сторона установит Connection: close в последнем запросе или заголовках ответа, чтобы обе стороны знали, что обмен HTTP-запросами невозможен, и тогда соединение будет закрыто.
Обычно в случае веб-сервера состояние TIME_WAIT будет состоянием, после которого после принятия решения об активном закрытии соединения он получил клиентский пакет FIN и отправляет последний ACK обратно при четырехстороннем удалении. После этого он ждет 2 * MSL : это способ убедиться, что соединение закрыто. Отсюда скомпилированные в ядре 60s . Таким образом, мы уверены, что не будем получать в новом соединении, используя тот же самый кортеж из 4х пакетов, неупорядоченных в результате предыдущего соединения.
Вы не хотите изменять его .
С другой стороны server.max-keep-alive-idle - это тайм-аут, по истечении которого соединение ESTABLISHED будет считаться бездействующим, если не поступит HTTP-запрос, и будет активно закрыто веб-сервер. Когда это решение будет принято, как вы теперь понимаете, произойдет отключение TCP.
Будьте очень осторожны с tcp_tw_recycle , если ваши посетители приходят из-за широкой сети с NAT, это может привести к несколько TCP-соединений с одними и теми же четырьмя кортежами, имеющих неупорядоченные временные метки, что приводит к молчаливому отбрасыванию попыток клиентских подключений на стороне сервера.
Итак, лучший вариант - настроить параметр, который вы видели в lighttpd. В масштабе всей системы вы можете безопасно понизить состояние FIN_WAIT2 и поднять сегменты для сокетов в состоянии TIME_WAIT с помощью net.ipv4.tcp_fin_timeout и net.ipv4. tcp_max_tw_buckets .