Мультиплексирование HTTP2 использует одно и то же TCP-соединение, тем самым удаляя время соединения с одним и тем же хостом.
Но с HTTP2 Server Push есть какие-либо значительные преимущества в производительности, за исключением времени, которое требуется для мультиплексирования HTTP2 при запросе каждого ресурса.
Я провел презентацию об этом, которую вы можете найти здесь.
В частности, демонстрация (начиная с 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 server push экономит за одну поездку туда и обратно. Поэтому, когда вы запрашиваете веб-страницу, она отправляет и HTML, и CSS, необходимые для отрисовки страницы, поскольку сервер знает, что вам понадобится CSS, поскольку бессмысленно просто отправлять вам HTML, ожидая, пока ваш веб-браузер получит его, проанализирует его, см. ему нужен CSS, он запрашивает файл CSS и ждет его загрузки.
Я не уверен, подразумеваете ли вы, что время прохождения туда и обратно настолько мало, что есть небольшой выигрыш в HTTP / 2 server push, потому что теперь нет задержки при запросе файла из-за мультиплексирования HTTP / 2? Если это не так - можно добиться значительных успехов в продвижении ресурсов, особенно в блокировке ресурсов, таких как CSS, которых браузер будет ждать, прежде чем рисовать что-то на экране. Хотя мультиплексирование уменьшает задержку при отправке запроса, оно не уменьшает задержку при передаче запроса на сервер, теперь сервер отвечает на это и отправляет его обратно. Хотя они кажутся маленькими, они заметны и замедляют работу сайта.
Итак, да, в настоящее время основной выигрыш для HTTP / 2 Server Push заключается в сокращении этого времени приема-передачи (в основном до нуля для ключевых ресурсов).
Однако мы находимся в зачаточном состоянии этого, и есть потенциальные другие применения для повышения производительности или по другим причинам. Например, вы можете использовать это как способ приоритизации контента, чтобы важное изображение могло быть отправлено раньше, когда без этого браузер, скорее всего, сначала запросит CSS и Javascript и оставит изображения на потом. Server Push также может свести на нет необходимость встроенного CSS (который раздувает страницы копиями таблиц стилей и может потребовать Javascript для последующей загрузки правильного файла CSS) - еще один обходной путь HTTP / 1.1 для повышения производительности. Думаю, будет очень интересно посмотреть, что произойдет с HTTP / 2 Server Push в ближайшие годы.
Сказав это, все еще существуют серьезные проблемы с HTTP / 2 server push. И что наиболее важно, как предотвратить трату пропускной способности из-за перенаправления ресурсов, которые браузер уже кэшировал? Вероятно, для этого будет добавлен дайджест HTTP-заголовка, но он все еще обсуждается. Что приводит к тому, как наилучшим образом реализовать HTTP / 2 Server Push - для веб-браузеров, веб-серверов и веб-разработчиков? В спецификации HTTP / 2 немного неясно, как это должно быть реализовано, поэтому остается вплоть до различных веб-серверов, в частности, предоставляющих различные методы для передачи серверу сигнала о необходимости продвижения ресурса.
Как я уже сказал, я думаю, что это одна из частей HTTP / 2, которая может привести к очень интересным приложениям. Мы живем в интересные времена...
