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

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

СПДИ

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

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

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

Рисунок SPDY включает в себя управление потоком и мультиплексирование для одновременного доступа к ресурсам, также возможна приоритизация запросов, сжатие данных и HTTP-заголовки, устраняющая избыточность. Кроме того, там Поддержка сервера и предложение сервера.

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

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

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

Протокол SPDY предполагает передачу бинарных сообщений — фреймов (frames). Клиент отправляет кадр 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. Это протокол транспортного уровня, который сочетает в себе функции протоколов уровня представления и уровня приложений.

Гугл QUIC (gQUIC) представляет собой бинарный протокол, первый проект которого был представлен в 2012 году. Дизайн gQUIC представляет собой монолит, который включает в себя как возможности прикладного уровня, так и криптографический уровень, требуемый Крипто QUIC с рядом функций транспортного протокола 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 и ориентируются только на ч2.

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

В 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 веб-сокеты не работают и, похоже, не работают.

Однако в 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-адреса отправителя и атак с усилением.

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

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

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

Что дальше?

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

Технологическая команда СберМаркета запустила социальные сети с новостями и анонсами. Если вы хотите узнать, что скрывается за высоконагруженной электронной коммерцией, подписывайтесь на нас Телеграмма и YouTube.

Source

ЧИТАТЬ  Шокирующие факты о мире, в которые сложно поверить: от похорон в банке из-под чипсов до трупов на Эвересте

от admin