情報管理技術士 学習ノート
← 一覧へ
ネットワーク
#MPTCP#다중경로#전송계층#서브플로우#결합혼잡제어
最終更新 · 2026-11-05

マルチパスTCP(MPTCP, Multipath TCP)

1. 概要

A. 定義

MPTCP(Multipath TCP)とは、1つのTCP接続を複数のネットワーク経路(サブフロー)にまたがって同時に転送しつつ、アプリケーションには単一の標準TCPソケットのように見せるトランスポート層の拡張プロトコルである。IETFがRFC 6824(v0, 2013)として標準化し、RFC 8684(v1, 2020)で改訂した。TCPオプションフィールドを用いて複数インタフェース(LTE・Wi-Fiなど)を1つの論理的接続に束ねる。

B. 登場背景と必要性

今日の端末は、2つ以上のネットワークインタフェースを同時に保有するのが一般的である。スマートフォンはセルラー(LTE・5G)とWi-Fiを、データセンタのサーバは複数NICを、ノートPCは有線と無線を併せ持つ。しかし従来のTCPは、接続確立時に選んだ送信元/宛先IPとポートの4タプルに固定され、そのうち1経路が切れたり輻輳したりしても別のインタフェースへ乗り換えられない。Wi-Fi信号が弱まるとセルラーが健在でもダウンロードが止まる経験がその典型例である。すなわち端末には余剰資源があるのに、TCPの硬直した接続モデルがそれを活かせないという構造的非効率が存在する。

この問題を解く直感的発想は「複数経路を同時に使う」ことだが、実現は単純でない。インターネットにはNAT・ファイアウォール・プロキシといったミドルボックス(middlebox)がTCPヘッダを検査・変形するため、まったく新しいトランスポートプロトコルは途中で遮断されやすい。MPTCPはこの現実を受け入れ、既存TCPとの線路(wire)互換性を保つ設計を選んだ。新しいプロトコル番号を使わず、既存TCPセグメントのオプションフィールドに制御情報を載せ、ミドルボックスには平凡なTCPに見えつつ両端ホストのみがマルチパスと理解するようにしたのである。この「漸進的配備可能性(incremental deployability)」こそ、数多くのマルチパス転送提案の中でMPTCPが実際の商用化に至った核心的理由である。

必要性は3つの価値に集約される。第一はスループット増大(bandwidth aggregation)で、複数経路の帯域を合わせてより速い転送を得る。第二は復元力(resilience)で、1経路が切れても残りの経路で接続を維持し、途切れのないハンドオーバを提供する。第三は輻輳分散(load balancing)で、輻輳した経路のトラフィックを余裕のある経路へ移し、ネットワーク全体の効率を高める。これら3つの価値は、モバイル・データセンタ・IoTなど多重接続環境が普遍化するほど重要度を増している。

C. 設計目標と特徴

MPTCPの設計はRFC 6356が明示した3つの目標に要約される。(1) スループット改善: 複数経路を併用するMPTCP接続は、最良の単一経路1本を使うよりも性能が劣ってはならない。(2) 無害性(do no harm): MPTCP接続の全サブフローが共有ボトルネックで占める総量は、同じボトルネックで単一経路TCP1本が占める量を超えてはならない。(3) 輻輳均衡(balance congestion): できる限り輻輳の少ない経路へトラフィックを寄せ、ネットワーク全体の輻輳を下げる。

これらの目標は互いに緊張関係にある。スループットだけを追えば公平性を損ない、公平性だけを守ればマルチパスの利点が消える。MPTCPが結合輻輳制御(coupled congestion control)という独特の機構を導入する理由は、まさにこの均衡を取るためである。すなわちMPTCPの技術的核心は単に「経路を複数使う」ではなく、複数経路を使いつつ既存のインターネット生態系に対して公平かつ無害になるよう制御する点にある。

2. MPTCP全体構造とプロトコルスタック

MPTCPは、アプリケーションと個々のTCPサブフローの間にMPTCP層を挿入する構造である。アプリケーションは普段どおり1つのソケットに対してsend()/recv()を呼ぶが、その下でMPTCP層がデータを複数サブフローに分けて送り、受信側で再び順序どおり再組立する。各サブフローはそれ自体が完結した正規のTCP接続であり、自身のシーケンス番号・輻輳ウィンドウ・再送を独立に管理する。下の構造図はこの層関係と2つのサブフローの構成を示す。

