В Chrome Canary добавили поддержку протокола HTTP/3 +22




QUIC позволяет мгновенно установить повторное соединение (0-RTT) и обеспечивает минимальную задержку между отправкой запроса и получением ответа

Google Chrome Canary стал первым браузером, в который интегрирована (очень) экспериментальная поддержка протокола HTTP/3, где вместо TCP в качестве транспортного уровня используется протокол QUIC.

HTTP/3 — это новый синтаксис HTTP, который работает на IETF QUIC, мультиплексированном и безопасном транспорте на основе UDP. Хотя некоторые разработчики называют QUIC на UDP «дичайшим экспериментом», новый протокол сулит массу преимуществ.

С момента принятия стандарта HTTP/2 прошло три с половиной года: спецификация RFC 7540 опубликована в мае 2015-го, но пока не используется повсеместно. Протокол реализован во всех браузерах ещё с конца 2015 года, а спустя три года только 40,9% из 10 млн самых популярных интернет-сайтов поддерживают HTTP/2.

Создание HTTP/3


Несмотря на принятие HTTP/2 на основе SPDY в качестве стандарта RFC 7540, инженеры Google продолжили эксперименты с ускорением транспорта. До 2015 года они выпустили новые версии SPDY v3 и v3.1, а также начали работать над протоколом gQUIC, первый черновик которого опубликовали в начале 2012 года.

В ранних версиях gQUIC использовался синтаксис HTTP SPDY v3. Такой выбор имел смысл, потому что HTTP/2 ещё не утвердили. Бинарный синтаксис SPDY упакован в пакеты QUIC, которые отправляются в датаграммах UDP. Это отход от транспорта TCP, на который традиционно полагался HTTP. Вся система в сборе выглядела так:


Слоёный пирог SPDY по gQUIC. Иллюстрация из статьи «HTTP/3: от корней до кончиков»

Затем разработку передали в IETF для стандартизации. Здесь она разделилась на две части: транспорт и HTTP. Идея была в том, что транспортный протокол можно использовать также для передачи других данных, а не только эксклюзивно для HTTP или HTTP-подобных протоколов. Однако название осталось таким же: QUIC. Разработкой транспортного протокола занималась рабочая группа QUIC Working Group в Инженерном совета интернета (IETF).

В то же время Google продолжила работу над своей собственной реализацией — и внедрила её в браузер Chrome не дожидаясь стандартизации.



Разноголосицу в версиях и именованиях QUIC объясняет Дэниель Стенберг, ведущий разработчик curl, работающий в Mozilla, который давно следит за этой историей.

По его словам, до стандартизации HTTP/3 в кругу разработчиков получили распространения неформальные названия двух версий QUIC, поскольку варианты от IETF и Google значительно различаются в деталях реализации:

  • iQUIC (версия IETF)
  • gQUIC (версия Google)

Протокол для передачи HTTP по iQUIC (версия IETF) долгое время называли “hq” (HTTP-over-QUIC).

Объединить iQUIC и gQUIC под названием HTTP/3 в сентябре 2018 года предложил Марк Ноттингем, один из самых влиятельных инженеров IETF, соавтор нескольких веб-стандартов. По его словам, это поможет устранить путаницу между QIUC-транспортом и QUIC-оболочкой для HTTP.

Таким образом, HTTP/3 — это новая версия HTTP, которая будет использовать транспорт QUIC.

Преимущества транспорта QUIC


