Как стать автором
Обновить
СберМаркет
Кодим будущее доставки товаров

Эволюция HTTP. Часть 2. Краткая история развития самого популярного протокола Всемирной паутины

Время на прочтение7 мин
Количество просмотров4.2K

Привет! Меня зовут Глеб Гончаров, я руководитель группы разработки клиентского продукта в СберМаркете. Это вторая часть в серии статей об истории развития самого популярного протокола Всемирной паутины — протокола HTTP.

В первой части я рассказал про старую группу протокола HTTP  (HTTP/0.9, HTTP/1.0, HTTP-NG, HTTP/1.1): причины их появления, видах запросов и недостатках. Сегодня же поговорим о новой группе, которая включает в себя протоколы SPDY, HTTP/2, gQUIC и HTTP/3.

SPDY

В 2009 году Google представил первую наработку нового протокола для устранения фундаментальных проблем с дизайном HTTP/1.1 под названием SPDY (произносится как «спиди»). К тому времени браузер Chrome уже получил широкое распространение и 30-миллионную базу активных пользователей, а развитие телекоммуникационных сетей позволило Google доставлять обновления пользователям и проводить широкие технические эксперименты.

Основной задачей SPDY стало уменьшение задержки загрузки веб-страниц путем устранения некоторых известных ограничений производительности HTTP/1.1. Важно отметить, что протокол SPDY не является заменой HTTP, а представляет новый транспортный слой для HTTP-трафика. Протокол так и не был стандартизирован и являлся больше лабораторным экспериментом для сбора данных о производительности.

Данные в SPDY передаются в пределах одного TCP-соединения. Благодаря тому, что полностью сохранена семантика HTTP, разработчикам не требовалось адаптировать свои приложения, а эксплуатации достаточно было использовать новый транспортный слой на стороне клиента и сервера.

Дизайн SPDY предполагает управление потоками и мультиплексирование для доступа к ресурсам одновременно, также возможно приоритизировать запросы, сжимать данные и HTTP-заголовки, удаляя избыточность. Кроме того, есть поддержка server push и server hint

Server push позволяет отправить ресурс клиенту без подтверждения с его стороны. Это интересная возможность для реализации уведомлений. Однако server push полностью игнорируют кеш клиента и использовать его для загрузки статических ресурсов, пожалуй, не следует.

Server hint отправляет URL до документов, позволяя клиенту самому валидировать документ и загружать связанные ресурсы, не дожидаясь основного тела HTML-документа. 

Работа криптографии в SPDY полагается на расширение TLS NPN (Next Protocol Negotiation). Используя NPN, сервер сообщает клиенту какие протоколы он знает, а клиент может выбрать и использовать наиболее предпочтительный. Сейчас TLS NPN полностью вытеснен в пользу расширения TLS ALPN (Application Level Protocol Negotiation), впоследствии ставшего стандартом RFC 7301.

Протокол SPDY подразумевает пересылку бинарных сообщений — кадров (фреймов). Клиент отправляет фрейм SYN_STREAM с запросом, а сервер отвечает фреймами SYN_REPLY и последовательной серией DATA-фреймов. Помимо перечисленного, SPDY поддерживает несколько управляющих фреймов (RST_STREAM, SETTINGS, PING, GOAWAY, WINDOW_UPDATE и CREDENTIAL). RST_STREAM, например, позволял прервать передачу потока от клиента к серверу. Ранее такая возможность отсутствовала в HTTP/1.1: запрос и данные передавались целиком, а прерывание передачи каждый веб-сервер реализовывал по-своему: зачастую на транспортном уровне через отправку клиенту TCP RST.

Эксперимент SPDY был признан удачным. Согласно отчёту Google, в некоторых случаях удалось сократить время загрузки веб-сайтов на 60%. Это стало возможным благодаря эффективному использованию транспортного протокола, снижению чувствительности к задержкам в сети (пусть и не полностью избавиться от Head-of-line блокировок) и сокращения избыточности HTTP-заголовков за счёт использования алгоритма HPACK.

