Сетевой протокол HTTP/3 в разработке с 2016 года, а его транспорт QUIC вышел в 2013-м. На сегодняшний день оба эти стандарта поддерживаются всеми ведущими браузерами (кроме Samsung и Opera Mini) и составляют 32,5% HTTP-запросов на Cloudflare, что отражает актуальное состояние всего интернета. Но темпы внедрения HTTP/3 крайне медленные.
Что же мешает веб-мастерам перейти на современный стандарт и ускорить загрузку сайтов? Основная причина в том, что ни QUIC, ни HTTP/3 до сих пор не включены в стандартные библиотеки популярных языков программирования Go, Rust, Python и Ruby. Они не активированы по умолчанию в Node.js, веб-серверах Nginx и Apache. Прошло более десяти лет, но протокол всё ещё считается экспериментальным! Удивительно.
Бенчмарки HTTP/3
HTTP/3 кардинально улучшает производительность сайтов в реальных условиях, особенно для мобильных пользователей и под большой нагрузкой. В бенчмарках можно посмотреть, как переход с HTTP/2 на HTTP/3 влияет на скорость загрузки и количество сбоев.
На графиках ниже один и тот же браузер использовался для запроса трёх сайтов через одну и ту же сеть, изменялась только версия HTTP. Каждый сайт загружался 20 раз, время отклика измерялось через API. В тестовой установке было три сайта (перечислены ниже).
Маленький сайт
10 JS-файлов от 2 до 100 КБ
10 картинок от 1 до 50 КБ
600 КБ в сумме, 20 блокирующих ресурсов
Контент-сайт
50 JS-файлов от 2 КБ до 1 МБ
55 картинок от 1 КБ до 1 МБ
в сумме 10 МБ, 105 ресурсов
SPA
85 JS-файлов от 2 КБ до 1 МБ
30 картинок от 1 до 50 КБ
в сумме 15 МБ, 115 ресурсов
Контент раздаётся веб-сервером Caddy, все ответы отправлялись с заголовком 'Cache-Control: "no-store" для отключения кэширования. Для HTTP/1.1 и HTTP/2 использовался TLS 1.2, для HTTP/3 — TLS 1.3 и 0-RTT.
На графиках ясно видно улучшение производительности с каждой новой версией HTTP при размещении сервера в дата-центрах Нью-Йорка, Лондона и Бангалора (Индия). Во всех случаях клиент находится в Миннесоте.
При загрузке с близкого сервера (1600 км между MN и NY) время загрузки уменьшается примерно на 40% для всех сайтов.
В случае Лондона ускорение гораздо заметнее: время загрузки при загрузке контента по HTTP/3 примерно в 2−2,5 раза меньше, чем по HTTP/2. Результаты HTTP/1.1 можно вообще не рассматривать — тот стандарт предусматривал последовательную передачу файлов с сервера клиенту по TCP, и любая задержка в одном файле блокирует все остальные.
Контент из Бангалора доставляется примерно в 2,5−3 раза быстрее по HTTP/3. Например, для маленького сайта задержка уменьшается с 2,4 до 1 секунды.
Основные преимущества HTTP/3
Значительно увеличенная устойчивость к ненадёжным сетям. В новом протоколе отказались от строгого порядка пакетов в TCP, так что каждый поток полностью независим, а потерянный пакет в одном потоке не замедляет другой.
Инициализация соединения с 0-RTT, который позволяет клиенту отправлять зашифрованные данные серверу в первом же пакете, устраняя задержку на установку соединения. В QUIC не нужно ждать рукопожатия TLS. То есть можно подключиться к серверу и сразу отправить HTTP-запрос, не дожидаясь ни одного пакета в ответ. Это и значит «нулевое время кругового обхода», то есть 0-RTT.
Сокращение трафика, количества подключений и RTT. Всё это уменьшает энергопотребление на клиентах и серверах, ускоряет обработку запросов и увеличивает производительность серверов (например, на максимальное количество подключённых пользователей).
Миграция соединений позволяет клиенту сохранить соединение даже при смене IP-адреса и, теоретически, даже с нескольких IP-адресов (например, одновременно по Wi-Fi и сотовой связи для дополнительной скорости и надёжности).
Улучшенное управление сетевыми заторами по уникальной технологии BBR (Bottleneck Bandwidth and RTT), улучшенное восстановление после потери пакетов, теоретически возможная поддержка коррекции будущих ошибок (Forward Erasure Correction, FEC).
Поддержка WebTransport для двунаправленных полудуплексных соединений. Протокол устраняет многие ограничения WebSockets (как несовместимость с CORS) и обеспечивает более низкую задержку в потоковых соединениях.
Поддержка веб-сайтами
С 2022 года поддержка HTTP/3 выросла с 18% до 32%, но в последние месяцы по графикам рост не особенно заметен.
Хотя HTTP/3 десять лет в разработке, он до сих пор в стадии предложенного стандарта (RFC 9114) и существует множество его реализаций.
Одна из причин медленного внедрения — кардинальная смена транспортного протокола, переход с TCP на QUIC. По этой причине браузер на практике будет использовать HTTP/3 только в том случае, если на 100% уверен, что сервер его поддержит. Иначе возникнет задержка на несколько секунд, чтобы откатиться на HTTP/2 и установить новое TCP-соединение, а это длительный процесс.
Как браузер может быть на 100% уверен? Только если сервер явно сообщит браузеру, что поддерживает HTTP/3 через заголовок HTTP Alt-Svc или через запись DNS HTTPS.
Даже если сервер поддерживает HTTP/3, но не сообщит браузеру об этом, тот просто не инициирует соединение HTTP/3, даже не попробует его использовать, потому что это слишком дорого стоит! Вот ещё одна причина замедления в принятии HTTP/3.
Запись DNS HTTPS — самый оптимальный способ объявления о поддержке HTTP/3, но он относительно новый — и не все веб-мастеры знают о нём.
По статистике Web Almanac, новый протокол поддерживали всего 28% сайтов в 2024 году.
Правда, эта статистика не совсем достоверна, потому что при использовании механизма Alt-Svc соединение по HTTP/3 обычно используется только со второй страницы сайта, а первая идёт по HTTP/2 или HTTP/1.1, даже если сервер поддерживает HTTP/3. И в этом заключается суть проблемы, так как Web Almanac измеряет только первую загрузку страницы.
Интересно, что мобильные главные страницы немного лучше поддерживают HTTP/3, чем страницы для десктопных браузеров. Это можно объяснить тем, что HTTP/3 в основном даёт преимущества в мобильных сетях.
Похоже, что быстрое принятие новых технологий — прерогатива крупных компаний, а рядовые фирмы и веб-мастеры гораздо медленнее переходят на новый стек. Развернуть проект на HTTP/3 со всеми новыми функциями, включая 0-RTT, далеко не так просто.
Кроме того, многие популярные веб-серверы до сих пор не включили HTTP/3 «из коробки».
В Nginx поддержка HTTP/3 добавлена в версии 1.25.0, но выключена по умолчанию. Чтобы активировать его, администратор должен вручную прописать в конфигурации директивы
listen 443 quicиhttp3 on, см. инструкцию и модуль ngx_http_v3_module.В Node.js функция находится в экспериментальном статусе.
В Apache полноценная поддержка отсутствует, протокол признан экспериментальным.
Для включения HTTP/3 на Windows Server 2022 тоже требуются довольно эзотерические шаги, начиная с добавления двух ключей в реестр. Один для HTTP/3:
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\HTTP\Parameters" /v EnableHttp3 /t REG_DWORD /d 1 /f
Другой ключ для заголовков Alt-Svc:
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\HTTP\Parameters" /v EnableAltSvc /t REG_DWORD /d 1 /f
Под Windows Server работают миллионы сайтов. Возможно, это один из факторов, которые замедляют всеобщий переход на HTTP/3.
В то же время некоторые крупные IT-компании полностью переходят на HTTP/3. Например, CDN Facebook (принадлежат Meta, чья деятельность признана экстремистской и запрещена в России) показывает HTTP/3 в 99,86% ответов, а CDN Automattic — 99,92%.
Отдельные страны тоже показывают аномально высокий уровень внедрения HTTP/3. Вероятно, это связано с централизацией инфраструктуры интернета — использованием крупных международных CDN. Например, Cloudflare включил поддержку HTTP/3 по умолчанию на всех бесплатных планах.
Кроме того, в этих странах мобильный интернет развит лучше проводного. Вдобавок трафик из глобального интернета к ним идёт за тысячи километров — а в таких условиях HTTP/3 наиболее эффективен.
В целом, внедрение HTTP/3 идёт очень медленно. Оказалось, что замена TCP на UDP (QUIC) требует значительной переделки стандартных библиотек, а продвинутые функции HTTP/3 оказались слишком сложными в реализации на клиентском уровне. Сложно найти хотя бы один популярный проект Open Source, который полностью поддерживает HTTP/3. Это просто поразительно, учитывая эффективность и все выгоды от внедрения новой технологии.
Похоже, большинство компаний решили, что проще поддерживать на уровне CDN, а не в своих приложениях. В итоге интернет разделился на две части: 1) технологические лидеры; 2) длинный хвост (две трети интернета).
Основные браузеры, крупные CDN (Cloudflare, Akamai, Fastly, CloudFront), облачная инфраструктура Google, Meta (признана экстремистской и запрещена в России), Amazon, Microsoft и отдельные мобильные приложения.
Все остальные: API-клиенты и серверы, мобильные приложения, маленькие CDN, большинство веб-сайтов, десктопные приложения, IoT, боты, приложения на самохостинге, консольные программы и скрипты и многое другое, что не поддерживает HTTP/3. Отсутствие поддержки HTTP/3 уже стало маркером небраузерных клиентов и ботов.
Пока ситуация такова, что преимуществами быстрого интернета пользуются лишь крупные IT-корпорации, а бóльшая часть населения фактически не имеет доступа к новой технологии, кроме как путём подписки на услуги CDN компаний из «продвинутой» части интернета.
Остальным же приходится работать на старом стеке без 0RTT, WebTransport и др. А ведь в будущем ожидается ещё больше технологий на базе HTTP/3 (как gRPC на HTTP/2). Очень печально, если эти преимущества будут доступны лишь небольшому числу организаций и их клиентам.
© 2026 ООО «МТ ФИНАНС»
Комментарии (36)
Aleksandr_Lar
05.08.2026 07:39Пока ситуация такова, что преимуществами быстрого интернета пользуются лишь крупные IT-корпорации, а бóльшая часть населения фактически не имеет доступа к новой технологии
От меня при чтении статьи ускользнули преимущества технологии для простого пользователя. То есть где в вульгарном пользовательском опыте (зашёл в интернет почитать хабр, посмотреть видео, попереписываться в мессенджере и так далее) применение HTTP/3 даст качественное повышение этого самого пользовательского опыта?
AVX
05.08.2026 07:39Так статья и не об этом. Тут уже были статьи про http3 и что он даëт пользователю. Кратко - уменьшение задержек, увеличение скорости загрузки, особенно в мобильных сетях и других, когда ip адрес пользователя меняется.
Aleksandr_Lar
05.08.2026 07:39А, понял. Впрочем, мне кажется, что снижение времени передачи пакетов/кадров для конечного пользователя будет незаметно, если он не качает огромные массивы информации.
Впрочем, здесь можно порассуждать в том ключе, что расширение технических возможностей (пропускной способности канала, объёма памяти, мощности процессора) для пользовательских приложений ведёт к ухудшению качества исполнения, этакий парадокс Браеса, которому мы видим иногда эмпирические подтверждения.
diderevyagin
05.08.2026 07:39мне кажется, что снижение времени передачи пакетов/кадров для конечного пользователя будет незаметно, если он не качает огромные массивы информации.
есть ситуация когда это поможет.
Сеть с сильно прыгающим временем прохождения пакета
Пользователи мобильных сетей, старлинка и так далее - первые бенефицианты этого нововведения. Когда RTT прыгает, UDP дает более внятный результат по задержкам.
nooblik
05.08.2026 07:39Снижение времени передачи пакетов на лишние 200мс фигня. Основная причина в анонимности этих самых пакетов. ТСПУ не сможет блокировать по SNI и tls hello. А в "цивилизованных" и развитых странах и подавно.
Когда блокировали сайты у меня, всё ждал DoH, DoT и его повсеместного внедрения. Прятал сайты и айпи за cloudflare. Государству ничего не стоило просто взять и "зарезать" этот сервис ради своей безопасности. Ничего и не будет стоить зарезать и http3
achekalin
05.08.2026 07:39Чтобы получить возможность эволюционировать транспортный протокол без изменения ОС и миллионов middlebox’ов, разработчики перенесли транспорт из ядра в userspace и заплатили за это дополнительной сложностью, CPU overhead и ухудшением сетевой наблюдаемости.
Но если сайт через него стал открываться плохо - отдебажить такое врагу не пожелаешь.
fhunter
05.08.2026 07:39От меня при чтении статьи ускользнули преимущества технологии для простого пользователя.
Следилдо ;-) (там уникальный ID есть, за счёт которого как раз возможна миграция между IP).
PS. для того чтобы миграция работала на nginx - нужна как минимум поддержка ещё и в ядре - там вроде как на eBPF что-то нужно. Я посмотрел и сказал - “да ну его к чёрту”.
AVX
05.08.2026 07:39Вроде же ничего такого сверхестественного не было для этого нужно, или я забыл уже, когда ковырял эту тему (может с тех времён поменялось чего, конечно).
К слову, даже для openvpn нужно что-то там с ядром (модуль чтоль какой-то), чтобы заметно шустрее работало, но я не тестировал, насколько муторно это и на сколько что-то изменится.
linux-over
05.08.2026 07:39а проблема ещё в том, что в свете начавшейся борьбы с vpn почти повсюду заблокировали udp
что ставит крест на http 3, по крайней мере в России
AlexeyPolunin
05.08.2026 07:39Вот это хороший вопрос, как по поводу него РКН возбуждается
igurylev
05.08.2026 07:39Пару месяцев назад столкнулись с регулярной недоступностью сайта.
Проблема была плавающая и повторялась почти каждый день в течение 1-2 часов.
По совету из одной из местных тем выключили http3 и tls1.3 - сразу стало хорошо.
Если и совпадение - то крайне странное
AVX
05.08.2026 07:39А tls1.3 зачем? Вроде как с точки зрения ИБ, сейчас это единственный считающийся безопасным протокол (в целом и 1.2 тоже ок, но там есть гораздо больше возможностей настроить небезопасный шифронабор, в случае с 1.3 такое просто не получится сделать).
fhunter
05.08.2026 07:39в tls1.3 появился шифрованный SNI (eSNI), вероятно. И его некоторое время назад активно блокировал РКН. Потому что - а как узнать - на какой домен за CDN-ом ходят?
funca
05.08.2026 07:39Просто поддержка сервера http/3 в стандартных библиотеках языков программирования ни кому не уперлась: ни кто в здавом уме не выставляет сервер на node.js, python, и т.п голым задом в интернет. Перед ним будет CDN, который закрывает
собойещё массу других вопросов.Проблема, которую решает этот протокол, возникает в сетях пользователя. Браузеры и основные CDN его поддерживают, что удовлетворяет 99% потребностям в web. Для не-браузеров по большому счету нужна лишь клиентская часть.
На бекендах сети быстрые и стабильные, там больше популярны всякие gRPC (http/2 хватает заглаза).
achekalin
05.08.2026 07:39А http/3 между сервером и CDN (если они в сетевом смысле близко находятся, и оба стоят в ЦОД) большого прямо смысла не имеет. Вот от CDN до клиента - да. Если бы не непредсказуемость РКН, когда из диапазона адресов CDN-сети могут заблочить рандомно несколько - то был бы актуален совет идти к Cloudflare, а тот уже до клиента имеет http/3...
ki11j0y
05.08.2026 07:39Ну, не поддерживает тот же апач h3 ну и что? Есть обратный прокси, это удобно, а там уже может и h3 жить смело, перевёл сервер на haproxy 3.2 завёл quic, alt svc добавил, и да, современные браузеры переходят на quic. Тут сейчас другой вопрос, это ркн, и ситуация с quic в стране не стабильная.
MrKirushko
05.08.2026 07:39Главная проблема QUIC в том что его разработчики смотрят на проблему с чисто теоретической точки зрения и это подходит только для случаев когда ресурсы почти не ограничены, вроде Google или Yandex или крупных хостеров. В реальности же существует как некоторое желание так и в России во многих случаях необходимость в локализации серверов, либо у небольших Hosting-провайдеров, чтобы по дешману, либо и вовсе в своей корпоративной сети и на своем старом каком-нибудь сервере. И тут мы сталкиваемся с тем что если мы произведем измерения то в реальности на типичном Linux-сервере TCP имеет просто большую эффективную пропускную способность чем UDP. В первую очередь - из за того что большая часть кода реализующего обмен с TCP уже включена в протокол и работает в пространстве ядра, в то время как с UDP все остается за приложением и библиотеками которые оно использует что в итоге увеличивает количество системных вызовов, но также немалую роль играет и то что современные сетевые карты поддерживают аппаратное ускорение многих операций необходимых для реализации этого протокола. Можете у себя в консоли дать команду
ethtool -k eth0(разумеется, заменив eth0 на имя своего интерфейса) и посмотреть что содержащийся в ядре вашей ОС драйвер вашей сетевухи поддерживает и что включено. Со временем новые сетевые карты, Linux и чипсеты материнок, конечно, подтянутся, но во первых никто так сходу обновлять уже решающее все задачи железо не будет, а во вторых все равно остается вопрос о том что какой смысл если и так все как-то работает.Проще говоря, пользователей много а сервер один, и если у этих юзеров там на пол секунды будет сайт дольше открываться то ничего - подождут, не умрут. В любом случае такая мелочь не стоит перелопачивания всей системы. Небольшое увеличение сетевого траффика - тоже не проблема. А вот то что для обслуживания сравнимого с TCP-HTTP количества клиентов с QUIС нужно будет тупо выделить виртуалке больше вычислительных ресурсов и докупить новых серверов - это уже критично, за это прийдется платить сразу и по полной. И все эти расходы, разумеется, ни на продажи ни даже на посещаемость интернет-ресурса явно никак заметно не скажется. Поэтому то этот протокол никому кроме своих создателей из Google особо и не нужен - в целом интересно и прикольно, но в целом чисто баловство, реально большого смысла нет.
Если бы не большая страшная надпись в стиле "Этот сайт очень-очень опасен, злобные хакеры через него смогут украсть всю твою коллекцию вкладышей от жвачек Turbo, так что подумай 100 раз прежде чем заходить" во всех популярных браузерах при открытии страницы без шифрования то и HTTPS у нас был бы гораздо менее распространен.
anoldman25
05.08.2026 07:39Я смотрю на это с такой стороны: в мире до фига (не знаю как правильно до фига или дофига?) потрачено, вложено денег в кабели, роутеры и т.д. И если какая то программа поможет сэкономить 1% пропускной скорости, то это будет огромная экономия, которую можно потратить на вознаграждение акционеров, покупку новых кабелей. оборудования. При условии, что ничего в кабелях, оборудовании менять не надо. И это при том, что услуги имеют свойство только дорожать.
Я как раз сегодня читал про quic. там написано, что он позволяет поддерживать соединение при переходе из одной сети в другую. Конечно можно сказать, что это фигня никому не нужная. Но очень полезная при неустойчивой работе сети. Хотя все же дома сидят. На гигабитном интернете.
Продолжаем ездить на своих лошадях.
MrKirushko
05.08.2026 07:39Так я и не спорю что если смотреть с точки рения общемировой экономии то это все действительно имеет смысл и вполне оправданно и если бы мы жили при коммунизме то можно было бы просто централизованно доработать микропрограммы всех стандартных сетевух сертифицированных единым комитетом по вопросам пакетной связи, централизованно через сеть единых микропрограммных репозиториев разослать везде по всему прогрессивному миру это обновление, то же самое проделать по драйверам для всех единых ОС, и все - этот самый мир сразу на следующих же день стал бы лучше: и пользователи получили бы преимущества в виде чуть большей скорости соединения и адекватном переносе соединения при роуминге, и провайдерам загрузка каналов уменьшилась бы.
Но это все - чисто теоретические измышления, к реальному миру не применимые, типичные обитатели страны эльфов это все придумали. На практике же выясняется что ничего нигде нормально не организованно, у всех стоит то что когда-то смогли достать или просто то что сложилось исторически, и для большинства тех кому реально ради этого перехода пришлось бы напрячься и потратиться оно просто и близко того не стоило бы. На всех же остальных халявщиков всем просто побоку изначально. Кошка бросила котят, пусть [выживают] как хотят...
anoldman25
05.08.2026 07:39Ну меня в сущности не интересуют вещи, на которые я не могу повлиять. Пусть люди работают как могут. Лично я, когда подсоединялся к сети yggdrasil, использовал протокол quic. Его похоже в москве не блокируют. По крайней мере у меня работает. И на даче работает. А там связь не очень. 1% к лучшей жизни 8)))
А так я согласен. С людьми трудно!
korn3r
05.08.2026 07:39"Этот сайт очень-очень опасен, злобные хакеры через него смогут украсть всю твою коллекцию вкладышей от жвачек Turbo, так что подумай 100 раз прежде чем заходить"
Это какие браузеры так про http пишут? Максимум шилдик "не защищено" рядом с адресной строкой в firefox, например.
MrKirushko
05.08.2026 07:39Так как раз Firefox несколько лет назад и писал вместо отображения страницы "Подключение не защищено", они то на это моду и ввели! Как сейчас ситуация там я не знаю, давно уже в Firefox не заходил, возможно и откатили уже эту тему, но ущерб индустрии уже нанесен.
Я, кстати, только что проверил этот момент с Google Chrome на Android и могу сказать что эти уже пошли еще дальше - оно просто вообще незашифрованные страницы открывать не дает. Chrome принудительно http:// в адресной строке заменяет на https:// и если 433-й порт у вас закрыт то соединение вываливается с ошибкой по таймауту. ЯБраузер при этом на том же самом Android-смартфоне все нормально открывает и даже вопросов не задает.
korn3r
05.08.2026 07:39проверил сейчас на хроме на андроиде - http сайт открылся нормально, но с восклицательным знаком слева от адресной строки.
MrKirushko
05.08.2026 07:39Может версия у вас отличается, может версия Android-а, может еще что (у меня это v150.0.7871.186 на Android 15, тестовой страницей была mrkirushko ru).
korn3r
05.08.2026 07:39Chrome 151.0.7922.83 Android 16, сайт http://httpforever.com
вайш сайт кстати и у меня по таймауту отвалился. хотя курлом норм открывает
UPD: если в хроме ткнуть "Версия для ПК", то нормально открывается и ваш сайт.
korn3r
05.08.2026 07:39" В Nginx поддержка HTTP/3 добавлена в версии 1.25.0, но выключена по умолчанию. Чтобы активировать его, администратор должен вручную прописать в конфигурации директивы
listen 443 quicиhttp3 on, см. инструкцию и модуль ngx_http_v3_module. "так получается и http/2 нгинкс "не поддерживает". http2 по-молчанию тоже в off
а то что веб-серверу надо явно указать quic, так это в первую очередь чтобы нгинкс начал вообще слушать UDP, а не TCP.
korn3r
05.08.2026 07:39И кстати, чтобы QUIC нормально работал на многоядерном сервере, желательно помимо прослушивателя и http3 on серверу включить quic_gso (оффлоад UDP) и bpf
в основной блок
quic_bpf on;в блок http
quic_gso on;плюс прав ему надо дописать если это докер
cap_add: - BPF - NET_ADMIN - PERFMONAVX
05.08.2026 07:39Спасибо! Довольно интересная инфа, не знал. А для обычного сервиса nginx не надо будет добавлять эти капсы? (ну там, в systemd-юните прописать, например)
korn3r
05.08.2026 07:39вроде нет, но ему надо от рута стартовать для этого. как сделать без рута я пока особо не смотрел (может кстати капы в системд и помогут). плюс если это рхел, то ему еще и правил надо для selinux прописать много помимо очевидного убирания 443/udp из reserved_port
redfox0
https://nginx.org/ru/docs/http/ngx_http_v3_module.html
achekalin
Да и бенчмарк в статье не является чистым сравнением HTTP/2 и HTTP/3: для HTTP/1.1 и HTTP/2 использован TLS 1.2, а для HTTP/3 — TLS 1.3 плюс 0-RTT; кэширование отключено, страницы искусственно раздроблены на десятки файлов. Часть показанного ускорения поэтому относится не собственно к HTTP/3.
Ещё несколько мелочей:
BBR не является «уникальной технологией QUIC» — он применяется и с TCP.
WebTransport обеспечивает полнодуплексный, а не полудуплексный обмен: это ошибка перевода исходного текста.
HTTP/1.1 не обязательно передаёт все файлы строго последовательно: браузеры давно открывают несколько TCP-соединений.
0-RTT работает при повторном подключении к уже известному серверу и имеет риск повторного воспроизведения запросов; это не бесплатное ускорение любого первого запроса.
В свежих версиях Node.js QUIC всё ещё находится в активной экспериментальной разработке, а в curl неэкспериментальным считается только один из нескольких QUIC-бэкендов. Lf b
То есть реальная картина такая: протокол хороший и уже массово работает на границе сети, но его преимущества локальны, а внедрение требует замены половины хорошо отработанного сетевого стека. Статья превращает это в загадку «почему ленивые разработчики не включили полезную функцию», одновременно вырезав из оригинала (датированного мартом 2025 года) раздел, где содержался настоящий ответ.