| 1.1, Аноним (-), 21:11, 20/02/2018 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– | |
Если взглянуть на график, то http/2 заметно медленнее обычного http, несмотря на то, что его создавали для ускорения. Даже обычный preload с http почти не отстаёт по скорости от HTTP/2 Server Push. И никто не учитывает expire time, при HTTP ресурс загрузится один раз и месяц будет браться браузером из кэша. А при Server Push каждый раз будет загружаться клиенту.
Спрашивается, ради чего все эти сложности?
| | |
| |
| 2.3, Аноним (-), 21:52, 20/02/2018 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Спрашивается, ради чего все эти сложности?
Ну для вас это сложности. Для гугла и фейсбука - нет.
| | |
| 2.6, Аноним (-), 22:10, 20/02/2018 [^] [^^] [^^^] [ответить]
| –3 +/– | |
> Спрашивается, ради чего все эти сложности?
Работа ради работы - деятельность нужна работникам, их руководителям, руководителям этих руководителей и т.д., это их хлеб. Пользователям это обойдется в виде необходимости обновления, трафика на обновление, расходу места под хранение допольнительного кода, расход дополнительных ресурсов в работе программы (браузера) и в целом отягощение работы браузера и всей системы.
| | |
| |
| |
| 4.11, Аноним (-), 01:06, 21/02/2018 [^] [^^] [^^^] [ответить]
| +15 +/– |
Это версионный фашист. Все кто пользуются не самой последней версией по его мнению должны умереть.
| | |
|
|
| 2.10, Crazy Alex (ok), 00:00, 21/02/2018 [^] [^^] [^^^] [ответить]
| +/– |
 Чтобы избавиться от нешифрованного HTTP, не потеряв время на лишнем раундтрипе, добававишемся за счёт поднятия TLS-сеанса.
И он не медленнее - медленнее (было) установление соединения, а не дельнейшая работа. При этом соединение в нём, в отличие от HTTP 1.1, одно.
Вообще - ну въедь ты в тему прежде чем вопросы задавать, а?
| | |
| |
| 3.12, Аноним (-), 01:08, 21/02/2018 [^] [^^] [^^^] [ответить]
| +/– |
Ты ещё поди за сустемг в том же ключе топил пару лет назад? "Скорость наше всё, вы все #*дарасы, не желающие приобщиться к прогрессу!111"
| | |
| |
| 4.23, Crazy Alex (ok), 19:33, 21/02/2018 [^] [^^] [^^^] [ответить]
| –1 +/– | |
Я на системг только что матом не ругался. Потому что кривые архитектурные решения, попытки сделать монолит там, где он ен нужен и убогий код. А был бы он сделан нормально - не ругался бы, шелл-скрипты для стандартных задач - это тупость.
А HTTP/2 - вполне логичная штука, в отличие от открытия кучи соединений на один сайт для параллельной загрузки контента. Да и полный переход на шифрованную передачу данных я всячески поддерживаю.
| | |
| |
| 5.29, Макс (??), 12:46, 22/02/2018 [^] [^^] [^^^] [ответить]
| +/– |
Даже между двумя, рядом стоящими серверами, изолированными от внешнего мира?
| | |
| |
| 6.34, XoRe (ok), 15:37, 24/02/2018 [^] [^^] [^^^] [ответить]
| +/– |
 > Даже между двумя, рядом стоящими серверами, изолированными от внешнего мира?
