ウェブは正確な取り決めによって成り立っています。Content-Length フィールドは、どの中継点でも同じ意味でなければなりません。キャッシュは、検証が必要なレスポンスを再利用してはいけません。不正な HTTP/3 フィールドセクションは、正しい範囲で失敗しなければなりません。安全なメソッドは、リバースプロキシを通過した後も安全でなければなりません。
Webship 1.3.1 は一つのルールを中心に作られています：バイトが意味を保つときだけ、速度が重要です。
だからこそ、私たちはWebshipを世界で最もRFC互換性の高い汎用ウェブサーバーとして説明しています。これはすべてのRFCのすべてのオプション機能が存在するという主張ではなく、境界が明確に見える工学的な主張です。下のマップには、Webshipのアクティブなサーバーの挙動や、それが所有するプロトコルの基盤に影響を与える52のRFCが示されています。現在の標準が最初に掲載されており、置き換えられた文書は互換性の系譜として特定されています。ドラフト仕様はRFCとして再ラベルされません。
互換性は行動であり、バッジではない
Webshipは、運用サーバーが最も曖昧になる場所で基準を適用します：
- HTTP/1.1 フレーミングは、矛盾する長さ、無効な転送コーディング、過大なリクエストターゲット、不正なチャンク、およびリクエスト・スマグリングの形状を拒否します。
- HTTP/2 と HTTP/3 は禁止された接続フィールドを拒否し、擬似フィールドを検証し、圧縮フィールドセクションの境界を設定し、ストリームのエラーを接続エラーから分離して保持します。
- 静的ファイルは、HEAD のセマンティクス、バリデータ、前提条件の順序、バイト範囲、リダイレクト、およびコンテンツタイプを保持します。
- リバースプロキシは、フレーミング、キャンセル、トレーラー、アップグレード、安全な再試行、および転送先の識別を保持しつつ、ホップごとのフィールドを除去します。
- キャッシュはキャッシングを単なるキーと値のショートカットとして扱うのではなく、年齢、新鮮さ、再検証、Vary、無効化、および古い使用ルールを計算します。
- TLS、QUIC、ACME、アーリーデータ、およびWebTransportは、有界状態と明示的な失敗方針を使用します。
高速パスでも同じルールが適用されます。Webshipは「正しい」パスと異なるベンチマークパスを定義していません。
HTTP のセマンティクス、フレーミング、キャッシュ、およびプロキシ
- RFC 3986 — ユニフォームリソース識別子 (URI): 一般的構文。Webshipは、キャッシュの無効化の判断を行う前に、ドット区切りを含む相対的なLocationおよびContent-Location参照を正規化します。
- RFC 6455 — WebSocket プロトコル。リバースプロキシのアップグレードは、WebSocket キー、Accept 値、サブプロトコル、拡張、およびトンネルの遷移を検証します。
- RFC 6585 — 追加のHTTPステータスコード。オーバーサイズのリクエストフィールドには、HTTPレスポンスがまだ可能な場合、定義された431レスポンスが使用されます。
- RFC 6797 — HTTP Strict Transport Security。Strict-Transport-Security は安全なトランスポート上でのみ送信され、トランスポートに依存しないキャッシュエントリから平文の HTTP に漏れることはありません。
- RFC 7235 — HTTP/1.1 認証。認証スキームトークンは保護された MCP コントロールサーフェスを含め、大文字小文字を区別せずに解析されます。その一般的な HTTP セマンティクスは現在 RFC 9110 にあります。
- RFC 7239 — Forwarded HTTP 拡張。オペレーターは、標準ベースの Forwarded フィールド、従来の X-Forwarded フィールド、両方、またはどちらも選択できます。信頼できない受信アイデンティティフィールドは最初に削除されます。
- RFC 7540 — HTTP/2。これはHTTP/2互換性の系列として保持されています。現在使用されているHTTP/2の仕様はその後継であるRFC 9113です。
- RFC 7541 — HPACK: HTTP/2のヘッダー圧縮。Webshipが所有するHTTP/2スタックは、HPACKワイヤーフォーマットとハフマン符号化を維持しながら、デコーダ状態とエンコーダテーブルの境界を管理します。
- RFC 7838 — HTTP代替サービス。Alt-Svcは、URLで表されるオリジンを変更せずにHTTP/3エンドポイントを広告します。
- RFC 8441 — HTTP/2でのWebSocketsのブートストラップ。Webshipは下流のextended-CONNECTネゴシエーション基盤をサポートしています。HTTP/1.1アップストリームがHTTP/2 extended CONNECTを実装していると装うことはありません。サポートされていないアップストリームの組み合わせは明示的に失敗します。
- RFC 8470 — HTTPでのEarly Dataの使用。Webshipが処理しない早期リクエストは、安全でないリプレイの前提で処理されるのではなく、425 Too Earlyを受け取ります。
- RFC 8941 — HTTPの構造化ヘッダーフィールドの値。HTTPの優先度値は構造化フィールド辞書の解析を使用する。不正なオプションフィールドは全体として無視される。
- RFC 9110 — HTTPセマンティクス。メソッド、ステータスコード、フィールド、バリデーター、前提条件、リダイレクト、コンテンツメタデータ、HEAD、CONNECT、OPTIONS、およびレンジセマンティクスは、プロトコルバージョン間で1つの現在の契約を共有します。
- RFC 9111 — HTTPキャッシング。Webshipは、修正済みAge、明示的な鮮度、Vary、only-if-cached、must-revalidate、proxy-revalidate、安全な古いキャッシュの使用、および有効なURIと関連するURIの無効化を実装しています。
- RFC 9112 — HTTP/1.1。リクエストライン、フィールド、ボディ長、転送符号化、チャンク、トレーラー、永続性、およびクローズ区切りのルールは、アプリケーションディスパッチの前に適用されます。
- RFC 9113 — HTTP/2。擬似フィールドの順序、権限、禁止されている接続フィールド、TE制限、ストリームライフサイクル、フロー制御、GOAWAY、およびエラー範囲は、Webship所有のH2パスによって処理されます。
- RFC 9114 — HTTP/3。Webshipは、そのHTTP/3サーバーで使用されるリクエスト、コントロールストリーム、SETTINGS、クリティカルストリーム、キャンセル、およびストリーム対接続のエラーパスを所有します。
- RFC 9204 — QPACK: HTTP/3用フィールド圧縮。動的テーブルの容量は通知された制限によって制約され、命令ストリームは容量がゼロでも解析可能なままであり、無効な状態は必要なQPACKエラーとなる。
- RFC 9218 — HTTPのための拡張可能な優先付けスキーム。緊急性と漸進的配信は、優先度のパラメータが未定の場合にも拡張可能な形で、HTTP/3のスケジューリングを案内する。
- RFC 9220 — HTTP/3でのWebSocketsのブートストラップ。Webshipは、現代のトンネル化プロトコルで使用されるHTTP/3拡張CONNECT SETTINGSの基盤を実装しています；これはすべての可能なCONNECTプロトコルが受け入れられることを意味するわけではありません。
- RFC 9297 — HTTP データグラムとカプセルプロトコル。WebTransport セッションは、境界付きカプセルデコーディングと HTTP データグラムの関連付けを使用し、未知のカプセルはパーサーの失敗ではなく拡張ポイントとして処理されます。
- RFC 9421 — HTTPメッセージ署名。オプションのEd25519レスポンスプロヴェナンスは、TLSやアプリケーション認証を置き換えることなく、Webshipのリリースおよび構成のIDをカバーできます。
- RFC 10008 — HTTP QUERY メソッド。Webship は QUERY を安全かつ冪等として扱い、プロキシを通す際にその本文を保持し、キャッシュ識別に本文および表現メタデータを含め、ヒューリスティックな鮮度判定を禁止し、条件付きおよび範囲指定の動作をサポートし、QUERY が使用されたという理由だけでキャッシュを無効化することはありません。
QUICのトランスポートと輻輳制御
- RFC 3465 — 適切なバイトカウントによるTCP輻輳制御。適切なバイトカウントのロジックは、WebshipのQUIC実装で使用されるNewReno輻輳制御系列の一部です。
- RFC 4303 — IPカプセル化セキュリティペイロード。WebshipはIPsec ESPを実装していません；そのQUICパケット重複除去機能は、実装系譜としてのみRFCのスライディングウィンドウ再生防止技術を使用しています。
- RFC 5681 — TCPの輻輳制御。損失および並べ替えの閾値は、QUICがTCPの慣行に基づいて構築される際に確立された輻輳制御の制約を引き継ぎます。
- RFC 6298 — TCPの再送タイマーの計算。平滑化された往復時間と分散の計算は、QUICの回復モデルに寄与する。
- RFC 8312 — 高速長距離ネットワーク向けCUBIC。これはアルゴリズムの系譜として保持されている以前のCUBIC仕様です；RFC 9438が現在の標準です。
- RFC 8899 — データグラムトランスポートのためのパケット化レイヤ経路MTU探索。設定可能なDPLPMTUDは、脆弱なネットワーク層の信号に依存せずに使用可能なQUICデータグラムサイズを検出します。
- RFC 8999 — QUICのバージョン非依存プロパティ。ロングヘッダー、コネクションID、バージョンネゴシエーション、および不変のパースは、バージョン固有のデコーダが実行される前でも安全です。
- RFC 9000 — QUIC: UDPベースの多重化された安全なトランスポート。接続ID、ストリーム、フロー制御、マイグレーション、アドレス検証、Retry、ステートレスリセット、トランスポートパラメータ、およびクローズ動作は、WebshipのHTTP/3トランスポート基盤を形成します。
- RFC 9001 — QUICを保護するためのTLSの使用。初期のシークレット、パケット保護、ヘッダ保護、リトライの整合性、キーのフェーズ、およびTLS統合はQUIC-TLSの規則に従います。
- RFC 9002 — QUICの損失検出と輻輳制御。パケット番号空間、確認応答、PTO、損失検出、回復、および輻輳計算が、トランスポートの信頼性を支える。
- RFC 9221 — QUICへの信頼性のないデータグラム拡張。ネゴシエートされたQUIC DATAGRAMフレームは、信頼性のないWebTransportトラフィックをストリームコンテンツに変換することなく運びます。
- RFC 9287 — QUICビットのグリース。QUICビットのグリースは、交渉の安全性を保ちながら硬直化（オシフィケーション）を減らします。
- RFC 9308 — QUICトランスポートプロトコルの適用性。制限付きアイドル時間や展開ガイダンスなどの運用デフォルトは、Webshipの本番トランスポートポリシーに情報を提供します。
- RFC 9369 — QUIC バージョン 2。バージョン 2 のパケットタイプ、初期キー、リトライ整合性、キー更新、およびバージョンネゴシエーションは、QUIC v1 とともに実装されています。
- RFC 9438 — 高速・長距離ネットワーク向けCUBIC。現在のCUBIC標準はWebshipのCUBIC輻輳制御装置を規定しており、BBRやNewRenoはワークロードに応じて選択可能のままです。
TLS、証明書、自動証明書管理
- RFC 3339 — インターネット上の日付と時刻: タイムスタンプ。ACMEの更新ウィンドウは、相互運用可能なインターネットタイムスタンプを使用します。
- RFC 4648 — Base16、Base32、Base64 データエンコーディング。ACME JOSE の値と WebSocket ハンドシェイクのデータは、必要な Base64 および Base64url のアルファベットとパディング規則を使用します。
- RFC 5280 — インターネット X.509 PKI 証明書および CRL プロファイル。証明書の解析および生成されたチャレンジ証明書は、正しい DNS およびバイナリ IP の subjectAltName 形式を使用します。
- RFC 5869 — HMAC ベースの抽出-展開型鍵導出関数。HKDF-SHA-256 および HKDF-SHA-384 の導出は、出力の範囲を含めて、TLS および QUIC の鍵の基礎となります。
- RFC 6066 — TLS 拡張。SNI は DNS アイデンティティを選択しますが、リテラル IP アドレスは通常のホスト名形式から正しく除外されます。
- RFC 7301 — TLS アプリケーション層プロトコルネゴシエーション。ALPN は TLS 境界で HTTP/1.1、HTTP/2、HTTP/3、および隔離された ACME チャレンジプロトコルを選択します。
- RFC 7638 — JSON Web Key Thumbprint。ACMEアカウントキーのサムプリントは、正規化されたJWK形式で導出されます。
- RFC 7807 — HTTP APIの問題詳細。WebshipはRFC 8555 ACMEサーバーが要求する問題ドキュメント形式を利用します。新しいProblem Details仕様は新しい汎用APIではこれに取って代わりますが、ACMEの規範的依存は明示的に残ります。
- RFC 8446 — TLS 1.3。Webship は、セッションチケット、キー更新、アラート、早期データポリシー、および QUIC キー導出を含む公開 TLS に TLS 1.3 を使用します。
- RFC 8555 — 自動証明書管理環境。アカウント、オーダー、認可、チャレンジ、最終化、証明書のダウンロード、および更新のフローは、範囲が限定された入力処理とともに自動化されています。
- RFC 8737 — ACME TLS-ALPN-01 チャレンジ。チャレンジ専用の TLS パスは acme-tls/1 のみをネゴシエートし、必要な重要な acmeIdentifier 証明書拡張を提供します。
- RFC 8738 — ACME IP識別子検証拡張。WebshipはIPv4およびIPv6の証明書注文、バイナリIP SAN、およびIP TLS-ALPN-01検証用の逆アドレスSNIをサポートしています。
- RFC 9525 — TLSにおけるサービス識別。DNS名とIP識別子は、IPアドレスに対するワイルドカードやコモンネームのショートカットを使用せず、現在のサービス識別ルールに従って照合されます。
- RFC 9773 — ACME更新情報拡張。更新ウィンドウはCAから提供されることがあり、これによりWebshipは一つの厳格なローカルスケジュールを使用するのではなく、安全に更新を分散させることができます。
WebTransport：標準化されていることについて正確に
HTTP/3 上の WebTransport は、53 番目の RFC としては数えられません。Webship 1.3.1 の時点では、そのワイヤーマッピングは draft-ietf-webtrans-http3-16 のままです。Webship は標準化された HTTP/3、拡張 CONNECT、QUIC DATAGRAM、HTTP Datagram、および上記の Capsule レイヤーの上にそのドラフトを実装しています。また、WebTransport ストリームがリセットされるときに信頼できるセッション識別プレフィックスを保持するために必要な、交渉された RESET_STREAM_AT 拡張も実装しています。
その区別は重要です。ドラフトをRFCと呼ぶことでは、標準の互換性は向上しません。それは、ドラフトを明示的に追跡し、通常のHTTPパスから分離し、すべての拡張を交渉し、すべてのセッションリソースを制限し、キャンセルおよび障害の挙動をテストすることで向上します。
なぜこの幅広さが生産において重要なのか
標準のバグはめったに単独では発生しません。不正な HSTS の処理はキャッシュの境界を越えることがあります。不正な QPACK 命令は無関係なリクエストを終了させることがあります。安全でない early-data の仮定は操作を再実行させる可能性があります。リクエストボディを省略した QUERY キャッシュキーは別のクエリの結果を返すことがあります。トレーラーを削除したりキャンセル処理を誤ったプロキシは、アプリケーションプロトコルを静かに変更する可能性があります。
Webshipのアーキテクチャは、これらを関連する問題として扱います。パーサーの制限、セキュリティ検査、キャッシュ、リバースプロキシ、トランスポート状態、計測は明示的な契約を共有します。その結果、各モードに異なる正確性の定義を与えることなく、HTTP/1.1、HTTP/2、HTTP/3、静的配信、リバースプロキシ、ストリーミング、WebTransportの間を移動できる1つのサーバーが実現します。
主張を確認する
最上級の表現を鵜呑みにしないでください。まず[Webship 1.3.1 のドキュメント](/docs/1.3.1)を読み、設定やプロトコルの境界を確認し、公開されている動作を再現してください。その後、[Webship をダウンロード](/downloads)して、システムにとって重要なエッジケースをテストしてください。