Почему содержание длины требуется в случае HTTP постоянных соединений

Question

Мое понимание того, как передача данных происходит в TCP/HTTP это:

Применение слоя на стороне сервера передает некоторые данные в ТСР для отправки для клиента. Уровень tcp разбивает данные приложения на сегменты и отправляет их дальше. Уровень tcp на другом конце гарантирует, что он получит и упорядочивает все сегменты в порядке, прежде чем передавать их на свой прикладной уровень.

Теперь, in the case of non-persistent connections, сервер может просто закрыть соединение, когда он будет отправлен. Что это значит? Означает ли это, что сервер отправит сегмент FIN в конце? Таким образом, уровень tcp клиента будет в основном ждать всех сегментов до сегмента FIN, передать эти данные на верхние уровни и продолжить с завершением соединения.

In the case of persistent connections, так как соединение не закрывается сервером, сказано, что клиент не может знать, когда ему нужно закончить чтение ответа и выполнить следующий запрос. И поэтому используются заголовок content-length и chunked transfer.

Мой вопрос: «Почему мы не можем просто отправить сегмент, похожий на FIN (скажем DONE), чтобы указать, что сервер передал весь ответ». Клиент, увидев DONE, может начать со следующего запроса. В чем заключалась необходимость включения заголовка длины контента, который связан с проблемой знания длины контента заранее?

Уверен, что я что-то неправильно понял или пропустил. Пожалуйста, поправьте меня, где я ошибаюсь.

Спасибо за чтение ДО здесь :)

Answer 1

Представьте, что произойдет, если ваши данные с полезной нагрузкой HTTP содержат DONE в середине.

TCP FIN пакеты с другой стороны, отметьте FIN внутри флагов TCP Header и, таким образом, нет никакой опасности errorneously ошибочно некоторый пакет данных в качестве FIN пакета.

Answer 2

Поскольку СДЕЛАНО может произойти в теле ответа, так как не существует механизма спасения в протоколе.