PR

Rakuten WiFi Pocket 5GでUDPは通る?STUN実測とNATタイプの限界

Rakuten WiFi Pocket 5GのIPv4・UDP STUN実測。GoogleとCloudflareへ各10要求がすべて成功し、往復中央値は50.1msと49.5ms。2026年10月30日18時06分の測定。ゲーム機のNATタイプと対戦は未検証。 モバイルルーター

広告:本記事にはアフィリエイト広告が含まれます。

実測日時:2026年10月30日18:06:41〜18:06:57(日本時間)/楽天最強プラン/Rakuten WiFi Pocket 5G/Windows PC・2.4GHz接続

Rakuten WiFi Pocket 5Gの回線でUDP通信は往復できるのか。今回はこのWindows PCからGoogleとCloudflareのSTUNサーバーへ各10回、合計20回の要求を送信した。20回すべてで要求と対応する成功応答が返り、往復時間の中央値はGoogleが50.1ms、Cloudflareが49.5msだった。

確認できたのは、特定の外部サーバーにこちらから送った小さなUDP要求と、その返信が通ったことだ。SwitchやPS5のNATタイプ、ポート開放、ゲームのマッチング成功を実証した結果ではない。この記事では実測の範囲と、ゲーム利用を判断するときに残る確認事項を分けて説明する。

ネット上の疑問:楽天のポケットWi-FiでNATタイプが厳しくなる?

楽天モバイルコミュニティには、Rakuten WiFi Pocket PlatinumでSwitchの接続テストがNATタイプCとなり、ゲームのマッチングに困ったという2024年10月3日の相談がある。投稿者はiPhoneのテザリングでは結果が異なったとも述べている。相談の原文(楽天モバイルコミュニティ)

相談はPlatinumについての体験で、今回測った5Gとは別機種だ。今回のPC試験でその相談の障害を再現・解決したわけではない。「UDPで要求と返信が通るか」という基礎部分を実測し、それとゲーム機のNAT判定を同じ結果として扱わないことを重視した。

STUN応答の実測結果:2宛先とも10回すべて成功

Googleのstun.l.google.com:19302とCloudflareのstun.cloudflare.com:3478に、IPv4・UDPでSTUN Binding Requestを送った。Googleの宛先はWebRTC公式サンプルの既定値、Cloudflareの宛先は同社公式ドキュメントで公開されているものを使った。WebRTC公式サンプル、サンプルの既定サーバー定義、Cloudflare公式のSTUN接続先

接続先 成功数 往復時間の中央値 最小〜最大 時間切れ/その他の失敗
Google/UDP 19302 10/10 50.1ms 39.8〜93.8ms 0回/0回
Cloudflare/UDP 3478 10/10 49.5ms 41.5〜105.0ms 0回/0回

全20応答で、成功応答の種別、メッセージ長、固定の識別値、要求と応答のトランザクションIDを照合した。IPv4形式のXOR-MAPPED-ADDRESS属性も全20応答に含まれていた。これはSTUNサーバー側から見えるアドレスとポートを通知する属性であり、その有無を確認した。個別のアドレスや割り当てポートは記事には載せていない。

表の往復時間は、PCの測定プログラムがUDP送信を呼び出してから、対応する応答を受信するまでの時間だ。DNSの名前解決時間は含めず、サーバーの処理やPCの実行待ち等は含まれる。ICMPのPing、ゲーム内のPing、片道の遅延とは異なる。

10組の要求で記録した往復時間

各組で2宛先へ並列に要求を送り、各応答を待ってから次の組まで1.5秒空けた。5組目の後には接続経路の再確認を挟んだため、厳密な等間隔の連続監視ではない。

要求の組 Google Cloudflare
1 50.4ms 46.3ms
2 49.8ms 49.4ms
3 50.9ms 49.6ms
4 53.0ms 51.8ms
5 45.7ms 105.0ms
6 41.5ms 41.5ms
7 39.8ms 44.9ms
8 59.1ms 57.1ms
9 49.1ms 46.8ms
10 93.8ms 91.9ms

今回は要求が3秒の待機上限を超えた例も、形式不一致の応答もなかった。ただし、各宛先10回の短い観測であり、「常に損失ゼロ」「一日中安定」といった評価はできない。2社で経路やサーバー処理が異なるため、この差で片方のサービスが優れているとも結論しない。

STUN成功と、NATタイプ・ゲームの接続成功が別である理由

