インターネットは少数の中核プロトコルで動作しており、 TCP と UDP がほぼすべてのデータを処理する主力となっています。しかし、他のものを使おうとするとどうなるでしょうか？架空のトランスポートプロトコルを使ってパケットをインターネット上で送信する興味深い実験により、デジタルインフラの隠れた制約と、トランスポート層でのイノベーションがなぜほぼ不可能になったのかが明らかになりました。
プロトコル硬化：インターネットの隠れた問題
インターネットは「プロトコル硬化」と呼ばれる状態に悩まされています。これは、ミドルボックス、ファイアウォール、 NAT デバイスの広範な展開により、トランスポートには TCP と UDP のみを使用することが事実上強制されている状態です。理論的には IP ネットワークはあらゆるプロトコルを転送できるはずですが、現実は大きく異なります。あるコメンターが説明するように、インターネットは TCP と UDP を中心に標準化されています。ほとんどの経路には、他のプロトコルを処理できないデバイスが多数存在します。この硬化は、ネットワーク機器メーカーやオペレーターが最も頻繁に見るプロトコルに最適化するため、新しいものや異なるものとの互換性が失われることで発生します。
SCTP （Stream Control Transmission Protocol）はこの問題の完璧な例です。多くの面で TCP より技術的に優れているにもかかわらず、公共インターネット上ではほとんど使用されていません。
「 SCTP は興味深いプロトコルです。地球上のほとんどの人々の通信を可能にする基盤技術の一つ（モバイルネットワークスタックはほぼこれに依存しています）であるにもかかわらず、ほぼすべての消費者デバイスで実質的にサポートされていません。」
SCTP は重要な通信インフラを内部的に支えていますが、公共インターネットを確実に横断することはできません。このパラドックスは、優れた設計の標準化されたプロトコルでさえ、ネットワークが実際にどのように構築・管理されているかという現実に直面すると、採用を獲得できない可能性があることを浮き彫りにしています。
プロトコル固定化の問題
- 失敗したプロトコル: SCTP（Stream Control Transmission Protocol）- 技術的には優れているが公共インターネットを通過できない
- NATの問題: NATの背後にいる一般ユーザーは TCP/UDP のみに制限される
- 回避策: 新しいプロトコルを UDP 内にトンネリングする（例：HTTP/3 のための QUIC）
- 特殊なケース:
- SCTP はモバイルネットワークインフラ内部で広く使用されている
- WebRTC は UDP 上の DTLS 上で SCTP を実行する
- カスタムプロトコルはデータセンターサーバー間では機能するが、公共インターネット経由では失敗する
カスタムプロトコルが失敗する理由
- ミドルボックスが見慣れないプロトコルを破棄する
- NAT デバイスはポート番号なしで接続状態を追跡できない
- 企業のセキュリティツールが可視性を失う
- ファイアウォールが既存のフローに一致しないパケットをブロックする
NAT：インターネットの最大の障害
ネットワークアドレス変換（ NAT ）デバイスは、プロトコルイノベーションに対する最も重大な障壁を表しています。 NAT はトランスポート層のフィールド、特に TCP と UDP ヘッダーのポート番号を使用して接続を追跡します。これらの馴染みのあるフィールドを持たない未知のプロトコルに直面すると、ほとんどの NAT デバイスは IP アドレス全体を消費する（利用可能なアドレスをすぐに使い果たす）か、単にパケットを破棄します。
この制限は特に家庭ユーザーにとって問題です。あるコメンターが指摘したように、すべての家庭ユーザーは NAT の背後にいます。データセンターサーバー間では任意のプロトコルを送信できますが、 IPv4 の家庭ユーザーは TCP または UDP に縛られています。記事で説明されている実験でも、カスタムプロトコルを使用したパケットは時々最初は通過しましたが、その後破棄されました。これはおそらく、ファイアウォールが既存の接続フローに一致させることができなかったためです。
未来：プロトコルトンネリングと IPv6
硬化を克服するために、現代のプロトコル設計者は実用的なアプローチを採用しています：新しいプロトコルを UDP 内にトンネリングすることです。 HTTP/3 を支える QUIC はこの戦略の典型です。システムと戦うのではなく、 QUIC は UDP を基盤として受け入れ、その上にイノベーションを構築します。
このアプローチはイノベーションとセキュリティの間に緊張を生み出します。ネットワーク管理者はこれらの開発に抵抗することが多いです。なぜなら、既存のセキュリティツールが機能しなくなるからです。あるネットワーク専門家が説明したように、「企業のセキュリティの観点から見ると、多くのツールが機能しなくなります。復号化できず、 IDS/IPS シグネチャが機能せず、ネットワークで何が起きているかの可視性が失われます。」
IPv6 は多くのシナリオで NAT の必要性を排除するため、プロトコルの多様性に希望を提供します。しかし、 IPv6 でも、ファイアウォールやミドルボックスは依然として未知のプロトコルをブロックする可能性があります。 IPv6 への移行は苛立たしいほど遅く、多くの企業ネットワークはまだ IPv4 アドレス空間に依存しています。
記事で説明されている実験は、ネットワークエンジニアが長い間疑っていたことを確認しています：インターネットは少数のプロトコルに最適化された非常に特殊な環境になっています。エキゾチックなプロトコルで単一のパケットを送信することに運良く成功するかもしれませんが、信頼性の高い通信を構築するには、ネットワークが理論的にサポートすべきものではなく、実際にサポートしている制約内で作業する必要があります。
予見可能な将来において、 TCP と UDP は公共インターネットトラフィックの唯一の実行可能なトランスポートオプションであり続け、イノベーションは主に新しいトランスポートプロトコルを通じてではなく、トンネリングとレイヤリングを通じて行われるでしょう。
参考文献: What would happen if we didn't use TCP or UDP?
 |
|---|
| アウトバウンドトラフィックを制限するファイアウォールルールは、プロトコル革新に対するネットワーク制約を表しています |