HTTP постоянное соединение с конвейером. Как несколько файлов делятся на сегменты по TCP

Question

У меня очень простой вопрос, ответ на который кажется невозможным, как я хочу. Предположим, у меня есть tcp-соединение между клиентом и сервером, и клиент сделал запрос на страницу, которая содержит 2 файла. Мы предполагаем, что соединение http сохраняется и с конвейером, поэтому 2 запроса на файлы отправляются в одном сегменте tcp от клиента к серверу. Теперь предположим, что файлы, которые хочет клиент, имеют размер 4500 байт и 3000 байт, а MSS tcp составляет 1460 байт, потому что мы используем ethernet, поэтому первый файл должен быть разделен на 3 сегмента по 1460 и один из 120, а второй - разделен на 2 сегмента по 1460 и один из 80 (по крайней мере, так будет, если tcp отправит только один файл). В этих ситуациях сколько сегментов отправит tcp? Первые 4 из первого файла и 3 из второго файла, или он сначала «объединит» файл 2 вместе, а затем отправит этот файл разделенным? Во втором случае у нас будет файл размером 7500, 5 MSS + 200 байт.

Я нигде не могу найти информацию об этой проблеме. Итак, в конце мой вопрос, как шаблон сегментов, отправляемых по TCP:

3 MSS -> 120 байтов -> 2 MSS -> 80 байтов Или же 5 MSS -> 200 байтов

Я не могу понять, как tcp может отправлять сегмент, содержащий байты 2 разных файлов.

Answer 1

Я не могу понять, как tcp может отправить сегмент, содержащий байты 2 разных файлов.

С точки зрения пользовательского приложения TCP - это просто поток байтов, и ничего не известно о том, как эти байты доставлялись в пакетах. В самом TCP нет представления о файлах или HTTP-запросах и ответах. Различие между ними выполняется на уровне приложения, т.е. в данном случае на уровне протокола HTTP.

Протокол HTTP определяет, что каждый запрос и ответ состоит из заголовка и тела, которые различаются пустой строкой. Размер тела или частей тела известен заранее, то есть либо указан в заголовке (с использованием поля content-length), либо перед каждым фрагментом тела (с transfer-encoding: chunked). Таким образом, конец тела и, следовательно, начало следующего запроса / ответа может быть определен синтаксическим анализатором протокола HTTP. И совершенно неважно, как эти данные пакетируются на нижележащем уровне TCP.