Л Програмери Цхроме-а су најавили да намеравају да престану да подржавају механизам Сервер пусх у ХТТП / 2 и гКУИЦ протоколима, као и да га не примењује за ХТТП / 3 протокол који је у стандардној фази одобрења. Сервер Пусх технологија од почетка није предвиђена у протоколу ХТТП / 1.1.
Разлог елиминације је жеља да се решимо велике компликације у коду, у контексту недостатка потражње и само теоретских предуслова за ефикасност оптимизација заснованих на Сервер Пусх-у.
Технологија Сервер Пусх је дефинисан у ХТТП / 2 стандарду и има за циљ оптимизацију учитавања података.
Поред прегледача заснованих на Цхромиум енгине-у, подршка за Пусх Пусх се тренутно примењује у Фирефоку и Сафарију, а на серверу у нгинку и Апацхеу хттпд.
Са Сервер Пусх-ом, сервер може клијенту послати ресурсе без чекања на ваш експлицитни захтев. Претпоставља се да на овај начин сервер може убрзати учитавање странице, јер ће ЦСС датотеке, скрипте и слике потребне за приказивање странице већ бити пребачене на њену страну када клијент то затражи.
Клијент се повезује и захтева одређену страницу, након чега сервер, на основу своје конфигурације или садржаја заглавља везе који је послао клијент, покреће пренос одређених ресурса путем већ успостављене ХТТП / 2 везе, не чекајући захтев за тим ресурсима од стране клијента.
Садржај пренесен путем пусх позива чува се на страни клијента у посебној кеш меморији повезаној са тренутном ХТТП / 2 везом.
Када у процесу приказивања странице клијент дође до захтева за ресурсе који су му повезани (цсс, јс, слике итд.), провера предмеморије се врши пре него што се сваки захтев стварно пошаље. Ако је ресурс сервер већ пренео и налази се у кеш меморији, клијент истовара тај ресурс из локалне кеш меморије без подношења спољног захтева серверу.
ХТТП / 3 је квази-РФЦ протокол који такође дефинише потискивање сервера.
Цхроме тренутно подржава руковање преносима преко ХТТП / 2 и гКУИЦ, а намера нам је да уклони подршку за оба протокола. Цхроме не подржава пусх овер ХТТП / 3, а додавање подршке није на путу.
Одржавање такве кеш меморије у великој мери компликује имплементацију Сервер пусх на страни клијента, али то не доводи до приметног убрзања оптерећења у поређењу са прелиминарним захтевом за ресурсом преко ознаке „прелоад“ и, према неким студијама, чак повећава латенцију.
Према Гоогле статистикама, Сервер Пусх технологија није правилно дистрибуирана. На пример, у последњих 28 дана 99,95% ХТТП / 2 веза није користило Сервер Пусх. Слични показатељи су примећени током студије у јуну 2019. године, односно нема пораста у применама Сервер Пусх-а.
Такође, ове године је прегледач користио само 40% порука које је примио Сервер Пусх, а пре две године ова цифра је износила 63,51% (сирове поруке су биле нетачне, нису се подударале са обрађеном страницом или су већ биле у кешу).
Уместо Сервер Пусх-а, ради оптимизације оптерећења странице, намерава да користи ознаку , на основу којих прегледач може да затражи ресурс без чекања на његову употребу на страници.
С једне стране, претходно учитавање, у поређењу са Сервер Пусх-ом, доводи до непотребне размене пакета (РТТ), али с друге стране спречава слање ресурса који се већ налазе у кеш меморији прегледача.
Генерално, разлике у кашњењу када се користе Сервер Пусх и предоптерећење сматрају се занемарљивим. Поред оптимизације оптерећења ресурса, механизам Сервер Пусх може се користити и за пренос података са сервера на клијента, али за ову сврху је погоднији протокол ВебТранспорт (заснован на КУИЦ) чија је стандардизација у фази израде .
izvor:https://groups.google.com