Зависит от того, как сделаете у себя вы.
| | |
|
|
|
| 3.13, Аноним (-), 01:16, 21/02/2018 [^] [^^] [^^^] [ответить]
| +/– |
Ради избавления от лишнего rtt в tls 1.3 сделали zero rt.
На мобильном интернете несколько соединений — лучше чем одно, потому что канал не стабилен (как ты думаешь, почему современные браузеры по http1.1 устанавливают от 4х до 8ми соединений сразу?). Задач у http2 только две: меньше соединений на сервер, впихивание контента ДО его запроса. Догадаешься, какой контент гугл будет впихивать вместе самым частоиспользуемым iframe в мире или подсказать? В качестве факультатива можешь изучить, как подходит рендеринг страницы в хромиуме при h/2 и в какой момент в этот процесс может вмешаться плагин.
| | |
| |
| 4.14, Аноним (-), 01:34, 21/02/2018 [^] [^^] [^^^] [ответить]
| +/– | |
> при h/2 и в какой момент в этот процесс может вмешаться плагин
мол все хорошо, но… барабанная дробь — uBlock Origin заблочил параллельную загрузку.
| | |
| |
| 5.19, Аноним (-), 04:32, 21/02/2018 [^] [^^] [^^^] [ответить]
| +/– |
Невероятно. И с учетом этого смыслом сущестования HTTP/2 Server Push будет ... ??
| | |
|
| 4.16, Аноним (-), 02:43, 21/02/2018 [^] [^^] [^^^] [ответить]
| +/– | |
> Догадаешься, какой контент гугл будет впихивать вместе самым частоиспользуемым iframe в мире
Вообще-то для этого есть флаг SETTINGS_ENABLE_PUSH, который можно установить на клиенте при создании соединения.
А для насильственного трекинга, которого все так боялись при обсуждении спецификации, давно и успешно используется обычный заголовок ETag (с HTTP/1.0). У него меньше потенциальных сайд еффектов, чем у HSTS, и большинство клиентов постремаются его блокировать, особенно если цеплять к массивным ассетам (например здоровой фоновой картинке).
| | |
| 4.17, Аноним (-), 02:54, 21/02/2018 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> (как ты думаешь, почему современные браузеры по http1.1 устанавливают от 4х до 8ми соединений сразу?)
Как ты думаешь, откуда взялся порог от 4 до 8 к серверу в браузерах? И почему это привело в те годы к рождению cdn-на-коленке чисто для обхода этого лимита?
Подход h2 с мультиплексированием адекватнее.
> В качестве факультатива можешь изучить, как подходит рендеринг страницы в хромиуме при h/2 и в какой момент в этот процесс может вмешаться плагин.
В момент onBeforeRequest? А в firefox 57+ есть ещё и filterResponseData с фильтрацией ответа до передачи парсеру браузера https://github.com/gorhill/uBlock/issues/3069
| | |
| 4.24, Crazy Alex (ok), 19:41, 21/02/2018 [^] [^^] [^^^] [ответить]
| +1 +/– | |
Мне абсолютно наплевать, как в хромиуме что делается. Возможности протокола - это хорошо. Браузер, заботящийся о моих интересах и подходящий набор расширений - тоже хорошо.
А как раз зачем по http 1.1 устанавливают несколько соединений я знаю отчлино - потому что, в отличие от http/2, он по одному соединению может только один объект отдавать в один момент времени. И чтобы получить параллельную загрузку нужны такие вот костыли.
Что до ифрейма - он никак не может прилететь через этот пуш, так как для этого контент должен быть на том же сервере, куда сделан запрос, а аналитика - на своём живёт. А если что-то подобное будет на том же сервере - так там и пуша не надо, так будет загружен (и заблочен NoScript и uBlock).
| | |
| 4.35, XoRe (ok), 15:40, 24/02/2018 [^] [^^] [^^^] [ответить]
| +/– |
> На мобильном интернете несколько соединений — лучше чем одно, потому что канал
> не стабилен (как ты думаешь, почему современные браузеры по http1.1 устанавливают
> от 4х до 8ми соединений сразу?)
Ну уж явно не из за нестабильного интернета, а ради распараллеливания нагрузки.
| | |
|
| 3.36, Аноним (-), 08:58, 27/02/2018 [^] [^^] [^^^] [ответить]
| +/– |
> И он не медленнее - медленнее (было) установление соединения, а не дельнейшая
> работа. При этом соединение в нём, в отличие от HTTP 1.1,
> одно.
Кстати, именно это и является его проблемой. Т.к. при плохом канале(мобильный инет например) рвутся все мультиплексированные запросы, а не один; и в итоге он оказывается медленнее. Тут где-то была ссылка на подобное исследование.
Вообще, смешивание в кучу специализированных вещей как в http, так и в html-наборе раздражает. Браузеры становятся монструозными и тормозными. Всякая cms стремиться непременно использовать всё, что ей не надо.
| | |
|
| 2.18, Аноним (-), 02:55, 21/02/2018 [^] [^^] [^^^] [ответить]
| –2 +/– | |
Есть HTTP/2-сервера (например nghttpx) поддерживают режим без SSL.
Проблема не в самом HTTP/2, а в производителях браузеров, лоббирующих свою SSL-шаражку.
| | |
| 2.20, qwerty_qwert1 (?), 09:23, 21/02/2018 [^] [^^] [^^^] [ответить]
| +/– |
Изначально, чтобы в момент времени t быть уверенным что файлы 1,2,3 уже загружены.
Все остальное это уже потом домыслили.
| | |
|
| 1.21, Ilya Indigo (ok), 11:56, 21/02/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
 > Глобальный кэш браузера имеет больший приоритет, чем кэш соединения HTTP/2, поэтому даже если push-запросом был передан более свежий ресурс, браузер продолжит использование ресурса из своего глобального кэша.
Гениально!
| | |
| |
| 2.22, Аноним (-), 12:24, 21/02/2018 [^] [^^] [^^^] [ответить]
| –1 +/– | |
Именно, бесполезный механизм который невозможно синхронизировать с алгоритмами кеша на клиенте.
HTTP/2 поставлен под сомнения, так как он тащит все legacy поля из HTTP/1.1.
| | |
| 2.26, Астролог (?), 23:28, 21/02/2018 [^] [^^] [^^^] [ответить]
| +/– |
Гениально было бы раздавать кэш через deb пакеты, а так шило на мыло.
Вообще очень похоже что едиственный смысл http/2 пересадить всех на https, который как бы не обязательный но почему то все браузеры при работе по http/2 его требуют.
| | |
|
| 1.25, xm (ok), 22:46, 21/02/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Графики ускорения загрузки/отображения сайта при грамотной реализации push подтверждают мои замеры с использованием H2O которые я приводил в предыдущей версии этой новости.
| | |
| 1.27, Аноним (-), 07:04, 22/02/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Смехотворно... официальная версия Nginx 1.13 не умеет даже полную спецификацию HPACK по RFC7541.
| | |
| |
| 2.31, xm (ok), 18:46, 22/02/2018 [^] [^^] [^^^] [ответить]
| +/– |
Да он дофига чего пока не умеет. В отличие от H2O.
| | |
| |
| 3.32, Аноним (-), 02:21, 23/02/2018 [^] [^^] [^^^] [ответить]
| +/– | |
> Да он дофига чего пока не умеет. В отличие от H2O.
Он и либой быть не умеет. И модули програмить очень геморно. Так что для нестандартных скоростных инсталляций nginx очень геморроен. Еще разработчики H2O не выделываются с системой контроля версий. Есть себе обычный гитхаб - и на том спасибо. Лучше чем hg какой-то там.
| | |
|
|
| 1.28, Аноним (-), 07:06, 22/02/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Если вам нужно сжатие заголовков для мобильного трафика из протокола HTTP/2.0 - Nginx вам не поможет он это не умеет практически...
| | |
|
