ストリーミングのパフォーマンスは、単にビデオプレーヤーだけの問題ではありません。ソフトウェアの成果物、モデルの重み、バックアップ、オーディオライブラリ、および大規模なAPIエクスポートはすべて同じ基本原則に依存しています：バイトを迅速に移動させ、正確なペイロードを保持し、バックプレッシャーを尊重し、クライアントが切断した際にはきれいに停止することです。
Webship は、これらの要件を HTTP/1.1、HTTP/2、HTTP/3、直接ファイル配信、リバースプロキシ、および WebTransport にわたる1つのトランスポート問題として扱います。ファストパスは、フレーミング、キャンセル、トレーラー、セキュリティ検査、およびメモリ制限を維持する場合にのみ有用です。
100 MBのストリーミング容量を測定
Webship 1.3.1 Debianの容量性能は、固定された100 MBのフィクスチャで測定された中央値ペイロードスループットで実行されました。受け入れられるすべてのサンプルは、正確に99,943,778バイトのレスポンスボディと、クライアント、プロトコル、プロキシ、メジャーページフォールト、およびHTTP/3パケット損失のエラーがゼロであることを要求しました。
| Webship モード | HTTP/1.1 TLS | HTTP/2 TLS | HTTP/3 TLS | | --- | ---: | ---: | ---: | | 直接ファイル配信 | 4,194.8 MiB/s | 3,574.3 MiB/s | 2,096.9 MiB/s | | TLS終端付きリバースプロキシ | 3,585.7 MiB/s | 3,355.0 MiB/s | 1,938.6 MiB/s | | TLSパススルー付きリバースプロキシ | 2,783.2 MiB/s | 2,135.0 MiB/s | 1,748.5 MiB/s |
記録された比較では、Webship が、測定されたすべてのプロトコルにおいて、最も高い直接およびTLS終了の中央値を示しました。完全なマトリックスには、Nginx、Lighttpd、Caddy、HAProxy、Envoy、Pingora、Bun が [ベンチマークページ](/benchmarks) に含まれています。
これらの数字はベンチマークホスト上での容量を測定したものです。任意のインターネット経路に対する保証ではありません。ストレージの遅延、ネットワーク帯域幅、往復時間、パケット損失、TLSポリシー、同時実行数、およびオリジンの挙動が、実際の配信速度を決定します。
1つのバイナリ、3つの輸送戦略
大きなレスポンスは、小さなHTMLドキュメントと同じポリシーの恩恵を受けません。Webship は通常のリクエスト経路を控えめに保ち、実証済みの大量レスポンスのみを促進します。
HTTP/1.1: ファイルの周りの遷移を減らす
Linuxでは、Webship がレスポンスのヘッダとファイルペイロードを1つのベストエフォートTCPコルク間隔内に保持します。大規模なTLSレスポンスがバルクパスに適格になると、直接ファイル配信はRustlsレコードから監査される一方向カーネルTLSに移動でき、アプリケーションバッファを通してペイロードをコピーすることなくsendfileを使用できます。
接続は依然としてユーザースペースTLSで開始されます。小さな応答はそこで維持されます。Webshipは、接続が大量のデータを運んでいることを証明する少なくとも1 MiBの応答ボディの後でのみ、kTLSへの移行を要求します。
HTTP/2: フロー制御を壊さずにバッチ処理
HTTP/2 の多重化は、制御されていないバッファリングを高価にします。Webship は、ストリームおよび接続のフロー制御制限を保持しながら書き込みをバッチ処理します。高並行ストリーミングの場合、128 KiB の TLS 書き込みバッファには 64 KiB の DATA フレームを 2 つ格納できますが、接続送信の予算は明示的かつ制限付きのままです。
すでに準備が整ったアップストリームのボディフレームは、ハイパーフレーミング、トレーラー、キャンセル、検査、またはバックプレッシャーを回避することなくプリフェッチできます。これにより、プロトコル契約を維持しながら不要なスケジューララウンドを減らすことができます。
HTTP/3: kTLSの代わりにQUICペーシング
HTTP/3 は TCP kTLS パスを決して使用しません。Webship は、トランスポートを意識した QUIC ペーシング、制限付きデータグラムパケット化、DPLPMTUD、およびリアクターごとのタイマー駆動マイクロバッチ処理を適用します。大きな HTTP/3 レスポンスおよび受け入れられた WebTransport セッションは、通常トラフィックで使用される CUBIC ポリシーを変更することなく BBR を選択できます。
集中したHTTP/3の安定性評価では、7つの承認済みサンプルが使用されました。TLS終了ストリーミングは、2.12%の変動係数で1,938.6 MiB/sの中央値を示しました。TLSパススルーは、1.65%の変動係数で1,748.5 MiB/sを提供しました。両シリーズとも、ボディ整合性、クライアント、プロトコル、およびパケット損失のエラーはゼロでした。
直接配信ですか、それともリバースプロキシですか？
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"Webship がパスでルーティングする必要がある場合、WAF や API シールドのチェックを適用する場合、ボディ制限を強制する場合、転送ヘッダーを追加する場合、または HTTP フィールドを監視する場合は、リバースプロキシ TLS 終端を使用してください:
[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 パススルーは ClientHello SNI によってルーティングされますが、HTTP/3 パススルーには 1 つの共有 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"上記の接続予算は、256のアクティブなストリームに対して128 KiBのクレジットを提供します。これは普遍的なデフォルトではなく、容量の判断として扱ってください。増加させる前に、予想される同時実行性でメモリ、レイテンシ、およびスループットを測定してください。
Linuxでは、カーネルTLSおよびBBRモジュールをロードし、Webship サービスアカウントがBBRを選択できるようにします。Webship は、必要なカーネル機能が利用できない場合、バインド前に失敗するため、最適化されたパスを利用せずに実行している間にデプロイメントがそれを黙って取得することはできません。他のオペレーティングシステムは、プラットフォーム用に文書化されているポータブルな Rustls および輻輳制御パスを保持します。
WebTransport は異なるストリーミング形状です
WebTransportは、セキュアなセッション上で信頼できるストリームと信頼できないデータグラムを組み合わせます。TCP kTLSは使用しません。Webshipの有限診断エンドポイントは、オリジンを検証し、セッション、ストリーム、カプセル、データグラム、バイト、およびアイドル時間の制限を強制します。
バージョン1.3.1の容量試験では、直接WebTransportは、信頼性のあるストリームで1,018.1 MiB/s、データグラムで1,038.9 MiB/sに達しました。TLSパススルーはそれぞれ548.6 MiB/sおよび629.7 MiB/sに達しました。両方のモードとも、5つのサンプルすべてで、拒否されたサンプル0、失われたデータグラム0、クライアントメジャーフォルト0という結果を達成しました。
新しいWebTransportクライアントにはHTTP/3を優先使用してください。古い期限切れドラフト設定との互換性のためにHTTP/2パスが存在します。
本番トラフィックの前に確認すること
- 提供する正確なメディアやアーティファクトのサイズをテストしてください、単なる小さな合成レスポンスだけでなく。
- クライアントでレスポンスの長さとコンテンツダイジェストを確認する。
- 演習のキャンセル、レンジのリクエスト、遅い読者、およびオリジンの半閉じ動作。
- CPU、メモリ、ソケットエラー、再送、およびテールレイテンシとともに、持続的なスループットを測定します。
- 直接モード、TLS終了モード、パススルーモードをそれぞれ検証してください。それぞれ異なるセキュリティおよびルーティングの境界があります。
- 通常の本番トラフィックでは計測をオフにしておき、調査する際に限定的な診断を意図的に有効にします。
- カーネル、コンテナ、または systemd サンドボックスの変更後に、Linux の kTLS と BBR のプレフライトを再確認してください。
ストリーミングは、全体の経路が協力すると高速です。Webship の設計は、1つの運用モデルと1つの正確性基準を維持しながら、大容量データの最適化をプロトコル固有に保ちます。
完全な[Webship 1.3.1 ドキュメント](/docs/1.3.1)を読み、[ベンチマークの方法論と競合他社マトリックス](/benchmarks)を確認するか、[ダウンロード](/downloads)から署名済みビルドをダウンロードしてください。