届くこと、順番、新しさのどれを守るか——ゲームプランナーのためのネットワーク入門④

宛先と窓口の先にある、運び方の約束

第3回では、IPアドレスという宛先と、ポート番号という窓口を扱った。同じ番号でも、TCPとUDPでは別の窓口になるとも説明した。今回は、その窓口でどんな約束をしてデータを運ぶかへ進む。第1回の5段の地図では、トランスポート層に当たる。

判断軸は、 送るデータごとに、「届くこと」「順番」「新しさ」のどれを守るかを決める。TCPかUDPかは、その結果として決まる ということだ。

たとえば、キャラクターの位置が古いまま確実に届くことと、最新の位置へ早く更新できることでは、遊びへの影響が違う。一方、チャットの発言が抜けたり、購入結果が分からなくなったりする場面では、別の約束が必要になる。

TCPは「全部、順番どおり」

TCP（Transmission Control Protocol）は、届くことと順番を守る通信方式である。RFC（Request for Comments、インターネットの技術仕様などを公開する文書群）9293の2.2節は、TCPを、信頼でき、順序を保つバイト列のサービスとして説明している。バイト列とは、データをひと続きの列として扱うことだ。ゲーム内の「発言1件」などの区切りは、その上のアプリケーション側で決める。[1]

「全部、順番どおり」を守るため、途中のデータが失われれば送り直しを待つ。後ろのデータが先に到着していても、抜けた部分を飛び越えてアプリケーションへ渡すことはできない。こうした先頭側の待ちが後続を止める性質を、 ヘッドオブラインブロッキング と呼ぶ。

HTTP（Hypertext Transfer Protocol、Webの要求と応答などを運ぶ規約）の第3版を定めるRFC 9114は、第2版のHTTP/2をTCPで運ぶ場合、パケットの損失や順序の入れ替わりによって、直接影響を受けていないやり取りまで待たされると説明している。パケットとは、通信で運ばれるデータのまとまりである。[2]

ゲームに置き換えて考えると、「1秒前の位置が届くまで、今の位置も使えない」状況になりうる。これは性質を理解するための本稿の例であり、RFCに書かれたゲームの事例ではない。古い位置を全部受け取る約束が、最新の位置を使うタイミングに影響するのである。

なお、TCPが守るのは、接続が続いている間の配送と順番である。データが届いたことと、購入などの処理が成立したことは、別に確認する必要がある。

UDPは「送るだけ」から始まる

UDP（User Datagram Protocol）は、最小限の仕組みでメッセージを送る通信方式である。RFC 768は、届くことも重複を防ぐことも保証せず、順序どおりの確実な配送が必要なアプリケーションにはTCPを使うよう述べている。[3]

途中が抜けても、後から届いたメッセージを受け取れる。ただし、失われたメッセージを埋めることや、順番を整えることはUDP自体の仕事に含まれない。必要なら、その上に仕組みを作る。

ここで「UDPは速い」とだけ覚えると、引き受ける仕事を見落とす。通信が混み合う状態を輻輳（ふくそう）といい、混雑を悪化させないよう送る量や速さを調整することを輻輳制御という。UDPには、それが組み込まれていない。RFC 8085は、輻輳制御のある通信方式を選ばないアプリケーションやプロトコルに、UDPの送信速度を自ら制御するよう求めている。[4]

送信量をどう制御するかは、エンジンや通信ライブラリの選定と実装を通じて、エンジニアが判断する領域である。それでも、プランナーはその結論を握っておきたい。送信量が制御されると、回線が混み合ったときに一度に送れるデータが絞られる。そのとき、位置の更新、演出、確実に届ける通知のどれを先に送るかは、遊びの手触りに直結する。ValveのSteamworksにあるISteamNetworkingSocketsには、メッセージを「レーン」に分け、レーンごとに優先度と帯域の配分を設定する仕組みもある。[5] 何を優先して残すかを、エンジニアが判断できる材料として仕様に書いておきたい。

