Hacker News Digest

Tailscale ускоряется за счёт снижения памяти и улучшения обработки пакетов. На Linux и Android теперь не копируются маленькие пакеты (например, 1 KiB) в отдельные 64 KiB буферы — вместо этого они остаются в едином буфере, где их границы помечаются, что экономит память и ускоряет обработку на ~5%. Одновременно сокращены длины очередей пакетов, что уменьшает задержки и освобождает память без потери устойчивости к всплескам трафика. Эти изменения уже частично реализованы и войдут в стабильный релиз v1.104 клиента.

Параллельно разрабатывается мульти-очередная технология для повышения пропускной способности в сценариях с подсетями, коннекторами приложений и выходными узлами — её выпуск запланирован после v1.104. Также тестируется кэширование netmap как флаг функции, которое станет стандартным в v1.104 для десктопов и позже для мобильных клиентов. Чтобы пользователи могли объективно оценивать производительность, Tailscale разрабатывает собственный набор инструментов для мониторинга и тестирования, который будет понимать специфику его сети: distinguish между DERP и прямыми соединениями, оценивать пользу пир-релеев и отслеживать динамику маршрутов — чего не умеют общие утилиты из-за привязки к точкам, жёсткости workflows и отсутствия поддержки QUIC/HTTP/3. Пользователей приглашают повлиять на развитие этого инструментария через опрос.

Tailscale проще в настройке, чем raw WireGuard: автоматизирует NAT-трансверс, DNS и управление ключами, что делает его удобным для не-технических пользователей и динамических сред (CI-джобы). Пользователи отмечают, что он позволяет подключаться к серверам без открытия портов, упрощая безопасный доступ к внутренним сервисам. Однако Tailscale критикуют за производительность на высоких нагрузках и высокое потребление батареи на iOS, что ограничивает его практическое применение. На Windows и macOS скорость не превышает 1 Гбит/с, на Linux — до 10 Гбит/с даже в синтетических тестах, что делает его неконкурентоспособным для высокопроизводительных сценариев. Потребление батареи на iOS вынуждает пользователей вручную управлять подключением, нивелируя преимущества автоматизации. Спор о скорости: некоторые утверждают, что raw WireGuard быстрее и стабильнее, особенно с динамическим DNS; другие отмечают, что Tailscale решает проблемы с забыванием конфигурации и сложностью поддержки после простоя. Также обсуждается отсутствие аппаратного ускорения криптографии в Tailscale, что ограничивает масштабируемость до сотен Гбит/с и может потребовать смены протокола (например, на IPsec с PQ). Однако ChaCha20-Poly1305 в WireGuard уже быстр и может быть оптимизирован через SIMD, что снижает необходимость в аппаратном ускорении. Дополнительные ограничения: Tailscale не поддерживает мультиузловые прокси, требуя отдельных контейнеров для устройств без прямой интеграции; не работает на микроконтроллерах, хотя это было бы идеально для IoT; не позволяет отключать принудительное исключение Android-приложений из VPN без вмешательства разработчика, что противоречит пользовательскому контролю. Предлагается добавить гибкость в выбор маршрутов через DERP (a→b→c) для снижения задержек при невозможности прямого соединения. На Linux и Android оптимизации (устранение копирования малых пакетов, сокращение очередей) дают ~5% прироста производительности, но не применимы на macOS и Windows из-за отсутствия ядерных аналогов. Tailscale уже давно отошёл от спецификации WireGuard, внося собственные улучшения, но создавая разрыв в ожиданиях совместимости. Использование батарейных устройств как exit-узлов неэффективно и противоречит рекомендациям по энергосбережению.

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 и соображения безопасности