WikiDer > Постоянное соединение HTTP - Википедия

HTTP постоянное соединение, также называемый HTTP keep-alive, или же Повторное использование HTTP-соединения, идея использования одного TCP соединение для отправки и получения нескольких HTTP-запросы/ response, в отличие от открытия нового соединения для каждой пары запрос / ответ. Новее HTTP / 2 Протокол использует ту же идею и развивает ее, позволяя мультиплексировать несколько одновременных запросов / ответов через одно соединение.

Операция

HTTP 1.0

В HTTP 1.0 соединения не считаются постоянными, если не включен заголовок keep-alive,^[1] хотя нет официальной спецификации того, как работает keepalive. По сути, это было добавлено к существующему протоколу. Если клиент поддерживает keep-alive, он добавляет к запросу дополнительный заголовок:

Подключение: keep-alive

Затем, когда сервер получает этот запрос и генерирует ответ, он также добавляет заголовок к ответу:

Подключение: keep-alive

После этого соединение не разрывается, а остается открытым. Когда клиент отправляет другой запрос, он использует то же соединение. Это будет продолжаться до тех пор, пока клиент или сервер не решат, что диалог завершен, и один из них не разорвет соединение.

HTTP 1.1

В HTTP 1.1 все соединения считаются постоянными, если не указано иное.^[2] Постоянные соединения HTTP не используют отдельные сообщения поддержки активности, они просто позволяют нескольким запросам использовать одно соединение. Однако время ожидания соединения по умолчанию для Apache httpd 1.3 и 2.0 составляет всего 15 секунд.^[3][4] и всего 5 секунд для Apache httpd 2.2 и выше.^[5][6] Преимущество короткого тайм-аута заключается в возможности быстро доставить несколько компонентов веб-страницы, не потребляя при этом ресурсов для запуска нескольких серверных процессов или потоков слишком долго.^[7]

Keepalive с кодирование передачи по частям

Keepalive затрудняет для клиента определение того, где заканчивается один ответ и начинается следующий, особенно во время конвейерной операции HTTP.^[8] Это серьезная проблема, когда Content-Length нельзя использовать из-за потоковой передачи.^[9] Чтобы решить эту проблему, HTTP 1.1 представил кодирование передачи по частям что определяет последний кусок кусочек.^[10] В последний кусок бит устанавливается в конце каждого ответа, чтобы клиент знал, где начинается следующий ответ.

Преимущества

• Уменьшенный задержка в последующих запросах (нет подтверждение связи).
• Уменьшенный ЦПУ использования и обратных поездок из-за меньшего количества новых подключений и Рукопожатия TLS.
• Позволяет Конвейерная обработка HTTP запросов и ответов.
• Уменьшенный перегрузка сети (меньше TCP-соединения).
• Об ошибках можно сообщать без штрафа за закрытие TCP-соединения.

В соответствии с RFC 7230, раздел 6.4, «клиент должен ограничить количество одновременных открытых подключений, которые он поддерживает с данным сервером». Предыдущая версия спецификации HTTP / 1.1 заявленные конкретные максимальные значения но по словам RFC 7230 «это оказалось непрактичным для многих приложений ... вместо этого ... быть консервативным при открытии нескольких соединений». Эти рекомендации предназначены для уменьшения времени ответа HTTP и предотвращения перегрузки. Если конвейерная обработка HTTP реализована правильно, дополнительные соединения не принесут выигрыша в производительности, а дополнительные соединения могут вызвать проблемы с перегрузкой.^[11]

Недостатки

Если клиент не закроет соединение после получения всех необходимых ему данных, ресурсы, необходимые для поддержания соединения на сервере, будут недоступны для других клиентов. Насколько это влияет на доступность сервера и как долго ресурсы недоступны, зависит от архитектуры и конфигурации сервера.

Также состояние гонки может произойти, когда клиент отправляет запрос на сервер в то же время, когда сервер закрывает TCP-соединение.^[12] Сервер должен отправить клиенту код состояния 408 Request Timeout непосредственно перед закрытием соединения. Когда клиент получает код состояния 408, после отправки запроса он может открыть новое соединение с сервером и повторно отправить запрос.^[13] Не все клиенты будут повторно отправлять запрос, и многие из них сделают это только в том случае, если запрос имеет идемпотентный метод HTTP.

Использование в веб-браузерах

Схема множественного и постоянного подключения.

Все современные веб-браузеры, включая Гугл Хром, Fire Fox, Internet Explorer (с 4.01), Опера (с 4.0)^[14] и Сафари использовать постоянные соединения.

По умолчанию, Internet Explorer версии 6 и 7 используют два постоянных соединения, а версия 8 - шесть.^[15] Время ожидания постоянных подключений истекает через 60 секунд бездействия, которое можно изменить через реестр Windows.^[16]

В Fire Foxможно настроить количество одновременных подключений (на сервер, на прокси, всего). Время ожидания постоянных соединений истекает через 115 секунд (1,92 минуты) бездействия, которое можно изменить в конфигурации.^[17]

Смотрите также

• Конвейерная обработка HTTP, благодаря чему можно отправлять несколько запросов, не дожидаясь ответа
• HTTP / 2, что позволяет выполнять конвейерную обработку запросов и ответов вне очереди, а также прогнозировать толкать контента до того, как он был запрошен

Рекомендации

внешняя ссылка

• Протокол передачи гипертекста (HTTP / 1.1): синтаксис и маршрутизация сообщений, управление подключениями, постоянство
• Постоянное соединение популярных браузеров (датировано)
• Поддержка Apache HTTPD Keep-Alive
• Влияние HTTP / 1.1, CSS1 и PNG на производительность сети