STUNの仕様RFC 8489は、STUNをNAT越えのために用いる道具として定義している。外部から見えるアドレスやポートを知るために使える一方、STUN単独でNAT越え全体を解決するものではない。RFC 8489:STUN仕様

今回の相手は、PCが先に要求を送ったSTUNサーバーだ。別の対戦相手から通信が届くか、P2Pの通信経路を確立できるかは試していない。送信元や宛先を変えたNATのマッピング・フィルタリング挙動の分類も行っていないので、対称型NAT等の種類を推定する根拠にもしていない。

さらに、今回の測定では要求ごとに新しいUDPソケットを作って閉じた。同じソケットを複数サーバーで比較するNAT挙動調査ではなく、STUNの返信を受け取れることの確認だ。Switch・Switch 2・PS5は使用しておらず、ゲーム機独自のNATタイプの文字・数字をこの値から割り当てることはできない。

ゲームの接続で困った場合に確認したいこと

実際のゲーム機の接続テスト結果、遊びたいゲーム、発生するエラーコードを確認し、メーカーの案内と照合する。任天堂はNATタイプC・Dの場合の案内で、ゲームやP2P通信に影響するサービス内容がないか、インターネット接続事業者へ確認する方法を示している。また、ネットワーク環境によってはルーター設定を変更しても接続できない場合があるとしている。任天堂公式:NATタイプC・Dの対処方法

今回の試験では、DMZ、UPnP、ポート転送、IPv6、ファイアウォール等の設定を変えていない。これらの変更でゲームがつながるようになるかも未検証だ。STUNが返ったことを理由に、ゲーム目的の契約や設定変更が必ず成功すると案内することはできない。

測定条件と通信量

Windows 11 Pro、Intel Dual Band Wireless-AC 8265、2.4GHz・802.11n・チャネル6で実施。送受信リンク速度は144.4Mbps、開始時の信号表示は97%、RSSIは−24dBmだった。開始時、5組目の後、終了時の3回、同じ楽天ルーターへの接続とIPv4・IPv6の既定経路がWi-Fiであることを確認した。携帯回線側で4G・5Gのどちらを使用していたかは未確認だ。

各要求のSTUNメッセージは20byte、各応答は32byteだった。20要求の送信は合計400byte、受信は合計640byte。これはUDPに載せたSTUNメッセージ自体の量で、UDP・IP・Wi-Fi等のヘッダー、DNS、他の通信は含めていない。my 楽天モバイルの使用量と同じ数値ではない。

1要求あたりの待機上限は3秒で、再送は行わない単発の測定とした。STUNクライアントの再送や認証等の機能をすべて実装・検証したものではない。最初の要求から最後の応答までは約16秒、接続確認等を含むプログラム実行は約20秒だった。測定ログは2026年10月30日のもので、記事の公開日と区別している。

今回確認していないこと

IPv6のSTUN、UDPの大きなデータ転送、持続的な負荷や長時間の安定性は未検証。ブラウザーのWebRTC候補収集、TURNの中継、VPNの接続、オンラインゲーム、音声・ビデオ会議の実利用も行っていない。PCの背景通信や他の接続機器は統制していない。

今回の結果が示すのは、この日時・接続条件で、2つの宛先へのIPv4・UDPの小さなSTUN要求と返信が成立したことだ。TCPやHTTPの試験だけでは扱っていなかった通信方式を確認できたが、任意のUDPポート、任意のサービス、外部からの新規接続を保証する結果ではない。

よくある質問

Rakuten WiFi Pocket 5GでUDP通信は通った?

今回のPCでは、GoogleのUDP 19302とCloudflareのUDP 3478へのSTUN要求が各10回、すべて成功した。確認した宛先・方式に限る結果だ。

STUNの往復が約50msならゲームも快適?

この数値はSTUNサーバーとの往復時間だ。ゲームのサーバーや相手、パケットの量が異なるため、そのままゲームの快適さには置き換えられない。実際のゲームは試していない。

NATタイプAやポート開放を確認できた?

確認していない。ゲーム機の接続テスト、外部からの新規接続、NAT挙動の分類は実施していない。

関連する実測レビュー

送受信速度と負荷時Pingは総合実測レビュー、IPv4・IPv6のHTTPS転送はIPv4・IPv6比較、Windowsの接続判定はWindows NCSIの実測で確認した。各記事は測定日時・方式が異なり、以前の値を今回の新規実測として使っていない。

コメント

タイトルとURLをコピーしました