CEDEC 2025 『ゲームにおけるリアルタイム通信への QUIC導入事例の紹介』

CEDEC 2025 にて講演した『ゲームにおけるリアルタイム通信への QUIC導入事例の紹介』の資料です。
※講演者メモ付きの資料を入手したい場合は CEDiL (https://cedil.cesa.or.jp/cedil_sessions/view/3064.html) より .pptx をご入手ください

株式会社セガ 開発技術部 竹原 涼
株式会社セガ 開発技術部 藤村 隆史
株式会社セガ 第２事業本部第４事業部 松崎 大

1. ゲームにおけるリアルタイム通信への QUIC導入事例の紹介 株式会社セガ 竹原 涼 松崎 大 藤村 隆史
2. ➢ 撮影・SNS投稿OK ➢ 後日CEDILで資料を公開 ➢ 質疑はAsk The Speakerにて • 資料に記載されている会社名、システム名、製品名、サービス名は各社の登録商標または商標です
3. ➢ TCPやUDP等の従来のプロトコルを改善 ➢ UDPベース ➢ 2021年5月27日にRFC 9000として策定 ➢ 最新のHTTPバージョンのHTTP/3でも採用 QUICの概要 HTTP/3 QUIC UDP
4. ➢ Head of Line Blocking (HoLB) ➢ IP アドレス変更時等ハンドシェイクやり直し ➢ パケットロス検出の仕組みがイマドキではない ゲームにおける問題点(TCP, HTTP) 例 : HTTP の Head of Line Blocking
5. ➢ 順序保証や暗号化の拡張を行う場合は自前 ➢ 標準プロトコルが無い ➢ 多くの場合TCPを併用になり実装が煩雑になる ➢ 輻輳制御の仕組みがない ゲームにおける問題点(UDP)
6. QUICを使えば解決(？)
7. 1. QUICの仕様やユースケースの共有 2. Sonic Rumbleの事例紹介 3. “SPHINGO” およびその採用タイトル事例紹介 4. 社内の取り組みの紹介 目次
8. 自己紹介 技術本部 開発技術部 竹原 涼 【登壇歴】 CEDEC 2023 「CRI ADXプロファイラー活用によるサウンドQAの自 動化・可視化に関する取り組みの紹介」 CEDEC 2021 「ダウンロード時間を大幅減！～大量のアセットをさば く高速な実装と運用事例の共有～」 CEDEC 2021 「Android iOS 実機上での自動テストをより楽に有意義 にする為に ～端末管理・イメージ転送・動画記録等の周辺情報のノウ ハウ共有～」 リアルタイムプロトコル趣味勢
9. 「ゲームならでは」の視点に フォーカスした QUICの仕様やユースケースの共有
10. QUICのゲームに適した仕様
11. ➢ Connection Migration ➢ ストリームレイヤーのHoLBの克服 ➢ パケロス耐性の向上 ➢ TCPベースの機能を搭載 ➢ ユーザランドでの実装 ➢ TLSを統合 ゲームに適した仕様 HTTP/3 QUIC UDP TLS 1.3
12. ➢ コネクションをIDベースで管理 ➢ IPアドレス・ポート変更時に維持可能 ➢ パス検証 (切り替え時のネットワークの検証) ➢ パスが有効か ➢ セキュリティ検証 Connection Migration (概要) 家庭用 スマホ
13. スマホや携帯機のネットワーク切り替わり時にも そのままゲーム可能 ➢ Wi-Fiからキャリア(4G,5G) ➢ 4G ← → 5G Connection Migration (影響) 家庭用 スマホ Wi-Fi 4G 5G 帰宅/フリースポット 等で切り替わる 移動中等に不安定に なることがある
14. 事例紹介は “SPHINGO” およびその採用タイトル事例紹介 にて実施 Connection Migration (事例) 家庭用 スマホ
15. QUICのゲームに適した拡張
16. ➢ QUIC Datagram ➢ QMux (QUIC On Stream) ➢ WebTransport ➢ Media over QUIC Transport (draft) ➢ WebSocket over HTTP/3 QUICのゲームに適した拡張
17. An Unreliable Datagram Extension to QUIC ➢ QUICの到達保証(再送)を無くす拡張 ➢ ACKは返る ➢ UDPに近い運用が可能になる QUIC Datagram (概要) 家庭用 スマホ クライアント サーバ ACK ACK ④ (③は再送しない) Datagram ① ② ③
18. ➢ リアルタイム性が特に高いものにも採用可能に ➢ 到達保証が必要な場合にもQUICで実装を一本化 ➢ TCPやRUDP等と併用実装しないでよくなる ➢ RFC発行済み (9221) QUIC Datagram (影響) 家庭用 スマホ
19. 事例紹介は後段の Sonic Rumbleの事例紹介 にて実施 QUIC Datagram (事例) スマホ 家庭用
20. ➢ 非UDPのQUIC互換レイヤーを用意する提案 ➢ TCP等との並行実装が不要になる可能性 ➢ まだ提案段階なのでこれから ➢ interim-2025-quic-01資料 QMux (QUIC On Stream) 家庭用 スマホ Application protocols (e.g. MoQ) UDP QUIC QMux Any reliable stream transport QUIC stream semantics
21. QUICユースケース
22. ➢ HTTP/3 ➢ HTTP/1.x,2をHTTP/3へアップグレード ➢ HTTPをAPIに採用しているゲームは多い API通信への利用 家庭用 スマホ HTTP/3 QUIC UDP
23. ➢ WebSocket over HTTP/3 ➢ RFC 9220で仕様策定済み ➢ RPC over HTTP/3 ➢ gRPCにも適用されている実装がある API通信への利用 家庭用 スマホ HTTP/3 QUIC UDP WebSocket RPC
24. ➢ UDPの代替 ➢ 輻輳制御等のUDPに無い仕様の獲得 ➢ QUIC Datagramで近い動きが可能 ➢ RUDPの代替 ➢ 独自実装を標準仕様に置換できるのは大きなメリット ➢ 時世的に暗号化無しは許容できなくなりつつある リアルタイム通信への利用 家庭用 スマホ
25. ➢ DTLSの代替 ➢ DTLSは2022/4にRFC9147にてついに標準化 ➢ 長らく各自で独自実装する形だった ➢ OpenSSL 3.0等主要なOSSが対応済み ➢ (資料公開後追記)上記誤りがあったので次ページにて訂正してあります ➢ RUDPへの適用については引き続き独自実装 リアルタイム通信への利用 家庭用 スマホ
26. ➢ DTLS自体は2006/4にRFC4347にて標準化済み ➢ RFC 4347: Datagram Transport Layer Security ➢ 2022/4にRFC9147で標準化されたのはDTLS 1.3 ➢ RFC 9147: The Datagram Transport Layer Security (DTLS) Protocol Version 1.3 ➢ DTLS 1.2 : RFC 6347: Datagram Transport Layer Security Version 1.2 ➢ 実装状況 ➢ OpenSSL : DTLS 1.2までの対応で1.3は実装中 ➢ BoringSSL : DTLS1_3_VERSION の定義があるので1.3まで対応してそう ➢ WolfSSL : 1.3まで対応済み DTLS現状(補足)資料 家庭用 スマホ
27. ➢ HTTP/3 ➢ HTTP/2同様の多重化を用いたダウンロードが可能 ➢ HTTP/3のメリットも享受 ➢ アプリケーションレイヤーの実装変更は不要 データダウンロードへの利用 スマホ
28. UnityでQUIC・リアルタイム通信でQUIC Sonic Rumbleの事例 株式会社セガ 松崎 大
29. 松崎 大 / Dai Matsuzaki 株式会社セガ 第２事業本部第４事業部 • 1998年 セガ・エンタープライゼス入社。AM2に配属 • 2002年くらいからサーバ・通信関連の業務多めに • Google Certified Professional Cloud Developer 自己紹介
30. • Sonic Rumble • UnityでQUIC • リアルタイム通信でQUIC • まとめ 目次
31. • Sonic Rumble • UnityでQUIC • リアルタイム通信でQUIC • まとめ 目次
32. • 最大32人対戦 • 開発はUnity • PC・モバイル向け • グローバル展開 • サーバ・クライアント型 Sonic Rumble ©SEGA
33. • 改めてQUICとは？ • TCPに比べ低遅延な通信を実現 • 到達保証・順番保証があるUDPベースのプロトコル • 各プロトコルとの比較 Sonic RumbleはQUICを使っています RUDPの代替としてQUICを採用 I S P P P P P P P
34. 1. QUICをUnityで使うことができるか？ 2. QUICはリアルタイム通信のプロトコルになり得るのか？ 3. QUICはリアルタイム通信のプロトコルになり得たのか？ QUIC検証のプロセス
35. • Sonic Rumble • UnityでQUIC • リアルタイム通信でQUIC • まとめ 目次
36. 内製通信ライブラリ「Nemofiller」 • C#（netstandard2.1準拠）で記述 • Unity・NetCoreで動作 • S/C、S/C + P2P • Replication（オブジェクト同期） • RPC • dotnetのソケットを使用 • Unityインテグレート • UnityEditor拡張 • Unityコンポーネント • 使用OSS • Agones-sdk • cloudflare-quiche Sonic Rumbleは内製通信ライブラリを使用しています Unity ＋ Nemofiller GameServer GameClient
37. • QUICのOSSに求める機能 • ソケットが別 • 単なるQUIC変換装置 • QUICのOSSに求める必須機能 • C#、C/C++ • 対応プラットフォーム • Win/Mac/Linux/iOS/Android QUIC変換装置が欲しい UserBytes QUIC変換装置 QuicBytes dotnet-socket
38. • QUICのOSSに求める機能 • ソケットが別 • 単なるQUIC変換装置 • QUICのOSSに求める必須機能 • C#、C/C++ • 対応プラットフォーム • Win/Mac/Linux/iOS/Android Cloudflare-quiche cloudflare-quiche • 特徴 • RUSTで書かれたQUIC実装 • ソケットは別に用意 • C/C++用quiche関数（ffi） • 機能 • QUIC-STREAM（multi-stream） • QUIC-DATAGRAM • マルチプラットフォーム対応 • Win/Linux/Android/iOS ※Mac向けにもビルドできました
39. Cloudflare-quicheをC#で使う UserBytes QUIC変換装置 QuicBytes dotnet-socket Rust Cloudflare-quiche C# quic_wrapper.so C/C++ libquiche.so C++実装
40. Cloudflare-quicheをC++で組み込み実装 quiche.h を見ると結構な数の関数 https://github.com/cloudflare/quiche/blob/master/quiche/include/quiche.h サンプルを見ると結構な組込み実装が必要 https://github.com/cloudflare/quiche/blob/master/quiche/examples/server.c https://github.com/cloudflare/quiche/blob/master/quiche/examples/client.c • C#<->C++の行き来は少ない方が良いのでは… • サンプルを見る限りC#よりもC++で書いた方が楽そう… quiche関数の組み込み実装はC++で Rust Cloudflare-quiche C# quic_wrapper.so C/C++ libquiche.so C++実装
41. Cloudflare-quicheをC++で組み込み実装 組込み 関数 I 変換装置 つの アと く 理を実装 つの を管理 理を実装 数の を管理 S
42. • 動作確認プラットフォーム • Win（x86-64） • Mac（Apple Silicon） • Linux（x86-64） • iOS • Android • UnityEditor（Win/Mac） • 気になること • マルチプラットフォーム対応時のビルド・動作チェックが大変 • netstandard2.1準拠で書かれたQUIC実装が欲しい… UnityでQUIC（Cloudflare-quiche）
43. • Sonic Rumble • UnityでQUIC • リアルタイム通信でQUIC • まとめ 目次
44. TCP vs UDP vs QUIC QUICはリアルタイム通信のプロトコルになり得るのか？
45. • 計測のスペック • 100msec毎にメッセージを送信＆サーバはエコーバック。クライアント側で RTT値を計測 • 送信メッセージサイズは128byteと1024byte • 各プロトコルで計測。TCP / UDP / QUIC-STREAM / QUIC-DATAGRAM • サーバのスペック • EKS（with Agones） • eu-west-3(paris) / us-west-1(oregon) / ap-northeast-1(tokyo) • c6i.large • NemofillerのRtcServer（リアルタイムサーバ） • クライアントのスペック • 自宅（有線, auひかり10G, 東京） • ThinkPad P1 Gen5（i7-12800H） • NemofillerのRtcClient（リアルタイムクライアント） TCP vs UDP vs QUIC：計測スペック
46. TCP vs UDP vs QUIC：計測結果(128byte) QUICとUDPのRTT値はニアリー TCPは大きく乖離
47. TCP vs UDP vs QUIC：計測結果(128byte) QUICとUDPのRTT値はニアリー TCPは大きく乖離
48. TCP vs UDP vs QUIC：計測結果(128byte) QUICとUDPのRTT値はニアリー TCPもニアリー
49. TCP vs UDP vs QUIC：計測結果(128byte) QUICとUDPのRTT値はニアリー
50. TCP vs UDP vs QUIC：計測結果(128byte) QUICとUDPのRTT値はping値とニアリー RTT平均値とping計測値の比較 P P I S I G
51. TCP vs UDP vs QUIC：計測結果(1024byte) TCP以外は128byte時の結果とほとんど同じ
52. TCP vs UDP vs QUIC：計測結果(1024byte) TCP以外は128byte時の結果とほとんど同じ RTT平均値とping計測値の比較 P P I S I G
53. • QUICは距離に応じた適切な通信速度が担保されやすい • QUICは通信データサイズの影響を受けにくい • QUICはUDPよりも高機能かつ同等の通信速度 QUICはリアルタイム通信のプロトコルになり得る QUIC-STREAMはTCPやRUDPの代替になり得る TCP vs UDP vs QUIC：まとめ
54. Sonic Rumbleでの実測値を検証 QUICはリアルタイム通信のプロトコルになり得たのか？
55. • QUIC-STREAMを使ってRTT値を計測している • 定期的な生存確認通信にてRTT値を計測 • 次回生存確認通信にて計測値をサーバに送信 • サーバ側でログに出力 • ゲームプレイ中に計測 • ゲーム内のメッセージと同じストリームを使用 • ゲームサーバクラスタは北米西海岸に設置して運用 • アプリ配信地域はアジア・南米・欧州・中東・カナダ Sonic Rumbleでの実測
56. Sonic Rumbleでの実測：任意プレイヤのRTT値 揺らぎはあるものの、割と安定したRTT値
57. Sonic Rumbleでの実測：任意プレイヤのRTT値 理論値とニアリーなRTT値 実測値と理論値の比較 トルコ ブラジル ーストラリア ア リ S ス ー ラ ス 値実 値 ～ ～ ～ ～ ～ ～ ～ 値理論値
58. Sonic Rumbleでの実測：RTT値の国別分布 距離に応じたRTT値になっている
59. 多人数接続・高頻度通信下において以下を確認 • 揺らぎはあるものの、割と安定したRTT値 • 理論値と乖離が少ないRTT値 • 距離に応じたRTT値 QUICはリアルタイム通信のプロトコルになり得た Sonic Rumbleでの実測：まとめ
60. • 内製通信ライブラリ • マルチプロトコル • サーバ・クライアントともに３ソケット • QUIC・TCP・UDPを使用可能 • Sonic Rumble • RELIABLE-MSGをQUIC-STREAM • UNRELIABLE-MSGをQUIC-DATAGRAM とある事情でTCP・UDPを使う事例が出てきた Sonic Rumbleはマルチプロトコル UNRELIABLE-MSG RELIABLE-MSG QUIC-STRM QUIC-DGRM UDP TCP
61. • Sonic Rumbleでの懸念 • UDPが通り難い地域があるとの噂 • グローバル展開だから心配との声 • 対応 • QUICで接続失敗後はTCPへフォールバック • 結果 • フォールバック発生率は平均0.014% • 発生地域は日によってバラバラ • UDPが通り難い云々は地域依存ではなく施設依存な印象 懸念は杞憂だった。 TCPへの ォールバックは将来的に廃止しても良いかも QUICからTCPへのフォールバック
62. • Sonic Rumbleでの問題 • Sonic Rumbleでは切断判定に至るケースが一定割合で存在していた • 調査して分かったこと • 地域・時間・端末スペック・OSには非依存だった • 該当ユーザーは再送やジッタが発生、その後切断判定に至る • Sonic Rumbleは、非効率なメッセージ送信になっていた • まとめ 理が効き らい送信 • 通信量の割にパケット数が多い パケット数の多さに起因した通信経路上の機器でのパケットドロップと予想 QUIC-DATAGRAMからUDPに暫定変更
63. • 方針 • ゲーム中のメッセージをなるべくまとめる • ゲームの体感を変えたくない • 対応 • QUIC-DATAGRAMからUDPに変更し、ACKの分をまるっとカット • 結果 • 切断判定の件数が減少 • その後体感を変えない範囲でメッセージをまとめ、切断判定の件数は更に減少 パケット数の多さが原因だった。 QUIC-DATAGRAMに戻すことを検討中 QUIC-DATAGRAMからUDPに暫定変更
64. • Sonic Rumble • UnityでQUIC • リアルタイム通信でQUIC • まとめ 目次
65. • QUICはリアルタイム通信のプロトコルになり得る • QUIC-STREAMをTCP・RUDPの代替として使うのはあり • QUIC-DATAGRAMにはACKが存在する • UDPと同じ感覚で投げるとパケット数が増える点は留意 • ACKのON-OFF機能や頻度制御機能などが欲しい • draft-ietf-quic-ack-frequency-11 - QUIC Acknowledgment Frequency • Unity + QUIC、非C#なOSSを使ったことで保守が結構ツライ • マルチプラットフォーム対応はそれなりに大変 • netstandard2.1で書かれたQUIC実装がとても欲しい まとめ
66. 社内製リアルタイムネットワークライブラリ SPHINGO 及びその採用タイトルの事例 株式会社セガ 藤村 隆史
67. 株式会社セガ 技術本部 開発技術部 藤村 隆史 1994年 セガ・エンタープライゼス入社 第二AM研究開発部で業務用ゲーム開発 2000年頃 DC 用インターネット通信対戦ゲーム作成 その後業務用ゲーム基板用システムやドライバ開発業務も並行 2008年頃よりネットワーク系ライブラリ開発、サポート系業務に軸足を移し今 に至る 自己紹介
68. • クライアントサーバ型リアルタイムネットワーク通信ライブラリ • 実装は C/C++ • ～数十プレイヤー間の信頼性あり・なし混在での疑似マルチキャス ト同報通信、ユーザによるサーバ内 理をサポート • TCP および UDP上にSCTPベースの独自プロトコルを個別選択 • 約 20 年の歴史があり、社内外の多数タイトルで採用、現在も改良 やサポート継続中 “SPHINGO” の紹介
69. • ゲーム中通信のリアルタイム性能の要求度合い – 最高 対戦格闘等、基本は P2P – 高 アクション系ゲーム(～ 数10mS) • 最大レイテンシ限界（～ 250mS 程度） ここでの「リアルタイム」の定義 – 低 さほどアクション性を要求しない 許容遅延時間
70. • Connection Migration を手軽に導入したい – ある採用タイトルで、クライアントの接続回線が切り 替わった際における自動復旧のニーズ • 独自プロトコルは維持管理工数がかかるため標準的なプ ロトコルを選択肢に加えたい ⇒既存環境への導入のしやすさ、導入時期における機能 実装の比較結果として chromium-quiche を利用 QUIC 採用のきっかけ
71. 機能互換レイ ヤ実装および テスト導入 JAIPA WG で 検証 マイグレー ション性能の 向上 タイトルへの 導入 QUIC 導入までの流れ
72. • ESCTP/U 既存実装と QUIC の違い • QUIC ESCTP/U QUIC 信頼性のない通信 マルチチャネル(独自拡張) DATAGRAM(RFC9221)(1つ) 信頼性のある通信 メッセージ指向 ストリーム指向 認証・暗号化 部分的に有効(独自) 接続全体(TLS) 接続の管理 通信相手のアドレスおよび ポート Connection Id コネクションマイグレーション その他 独自実装 (RFC2960,3309を基に) RFC9000(8999-9002等) 互換機能実装 とテスト導入
73. • 数チャネルへの対応 – もともと TCP を使う場合のためにあった MUX/DEMUX 実装を応用 ⇒ 但し信頼性が無い通信であるにも関わらず存在する ACK が冗長、という部分は未解決 QUIC Datagram の扱い 互換機能実装 とテスト導入
74. • リアルタイム通信ではバイトストリームより シーケンスパケット的な通信が多い 出来ればパケット単位で不可分な通信をしたい – QUIC の場合はミドルボックスでの操作可能性が低い • 送信側実装の工夫でメッセージ指向っぽくできる ⇒ストリームの伝送効率とは相反 QUIC Stream の扱い 互換機能実装 とテスト導入
75. 機能互換レイ ヤ実装および テスト導入 JAIPA WG で 検証 マイグレー ション性能の 向上 タイトルへの 導入 QUIC 導入までの流れ
76. • JAIPA「ゲーム・エンタメのネットワーク接続性 課題検討WG」 – ゲームやエンターテイメント等コンテンツのネット ワーク疎通性の課題を業界横断的に検討するWG – 2019 年から活動 – 2022 年に QUIC 通信でのルータセッションテーブル 枯渇の可能性検討から開催の QUIC 検証会に、この 実装のプロトタイプを持ち込み動作検証 JAIPA WG での接続性検証 JAIPA WG での 接続性検証
77. • [送信] DATAGRAM 30pps, STREAM 1pps, 300 bytes/packet • [受信] DATAGRAM 90pps, STREAM 3pps, 300 bytes/packet (MAX) JAIPA WG での接続性検証 クライアント (/w Wi-Fi キャプチャ) L2 Switch Mirror Mirror 無線(/w有線) LANルータ LAN1 (Wi-Fi) パケットキャプチャ CPE サーバ #1 #2 #3 #4 WAN LAN2 (Wired) JAIPA WG での 接続性検証
78. • 検証結果の概要(弊社分) – 動作中のマイグレーションでは、必要以上に通信アド レス、ポートの組み合わせを使用することは無かった （実装に く） – マイグレーションに成功した場合でも、マイグレー ションにかかった時間が長いと送受信バッファ溢れ起 因での切断があった JAIPA WG での接続性検証 JAIPA WG での 接続性検証
79. 経路変更にかかった時間と通信継続について JAIPA WG での接続性検証 ⇒ この時の送受信バッファ量だと不通時間として 0.6 秒前後しか余裕がないことが判る JAIPA WG での 接続性検証 クライアント クライアント クライアント クライアント 続 時間 続 時間 続 時間 続 時間 無線 有線 有線 無線 無線 有線 有線 無線 無線 有線 有線 無線
80. 機能互換レイ ヤ実装および テスト導入 JAIPA WG で 検証 マイグレー ション性能の 向上 タイトルへの 導入 QUIC 導入までの流れ
81. • QUIC は通信経路の切り替えに配慮のあるプロト コル（というだけ） – 実際にはプロトコルを用いた通信の具体的な 実装がポイント 想定はしていたものの結構面倒 マルチP/F対応 マイグレー ション改良
82. • 切断時や通信異常時に既に切り替え先が存在す る場合の Write-Error 挙動等 – 主に Winsock 系実装と BSD Socket 由来の実装の差 異や、 BSD Socket 由来でもエラーの扱いには環境 によって差異がある Socket I/F の異常時挙動の違い マイグレー ション改良
83. • 統一したインタフェースが無い • 「接続環境が変わった」という定義が一意では ない Ex) default_route が変わった? 新しい I/F が見つかっ た? DNSが切り替わった? 外のアドレス宛ての通信成 功? キャプティブポータルは? 下層の接続環境の変化を知る マイグレー ション改良
84. レスポンス良く知ることができる環境 – Windows, MacOS, iOS, Linux, Android, BSD系 等 • カーネル通知をコールバックやイベント、ソケッ ト等で知ることができる 但し方法はまちまちかつ不確実なのでいくつかの手法を 併用 下層の接続環境の変化を知る マイグレー ション改良
85. 自分で変更をポーリングする必要がある環境 – 先ほど挙げていない環境の多く • 自分で /etc 以下の各種システムファイル変更をイベント等 で知るかポーリング • (POSIX には含まれていないが) getifaddrs(3) などをポー リング この環境の場合、低負荷低遅延で知る方法が無い 下層の接続環境の変化を知る マイグレー ション改良
86. • マルチパスベースの実装 – 新たな経路の発見と同時に疎通性検証 (有効な経路の個数の socket を同時に使う) – 通信エラーが発生したら既に発見済みの他経路でパス 検証 – 一定時間切り替えができなければ切断 (問題点) 数経路に同時通信発生の可能性と、リ ソースを必要以上に消費 逐次切り替えとマルチパス マイグレー ション改良
87. • 逐次切り替え実装 – 通信エラーが発生したら OS からの有効な経路出現情 報を元に切り替え(socket 作り直し) – パス検証 – 一定時間切り替えができなければ切断 (問題点) 切り替え毎にレスポンス低下 ⇒こちらの実装を採用 逐次切り替えとマルチパス マイグレー ション改良
88. • 一般的な接続環境 – 物理的には • Wi-Fi / キャリア回線 / 有線 LAN – 論理的には • Server IPv4 で 数の移行技術環境(DS-lite, MAP-E, 464XLAT, ...) • Server IPv6 でも場合によって 数の通信環境 これら間のマイグレーション動作確認は大変 ⇒ 開発初期では Wi-Fi 同士や Wi-Fi⇔Wired 等に絞って実験 Connection-Migration のテスト マイグレー ション改良
89. 機能互換レイ ヤ実装および テスト導入 JAIPA WG で 検証 マイグレー ション性能の 向上 タイトルへの 導入 QUIC 導入までの流れ
90. • 30秒間隔で100クライアントを接続・切断した際の負荷比較 既存実装とのCPU 理負荷比較 タイトル への導入 時間 理 サーバ
91. • 30秒間隔で100クライアントを接続・切断した際のメモリ比較 既存実装とのメモリ使用量比較 タイトル への導入 メ リ 時間 メ リ サーバ
92. • Connection-Migration 件数 / 接続数 = 331 / 17561 (日) マイグレーション件数事例 タイトル への導入 時 コネクションマイグレーション
93. • QUIC はリアルタイム通信でも既存実装に近い性能 • QUIC Stream をバイトストリームではない扱いをした い場合は送信側実装で工夫 • Connection-Migration はゲームジャンルによっては使 えるがクライアント側の環境により異なる実装対応が必 要、またテスト環境の組み合わせ規模が課題 まとめ
94. 社内の取り組みの紹介
95. • 専用のチャットルームを作成し情報交換 • QUICの社内勉強会等も実施 社内の取り組み
96. 業界全体でも知見を共有していきましょう！ リアルタイム通信の情報をもっと知りたい……！！
97. ご清聴ありがとうございました 質疑はAsk The Speakerにて