Основные преимущества QUIC, из документа QUIC Geek FAQ (в изложении Opennet):

  • Высокая безопасность, аналогичная TLS (по сути QUIC предоставляет возможность использования TLS поверх UDP).
  • Контроль за целостностью потока, предотвращающий потерю пакетов.
  • Возможность мгновенно установить соединение (0-RTT, примерно в 75% случаях данные можно передавать сразу после отправки пакета установки соединения) и обеспечить минимальные задержки между отправкой запроса и получением ответа (RTT, Round Trip Time).
  • Не использование при повторной передаче пакета того же номера последовательности, что позволяет избежать двусмысленности при определении полученных пакетов и избавиться от таймаутов.
  • Потеря пакета влияет на доставку только связанного с ним потока и не останавливает доставку данных в параллельно передаваемых через текущее соединение потоках.
  • Средства коррекции ошибок, минимизирующие задержки из-за повторной передачи потерянных пакетов. Использование специальных кодов коррекции ошибок на уровне пакета для сокращения ситуаций, требующих повторной передачи данных потерянного пакета.
  • Криптографические границы блоков выравнены с границами пакетов QUIC, что уменьшает влияние потерь пакетов на декодирование содержимого следующих пакетов.
  • Отсутствие проблем с блокировкой очереди TCP.
  • Поддержка идентификатора соединения, позволяющего сократить время на установку повторного соединения для мобильных клиентов.
  • Возможность подключения расширенных механизмов контроля перегрузки соединения.
  • Использование техники прогнозирования пропускной способности в каждом направлении для обеспечения оптимальной интенсивности отправки пакетов, предотвращая скатывание в состояние перегрузки, при которой наблюдается потеря пакетов.
  • Заметный прирост производительности и пропускной способности, по сравнению с TCP. Для видеосервисов, таких как YouTube, применение QUIC показало сокращение операций повторной буферизации при просмотре видео на 30%.

По словам Марк Ноттингема, переход от устаревшего TCP на новые протоколы просто неизбежен, поскольку сейчас очевидно, что TCP страдает от проблем неэффективности: «Поскольку TCP — протокол доставки пакетов по порядку, то потеря одного пакета может помешать доставке приложению последующих пакетов из буфера. В мультиплексированном протоколе это может привести к большой потере производительности, — объясняет Марк Ноттингем. — QUIC пытается решить эту проблему с помощью эффективной перестройки семантики TCP (вместе с некоторыми аспектами потоковой модели HTTP/2) поверх UDP».

Кроме того, любая версия требует обязательного шифрования: нешифрованного QUIC не существует вообще. iQUIC использует TLS 1.3 для установки ключей сессии, а затем шифрования каждого пакета. Но поскольку он основан на UDP, значительная часть информации о сессии и метаданных, открытых в TCP, шифруется в QUIC:

В статье «Будущее интернет-протоколов» Марк Ноттингем говорит о значительных улучшениях в безопасности с переходом на QUIC: «На самом деле текущий "короткий заголовок" iQUIC — который используется для всех пакетов, кроме рукопожатия — выдаёт только номер пакета, необязательный идентификатор соединения и байт состояния, необходимый для процессов вроде смены ключей шифрования и типа пакета (который тоже может быть зашифрован). Всё остальное зашифровано — включая пакеты ACK, что значительно повышает планку для проведения атак с анализом трафика. Кроме того, становится невозможна пассивная оценка RTT и потерь пакетов путём простого наблюдения за соединением; там недостаточно информации для этого».

Некоторые специалисты считают, что принятие стандарта HTTP/3 произошло бы и раньше, если бы компания Google не поспешила внедрить свою реализацию в браузер Chrome. Тем не менее, прогресс неизбежен — и в ближайшие годы можно ожидать дальнейшего распространения HTTP/3. Поддержка протокола в Chrome Canary — только начало. У Mozilla уже есть такие планы для браузера Firefox.

Для включения HTTP/3 требуется запустить Chrome Canary с опциями --enable-quic —quic-version=h3-23. Потом зайти на тестовый сайт quic.rocks:4433 — и вы увидите соответствующее уведомление.



В инструментах для разработчиков активность HTTP/3 отображается как "http/2+quic/99".

Вы можете помочь и перевести немного средств на развитие сайта



