Hacker News Digest

В статье рассматривается применение протокола QUIC для решения проблем обхода NAT в P2P-сетях. Авторы отмечают, что за годы было стандартизировано множество протоколов (STUN, ICE, TURN), но процесс остается сложным из-за разнообразия реализаций NAT, которые переписывают IP-адреса пакетов и действуют как файрволы. Основная проблема P2P-сетей — соединение двух узлов, находящихся за разными NAT, независимо от их типа.

Традиционные решения включают использование STUN для обнаружения публичных IP-адресов, ICE для координации пробивания дыр в файрволах и TURN как запасной вариант с ретрансляцией трафика. Авторы предлагают, что QUIC может предоставить комплексное решение для обхода NAT, объединяя все эти функции в одном протоколе и упрощая P2P-сетевое взаимодействие. Это потенциально может заменить несколько отдельных протоколов единой, более эффективной реализацией.

• Обсуждение вращается вокруг проблемы NAT и hole punching при попытке установить прямое P2P соединение, включая то, что некоторые NAT ведут себя непредсказуемо и не позволяют hole punching.
• QUIC и WebTransport обсуждаются как потенциальные решения, но оба стандарта ещё не реализованы в браузерах и их поддержка ограничена.
• Обсуждается, что для P2P соединений не требуется централизованный сервер, но вопрос в том, что сервер может всё ещё потребоваться для ретрансляции трафика в случае, если оба клиента находятся за NAT.
• Поднимается вопрос о том, что TLS сертификаты могут быть самоподписанными и не обязаны быть выданы удостоверяющим центром, что может быть использовано для P2P соединений.
• Участники обсуждают, что хотя WebTransport и был предложен как стандарт для web-платформ, он всё ещё не реализован в браузерах и его будущее неясно.

HTTP/3 — это новая версия протокола HTTP, работающая поверх QUIC (Quick UDP Internet Connections) вместо традиционного TCP. Основное преимущество — решение проблемы "head of line blocking", когда потеря одного пакета блокирует всю передачу данных. HTTP/3 использует UDP, что позволяет параллельно обрабатывать пакеты без ожидания восстановления связи. Протокол включает встроенную безопасность с TLS 1.3 и поддерживает 0-RTT handshakes для снижения задержки при повторных подключениях.

Книга подробно разбирает эволюцию протокола: от HTTP/2 с его ограничениями TCP до современных возможностей QUIC. HTTP/3 сохраняет такие функции HTTP/2, как мультиплексирование запросов и приоритизацию, но с улучшенной производительностью. Особое внимание уделено техническим деталям: работа с потоками, сравнение с HTTP/2, а также критика и перспективы развития. Документ доступен на нескольких языках и представляет собой исчерпывающее руководство для разработчиков, интересующихся современными веб-протоколами.

• Обсуждение охватывает отсутствие обновлений документации HTTP/3, проблемы с потерей пакетов в HTTP/2, и то, что HTTP/3 уже поддерживается большинством браузеров и сайтов, но документация и инструменты отстают.
• Участники обсуждают, что HTTP/3 в основном использует UDP, что вызывает споры о безопасности и приватности, а также то, что TCP может быть выключен в будущем.
• Также обсуждается, что HTTP/3 уже активно используется, но не всегда очевидно, что это именно он, так как внешне это может быть незаметно.
• Участники также отмечают, что документация и инструменты для HTTP/3 развиты недостаточно, и что будущее HTTP/4 неясно.
• В конце обсуждение сдвигается к тому, что HTTP/3 уже здесь и сейчас, и мы должны начать его использовать и развивать экосистему вокруг него.

Разработчики создали Wireguard-FPGA — полностью аппаратную реализацию VPN Wireguard на основе ПЛИС Artix7. Проект с открытым исходным кодом, включая весь RTL, встраиваемое ПО, битстримы и инструменты сборки, что позволяет любому провести полный аудит безопасности. Идея в том, что аппаратная реализация обеспечивает wire-speed производительность даже на недорогих FPGA, а открытость гарантирует отсутствие бэкдоров. Вместо традиционных программных реализаций, которые могут быть уязвимы для атак по сторонним каналам, этот подход обеспечивает физическую изоляцию и эффективность. Проект приглашает к сотрудничеству и аудиту.

