Путь к HTTP/2

[@varnav]

Однако, дело в том, что HTTP/1.1 поддерживает лишь одно внешнее соединение в любой момент времени.

А по факту — шесть и более

[@knott]

В 2015 в Google решили, что не должно быть двух конкурирующих стандартов, и объединили SPDY с HTTP, дав начало HTTP/2.

Звучит как многоходовочка.

[@swanrnd]

А вот такой вопрос.

Может ли сайт работать на HTTP/1.1, а статику раздавать на HTTP/2.0. Как такой симбиоз?
На некоторых проектах сразу перейти будет проблематично, а вот статику перенести хочется.

[@swanrnd]

Просто сейчас статика отдается с нескольких поддоменов, что бы обойти ограничение количество соединений на домен.
Это конечно не есть хорошо.

Если статику вынести на один домен HTTP2, то хватит и только одного домена.

Зачем выносить?
Как минимум домен без cookies.

Вот, я думаю профит от этого действия.

[@domix32]

TSL или таки TLS?

[@Evsign]

Да. Уже вполне себе стандартный кейс (раздавать статику через server push).

[@slonopotamus]

Вообще, конечно, подход ранних HTTP «одно соединение — один файл» — это полный провал. Я не знаю ни одного другого протокола который настолько же бессмысленно неэффективно использует TCP.

[@phoenixx]

FTP? :)

[@slonopotamus]

Даже FTP немного лучше в этом плане, в FTP по крайней мере управляющее соединение постоянное.

[@ruikarikun]

В FTP «два соединения — один файл». Это не настолько же бессмысленно, это ещё лучше.

[@ahdenchik]

FTP не так прост, как кажется: он был разработан чтобы контролировать передачу между любыми двумя серверами, не только между сервером и клиентом.

При этом управляющему передачей файла клиенту даже FTP-клиент не нужен — достаточно двух telnet-сессий с управляющим портом каждого из FTP-серверов.

[@Acuna]

Вы не забывайте что это было вообще рождение самого интернета по сути, тогда вообще никто не знал во что это выльется и стоит ли вообще на это тратить время и силы, а особенно улучшать.

[@slonopotamus]

Вы много можете назвать других протоколов тех времён так же неэффективно использующих TCP?

[@Acuna]

В 91-м? Другие протоколы для веба? Уж не Telnet ли вы имеете ввиду? Или может быть Gopher? Самое то для девочек, главное что фоточки можно лить, чем не интернет, ага…

[@pansa]

>Новые HTTP-методы — PUT, PATCH, HEAD, OPTIONS, DELETE
Head добавили еще в 1.0, в 1.1 появился TRACE, потом вроде patch.

[@pansa]

> Server push позволяет серверу снизить количество дополнительных запросов. Если он знает, что клиент собирается запросить данные, он сразу их посылает.
А откуда сервер узнаёт какие данные ещё запросит клиент? Ну вот на том же примере запроса страницы с картинками. Серверу нужно, во-первых, откуда-то знать какие ресурсы нужно отдавать с этой страницей, во-вторых, откуда-то знать какие ресурсы клиент уже загрузил, а какие — нет, чтобы не оказать медвежью услугу и не пулять данные, которые уже есть.
Да, кстати, клиент их вполне мог закэшировать и они ему не нужны вообще — особенно это касается статики.
В общем, не могли бы вы немного расскрыть этот момент?

[@aalexeev]

Посмотрите на опыт внедрения, описанный в этом посте.

[@LeamasRein]

А откуда сервер узнаёт какие данные ещё запросит клиент? Ну вот на том же примере запроса страницы с картинками. Серверу нужно, во-первых, откуда-то знать какие ресурсы нужно отдавать с этой страницей, во-вторых, откуда-то знать какие ресурсы клиент уже загрузил, а какие — нет, чтобы не оказать медвежью услугу и не пулять данные, которые уже есть.

При отдаче страницы мы сами указываем какие данные попадают в категорию «загрузить сразу». Прописывается в заголовках, соответственно это можно делать как на статике, так и на уровне бэкенда.

Да, кстати, клиент их вполне мог закэшировать и они ему не нужны вообще — особенно это касается статики.

