UDPホールパンチング
NATを使用したプライベートネットワーク内のホスト同士が、インターネットを経由して双方向にUDPコネクションを確立するための仕組み アルゴリズム
https://gyazo.com/dfa266b5de4e4c409ecd8a2fbec81641
Wikipedia の例より引用
AとBというホストが、それぞれのプライベートネットワークにあるとする。
N1とN2はそれぞれのNATデバイスである。SはグローバルIPアドレスを持つパブリックサーバである。
1. A と B は S との UDP 通信を開始する。NATデバイス N1 と N2 は UDP 変換状態を作成し、一時的な外部ポート番号を割り当てる。
A は S に対して自信のプライベートネットワークから外部にUDPで通信する
この時自身のプライベートネットワークから出ていくときにNATデバイス(ルーター)N1を通過する
N1はAからのパケットを宛先であるSに送ってそのレスポンスを受けられるよう、一時ポート(エフェメラルポート)を割り当てる
SはN1を経由してAに対して通信する経路を宛先IPとN1が割り当てた一時ポートの番号を知っている
Bも同様にSに対してUDPでの通信を行う
Aのときと同様の内容が B のネットワークであるNATデバイス N2 でも起こる
S は B に対して通信する経路である宛先IPとN2 が割り当てた一時ポートの番号を知っている
2. S はそれらのポート番号を A と B にリレーして通知する。
S は A に対してBの宛先IPと一時ポートを、Bに対してはAの宛先IPと一時ポートの情報を引き渡す
このあとの通信にSは介入する必要はないので最低限の機能であればこれで役目はおしまい
3. A と B は相手のNATデバイスと通知されたポート番号で直接通信する。NAT デバイスはそれ以前に生成されていた変換状態を使い、A および B の間でパケットの送受信が可能になる。
A、Bは Sから渡された相手の宛先IPと一時ポートを知ることになるのでUDPでの通信が可能になる。
なんでTCPじゃないのか？
同様の技法をTCPコネクションにも適用する場合があるが、成功率は遥かに低くなる。何故なら、TCPではコネクションのストリームは応用プログラムではなくホスト OS が制御しており、順序番号がランダムに生成されるので、順序番号を検査するような NAT デバイスは、パケットを既存のコネクションに結び付けることが出来ずに破棄してしまうからである。
単純に「できなくはないがコネクションの確立の成功率がUDPのそれに比較して低いから」ということらしい。
※あんまり得意な分野ではないので間違っているかもしれない