SPDY прекрасно выполнил свою задачу и продемонстрировал выдающиеся результаты производительности загрузки веб-страниц в результате смены парадигмы, сменив текстовый протокол бинарным с поддержкой параллелизма и мультиплексирования. Хоть SPDY не являлся стандартом и разрабатывался преимущественно инженерами Google с незначительным участием открытого сообщества, рабочая группа HTTP (HTTP-WG) извлекла важные уроки для появления нового протокола HTTP/2.

gQUIC

В 2012 году Google начинает работать над протоколом QUIC. Это протокол транспортного уровня, сочетающий в себе функции протоколов уровня представления и приложения.

Google QUIC (gQUIC) — это бинарный протокол, первый черновик которого был представлен в 2012 году. Дизайн gQUIC представляет собой монолит, включающий как возможности прикладного уровня, так и обязательного криптографического слоя из состава QUIC crypto с рядом функций транспортного протокола TCP как проверка целостности, контроль перегрузок и коррекция ошибок. Однако наиболее значимое отличие gQUIC от предшественников — это ориентированность на пакетную передачу по UDP. 

Благодаря переходу на UDP, gQUIC сокращает время установки соединения до 1RTT или до 0RTT и реализует миграцию между узлами за счёт возобновляемых сессий. Представьте, что вы смотрите видео и перемещаетесь точками доступа, а вам не требуется повторно инициировать соединение. Также это работает и со стороны сервера: миграция подключений позволит долгим запросам переехать на новые узлы без простоя. 

При всех преимуществах, были и недостатки:

  • Всё же изначально gQUIC неофициальный протокол от Google;

  • Использовал собственную реализацию криптографии, несовместимой с OpenSSL, BoringSSL и др. открытыми реализациями, что затрудняло повсеместное внедрение.

  • Использовал чувствительный к потерям алгоритм сжатия заголовков HPACK из SPDY. Учитывая, что основной транспортный уровень стал UDP и потери датаграмм неизбежны, компрессия заголовков была узким местом производительности.

  • gQUIC смешивает несколько протоколов в один уровень, что затруднит развитие протокола в будущем.

Тем не менее, это позволило продемонстрировать эффективность решений. К примеру, в период разработки gQUIC компания Google экспериментировала, предлагая пользователям Chrome и Chromium использовать новый протокол в своих сервисах (YouTube, GMail и пр.). К моменту начала обсуждения IETF QUIC (iQUIC) в 2015 году, в мире около 7.8% всего трафика уже работало на Google QUIC.

HTTP/2

Тем временем в мае 2015 года IETF заканчивает стандартизацию HTTP/2. Любопытно, что буквально в апреле того же года Google сообщает о планах передачи gQUIC в IETF в роли нулевого черновика в IETF для разработки HTTP/3.

Итак, HTTP/2 — это бинарный протокол, ориентированный на передачу пакетов, ставший стандартом развития HTTP. Работает поверх TCP с опциональным SSL/TLS. Примечательно, что стандарт HTTP/2 поддерживает работу поверх TCP без SSL/TLS, однако на практике практически нигде не поддерживается без шифрования: основные вендоры браузеров Mozilla и Google сразу заявили, что не будут реализовывать h2c и сконцентрируются только на h2.

Основные возможности берут лучшее и проверенное из SPDY и gQUIC. Основное улучшение — передача данных в пределах одного TCP-соединения. Также заимствовали реализацию управления потоками и мультиплексирования для распараллеливания загрузки. Дополнительно реализовали отправку нескольких запросов (HTTP pipelining), server push и механизм обновления протокола.

