Уже более 20 лет мы просматриваем веб-страницы по протоколу HTTP. Большинство пользователей даже не задумываются о том, что это такое и как это работает. Другие знают, что где-то под HTTP есть TLS, а под ним TCP, под которым IP и так далее.
А третьи – еретики – считают, что TCP остался в прошлом; им нужно что-то более быстрое, надежное и безопасное.
Но в своих попытках изобрести новый идеальный протокол они вернулись к технологиям 80-х годов и пытаются построить на них свой дивный новый мир.
Немного истории: HTTP/1.1
В 1997 году протокол обмена текстовой информацией HTTP версии 1.1 обзавелся собственным RFC. На тот момент протокол использовался браузерами уже несколько лет, а новый стандарт просуществовал еще пятнадцать.Протокол работал только по принципу запрос-ответ и предназначался в основном для передачи текстовой информации.
HTTP был разработан для работы поверх протокола TCP, гарантируя надежную доставку пакетов по назначению.
TCP работает путем установления и поддержания надежного соединения между конечными точками и разбиения трафика на сегменты.
Сегменты имеют свой серийный номер и контрольную сумму.
Если вдруг один из сегментов не придет или придет с неверной контрольной суммой, то передача прекратится до тех пор, пока потерянный сегмент не будет восстановлен.
В HTTP/1.0 TCP-соединение закрывалось после каждого запроса.
Это было крайне расточительно, потому что.
установление TCP-соединения (3-стороннее рукопожатие) — медленный процесс.
В HTTP/1.1 представлен механизм поддержания активности, который позволяет повторно использовать одно соединение для нескольких запросов.
Однако, поскольку он может легко стать узким местом, различные реализации HTTP/1.1 позволяют открывать несколько TCP-соединений к одному и тому же хосту.
Например, Chrome и последние версии Firefox допускают до шести подключений.
Шифрование также предполагалось оставить другим протоколам, и для этого использовался протокол TLS поверх TCP, который надежно защищал данные, но еще больше увеличивал время, необходимое для установления соединения.
В результате процесс рукопожатия стал выглядеть так: 
Иллюстрация облачной вспышки
Таким образом, HTTP/1.1 имел ряд проблем:
- Медленная установка соединения.
- Для одного запроса используется одно TCP-соединение, а это означает, что другие запросы должны либо найти другое соединение, либо дождаться, пока текущий запрос его не освободит.
- Поддерживается только модель извлечения.
В стандарте нет ничего о серверной отправке.
- Заголовки передаются в текстовом виде.
Немного современности: HTTP/2
В 2012 году Google начала работу над протоколом SPDY (произносится как «скоростной»).Протокол был разработан для решения основных проблем HTTP/1.1 и в то же время должен был сохранять обратную совместимость.
В 2015 году рабочая группа IETF представила спецификацию HTTP/2, основанную на протоколе SPDY. Вот различия в HTTP/2:
- Бинарная сериализация.
- Мультиплексирование нескольких HTTP-запросов в одно TCP-соединение.
- Серверная рассылка из коробки (без WebSocket).
То есть в одном соединении есть несколько так называемых потоков, каждый из которых имеет свой идентификатор.
Бонус — коробочный сервер-пуш.
Однако мультиплексирование приводит к другой ключевой проблеме.
Представьте, что мы асинхронно выполняем 5 запросов к одному серверу.
При использовании HTTP/2 все эти запросы будут выполняться в рамках одного и того же TCP-соединения, а это означает, что если один из сегментов любого запроса будет утерян или получен некорректно, передача всех запросов и ответов прекратится до тех пор, пока не будет потерян потерянный сегмент. восстановлен.
Очевидно, что чем хуже качество соединения, тем медленнее работает HTTP/2. По словам Дэниела Стенберга , в условиях, когда потерянные пакеты составляют 2% от всех пакетов, HTTP/1.1 в браузере работает лучше, чем HTTP/2 за счет того, что он открывает 6 соединений, а не одно.
Эта проблема называется «блокировка начала строки» и, к сожалению, решить ее при использовании TCP не удается.
Иллюстрация Дэниела Стейнберга
В результате разработчики стандарта HTTP/2 проделали огромную работу и сделали практически всё, что можно было сделать на прикладном уровне модели OSI. Пришло время перейти на транспортный уровень и изобрести новый транспортный протокол.
Нам нужен новый протокол: UDP против TCP.
Довольно быстро стало понятно, что реализация совершенно нового протокола транспортного уровня — невыполнимая задача в сегодняшних реалиях.Дело в том, что оборудование или промежуточные устройства (маршрутизаторы, межсетевые экраны, NAT-серверы.
) знают о транспортном уровне, и научить их чему-то новому — чрезвычайно сложная задача.
Кроме того, поддержка транспортных протоколов встроена в ядро операционных систем, а ядра тоже не очень-то желают меняться.
И тут можно было бы развести руками и сказать «Мы, конечно, придумаем новый HTTP/3 с преферансом и куртизанками, но его внедрение займет 10-15 лет (примерно за это время большая часть оборудования будет заменено)», но есть еще одно не так.
Очевидный вариант — использовать протокол UDP. Да-да, тот самый протокол, который мы использовали для перекидывания файлов по локальной сети в конце девяностых-начале 2000-х.
Почти все современное оборудование может с ним работать.
Каковы преимущества UDP перед TCP? Прежде всего, у нас нет сеанса транспортного уровня, о котором знает оборудование.
Это позволяет нам самим определять сессию на конечных точках и разрешать там конфликты.
То есть мы не ограничиваемся одной или несколькими сессиями (как в TCP), а можем создать их столько, сколько нам необходимо.
Во-вторых, передача данных по UDP происходит быстрее, чем по TCP. Таким образом, теоретически мы можем преодолеть нынешний потолок скорости, достигнутый в HTTP/2. Однако UDP не гарантирует надежную передачу данных.
По сути, мы просто отправляем пакеты, надеясь, что другой конец их получит. Не получил? Ну не повезло.
Для передачи видео взрослым этого хватило, но для более серьёзных вещей нужна надёжность, а значит придётся поверх UDP ещё что-то наворачивать.
Как и в случае с HTTP/2, работа над созданием нового протокола началась в Google в 2012 году, то есть примерно в то же время, когда началась работа над SPDY. В 2013 году Джим Роскинд представил широкой публике Протокол QUIC (быстрое подключение к Интернету UDP) , а уже в 2015 году Internet Draft был представлен для стандартизации в IETF. Уже в то время протокол, разработанный Роскиндом в Google, сильно отличался от стандартного, поэтому версия Google стала называться gQUIC.
Что такое QUIC
Во-первых, как уже говорилось, это обертка над UDP. QUIC-соединение возникает поверх UDP, в котором по аналогии с HTTP/2 может существовать несколько потоков.Эти потоки существуют только на конечных точках и обслуживаются независимо.
Если потеря пакетов произойдет в одном потоке, это не повлияет на другие.
Иллюстрация Дэниела Стейнберга
Во-вторых, шифрование больше не реализовано на отдельном уровне, а включено в протокол.
Это позволяет вам устанавливать соединение и обмениваться открытыми ключами за одно рукопожатие, а также позволяет использовать умный механизм рукопожатия 0-RTT и в целом избегать задержек рукопожатия.
Кроме того, теперь можно шифровать отдельные пакеты данных.
Это позволяет не дожидаться завершения приема данных из потока, а самостоятельно расшифровывать полученные пакеты.
Такой режим работы вообще был невозможен в TCP, поскольку TLS и TCP работали независимо друг от друга, и TLS не мог знать, на какие части будут разбиты данные TCP. И поэтому он не мог подготовить свои сегменты так, чтобы они вписывались в TCP-сегменты один в один и могли быть расшифрованы самостоятельно.
Все эти улучшения позволяют QUIC снизить задержку по сравнению с TCP. 
В-третьих, концепция легкой потоковой передачи позволяет отделить соединение от IP-адреса клиента.
Это важно, например, когда клиент переключается с одной точки доступа Wi-Fi на другую, меняя свой IP. В этом случае при использовании TCP происходит длительный процесс, в ходе которого истекает время ожидания существующих TCP-соединений и создаются новые соединения с нового IP. В случае с QUIC клиент просто продолжает отправлять пакеты на сервер с нового IP со старым ID потока.
Поскольку идентификатор потока теперь уникален и не используется повторно, сервер понимает, что клиент сменил IP, повторно отправляет потерянные пакеты и продолжает связь по новому адресу.
В-четвертых, QUIC реализован на уровне приложения, а не уровня операционной системы.
Это, с одной стороны, позволяет быстро вносить изменения в протокол, т.к.
чтобы получить обновление, нужно просто обновить библиотеку, а не ждать новой версии ОС.
С другой стороны, это приводит к сильному увеличению потребления процессора.
И, наконец, заголовки.
Сжатие заголовка — это одна из особенностей QUIC и gQUIC. Не вижу смысла уделять этому много времени, скажу лишь, что в представленной на стандартизацию версии сжатие заголовков сделано максимально похожим на сжатие заголовков в HTTP/2. Вы можете прочитать больше Здесь .
Насколько это быстрее?
Это сложный вопрос.Дело в том, что пока у нас не будет эталона, измерять особо нечего.
Пожалуй, единственная статистика, которой мы располагаем, — это статистика Google, которая использует gQUIC с 2013 года и в 2016 году.
сообщил IETF что около 90% трафика, идущего на их серверы из браузера Chrome, теперь использует QUIC. В той же презентации они сообщают, что через gQUIC страницы загружаются примерно на 5% быстрее, а при потоковой передаче видео на 30% меньше заиканий по сравнению с TCP. В 2017 году группа исследователей под руководством Араша Молави Кахки опубликовала отличная работа изучить производительность gQUIC по сравнению с TCP. Исследование выявило несколько слабых сторон gQUIC, таких как неустойчивость к смешиванию сетевых пакетов, жадность (несправедливость) к пропускной способности канала и более медленная передача небольших (до 10 Кб) объектов.
Последнее, однако, можно компенсировать использованием 0-RTT. Во всех остальных изученных случаях gQUIC показал прирост скорости по сравнению с TCP. Здесь сложно говорить о конкретных цифрах.
Лучше прочитать само исследование или короткий пост .
Здесь надо сказать, что эти данные касаются конкретно gQUIC, и для разрабатываемого стандарта они не актуальны.
Что будет с QUIC: пока секрет, но есть надежда, что выявленные в gQUIC слабые места будут учтены и исправлены.
Немного из будущего: а как насчет HTTP/3?
Но здесь все кристально ясно: API никак не изменится.Все останется точно таким же, как было в HTTP/2. Ну а если API останется прежним, то переход на HTTP/3 придется решать использованием свежей версии библиотеки на бэкенде, поддерживающей транспорт QUIC. Правда, вам придется довольно долго держать запасной вариант на старых версиях HTTP, т.к.
Интернет на данный момент не готов к полному переходу на UDP.
Кто уже поддерживает
Здесь список существующие реализации QUIC. Несмотря на отсутствие стандарта, список неплох.Ни один браузер в настоящее время не поддерживает QUIC в рабочей версии.
Недавно появилась информация, что поддержка HTTP/3 включена в Chrome, но пока только в Canary. Из бэкэндов HTTP/3 поддерживает только Кэдди И Облачное сияние , но пока экспериментальный.
NGINX в конце весны 2019 года объявлено , которые начали работу над поддержкой HTTP/3, но еще не закончили ее.
Какие проблемы?
Мы с вами живем в реальном мире, где ни одна крупная технология не может достичь масс, не встретив сопротивления, и QUIC не является исключением.Самое главное, что нужно как-то объяснить браузеру, что «https://» уже не факт, что он ведет на TCP-порт 443. TCP может и не быть вообще.
Для этого используется заголовок Alt-Svc. Он позволяет сообщить браузеру, что этот веб-сайт также доступен по такому-то протоколу и по такому-то адресу.
По идее это должно работать как прелесть, но на практике мы столкнёмся с тем, что UDP можно, например, запретить на фаерволе, чтобы избежать DDoS-атак.
Но даже если UDP не запрещен, клиент может находиться за маршрутизатором NAT, который настроен на проведение TCP-сессии по IP-адресу, а поскольку мы используем UDP, у которого нет аппаратного сеанса, NAT не будет удерживать соединение, и QUIC сессия будет постоянно отрываться .
Все эти проблемы связаны с тем, что UDP ранее не использовался для передачи интернет-контента, и производители оборудования не могли предвидеть, что такое когда-либо произойдет. Точно так же администраторы пока не очень понимают, как правильно настроить свои сети для работы QUIC. Эта ситуация будет постепенно меняться, и в любом случае такие изменения займут меньше времени, чем внедрение нового протокола транспортного уровня.
Кроме того, как уже было описано, QUIC значительно увеличивает загрузку процессора.
Дэниел Стенберг оценил рост процессора до трёх раз.
Когда появится HTTP/3?
Стандартный хочу принять к маю 2020 года, но учитывая, что документы, запланированные на июль 2019 года, на данный момент остаются незавершенными, можно сказать, что дата, скорее всего, будет перенесена.Что ж, Google использует свою реализацию gQUIC с 2013 года.
Если вы посмотрите на HTTP-запрос, который отправляется в поисковую систему Google, вы увидите следующее: 
выводы
QUIC сейчас выглядит довольно сырой, но очень перспективной технологией.Учитывая, что последние 20 лет все оптимизации протоколов транспортного уровня касались в основном TCP, QUIC, который в большинстве случаев выигрывает по производительности, уже выглядит крайне хорошо.
Однако остаются еще нерешенные проблемы, которые придется решать в ближайшие несколько лет. Процесс может затянуться из-за того, что задействовано железо, которое никто не любит обновлять, но тем не менее все проблемы выглядят вполне решаемыми, и рано или поздно у всех нас будет HTTP/3. Будущее не за горами! Теги: #Сетевые технологии #ИТ-стандарты #tls #dodo #dodopizza #dodopizzaengineering #http #standards #tcp #udp #quic #HTTP/2 #http-server #spdy #dodois #dodois #dodois #dodois #протоколы передачи данных # gquic #http 1.1
-
Шифр Цезаря Или Как Просто Зашифровать Текст
19 Oct, 24 -
Спам Через Счетчики Трафика
19 Oct, 24
