Разработчики Chrome намерены прекратить поддержку механизма Server Push в протоколах HTTP/2 и gQUIC, а также не реализовывать её для протокола HTTP/3, находящегося на стадии утверждения стандарта. В протоколе HTTP/1.1 технология Server Push не предусмотрена изначально. Причиной удаления является желание избавиться от большого усложнения в коде, на фоне невостребованности и лишь теоретических предпосылок в эффективности оптимизаций на основе Server Push...Подробнее: https://www.opennet.me/opennews/art.shtml?num=54069
Во больные
Предъявите ваш диплом доктора медицины.
Он не доктор.
«доктор медицины» - всм, лечащий медицину ?
До́ктор (лат. doctor, «учитель») — высшая учёная степень.
Нет. Он просто "лечит".
Ты дибилоид? Если у тебя коллега придет га работу, усядется рядом с тобой и будет высмаркивать килограмм соплей в минуту и кашлять легкими, то ты его больным не назовешь, потому что у тебя диплома доктора нет? Тогда ты точно дибилоид
приплетаю-ковидлу.jpg
От мифов надо избавляться.
вроде звучит разумно
Да еще когда они пропихивали это в HTTP2 им тогда говорили что это мало кому нужно, но нет "Мы Гугл, мы знаем лучше". ну и вот результат.
Нормальная технология, с ней можно огранизовать поток без жабаскрипта. С другой стороны это хромой, кому он нужен.
> не приводит к заметному ускорению загрузкиХромой не приводит к ускорению загрузки вообще, его надо удалить.
Лиса приводит? Удаляем!
"на стадии черновика"Но сначало нужно выкинуть сделанное не ими, "тама слишка сложный кот, насяльника!"
странно это слышать от тех, у кого сырцы хромиума весят 16 ГБ... Нет, он не сложный, а вот реализация кеша - О_о, <белая лиса> как сложно!
Сходная ситуация была у Мозиллы. Они долго пилили "мультипликацию HTTP соединений", чтобы параллельно грузить быстрее, но все это было очень на грани стандартов, поэтому на очень многих серверах глючило, что заставило их внедрить сложный эвристический механизм угадывающий будет ли мультипликация работать на конкретном сервере и потом долго упорно настраивать эвристику...
Короче, в какой-то момент вот это все разрослось до настолько монструозной конструкции что было принято решение выкинуть все целиком - и мультипликацию и эвристику, потому что это все тормозило браузер уже сильнее чем ускоряло.
> нужно выкинуть сделанное не имиТут они выкидывают сделанное ими, так что все ок.
Не знаю что такое Server Push, а читать лень. Но увидел в заголовеке "Chrome", поэтому осуждаю. Ставь плюсик, если тоже так сделал.
с удовольствием ставлю минус, ведь мне не лень читать новости, коли я их открываю
Сначала ввели, а потом выпиливают... гугл такой гугл
Да, они любят вводить своим пользователям
А у мазилки вводилка заржавела. и не rastёт. Теперь только языком.
Потенциал чуствую большой я юный подаван. Сторону не попутай главное ты !
Скорее гуглеры - такие гуглеры. Устроиться туда работать довольно трудно, но те кто уже устроились постоянно кодят какую-то хрень, ломают годами работающий функционал, а затем так же годами его не чинят.
ну так им за это денег платютстранно что они еще quic не задепрекейтили
Шоб в гугле рядовым сотрудникам и норм деньги платили.. смищноОсобенно с учётом того, что они очень любят нанимать подрядчиков
Гуглеры рукожопы от мира ИТ это общеизвестный факт
Да ладно вам. Вот я работаю на гугл не устраиваясь непосредственно туда.
Секрет прост - гугл очень любит подрядчиков, они дешевые и их можно увольнять сразу после завершения проекта.
А подрядчики все из мазилы?
> Вот я работаю на гугл не устраиваясь непосредственно туда.А за мысли неправильные или чтение чужих но тоже неугодных - не уволят ? Давай затестим !
Да если бы были хоть какие-то конкуренты, то Гугл бы ещё и не такие переусложнённые велоспеды через стандарты навязывал...
А так оказывается что "да неоченьто оно и нужно" и "HTTP/1.1 хватит всем"
> Да если бы были хоть какие-то конкурентыПро Edge не слышали?
Тонко. Зачот.
> Про Edge не слышали?И он тоже уже на Chromium. А вообще принципиально осталось три браузера: chrome, firefox и safari. А если считать chrome и safari как один WebKit, так и вообще два.
> chrome и safari как один WebKitу хрома блямк вроде...
Который суть плоть от плоти вебкита, только банановый.
Ага, а все они KHTML. На самом деле, Blink давно в сторону убежат от WebKit, там все меньше общего остается.
Сам ты опасный. Учи матчасть.
> Сам ты опасныйСпасибо.
> Учи матчасть.Спасибо.
Ты на пенёк сел?
> А если считать chrome и safari как один WebKitА на каком основании, если даже js-движки у них ощутимо разные ?
> А на каком основании, если даже js-движки у них ощутимо разные ?Ну если уж совсем точно то WebCore. WebKit - это же ЕМНИП WebCore (DOM, CSS, SVG и вот это всё) и JSCore (JS-движок). Google от WebCore форкнули в Blink и прикрутили свой JS-движок V8.
О том и речь, что разница ощутима:
жс движки разные, веб-движки - разные( с момента форка оба сильно изменились )
Их едва ли корректно под один вебкит( у которого jscore, а не v8 ) группировать
Нельзя считать chrome и safari как один, blink сильно оторвался вперед за 7 лет, в webkit до сих пор баги рендера которые были в хроме лет 6 назад, по поддержке новых стандартов в webkit отстает больше чем в firefox.Кстати, большинство багов рендера воспроизводятся в gtkwebkit(например в epiphany), при этом запустить под виндой современный webkit кране муторно.
> но не приводит к заметному ускорению загрузки по сравнению с упреждающим запросом ресурсов через тег "preload", а по данным некоторых исследований даже увеличивает задержки.Ведь могут. Могут померять, подумать, и оставить глупости.
Почему с масками так не получается? https://pashev.me/posts/why-masks
Во-первых, оффтоп.
Во-вторых, пропаганда потенциально опасного поведения.
Осталось еще сам http/2 теперь тоже выпилить, вот умора-то будет
Так уже все на http3 нацелились т.к. http2 "не получило должного распространения"
Хз насчет этого. У меян в Лисе стоит аддон показывающий что сайт использует HTTP2. Как ни странно, таких нынче очень даже немало. И не только крупняк, уже и в общем относительная мелочь часто на HTTP2. Опеннет конечно не пример.
> Опеннет конечно не примерРетроградство, бывает, очень сильно выручает. Яркий пример - в фильме и сериале "Крейсер Галактика". В-)
ХАХАХАХАХА. Но на самом деле это хорошая новость, потому что идея изначально была дно.
Вы про Server Push или Chrome?
Переусложненный протокол, неочевидные выгоды - об этом говорили с самого начала. Но всё равно эту дичь пропихнули и стандартизовали. Это всё, что надо знать о текущем уровне инженерии в гугле, который всё больше напоминает слона в посудной лавке.
А им некогда сейчас разработкой заниматься, надо словари составлять разрешённых слов.
>Наш QUIC никому даром не нужен, а значит надо http/2 прибить.Ясно.
>При помощи Server Push сервер может отправить ресурсы клиенту, не дожидаясь их явного запроса.нет чтобы юзать православный json-rpc 2.0
> не дожидаясь их явного запросаТ.е серверную часть ещё больше придётся смешивать с клиентской, чтобы она знала (!) лучше клиентской части, что ей вот-вот потребуется
Это заведомо эпический цЫрк и плохой подход. Хотя, гуглу не привыкать
Да легко, посадить на сервер ИИ, который будет наблюдать за последовательностью запросов и предлагать варианты, основываясь на истории.
А если фронтенд периодически дорабатывается, то что с накопленной статистикой делать ?)Т.е вместо того, чтобы просто на фронте прописать загрузку допресурсов, но после основных и тендера страницы, предлагаете прикручивать черти какой ИИ, вести отдельную статистику и париться с её актуализацией и, более того, ещё и место в БД подо всё это творчество выделять.. не жирно ли для такой примитивной «задачи» и это точно приведёт к СНИЖЕНИЮ потребления ресурсов, если речь о выдаче статики ?
Почитай, как кеши в процах протухают, и как бедненький проц с этим справляется... да уж, прям невыполнимая задача. Надо срочно удалить все кеши.
Если 100500 раз вслед за html загрузили css, то, однако, и на 100501-ый раз тоже css понадобится.
Мама, что такое кэширование?
Сынок, не забудь опять завтра букварь в школу взять.
Если проект живой, то на сайте постоянно что-то допиливают
И далеко не факт, что по итогу очередного изменения какой-то ранее необходимый файл будет требоваться.Тем более, что ничто не мешает их загрузку прописать на фронтенде, но после загрузки основных ресурсов
А сколько было пеара, сколько обещаний 10005000% ускорения загрузки рекламы...
Ещё немного и можно будет признать что и сам QUIC отрыжка технологий.
шеф, бунтуют! вытащить на полдюйма и лям на пропаганду!
> сам QUIC отрыжка технологийИзобретатель ARPANET утверждает, что использование UDP
для преодоления ограничений TCP — это путь в никуда.
Они это проходили в 1983-м с коллапсом NCP, в результате
Vint Cerf изобрёл TCP, оптимизированный для килобитных
или мегабитных скоростей. Для гигабит/с и терабит/с
нужен другой протокол надёжной передачи с контролем потока,
с поддержкой на уровне сети (маршрутизаторов).> 10005000% ускорения загрузки рекламы.
И чрезмерным заполнением каналов невостребованными пакетами UDP,
которые отсылаются по принципу: "Ах, мы потеряли один пакет — вот вам
N таких же, даст бог, какой-то из них пробьётся".
Для гигабитных скоростей TCP всё ещё вполне хватает, даже не знаю сколько нынче потолок TCP в один конект для обычных OS без супертюнингов, но дуюма 10Г должны переварить все.
А дальше начинаются проблемы не только с TCP но и с тем откуда столько взять и куда это потом деть.Маршрутизатор то тут причём!?
Он смотрит в заголовок IP пакета, а что там дальше его не интересует совсем.Если где и будут проблемы - так это с кучей домашних железок, где IPv4 NAT используется, потому что оно в основном умеет только TCP/UDP, иногда gre и что то ещё.
> Для гигабитных скоростей TCP всё ещё вполне хватает,
> TCP в один конект для обычных OS без супертюнингов,Часто приходилось перезаливать десятки терабайт контента из Европы в Штаты и обратно.
С обеих сторон linux, 10 Гбит/с интерфейсы. Так вот, если в один поток, то скорости
от 160 до, примерно, 360 Мегабит/с. Крайне редко — до 0,5 Гбит/с. А вот если в несколько
потоков зарядить, тогда ограничение наступает по скорости записи на storage.> Маршрутизатор то тут причём!?
Ну вы же не слушаете, что вам говорят.
Еще раз, Larry Roberts: TCP нужно выкинуть, а вместо него внедрить протокол, в котором
управлением потоком будет заниматься сеть (DCE, маршрутизатор и т.д.), оптимизированный
для гигабитных скоростей. С этим QUIC (долой UDP, да здравствует UDP) стало понятно,
что ребята решили прогуляться по тем же граблям, которые были в 80-х годах с NCP.
Перекладывание на маршрутизатор чревато тем что каждый админ роутера будет считать себя властителем инета и что ему, как вахтёру, все должны.Если вы хотите скорости выше на линухе - тюньте сетевой стёк, вы же поди на дефолтах сидели, а там уныный cubic.
> Перекладывание на маршрутизатор чревато …… не более, чем сейчас.
Это всё уже было. Просто вы, видимо, не застали.
Контролем потока занимались PAD'ы. Просто из-за
слабости процессоров в то время (m68k, 6502 и т.д.)
Vint Cerf сотоварищи при переходе с NCP на TCP решили
перекинуть эту задачу на конечные точки соединения.
Тогда думали, что в течение десяти лет все плавно
перейдут с TCP/IP на протокол ISO. Этого не случилось
по известным причинам.> Если вы хотите скорости выше на линухе - тюньте сетевой стёк,
> вы же поди на дефолтах сидели, а там уныный cubic.А это кто писáл, Пушкин?:
— Для гигабитных скоростей TCP всё ещё вполне хватает, даже не знаю сколько нынче потолок TCP в один конект для обычных OS без супертюнингов, но дуюма 10Г должны переварить все.Larry Roberts же вам объяснил, что из-за того, что TCP надо "тюнить" под каждый чих [(1)диапазон задержек (2) диапазон потерь] (иначе он не даёт ожидаемой производительности), инженеры этих ваших энторнэтов придумали ничего лучше, чем пускать трафик по UDP. А это чревато засорением каналов ненужным трафиком. Вместо этого для эффективного использования полосы пропускания нужно внедрять протокол, в котором контролем потока будет заниматься сеть, а не конечное устройство.
Я это всё в третий раз пишу, но, думаю, до вас не дойдёт.
" Для гигабитных скоростей TCP всё ещё вполне хватает, "
пусти его по вайфай с 5% потерь пакетов или 4g в поезде - и посмотри какой процент реально доступного канала оно сможет прогрузить, когда кубик архаичный уйдет в тормоза по минутену а вот в udp можно пакеты в программе самому шедулить - с tcp так не получится, особенно в винде
" С этим QUIC (долой UDP, да здравствует UDP) стало понятно, "
а что там не понятно, в винде нельзя свой шедулинг tcp сделать, вот все и любят удп когда архаичные кубики задолбали
Проблема в том что всем нас*** на производительность своих сайтов. А отправка PUSH сродни сокращению TTL про это не думают 99,95% разработчиков сайтов.
Наверное не TTL а rtt.
Разработчики сайтов в общем и не должны об этом думать, это не их область компетенций.
Ну, я вот ставлю себя на место разработчика вебсайта. Первый вопрос на кой хер мне заливать клиенту то, что ему скорее всего не нужно? Тупо трафик погонять? Трафик кстати стоит денег. Второй вопрос, с учетом того, что веб-разработка идет совсем иным путем (аля ajax-запросы) + паковка всего кода в страницу SPA, то накой нужна вообще эта технология, нету юзкейса в SPA, где этот Server Push вообще как-то пригодится. Наоборот, это рушит концепцую SPA.
с точки зреения разработчика надо какой-то список взаимозависимостей создавать, и еще серваку это в понятном ему виде прописать, это много возни а выигрыш небольшой, вот все и забили
И они ещё спрашивают почему столько консервативных разработчиков? Понапиваются смузи, наплодят технологий и языков, а потом два раза удивляются: почему технологию не хотят осваивать разработчики и почему эту технологию - которую мы решили выкинуть - начали осваивать разработчики.
Лавров.jpg
Ну вообще говоря, логические потоки внутри HTTP сессии напрашивались давно. Так что кое-что у них получилось ок. Дропнуть User-Agent это тоже хорошая идея.
Окей, юзерагента нет.
Как более-менее универсально определять на стороне сайта браузер и версию( даже чтобы банально сказать, что он старое г.но и пора обновиться для корректного ото радения сайта ) ?
> Как более-менее универсально определять на стороне сайта браузер и версию( даже чтобы банально сказать, что он старое г.но и пора обновиться для корректного ото радения сайта ) ?Никак. Ты и с User-Agent это не можешь. Более того, это не нужно, особенно для того случая, что ты привел. Делайте сайты по стандартам и перестаньте быдлокодить.
> Никак. Ты и с User-Agent это не можешь. Более того, это не
> нужно, особенно для того случая, что ты привел.Могу, если пользователь сам его не изменил( но тут уж его проблемы начинаются ).
> Делайте сайты по стандартам и перестаньте быдлокодить.
И более-менее свежие фичи html, css и js от этого внезапно заработают на г.не мамонта в лице какого-нибудь ИЕ8 ?
Если начинать углубляться в какие-то специфические детали, то очень много нюансов появляется.
Доходит вплоть до того, что один и тот же браузер, но разных типов( десктоп / мобильный ) может работать и выполнять скрипты по разному, может иметь разный браузерный апи и особенности его исполнения.. даже один и тот же мобильный браузер, но в андройде и на яблоке могут ощутимо различаться.И, в общем-то, для многих не секрет, что у разных браузеров более чем немало своего, браузероспецифичного.
Просто, обычно используют библиотеки и модули, в которых подобная проблема, мб с кучей костылей и мусора, но решена.
Но не для всех случаев жизни существуют подобные модули.
> Могу, если пользователь сам его не изменил( но тут уж его проблемы начинаются ).Ну вот видишь. Если не изменил, если браузер репортит, если твой серверный код распознал правильно.
> И более-менее свежие фичи html, css и js от этого внезапно заработают на г.не мамонта в лице какого-нибудь ИЕ8?
Если не заработают, то пользователь поменяет свой браузер на поддерживаемый.
> <много страданий из мира веб-разработки>
В мире по сути остались три браузера: хром, фуррифокс и сафари. Они вполне способны договориться о следовании стандартам. Хватит всего этого рака.
Feature detection. Если не проходит, пишешь "что он старое г.но и пора обновиться". Зачем тебе именно версия? Очень хочешь писать "ваш хром 54 устарел, обновите как минимум до 72"?
https://developer.mozilla.org/en-US/docs/Web/HTTP/Browser_de...
> 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.
> 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)
> );
> }
> }ИМХО, такое себе решение с кучей костылей на пару десятков строк кода для проверки лишь одного-единственного параметра
>ТЗ требует некорректной работы на браузерах ниже определенной версииПофиксил, не благодари.
>>По статистике Google технология Server Push не получила должного распространения.Ну так потому что сырая технология. Вы с таким же успехом можете HTTP/3 выпиливать и вайланд. Нет у них должного распространения.
вайланд уже 12 лет как сырой, сколько еще лет нужно, чтобы он перестал быть сырым
Это не наш путь. (с)Mozilla Corporationdom.push.enable = false
dom.push.connection.enabled = false
dom.push.serverURL = ""
dom.webnotifications.enabled = false
dom.webnotifications.serviceworker.enabled = false
dom.serviceWorkers.enabled = false
firefox.enable = false
> firefox.enable = false
>firefox.google_donate.disable = true
>firefox.crash_segfualt.enable = rip
В новости речь немного не об этом, но да.
Мазилафаги люто минусуют. Видно, пахнуло жареным.
уже давно запахло и разработчиков уволили, остался только маркетинг
во, а тут только какой то горе оптимизатор нанятый рассказывал, что у нас всё медленно потому что у нас сервер пуш не применяется.. не, его конечно послали лесом и не только по этому. но ктото ведь на них ведется. ща такие бросят всё, навставляю.т пушей. получат минус 5% прироста производительности (т.к. серверный код станет в разы толще, то станет только медленнее), а тут бац, вторая смена, выпиливаем...
И станет на 5% быстрее!! Успех!
На 2%, ведь из проекта обычно выпиливается не весь мусор
На самом деле новость читать следует так:
"мы не смогли осилить кэш браузера, звонок другу в Бангалор ничего не дал, по этому будете без кэша, и как следствие без server push".
Я не шучу, в хромом это именно так и есть, и то давно, годами. Кто считает, что хромой правильно умеет работать с кэшем - пускай первый бросит в меня коммент.
эх, а вот в опере какой православный кэш был)
1. Не знаю как там у большинства - я на своём сайте использую.
2. Собрал все js в один файл и все css в один файл и отдаю server push-eм. Убыстрение очень даже заметно!https://webpagetest.org/result/201112_Di2S_ab008a11f94d57e4e...
Вывод:
Ну гады хромоногие :(
3. Собери всё html+js+css в один файл, и будет тебе тру профит!
Иногда лучше молчать чем говорить!
Вот как бы да. Лучше бы ты молчал.
Ну дошло наконецто. Изначально было понятно что это кривохак. Хоть что-то действительно бесполезное вырезали.А у iPony наверное вообще когнетивный диссонанс. Как-это так? Новую модную технологию вырезали.
а этой технологией кто-то вобще пользовался, хотя-бы этот ваш ифон?
В чем смысл?
Гугл не осилили то, что сами толкали в стандарт http/2
Это я понял, в чем смысл пилить http3 с руками из жопу у гугла? Лучше уж вернуться к проверенному HTTP 1.1
То есть как "В чем"? В том что нагрузка на серверы гугла снизится на 3 или даже целых семь процентов.Проооофит!
А что возрастет нагрузка на инфраструктуру и всем кроме гугля работать станет хуже - так это... опять проооофит!
А http 1.1 скоро запретят - небезопастно, немодно, и вообще не гуглеугодно. После его отключения (или небольшой порчи) на ютрупчике - ты и сам быстро зак...ешь свой неправильный браузер.
с разморозкой, уже дофига сайтов http/2 используют во всю, а станет >90% юзерей таких, так и уберут 1.х для упрощения кодовой базы
gRPC всё R.I.P
> Поддержание подобного кэша [...] не приводит к заметному ускорению загрузкиВыяснить это ДО отправки запроса на принятие в стандарт гугл, конечно, был не в состоянии.
пусть еще свою билдсистему из хромиума удалят, вот уж что сложное в использовании
Сначала топим за технологию, потом топим саму технологию.
Короче вот это вот самое вау-новшество всего смузи/2, которым его усиленно проталкивали, в итоге оказалось никому не нужным.Из единственного оставшегося полезным там - мультистрим. 0-RTT - это для гуглей, клаудфлейров и мазохистов. А так - welcome back to HTTP/1.1 world, guys.