Включает ли HTTP как протокол какой-либо механизм гарантирования информации?

344
Zach Smith

Я задал этот вопрос на networkengineering.stackexchange, не понимая, что любые протоколы поверх TCP были не по теме (то есть, что там обсуждаются только уровни OSI 4 и ниже).

Вопрос в следующем:

Поскольку HTTP реализован поверх TCP, а TCP без потерь, включает ли HTTP какую-либо информацию для сборки пакетов?

Я полагаю, что после завершения HTTP-запроса вы можете просто предположить, что информация HTTP завершена (поскольку вся последовательность TCP-пакетов, используемых для передачи HTTP, гарантированно будет упорядочена и завершена).

Это предположение верно?

Быстрый поиск в Google показывает, что уровень 4 OSI имеет дело именно с сквозными соединениями и надежностью, что позволяет мне понять, что HTTP-пакеты НЕ требуют каких-либо средств проверки целостности, поскольку они повторно собираются. то есть, что в конце сетевой передачи HTTP-пакет будет полностью и правильно собран, если сеанс TCP завершен без ошибок.

Это правильно?

0

1 ответ на вопрос

3
grawity

Да, HTTP / 1.x не включает в себя какой-либо механизм повторной сборки / повторной доставки пакетов. Он ожидает, что транспортный уровень (обычно TCP или QUIC) предоставит его, как видно из RFC 7230, раздел 6 :

6. Управление подключением

Обмен сообщениями HTTP не зависит от базового протокола (ов) транспортного или сеансового уровня. HTTP предполагает только надежный транспорт с доставкой запросов по порядку и соответствующей доставкой ответов по порядку.

Тем не менее, HTTP / 1.x делает себя дополнительные механизмы для определения, когда ответ завершен . Это необходимо, потому что HTTP / 1.x поддерживает повторное использование соединения, и одно и то же основное TCP-соединение может использоваться для нескольких пар запрос / ответ. (И, конечно, TCP не имеет понятия об отдельных сообщениях.)

Те, кто использует «Connection: close» (по умолчанию в HTTP / 1.0), могут просто предположить, что чисто закрытое TCP-соединение указывает на конец ответа. Однако клиенты, использующие «Connection: keep-alive» (по умолчанию в HTTP / 1.1) ожидают, что ответ будет иметь

  1. заголовок «Content-Length:», если длина ответа определена и известна, или
  2. чанк нулевой длины, если ответ имеет неопределенную длину и использует «Transfer-Encoding: chunked».

То же самое относится и к HTTP / 2 по TCP и даже по HTTP через QUIC.

Похожие вопросы