# トランスポートプロトコル設計 ## 定義 トランスポートプロトコル設計における中心的な緊張は、あらゆるユースケースに対応しようとする汎用のストリームトランスポート(TCP)と、リクエスト/リプライ型のワークロード(RPC、遠隔手続き呼出し)に特化したトランスポート(VMTP、Homa、RDMA系プロトコル、QUICなど)のどちらを選ぶかという設計軸である。RPCの核心はバイトストリームの転送ではなくメッセージの送信とレスポンスの受け取りにあり、メッセージの損失・順序入れ替え・重複への対処やリクエスト/レスポンスの紐付けを要する一方、信頼性のあるバイトストリームでは防がれてしまうアウトオブオーダー配信はRPCにとってむしろ望ましい。1980年代から90年代にかけてTCP/IPスタックにRPC向けの標準トランスポートが欠けていたことが、数多くのRPCフレームワーク(SunRPC、DCE/RPC、x-kernel実装等)の乱立と、HTTPが事実上のRPCプロトコルとして扱われる状況を生んだ。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 7 TCPの考古学]] §7.4, §7.5) ## 横断的知見 - **標準化に失敗したRPCトランスポートの系譜と、各社独自RPCフレームワークの乱立は同じ欠落の異なる現れである**: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 7 TCPの考古学]] は、V Kernelでの経験をもとに1988年に試みられたVMTP(RFC 1045で規定)の標準化が最終的に頓挫したことを示す一方、[[@2023__SOSP__A Cloud-Scale Characterization of Remote Procedure Calls]] が特性を明らかにするGoogleの独自RPCフレームワーク(Stubby)は、標準化されたインターネットRPCトランスポートが存在しないまま各組織が自前でRPC基盤を構築してきた歴史的パターンの一事例と読める。インターネット標準の側でRPCトランスポートが確立しなかったことが、結果としてハイパースケーラごとに独自のRPCスタックとその上のレイテンシ特性(P99テールタックス、コールグラフの偏り)を生み出す土壌になったと言える。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 7 TCPの考古学]] §7.5, [[@2023__SOSP__A Cloud-Scale Characterization of Remote Procedure Calls]]) - **HPCコミュニティの「並行世界」は、インターネット標準化とは独立にRPC的問題を解決した先行事例である**: 同章は、HPCコミュニティがインターネットほど広範な相互運用性を気にかけず、通信ハードウェア(InfiniBand)からエンドツーエンド通信のソフトウェア(MPI、Active Messages)まで独自のネットワーク基盤技術を構築し、通信の両端を完全に制御できるという前提でスループット最大化・レイテンシ最小化を追求してきたと述べる。この系譜がクラウド汎用ハードウェアへ波及した結果がRoCE(RDMA over Converged Ethernet)である。[[データセンター輻輳制御]] が集約するDCQCN・TIMELY・HPCCといったRDMA/RoCE向け輻輳制御プロトコル群は、この意味で「TCPに代わるRPC指向トランスポートの選択肢」という本概念の関心と、「輻輳制御アルゴリズムそのものの設計」という[[データセンター輻輳制御]]の関心が、同じRDMA技術群を異なる粒度・異なる問いで捉えている実例である。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 7 TCPの考古学]] §7.6, [[データセンター輻輳制御]]) - **RPCの実証的な特性(SOSP 2023)は、TCPとRPCの構造的ミスマッチという歴史的議論(本書第7章)の具体的な帰結として読める**: [[クラウドスケールRPC特性]] が示す「平均では小さいRPC latency taxがテールでは支配的になる」という観察は、本書第7章がTCPの信頼性のあるバイトストリームというモデルをHTTP/RPCに適用することの「避け難いミスマッチ」と呼ぶ現象の定量的な裏付けの一つと解釈できる。ただし本書第7章はこのミスマッチをヘッドオブラインブロッキング・輻輳への応答・TLSの追加RTTという設計論のレベルで論じるのに対し、SOSP 2023論文はGoogle本番環境の測定データからテールタックスやコールグラフの偏りを実証する点で、抽象度も出典の性質(設計エッセイ対大規模実測)も異なる。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 7 TCPの考古学]] §7.4, [[@2023__SOSP__A Cloud-Scale Characterization of Remote Procedure Calls]]) - **PCSD第7章が示すAt-Least-Once/At-Most-Once配送保証の分解(タイマー+nonceによる持続的送信者 対 受信側nonce一覧による重複抑止)は、『ネットワークシステムについて語るときに我々の語ること』第7章がRPC向けトランスポートに求める要件を、より基礎的な設計語彙で裏付ける**: 本概念の既存の横断的知見は、RPCの核心が「メッセージの損失・順序入れ替え・重複への対処やリクエスト/レスポンスの紐付け」にあると述べるが、その対処の具体的な機構分解までは踏み込んでいなかった。PCSD第7章§7.5.2-§7.5.3は、この対処を独立した2つの保証に分解する。At-Least-Once配送は送信側にタイマーと持続的送信者(persistent sender)を置き、確認応答が返るまで再送し続けることで実現し、At-Most-Once配送(重複抑止)は受信側に既知nonce一覧(tombstone)を置き、二重処理を防ぐことで実現する。両者を組み合わせたExactly-Once配送ですら「配送されるなら1回だけ」を保証するにとどまり、配送そのものの成功は保証しない、という限界も明示される。TCPが単一のストリーム順序保証にこの2つの配送保証を溶け込ませてしまい、RPCが個別に必要とする2つの独立した保証を選択的に有効化できないことが、VMTP・Homa・RDMA系プロトコルのようなRPC指向トランスポートが標準的なバイトストリームモデルからの逸脱を必要とする理由の一端だと読める。(Source: [[@2009__MITOCW__Principles of Computer System Design - Chapter 7 The Network as a System and as a System Component]] §7.5.2, §7.5.3, [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 7 TCPの考古学]] §7.4) - **PCSD第7章のtombstone問題(重複抑止のためのnonce一覧が無限に増大しうるという課題)は、本概念が扱うRPCフレームワークの実装がべき等性キーの寿命管理をどう設計すべきかという、実務上見落とされがちな設計判断を明示化する**: PCSD§7.5.3は、tombstoneの無限増大への対処として「ポート番号を使い捨てにする」「一定回数の再試行後に古いnonceを破棄する」という2つの実務的な妥協策を挙げ、後者は僅かな確率での誤りを許容する設計だと明記する。本概念が扱うSunRPC・DCE/RPC・Stubbyのような独自RPCフレームワークの乱立(既存の横断的知見)は、標準化されたトランスポートの不在という側面に加えて、こうしたtombstone寿命管理のような細部の設計判断についても各実装が独自の解を持たざるを得なかった可能性を示唆する。(Source: [[@2009__MITOCW__Principles of Computer System Design - Chapter 7 The Network as a System and as a System Component]] §7.5.3) - **原典教科書(本書第5章)は「TCP対RPC」という2項対立ではなく、UDP・TCP・RPC・RTPを『プロセス間通信サービスへの4つの異なる答え』として並置しており、本概念の既存の軸(TCP対RPC)はこの4分類のうち2つを取り出した部分集合にすぎない**: 既存の横断的知見・定義は「TCP対RPC」を中心的な緊張として扱ってきたが、本書第5章のProblem節は、トランスポート層の課題を「ホスト間パケット配送をプロセス間通信サービスへ変換すること」という単一の問題として立て、UDP(最小の多重分離)・TCP(信頼性のあるバイトストリーム)・RPC(リクエスト/リプライ)・RTP(リアルタイム)を、この単一問題に対する並列の4つの設計解として提示する。この教科書的な整理に照らすと、[[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 7 TCPの考古学]] が論じる「TCP対RPC」の緊張は、4つの答えのうちTCPとRPCという2つだけを取り出し、なぜインターネットがRPC向けの標準解を持たずTCPの流用(HTTP経由)で済ませてきたかを歴史的に掘り下げたものだと位置づけ直せる。UDP・RTPという残り2つの答えは、TCP対RPCの緊張の外側にある独立した設計解として本概念にはまだ十分に統合されていない。(Source: [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 5 End-to-End Protocols]] Problem, [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 7 TCPの考古学]] §7.4) - **本書第5章が示すSunRPC・DCE-RPCの実装上の違い(at-most-once semanticsを保証できるか否か)は、PCSD第7章が示すAt-Least-Once/At-Most-Once配送保証の抽象的な分解に、具体的な実装の明暗を与える**: 既存の横断的知見は、PCSD第7章がAt-Least-Once配送(送信側タイマー+持続的送信者)とAt-Most-Once配送(受信側nonce一覧)を独立した2つの保証に分解することを示した。本書第5章§5.3.2は、この抽象的な分解が現実のRPC実装でどちらか一方しか満たされない例を与える。SunRPCはXIDで要求と応答を対応づけるが応答後にXIDを記憶しないためAt-Most-Once semanticsを保証できず、DCE-RPCは`ActivityId`・`SequenceNum`・`ServerBoot`という3つのフィールドでこれを実現する(SunRPCのbootID相当の仕組みをDCE-RPCは`ServerBoot`として明示的に持つ)。すなわちSunRPCは意図的にPCSDの言う「重複抑止」機構を持たない設計を選び、DCE-RPCはそれを実装するという選択の分岐が、同じ問題領域に対する2つの現実の答えとして観察できる。(Source: [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 5 End-to-End Protocols]] §5.3.2, [[@2009__MITOCW__Principles of Computer System Design - Chapter 7 The Network as a System and as a System Component]] §7.5.2, §7.5.3) - **本書第5章のgRPCの説明(TCP・TLS・HTTP/2という既存の層の上にRPCを『アウトソース』して構築する設計)は、本概念が扱う『標準化されたRPCトランスポートの不在』という歴史的欠落に対する、現代における実務的な決着の一形態を示す**: 既存の横断的知見は、VMTPの標準化失敗とSunRPC・DCE-RPC・Stubby(≒gRPC相当のGoogle内製RPC)の乱立を、標準化されたRPCトランスポートが存在しなかったことの帰結として位置づけていた。本書第5章§5.3.2は、gRPCが独自のRPCトランスポートを新規に定義するのではなく、TCP・TLS・HTTP/2という既に広く普及した3層の上に「乗る」ことで、接続管理・暗号化・多重化の問題を丸ごと再利用する設計を選んだと説明する。これは新しいRPC専用トランスポート(VMTP、Homa)を標準化させる方向ではなく、既存の砂時計のくびれ(HTTP、[[砂時計モデル]]参照)へRPCを合流させる方向の解決であり、本概念が示す「TCP対RPC」の緊張を、新しいプロトコルの発明ではなく既存プロトコルの積層で解消する第3の道筋を示している。(Source: [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 5 End-to-End Protocols]] §5.3.2 gRPC, [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 7 TCPの考古学]] §7.4, §7.5) ## 未解決の問い - PCSDのAt-Least-Once/At-Most-Once配送保証の分解を、Homa・QUICなどの現代のRPC指向トランスポートは実際にどう実装しているか(nonce・tombstoneに相当する機構をどこに置いているか)は、本ページでは未検証。 - 本書第5章が示すUDP・RTPという残り2つの「答え」(最小の多重分離、リアルタイム向け)は、TCP対RPCの緊張の外側でどのような独自の設計トレードオフを持つか。特にRTPが持つApplication Level Framing(ALF)原則は、Homa・QUICが採用する設計判断とどこまで系譜的に近いか、本ページでは未検証。 - VMTP(1988年)が標準化に失敗した理由と、QUIC(UDP上に構築、ミドルボックス互換性を優先)が普及しつつある要因を比較すると、新しいトランスポートプロトコルの標準化・普及戦略についてどのような一般的教訓が得られるか。 - HomaやQUICのような「第二の設計アプローチ」がカーネル内でTCPと十分に共存できることは、大規模本番環境でどこまで実証されているか。 - HPCコミュニティのRDMA/InfiniBand/MPIという「並行世界」は、クラウド汎用ハードウェアへの移行が進むなかで、インターネットコミュニティの標準化プロセスとどこまで統合されるか。RoCEはその統合の途中経過と言えるか。 - [[クラウドスケールRPC特性]] が示す実運用のテールレイテンシ税のうち、TCPの汎用性(信頼性のあるバイトストリームというモデル)に起因する部分と、RPCフレームワーク自体の設計(シリアライズ、コールグラフの構造)に起因する部分はどう切り分けられるか。 - モノリシックでないカーネル(Exokernelのようなアーキテクチャ)でHoma・TCP・RoCE・QUICをライブラリOSごとに使い分けるという構想は、特権/非特権モードの境界設計やSmartNIC/IPUへのオフロード判断とどう両立しうるか。 ## 関連 - [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 5 End-to-End Protocols]] — UDP・TCP・RPC・RTPを「プロセス間通信サービスへの4つの異なる答え」として整理する教科書的原典。 - [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 7 TCPの考古学]] — TCP対RPCの歴史的議論の主要ソース。 - [[@2023__SOSP__A Cloud-Scale Characterization of Remote Procedure Calls]] — RPCの実証的な規模・レイテンシ特性。 - [[@2009__MITOCW__Principles of Computer System Design - Chapter 7 The Network as a System and as a System Component]] — At-Least-Once/At-Most-Once配送保証の分解と、それぞれを実現する機構(タイマー・重複抑止)の基礎的な設計語彙。 - [[クラウドスケールRPC特性]] — 同論文が示すRPCの規模・構造・レイテンシ特性を集約する概念。 - [[データセンター輻輳制御]] — RDMA/RoCE系の輻輳制御プロトコル群を輻輳制御という異なる軸から扱う概念。 - [[QUIC]] — RPCパラダイムを実装するトランスポートとしてのQUIC。 - [[TCP輻輳制御アルゴリズム]] / [[エンドツーエンド論]] / [[ユーザーレベルTCPスタック]] — 関連する設計原則・実装アプローチ。 - [[Homa]] / [[John Ousterhout]] / [[David P. Reed]] — TCP対RPCの議論の中心人物と成果物。 ## 出典 - Larry Peterson and Bruce Davie, *Computer Networks: A Systems Approach*, 6th edition, Chapter 5: End-to-End Protocols. https://book.systemsapproach.org/e2e.html - [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 7 TCPの考古学]] §7.4, §7.5, §7.6 - [[@2023__SOSP__A Cloud-Scale Characterization of Remote Procedure Calls]] - Jerome H. Saltzer and M. Frans Kaashoek, *Principles of Computer System Design: An Introduction*, Version 5.0, 2009, Chapter 7, §7.5.2, §7.5.3.