Из Википедии, свободной энциклопедии
  (Перенаправлено с постоянных HTTP-соединений )
Перейти к навигации Перейти к поиску
HTTP
Способы запроса
Поля заголовка
Коды состояния
Методы управления безопасным доступом
Уязвимости безопасности

Постоянное соединение HTTP , также называемое HTTP keep-alive или повторное использование HTTP-соединения , представляет собой идею использования одного TCP- соединения для отправки и получения нескольких HTTP-запросов / ответов, в отличие от открытия нового соединения для каждой отдельной пары запрос / ответ. Более новый протокол 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-соединения не используют отдельные сообщения keepalive, они просто позволяют нескольким запросам использовать одно соединение. Однако время ожидания соединения по умолчанию для 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 было введено кодирование передачи по частям , определяющее last-chunkбит. [10]last-chunk бит установлен в конце каждого ответа , так что клиент знает , где начинается следующий ответ.

Преимущества [ править ]

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

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

Недостатки [ править ]

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

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

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

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

Все современные веб-браузеры, включая Google Chrome , Firefox , Internet Explorer (с 4.01), Opera (с 4.0) [14] и Safari, используют постоянные соединения.

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

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

См. Также [ править ]

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

Ссылки [ править ]

  1. ^ «Руководство TCP / IP - Установление, управление и завершение постоянного соединения HTTP» . www.tcpipguide.com . Архивировано из оригинала на 2017-05-21 . Проверено 31 декабря 2017 .
  2. ^ Протокол передачи гипертекста (HTTP / 1.1): синтаксис сообщений и маршрутизация, постоянство
  3. ^ Apache HTTP Server 1.3 - Директива KeepAliveTimeout
  4. ^ Apache HTTP Server 2.0 - Директива KeepAliveTimeout
  5. ^ Apache HTTP Server 2.2 - Директива KeepAliveTimeout
  6. ^ Apache HTTP Server 2.4 - Директива KeepAliveTimeout
  7. ^ Несколько (вики). «Httpd / KeepAlive» . Докфорж . Архивировано из оригинального 6 -го января 2010 года . Проверено 30 января 2010 .
  8. ^ «HTTP: Каковы отношения между конвейерной обработкой, сохранением активности и событиями, отправленными сервером» .
  9. ^ «HTTP Streaming (или Chunked vs Store & Forward)» .
  10. ^ «Разделенное кодирование передачи» .
  11. ^ Нильссен, Фристик Хенрик; Геттис, Джеймс; Бэрд-Смит, Ансельм; Прюдоммо, Эрик; Виум Ли, Хокон; Лилли, Крис (октябрь 1997 г.), «Влияние HTTP / 1.1, CSS1 и PNG на производительность сети» , Computer Communication Review , 27 (4), ISSN 0146-4833 
  12. ^ [1]
  13. ^ [2]
  14. ^ «Opera 4.0 обновляет обмен файлами: включает HTTP 1.1» . Программное обеспечение Opera. 2000-03-28 . Проверено 8 июля 2009 .
  15. ^ "IE8 ускоряет работу" . Stevesouders.com. 2008-03-10 . Проверено 17 июля 2009 .
  16. ^ «Как изменить значение тайм-аута проверки активности по умолчанию в Internet Explorer» . Microsoft. 2007-10-27 . Проверено 17 июля 2009 .
  17. ^ "Network.http.keep-alive.timeout" . Mozillazine.org . Проверено 17 июля 2009 .

Внешние ссылки [ править ]

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