Комментарии 57
Однако, дело в том, что HTTP/1.1 поддерживает лишь одно внешнее соединение в любой момент времени.
А по факту — шесть и более
А по факту — шесть и более
НЛО прилетело и опубликовало эту надпись здесь
А вот такой вопрос.
Может ли сайт работать на HTTP/1.1, а статику раздавать на HTTP/2.0. Как такой симбиоз?
На некоторых проектах сразу перейти будет проблематично, а вот статику перенести хочется.
Может ли сайт работать на HTTP/1.1, а статику раздавать на HTTP/2.0. Как такой симбиоз?
На некоторых проектах сразу перейти будет проблематично, а вот статику перенести хочется.
НЛО прилетело и опубликовало эту надпись здесь
Просто сейчас статика отдается с нескольких поддоменов, что бы обойти ограничение количество соединений на домен.
Это конечно не есть хорошо.
Если статику вынести на один домен HTTP2, то хватит и только одного домена.
Зачем выносить?
Как минимум домен без cookies.
Вот, я думаю профит от этого действия.
Это конечно не есть хорошо.
Если статику вынести на один домен HTTP2, то хватит и только одного домена.
Зачем выносить?
Как минимум домен без cookies.
Вот, я думаю профит от этого действия.
Да. Уже вполне себе стандартный кейс (раздавать статику через server push).
НЛО прилетело и опубликовало эту надпись здесь
Вообще, конечно, подход ранних HTTP «одно соединение — один файл» — это полный провал. Я не знаю ни одного другого протокола который настолько же бессмысленно неэффективно использует TCP.
FTP? :)
Даже FTP немного лучше в этом плане, в FTP по крайней мере управляющее соединение постоянное.
В FTP «два соединения — один файл». Это не настолько же бессмысленно, это ещё лучше.
Вы не забывайте что это было вообще рождение самого интернета по сути, тогда вообще никто не знал во что это выльется и стоит ли вообще на это тратить время и силы, а особенно улучшать.
>Новые HTTP-методы — PUT, PATCH, HEAD, OPTIONS, DELETE
Head добавили еще в 1.0, в 1.1 появился TRACE, потом вроде patch.
Head добавили еще в 1.0, в 1.1 появился TRACE, потом вроде patch.
> Server push позволяет серверу снизить количество дополнительных запросов. Если он знает, что клиент собирается запросить данные, он сразу их посылает.
А откуда сервер узнаёт какие данные ещё запросит клиент? Ну вот на том же примере запроса страницы с картинками. Серверу нужно, во-первых, откуда-то знать какие ресурсы нужно отдавать с этой страницей, во-вторых, откуда-то знать какие ресурсы клиент уже загрузил, а какие — нет, чтобы не оказать медвежью услугу и не пулять данные, которые уже есть.
Да, кстати, клиент их вполне мог закэшировать и они ему не нужны вообще — особенно это касается статики.
В общем, не могли бы вы немного расскрыть этот момент?
А откуда сервер узнаёт какие данные ещё запросит клиент? Ну вот на том же примере запроса страницы с картинками. Серверу нужно, во-первых, откуда-то знать какие ресурсы нужно отдавать с этой страницей, во-вторых, откуда-то знать какие ресурсы клиент уже загрузил, а какие — нет, чтобы не оказать медвежью услугу и не пулять данные, которые уже есть.
Да, кстати, клиент их вполне мог закэшировать и они ему не нужны вообще — особенно это касается статики.
В общем, не могли бы вы немного расскрыть этот момент?
Посмотрите на опыт внедрения, описанный в этом посте.
А откуда сервер узнаёт какие данные ещё запросит клиент? Ну вот на том же примере запроса страницы с картинками. Серверу нужно, во-первых, откуда-то знать какие ресурсы нужно отдавать с этой страницей, во-вторых, откуда-то знать какие ресурсы клиент уже загрузил, а какие — нет, чтобы не оказать медвежью услугу и не пулять данные, которые уже есть.
При отдаче страницы мы сами указываем какие данные попадают в категорию «загрузить сразу». Прописывается в заголовках, соответственно это можно делать как на статике, так и на уровне бэкенда.
Да, кстати, клиент их вполне мог закэшировать и они ему не нужны вообще — особенно это касается статики.
Вот тут попрошу поправить меня уважаемых знатоков, но как я понял, этот процесс мы отслеживаем самостоятельно.
- Если клиент пришел на сайт первый раз — отдаем данные пачкой, получаем плюс в производительности.
- Если мы знаем, что клиент получил данные и использует кэш, все ок — не отдаем preload.
- Если мы «профилонили» и у клиента больше нет кэша, он запросит его сам. Но и здесь буст по сравнению с HTTP1, т.к. это будет сделано без открытия нового соединения *
* Если используются CDN-сервера или кросс-доменные соединения, то прироста в производительности не будет, т.к. в этом случае браузер будет открывать новые соединения.
Однако большинство производителей браузеров заявило, что они будут поддерживать HTTP/2 только тогда, когда он будет использоваться поверх TLS.
А вот это вот сильно печалит.
НЛО прилетело и опубликовало эту надпись здесь
А вот объясните, зачем шифровать содержимое страниц для неавторизированных пользователей? Подписи контента вполне хватило бы. Но нет, поленились делать.
Зачем принуждать использовать https? В подавляющем большинстве случаев он не нужен ни пользователям ни администраторам, да ещё и вредит.
НЛО прилетело и опубликовало эту надпись здесь
Он нужен всем пользователям и администраторам, просто они ещё об этом не знают.
Это только повод сменить провайдера.
И вообще, я не хочу, чтобы хоть кто-то читал то, что читаю я.
Людям с воспалённой приватностью в интернет вообще опасно ходить. И это не повод решать их страхи поголовным шифрованием. В тяжёлых случаях есть другие решения, которые осложняют жизнь только им.
НЛО прилетело и опубликовало эту надпись здесь
Я не пойму, как и чем осложняет жизнь шифрование на сайте? Пользователь вообще не заметит разницы, а админам только в плюс.
Администраторам — лишнее усложнение системы, необходимость отслеживать сертификаты (Let's Encrypt не предлагать) и нагрузка на сервера. Да и тот же SNI далеко не всегда корректно работает у клиентов и при множестве доменов бывают косяки.
Пользователям — лишняя нагрузка, особенно чувствительная на мобильных устройствах. Проблемы со SNI. Лишняя задержка на установку TLS соединения, которая может легко сожрать плюсы HTTP/2.
А сколько старого контента на серверах, за которыми особо никто не следит, сгинет при просроченном сертификате?
Я не против шифрования, но всему своё место.
НЛО прилетело и опубликовало эту надпись здесь
Действительно, есть проблема, решение не предлагать, будем мучатся.
Они не дают достаточный уровень сертификации.
Пользователя IE6 за клиента не считаю.
Если бы только IE… И у тех, кто поддерживает — тоже бывают сбои.
НЛО прилетело и опубликовало эту надпись здесь
winldcard сертификаты, сертификаты с проверкой организации и тп.
НЛО прилетело и опубликовало эту надпись здесь
Это был ответ на вопрос, почему Lets encrypt не подходит; и почему требования обязательного шифрования, если хочется использовать HTTP/2, огорчают.
НЛО прилетело и опубликовало эту надпись здесь
А если корпоративному сайту, да не одному, нужно HTTP/2 но нафиг не сдалось шифрование?
НЛО прилетело и опубликовало эту надпись здесь
Дожили — Edge единственный стремится соблюдать спецификации…
И «корпоративный» — не значит для внутреннего пользования.
И «корпоративный» — не значит для внутреннего пользования.
НЛО прилетело и опубликовало эту надпись здесь
Потому что бесплатный сертификат не удовлетворяет требованиям сертификации компании.
Как-то дискуссия по кругу пошла :).
В общем подытожу свою точку зрения:
1. Всеобщее шифрование — ненужная трата ресурсов в угоду моде приватности.
2. Позиция основных браузероделов по принуждению к https — пиар на этой моде и преследование своих целей.
3. HTTP/2 — хорошо, но позиция вышеперечисленных сильно сократит его использование.
Как-то дискуссия по кругу пошла :).
В общем подытожу свою точку зрения:
1. Всеобщее шифрование — ненужная трата ресурсов в угоду моде приватности.
2. Позиция основных браузероделов по принуждению к https — пиар на этой моде и преследование своих целей.
3. HTTP/2 — хорошо, но позиция вышеперечисленных сильно сократит его использование.
НЛО прилетело и опубликовало эту надпись здесь
Однако большинство производителей браузеров заявило, что они будут поддерживать HTTP/2 только тогда, когда он будет использоваться поверх TLS.
Вот это следование «стандартам» удивляет.
А еще удивляет поведение Google (с Chrome) — взяли, и отключили поддержку http/2 для сайтов, поддерживающих только NPN (без ALPN). Причина вроде как и есть, но вся штука в том, что внедрение http/2 этот выкрутас оттянул (потому что менять openssl на руками собранный, или менять ОС, или ждать обновления openssl для своей системы — все эти варианты не сильно, как оказалось, популярны; а чего хотел Гугл?).
Мне, как пользователю, такую логику «следования» стандартам (http/2 без tls делать не будем; npn поддерживать не будем) видеть в браузере несимпатично. Альтернатив особо нет, но и Chrome из апологета стандартов постепенно мигрирует в сторону старого IE по привычкам своих создателей :)
Насколько я помню, в стандарте на HTTP/2 прописан как раз ALPN, а не NPN (он был для SPDY).
А требование TLS для HTTP/2 обусловлено не только желаниями Google, но и проблемой с middle boxes, которые любят перерабатывать HTTP-трафик (Proxy, DPI и т.д.), при этом ничено не знают о HTTP/2.
Вы же не хотите внедрить новый протокол и узнать, что у 5% (например) пользователей возникают проблемы с вашим сайтом (с каким-нибудь древним офисным Proxy), которые вы никак исправить не сможете?
А требование TLS для HTTP/2 обусловлено не только желаниями Google, но и проблемой с middle boxes, которые любят перерабатывать HTTP-трафик (Proxy, DPI и т.д.), при этом ничено не знают о HTTP/2.
Вы же не хотите внедрить новый протокол и узнать, что у 5% (например) пользователей возникают проблемы с вашим сайтом (с каким-нибудь древним офисным Proxy), которые вы никак исправить не сможете?
Ну тут фраза про «шашечки или ехать» очень в тему будет: вы хотите, чтобы протокол быть точно таким, как на бумаге (и тогда ALPN-only, и с высокой колокольни плюем на всякие проксики в офисах), или предпочитаете, чтобы у всех работало хотя бы подмножество протокола (и тогда NPN и проксики уважаются).
А то, что приняли стандарт, до которого ПО еще расти (я про ALPN, который на старых версиях библиотек не получить), а потом начали делать послабления и костыли в нем, чтобы проблем с миддл-боксами не было — я и говорю, это двоемыслие сродни запуску IE6, мол, все равны, а мы ровнее".
Хочу ли я новый стандарт внедрить? У меня может быть две причины сделать это в отношении http/2: мультиплексирование соединений (что, по факту, позволяет всего лишь немного компенсировать накладные расходы TLS, а не сумасшедшим образом ускориться на фоне http/1.1), и как бы бесплатный TLS получить (что тоже неверно, т.к. TLS можно и с http/1.1 поднять).
«Компьютер помогает решить проблемы, которых не было до появления компьютера» — с http/2 иногда такое тоже случается. Тем более что Гуглы всякие сами сидят не на нем, а на QUIC. В общем, подняли смуту ребята, а сами в кусты ))
А то, что приняли стандарт, до которого ПО еще расти (я про ALPN, который на старых версиях библиотек не получить), а потом начали делать послабления и костыли в нем, чтобы проблем с миддл-боксами не было — я и говорю, это двоемыслие сродни запуску IE6, мол, все равны, а мы ровнее".
Хочу ли я новый стандарт внедрить? У меня может быть две причины сделать это в отношении http/2: мультиплексирование соединений (что, по факту, позволяет всего лишь немного компенсировать накладные расходы TLS, а не сумасшедшим образом ускориться на фоне http/1.1), и как бы бесплатный TLS получить (что тоже неверно, т.к. TLS можно и с http/1.1 поднять).
«Компьютер помогает решить проблемы, которых не было до появления компьютера» — с http/2 иногда такое тоже случается. Тем более что Гуглы всякие сами сидят не на нем, а на QUIC. В общем, подняли смуту ребята, а сами в кусты ))
А то, что приняли стандарт, до которого ПО еще расти (я про ALPN, который на старых версиях библиотек не получить), а потом начали делать послабления и костыли в нем, чтобы проблем с миддл-боксами не было — я и говорю, это двоемыслие сродни запуску IE6, мол, все равны, а мы ровнее".
Использование только с TLS это ограничение для гарантии работоспособности, а не костыль.
«Компьютер помогает решить проблемы, которых не было до появления компьютера» — с http/2 иногда такое тоже случается. Тем более что Гуглы всякие сами сидят не на нем, а на QUIC. В общем, подняли смуту ребята, а сами в кусты ))
Гуглы сидят в том числе и на нём и постоянно проводят эксперименты с другими протоколами (QUIC), в чем здесь проблема?
Одно соединение хуже чем 2, тем более 10 ибо окно передачи будет у хх соединений ощутимо больше и данные по хх соединениям передадутся быстрее чем по одному, как ты не извращайся
Почему это? Ничто не мешает на одном соединении иметь очень большой размер окна. Это же адаптивная величина — она растет (и увеличивается скорость передачи) до тех пор, пока не утилизируется весь канал и не начинаются потери пакетов. Если сервер и клиент настроены хорошо — то и в 1 коннект можно любой канал полностью забить.
Спасибо. Очень познавательная, а самое главное-конкретная статья.
Два бонуса для тех, кто читает комменты.
Если вы новичок и хотите узнать побольше, посмотрите:
1. Доклад http-протокол Алексея Бережного.
2. Курс «Компьютерные сети».
Если вы новичок и хотите узнать побольше, посмотрите:
1. Доклад http-протокол Алексея Бережного.
2. Курс «Компьютерные сети».
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Путь к HTTP/2