Мультиплексирование HTTP2 использует одно и то же соединение TCP, тем самым удаляя время соединения с тем же хостом.Есть ли существенные преимущества при работе с мультиплексированием HTTP2 по сравнению с HTTP2 Server Push?
Но с HTTP2 Server Push есть какие-либо существенные преимущества в производительности, за исключением того, что время межсетевого обмена будет выполняться при запросе каждого ресурса.
Я дал презентацию об этом, что вы можете найти here.
В частности, демонстрационная версия (начиная с 36:37) показывает преимущества, которые могут иметься при мультиплексировании, а затем путем добавления HTTP/2 Push.
Спойлер: комбинация мультиплексирования HTTP/2 и Push дает удивительные лучшие результаты в отношении HTTP/1.1.
С другой стороны, каждый случай отличается, поэтому вы должны действительно измерить свой случай. Но потенциал HTTP/2 для повышения производительности, чем HTTP/1.1, действительно большой, и многие из них (в большинстве случаев) выиграют от этого.
Я не уверен, что именно вы здесь просите, или если это хорошо подходит для StackOverflow, но попытается ответить ни на что. Если это не тот ответ, который вы ищете, пожалуйста, перефразируйте вопрос, чтобы мы могли понять, что именно вы ищете.
Вы правы в том, что HTTP/2 использует мультиплексирование, что отрицает необходимость в нескольких подключениях (а также время и ресурсы, необходимые для их настройки и управления ими). Однако это намного больше, чем это не ограничено (браузеры обычно ограничивают соединения с 4-6 на хост), а также позволяет использовать «похожие» соединения (один и тот же IP-адрес и один и тот же сертификат, но другое имя хоста) для совместного использования соединений. В основном это решает очередь ресурсов, что метод запроса/ответа HTTP/1 означает и уменьшает потребность в ограниченных множественных соединениях, которые HTTP/1 требует как обходной путь. Который также уменьшает потребность в других обходных решениях, таких как осколки, спрайт-файлы, конкатенация ... и т. Д.
И да, HTTP-сервер 2-го уровня сохраняет в одном обратном направлении. Поэтому, когда вы запрашиваете веб-страницу, он отправляет как HTML, так и CSS, необходимые для рисования страницы, поскольку сервер знает, что вам понадобится CSS, так как бессмысленно просто отправлять HTML-код, ожидая, когда ваш веб-браузер получит его, проанализирует, посмотрит он нуждается в CSS и запрашивает файл CSS и ждет его загрузки.
Я не уверен, что вы предполагаете, что время в оба конца настолько низкое, что в HTTP/2-сервере просто не получается, потому что теперь нет задержки при запросе файла из-за мультиплексирования HTTP/2 ? Если так, то это не так - есть значительные успехи в том, чтобы продвигать ресурсы, особенно блокируя ресурсы, такие как CSS, которые браузер будет ждать, прежде чем рисовать одну вещь на экране. В то время как мультиплексирование уменьшает задержку при отправке запроса, оно не уменьшает задержку при запросе, отправляемом на сервер, теперь на сервере, отвечающем на это и отправляя его обратно. Хотя эти звуки небольшие, они заметны и делают сайт медленным.
Итак, в настоящее время основной прирост для HTTP/2 Server Push заключается в сокращении времени туда и обратно (в основном до нуля для ключевых ресурсов).
Однако мы находимся в зачаточном состоянии, и есть другие потенциальные возможности использования по производительности или по другим причинам. Например, вы могли бы использовать это как способ определения приоритетности контента, поэтому важный образ можно было бы нажимать раньше, когда без этого браузер, скорее всего, сначала попросит CSS и Javascript и оставит изображения дольше. Server Push также может отрицать необходимость встроенного CSS (который раздувает страницы с копиями таблиц стилей и может потребовать Javascript для загрузки надлежащего файла CSS) - еще один HTTP/1.1 обходной путь для выполнения. Я думаю, будет очень интересно наблюдать, что происходит с HTTP/2 Server Push в ближайшие годы.
Сказать, что все еще есть серьезные проблемы с HTTP/2-сервером. Самое главное, как вы мешаете тратить пропускную способность, нажимая ресурсы, которые браузер уже кэшировал? Вероятно, для этого будет добавлен заголовок HTTP-заголовка, но все еще обсуждается. Что приводит к тому, как реализовать HTTP/2 Server Push в лучшем методе - для веб-браузеров, веб-серверов и веб-разработчиков? HTTP/2 spec немного расплывчато в отношении того, как это должно быть реализовано, что оставляет его на разных веб-серверах, в частности, предоставляя разные методы для подачи сигнала на сервер, чтобы выталкивать ресурс.
Как я уже сказал, я думаю, что это одна из частей HTTP/2, которая может привести к некоторым очень интересным приложениям. Мы живем в интересные моменты ...