Производительность потоковой передачи важна не только для видеоплееров. Программные артефакты, веса моделей, резервные копии, аудиобиблиотеки и большие экспорты API зависят от одних и тех же основ: быстро перемещать байты, сохранять точный полезный пакет, учитывать обратное давление и корректно прекращать работу при отключении клиента.
Webship рассматривает эти требования как одну транспортную задачу через HTTP/1.1, HTTP/2, HTTP/3, прямую доставку файлов, обратное проксирование и WebTransport. Быстрый путь полезен только тогда, когда он сохраняет фрейминг, отмену, трейлеры, проверку безопасности и ограниченную память.
Измеренная пропускная способность потоковой передачи 100 МБ
Пропускная способность Webship 1.3.1 на Debian была измерена по медианному объему полезной нагрузки с использованием фиксированного устройства на 100 МБ. Каждый принятый образец требовал точно 99 943 778-байтовое тело ответа и отсутствия ошибок клиента, протокола, прокси, крупных аппаратных сбоев и потери пакетов HTTP/3.
| Режим Webship | HTTP/1.1 TLS | HTTP/2 TLS | HTTP/3 TLS | | --- | ---: | ---: | ---: | | Прямая передача файлов | 4,194.8 МиБ/с | 3,574.3 МиБ/с | 2,096.9 МиБ/с | | Обратный прокси с завершением TLS | 3,585.7 МиБ/с | 3,355.0 МиБ/с | 1,938.6 МиБ/с | | Обратный прокси с TLS pass-through | 2,783.2 МиБ/с | 2,135.0 МиБ/с | 1,748.5 МиБ/с |
В записанном сравнении Webship показал наивысшие медианные показатели прямого и TLS-завершённого соединения для каждого измеренного протокола. Полная матрица включает Nginx, Lighttpd, Caddy, HAProxy, Envoy, Pingora и Bun на [странице с бенчмарками](/benchmarks).
Эти числа измеряют ёмкость на эталонном хосте. Они не являются обещанием для произвольного интернет-маршрута. Задержка хранения, пропускная способность сети, время отклика, потеря пакетов, политика TLS, параллельность и поведение источника по-прежнему определяют реальную скорость доставки.
Один бинарный файл, три транспортные стратегии
Большой ответ не выигрывает от той же политики, что и небольшой HTML-документ. Webship сохраняет обычный путь запроса консервативным и продвигает только проверенный массовый ответ.
HTTP/1.1: меньше переходов по файлу
В Linux Webship сохраняет заголовок ответа и полезную нагрузку файла внутри одного интервала TCP cork с наилучшими усилиями. Как только большой TLS-ответ подходит для массового пути, прямая передача файла может перейти от записей Rustls к проверенному одностороннему ядру TLS и использовать sendfile без копирования полезной нагрузки через буфер приложения.
Соединение по-прежнему начинается в TLS на уровне пользовательского пространства. Небольшие ответы остаются там. Webship запрашивает переход на kTLS только после того, как тело ответа размером не менее 1 МиБ докажет, что соединение передает большие объемы данных.
HTTP/2: пакетная обработка без нарушения управления потоком
Мультиплексирование HTTP/2 делает неконтролируемое буферизование дорогим. Webship группирует записи, при этом соблюдая ограничения потока и управления потоком соединения. Для потоковой передачи с высокой конкуренцией буфер записи TLS размером 128 КБ может содержать два фрейма DATA по 64 КБ, при этом бюджет отправки соединения остается явным и ограниченным.
Готовое каркасное тело верхнего уровня можно предварительно получить без обхода гиперфрейминга, трейлеров, отмены, проверки или обратного давления. Это уменьшает количество лишних обходов планировщика, при этом сохраняя целостность протокольного контракта.
HTTP/3: управление скоростью QUIC вместо kTLS
HTTP/3 никогда не использует путь TCP kTLS. Webship применяет управление потоками QUIC с учетом транспорта, ограниченную пакетизацию дейтаграмм, DPLPMTUD и микропакетирование с таймерами на каждый реактор. Большие ответы HTTP/3 и принятые сессии WebTransport могут выбирать BBR без изменения политики CUBIC, используемой для обычного трафика.
Фокусированная квалификация стабильности HTTP/3 использовала семь принятых образцов. Потоковая передача с завершением TLS обеспечила медиану 1,938.6 МиБ/с с коэффициентом вариации 2,12%. Прямой TLS показал 1,748.5 МиБ/с с коэффициентом вариации 1,65%. Обе серии не имели ошибок целостности тела, ошибок клиента, протокола и потери пакетов.
Прямая доставка или обратный прокси?
Используйте прямую доставку, когда Webship владеет развернутым деревом файлов. Это устраняет промежуточный этап и обеспечивает наиболее эффективный путь для статических файлов.
Минимальный многопротокольный сайт выглядит так:
listen = "0.0.0.0:443"
workers = 8
root = "/srv/media"
[[sites]]
domain = "media.example.com"
root = "/srv/media"
[sites.protocols]
h1 = true
h2 = true
h3 = true
[sites.tls]
cert = "/etc/webship/media-cert.pem"
key = "/etc/webship/media-key.pem"Используйте завершение TLS через обратный прокси, когда Webship должен маршрутизировать по пути, применять проверки WAF или API Shield, устанавливать ограничения на тело, добавлять заголовки пересылки или отслеживать HTTP-поля:
[reverse_proxy]
enabled = true
tls_termination = true
[reverse_proxy.protocols]
h1 = true
h2 = true
h3 = true
[reverse_proxy.tls]
cert = "/etc/webship/proxy-cert.pem"
key = "/etc/webship/proxy-key.pem"
[[reverse_proxy.routes]]
domain = "media.example.com"
path_prefix = "/"
upstreams = ["10.0.0.20:8080"]Установите tls_termination = false, когда исходная система должна сохранять открытые данные приложения и активные ключи сессии. Прозрачная передача не может проверять зашифрованные поля HTTP. Поэтому передача через TCP маршрутизируется по SNI в ClientHello, тогда как передача через HTTP/3 требует одного общего UDP-источника.
Явно настраивать массовую потоковую передачу
Для высококонкурентного потокового передачи данных по HTTP/2 TLS Webship документирует эти настройки, привязанные к процессу:
[runtime.settings]
h2_tls_write_buffer_bytes = "131072"
proxy_h2_tls_max_send_buffer_bytes = "131072"
proxy_h2_tls_connection_send_buffer_bytes = "33554432"Приведённый выше бюджет соединения предоставляет 128 КиБ кредита для 256 активных потоков. Рассматривайте это как решение о ёмкости, а не как универсальный стандарт. Измеряйте использование памяти, задержку и пропускную способность при ожидаемой конкуренции перед её увеличением.
В Linux загрузите модули ядра TLS и BBR и разрешите учетной записи службы Webship выбирать BBR. Webship завершает работу до привязки, если требуемая возможность ядра недоступна, поэтому развертывание не может беззвучно выбрать оптимизированный путь, работая без нее. Другие операционные системы сохраняют переносимые пути Rustls и управления перегрузкой, документированные для их платформы.
WebTransport — это другой формат потоковой передачи
WebTransport сочетает надежные потоки и ненадежные датаграммы через безопасную сессию. Он не использует TCP kTLS. Ограниченная диагностическая конечная точка Webship проверяет источники и обеспечивает соблюдение ограничений сессии, потока, капсулы, датаграммы, байта и времени простоя.
В прогоне пропускной способности 1.3.1 прямая передача WebTransport достигла 1 018,1 МиБ/с для надежных потоков и 1 038,9 МиБ/с для датаграмм. Пропуск через TLS достиг 548,6 МиБ/с и 629,7 МиБ/с соответственно. Оба режима прошли все пять образцов без отклоненных образцов, без потерянных датаграмм и без серьезных ошибок клиента.
Предпочитайте HTTP/3 для новых клиентов WebTransport. Путь HTTP/2 существует для совместимости со старыми настройками устаревших черновиков.
Что проверить перед выпуском в производство
- Тестируйте точные размеры медиа или объектов, которые вы будете предоставлять, а не только маленький синтетический ответ.
- Проверьте длину ответа и контрольную сумму содержимого на клиенте.
- Отмена упражнений, запросы диапазона, медленные читатели и поведение при полузакрытом исходном состоянии.
- Измеряйте устойчивую пропускную способность вместе с загрузкой ЦП, памятью, ошибками сокета, повторными передачами и задержкой на конце.
- Отдельно проверяйте прямой режим, режим с завершением TLS и режим сквозной передачи; у них разные границы безопасности и маршрутизации.
- Держите инструменты выключенными для обычного рабочего трафика, затем включайте ограниченную диагностику намеренно при расследовании.
- Перепроверьте предварительную проверку Linux kTLS и BBR после изменений ядра, контейнера или песочницы systemd.
Потоковая передача данных быстра, когда весь путь работает согласованно. Дизайн Webship сохраняет оптимизации для больших объемов данных специфичными для протокола, одновременно поддерживая одну операционную модель и один стандарт корректности.
Прочитайте полную [документацию Webship 1.3.1](/docs/1.3.1), ознакомьтесь с [методологией бенчмарка и матрицей конкурентов](/benchmarks) или скачайте подписанную сборку из [Загрузок](/downloads).