Подготовлен (https://www.nginx.com/blog/nginx-1-13-9-http2-server-push/) выпуск основной ветки высокопроизводительного HTTP-сервера nginx 1.13.9 (http://nginx.org/), в котором реализован (http://nginx.org/en/CHANGES) механизм Server Push (https://www.w3.org/TR/preload/#server-push-http-2) для протокола HTTP/2. Server Push предоставляет возможность отправки ресурсов от сервера к клиенту, не дожидаясь их явного запроса (например, подобным образом можно передавать файлы CSS, скрипты и изображения, которые необходимы для отрисовки страницы).
Для отправки push-запросов используется (https://jakearchibald.com/2017/h2-push-tougher-than-i-thought/) уже установленное клиентом соединение. Т.е. клиент подключается и запрашивает определённую страницу, после этого сервер на основании своих настроек или содержимого переданного клиентом заголовка Link сам инициирует передачу определённых ресурсов через уже установленное соединение HTTP/2, не дожидаясь запроса этих ресурсов от клиента. При этом клиент может отвергнуть попытку push-отправки, вернув флаг RST_STREAM.
Переданный через push-обращение контент сохраняется на стороне клиента в специальном кэше, ассоциированном с текущим HTTP/2-соединением. Когда в процессе обработки страницы клиент дойдёт до запроса связанных с ней ресурсов (css, js, картинки и т.п.), перед фактической отправкой каждого запроса, будет выполнена проверка в кэше. Если ресурс уже передан сервером и находится в кэше, то клиент загрузит этот ресурс из локального кэша не формируя внешний запрос к серверу. После закрытия соединения HTTP/2 содержимое кэша очищается.
При этом есть важные особенности: Глобальный кэш браузера имеет больший приоритет, чем кэш соединения HTTP/2, поэтому даже если push-запросом был передан более свежий ресурс, браузер продолжит использование ресурса из своего глобального кэша, если он не потерял актуальность (трафик потраченный на push-запрос будет потрачен в пустую). С другой стороны, так как одно HTTP/2 соединение может обслуживать загрузку разных страниц с одного хоста, то загруженные через push ресурсы могут совместно использоваться при загрузке разных страниц.Для управления отправкой push-запросов в новом выпуске nginx реализованы директивы:
- "http2_push {uri} (https://nginx.org/en/docs/http/ngx_http_v2_module.html#http2...)" для включения упреждающей отправки заданных ресурсов (например, "http2_push /main.css") в составе первого ответа, не дожидаясь их явного запроса. В URI допустимо использование переменных. В одном блоке конфигурации может быть задано несколько директив http2_push. Для обеспечения должного уровня защиты обрабатываются только относительные пути к ресурсу;- "http2_push_preload (https://nginx.org/en/docs/http/ngx_http_v2_module.html#http2...)" - данные о ресурсах, которые следует передавать через Server Push, определяются на основе анализа содержимого отправляемых клиентом HTTP-заголовков Link;
- "http2_max_concurrent_pushes (https://nginx.org/en/docs/http/ngx_http_v2_module.html#http2...)" - максимально допустимое число одновременных push-запросов, сопровождающих ответ.URL: https://www.nginx.com/blog/nginx-1-13-9-http2-server-push/
Новость: http://www.opennet.me/opennews/art.shtml?num=48109
Если взглянуть на график, то http/2 заметно медленнее обычного http, несмотря на то, что его создавали для ускорения. Даже обычный preload с http почти не отстаёт по скорости от HTTP/2 Server Push. И никто не учитывает expire time, при HTTP ресурс загрузится один раз и месяц будет браться браузером из кэша. А при Server Push каждый раз будет загружаться клиенту.Спрашивается, ради чего все эти сложности?
Его с HTTPS надо сравнивать.
> Спрашивается, ради чего все эти сложности?Ну для вас это сложности. Для гугла и фейсбука - нет.
> Спрашивается, ради чего все эти сложности?Работа ради работы - деятельность нужна работникам, их руководителям, руководителям этих руководителей и т.д., это их хлеб. Пользователям это обойдется в виде необходимости обновления, трафика на обновление, расходу места под хранение допольнительного кода, расход дополнительных ресурсов в работе программы (браузера) и в целом отягощение работы браузера и всей системы.
молчи лучше. Хттп 1.1 должен умерет
Почему?
Это версионный фашист. Все кто пользуются не самой последней версией по его мнению должны умереть.
Чтобы избавиться от нешифрованного HTTP, не потеряв время на лишнем раундтрипе, добававишемся за счёт поднятия TLS-сеанса.И он не медленнее - медленнее (было) установление соединения, а не дельнейшая работа. При этом соединение в нём, в отличие от HTTP 1.1, одно.
Вообще - ну въедь ты в тему прежде чем вопросы задавать, а?
Ты ещё поди за сустемг в том же ключе топил пару лет назад? "Скорость наше всё, вы все #*дарасы, не желающие приобщиться к прогрессу!111"
Я на системг только что матом не ругался. Потому что кривые архитектурные решения, попытки сделать монолит там, где он ен нужен и убогий код. А был бы он сделан нормально - не ругался бы, шелл-скрипты для стандартных задач - это тупость.А HTTP/2 - вполне логичная штука, в отличие от открытия кучи соединений на один сайт для параллельной загрузки контента. Да и полный переход на шифрованную передачу данных я всячески поддерживаю.
Даже между двумя, рядом стоящими серверами, изолированными от внешнего мира?
> Даже между двумя, рядом стоящими серверами, изолированными от внешнего мира?Зависит от того, как сделаете у себя вы.
Ради избавления от лишнего rtt в tls 1.3 сделали zero rt.
На мобильном интернете несколько соединений — лучше чем одно, потому что канал не стабилен (как ты думаешь, почему современные браузеры по http1.1 устанавливают от 4х до 8ми соединений сразу?). Задач у http2 только две: меньше соединений на сервер, впихивание контента ДО его запроса. Догадаешься, какой контент гугл будет впихивать вместе самым частоиспользуемым iframe в мире или подсказать? В качестве факультатива можешь изучить, как подходит рендеринг страницы в хромиуме при h/2 и в какой момент в этот процесс может вмешаться плагин.
> при h/2 и в какой момент в этот процесс может вмешаться плагинмол все хорошо, но… барабанная дробь — uBlock Origin заблочил параллельную загрузку.
Невероятно. И с учетом этого смыслом сущестования HTTP/2 Server Push будет ... ??
> Догадаешься, какой контент гугл будет впихивать вместе самым частоиспользуемым iframe в миреВообще-то для этого есть флаг SETTINGS_ENABLE_PUSH, который можно установить на клиенте при создании соединения.
А для насильственного трекинга, которого все так боялись при обсуждении спецификации, давно и успешно используется обычный заголовок ETag (с HTTP/1.0). У него меньше потенциальных сайд еффектов, чем у HSTS, и большинство клиентов постремаются его блокировать, особенно если цеплять к массивным ассетам (например здоровой фоновой картинке).
> (как ты думаешь, почему современные браузеры по http1.1 устанавливают от 4х до 8ми соединений сразу?)Как ты думаешь, откуда взялся порог от 4 до 8 к серверу в браузерах? И почему это привело в те годы к рождению cdn-на-коленке чисто для обхода этого лимита?
Подход h2 с мультиплексированием адекватнее.
> В качестве факультатива можешь изучить, как подходит рендеринг страницы в хромиуме при h/2 и в какой момент в этот процесс может вмешаться плагин.В момент onBeforeRequest? А в firefox 57+ есть ещё и filterResponseData с фильтрацией ответа до передачи парсеру браузера https://github.com/gorhill/uBlock/issues/3069
Мне абсолютно наплевать, как в хромиуме что делается. Возможности протокола - это хорошо. Браузер, заботящийся о моих интересах и подходящий набор расширений - тоже хорошо.А как раз зачем по http 1.1 устанавливают несколько соединений я знаю отчлино - потому что, в отличие от http/2, он по одному соединению может только один объект отдавать в один момент времени. И чтобы получить параллельную загрузку нужны такие вот костыли.
Что до ифрейма - он никак не может прилететь через этот пуш, так как для этого контент должен быть на том же сервере, куда сделан запрос, а аналитика - на своём живёт. А если что-то подобное будет на том же сервере - так там и пуша не надо, так будет загружен (и заблочен NoScript и uBlock).
> На мобильном интернете несколько соединений — лучше чем одно, потому что канал
> не стабилен (как ты думаешь, почему современные браузеры по http1.1 устанавливают
> от 4х до 8ми соединений сразу?)Ну уж явно не из за нестабильного интернета, а ради распараллеливания нагрузки.
> И он не медленнее - медленнее (было) установление соединения, а не дельнейшая
> работа. При этом соединение в нём, в отличие от HTTP 1.1,
> одно.Кстати, именно это и является его проблемой. Т.к. при плохом канале(мобильный инет например) рвутся все мультиплексированные запросы, а не один; и в итоге он оказывается медленнее. Тут где-то была ссылка на подобное исследование.
Вообще, смешивание в кучу специализированных вещей как в http, так и в html-наборе раздражает. Браузеры становятся монструозными и тормозными. Всякая cms стремиться непременно использовать всё, что ей не надо.
> А при Server Push каждый раз будет загружаться клиенту.Только у nginx и прочих недосерверов. В h2o есть поддержка определения, посещался ли ресурс в прошлом: https://h2o.examp1e.net/configure/http2_directives.html#http...
Есть HTTP/2-сервера (например nghttpx) поддерживают режим без SSL.Проблема не в самом HTTP/2, а в производителях браузеров, лоббирующих свою SSL-шаражку.
Уж не производитель на букву Г придумал этот протокол?
Изначально, чтобы в момент времени t быть уверенным что файлы 1,2,3 уже загружены.
Все остальное это уже потом домыслили.
Было уже.
На каждый бранч по новости.
> Глобальный кэш браузера имеет больший приоритет, чем кэш соединения HTTP/2, поэтому даже если push-запросом был передан более свежий ресурс, браузер продолжит использование ресурса из своего глобального кэша.Гениально!
Именно, бесполезный механизм который невозможно синхронизировать с алгоритмами кеша на клиенте.HTTP/2 поставлен под сомнения, так как он тащит все legacy поля из HTTP/1.1.
Гениально было бы раздавать кэш через deb пакеты, а так шило на мыло.
Вообще очень похоже что едиственный смысл http/2 пересадить всех на https, который как бы не обязательный но почему то все браузеры при работе по http/2 его требуют.
Графики ускорения загрузки/отображения сайта при грамотной реализации push подтверждают мои замеры с использованием H2O которые я приводил в предыдущей версии этой новости.
Смехотворно... официальная версия Nginx 1.13 не умеет даже полную спецификацию HPACK по RFC7541.
Да он дофига чего пока не умеет. В отличие от H2O.
> Да он дофига чего пока не умеет. В отличие от H2O.Он и либой быть не умеет. И модули програмить очень геморно. Так что для нестандартных скоростных инсталляций nginx очень геморроен. Еще разработчики H2O не выделываются с системой контроля версий. Есть себе обычный гитхаб - и на том спасибо. Лучше чем hg какой-то там.
На гитхабе есть зеркало: https://github.com/nginx/nginxА патчи в любом случае принимаются только через список рассылки, и это правильно. Если что, форматы патчей в git и hg абсолютно идентичны.
Если вам нужно сжатие заголовков для мобильного трафика из протокола HTTP/2.0 - Nginx вам не поможет он это не умеет практически...