Ответ 1
В HTTP/2 сервер подталкивает клиенту запрос для ресурса с кадром PUSH_PROMISE.
При переходе от сервера к клиенту это не ответ, а запрос, запрос, который клиент сделает для получения этого ресурса.
Когда клиент получает PUSH_PROMISE, он может посмотреть на URI и выяснить статус кэша этого ресурса. Браузеры обычно используют разные кэши для обычно получаемых ресурсов и подталкивают ресурсы. Если кеш по-прежнему действителен, клиент может отменить толкаемый поток, отправив на сервер RST_STREAM-фрейм для этого потока.
В то же время сервер запускает то, что требуется для продвижения ресурса. Это создаст кадр ответа HEADERS, который будет содержать типичные заголовки ответов, такие как etag. Когда клиент получает кадр ответа HEADERS, у него есть еще один шанс отменить поток, хотя, конечно, - кадры DATA могут быть потоками, возможно, все из них.
Сохранение полосы пропускания может быть интересным, но обычно это не проблема, чтобы тратить небольшую полосу пропускания; что имеет большее значение с точки зрения пользователя, это латентность, и механизм нажатия уменьшает это на значительную величину.
Я не думаю, что механизм push компрометирует любую оптимизацию кеша клиента; если бы это было так, разработчики браузеров бы сражались против этой функции, в то время как большинство из них (если не все) реализовали ее с очень хорошими результатами в пользовательском опыте и уменьшенной задержкой.
Конечно, механизм может быть улучшен, например, если клиенты и серверы согласятся на какой-то заголовок, который даст больше информации о том, что ресурс будет нажат, но пока работает достаточно хорошо.
[Отказ от ответственности: я - коммиттер Jetty] Первым, кто реализовал SPDY и HTTP/2 Push для экосистемы Java (почти 3 года назад), проект Jetty Project, безусловно, интересуется большим количеством обсуждений и идей вокруг HTTP/2 Push.