Будет ли тайм-аут клиента, если запрос на постоянное соединение HTTP занимает много времени?

#http #keep-alive

#http #поддерживать работоспособность

Вопрос:

Если у нас есть постоянное соединение HTTP, однако один из запросов занимает много времени (скажем, 30 секунд). Предположим, что время ожидания клиента составляет 15 секунд.

  1. Соблюдается ли тайм-аут запросов клиента при использовании через постоянное соединение?

  2. Если да, то разрывается ли соединение?

  3. Есть ли какой-либо способ избежать разрыва всего соединения и вместо этого просто установить время ожидания для этого одного конкретного запроса?

Ответ №1:

  1. Клиент может указать тайм-аут, но это зависит от конфигурации сервера для использования тайм-аута клиента или его собственной конфигурации тайм-аута. По умолчанию конфигурация тайм-аута на стороне сервера имеет больший приоритет, чем конфигурация тайм-аута клиента.
  2. НЕТ
  3. Для одного конкретного запроса с другой конфигурацией тайм-аута это невозможно в одном и том же соединении, но вы можете объявить другое соединение конфигурации http-клиента и использовать одно из них по умолчанию, а другое для запроса, для которого требуется гораздо большее значение тайм-аута, но они не находятся в одном и том же постоянно действующем соединении.
    Обратите внимание, что в конфигурации тайм-аута на стороне клиента у нас есть два разных типа тайм-аута
    1- Тайм-аут открытия соединения 2- Тайм-аут чтения ответа.
    Первый объявляется для открытого соединения между сервером и клиентом, а второй объявляется на то, сколько времени клиенту нужно, чтобы получить ответ на его запрос.

Комментарии:

1. что произойдет, если тайм-аут на стороне клиента (10 секунд) меньше, чем тайм-аут на стороне сервера (15 секунд)?

2. В случае, если клиент или веб-сервер имеют меньшее значение поддержания активности, это меньшее значение является ограничивающим фактором.

Ответ №2:

Это зависит от того, какой клиент вы используете и как настроен сервер. Проблема сложнее … установка keep-alive в http не позволит избежать tcp тайм-аутов на транспортном уровне, вам также нужно установить tcp тайм-аут на keep-alive , но тогда сервер может не захотеть поддерживать соединение для вас так долго, как вам хотелось бы. Для постоянных соединений лучше использовать udp вместо tcp — у него нет такого строгого контроля потока. Другое дело, что HTTP/2 вообще не имеет такого понятия, как keep-alive , поскольку все обрабатывается совершенно иначе, чем в HTTP/1 . Из HTTP / 2 RFC:

8.1.2.2. Поля заголовка, зависящие от соединения

HTTP / 2 не использует поле заголовка соединения для указания полей заголовка, относящихся к
соединению; в этом протоколе
специфичные для соединения метаданные передаются другими способами. Конечная точка НЕ ДОЛЖНА
генерировать сообщение HTTP / 2, содержащее поля заголовка для конкретного соединения
; любое сообщение, содержащее поля заголовка для конкретного соединения, ДОЛЖНО рассматриваться как искаженное (раздел 8.1.2.6).

Единственным исключением из этого является поле заголовка TE, которое МОЖЕТ
присутствовать в запросе HTTP / 2; когда это так, оно НЕ ДОЛЖНО содержать никакого
значения, кроме «trailers».

Это означает, что посреднику, преобразующему сообщение HTTP / 1.x в HTTP / 2, потребуется удалить все поля заголовка, назначенные полем заголовка
соединения, вместе с самим полем заголовка соединения
. Такие посредники ДОЛЖНЫ также удалять другие поля заголовка,
относящиеся к соединению, такие как Keep-Alive, Proxy-Connection,
Transfer-Encoding и Upgrade, даже если они не указаны в поле заголовка соединения.