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

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

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

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

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

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

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

1 ответ1

3

Да, 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.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .