Comments 57
Однако, дело в том, что HTTP/1.1 поддерживает лишь одно внешнее соединение в любой момент времени.
А по факту — шесть и более
А по факту — шесть и более
UFO just landed and posted this here
А вот такой вопрос.
Может ли сайт работать на HTTP/1.1, а статику раздавать на HTTP/2.0. Как такой симбиоз?
На некоторых проектах сразу перейти будет проблематично, а вот статику перенести хочется.
Может ли сайт работать на HTTP/1.1, а статику раздавать на HTTP/2.0. Как такой симбиоз?
На некоторых проектах сразу перейти будет проблематично, а вот статику перенести хочется.
Если это разные домены или поддомены, то можно попробовать. Но такого профита, как от полного перехода, не будет.
Просто сейчас статика отдается с нескольких поддоменов, что бы обойти ограничение количество соединений на домен.
Это конечно не есть хорошо.
Если статику вынести на один домен HTTP2, то хватит и только одного домена.
Зачем выносить?
Как минимум домен без cookies.
Вот, я думаю профит от этого действия.
Это конечно не есть хорошо.
Если статику вынести на один домен HTTP2, то хватит и только одного домена.
Зачем выносить?
Как минимум домен без cookies.
Вот, я думаю профит от этого действия.
Да. Уже вполне себе стандартный кейс (раздавать статику через server push).
UFO just landed and posted this here
Вообще, конечно, подход ранних 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.
А сколько старого контента на серверах, за которыми особо никто не следит, сгинет при просроченном сертификате?
Я не против шифрования, но всему своё место.
Let's Encrypt не предлагать
Действительно, есть проблема, решение не предлагать, будем мучатся.
Да и тот же SNI далеко не всегда корректно работает у клиентов
Пользователя IE6 за клиента не считаю.
Действительно, есть проблема, решение не предлагать, будем мучатся.
Они не дают достаточный уровень сертификации.
Пользователя IE6 за клиента не считаю.
Если бы только IE… И у тех, кто поддерживает — тоже бывают сбои.
Они не дают достаточный уровень сертификации.
В смысле?
winldcard сертификаты, сертификаты с проверкой организации и тп.
Мы сейчас до сих пор бесплатные сертификаты обсуждаем? Такие типы сертификатов никогда не были бесплатными, и не будут.
Они не нужны для простого обеспечения работы TLS, и полностью покрывают потребности тех, кому нужно просто шифрование.
Они не нужны для простого обеспечения работы TLS, и полностью покрывают потребности тех, кому нужно просто шифрование.
Это был ответ на вопрос, почему Lets encrypt не подходит; и почему требования обязательного шифрования, если хочется использовать HTTP/2, огорчают.
Не вижу смысла в этом доводе. Если у сайта вообще нет шифрования, то подойдёт любой сертификат, а если сайту нужен сертификат с проверкой организации и зелёной адресной строкой, то он так и так его купит. HTTP/2 тут вообще не причём.
А если корпоративному сайту, да не одному, нужно HTTP/2 но нафиг не сдалось шифрование?
Пускай тот корпоративный сайт использует Edge вместо браузера, он поддерживает HTTP/2 без SSL.
Дожили — Edge единственный стремится соблюдать спецификации…
И «корпоративный» — не значит для внутреннего пользования.
И «корпоративный» — не значит для внутреннего пользования.
Тогда не понимаю, почему бы не влепить туда бесплатный сертификат. Я думал там внутренний сайт, со своим внутренним доменом, на который сертификат не выписать.
Потому что бесплатный сертификат не удовлетворяет требованиям сертификации компании.
Как-то дискуссия по кругу пошла :).
В общем подытожу свою точку зрения:
1. Всеобщее шифрование — ненужная трата ресурсов в угоду моде приватности.
2. Позиция основных браузероделов по принуждению к https — пиар на этой моде и преследование своих целей.
3. HTTP/2 — хорошо, но позиция вышеперечисленных сильно сократит его использование.
Как-то дискуссия по кругу пошла :).
В общем подытожу свою точку зрения:
1. Всеобщее шифрование — ненужная трата ресурсов в угоду моде приватности.
2. Позиция основных браузероделов по принуждению к https — пиар на этой моде и преследование своих целей.
3. HTTP/2 — хорошо, но позиция вышеперечисленных сильно сократит его использование.
UFO just landed and posted this here
Однако большинство производителей браузеров заявило, что они будут поддерживать 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. Курс «Компьютерные сети».
Only those users with full accounts are able to leave comments. Log in, please.
Путь к HTTP/2