ゲームはUDPの上に「選べる約束」を作る

ゲームエンジンや通信ライブラリは、UDPの上に信頼性を足し、メッセージごとに配送の約束を選べるようにしている。たとえばUnity Transportは、UDPソケットなどの上で動き、信頼性、順序、分割を追加の機能（パイプライン）として選べる。[6] ISteamNetworkingSocketsも、素のUDPでの接続に対応し、受信確認と再送の仕組みを備える。[5] reliableは確実に届けるための仕組みを使う指定、unreliableは配送を保証しない指定だ。ただし、順番をどこまで保証するかは、それぞれのAPIの仕様も読む必要がある。

UnrealとUnityでは、既定値が逆になる

RPC（Remote Procedure Call）は、遠隔の相手に処理を呼び出させる仕組みである。Unreal Engineの公式資料では、RPCの既定はunreliableだ。主な用途として、一時的なゲーム内イベントや見た目の演出を挙げている。reliableを指定すると、受信確認まで送り直し、順番も保証する。その代わり、確認まで後続のRPCの実行が止まり、帯域も余計に使うため、控えめな使用を勧めている。[7]

UnityのNetcode for GameObjectsでは、RPCの既定はreliableである。公式資料は、パーティクルや効果音などの重要でない演出、1秒に何度も更新するRPCにはunreliableが向く場合があると説明する。また、reliableの順序保証は、同じNetworkObject、つまりネットワークで同期する個々のオブジェクトに対するRPCの間に限られる。異なるオブジェクト間まで、送信順どおりになるとは限らない。[8]

仕様書に「既定のまま」と書くと、エンジンによって逆の意味になる。「この通知はreliable」「この演出はunreliable」と、守りたい約束を明示したい。

reliableでも、順序を守る範囲では、確認や再送を待つために後続が待たされうる。これはTCPで見た性質につながる。ただし、待ちが及ぶ範囲まで、すべての方式で同じになるわけではない。

配送の種類を、約束として読む

UnityのNetworkDeliveryという配送指定には、次の5種類がある。表は公式APIの短い説明を整理したものである。[9]

分割とは、大きなメッセージを分けて運ぶことだ。UnreliableSequencedの説明は「Unreliable with sequencing」にとどまる。この説明だけから、古いメッセージをどう扱うかまでは決められない。

一方、設計の考え方として「古い位置の穴埋めより、最新の位置を使う」ことは選べる。先ほどの図の「最新の5だけを使う」は、その考え方を示す例である。

ISteamNetworkingSocketsも、reliableとunreliableの両方のメッセージに対応する。[5] プランナーが整理する対象は、ゲーム全体で使う方式の名前だけでなく、個々のデータに必要な配送の約束なのである。

PS3の時代にも、通信の用途で窓口は分かれていた

PS3の公式ユーザーズガイド、システムソフトウェア3.10版には、PlayStation Networkサーバーとの通信に TCP : 80, 443, 5223 と UDP : 3478, 3479 を使うとある。一方、AVチャットやオンラインゲームで他のPS3と直接通信する際のポートは UDP : 3658 と説明されている。[10]

これはPS3の当時の説明である。サーバーとの通信と、本体どうしの通信対戦で、使う窓口が分かれていた例として読める。同じゲーム機のオンライン機能でも、通信の用途ごとに運び方を考える手がかりになる。

新しい選択肢、QUIC

QUICはUDPの上に作られた通信方式である。RFC 9000のタイトルも「QUIC: A UDP-Based Multiplexed and Secure Transport」としている。[11]

特徴の一つは、複数のストリームをまたぐヘッドオブラインブロッキングを避けられることだ。ストリームとは、ひと続きのデータの流れである。パケットが失われた場合、その中にデータが入っていたストリームは再送を待つが、ほかのストリームは進められる。[11]

