The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

В Chrome намерены удалить поддержку технологии Server Push

12.11.2020 08:56

Разработчики Chrome намерены прекратить поддержку механизма Server Push в протоколах HTTP/2 и gQUIC, а также не реализовывать её для протокола HTTP/3, находящегося на стадии утверждения стандарта. В протоколе HTTP/1.1 технология Server Push не предусмотрена изначально. Причиной удаления является желание избавиться от большого усложнения в коде, на фоне невостребованности и лишь теоретических предпосылок в эффективности оптимизаций на основе Server Push.

Технология Server Push определена в стандарте HTTP/2 и нацелена на оптимизацию загрузки данных. Помимо браузеров на базе движка Chromium поддержка Server Push в настоящее время реализована в Firefox и Safari, а на стороне сервера в nginx и в Apache httpd. При помощи Server Push сервер может отправить ресурсы клиенту, не дожидаясь их явного запроса. Предполагается, что таким образом сервер может ускорить загрузку страницы, так как необходимые для отрисовки страницы файлы CSS, скрипты и изображения к моменту запроса клиентом окажутся уже переданными на его сторону.

Клиент подключается и запрашивает определённую страницу, после этого сервер на основании своих настроек или содержимого переданного клиентом заголовка Link сам инициирует передачу определённых ресурсов через уже установленное соединение HTTP/2, не дожидаясь запроса этих ресурсов от клиента. Переданный через push-обращение контент сохраняется на стороне клиента в специальном кэше, ассоциированном с текущим HTTP/2-соединением. Когда в процессе обработки страницы клиент дойдёт до запроса связанных с ней ресурсов (css, js, картинки и т.п.), перед фактической отправкой каждого запроса выполняется проверка в кэше. Если ресурс уже передан сервером и находится в кэше, то клиент загружает этот ресурс из локального кэша не формируя внешний запрос к серверу.

Поддержание подобного кэша сильно усложняет реализацию Server Push на стороне клиента, но не приводит к заметному ускорению загрузки по сравнению с упреждающим запросом ресурсов через тег "preload", а по данным некоторых исследований даже увеличивает задержки. По статистике Google технология Server Push не получила должного распространения. Например, за последние 28 дней в 99.95% соединений HTTP/2 не применялся Server Push. Аналогичные показатели наблюдались при проведении исследования в июне 2019 года, т.е. рост внедрений Server Push не наблюдается. Более того, в нынешнем году лишь 40% полученных Server Push отправлений были использованы браузером, а два года назад этот показатель составлял 63.51% (необработанные отправления были некорректными, не соответствовали обрабатываемой странице или уже были в кэше).