Комментарии (24):

  1. mamont80
    /#20651801

    Давно пора было отправить TCP на свалку истории. Жаль что для этого потребовалось столько времени. До сих пор скачивание в несколько потоков из одного далекого источника эффективней, чем в 1 поток. Надеюсь новая реализация это починит. Не говоря уже о избыточном «рукопожатии».

    • DerRotBaron
      /#20651959 / +5

      К сожалению, пока QUIC выглядит как очередной "стандарт", сделанный гуглом ради удовлетворения нужд гугла, что вообще говоря пугает.

      • KasperGreen
        /#20652513 / +1

        А хорошие штуки они такие. Делаются в первую очередь — для себя.

      • Turbine
        /#20659623

        Ага, а для остальных HTTP/3 будет исключительно во вред. Статью хоть прочитали? Поняли с какой целью он создаётся?

        • DerRotBaron
          /#20661703 / +1

          Цели понятны, даже более-менее понятно, что из них и как решается.
          Однако взамен создаются новые проблемы, которые Гугл видит незначительными, однако не во всех случаях и не для всех это так. И в контексте гугла следует заметить, что это далеко не первый раз, когда удобные прежде всего этой корпорации стандарты проталкиваются в качестве стандарта, из чего потом гугл извлекает не совсем конкурентное преимущество.

          • Turbine
            /#20661783

            Этот протокол не проприетарный, а общедоступный. Следовательно любой может извлеч из него выгоду, также как и гугл. Я думаю другие разработчики браузеров тоже захотят, чтобы самый популярный видеосервис отсылал ответы в их браузер также быстро, как и в хроме. Если бы протокол был закрыт, то тогда был бы другой разговор. А так они тебе его дают и говорят «На, пользуйся». Причём это не замена предыдущих версий, а + 1 к варианту выбора. Если он тебе подходит, то пожалуйста. Так что невижу вообще смылса в боязне того, что изначально гугл сделал его для оптимизации трафика на своих загруженных сервисах. Иначе бы все орали: «Во гугл гады, сделали у себя там протокол, который работает быстрее и не хотят его открывать, работает только в хроме. Монополисты чёртовы.»

            • johnfound
              /#20661947

              Я думаю другие разработчики браузеров тоже захотят,

              Это какие такие "другие" браузеры???

    • DistortNeo
      /#20652097

      И получить вместо одного стандарта множество конкурирующих? Нет, спасибо.

      • mamont80
        /#20653373

        Не пойму скепсиса. Вам же не потребуется реализовывать его самостоятельно. Это проблема браузеров и вёб-серверов. Вам максимум потребуется включить настройку в конфиге. Тот же HTTP2 в IIS работает по умолчанию, делать ничего не надо. В nginx надо только дописать слово http2 в конфиг.

        • Dima_Sharihin
          /#20653435

          А что делать разработчикам железок, где нету ни IIS, ни Nginx?

          • mamont80
            /#20653439

            Старые протоколы никто не отменяет. Обычный http через TCP не умрёт никогда, как и ванильный HTML без CSS.

    • creker
      /#20652509

      Не говоря уже о избыточном «рукопожатии».

      TCP fast open и TLS 1.3 уже могут то, чем хвастается QUIC. Преимущества последнего сильно преувеличены.

  2. Tetrakronos
    /#20652381 / +4

    Относительно недавно только HTTP/2 начали использовать. Уже HTTP/3. Куда так разогнались?

    • Finesse
      /#20653307

      Не понятно, причём здесь HTTP. Сам Google называет это «http/2+quic/99», намекая, что протокол HTTP не поменялся.

  3. johnfound
    /#20652621 / -2

    Ну не знаю. На HTTP2 перешли. Обещали много, а веб стал еще медленнее. Теперь HTTP3… Темпы взвинчены, обещают много чего… А браузеры уже только два остались.


    Мне вообще на ЕЕЕ похоже, а веб еще медленнее станет.

    • iproger
      /#20652771 / +3

      Он может и стал медленнее, но явно не из-за http2.

      • johnfound
        /#20652847 / -1

        Конечно не из за http2. Но почему тогда http2 (и сейчас http3) преподносится как решение проблемы скорости? А когда останется только один браузер, то и новые хттп уже не понадобятся.

  4. DmitryKoterov
    /#20652663 / +2

    Избавление от тройного рукожопатия, а также от начальных накладывательных расходов на установку SSL-соединения может сэкономить сотни миллисекунд, это очень круто.

    • Rsa97
      /#20652865 / +6

      Избавление от тройного рукожопатия может сэкономить гораздо больше :)

      • MedicusAmicus
        /#20653389

        Я расскажу вам шутку про tcp, и буду повторять ее, пока вы не поймете...

        • Meklon
          /#20655721 / +1

          Ответил бы шуткой про UDP, но не факт, что дойдет.

          • Lure_of_Chaos
            /#20656003 / +1

            А Вы поймёте две шутки про HTTP/2 одновременно?

            • igorp1024
              /#20661155

              Дилетант тут видит всего половину олдовой шутки про обычный HTTP.

              • RomanPyr
                /#20667919

                Хотел рассказать шутку про IPX, но забыл…