flowchart TB
  APP["アプリケーション (単一ソケットAPI)"]
  subgraph MP["MPTCP層"]
    SCH["スケジューラ (どの経路で送るか)"]
    DSS["データシーケンス写像 (DSS)"]
    PM["経路管理者 (サブフロー生成/削除)"]
  end
  subgraph SF["サブフロー (各々が正規TCP)"]
    SF1["サブフロー1 : Wi-Fi経路"]
    SF2["サブフロー2 : LTE経路"]
  end
  APP --> MP
  SCH --> SF1
  SCH --> SF2
  DSS -. "接続レベルの順序保証" .-> SF1
  DSS -. "接続レベルの順序保証" .-> SF2
  SF1 --> NET["IPネットワーク (ミドルボックス通過)"]
  SF2 --> NET

構造の中心には2つのシーケンス空間がある。各サブフローはミドルボックスを欺くため、自身のTCPシーケンス番号をそのまま維持する。同時にMPTCPは接続レベルの64ビットデータシーケンス番号(DSN)を別途持ち、どのバイトが全データストリームのどこに該当するかを追跡する。この両者を結ぶのがDSS(Data Sequence Signal)オプションであり、「このサブフローのシーケンスXからYバイトは接続レベルのDSN Zに写像される」という写像(mapping)情報を運ぶ。受信側は複数サブフローから入り混じって届いた断片を、DSS写像に従って正しい順序に再組立(reassembly)したうえでアプリケーションへ渡す。

この二重シーケンス設計がMPTCPの真髄である。もし接続レベルのシーケンスがなければ受信側は異なる経路で届いたデータの全体順序を知れず、逆にサブフローレベルのシーケンスがなければミドルボックスが「シーケンスに穴が空いた」と誤判定して接続を切ったり改ざんしたりしかねない。2つの空間を分離することで、MPTCPはミドルボックス互換性と経路独立性を同時に達成する。主な構成要素を整理すると次のとおりである。

構成要素 役割 備考
サブフロー(Subflow) 1経路を担う正規TCP接続 独立の輻輳窓・再送
DSS写像 サブフロー ↔ 接続レベルシーケンスの写像 64ビットDSN、再組立の基準
トークン/鍵 接続識別・サブフロー認証 HMACベースのMP_JOIN検証
経路管理者 サブフロー追加/削除の決定 full-mesh、ndiffportsなど
スケジューラ パケットをどの経路で送るか決定 minRTT(既定)、BLEST、RRなど

3. 接続確立とサブフロー管理の手順

MPTCP接続は、平凡なTCPハンドシェイクにMP_CAPABLEオプションを載せることで始まる。SYN・SYN/ACK・ACKの3ウェイ過程で両者がMP_CAPABLEを交換すると互いにMPTCP対応を確認し、このとき交換した鍵で接続固有のトークンとサブフロー認証用の秘密を生成する。もし相手がMP_CAPABLEを理解できないか、途中のミドルボックスがオプションを除去すると、接続は静かに通常のTCPへフォールバック(fallback)する。この「失敗しても普通のTCPとして動く」性質が、MPTCPを安全に配備できる土台である。

最初のサブフローが立つと、以後の追加経路はMP_JOINオプションで結合する。端末が2つ目のインタフェース(例: LTE)で新たなTCPハンドシェイクを開き、MP_JOINに既存接続のトークンとHMAC認証値を載せると、相手はそれが同じ論理的接続に属する新経路であることを認証・確認して受け入れる。この認証手順は、第三者が任意に他人の接続へサブフローを差し込む攻撃を防ぐ役割を果たす。下のシーケンス図は、初期確立から2つ目のサブフロー結合、データ転送、接続終了までの流れを示す。

sequenceDiagram
  participant C as クライアント
  participant S as サーバ
  Note over C,S: 段階1 - 最初のサブフロー確立 (Wi-Fi)
  C->>S: SYN + MP_CAPABLE (鍵交換)
  S->>C: SYN/ACK + MP_CAPABLE
  C->>S: ACK + MP_CAPABLE
  Note over C,S: 段階2 - 2つ目のサブフロー結合 (LTE)
  C->>S: SYN + MP_JOIN (トークン + HMAC)
  S->>C: SYN/ACK + MP_JOIN (HMAC検証)
  C->>S: ACK
  Note over C,S: 段階3 - データ転送 (DSS写像で分散/再組立)
  C->>S: データ断片A (Wi-Fi, DSS)
  C->>S: データ断片B (LTE, DSS)
  S->>C: 接続レベルACK (DATA_ACK)
  Note over C,S: 段階4 - 終了 (DATA_FIN)
  C->>S: DATA_FIN
  S->>C: DATA_ACK