Вот тут попрошу поправить меня уважаемых знатоков, но как я понял, этот процесс мы отслеживаем самостоятельно.

• Если клиент пришел на сайт первый раз — отдаем данные пачкой, получаем плюс в производительности.
• Если мы знаем, что клиент получил данные и использует кэш, все ок — не отдаем preload.
• Если мы «профилонили» и у клиента больше нет кэша, он запросит его сам. Но и здесь буст по сравнению с HTTP1, т.к. это будет сделано без открытия нового соединения *

* Если используются CDN-сервера или кросс-доменные соединения, то прироста в производительности не будет, т.к. в этом случае браузер будет открывать новые соединения.

[@Lelik13a]

Однако большинство производителей браузеров заявило, что они будут поддерживать HTTP/2 только тогда, когда он будет использоваться поверх TLS.

А вот это вот сильно печалит.

[@Regis]

А вот объясните, зачем шифровать содержимое страниц для неавторизированных пользователей? Подписи контента вполне хватило бы. Но нет, поленились делать.

[@Lelik13a]

Зачем принуждать использовать https? В подавляющем большинстве случаев он не нужен ни пользователям ни администраторам, да ещё и вредит.

[@Lelik13a]

Он нужен всем пользователям и администраторам, просто они ещё об этом не знают.

Это только повод сменить провайдера.

И вообще, я не хочу, чтобы хоть кто-то читал то, что читаю я.

Людям с воспалённой приватностью в интернет вообще опасно ходить. И это не повод решать их страхи поголовным шифрованием. В тяжёлых случаях есть другие решения, которые осложняют жизнь только им.

[@Lelik13a]

Я не пойму, как и чем осложняет жизнь шифрование на сайте? Пользователь вообще не заметит разницы, а админам только в плюс.

Администраторам — лишнее усложнение системы, необходимость отслеживать сертификаты (Let's Encrypt не предлагать) и нагрузка на сервера. Да и тот же SNI далеко не всегда корректно работает у клиентов и при множестве доменов бывают косяки.
Пользователям — лишняя нагрузка, особенно чувствительная на мобильных устройствах. Проблемы со SNI. Лишняя задержка на установку TLS соединения, которая может легко сожрать плюсы HTTP/2.
А сколько старого контента на серверах, за которыми особо никто не следит, сгинет при просроченном сертификате?

Я не против шифрования, но всему своё место.

[@Lelik13a]

Действительно, есть проблема, решение не предлагать, будем мучатся.

Они не дают достаточный уровень сертификации.

Пользователя IE6 за клиента не считаю.

Если бы только IE… И у тех, кто поддерживает — тоже бывают сбои.

[@Lelik13a]

winldcard сертификаты, сертификаты с проверкой организации и тп.

[@Lelik13a]

Это был ответ на вопрос, почему Lets encrypt не подходит; и почему требования обязательного шифрования, если хочется использовать HTTP/2, огорчают.

[@Lelik13a]

А если корпоративному сайту, да не одному, нужно HTTP/2 но нафиг не сдалось шифрование?

[@Lelik13a]

Дожили — Edge единственный стремится соблюдать спецификации…
И «корпоративный» — не значит для внутреннего пользования.

[@Lelik13a]

Потому что бесплатный сертификат не удовлетворяет требованиям сертификации компании.
Как-то дискуссия по кругу пошла :).
В общем подытожу свою точку зрения:
1. Всеобщее шифрование — ненужная трата ресурсов в угоду моде приватности.
2. Позиция основных браузероделов по принуждению к https — пиар на этой моде и преследование своих целей.
3. HTTP/2 — хорошо, но позиция вышеперечисленных сильно сократит его использование.

[@dmitry_ch]

Однако большинство производителей браузеров заявило, что они будут поддерживать HTTP/2 только тогда, когда он будет использоваться поверх TLS.

Вот это следование «стандартам» удивляет.

А еще удивляет поведение Google (с Chrome) — взяли, и отключили поддержку http/2 для сайтов, поддерживающих только NPN (без ALPN). Причина вроде как и есть, но вся штука в том, что внедрение http/2 этот выкрутас оттянул (потому что менять openssl на руками собранный, или менять ОС, или ждать обновления openssl для своей системы — все эти варианты не сильно, как оказалось, популярны; а чего хотел Гугл?).

