2023年秋 中村研 WIP発表資料

Transcript

1. Using QUIC to Traverse NATsの実装 Arch B1 Kota
2. 概要 現在IETFで議論されているドラフト「Using QUIC to Traverse NATs[1]」にて提案さ れている、QUIC上でNAT越えを⾏いP2P通信を確⽴する2つの⼿法を実装し、QUIC への理解と実装⼒を深める 2
3. 背景と⽬的 • 従来のP2P通信のほとんどはUDPで⾏われている • 2021年にQUICプロトコルのバージョン1が公開され，普及してきている • P2P通信を扱うアプリケーションは特に，コネクションマイグレーションなど接続の継続性を持つ QUICの恩恵を受けやすい • Using QUIC to traverse NATsでP2P通信 over QUICの⼿法が⼆つ提案された • しかし現状それらの実装が存在しないため，本稿で実装を⾏う • 将来的にQUIC周りのプロトコル開発に関わるための知識と実装⼒をつけるという⽬的も含む 3
4. 先⾏事例 4 • Interactive Connectivity Establishment (ICE) [2] ◦ UDP上のP2P通信において、最適なアドレスとポート、NAT越えの⼿順、失敗時のフォール バックなどを定義したプロトコル • TCP Candidates with ICE [3] ◦ TCP上のP2P通信におけるNAT越えの⼿法 • P2P QUIC [4] ◦ QUIC上でICEプロトコルを作るためのドラフト ◦ 今⽉ドラフトとしては期限切れになった
5. 提案されている⼿法 Using QUIC to traverse NATsで提案されている以下の⼆つの⼿法を説明する 1. ICEプロトコルを⽤いてP2P通信を確⽴し、その上でQUICのセッションを確⽴する 2. QUICのみを使ってP2P通信を確⽴する 5
6. ⼿法1: ICEプロトコルを⽤いて接続を確⽴する 6 ICEプロトコルでまずUDP上でP2P通信を確⽴する • NATデバイスの背後にあるA,B • 仲介サーバーを通して候補となるアドレス (Candidates)を交換する • 交換したCandidate全ての組み合わせに対して接 続確認を⾏い、最適なペアを決定する • 最適なペアが決定したらそのアドレスでP2P通信 を確⽴する
7. ⼿法1: ICEプロトコルを⽤いて接続を確⽴する 7 ICEプロトコルはUDPベースであり、同じくUDP ベースであるQUICはICEで確⽴されたP2P通信をそ のまま利⽤することができる メリット • 既存のICEプロトコルの実装が使える • QUICの拡張ができない環境などで使える デメリット • 接続確⽴までに時間がかかる
8. ⼿法2: QUICのみを使って接続を確⽴する 8 • 仲介サーバーとの通信もQUICを⽤いる • 通信プロトコルが変わっただけで、最適な Candidateペアの選択アルゴリズムや交換の ⼿順はICEを踏襲する ◦ ICE over QUICとも⾔える
9. ⼿法2: QUICのみを使って接続を確⽴する 9 • ペアの接続チェックに関しても、QUICハンド シェイクの⼀部であるPath Validationを利⽤ する 接続チェックとハンドシェイクを併せて⾏うことで ⼿法1に⽐べて接続確⽴が早くなる • Path Validationが完了したらそのままハンド シェイクの続きを⾏う ※本稿ではこの全ての実装が終わらなかったので⼿法2のうち の⼀部の実装に⽌まっている
10. 実装: ⼿法1 10 ICEプロトコルで確⽴したP2P通信をQUICに再利⽤するためにはUDPソケットを再利⽤する 必要がある • aioiceの実装を、接続が確⽴されたソケットを外部ライブラリに渡せるように変更した • aioquicの実装も、外部からあらかじめ作ったソケットを引数として渡せるように変更した • aioiceを⽤いてP2P通信を確⽴し、そのソケットを再利⽤してaioquicでQUIC通信を確⽴した 使⽤した⾔語: Python 使⽤したライブラリ: aioice(ICEの実装), aioquic(QUICの実装)
11. 実装: ⼿法2 11 • aioquicの実装変更 ◦ ⼿法1同様、外部からソケットを引数で渡せるように変更する ◦ サーバー側からもPath Validationを⾏えるように変更する • ICEプロトコル全てを実装することができなかったため、アドレス、ポート決め打ちでPath Validationを⾏う部分を今回の実装範囲とした
12. 実験 12 • ⼿法1, 2の実装を実際にローカルネットワーク内にある⼆つのピアで実⾏してみる • ⼿法1に関しては通信確⽴までの速度の計測も⾏った ◦ 最初のサーバーを送る前にタイムスタンプをスタートして計測した 実⾏環境 • ピア1: Mac OS 13.5 (Ventura) • ピア2: Ubuntu OS 18.0.4 on Compute Engine • 仲介サーバー: Heroku22 (Ubuntu 22.0.4) ピアのNATタイプはどちらもAddress-restricted NAT (⼀度送信先になったIPアドレスのパケットは受け⼊ れる)
13. ⼿法1の実験 13 • STUNパケットを⽤いた接続性チェックの後，QUICでのハンドシェイクが始まり，その後通信が確 ⽴されている • 30回実⾏したところ，通信確⽴にかかった秒数は平均約5.35秒，ICEは約4.80秒 ◦ UDPでのP2P通信に⽐べて⼿法1は0.5秒ほど遅くなる
14. ⼿法2の実験 14 • サーバー側の NATマッピングがなされていない最初の数回の接続試⾏はDestination unreachable で 失敗している • その後NAT 越えが成功し，通信が確⽴している
15. 今後の計画 15 • ⼿法2: ICE over QUICの実装 ◦ 実際にQUICの上にICEプロトコルを実装し、接続確⽴まで⾏う ◦ ⼿法1と速度、接続性、成功率について⽐較する • 評価 ◦ 他プロトコル（TCP/UDPなど）でのNAT越えとも同様に⽐較する • QUICの上に乗る他プロトコルの実装 ◦ 今回のaioquicの拡張実装を利⽤して他のQUICとP2Pに関するプロトコルやアプリ ケーションの実装を進める
16. 結論 16 • QUIC上でP2P通信を確⽴する⼿法はこれまで仕様として提案されておらず、Using QUIC to Traverse NATsで初めて提案された • 提案されている⼿法の実装はまだ公開されていなかったため、今回QUICへの理解の向上 も兼ねて実装を⾏った • 提案⼿法に完全に沿った実装は間に合わなかったが、QUIC上でのP2P通信は確認するこ とができた • 提案されている2つの⼿法の⽐較や定量的な評価は今後⾏っていく
17. 参考⽂献 17 [1] Marten Seemann. Using QUIC to traverse NATs. October 2023. [2] A. Keranen, C. Holmberg, J. Rosenberg. Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal. RFC8445. July 2018. [3] J. Rosenberg, A. Keranen, B. B. Lowekamp, A. B. Roach. TCP Candidates with Interactive Connectivity Establishment (ICE). RFC6544. March 2012. [4] Peter Thatcher. P2P QUIC. July 2023.
18. appendix: ⼿法2の実装（WIP版） 18 サーバーがまず接続試⾏しNATマッピ ングしておく その後クライアントから接続試⾏する と通信が可能になる 4.1. Gathering Address Candidates The gathering of address candidates is out of scope for this document. Endpoints MAY use the logic described in Sections 5.1.1 and 5.2 of [RFC8445], or use address candidates provided by the application.