接続確立後もMPTCPは経路状態を動的に管理する。特定のサブフローを平時には使わずバックアップとしてのみ置くことを示すMP_PRIO信号、消えたアドレスを相手に知らせて該当サブフローを整理させるREMOVE_ADDR信号が代表的である。また終了は2つの水準に分かれ、個々のサブフローは平凡なTCP FINで閉じるが、接続全体は接続レベルのDATA_FINで終わるため、一部の経路が先に閉じてもデータストリーム全体の整合性は維持される。このように制御信号がサブフローレベルと接続レベルに二元化されている点が、MPTCP状態管理の特徴である。

経路の生成と消滅を決める主体が経路管理者(Path Manager)である。あるインタフェースが新たに有効化されたとき直ちにサブフローを追加するか、いくつまで置くか、切れた経路をいつ整理するかを方針として管理する。Linux実装はモジュール型の経路管理者を提供し、可能なすべてのアドレス対でサブフローを作るfull-mesh、同じアドレス対にポートだけ変えて複数フローを作るndiffportsなどが代表的である。さらに、一方が自身の持つ追加アドレスを相手に知らせるADD_ADDR信号によって、サーバ背後のNAT環境でも相手がどのアドレスへサブフローを開けるかを広告する。経路管理者の方針はスループット・電池・コスト(セルラー課金)の間のトレードオフを直接左右するため、モバイル環境では「既定はWi-Fi、切れたらLTE」のようなハンドオーバ志向の方針が、データセンタでは「利用可能な経路を全て束ねる」のような集約志向の方針が用いられる。

4. 中核機構: スケジューラ・輻輳制御

A. パケットスケジューラ

スケジューラは、毎回の送信時点で「このデータ断片をどのサブフローで送り出すか」を決める頭脳である。Linuxの既定スケジューラは最小RTT(minRTT)方式で、輻輳ウィンドウに余裕のあるサブフローのうち往復遅延が最も短い経路を優先して使う。遅延の短い経路を先に埋め、あふれたときに次の経路を使う戦略であるため、単一の速い経路の状況で不要な遅い経路の使用を抑える。

問題は経路の性能が互いに大きく異なるとき(heterogeneous)に生じる。速いWi-Fiと遅いLTEを併用すると、遅い経路で送った断片が遅れて届き、受信バッファでヘッドオブラインブロッキング(Head-of-Line Blocking)を起こす。すでに届いた速い経路の後続データが、遅い経路の前方が来るまでアプリケーションへ渡されず待機するのである。これを緩和しようとBLEST(バッファ占有予測)、ECF(Earliest Completion First、完了時刻予測)、RR(ラウンドロビン)、redundant(同一データを複数経路へ冗長送信し遅延を最小化)など多様なスケジューラが提案された。例えば遅延に極度に敏感な遠隔制御・音声トラフィックには、帯域を犠牲にしても冗長スケジューラで最短到着時間を保証する選択が行われる。

スケジューラ選択はすなわち応用特性への最適化である。大容量ファイルのダウンロードは総スループットが重要なため全経路を満たすのがよく、ビデオ会議は遅延・ジッタが重要なため安定した単一経路中心に補助経路をバックアップとして置くのがよい。1つのスケジューラがあらゆる状況で最適でありえない点がMPTCP運用の核心的難題であり、近年は強化学習に基づく適応型スケジューラの研究も活発である。

異種ネットワークを扱った近年の実験研究は、スケジューラと輻輳制御の組み合わせが性能を左右することを示す。例えばminRTT・ECF・RR系のスケジューラは結合型の損失ベース輻輳制御と組むときBLEST・LLHD系より良いスループットを出す一方、遅延の分散が極端な区間では完了時刻を予測するECFがヘッドオブラインブロッキングをより良く抑える。結局「どのスケジューラが絶対的に優秀か」ではなく「与えられた経路の組み合わせと応用要求にどのスケジューラ・輻輳制御の対が合うか」という設定問題に帰着し、この点がMPTCPを単なる機能ではなく運用力の領域にする。

B. 結合輻輳制御(Coupled Congestion Control)

各サブフローが単に独立したTCP輻輳制御を回すと、MPTCP接続は共有ボトルネックでn個の通常TCP接続のように振る舞い、他の利用者よりn倍の帯域を奪う不公平を犯す。これを防ぐためMPTCPは、複数サブフローの輻輳ウィンドウ増加を互いに連動(coupling)させ、接続全体が共有ボトルネックでおおむね通常TCP1本ほどの攻撃性しか持たないよう抑える。同時に輻輳の少ない経路のウィンドウをより大きくし、トラフィックをそちらへ自然に移す。

