Логика поддержки активности HTTP-соединения [закрыто]
Я новичок в HTTP и прошу прощения, если вопрос выглядит глупо. Я не могу понять логику поддержки активности HTTP. Я изучаю подробное руководство по HTTP.
Мы отправляем несколько запросов, ответ по одному TCP-соединению ясен, но я не понимаю, как это работает с прокси. Прокси не должен пересылать заголовок keepalive (это шаг за шагом) , тогда как сервер узнает, что соединение должно быть открыто? Если сервер не знает, он отправит ответный пакет закрытия? Итак, как соединение на стороне клиента по-прежнему пересылает больше запросов по одному и тому же TCP-соединению.
Пример
клиент (10.0.0.1) --------- Прокси (1.1.1.1) ---------- (1.1.1.5) Сервер
клиент отправляет запрос с соединением: keepalive для 1.1.1.5. Прокси-сервер получает и: 1) вслепую пересылает его, если HTTP / 1.0 2) Прокси-сервер отправляет соединение 1.1.1.1 -> 1.1.1.5 к серверу, отправлено ли соединение: keepalive или нет?
Он говорит, что прокси не кэширует и не пересылает заголовки соединения и keepalive, тогда как сервер узнает, что он должен держать его открытым или закрывать.
Пожалуйста, помогите ....Я немного заблудился здесь
Последовательный переход означает, что прокси может изменять заголовок по своему усмотрению и немедленно его интерпретировать; заголовок не должен пересылаться без интерпретации.
По умолчанию для HTTP / 1.1 используются постоянные соединения, если одна из сторон соединения (клиент-прокси или прокси-сервер) не указывает Соединение: закрыть заголовок . Этот заголовок зависит от соединения и не имеет отношения к другому соединению в цикле клиент-прокси-сервер.
Таким образом, прокси может установить постоянное соединение с исходным сервером или указать Соединение: закрыть независимо от чего клиент указал в Connection . Точно так же, если исходный сервер отправляет Connection: close , прокси не требуется пересылать этот заголовок обратно клиенту, который затем может делать дальнейшие запросы на все еще действующем соединении клиент-прокси.
Единственное, что запрещено, - это отправка Keep-Alive на прокси-сервер http / 1.0, поскольку они не обязаны интерпретировать Keep-Alive и Соединение
RFC 2616 раздел 13.5.1 определяет все заголовки, которые должны обрабатываться поэтапно (не кэшироваться, не пересылаться).