В HTTP/2 клиент отправляет фрейм HEADERS с заголовками, а сервер отвечает фреймом HEADERS и последовательной серией DATA-фреймов. HTTP/2 также поддерживает несколько управляющих фреймов (PRIORITY, RST_STREAM, SETTINGS, PUSH_PROMISE, GOAWAY, PING, WINDOW_UPDATE, CONTINUATION). Как и в SPDY, можно прерывать поток передачи отправкой фрейма RST_STREAM.

Результатом внедрения HTTP/2 стало сокращение времени установлена соединения до 2RTT или 1RTT, а стандарт подтолкнул вендоров реализовать поддержку нового протокола. Также удалось снизить чувствительность к задержкам в сети.

К сожалению, использование преимуществ HTTP/2 означало отказ от старых хаков HTTP/1.1, а потому разработчикам требовалось адаптировать свои приложения для достижения высокой скорости загрузки и рендера страниц. Также при увеличении задержки преимущества протокола также нивелировались. Также не удалось полностью исключить чувствительность к задержкам, поскольку транспортный слой остался на TCP. Это означало те же проблемы: при потере одного пакета может «сорваться» доставка всех последующих, сводя на нет мультиплексирование.

В ходе эксплуатации HTTP/2 также выяснилось, что практически ни один из промышленных веб-серверов не реализовал server push в виду низкой популярности. Также в Nginx в HTTP/2 не работают websockets и, похоже, не заработают.

В любом случае, в 2022 году на HTTP/2 работает 95% браузеров и 66% веб-серверов в мире и с уверенностью можно сказать, что протокол достаточно хорошо освоен и в значительной мере улучшил пользовательский опыт в Интернете.

HTTP/3

В ноябре 2018-го года IETF сообщил о переименовании QUIC+HTTP/2 в HTTP/3, назвав его новым протоколом WWW. Изначально предполагалось, что стандарт выйдет в ноябре, но обсуждения продолжились до лета 2019 года. Думаю, сейчас уже становится очевидным, это не принципиально новый протокол, а эволюционное эволюционное развитие HTTP/2, логическое продолжение идей прошлого.

В результате в стандарт вошли как проверенные возможности HTTP/2 (за небольшими модификациями в виде QPACK, ставшего заменой HPACK для корректной работы поверх UDP), так и наработки gQUIC — альтернативные сервисы, обязательное шифрование, миграция подключений. Дополнительно IETF предложили реализацию защиты от спуфинга IP-адреса отправителя и от amplification-атак.

Стандарт позволил решить практически все имеющиеся проблемы предшественников, вобрав лучшие из наработок gQUIC и HTTP/2, однако сейчас есть несколько трудностей с его внедрением. Во-первых, в ядрах основных серверных ОС есть слабые места в работе UDP. За десятилетия эксплуатации HTTP, протокол TCP уже достаточно хорошо оптимизирован, в то время как с UDP могут быть проблемы с производительностью (со слов LWH).

Также отсутствуют готовые промышленные реализации, чтобы оценить работу на местах. Сейчас уже есть реализации в libcurl и экспериментальных веб-серверов, но на это едва ли будут готовы крупные компании. Технологическое preview того же Nginx было в 2020-м году. Появление возможности обещали к концу 2021 года, но пока без изменений.

Также не ясно как быстро разработчики популярных криптографических библиотек адаптируются под изменения. Например, условный Nginx работает только с BoringSSL, а OpenSSL и LibreSSL пока не поддерживают TLS over QUIC.

Что дальше?

Итак, мы рассмотрели краткую историю развития протокола HTTP. Как вы думаете, что ждёт нас в HTTP/4?

Tech-команда СберМаркета завела соцсети с новостями и анонсами. Если хочешь узнать, что под капотом высоконагруженного e-commerce, следи за нами в Telegram и YouTube.

Теги:
Хабы:
Всего голосов 6: ↑5 и ↓1+4
Комментарии1

Публикации

Информация

Сайт
sbermarket.ru
Дата регистрации
Дата основания
Численность
1 001–5 000 человек
Местоположение
Россия
Представитель
SberMarket Tech