Представьте, что дороги в вашем городе заменили за ночь: больше нет светофоров на каждом перекрёстке, машины едут быстрее, а пробки исчезают сами собой.
Так же внезапно (и не так уж безболезненно) интернет получил новую «дорожно-транспортную» логику: QUIC и HTTP/3. В этой статье разберём, что конкретно дают HTTP/3/QUIC веб- и мобильным приложениям, где эффект заметен сразу, а где — только после тщательного теста. Детали под катом.
Откуда HTTP и зачем он меняется
Если «везде уже https», почему обсуждение ведётся не про него? Дело в том, что HTTPS — это надстройка, при которой все передачи данных защищаются TLS (SSL). Но как технология не определяет ни транспортный уровень, ни детали организации потоков — она отвечает именно за шифрование и верификацию серверов.
Запросы включают: HTTP-метод, глагол (GET, POST) или существительное (OPTIONS, HEAD), определяет операцию, которую выполнить. Далее указан путь к ресурсу. В данном случае URL не содержит элементов, которые можно было бы определить из контекста, таких как протокол (например, http:// или https://), доменное имя или номер TCP-порта (например, 80). Ещё есть необязательные заголовки, предоставляющие доп. информацию для сервера. И тело, которое содержит отправленный ресурс, для некоторых методов (типа POST).
HTTP — это протокол запрос-ответа: браузер (или клиент) задаёт серверу вопрос «дай мне страницу/картинку/данные», сервер отвечает. Расшифровывается эта аббревиатура, как HyperText Transfer Protocol, что означает «протокол передачи гипертекста».
Проще говоря, HTTP — это набор правил, по которым браузеры и другие приложения обмениваются данными с серверами в интернете. Всё это появилось в начале 1990-х — когда веб был прост: голый html, короткие соединения, и схема «отправил-получил» работала отлично. Трафика было мало, пользователей — немного, и задержки не резали UX.
В ответе содержится: Версия HTTP-протокола, код состояния (успешен или провален запрос), сообщение состояния (описание кода состояния). Ещё включает HTTP-заголовки, как заголовки в запросах и тело, содержащее получаемый ресурс (необязательно).
Потом интернет вырос. Появились сайты с сотнями мелких ассетов, одностраничные приложения (SPA), мобильный трафик, стриминг. Это всё сценарии, где отклик и параллельная загрузка стали критичны. Вместе с интернетом рос и протокол. HTTP/1.1 ввёл keep-alive и частичную pipelining. Потом HTTP/2 принёс многообещающее мультиплексирование и сжатие заголовков. Казалось, апдейты решат проблему — но осталась одна фундаментальная штука. Транспорт под HTTP — TCP — требовал строгого порядка доставки пакетов. И вот тут зародилась новая боль.
Представьте обычную железную дорогу с одним путём. Если тягач или вагон стоит на месте/ломается, то весь состав встал. Поезд никуда не двинется, пока не уберут этот вагон, потому что нет запасных путей объезда.
В транспортных сетях через TCP происходит примерно то же самое — весь поток данных считается последовательной лентой байтов, и если один пакет утерян в пути, остальные пакеты, которые пришли позже, приходится «задержать» и подождать, пока пропавший пакет не будет переслан.
HTTP/2 мог отправлять много потоков поверх одного TCP-соединения, но если нет запозданий со стороны TCP. Решение: заменить «один путь, то бишь порядковую подачу» на другую модель — гибкую, с возможностью параллельного движения и быстрым стартом.
Так родился QUIC, изначально проект Google. Идея простая, взять UDP, более «голый» транспорт, на нём реализовать новый, умный транспортный слой. В котором уже будет мультиплексирование, встроенный TLS и идентификаторы сессий.
HTTP поверх QUIC — это и есть HTTP/3. Чем меньше взаимодействий, тем меньше блокировок и сессии не умирают при смене сети.
Коротко о QUIC
QUIC — это современная альтернатива традиционному транспорту интернета. Технически он строится поверх UDP, но внутри реализует те функции, к которым мы привыкли у TCP. А именно контроль потерь, управление потоком и надёжная доставка — только в библиотеке, а не в ядре. Почему это важно? Два простых эффекта.
Во-первых, мультиплексирование: в одном соединении можно вести несколько независимых потоков — потеря пакета в одном потоке не блокирует остальные.
Технически это выглядит так: QUIC реализует управление потоком и согласование порядка доставки для каждого потока отдельно. Каждому потоку выделяется отдельный идентификатор, а пакеты QUIC содержат заголовки с информацией о размере и номере потока. Данные можно лучше разделять, а передачу восстанавливать.
Во-вторых, сократить время установления защищённого канала — до 1-RTT или 0-RTT может встроенный TLS 1.3, даже при повторных подключениях. В классическом TCP+TLS, сначала устанавливается соединение TCP (3-RTT), а затем TLS (1-RTT), что вместе даёт большую задержку.
Для пользователя это значит: меньше подтормаживаний, быстрее первые байты и более плавное переключение между Wi-Fi и сотовой сетью, потому что QUIC привязывает сессии к идентификаторам, а не только к IP-адресам.
HTTP/3 — что изменилось сверху
HTTP/3 во многом унаследовал функциональность и семантику HTTP/2, включая методы запросов, статусы и структуру сообщений, однако ключевое отличие — замена транспортного протокола с TCP на QUIC поверх UDP, что повлекло за собой ряд существенных изменений в механизмах сжатия заголовков и облегчении мультиплексирования потоков.
Одной из важных новаций стал переход от HPACK к QPACK — двум алгоритмам для эффективной компрессии HTTP-заголовков. HPACK, используемый в HTTP/2, работает в условиях строго упорядоченной доставки данных TCP, благодаря чему сжатие и декомпрессия происходит синхронно и упрощённо, с общей динамической и статической таблицей заголовков. Это позволяет сократить объём передаваемых данных, но в то же время HPACK подвержен проблеме head-of-line blocking (HOL): если TCP-пакет теряется, вся очередь мультиплексированных потоков блокируется, что заметно увеличивает задержки.
QPACK, внедрённый в HTTP/3, изначально проектировался с учётом особенностей QUIC: в частности, отсутствия гарантии упорядоченной доставки между потоками. QPACK реализует асинхронное взаимодействие между кодировщиком (encoder) и декодировщиком (decoder) заголовков через выделенные односторонние потоки управления, позволяя отслеживать и синхронизировать состояние компрессируемой таблицы между клиентом и сервером отдельно от основного потока данных. Это снижает риск блокировки передачи заголовков при потере пакетов и снижает задержки их восстановления.
Техника QPACK использует две таблицы: статическую — с фиксированными часто используемыми заголовками, и динамическую — содержащую недавно переданные поля. Важное отличие — адресация записей в статической и динамической таблицах происходит раздельно, что повышает гибкость и эффективность сжатия. Кроме того, QPACK поддерживает более сложные стратегии кодирования, включая кодирование заголовков быстрым способом (quick encoding) с одной байтовой длиной, что ускоряет обмен данными.
В результате QPACK позволяет избежать проблем head-of-line blocking на уровне заголовков, что было критично в HTTP/2 из-за накладных расходов TCP, и обеспечивает более высокую устойчивость параллельных запросов и ресурсов к сетевым потерям и задержкам. Это особенно заметно в современных распределённых приложениях и микросервисах с большим количеством мелких, но частых API-запросов, где скорость и надёжность первично важны.
Где реально почувствуете разницу
Влияние QUIC и HTTP/3 уже заметно на уровне конечных приложений, но при этом всё зависит от конкретного профиля трафика и сценариев использования.
Наиболее ощутимо в области мобилок и их трафика. Что можно представить, думая о мобильных устройствах? Скорее всего, вы подумали о частой смене сетей, переключении между Wi-Fi и мобильным интернетом, и зоны, где то ловит, то не ловит (разное качество связи). И вы будете правы.
В обычном TCP каждый раз нужно заново устанавливать соединение. Из-за этого частые разрывы и задержки. Спасли всё уникальные идентификаторы, connection ID. Они сохраняли сессию при смене IP адреса или сети. Также упростили балансировку нагрузки на серверных кластерах, обеспечивая более стабильный background-синхронный обмен данными. Это делает заметно плавнее пуш-уведомления, синхронизацию и обновления приложений.
HTTP/3 значительно сокращает p99 время загрузки каждого мелкого ресурса, что заметно улучшает основные метрики загрузки — LCP (Largest Contentful Paint) и TTFB (Time To First Byte). Это даёт SPA (Single Page Applications), сайтам с множеством мелких ассетов и API-запросов, быть отзывчивее и обеспечивать лучший пользовательский опыт, особенно в условиях сетей с потерями пакетов.
Игры и стриминг с низкой задержкой получают выгоду от быстрого установления сессии — у QUIC время рукопожатия значительно короче. Установление защищённого канала и улучшенное управление малыми сообщениями внутри сессий делает интерактивный контент более плавным и отзывчивым, снижая лаги и прерывания.
Для оценки эффекта внедрения важно системно измерять ключевые метрики: время настройки соединения (connection_setup_ms) по p50/p95/p99, время до первого байта (time_to_first_byte_ms), задержки критичных запросов (request_latency_ms), а также error_rate и количество reconnect’ов в мобильных сценариях. Наряду с этими техническими параметрами следует учитывать бизнес-метрики — конверсию и bounce rate, так как задержки напрямую влияют на UX и поведение пользователей.
Реальная польза проявляется особенно в «плохих» сетях, где улучшения p99 по задержкам достигают десятков процентов. В «хороших» сетях эффект будет менее выражен, но всё равно часто ощутим, особенно по tail latency, что влияет на стабильность и плавность интерфейса.
Быстрая проверка поддержки HTTP/3 доступна через curl с ключом --http3, а в браузерах достаточно посмотреть в DevTools секцию Protocol, где должен быть помечен протокол h3, чтобы удостовериться, что используемый хост поддерживает новый стандарт.
Подводные камни, безопасность и best practices
Если разбирать их по категориям, получается интересная картина.
Первое, с чем сталкивается любой разработчик сетевого стека, реализация Path MTU Discovery. QUIC не допускает IP-фрагментации UDP-пакетов из-за потери целого пакета при выпадении фрагмента. На этапе установления соединения QUIC использует минимальный размер Initial пакетов 1200 байт, затем динамически определяет максимально возможный размер пакета с помощью Packetization Layer PMTUD (RFC 8899) — активных пробных пакетов, не зависящих от часто блокируемых ICMP. Необходимо мониторить и кешировать PMTU, управлять backoff и логировать результаты через qlog.
Вторая группа проблем связана с потерями. Базовый стандарт QUIC не предусматривает Forward Error Correction, но многие коммерческие реализации добавляют FEC-слой поверх фреймов. Смысл в том, что блоки данных кодируются в избыточные пакеты и при потерях можно восстановить до N кадров без повторной передачи. Это снижает задержки, но даёт дополнительный overhead в пределах 5–10 %.
Также стоит внимание уделить отсутствию поддержки TCP Offload — QUIC полностью жизнеспособен в user space, что повышает нагрузку на CPU серверов. Часто требуется внедрение решений с DPDK, eBPF или аналогичных ускорителей, особенно для продакшен-систем. Без этого не будет обработки UDP и шифрования.
Механизмы безопасности уровня сессий. Stateless Reset — инструмент, позволяющий серверу завершать соединение без хранения состояния. Но здесь есть риск DoS-атак, если reset_token окажется предсказуемым или злоумышленник начнёт генерировать большое число reset-запросов.
Не стоит забывать и про контроль перегрузок. QUIC использует алгоритмы вроде BBR или Cubic, но из-за мультиплексирования множества потоков возникает вопрос fairness: один поток может «съедать» больше полосы, чем положено.
QUIC предусматривает negotiation: клиент и сервер договариваются, на какой версии (v1, v2…) продолжить работу. В случае несовместимости и логирования всех таких событий для анализа, применяют VN-фреймы и fallback на HTTP/2.
Последнее, но не по важности — QoS и network slicing, особенно в 5G-сетях (что-то на богатом). Здесь для разметки QUIC-пакетов используются DSCP-пометки. Но downstream-оборудование может обрабатывать большие QUIC-пакеты по-разному. Поэтому тест в реальной сети обязателен.
Заключение
В ближайшей перспективе этот протокол станет стандартом не только для веб-страниц, но и для IoT-экосистем, облачных игр, видеоконференций, AR/VR и распределённых систем, требующих сверхнизкой задержки и устойчивости к нестабильным сетям.
HTTP/3 как часть стратегии эволюции стека:
Автоматизировать мониторинг ключевых метрик (PMTUD, congestion window, 0-RTT rejects).
Интегрировать поддержку QUIC на уровне ОС и железа (DPDK, eBPF, специализированные ускорители).
Настраивать adaptive congestion control и anti-replay для 0-RTT.
В перспективе протоколы будут развиваться с ориентацией на ещё большую автоматизацию управления потоками и интеллектуальные алгоритмы контроля качества связи, возможно, интегрируя машинное обучение для предсказания потерь и адаптивной настройки.
Технически, важным трендом станет более глубокая интеграция QUIC на уровне операционных систем и оборудования с появлением специализированных ускорителей, что уменьшит нагрузку на CPU и повысит энергоэффективность, особенно в мобильных и edge-устройствах.
Что думаете по этому поводу, когда ждать интеграцию с интернетом вещей? Делитесь мнением в комментариях.
© 2025 ООО «МТ ФИНАНС»
Комментарии (0)
warus
19.09.2025 14:31главное:
а) в http2-3 появилась возможность досить сервер одним запросом (раз в 2 месяца такую уязвимость в веб серверах нужно патчить),
б) не знаю почему но с вероятностью 30% реальное тестирование показывает что http2-3 медленее http.
И да балансировщики tcp давно новые не появлялись (не совсем, есть статьи и выкладки), не внедрялись с 2006 года, а сети уже сильно поменялись, надо что то делать.
Panzerschrek
19.09.2025 14:31А как обстоит дело с внедрением данного протокола? Поддерживается ли он уже в свежих браузерах? Много ли есть сайтов с его поддержкой?
vikarti
19.09.2025 14:31Поддерживается но в некоторых странах на интернет-каналах сидят неизвестные люди (провайдеры заявляют что это не они) которые ломаю этот протокол кроме как (видимо) своим аффилированным коммерческим структурам.
Решается как обычно средствами защита канала от постороннего вмешательства.
lostero
19.09.2025 14:31Как у австралопитека, но из будущего
Написал TCP сервер для HTTP/1.1, чтобы гонять вебсокеты с низкоуровневым контролем соединений в JS
Решил добавить 2 и 3 (стырить MIT код у h2o), но перед этим глянул на поддержку вебсокетов по ним в браузерах - сэкономил время
Сайтики смотреть - работает, а дальше там мрак
Mihrutkin
19.09.2025 14:31Именно quick трафик с легкостью блочит РКН.
CptAFK
19.09.2025 14:31Потому что, условно, для людей это проходит не заметно. Сайты просто начинают отдавать данные по http2.
А блочат, на сколько я помню, там все запросы зашифрованные или типа того. Суть в том, что нельзя подсмотреть в пакеты.
vanxant
19.09.2025 14:31Жил да был нормальный себе протокол HTTP 1.1. Очень лёгкий, очень простой, поднять простой и клиент и сервер может любой школьник на любом устройстве, где есть tcp.
Но тут в гугол понабирали по объявлению труЪ разрабов с синдромом NIH, и они начали творить ЭТО. Перевод текстового протокола в бинарный, мультиплексирование запросов, серверный пуш (он хоть где-то реально использовался?..)
И да, одна компания тупо может себе позволить творить любую дичь. И все остальные утрутся и примут к исполнению. Куда смотрит американский ФАС?
На выходе ожидаемо получили кривого тормозного шатающегося монстра. Если раньше браузеры открывали к серверу по 6 переиспользуемых соединений http/1.1 и вдруг какое-то из них подвисало, то чисто по статистике, скорее всего, это приходилось на какую-нибудь никому не нужную картинку. В случае с 1 соединением http/2 колом встаёт всё.
Когда гугловцев с цифрами и фактами отпинали все коллеги по цеху, включая даже Яндекс, естественно, гугл выкатил ещё более монструозного монстра на базе UDP. Но, поскольку это совершенно другой протокол (http означает tcp соединение на порт 80, а не udp), теперь у нас в браузерах есть списки правильных сайтов, которые точно-точно поддерживают http/3 и на которые надо ходить по udp. Состоит оно в-основном из записей вида google|amazon для разных TLD (доменов верхнего уровня). Идею взять там допустим топ-1000 сайтов по статистике и включить их удалось продавить только в ~2022.
Красоту и труЪ-кроваво-энтерпрайзность решения с захардкоженным списком доменов вы оценили, да?
Ну и разумеется, это решение добавляет тормозов тем, у кого udp на 443 порту заблокирован (т.е. у половины населения земли, тут и офисы и Китай с РФ и Ираном и пр.)
mirwide
19.09.2025 14:31Гугл можно понять. Недостатки http1.1 проявляются на большом количестве пользователей. Без keep-alive нагружается сервер на создание TCP и TLS соединения, клиент получает рандомные задержки на загрузку каждой мелкой картинки. keep-alive эту проблему решает, но на больших масштабах появляется другая - на FW трятится много ресурсов на поддержание сессий, на реверс прокси не хватает сокетов для исходящих соединений. Одно соединие вместо 6, значит в 6 раз меньше количество FW. Осталась последняя проблема, в http2 браузеру недоступно управление TCP, значит из-за потери пакетов мы можем словить задержки на которые ни как не можем повлиять. Решение простое, переносим функционал TCP на уровень приложения, теперь гугл управляет сетью на обоих концах провода - идеально.
Если вы не гугл, http3 вам не нужен.
vanxant
19.09.2025 14:31А можно пруфы про "много ресурсов на поддержание сессий" и прочее подобное?
mirwide
19.09.2025 14:31Datasheet любого FW.
vanxant
19.09.2025 14:31ну дайте ссылку на дадашит, где приведено сравнение затрат ресурсов на поддержание tcp и udp сессий (в случае NAT). Потому что с quic их таки приходится поддерживать, и именно поэтому оно заблокировано ТСПУ
mirwide
19.09.2025 14:31Для чего это сравнение? Эта строка, почему http2 выгоднее http1.1. Максимальное количество соединений и их максимальный рейт на открытие, это ключевая характеристика FW. Вместе с пропускной способностью. Делим количество активных пользователей гугла на лимит из datasheet и получаем сколько нужно стоек только под FW.
vanxant
19.09.2025 14:31Дата-центр это не только FW. И более того, всем кроме может гугла и других фаангов, срать на проблемы дата-центра. Всех интересует UX конечных пользователей. И вот он конкретно, до 10%, падает при переходе на http 2 и 3.
ruslan_sverchkov
19.09.2025 14:31И вот он конкретно, до 10%, падает при переходе на http 2 и 3.
ВК говорит что у них растет, думаете врут?
subzey
19.09.2025 14:31Что за язвительная ненависть?
Http/2 действительно лучше http/1. Не 6 запросов в параллель, а 100..128. Keepalive дольше, значительно меньше шансы того, что новый запрос потребует установки соединения заново. Приоритеты в конце концов, когда можно поставить один ответ на паузу и послать что-то более важное вперёд.Http/3 решает и проблемы с "колом встаёт всё". Списки доменов уже не нужны — есть DNS записи HTTPS.
Проблемы с DPI и блокировкой — это гугл виноват? Или может быть кто-то другой?
vanxant
19.09.2025 14:31Http/2 действительно лучше http/1
Только если ходить из одной виртуалки в другую на том же хосте. Как только начинаются потери пакетов и ретрейны, всё становится очень плохо.
Более того, даже без ретрейнов, но на линках с большой latency http/2 показывает себя сильно хуже http/1.1. Это из особенностей tcp идёт, но вот так.
Гуглите, крупнейшие конторы реально размазали http/2 конкретно на своём живом трафике. После перехода на моднейший http/2 они получили "ускорение" (с точки зрения их клиентов) в размере 0.9...0.98. Т.е. тормоза от 2% до 10%.
amakhrov
19.09.2025 14:31Как только начинаются потери пакетов и ретрейны, всё становится очень плохо.
В каких сценариях использования? А HTTP1 при потере пакетов хорошо себя чувствует?
Гуглите, крупнейшие конторы реально размазали http/2 конкретно на своём живом трафике. После перехода на моднейший http/2 ...Погуглил и не нашел. У вас есть ссылка? Или хотя бы название конторы, которая такие данные обнародовала, по каким ключевым словам гуглить?
subzey
19.09.2025 14:31Я понимаю, к чему вы, если соединений 6, то дроп одного пакета заафектит только 1 коннекцию из 6.
Но вместе с h2 поменялась и манера изготовления сайтов. Мы больше не клеим спрайты, не склеиваем среднего размера джаваскрипты в джамбо-бандлы весом по мегабайту, из-за чего они прилетают на клиент и исполняются быстрее. Мы можем делать запрос двух эндпойнтов в параллель с практически нулевым оверхердом, что дало лучшую попадаемость в кэш.Да, может быть, дропы стали аффектить коннекцию больше, но h2 открыл нам возможности и техники чтобы в оптимистичном случае всё работало быстрее.
Само собой, если сайт оптимизированный под h1 гонять через h2, могут быть просадки. И наоборот. Но в целом и общем, я бы сказал, что h2 скорее добро, чем зло
vanxant
19.09.2025 14:31Проблемы с DPI и блокировкой — это гугл виноват?
Да, именно, из-за предельно кривого дизайна протокола QUIC.
Гугл хотел стать царём горы и единственным, кто шпионит за юзерами. Но как бы у властей более других, чем США, держав на этот счёт были другие планы.
Я не оправдываю ни тех ни других, но делать настолько кривой протокол стандартом интернета из-за своих шкурных интересов это как-то за гранью.
Dont be evil примерно тогда же закопали.
mvv-rus
19.09.2025 14:31Жил да был нормальный себе протокол HTTP 1.1. Очень лёгкий, очень простой, поднять простой и клиент и сервер может любой школьник на любом устройстве, где есть tcp.
Но тут в гугол понабирали по объявлению труЪ разрабов с синдромом NIH, и они начали творить ЭТО. Перевод текстового протокола в бинарный, мультиплексирование запросов, серверный пуш (он хоть где-то реально использовался?..)
IMHO дело здесь не в субъективных причинах, а в объективных: не в NIH-синдроме разработчиков и менеджеров, а в специфических потребностей Гугля и других рекламодателей, которым исходный протокол HTTP соответствует, мягко говоря, не идеально.
Исходно HTTP был задуман как протокол передачи документов, более-менее статичных - сначала текстовых, потом - мультимедийных, как это тогда, лет 30 назад, называли. Потому и была выбрана схема "запрос-ответ" - она для этого более чем годилась. Правда, для мультимедийных документов напрашивается пакетная передача, которая AFAIK по каким-то причинам не взлетела (хотя причина непонятна: есть же под это дело стандрт - MIME, в котором можно было бы передавать документ целиком, если чо, электронные письма так с успехом передаются): при пакетной передаче не пришлось бы устанавливать с сервером более одного соединения на документ.
Но в нынешнем интернете господствуют не страницы-документы, а страницы-приложения - динамические, часто интерактивные и т.д. И на то есть причины вполне экономические: расходы на содержание сайтов и прочу. днеятельность в Сети возмещаются, прежде всего, распространением рекламы (и Гугль тут - один из крупнейших), а рекламе, чтобы она работала, требуется быть приложением - динамическим - выглядит привлекательнее, - интерактивным - а как иначе собрать данные для профиля просматривающего и его реакциях - и т.д.
Исходный же HTTP для выполнения этой функции предназначен не был, а локальные дополнения - это все же коcтыли. Вот Гугль и усовершенствует протокол в нужную ему сторону - мультиплексирование, снижение задержек и т.д. Вся эта деятельность - она, с точки зрения Гугля, вполне целесообразна: служит лучшему, более эффективному доступу к аудитории, которую Гугль продает рекламодателям.
PS Кстати, засилие HTTPS даже там, где никакая безопасность объективно не нужна - типа, на новостных и прочих сайтах с общедоступным содержимым - оно IMHO тоже результат потребности в распространении рекламы как основном способе возврата затрат на деятельность в интернете: чтобы провайдеры по пути не подменяли рекламу от источника-сайта на свою.
PPS Всё это - естественно, мои личные выводы, а не результат каких-то там научных исследований.
subzey
19.09.2025 14:31HTTPS … где никакая безопасность объективно не нужна … результат потребности в распространении рекламы
Не чтобы спорить, а просто пооффтопить:
Моя любимая шапочка из фольги в том, что фразу "Internet is for porn" следует читать буквально.Когда всё было по HTTP, процветала "спутниковая рыбалка", спутник работает как радио, рассылая ответ всем. Народ вычленял из этого "радио" чужие ответы, прежде всего видосы. Ну и вы понимаете, какой характер носили 60+% видосов.
Чтобы прекратить рассылать платный контент в открытом виде, нужно было как-то убедить интернет перейти на шифрование трафика.Флеш не работает в браузере на айфоне? Нужно дать людям возможность смотреть видео из браузера! Потому что приложения… они наверное не будут ставить, слишком палевно.
Туда же и и крипта. За крипту можно анонимно оплатить всякие видосы. Хорошая вещь, оставляем.
А вот NFT для порно-индустрии бесполезен, вот он и отмер.
mvv-rus
19.09.2025 14:31Чтобы прекратить рассылать платный контент в открытом виде, нужно было как-то убедить интернет перейти на шифрование трафика.
Про платное содержимое я не пишу - экономика современного интернета основана не на нем, а на бесплатном сыре с общедоступных сайтов.
А платное - там защита каналов передачи, пердаваемое по которым содержимое можно перехватить, обоснована. И применялась она, кстати, ещё до этих ваших интернетов: в 90-00 платные каналы спутникового ТВ часто скремблировались 0 это такое примитивное шифрование, снимаемое на приемой стороне помощью приставок от вещателе. Ну, и были умельцы, которые делали свои приставки - самим попользжоваться, друзьям подарить, продать недорого... Но это - другое, понимать надо.
PS Лично мне кажется, что вы преувеличиваете вес порноиндустрии в содержимом современного интернета. Но данных исследований, чтобы поспорить, у меня нет. И вообще, это тут офтопик.
subzey
19.09.2025 14:31Поэтому и говорю, шапочка из фольги. Это оффтопик и есть, сорри, если не в тему
JerryI
19.09.2025 14:31А разве пуш уведомления поллятся через HTTP?
Ну ладно, допустим даже так. Взять какое-нибудь сложное веб-приложение, там ведь все будет подгружаться по WS (вебсокеты). Не надо постоянно грузить ничего GET запросами каждую остановку трамвая. Оверхеда там нуль, это почти голый TCP.
Впечатление, что пытаются решить проблему которая в целом есть, но цена решения перечеркивает выгоду - надо все сломать и переписать с нуля. Поправьте, если я не прав.
Я бы сказал спасибо за просто бинарный стандарт HTTP (сырые байты вместо человекочиатемых штук, с разметкой).
vvzvlad
19.09.2025 14:31Ассеты по WS не подгружаются, их проще с CDN качать. Или с сервера статики, если до CDN не доросли. WS дороговато обходится (надо соединение держать), чтобы через нее таскать картинки-аудио-видео, которые грузятся один раз.
tairbakiev
19.09.2025 14:31А зачем понадобился quic, почему не допили SCTP, который при желании не только поверх ip, но и поверх UPD пустить можно. И соединения с разными путями на разные ip он поддерживает. Так какой у него был фатальный неустранимый недостаток, что пришлось создавать QUIC?
blind_oracle
19.09.2025 14:31SCTP работает в общем поверх IP, через UDP это его туннелировать надо. А поверх IP новый протокол - явно куча файрволлов и прочих натов его не пропустят и как трекать не знают.
Ну а в QUIC сразу встроен TLS, для SCTP его пришлось бы как в TCP сверху класть.
graphican
19.09.2025 14:31Скорее всего, вы подумали о частой смене сетей
Не понятно, что тут имелось ввиду, но если речь о базовых станциях, то TCP подключение переноситься механизмом handover базовыми станциями автоматически с сохранением ip адреса
В классическом TCP+TLS, сначала устанавливается соединение TCP (3-RTT), а затем TLS (1-RTT)
TCP Fast open экономит один раунд трип, но при этом открывается возможность атаки подменой IP адресов - cloud flare отказались от этой оптимизации. Но UPD изначально открыт для UDP flood / amplification/reflection атак и даже не ботнетом, но подменой адреса отправителя, чтобы не отфильтровать по ip. С одного хоста задидосить можно (в «плохих» сетях МАС не сверяют)
Про NAT
Запись в таблице маршрутизации для TCP раз в 10 дольше держится - keep alive реже нужен чем пинги в UDP делать каждые 20 секунд
Роутеры традиционно приоритет TCP трафику отдавали, чтобы торренты не тормозили сайты
Корпоративные файрволы часто UDP блокируют
На iOS куча ограничений на UDP - не дают в демонах или в фоне (до выгрузки приложения), но для quic вроде послабления сделали
MetallDoctor
19.09.2025 14:31UDP
Ведь люди, делавшие TCP такие недалёкие и примитивные бездари, напридумывали каких-то состоянии, сложное установление соединения за целых 3 пакета и прочее... Так? Или это появилось чтобы решить конкретные вопросы? Как бы, не имея трёх пакетов до EST, поймёшь, что соединение есть? А если пакеты по той или иной причине уходят "в молоко"? Ты сможешь только бомбить повторением запроса и никак иначе.
Или вот клиент попросил картинку. Супер. Взяли изображение, разделили его, скажем, на 15 пакетов и отправили чистые датаграммы! Круто и быстро! Один из пакетов не дошёл, что делать? А ничего мы же об этом даже не узнаем! Вот в TCP в конце сервер бездарно спросил бы "ты там всё получил", на что клиент бездарно ответил "нет, не хватает пакета 7" и сервер переотправил бы его. Но это же скучно и уныло! Потому путь будет как будет... Ну или изобретём контроль получения на UDP и реализуем TCPoverUDP.
TCP + TLS отнимают у нас целых 0,2с...
Это, конечно, реально много. Вот только есть важное НО: оба участника в это время вообще-то делом заняты! TLS это прекрасный пример компромисса между скоростью и безопасностью. Коротко: он не берёт и не шифрует в лоб траффик открытыми ключами ассиметричным протоколом. Он тратит время на хендшейк, в процессе которого оба участника проверяют друг-друга и согласуют ключ для того, чтобы в рамках сеанса использовать быстрое симметричное шифрование. Если хотите сделать что-то настолько же оптимальное -- то придётся обменяться всеми теми же пакетами. Вам придётся договориться о возможном шифровании, вам придётся проверить вторую сторону (базово -- клиенту придётся проверить сервер), вам придётся обменяться ключами и вам придётся сообщить, что рукопожатие принято.
Игры и стриминг
И для игр и для стриминга от самого палеозоя были варианты использования специальных протоколов, вот как раз там использование UDP было более чем оправдано. То, что сейчас всё это пытаются стандартизировать и прибить в HTTP это как минимум странно! А ведь его пытаются сделать протоколом-для-всего, спаять так, чтобы связка IP-HTTP была единственной в интернете зачем-то.
И для этого HTTP превращают в швейцарский нож... Вот только никто в здравом уме и твёрдой памяти не будет реально пользоваться швейцарским ножом, если есть альтернатива.
Тут немного моей боли, извините за скомканность. Вообще последние десятилетия значительная часть развития IT словно проходит под лозунгов "зумеры и вайбкодеры -- объединяйтесь, чтобы снизить сложность того, что сделали инженеры!" А в итоге получается вейланд, который устроен сложнее и работает хуже, зато содержит свистоперделку, нужную 0,4% пользователей. Для меня, если что, один из первых (хронологически) примеров -- то, что называется
noSQL, подход, который с моей колокольни чаще всего выглядит как "таблички и нормальные формы это сложно и скучно, давайте сваливать всё в бессистемную кучу и вытаскивать из неё что получится!" (Ну да, это не всегда так и иногда даже оправданно, я не говорю, что подход вообще не имеет права на жизнь... Просто большинство примеров, которые я видел именно такие.)
isumix
19.09.2025 14:31Интересно, РКН не станет ли сложнее вставлять палки в колеса интернету (обнаружение ВПН) с внедрением HTTP/3, а также не станет ли это катализатором его (HTTP/3) запрета?
vanxant
19.09.2025 14:31вы всё проспали, http/3 в рф разрешён очень небольшому белому списку сайтов типа вк, остальным просто режут и всё тут
ezguru
про другие протоколы обычно не вылазят ошибки