具体的アルゴリズムとしては、元祖格のLIA(Linked Increases Algorithm, RFC 6356)、その公平性の欠陥を改善したOLIA(Opportunistic LIA)、応答性と安定性の均衡を狙ったBALIA(Balanced Linked Adaptation)、遅延ベースのwVegasなどがLinuxカーネルに実装され、sysctlで選択できる。LIAは単純だが時に単一経路TCPに過度に攻撃的との指摘があり、OLIA・BALIAがこれを補正する。このように「経路は複数だがネットワークには1本のように振る舞わせる」ことが結合輻輳制御の本質であり、これはMPTCPがMultipath QUICなど後続プロトコルの設計にも引き継いだ重要な遺産である。

C. 受信バッファと再組立

MPTCPの体感性能は受信バッファの大きさに大きく左右される。経路間の遅延差が大きいほど、遅い経路を待つ間に速い経路のデータを収めておくバッファが大きくなければならないからである。バッファが不足するとヘッドオブラインブロッキングがひどくなり、マルチパスがかえって単一経路より遅くなる逆効果が生じる。したがって実務では経路特性(帯域・遅延)を考慮して受信バッファを十分に取り、スケジューラが遅い経路へ送る量を制限するよう調整する。この相互作用のため、MPTCPの性能は「経路数を増やせば線形に良くなる」ではなく、スケジューラ・輻輳制御・バッファが共に噛み合ったシステム最適化問題として扱うべきである。

直感的な数値で見ると理解しやすい。おおまかな算定式として、必要な受信バッファは総帯域 × 最大経路RTTの水準となるべきである。例えば100Mbps Wi-Fi(RTT 20ms)と50Mbps LTE(RTT 80ms)を併用するなら、合算150Mbpsを最も遅い80msの間収容するには約150Mbps × 80ms ≈ 1.5MB程度のバッファが要る。カーネル既定値(数百KB)では不足し、遅い経路が届くたびに転送が止まる現象が現れる。これが「LTEを足したらかえって遅くなった」というよくある誤解の実際の原因である。したがって異種経路を束ねる際にはバッファの引き上げとともに、利得のない遅い経路はスケジューラがバックアップとしてのみ使うよう抑える設定が併せて必要である。

5. 単一経路TCP・Multipath QUICとの比較

MPTCPを通常のTCPと分ける決定的な違いは経路移動性である。通常のTCPは4タプルに縛られインタフェースが変わると接続が切れるが、MPTCPはサブフローを足し引きして接続を維持する。その結果、Wi-Fiの陰影地帯を通りLTEへ切り替わっても映像ストリームが途切れない。ただしMPTCPはこの利点を無償では得られない。ミドルボックスがオプションを除去するとフォールバックせねばならず、2つのシーケンス空間と再組立ロジックで実装複雑度とバッファコストが増す。

QUICのマルチパス拡張との比較は近年の重要な出題・実務論点である。QUICはUDP上で動作しコネクションID(Connection ID)で経路を識別するため、IPが変わってもハンドシェイクなしで接続を継ぐコネクションマイグレーションがプロトコルに内蔵されている。一方MPTCPはTCP生態系との互換性が強みだがミドルボックス干渉に弱い。すなわち「既存インフラとの互換(MPTCP)」と「暗号化されたUDPベースの柔軟性(QUIC)」という異なる設計哲学の産物として理解すべきで、両者は競合であり相互補完の関係にある。下の表は中核的差異を比較したものである。

区分 単一経路TCP MPTCP Multipath QUIC
経路数 1本に固定 複数サブフロー 複数経路
インタフェース切替 接続切断 サブフローで維持 コネクションマイグレーション
ミドルボックス互換 高い オプション除去時フォールバック UDP遮断時に脆弱
暗号化 任意(TLS) 任意(TLS) 既定で内蔵
再組立コスト 低い 高い(二重シーケンス) 中程度

6. 深化: 標準・実装動向と実務適用事例

標準面でMPTCPはRFC 6824(v0)からRFC 8684(v1, 2020)へ改訂され、オプション形式とフォールバック処理が整備され、サーバ側配備を助ける0-RTT TCP Converter(RFC 8803)のようなプロキシ標準も出た。Linuxは長く外部パッチ(multipath-tcp.org)としてのみ提供されたが、カーネル5.6(2020年3月)から正式にアップストリームへ統合され、モジュール型の経路管理者・スケジューラ・輻輳制御を既定で提供するようになった。これはMPTCPが研究段階を越えて汎用オペレーティングシステムの標準機能として定着したことを示す里程標である。