• Проект представляет собой реализацию WireGuard на FPGA, что позволяет достичь высокой производительности и низкого энергопотребления, но вызывает вопросы о целесообразности, поскольку обычное ПО может справляться с подобной задачей.
• Обсуждение затрагивает вопрос о том, почему не используется QUIC вместо WireGuard, несмотря на то, что он может предложить схожие возможности и при этом не требует специализированного оборудования.
• Участники обсуждения также поднимают вопрос о том, почему не используется уже готовое решение, такое как OpenVPN или IPSec, которые могли бы быть более подходящими для корпоративного использования.
• Некоторые участники высказывают мнение, что проект является "академическим грантваром", поскольку он не решает практическую задачу, а вместо этого служит демонстрацией возможностей FPGA.
• В то же время, другие участники подчеркивают, что это может быть полезно для обучения и исследований, а также может быть полезно в ситуациях, где требуется высокая безопасность и производительность.
• Наконец, обсуждение также затрагивает вопрос о том, почему не используется уже готовое решение, такое как OpenVPN или IPSec, которые могли бы быть более подходящими для корпоративного использования.

SSH3 — это новая реализация SSH, построенная поверх HTTP/3 и QUIC вместо традиционного TCP. Она обещает значительно более низкую задержку установки соединения, многопоточность и встроенную поддержку мультиплексирования. Это позволяет ускорить интерактивные сессии, особенно в условиях нестабильных сетей.

Проект также включает улучшенные возможности, такие как передача файлов через HTTP и использование современных криптографических алгоритмов. Уже есть черновик IETF и техническая статья на arXiv, демонстрирующая производительность и совместимость. SSH3 может стать практичной альтернативой для DevOps и удалённого управления.

• Скептицизм по поводу заявлений о скорости: некоторые участники сомневаются в значительном преимуществе SSH3, отмечая, что основная задержка часто связана не с установкой соединения, а с настройкой сессии (PAM и т.д.).
• Критика имени "SSH3" и интеграции в HTTP: многие считают название неудачным и выражают сожаление по поводу поглощения прикладных протоколов HTTP, что увеличивает сложность и потенциальные риски безопасности.
• Обеспокоенность безопасностью и аудируемостью: новая, не испытанная в боях реализация вызывает опасения; участники подчеркивают необходимость тщательного аудита перед использованием в production.
• Вопросы к практической полезности и статусу проекта: обсуждается отсутствие commits за последний год, целесообразность поддержки OAuth для входа на сервер и необходимость таких функций, как миграция соединений.
• Технические аспекты и потенциальные преимущества: отмечается возможность решения проблемы head-of-line blocking за счёт мультиплексирования в QUIC/HTTP3, а также преимущества скрытия сервера за HTTP-прокси.

Firefox переписывает свой стек UDP для QUIC на Rust, чтобы использовать современные системные вызовы и повысить производительность. Около 20% HTTP-трафика браузера уже идёт через HTTP/3 поверх QUIC/UDP, а старый код на NSPR не поддерживает многопакетные операции вроде sendmmsg или аппаратное ускорение сегментации (GSO/GRO).

Новый движок построен на основе библиотеки quinn-udp и показывает впечатляющие результаты: в CPU-нагруженных сценариях пропускная способность выросла с менее 1 Гбит/с до 4 Гбит/с. Основная сложность заключалась в поддержке старых версий ОС, включая Android 5. Проект также усиливает безопасность благодаря использованию memory-safe языка и тесной интеграции с существующей Rust-реализацией QUIC во Firefox.

• Увеличение пропускной способности UDP до 4 Гбит/с и снижение нагрузки на CPU благодаря оптимизациям в библиотеке quinn-udp
• Критика скорости в 4 Гбит/с как недостаточной для высокоскоростных сетей и обсуждение ограничений системных вызовов и шифрования
• Вопросы о работе механизмов GSO/GRO для UDP и обработки пакетов, приходящих не по порядку
• Обсуждение поддержки проектов с открытым исходным кодом, в частности, вклад Mozilla в Quinn кодом, но не финансированием
• Дебаты о целесообразности использования самоподписанных сертификатов в HTTP/3 для LAN и соображения безопасности

Краткий русский пересказ утечки Geedge & MESA

• 11 сентября 2025 года утекло ≈600 ГБ внутренних данных «Великого китайского файрвола» (GFW): исходники, логи, переписка.
• Источник — компания Geedge Networks (главный учёный — «отец GFW» Фан Бинсин) и лаборатория MESA при Институте информатики АН Китая.
• Документы показывают: разработка и эксплуатация систем фильтрации для Синьцзяна, Цзянсу, Фуцзяня; экспорт цензуры в Мьянму, Пакистан, Эфиопию, Казахстан и другие страны «Пояса и пути».
• Архивы: 500 ГБ RPM-репозиторий, 35 ГБ Git MESA, 15 ГБ Jira Geedge, десятки документов Word о тендерах, графиках, отчётах.
• Зеркала: BitTorrent и HTTPS на EnlaceHacktivista.
• Рекомендация: разбирать только в изолированной виртуалке — возможны следящие модули и вредоносное ПО.