Вместо Server Push для оптимизации загрузки страниц предлагается использовать тег <link rel="preload">, на основании которого браузер может запросить ресурс не дожидаясь его использования на странице. C одной стороны, preload по сравнению с Server Push приводит к лишнему обмену пакетами (RTT), но с другой стороны позволяет избежать отправки ресурсов, которые уже имеются в браузерном кэше. В целом отличия в задержках при использовании Server Push и preload отмечены как несущественные. Кроме оптимизации загрузки ресурсов механизм Server Push также может использоваться для потоковой передачи данных от сервера клиенту, но для этих целей лучше подходит протокол WebTransport (на базе QUIC), стандартизация которого находится на стадии черновика.

  1. Главная ссылка к новости (https://groups.google.com/a/ch...)
  2. OpenNews: Сравнение производительности HTTP/1.1, HTTP/2 и HTTP/2 + Server Push
  3. OpenNews: Выпуск nginx 1.13.9 c поддержкой технологии HTTP/2 Server Push
  4. OpenNews: В Chrome планируют включить механизм Signed HTTP Exchanges (SXG)
  5. OpenNews: Google намерен до 2022 года прекратить поддержку сторонних Cookie в Chrome
  6. OpenNews: Разработчики Chromium предложили унифицировать и объявить устаревшим заголовок User-Agent
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/54069-http2
Ключевые слова: http2, server, push, chrome
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (116) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 09:27, 12/11/2020 Скрыто ботом-модератором [﹢﹢﹢] [ · · · ]     [к модератору]
  • –3 +/
     

     ....ответы скрыты (8)

  • 1.3, leibniz (ok), 09:36, 12/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +14 +/
    вроде звучит разумно
     
     
  • 2.58, Kuromi (ok), 17:29, 12/11/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Да еще когда они пропихивали это в HTTP2 им тогда говорили что это мало кому нужно, но нет "Мы Гугл, мы знаем лучше". ну и вот результат.
     
     
  • 3.106, Аноним (-), 18:22, 13/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Нормальная технология, с ней можно огранизовать поток без жабаскрипта. С другой стороны это хромой, кому он нужен.
     
  • 2.61, Аноним (61), 18:15, 12/11/2020 [^] [^^] [^^^] [ответить]  
  • +7 +/
    > не приводит к заметному ускорению загрузки

    Хромой не приводит к ускорению загрузки вообще, его надо удалить.

     
     
  • 3.97, Аноним (28), 10:27, 13/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Лиса приводит? Удаляем!
     

  • 1.4, псевдонимус (?), 09:38, 12/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    "на стадии черновика"

    Но сначало нужно выкинуть сделанное не ими, "тама слишка сложный кот, насяльника!"

     
     
  • 2.62, Аноним (61), 18:19, 12/11/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    странно это слышать от тех, у кого сырцы хромиума весят 16 ГБ... Нет, он не сложный, а вот реализация кеша - О_о, <белая лиса> как сложно!
     
     
  • 3.72, Kuromi (ok), 19:29, 12/11/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Сходная ситуация была у Мозиллы. Они долго пилили "мультипликацию HTTP соединений", чтобы параллельно грузить быстрее, но все это было очень на грани стандартов, поэтому на очень многих серверах глючило, что заставило их внедрить сложный эвристический механизм угадывающий будет ли мультипликация работать на конкретном сервере и потом долго упорно настраивать эвристику...
    Короче, в какой-то момент вот это все разрослось до настолько монструозной конструкции что было принято решение выкинуть все целиком - и мультипликацию и эвристику, потому что это все тормозило браузер уже сильнее чем ускоряло.
     
  • 2.89, AnonGdon (?), 01:12, 13/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > нужно выкинуть сделанное не ими

    Тут они выкидывают сделанное ими, так что все ок.

     

  • 1.5, Аноним (5), 09:41, 12/11/2020 Скрыто ботом-модератором [﹢﹢﹢] [ · · · ]     [к модератору]
  • –11 +/
     

  • 1.6, Аноним (6), 09:44, 12/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +18 +/
    Сначала ввели, а потом выпиливают... гугл такой гугл
     
     
  • 2.7, Аноним (5), 09:51, 12/11/2020 [^] [^^] [^^^] [ответить]  
  • +21 +/
    Да, они любят вводить своим пользователям
     
     
  • 3.96, Аноним (28), 08:37, 13/11/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А у мазилки вводилка заржавела. и не rastёт. Теперь только языком.
     
     
  • 4.107, Аноним (-), 18:26, 13/11/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Потенциал чуствую большой я юный подаван. Сторону не попутай главное ты !
     
  • 2.10, пдк (?), 10:03, 12/11/2020 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Скорее гуглеры - такие гуглеры. Устроиться туда работать довольно трудно, но те кто уже устроились постоянно кодят какую-то хрень, ломают годами работающий функционал, а затем так же годами его не чинят.
     
     
  • 3.14, Аноним (14), 10:36, 12/11/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    ну так им за это денег платют

    странно что они еще quic не задепрекейтили

     
     
  • 4.33, Lex (??), 12:12, 12/11/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Шоб в гугле рядовым сотрудникам и норм деньги платили.. смищно

    Особенно с учётом того, что они очень любят нанимать подрядчиков

     
  • 3.25, Аноним (6), 11:20, 12/11/2020 [^] [^^] [^^^] [ответить]  
  • +8 +/
    Гуглеры рукожопы от мира ИТ это общеизвестный факт
     
  • 3.31, Урри (ok), 11:55, 12/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Да ладно вам. Вот я работаю на гугл не устраиваясь непосредственно туда.
    Секрет прост - гугл очень любит подрядчиков, они дешевые и их можно увольнять сразу после завершения проекта.
     
     
  • 4.98, Аноним (28), 10:29, 13/11/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А подрядчики все из мазилы?
     
  • 4.108, Аноним (-), 18:29, 13/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Вот я работаю на гугл не устраиваясь непосредственно туда.

    А за мысли неправильные или чтение чужих но тоже неугодных - не уволят ? Давай затестим !

     

  • 1.9, Аноним (-), 10:01, 12/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    Да если бы были хоть какие-то конкуренты, то Гугл бы ещё и не такие переусложнённые велоспеды через стандарты навязывал...
    А так оказывается что "да неоченьто оно и нужно" и "HTTP/1.1 хватит всем"
     
     
  • 2.11, Аноним (11), 10:23, 12/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Да если бы были хоть какие-то конкуренты

    Про Edge не слышали?

     
     
  • 3.13, YetAnotherOnanym (ok), 10:35, 12/11/2020 [^] [^^] [^^^] [ответить]  
  • +10 +/
    Тонко. Зачот.
     
  • 3.15, llolik (ok), 10:36, 12/11/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Про Edge не слышали?

    И он тоже уже на Chromium. А вообще принципиально осталось три браузера: chrome, firefox и safari. А если считать chrome и safari как один WebKit, так и вообще два.

     
     
  • 4.18, YetAnotherOnanym (ok), 10:51, 12/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > chrome и safari как один WebKit

    у хрома блямк вроде...

     
     
  • 5.22, Аноним (22), 10:58, 12/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Который суть плоть от плоти вебкита, только банановый.
     
     
  • 6.24, Аноним (24), 11:11, 12/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ага, а все они KHTML. На самом деле, Blink давно в сторону убежат от WebKit, там все меньше общего остается.
     
  • 5.44, Ковид20 (?), 14:14, 12/11/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Сам ты опасный. Учи матчасть.
     
     
  • 6.59, YetAnotherOnanym (ok), 17:39, 12/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Сам ты опасный

    Спасибо.
    > Учи матчасть.

    Спасибо.

     
  • 6.105, Опасный поцык (?), 16:31, 13/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ты на пенёк сел?
     
  • 4.34, Lex (??), 12:14, 12/11/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > А если считать chrome и safari как один WebKit

    А на каком основании, если даже js-движки у них ощутимо разные ?

     
     
  • 5.38, llolik (ok), 12:53, 12/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > А на каком основании, если даже js-движки у них ощутимо разные ?

    Ну если уж совсем точно то WebCore. WebKit - это же ЕМНИП WebCore (DOM, CSS, SVG и вот это всё) и JSCore (JS-движок). Google от WebCore форкнули в Blink и прикрутили свой JS-движок V8.

     
     
  • 6.78, Lex (??), 22:21, 12/11/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    О том и речь, что разница ощутима:
    жс движки разные, веб-движки - разные( с момента форка оба сильно изменились )
    Их едва ли корректно под один вебкит( у которого jscore, а не v8 ) группировать
     
  • 4.56, Аноним (56), 17:07, 12/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Нельзя считать chrome и safari как один, blink сильно оторвался вперед за 7 лет, в webkit до сих пор баги рендера которые были в хроме лет 6 назад, по поддержке новых стандартов в webkit отстает больше чем в firefox.

    Кстати, большинство багов рендера воспроизводятся в gtkwebkit(например в epiphany), при этом запустить под виндой современный webkit кране муторно.

     

  • 1.12, Ковид20 (?), 10:26, 12/11/2020 Скрыто ботом-модератором [﹢﹢﹢] [ · · · ]     [к модератору]
  • –7 +/
     

  • 1.16, vitalif (ok), 10:42, 12/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +7 +/
    Осталось еще сам http/2 теперь тоже выпилить, вот умора-то будет
     
     
  • 2.40, Аноним (40), 13:49, 12/11/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Так уже все на http3 нацелились т.к. http2 "не получило должного распространения"
     
     
  • 3.71, Kuromi (ok), 19:22, 12/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Хз насчет этого. У меян в Лисе стоит аддон показывающий что сайт использует HTTP2. Как ни странно, таких нынче очень даже немало. И не только крупняк, уже и в общем относительная мелочь часто на HTTP2. Опеннет конечно не пример.
     
     
  • 4.86, rvs2016 (ok), 23:34, 12/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Опеннет конечно не пример

    Ретроградство, бывает, очень сильно выручает. Яркий пример - в фильме и сериале "Крейсер Галактика". В-)

     

  • 1.19, Аноним (22), 10:55, 12/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    ХАХАХАХАХА. Но на самом деле это хорошая новость, потому что идея изначально была дно.
     
     
  • 2.70, Аноним (5), 19:10, 12/11/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вы про Server Push или Chrome?
     

  • 1.20, zzz (??), 10:56, 12/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +9 +/
    Переусложненный протокол, неочевидные выгоды - об этом говорили с самого начала. Но всё равно эту дичь пропихнули и стандартизовали. Это всё, что надо знать о текущем уровне инженерии в гугле, который всё больше напоминает слона в посудной лавке.
     
     
  • 2.64, Аноним (61), 18:26, 12/11/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А им некогда сейчас разработкой заниматься, надо словари составлять разрешённых слов.
     

  • 1.21, Аноним (23), 10:58, 12/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    >Наш QUIC никому даром не нужен, а значит надо http/2 прибить.

    Ясно.

     
  • 1.27, еман (?), 11:29, 12/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    >При помощи Server Push сервер может отправить ресурсы клиенту, не дожидаясь их явного запроса.

    нет чтобы юзать православный json-rpc 2.0

     
     
  • 2.35, Lex (??), 12:17, 12/11/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > не дожидаясь их явного запроса

    Т.е серверную часть ещё больше придётся смешивать с клиентской, чтобы она знала (!) лучше клиентской части, что ей вот-вот потребуется

    Это заведомо эпический цЫрк и плохой подход. Хотя, гуглу не привыкать

     
     
  • 3.65, Аноним (61), 18:28, 12/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Да легко, посадить на сервер ИИ, который будет наблюдать за последовательностью запросов и предлагать варианты, основываясь на истории.
     
     
  • 4.80, Lex (??), 22:28, 12/11/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А если фронтенд периодически дорабатывается, то что с накопленной статистикой делать ?)

    Т.е вместо того, чтобы просто на фронте  прописать загрузку допресурсов, но после основных и тендера страницы, предлагаете прикручивать черти какой ИИ, вести отдельную статистику и париться с её актуализацией и, более того, ещё и место в БД подо всё это творчество выделять.. не жирно ли для такой примитивной «задачи» и это точно приведёт к СНИЖЕНИЮ потребления ресурсов, если речь о выдаче статики ?

     
     
  • 5.92, Аноним (61), 04:08, 13/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Почитай, как кеши в процах протухают, и как бедненький проц с этим справляется... да уж, прям невыполнимая задача. Надо срочно удалить все кеши.
     
  • 3.66, Аноним (61), 18:30, 12/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Если 100500 раз вслед за html загрузили css, то, однако, и на 100501-ый раз тоже css понадобится.
     
     
  • 4.77, Аноним (-), 22:13, 12/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Мама, что такое кэширование?
     
     
  • 5.93, Аноним (61), 04:10, 13/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Сынок, не забудь опять завтра букварь в школу взять.
     
  • 4.79, Lex (??), 22:24, 12/11/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Если проект живой, то на сайте постоянно что-то допиливают
    И далеко не факт, что по итогу очередного изменения какой-то ранее необходимый файл будет требоваться.

    Тем более, что ничто не мешает их загрузку прописать на фронтенде, но после загрузки основных ресурсов

     

  • 1.30, Ivan_83 (ok), 11:46, 12/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +6 +/
    А сколько было пеара, сколько обещаний 10005000% ускорения загрузки рекламы...
    Ещё немного и можно будет признать что и сам QUIC отрыжка технологий.
     
     
  • 2.37, Аноним (-), 12:40, 12/11/2020 [^] [^^] [^^^] [ответить]  
  • +5 +/
    шеф, бунтуют! вытащить на полдюйма и лям на пропаганду!
     
  • 2.47, Demo (??), 15:04, 12/11/2020 [^] [^^] [^^^] [ответить]  
  • +5 +/
    > сам QUIC отрыжка технологий

    Изобретатель ARPANET утверждает, что использование UDP
    для преодоления ограничений TCP — это путь в никуда.
    Они это проходили в 1983-м с коллапсом NCP, в результате
    Vint Cerf изобрёл TCP, оптимизированный для килобитных
    или мегабитных скоростей. Для гигабит/с и терабит/с
    нужен другой протокол надёжной передачи с контролем потока,
    с поддержкой на уровне сети (маршрутизаторов).

    > 10005000% ускорения загрузки рекламы.

    И чрезмерным заполнением каналов невостребованными пакетами UDP,
    которые отсылаются по принципу: "Ах, мы потеряли один пакет — вот вам
    N таких же, даст бог, какой-то из них пробьётся".

     
     
  • 3.54, Ivan_83 (ok), 16:19, 12/11/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Для гигабитных скоростей TCP всё ещё вполне хватает, даже не знаю сколько нынче потолок TCP в один конект для обычных OS без супертюнингов, но дуюма 10Г должны переварить все.
    А дальше начинаются проблемы не только с TCP но и с тем откуда столько взять и куда это потом деть.

    Маршрутизатор то тут причём!?
    Он смотрит в заголовок IP пакета, а что там дальше его не интересует совсем.

    Если где и будут проблемы - так это с кучей домашних железок, где IPv4 NAT используется, потому что оно в основном умеет только TCP/UDP, иногда gre и что то ещё.

     
     
  • 4.69, Demo (??), 19:05, 12/11/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Часто приходилось перезаливать десятки терабайт контента из Европы в Штаты и обр... большой текст свёрнут, показать
     
     
  • 5.99, Ivan_83 (ok), 11:41, 13/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Перекладывание на маршрутизатор чревато тем что каждый админ роутера будет считать себя властителем инета и что ему, как вахтёру, все должны.

    Если вы хотите скорости выше на линухе - тюньте сетевой стёк, вы же поди на дефолтах сидели, а там уныный cubic.

     
     
  • 6.110, Demo (??), 00:12, 14/11/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Перекладывание на маршрутизатор чревато …

    … не более, чем сейчас.

    Это всё уже было. Просто вы, видимо, не застали.
    Контролем потока занимались PAD'ы. Просто из-за
    слабости процессоров в то время (m68k, 6502 и т.д.)
    Vint Cerf сотоварищи при переходе с NCP на TCP решили
    перекинуть эту задачу на конечные точки соединения.
    Тогда думали, что в течение десяти лет все плавно
    перейдут с TCP/IP на протокол ISO. Этого не случилось
    по известным причинам.

    > Если вы хотите скорости выше на линухе - тюньте сетевой стёк,
    > вы же поди на дефолтах сидели, а там уныный cubic.

    А это кто писáл, Пушкин?:
    — Для гигабитных скоростей TCP всё ещё вполне хватает, даже не знаю сколько нынче потолок TCP в один конект для обычных OS без супертюнингов, но дуюма 10Г должны переварить все.

    Larry Roberts же вам объяснил, что из-за того, что TCP надо "тюнить" под каждый чих [(1)диапазон задержек (2) диапазон потерь] (иначе он не даёт ожидаемой производительности), инженеры этих ваших энторнэтов придумали ничего лучше, чем пускать трафик по UDP. А это чревато засорением каналов ненужным трафиком. Вместо этого для эффективного использования полосы пропускания нужно внедрять протокол, в котором контролем потока будет заниматься сеть, а не конечное устройство.

    Я это всё в третий раз пишу, но, думаю, до вас не дойдёт.

     
     
  • 7.117, Аноним (-), 21:36, 21/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    " Для гигабитных скоростей TCP всё ещё вполне хватает, "
    пусти его по вайфай с 5% потерь пакетов или 4g в поезде - и посмотри какой процент реально доступного канала оно сможет прогрузить, когда кубик архаичный уйдет в тормоза по минуте

    ну а вот в udp можно пакеты в программе самому шедулить - с tcp так не получится, особенно в винде

     
  • 5.115, Аноним (-), 21:32, 21/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    " С этим QUIC (долой UDP, да здравствует UDP) стало понятно, "
    а что там не понятно, в винде нельзя свой шедулинг tcp сделать, вот все и любят удп когда архаичные кубики задолбали
     
  • 2.50, vitektm (?), 15:34, 12/11/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Проблема в том что всем нас*** на производительность своих сайтов. А отправка PUSH сродни сокращению TTL про это не думают 99,95% разработчиков сайтов.  
     
     
  • 3.55, Ivan_83 (ok), 16:21, 12/11/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Наверное не TTL а rtt.
    Разработчики сайтов в общем и не должны об этом думать, это не их область компетенций.
     
  • 3.85, Аноним (85), 23:33, 12/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, я вот ставлю себя на место разработчика вебсайта. Первый вопрос на кой хер мне заливать клиенту то, что ему скорее всего не нужно? Тупо трафик погонять? Трафик кстати стоит денег. Второй вопрос, с учетом того, что веб-разработка идет совсем иным путем (аля ajax-запросы) + паковка всего кода в страницу SPA, то накой нужна вообще эта технология, нету юзкейса в SPA, где этот Server Push вообще как-то пригодится. Наоборот, это рушит концепцую SPA.
     
     
  • 4.116, Аноним (-), 21:33, 21/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    с точки зреения разработчика надо какой-то список взаимозависимостей создавать, и еще серваку это в понятном ему виде прописать, это много возни а выигрыш небольшой, вот все и забили
     

  • 1.36, Аноним (36), 12:17, 12/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +8 +/
    И они ещё спрашивают почему столько консервативных разработчиков? Понапиваются смузи, наплодят технологий и языков, а потом два раза удивляются: почему технологию не хотят осваивать разработчики и почему эту технологию - которую мы решили выкинуть - начали осваивать разработчики.
    Лавров.jpg
     
     
  • 2.42, Ананимус (?), 14:10, 12/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ну вообще говоря, логические потоки внутри HTTP сессии напрашивались давно. Так что кое-что у них получилось ок. Дропнуть User-Agent это тоже хорошая идея.
     
     
  • 3.81, Lex (??), 22:32, 12/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Окей, юзерагента нет.
    Как более-менее универсально определять на стороне сайта браузер и версию( даже чтобы банально сказать, что он старое г.но и пора обновиться для корректного ото радения сайта ) ?
     
     
  • 4.84, Ананимус (?), 22:47, 12/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Как более-менее универсально определять на стороне сайта браузер и версию( даже чтобы банально сказать, что он старое г.но и пора обновиться для корректного ото радения сайта ) ?

    Никак. Ты и с User-Agent это не можешь. Более того, это не нужно, особенно для того случая, что ты привел. Делайте сайты по стандартам и перестаньте быдлокодить.

     
     
  • 5.101, Lex (??), 15:38, 13/11/2020 [^] [^^] [^^^] [ответить]  
  • +/

    > Никак. Ты и с User-Agent это не можешь. Более того, это не
    > нужно, особенно для того случая, что ты привел.

    Могу, если пользователь сам его не изменил( но тут уж его проблемы начинаются ).

    > Делайте сайты по стандартам и перестаньте быдлокодить.

    И более-менее свежие фичи html, css и js от этого внезапно заработают на г.не мамонта в лице какого-нибудь ИЕ8 ?

    Если начинать углубляться в какие-то специфические детали, то очень много нюансов появляется.
    Доходит вплоть до того, что один и тот же браузер, но разных типов( десктоп / мобильный ) может работать и выполнять скрипты по разному, может иметь разный браузерный апи и особенности его исполнения.. даже один и тот же мобильный браузер, но в андройде и на яблоке могут ощутимо различаться.

    И, в общем-то, для многих не секрет, что у разных браузеров более чем немало своего, браузероспецифичного.
    Просто, обычно используют библиотеки и модули, в которых подобная проблема, мб с кучей костылей и мусора, но решена.
    Но не для всех случаев жизни существуют подобные модули.

     
     
  • 6.103, Ананимус (?), 15:52, 13/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Могу, если пользователь сам его не изменил( но тут уж его проблемы начинаются ).

    Ну вот видишь. Если не изменил, если браузер репортит, если твой серверный код распознал правильно.

    > И более-менее свежие фичи html, css и js от этого внезапно заработают на г.не мамонта в лице какого-нибудь ИЕ8?

    Если не заработают, то пользователь поменяет свой браузер на поддерживаемый.

    > <много страданий из мира веб-разработки>

    В мире по сути остались три браузера: хром, фуррифокс и сафари. Они вполне способны договориться о следовании стандартам. Хватит всего этого рака.

     
  • 4.100, Аноним (100), 14:50, 13/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Feature detection. Если не проходит, пишешь "что он старое г.но и пора обновиться". Зачем тебе именно версия? Очень хочешь писать "ваш хром 54 устарел, обновите как минимум до 72"?
    https://developer.mozilla.org/en-US/docs/Web/HTTP/Browser_detection_using_the_
    > Feature detection is where you don't try to figure out which browser is rendering your page, but instead, you check to see if the specific feature you need is available. If it's not, you use a fallback. In those rare cases where behavior differs between browsers, instead of checking the user agent string, you should instead implement a test to detect how the browser implements the API and determine how to use it from that.
     
     
  • 5.102, Lex (??), 15:52, 13/11/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Feature detection. Если не проходит, пишешь "что он старое г.но и пора
    > обновиться". Зачем тебе именно версия?

    Иногда все проще:
    ТЗ требует корректной работы на браузерах не ниже определенной версии. Если ниже или не определен - отображается соотв сообщение.

    Поглядел. в меру интересно, но неоднозначно, поскольку у разных браузеров много браузероспецифичного апи и код проверки фич без юзерагента может быть ощутимо более бомбезным( из ссылки, пример кода определения мобильного устройства ):

    >[оверквотинг удален]
    >         hasTouchScreen = true; // deprecated, but good fallback
    >     } else {
    >         // Only as a last resort, fall back to user agent sniffing
    >         var UA = navigator.userAgent;
    >         hasTouchScreen = (
    >             /\b(BlackBerry|webOS|iPhone|IEMobile)\b/i.test(UA) ||
    >             /\b(Android|Windows Phone|iPad|iPod)\b/i.test(UA)
    >         );
    >     }
    > }

    ИМХО, такое себе решение с кучей костылей на пару десятков строк кода для проверки лишь одного-единственного параметра

     
     
  • 6.109, Аноним (23), 23:20, 13/11/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >ТЗ требует некорректной работы на браузерах ниже определенной версии

    Пофиксил, не благодари.

     

  • 1.39, Аноним (40), 13:48, 12/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    >>По статистике Google технология Server Push не получила должного распространения.

    Ну так потому что сырая технология. Вы с таким же успехом можете HTTP/3 выпиливать и вайланд. Нет у них должного распространения.

     
     
  • 2.111, Аноним (111), 08:31, 16/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    вайланд уже 12 лет как сырой, сколько еще лет нужно, чтобы он перестал быть сырым
     

  • 1.48, NotaBug (ok), 15:19, 12/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Это не наш путь. (с)Mozilla Corporation

    dom.push.enable = false
    dom.push.connection.enabled = false
    dom.push.serverURL = ""
    dom.webnotifications.enabled = false
    dom.webnotifications.serviceworker.enabled = false
    dom.serviceWorkers.enabled = false

     
     
  • 2.52, Минона (ok), 15:41, 12/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    firefox.enable = false
     
     
  • 3.75, NotaBug (ok), 21:14, 12/11/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > firefox.enable = false
    >firefox.google_donate.disable = true
    >firefox.crash_segfualt.enable = rip
     
  • 2.57, Аноним (22), 17:08, 12/11/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В новости речь немного не об этом, но да.
     

  • 1.60, Аноним (60), 18:03, 12/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Мазилафаги люто минусуют. Видно, пахнуло жареным.
     
     
  • 2.118, Аноним (-), 21:37, 21/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    уже давно запахло и разработчиков уволили, остался только маркетинг
     

  • 1.67, Аноним (67), 18:33, 12/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    во, а тут только какой то горе оптимизатор нанятый рассказывал, что у нас всё медленно потому что у нас сервер пуш не применяется.. не, его конечно послали лесом и не только по этому. но ктото ведь на них ведется. ща такие бросят всё, навставляю.т пушей. получат минус 5% прироста производительности (т.к. серверный код станет в разы толще, то станет только медленнее), а тут бац, вторая смена, выпиливаем...
     
     
  • 2.68, Аноним (40), 18:38, 12/11/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    И станет на 5% быстрее!! Успех!
     
     
  • 3.82, Lex (??), 22:34, 12/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    На 2%, ведь из проекта обычно выпиливается не весь мусор
     

  • 1.73, Аноним (-), 19:32, 12/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    На самом деле новость читать следует так:
    "мы не смогли осилить кэш браузера, звонок другу в Бангалор ничего не дал, по этому будете без кэша, и как следствие без server push".
    Я не шучу, в хромом это именно так и есть, и то давно, годами. Кто считает, что хромой правильно умеет работать с кэшем - пускай первый бросит в меня коммент.
     
     
  • 2.121, Gemorroj (ok), 20:07, 26/01/2021 [^] [^^] [^^^] [ответить]  
  • +/
    эх, а вот в опере какой православный кэш был)
     

  • 1.74, suffix (ok), 20:46, 12/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    1. Не знаю как там у большинства - я на своём сайте использую.
    2. Собрал все js в один файл и все css в один файл и отдаю server push-eм. Убыстрение очень даже заметно!

    https://webpagetest.org/result/201112_Di2S_ab008a11f94d57e4e039726768446930/1/

    Вывод:

    Ну гады хромоногие :(

     
     
  • 2.76, Аноним (61), 22:04, 12/11/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    3. Собери всё html+js+css в один файл, и будет тебе тру профит!
     
     
  • 3.83, suffix (ok), 22:42, 12/11/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Иногда лучше молчать чем говорить!
     
     
  • 4.88, Аноним (88), 00:39, 13/11/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вот как бы да. Лучше бы ты молчал.
     

  • 1.87, Аноним (88), 00:38, 13/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Ну дошло наконецто. Изначально было понятно что это кривохак. Хоть что-то действительно бесполезное вырезали.

    А у iPony наверное вообще когнетивный диссонанс. Как-это так? Новую модную технологию вырезали.

     
     
  • 2.119, Аноним (-), 21:38, 21/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    а этой технологией кто-то вобще пользовался, хотя-бы этот ваш ифон?
     

  • 1.90, Аноним (90), 01:22, 13/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    В чем смысл?
     
     
  • 2.91, Аноним (61), 04:02, 13/11/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Гугл не осилили то, что сами толкали в стандарт http/2
     
     
  • 3.94, Аноним (90), 04:47, 13/11/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это я понял, в чем смысл пилить http3 с руками из жопу у гугла? Лучше уж вернуться к проверенному HTTP 1.1
     
     
  • 4.112, пох. (?), 11:44, 16/11/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    То есть как "В чем"? В том что нагрузка на серверы гугла снизится на 3 или даже целых семь процентов.

    Проооофит!

    А что возрастет нагрузка на инфраструктуру и всем кроме гугля работать станет хуже - так это... опять проооофит!

    А http 1.1 скоро запретят - небезопастно, немодно, и вообще не гуглеугодно. После его отключения (или небольшой порчи) на ютрупчике - ты и сам быстро зак...ешь свой неправильный браузер.

     
     
  • 5.114, Аноним (-), 21:29, 21/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    с разморозкой, уже дофига сайтов http/2 используют во всю, а станет >90% юзерей таких, так и уберут 1.х для упрощения кодовой базы
     

  • 1.95, Аноним (95), 08:05, 13/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    gRPC всё R.I.P
     
  • 1.104, Аноним (104), 16:10, 13/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    > Поддержание подобного кэша [...] не приводит к заметному ускорению загрузки

    Выяснить это ДО отправки запроса на принятие в стандарт гугл, конечно, был не в состоянии.

     
  • 1.113, Аноним (-), 21:28, 21/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    пусть еще свою билдсистему из хромиума удалят, вот уж что сложное в использовании
     
  • 1.120, Аноним (120), 21:23, 24/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Сначала топим за технологию, потом топим саму технологию.
     
  • 1.122, Tron is Whistling (?), 14:18, 14/06/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Короче вот это вот самое вау-новшество всего смузи/2, которым его усиленно проталкивали, в итоге оказалось никому не нужным.

    Из единственного оставшегося полезным там - мультистрим. 0-RTT - это для гуглей, клаудфлейров и мазохистов. А так - welcome back to HTTP/1.1 world, guys.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру