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


    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".

    UPD. 26 сентября 2019 года о предварительной поддержке QUIC и HTTP/3 объявил CDN-провайдер Cloudflare. Организация Mozilla тоже анонсировала поддержку HTTP/3 в браузере Firefox «в ближайшее время». «Разработка нового сетевого протокола является трудным делом, и для его правильного выполнения требуется, чтобы все работали вместе, — сказал технический директор Mozilla Эрик Рескорла (Eric Rescorla). — В последние несколько лет мы сотрудничали с Cloudflare и другими отраслевыми партнёрами для тестирования TLS 1.3, а теперь HTTP/3 и QUIC. Ранняя поддержка Cloudflare на стороне сервера для этих протоколов помогла нам решить проблемы совместимости из нашей реализации Firefox на стороне клиента. Надеемся, что наша совместная работа поможет повысить безопасность и производительность интернета».
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 24

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

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

          +2

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

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

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

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

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

            +1

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

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

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

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

              TCP fast open и TLS 1.3 уже могут то, чем хвастается QUIC. Преимущества последнего сильно преувеличены.
              +4
              Относительно недавно только HTTP/2 начали использовать. Уже HTTP/3. Куда так разогнались?
                +1

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

                –2

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


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

                  +4

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

                    –1

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

                  +3

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

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

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

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

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

                            +1

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

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

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

                  Самое читаемое