• Компания Geedge с 2018 г. продаёт авторитарным режимам (Казахстан, Пакистан, Беларусь, Россия) «Great-Firewall-ин-а-box» под маркой Tiangou Secure Gateway: DPI, MITM, SNI-сканирование, «замедление» SSH/VPN, блокировка QUIC и облачных IP.
• Участники считают, что технологии цензуры уже массово экспортируются западными вендорами (Cisco, Nokia, Siemens, Blue Coat) и внедряются в корпоративных и государственных сетях; «западный файрвол» — вопрос времени и удобного повода.
• Обход всё ещё возможен (v2ray, Outline/Shadowsocks, ротация серверов, маскировка трафика), но GFW быстро учится: типичный Outline-блок наступает через 3 дня наблюдений.
• Мнения морализаторов разделились: кто-то видит в разработчиках «веру во всё ради общего блага», кто-то — «провалившихся людей»; упоминается, что в Китае индивидуализм воспринимается как вредный «западный» порок.
• Лейтмотив: «как только власть попробовала цензуру, бутылку уже не закупорить» — примеры Непала, Беларуси, России; в то же время всплывают новые исследования и инструменты как для усиления, так и для обхода блокировок.

Cloudflare запустил первый MoQ-CDN
Теперь можно тестировать Media over QUIC на их глобальной сети — это официальный продукт. MoQ — новый стандарт для live-медиа, призванный заменить WebRTC, HLS/DASH, RTMP и SRT.

Что уже работает

• Бесплатный технический превью: relay.cloudflare.mediaoverquic.com
• Поддерживаются клиенты draft-07: moq-rs, imquic, moxygen и др.
• Публикация/просмотр прямо в браузере через Web-компоненты <hang-publish> и <hang-watch>:

<hang-publish url="https://relay.cloudflare.mediaoverquic.com"
              name="unique-name-abc123" audio video controls captions>
  <video muted autoplay></video>
</hang-publish>

• Скрытые субтитры генерируются в браузере (Whisper + WebGPU) и передаются по MoQ.
• Есть Rust-библиотека: импорт MP4, ffmpeg, gstreamer.

Что пока не работает

• Нет аутентификации — используйте случайные имена стримов.
• Нет ANNOUNCE → конференции не стартуют.
• Safari не поддерживает WebTransport (в планах).
• Код не оптимизирован, баги гарантированы.

• Пользователи хвалят скорость и плавность демо MoQ, но жалуются на чёрные полосы на мобильных и проблемы с полноэкранным режимом.
• Вопросы к разработчикам: поддержка multicast, graceful degradation, fallback для Safari, балансировка нагрузки и сравнение с WebRTC после установки соединения.
• Разработчики объясняют: multicast не нужен — CDN решает это на L7; MoQ строится поверх WebTransport/WebCodecs и может работать с MSE для совместимости.
• QUIC/WebTransport пока работает в основном в Chrome; Firefox страдает от багов WebTransport и HTTP/3.
• MoQ позиционируется как более гибкая замена WebRTC для лайв-стриминга и может быть использована и для других данных, включая игровой трафик.

TCP: увеличить initcwnd снова

Google в 2011 г. подняли начальное окно TCP (initcwnd) с 1 до 10 пакетов; RFC 6928 сделало это стандартом. Сегодня, при среднем размере страницы ~2 МБ и RTT 30–100 мс, 10 пакетов (~14 КБ) всё ещё тормозит старт.

Почему расти

• 75 % HTTP-ответов ≤ 32 КБ; 10 пакетов передают лишь 40 %.
• У Google, Meta, Akamai уже 32–64 пакета без потерь.
• Современные сети: 100 Гбит, AQM, ECN, BBR — потери редки.

Риски

• Пакет потеряют лишь 0,01 % сессий при initcwnd=30.
• Re-buffering в YouTube снизился на 3 % при 30 пакетах.

Вывод
initcwnd=30–50 пакетов безопасно и ускоряет web на 5–15 %. Пора обновить RFC.

• Участники считают, что статья поверхностна и ошибочна в выводах о TCP initcwnd и BBR.
• QUIC/HTTP-3 всё равно использует алгоритмы управления перегрузкой (CUBIC, BBR); «окна нет» — миф.
• L4S позволяет получать сигналы о перегрузке без потери пакетов, помогая молодым соединениям.
• Увеличение initcwnd может лишь временно скрыть «раздутый» фронтенд-код, пока бизнес не пострадает.
• BBR и другие алгоритмы плохо переносят высокую джиттерность RTT в беспроводных сетях.
• Bufferbloat всё ещё актуален (особенно на мобильных и Wi-Fi), несмотря на улучшения в кабеле/волокне.