Мне, как пользователю, такую логику «следования» стандартам (http/2 без tls делать не будем; npn поддерживать не будем) видеть в браузере несимпатично. Альтернатив особо нет, но и Chrome из апологета стандартов постепенно мигрирует в сторону старого IE по привычкам своих создателей :)

[@Nickmob]

Насколько я помню, в стандарте на HTTP/2 прописан как раз ALPN, а не NPN (он был для SPDY).
А требование TLS для HTTP/2 обусловлено не только желаниями Google, но и проблемой с middle boxes, которые любят перерабатывать HTTP-трафик (Proxy, DPI и т.д.), при этом ничено не знают о HTTP/2.
Вы же не хотите внедрить новый протокол и узнать, что у 5% (например) пользователей возникают проблемы с вашим сайтом (с каким-нибудь древним офисным Proxy), которые вы никак исправить не сможете?

[@dmitry_ch]

Ну тут фраза про «шашечки или ехать» очень в тему будет: вы хотите, чтобы протокол быть точно таким, как на бумаге (и тогда ALPN-only, и с высокой колокольни плюем на всякие проксики в офисах), или предпочитаете, чтобы у всех работало хотя бы подмножество протокола (и тогда NPN и проксики уважаются).

А то, что приняли стандарт, до которого ПО еще расти (я про ALPN, который на старых версиях библиотек не получить), а потом начали делать послабления и костыли в нем, чтобы проблем с миддл-боксами не было — я и говорю, это двоемыслие сродни запуску IE6, мол, все равны, а мы ровнее".

Хочу ли я новый стандарт внедрить? У меня может быть две причины сделать это в отношении http/2: мультиплексирование соединений (что, по факту, позволяет всего лишь немного компенсировать накладные расходы TLS, а не сумасшедшим образом ускориться на фоне http/1.1), и как бы бесплатный TLS получить (что тоже неверно, т.к. TLS можно и с http/1.1 поднять).

«Компьютер помогает решить проблемы, которых не было до появления компьютера» — с http/2 иногда такое тоже случается. Тем более что Гуглы всякие сами сидят не на нем, а на QUIC. В общем, подняли смуту ребята, а сами в кусты ))

[@Nickmob]

А то, что приняли стандарт, до которого ПО еще расти (я про ALPN, который на старых версиях библиотек не получить), а потом начали делать послабления и костыли в нем, чтобы проблем с миддл-боксами не было — я и говорю, это двоемыслие сродни запуску IE6, мол, все равны, а мы ровнее".

Использование только с TLS это ограничение для гарантии работоспособности, а не костыль.

«Компьютер помогает решить проблемы, которых не было до появления компьютера» — с http/2 иногда такое тоже случается. Тем более что Гуглы всякие сами сидят не на нем, а на QUIC. В общем, подняли смуту ребята, а сами в кусты ))

Гуглы сидят в том числе и на нём и постоянно проводят эксперименты с другими протоколами (QUIC), в чем здесь проблема?

[@xenon]

Одно соединение хуже чем 2, тем более 10 ибо окно передачи будет у хх соединений ощутимо больше и данные по хх соединениям передадутся быстрее чем по одному, как ты не извращайся

Почему это? Ничто не мешает на одном соединении иметь очень большой размер окна. Это же адаптивная величина — она растет (и увеличивается скорость передачи) до тех пор, пока не утилизируется весь канал и не начинаются потери пакетов. Если сервер и клиент настроены хорошо — то и в 1 коннект можно любой канал полностью забить.

[@Nickmob]

Товарищ видимо имел в виду начальное окно (initcwd), до его расширения за счет TCP Slow Start.

[@Stroy71]

Спасибо. Очень познавательная, а самое главное-конкретная статья.

[@aalexeev]

Два бонуса для тех, кто читает комменты.

Если вы новичок и хотите узнать побольше, посмотрите:
1. Доклад http-протокол Алексея Бережного.
2. Курс «Компьютерные сети».