最も広く知られた商用事例はAppleのSiriである。Appleは2013年のiOS 7からSiriトラフィックにMPTCPを適用し、Wi-Fiとセルラーを行き来(switching)して応答遅延とネットワーク失敗を減らした。注目すべきは、Appleの初期適用が帯域を合わせる「ボンディング」ではなく、途切れなく経路を切り替える復元力中心だった点である。その後AppleはiOS 11で開発者APIを開き、Maps・Music・Apple PayなどへMPTCP利用を拡大した。

国内の代表事例はKTのGiGA LTEである。KTはサムスン電子と共同開発し、2015年6月、3バンドCA LTEとGiGA Wi-FiをMPTCPで束ねて理論上最大1.17Gbpsを提供する世界初の商用サービスを披露した(実演では最大約835Mbps、平均600〜700Mbps水準)。KTのIETF発表資料によれば、LTEを主サブフロー(MP_CAPABLE)、Wi-Fiを補助サブフロー(MP_JOIN)とし、端末と通信事業者網の間にMPTCPプロキシゲートウェイを配置して、サーバがMPTCPを知らなくてもボンディング効果を出すようにした。Appleの「切替」事例と異なり、これは帯域集約(bonding)に焦点を当てたもので、同じMPTCPでも適用目的によって設計がどう変わるかを示す良い対比である(ただし一部の二次資料はSOCKSプロキシベースの説明をしており、詳細アーキテクチャは資料ごとに差がある)。

想定される出題方向としては「MPTCPの3つの設計目標と結合輻輳制御の必要性を論ぜよ」「MPTCPとMultipath QUICをミドルボックス互換性・マイグレーションの観点で比較せよ」「モバイルハンドオーバとデータセンタボンディングそれぞれに適したMPTCP経路管理者・スケジューラ方針を提示せよ」などが有力である。

7. 考慮事項および示唆

  • 適用戦略(目的別の方針分離): MPTCPは「すべての経路を常に束ねる」画一的適用より、モバイルは復元力(ハンドオーバ)中心・データセンタはスループット(ボンディング)中心に経路管理者とスケジューラを分離設計してこそ効果が大きい。セルラー課金・電池を考慮し、平時はWi-Fi、有事にLTEへ切り替える方針がモバイルで現実的である。
  • トレードオフ(性能 ↔ 複雑度・バッファ): 経路を増やしても線形には速くならない。経路間の遅延偏差が大きいとヘッドオブラインブロッキングと再組立コストが利得を相殺するため、受信バッファのサイジングと遅い経路の抑制調整が先行せねばならない。異種経路ではむしろサブフロー数を減らす方が良いこともある。
  • ミドルボックス・配備可能性: オプションを除去・変形するファイアウォール・NAT環境ではMPTCPが通常のTCPへフォールバックする。終端サーバがMPTCP非対応という現実を踏まえ、通信事業者網内のMPTCPプロキシ/コンバータを置くアーキテクチャが商用配備の中核パターンである。
  • セキュリティの観点: MP_JOINのHMAC認証でサブフローハイジャックを防ぐが、ADD_ADDRスプーフィング・クロスパス攻撃などマルチパス特有の脅威が存在する。経路別のTLS終端暗号化と結合し、接続レベルの完全性を併せて確保せねばならない。
  • 展望・連携技術: マルチパスの設計思想はMultipath QUICへ継承・拡張されており、5G・Wi-Fi 7の多重接続、ATSSS(5Gの多接続トラフィック操舵)、SD-WANの経路ボンディングとも緊密に連携する。暗号化転送が標準になる流れの中で、MPTCPとMultipath QUICの役割分担が今後の核心的争点である。

参考資料

一言まとめ: MPTCPは既存TCPオプションにDSS写像・MP_CAPABLE/MP_JOINを載せて複数経路を1つの論理的接続に束ねるトランスポート層拡張であり、スループット・復元力・輻輳分散を結合輻輳制御で公平に達成しつつ、ミドルボックスフォールバック・ヘッドオブラインブロッキング・バッファコストの限界をプロキシ・スケジューラ・バッファ調整で補い、Siri(切替)・KT GiGA LTE(ボンディング)の事例とMultipath QUICへとつながる。