Казалось бы, кого волнует, будут новые функции в HTTP/3 или QUIC? Это важно, потому что QUIC - это универсальный транспортный протокол, который, как и TCP, может и будет использоваться в нескольких вариантах, в дополнение к HTTP и загрузке веб-страниц. Через QUIC могут работать, например, DNS, SSH, SMB, RTP и так далее. Рассмотрим QUIC немного подробнее, потому что именно здесь появляется большинство неправильных представлений о HTTP/3.
Вы, возможно, слышали, что QUIC работает поверх еще одного протокола - UDP (User Datagram Protocol / Протокол пользовательских дейтаграмм). Это правда, но не из-за производительности, как многие говорят. В идеале QUIC был бы полностью независимым новым транспортным протоколом, работающим непосредственно поверх IP в стеке протоколов, показанном на изображении выше.
Однако это привело бы к той же проблеме, с которой мы столкнулись при попытке развить TCP: все устройства в Интернете сначала должны были бы обновиться, чтобы распознавать и разрешать QUIC. К счастью, мы можем построить QUIC поверх другого широко поддерживаемого протокола транспортного уровня в Интернете: UDP.
А вы знали?
UDP - это самый простой из возможных транспортных протоколов. На самом деле он не предоставляет никаких функций, кроме так называемых номеров портов (например, HTTP использует порт 80, HTTPS находится на 443, а DNS использует порт 53). Он не устанавливает соединение с помощью рукопожатия и не является надежным: если UDP-пакет потерян, он не передается автоматически повторно. Таким образом, подход UDP “прилагать все усилия” означает, что он выжимает максимум эффективности: нет необходимости ждать рукопожатия, нет блокировки HoL. На практике UDP в основном используется для трафика в реальном времени, который обновляется с высокой скоростью и, следовательно, мало страдает от потери пакетов, поскольку отсутствующие данные в любом случае быстро устаревают (видеоконференции в реальном времени и игры). Это также полезно для случаев, когда требуется быстрая начальная загрузка данных; например, поиск доменных имен DNS занимает всего один цикл перехода по сети.
Многие источники утверждают, что HTTP/3 построен поверх UDP из-за производительности. Якобы HTTP/3 быстрее, потому что, как и UDP, не устанавливает соединение и не ждет повторной передачи пакетов. Эти утверждения ошибочны. Как мы сказали выше, QUIC и следовательно, HTTP/3 использует UDP в основном потому, что есть надежда на то, что это облегчит их внедрение, потому что UDP уже известен и реализован (почти) на всех устройствах в Интернете.
Таким образом, на основе UDP, QUIC реализует почти все функции TCP, которые делают его таким мощным и популярным (хотя и несколько более медленным) протоколом. QUIC абсолютно надежен, он использует подтверждения для полученных пакетов и повторные передачи потерянных пакетов. QUIC также по-прежнему устанавливает соединение и использует для этого сложное рукопожатие.
Наконец, QUIC также использует так называемые механизмы управления потоком и контроля перегрузки, которые предотвращают чрезмерную нагрузку на сеть или устройство получателя, но и делают TCP медленнее, чем непосредственно UDP. Ключевым моментом является то, что QUIC реализует эти функции более разумно и производительно, чем TCP. Он сочетает в себе многолетний опыт использования и лучшие практики TCP с некоторыми новыми функциями. Мы обсудим эти функции более подробно позже.
Вывод
Не бывает бесплатного обеда. HTTP/3 не волшебным образом быстрее HTTP/2 только потому, что TCP заменили на UDP. Вместо этого переосмыслили и внедрили гораздо более продвинутую версию TCP и назвали ее QUIC. И поскольку предпочтительно упростить развертывание QUIC, он запускается поверх UDP.
Большие изменения
Итак, как именно QUICK улучшает TCP? Что же в нем особенного? В QUIC есть несколько новых конкретных функций и возможностей (0-RTT данные, не требующие времени на прием-передачу; миграция соединений; повышенная устойчивость к потере пакетов и медленным сетям), которые мы подробно обсудим в следующей части серии. Все новшества сводятся к четырем основным изменениям:
- QUIC глубоко интегрируется с TLS;
- QUIC поддерживает несколько независимых потоков байтов;
- QUICK использует идентификаторы соединений;
- QUIC использует фреймы.
Давайте подробнее рассмотрим каждый из этих пунктов.
QUIC невозможен без TLS
Как вы уже знаете, TLS (Transport Layer Security protocol - протокол безопасности транспортного уровня) отвечает за защиту и шифрование данных, передаваемых через Интернет. Когда вы используете HTTPS, ваши незашифрованные HTTP-данные сначала шифруются с помощью TLS, а затем передаются по протоколу TCP.
А вы знали?
Технические детали TLS, к счастью, здесь не нужны; вам просто нужно знать, что шифрование выполняется с использованием довольно сложной математики и очень больших простых чисел. Эти математические параметры согласовываются между клиентом и сервером во время отдельного криптографического рукопожатия, специфичного для TLS. Так же, как и при рукопожатии TCP, это согласование занимает некоторое время. В более старых версиях TLS (скажем, версии 1.2 и ниже) для этого обычно требуется два обхода сети. К счастью, более новые версии TLS (последняя версия 1.3) сводят это всего к одному обходу. Это происходит главным образом потому, что TLS 1.3 строго ограничивает различные математические алгоритмы, которые могут быть согласованы, всего несколькими (наиболее безопасными). Клиент может сразу угадать, какие из них будет поддерживать сервер, вместо того, чтобы ждать явного списка, экономя время одного обхода сети.
На заре Интернета шифрование трафика было довольно дорогостоящим с точки зрения обработки. Кроме того, его не считали необходимым для всех пользовательских сценариев. Исторически сложилось так, что TLS был полностью отдельным протоколом, который при желании можно использовать поверх TCP. Вот почему у нас есть различие между HTTP (без TLS) и HTTPS (с TLS).
Со временем наше отношение к безопасности в Интернете, конечно, изменилось на “безопасность по умолчанию”. В то время как HTTP/2 теоретически может выполняться непосредственно через TCP без TLS (и это даже определено в спецификации RFC как открытый текст HTTP/2), ни один популярный веб-браузер фактически не поддерживает этот режим. В некотором смысле производители браузеров сознательно пошли на компромисс в пользу большей безопасности за счет производительности.
Учитывая эту очевидную эволюцию в сторону постоянно включенного протокола TLS (особенно для веб-трафика), неудивительно, что разработчики QUIC решили вывести эту тенденцию на новый уровень. Вместо того, чтобы просто запретить режим открытого текста для HTTP/3, они решили глубоко внедрить шифрование в сам QUIC. В то время как первые версии QUIC, ориентированные на Google, использовали для этого пользовательскую настройку, стандартизированный QUIC напрямую использует существующий протокол TLS 1.3.
Для этого он как бы нарушает типичное четкое разделение между протоколами в стеке протоколов, как мы можем видеть на предыдущем изображении. В то время как TLS 1.3 все еще может выполняться независимо поверх TCP, QUIC вместо этого как бы инкапсулирует TLS 1.3. Иными словами, нет никакого способа использовать QUIC без TLS; QUIC (и, соответственно, HTTP/3) всегда полностью зашифрован. Кроме того, QUIC также шифрует почти все поля заголовка пакета; информация транспортного уровня (например, номера пакетов, которые никогда не шифруются для TCP) больше не читается посредниками в QUIC (зашифрованы даже некоторые флаги заголовка пакета).
QUICK сначала использует рукопожатие TLS 1.3 более или менее так же, как и в случае с TCP, для установления математических параметров шифрования. Однако после этого QUICK берет управление на себя и сам шифрует пакеты, тогда как при использовании TLS-over-TCP TLS выполняет собственное шифрование. Это, казалось бы, небольшое различие представляет собой фундаментальное изменение в сторону постоянного шифрования, которое применяется на все более низких уровнях протокола.
Такой подход дает QUICK несколько преимуществ:
1. QUICK более безопасен для пользователей. В QUIC невозможно запустить открытый текст, поэтому у злоумышленников и подслушивающих устройств также меньше возможностей для прослушивания.
(Недавние исследования показали, насколько опасной может быть опция открытого текста HTTP/2.)
2. Настройка соединения QUIC выполняется быстрее. В то время как для TLS-over-TCP обоим протоколам требуются отдельные рукопожатия, QUIC объединяет транспортное и криптографическое рукопожатие в одно, экономя время одного оборота по сети (см. изображение выше). Позже мы обсудим это более подробно.
3. QUIC легче развивать. Поскольку он полностью зашифрован, промежуточные блоки в сети больше не могут наблюдать и интерпретировать его внутреннюю работу, как это происходит с TCP. Следовательно, они также больше не могут ломаться из-за отсутствия обновлений в более новых версиях QUIC. Для внедрения новых функций в QUIC в будущем, нужно будет обновить только конечные устройства, а не все промежуточные блоки.
Однако у расширенного шифрования есть и некоторые потенциальные недостатки:
1. Многие сети не решатся использовать QUIC.
Компании могут захотеть заблокировать его на своих брандмауэрах, поскольку обнаружение нежелательного трафика становится сложнее. Интернет-провайдеры и промежуточные сети могут блокировать его, поскольку такие показатели, как средние задержки и процент потери пакетов, больше не доступны, что затрудняет обнаружение и диагностику проблем. Все это означает, что QUIC, вероятно, никогда не будет общедоступным.
2. QUIC использует больше ресурсов на шифрование.
QUIC шифрует каждый отдельный пакет с помощью TLS, в то время как TLS-over-TCP может шифровать несколько пакетов одновременно. Это потенциально замедляет работу QUIC в сценариях с высокой пропускной способностью.
3. QUIC делает Интернет более централизованным.
Часто встречаются жалобы вроде “Google продвигает QUIC, потому что он предоставляет им полный доступ к данным, не делясь ими с другими”. Это не совсем так. Во-первых, QUIC скрывает не больше (и не меньше!) пользовательской информации (например, какие URL-адреса вы посещаете) от внешних наблюдателей, чем TLS-over-TCP (QUIC сохраняет статус-кво).
Во-вторых, хотя Google и инициировала проект QUIC, окончательные протоколы, о которых мы говорим сегодня, были разработаны гораздо более широкой командой в Internet Engineering Task Force (IETF). QUIC IETF технически сильно отличается от QUIC Google. Тем не менее, правда и то, что люди в IETF в основном из крупных компаний, таких как Google и Facebook, и Сетей доставки (и дистрибуции) содержимого (Content Delivery Network - CDN), таких как Cloudflare и Fastly. Из-за сложности QUIC, это в основном те компании, которые обладают необходимыми знаниями для правильного и эффективного внедрения, например, HTTP/3. Это, вероятно, приведет к большей централизации в этих компаниях, что может стать причиной для беспокойства.
Вывод
QUIC по умолчанию зашифрован. Это не только улучшает его характеристики безопасности и конфиденциальности, но и способствует его внедрению и развитию. Запуск протокола немного усложняется, но, в свою очередь, позволяет другие оптимизации, такие как более быстрое установление соединения.