HTTP/3は、このQUICの上でHTTPのやり取りを運ぶ。[2] IPA（情報処理推進機構）の基本情報技術者試験シラバスVer.9.2にも、HTTP/3が用語として載っている。[12] UDPの上にも、こうした配送の仕組みを組み立てられるのである。詳細は第6回「スマホゲームのHTTP通信」で扱う。

仕様書には、データごとに守るものを書く

次の表は、架空のゲームの仕様例である。実在のタイトルの通信方式を示すものではない。

被弾や取得の結果を確実に共有したい場合も、すべてを同じreliableなRPCにするという結論には直結しない。必要な結果を共有する方法と、その通知に使う配送指定を、実装担当とすり合わせるための表である。

購入では、届くことに加えて、同じ要求を二重に処理しない設計が必要になる。この論点は「『受け取る』を一度だけにする――ゲームプランナーのための連打と通信再試行の話」で扱っている。

LANで成功した先のテストを計画する

Unityの公式資料は、LAN（Local Area Network、家庭や開発室などの限られた範囲のネットワーク）では、unreliableなパケットが失われる機会が大きく減り、ときには一度も失われないと説明する。そのため、ネットワーク状態を再現するシミュレーターでのテストを勧めている。[8]

開発室で演出が毎回届いていても、本番の回線で同じとは限らない。QA（Quality Assurance、品質保証）の計画には、通信の遅れや欠落がある条件を入れたい。位置更新が抜けたとき、演出だけが届かなかったとき、確実に届ける通知が待たされたときに、画面と進行がどうなるかを確認するのである。

仕様で決めた約束を、通信条件が悪い場面でも満たせるか。その確認まで含めると、「届くこと」「順番」「新しさ」という判断軸が、テスト項目にもつながる。

次回は、移動しながら使う回線へ

今回は、宛先と窓口が決まった先で、データをどんな約束で運ぶかを整理した。データの用途に応じて守るものを決め、配送の設定と待ちの範囲を確認することが、プランナーの使い道である。

次回、第5回は「セルラー（4G・5G）」。ここまでの話が、移動しながら使うスマートフォンの回線でどう変わるかを見ていく。

References

1. W. Eddy編「Transmission Control Protocol (TCP)」 — RFC Editor、RFC 9293、2022年8月。2.2節。

2. M. Bishop編「HTTP/3」 — RFC Editor、RFC 9114、2022年6月。1節、1.1節。

3. J. Postel「User Datagram Protocol」 — RFC Editor、RFC 768、1980年8月。

4. L. Eggertほか「UDP Usage Guidelines」 — RFC Editor、RFC 8085、2017年3月。3.1節。

5. Valve「ISteamNetworkingSockets」 — Steamworks Documentation、2026年11月1日確認。素のUDPでの接続、受信確認と再送、レーンによる優先度と帯域配分を参照。

6. Unity「About Unity Transport」 — Unity Transport 2.5 Manual、2026年11月1日確認。UDPソケットまたはWebSocketの上で動くことと、パイプラインによる信頼性・順序・分割の追加を参照。

7. Epic Games「Remote Procedure Calls in Unreal Engine」 — Unreal Engine 5.8 Documentation、2026年11月1日確認。

8. Unity「Reliability」 — Netcode for GameObjects 2.5 Manual、2026年11月1日確認。

9. Unity「NetworkDelivery」 — Netcode for GameObjects 2.0 API、2026年11月1日確認。

10. ソニー・コンピュータエンタテインメント「インターネット接続テスト」 — PS3ユーザーズガイド、システムソフトウェア3.10版、2026年11月1日確認。

11. J. Iyengar、M. Thomson編「QUIC: A UDP-Based Multiplexed and Secure Transport」 — RFC Editor、RFC 9000、2021年5月。13節。

12. IPA「基本情報技術者試験（レベル2）シラバス Ver.9.2」 — IPA、2026年1月8日掲載。

この文書は、Perplexity、Claude、ChatGPT の3つのAIの支援を受けて著述されたものです。引用画像を除き、MIT License にて提供されています。