Почему HTTP / 2 выполняет мультиплексирование, хотя tcp делает то же самое?

TCP не мультиплексируется. TCP - это просто гарантированный поток сообщений (т.е. пропущенные пакеты повторно запрашиваются, а поток TCP в основном временно блокируется, пока это происходит).

TCP, как протокол на основе пакетов, может использоваться для мультиплексных соединений, если протокол приложения более высокого уровня (например, HTTP) позволяет отправлять несколько сообщений. К сожалению, HTTP / 1.1 не позволяет этого: как только сообщение HTTP / 1.1 отправлено, никакое другое сообщение не может быть отправлено по этому соединению, пока это сообщение не будет возвращено полностью (игнорируя плохо поддерживаемую концепцию конвейерной обработки). Это означает, что HTTP / 1.1 в основном синхронный, и, если не используется полная пропускная способность и другие сообщения HTTP помещены в очередь, то он тратит впустую любую дополнительную емкость, которая может быть использована в базовом TCP-соединении.

Чтобы обойти это, можно открыть больше TCP-соединений, что в основном позволяет HTTP / 1.1 действовать как (ограниченный) мультиплексированный протокол. Если бы полоса пропускания сети была полностью использована, то эти дополнительные соединения не добавили бы никакой пользы - это факт, что пропускная способность есть, а другие TCP-соединения используются не полностью, что означает, что это имеет смысл.

Таким образом, HTTP / 2 добавляет к протоколу мультиплексирование, позволяющее использовать одно TCP-соединение для нескольких HTTP-запросов в полете.

Это достигается путем изменения текстового протокола HTTP / 1.1 на двоичный протокол на основе пакетов. Они могут выглядеть как пакеты TCP, но на самом деле это не актуально (точно так же, как утверждение, что TCP похож на IP, потому что он основан на пакетах, не имеет значения). Разделение сообщений на пакеты - действительно единственный способ позволить нескольким сообщениям быть в движении одновременно.

HTTP / 2 также добавляет концепцию потоков, так что пакеты могут принадлежать разным запросам - TCP не имеет такой концепции - и это то, что действительно делает HTTP / 2 мультиплексированным.

Фактически, поскольку TCP не позволяет использовать отдельные независимые потоки (т.е. мультиплексирование) и поскольку это гарантировано, это фактически создает новую проблему, когда один отброшенный пакет TCP удерживает все HTTP / 2. потоков в этом соединении, несмотря на то, что действительно должен быть затронут только один поток, а другие потоки должны иметь возможность продолжать работу, несмотря на это. Это может даже замедлить работу HTTP / 2 в определенных условиях. Google экспериментирует с переходом от TCP к QUIC, чтобы решить эту проблему.

Подробнее о том, что означает мультиплексирование в HTTP / 2 (и почему это хорошее улучшение!), Читайте в моем ответе здесь: Что означает мультиплексирование в HTTP / 2

TCP не выполняет мультиплексирование. Сегменты TCP просто означают, что (одиночный) поток данных разбивается на части, которые могут быть отправлены в IP-пакетах. Каждый сегмент TCP идентифицируется только смещением потока (порядковым номером), а не каким-либо полезным способом идентификации отдельных потоков. (Мы проигнорируем редко используемую вещь Urgent Pointer.)

Итак, чтобы выполнить мультиплексирование, вам нужно что-то поставить поверх TCP. Что делает HTTP / 2.

HTTP и HTTP / 2 являются протоколами уровня приложений, которые должны использовать протокол более низкого уровня, такой как TCP, для фактического общения в Интернете. Протокол Интернета - это обычно TCP через IP через Ethernet.

Выглядит это так:

Как видите, HTTP находится выше TCP. Ниже TCP - IP. Один из основных протоколов Интернета. Сам IP имеет дело с пакетами, которые коммутируются / мультиплексируются. Думаю, отсюда вы можете подумать, что TCP мультиплексирован, но это не так. Думайте о TCP-соединении как о туннеле с одной полосой движения, по которому никто не может проехать. Допустим, у него по одной полосе в каждом направлении. Вот как будет выглядеть TCP-соединение. Туннель, в который вы помещаете данные в один конец, а они выходят из другого в том же порядке, в котором они входили. Это TCP. Как видите, на этом нет мультиплексирования. Однако TCP действительно обеспечивает надежный протокол соединения, для которого другие протоколы могут быть построены поверх, например, HTTP. А для HTTP важна надежность.

HTTP 1.1 - это просто протокол ответа на запрос. Но, как вы понимаете, это не мультиплексирование. Таким образом, разрешайте только один невыполненный запрос за раз и нужно отправлять весь ответ на каждый запрос за раз. Раньше браузеры обходили это ограничение, создавая несколько TCP-соединений (туннелей) с сервером, с помощью которого можно было делать больше запросов.

HTTP 2 фактически снова разделяет данные и позволяет мультиплексировать по одному соединению, так что не нужно создавать никаких дополнительных соединений. Это означает, что сервер может начать обслуживать несколько запросов и мультиплексировать ответы, чтобы браузер мог получать изображения, страницы и другие ресурсы одновременно, а не по одному.

Надеюсь, что это проясняет.