Skip to content

Latest commit

 

History

History
337 lines (247 loc) · 18.3 KB

minutes.md

File metadata and controls

337 lines (247 loc) · 18.3 KB
Raw

ゲーム業界におけるリアルタイム通信プロトコルの 最適な選択肢を探るラウンドテーブル

CEDEC 2023 "ゲーム業界におけるリアルタイム通信プロトコルの 最適な選択肢を探るラウンドテーブル" の議事録です

★ : 当日出た意見(会場・配信・Xでのコメント)
● : 議事録記載時(竹原)の追記・回答・補足

議題以外に関する内容

当ラウンドテーブルの目的

リアルタイム通信で使用されるプロトコルについて情報交換を行い、業界全体でリアルタイム通信の品質向上を目指す。

取り扱う内容

“プロトコル”にフォーカスをあてて議論を行う。

  • RFCが策定された標準プロトコル
  • 標準の拡張プロトコル
  • 準標準(draft止まりの)プロトコル
  • オープンではあるものの非標準のプロトコル
  • 各社で独自拡張を行っているプロトコル

取り扱わない内容

  • ネットワークの接続性に関する問題
    • “ゲーム・エンタメネットワーク接続性課題検討WG”へ
  • スケーラビリティ等のサーバ運用に関する話
  • ロールバック等の同期に関する技術

情報共有の場を用意

Discord → https://discord.gg/n45aCcd7Cj
ゲーム業界におけるリアルタイム通信プロトコルについて情報共有する場。 参加自由。

1. ベストプラクティス

独自のプロトコルの採用・実装事例やノウハウ、ユースケースの共有を行う。

TCP拡張事例

リアルタイムサーバー Erlang/OTPで作るPubSubサーバー で RTT 計測用に TCP を拡張した事例。

  • QUICには標準でRTTに関する仕様がある
    • min_rtt: 最小RTTの推定値
    • smoothed_rtt: RTTの指数加重移動平均
  • 例 : Cloudflare – quiche の場合以下を取得可能
    • min_rtt/smoothed_rtt/latest_rtt/rtt_variance
  • 詳細は RFC 9002 - QUIC Loss Detection and Congestion Control 参照
      1. Estimating the Round-Trip Time

gRPCベースの独自OSSを作成

gRPC(HTTP/2)により以下のメリットを得た事例。

  • Webの標準に乗っかり易い
    • クラウドサービスのサポート
    • ロードバランサーの対応
    • Envoyなどのミドルウェアの利用
    • Observabilityのための監視システム
  • アプリケーション構成が単純化された
    • API・リアルタイム通信をHTTP/2で統一

SCTPを拡張した独自プロトコルの実装

  • UDP上にSCTPを拡張したプロトコルを実装
    • 業務用/家庭用/スマホ対応のネットワークライブラリ
    • 各種リアルタイム対戦ゲーム向け
  • ★ 18 年くらい前に業務用のネットワークゲームのリアルタイム性を高める為に作ったもの
    • サーバ - クライアントモデル
    • 元々業務用のゲームは光同期通信ベースだったがインターネット上の通信を行う為に必要になった
    • SCTP over UDP の選択理由
      • SCTP ベースにしたのは送信側で Byte ストリームを使いたくなかった為
        • パケットレベルで自分でサイズのコントロールをしたかった
        • SCTP は元々はストリームしかないので、生パケットを投げるようなことはできないのでそこを拡張している
      • UDP 上に SCTP を構築したのは疎通性の高いプロトコルに乗りたかったから
  • ★ 今だと QUIC で良いのではないか？
    • 歴史的経緯を感じる
  • ★ SCTP の疎通性の問題を回避するために UDP を使うのは面白いアプローチ
  • ★ TCP だと OS に隠ぺいされる部分があり、細やかな制御ができない、というのは QUIC や HTTP/2 標準化の際にテーマになった問題
  • ★ UDP上でSCTPを実装しているということは、その実装自体はOSSのようなものでなく自前でやっている(あくまで仕様にのっとってるだけ)でしょうか?
    • ● はい、その通りです

独自RUDPでオンライン対戦を実現

1on1のアクション対戦ゲーム

ロボット等の遠隔操作をWebRTCで実装

  • ゲーム並にリアルタイム性が要求される分野
  • 車載ネットワークもMultipath(QUIC)に積極的

2. バッドノウハウ・トラブル事例

デメリットや問題点、NATやユーザ接続環境の課題の共有。

TCP・HTTPの課題

  • 高頻度の通信を要するものには不向き
  • WebブラウザでTCPソケットを直接触れない
  • HTTPのバイトストリームの効率を念頭においた設計となっており、リアルタイム通信で使うのに向いていない
    • TCP以外でもほぼ全ての既存プロトコルが該当
  • プロトコルレイヤ目線での複雑化
    • IPv4をIPv6通信上にカプセルした環境(特に日本)
  • 解決策の独自のプロトコル設計も課題がある
    • 疎通性の問題や移植性等で維持に大きな労力が必要
  • ★ 「高頻度の通信を要するものには不向き」は具体的にはどういうこと？
    • 信頼性の高い通信を使うとサーバの負荷や極端に高いリアルタイム性を求める場合に厳しい、という話
    • 本日の午前の Diarkis さんの講演時例にも同様の課題を踏んだ話があった
  • ★ Nagle を切ればとりあえず TCP でもリアルタイム通信に耐えられる
  • ★ ブラウザとおしゃべりしたいのか？問題
    • DirectSocket API というものがあるが Sandbox 環境でしか動かない
    • この先 WebTransport が来ると改善するかも？
  • ★ UDP の疎通性の問題
    • モバイルも含めて 9 割くらいは通るのを確認しているが、1 割通らないので結局 TCP にフォールバックしている
    • TCP にフォールバックして耐えうるゲーム性なのか、というのも一つのポイント
      • ゲーム性遅延が発生する方が有利なケースがある
  • ★ TCPやHTTPのデメリットとして、P2Pでの通信に向かないというもありそうでしょうか?(NATトラバーサルできるのか?)
    • ● 技術的には NAT トラバーサルできないこともないので、 P2P 以外の側面でのデメリットの方が大きいと感じています
  • ★ 独自プロトコルに設計したつもりが、別の制限をかけられるようなプロトコルとヘッダーの一部が一致して ISP やキャリアにドロップされるケースもある
    • ● こういった問題が起こるのも、独自拡張プロトコルを辞めて標準化されたプロトコルに乗りたい大きな理由の一つだと思います
  • ★ 昨今の土日の夜は 1% のパケロス環境も多くあるので TCP だと 2 秒に一回画面が一瞬止まるレベルになり困る
    • ● 最近はマンション等国内でも環境が悪化してきているので対策を

ゲームエンジンが積極的でない

疎通性

  • HTTP/3の採用
    • HTTP/2, HTTP/1へのフォールバックも必要？
      • UDPの疎通性
      • HTTP/3にサーバやFW、中継器等が非対応
    • 1-3全てに対応したClientが必要？
  • FW設定とプロトコル
    • 設定を厳しくしてしまい特定PFでのみ通信できない

UDPのパフォーマンスが出ない

Can QUIC match TCP’s computational efficiency?

  • UDP のスループットが TCP の 1/5 問題
    • 5万/s はいける
  • fprof でプロファイリング
    • send が遅い
      • port_command で非同期にしたら解決
    • gen_udp/tcp:send がボトルネックなときにやること
    • 10万/s 出た

到達保証とリアルタイム性のトレードオフ

  • 到達保証とリアルタイムのどちらを優先するか
    • 操作についてはロールバック・補完等対応技術がある
    • 映像・音声の場合は品質を落とすのか遅延させるのか

ゲームエンジンのヘッドレスビルド vs ゲームエンジン外での通信フレームワーク

  • ゲームエンジン外の通信フレームワークを採用
    • ゲームエンジンに結びついた機能を活用できない
    • 実装の制約や実装コストの増大
  • ゲームエンジンのヘッドレスビルド採用
    • サーバーとして開発し辛い (複雑なビルドプロセス)
    • ライブラリが少ない
    • パフォーマンスに問題がある

WebSocketでのトラブル事例

WebSocketを採用したゲームで、バックエンドへのリソース管理に影響があり(ライブラリのコネクションプール管理と相性がよくなかった）、同時接続数を伸ばせなかった。

3. 技術トレンド

ゲームに適用可能なプロトコル仕様・拡張情報や業界外の技術動向・応用できそうな技術の共有。

時代はQUIC？

  • RUDP vs QUIC
  • WebTransportも気になる
    • よりゲームに特化したプロトコルの模索
      • 例 : netcode.io
    • 当ラウンドテーブルを通じた活動の最終目標！！
  • ★ QUIC を使ってもゲームの場合改ざん対策で自前の暗号化が必要か
    • 経路の暗号化とデータの暗号化は異なるので必要
  • ★ QUIC に強制再送機能を付けてくれればゲームで使いたいが検討されているか？
    • 検討されていない
    • 必要としているのがゲーム業界だけの可能性
    • トランスポートレイヤーでの実装 vs アプリケーションレイヤーでの実装で Web 側の標準化に入れるのは厳しそう
      • 正しくゲーム業界向けの仕様が必要な理由
  • ★ P2P で使う場合の懸念点はあるか？
    • 提案資料が出てきたくらいの段階(温度感は低め)
    • QUIC の TLS ハンドシェイクをする部分があるが、無視すればいいので UDP の P2P とあまり変わらない
    • Connection Migration はできない
      • 都度 NAT 越えをしなければいけないのはこれまでの UDP と同じ
  • ★ ゲーム業界に特化したプロトコルを提案する動きはありますか？
    • 動きはないが需要があれば後藤が頑張ります
    • ステークホルダーが乗り気になってこれ大事だよね、という機運が高まればもっていける
      • 例えば、動画配信を QUIC でやりたいというのを Twitch が出している

QUIC Datagram

  • 信頼性の低い通信を行う為のQUIC拡張
    • フレーム単位で再送の有無を指定可能
    • 輻輳制御等はQUICベースで動作
  • RFC 9221で標準化済み
  • 数多くのOSSで対応済み
  • QUIC Datagram の解説書あります → https://booth.pm/ja/items/2015228
  • ★ QUIC Datagram で再送を無しにした場合のストリームとの関係がよく分からない
    • QUIC Datagram はあくまで Frame レイヤーの定義
    • QUIC ストリームには紐づかない
    • ● 当日フレームにフラグを付けると言いましたがトランスポートパラメータにフラグを付けるの間違いです (max_datagram_frame_size)
  • ★ QUIC Datagram は再送はしないが ACK は誘発する
    • ACK を使用してパケロス率を見て挙動を変える等しても良い
    • 全く見ずに捨てても良い

Multipath

  • 複数の経路を用いて安定した通信を実現する
    • 特に無線環境でのリアルタイム通信で有用
    • ゲーム業界外の方が比較的熱量が高い？
    • コンシューマにおいてもプロユースでは有用？
  • 対応プロトコル
  • ★ ゲーム用途でマルチパスをする場合に帯域とか気にならないものか？
    • ● 経路が異なる(例えば Wi-Fi と 5G)のでクライアントの帯域については気にならないと思います
      • サーバ側も正しくマルチパス対応している場合は影響は薄いという話なのですが、この辺り自分の理解が浅めです
  • ★ QUIC の Connection Migration とどちらがゲーム向きか？もしくはそもそも目的が異なるか
    • ● Connection Migration は経路が切り替わった際にコネクションが切れないようにする為の技術なので、 Multipath とは目的が異なります(若干 Multipath 側が包含していますが)
      • 一般的に使えるのであれば Multipath の方がゲーム向けと言えますが、実装状況的に実用段階に入るのはまだまだ先になると思います

Bonding

  • 複数の物理I/Fを一つの論理I/Fとして結合
  • 携帯回線ベースのソリューションが増加傾向
    • 例 : LiveU(NTT)
    • 屋外からの映像中継時に活用
    • 携帯回線をBondingしてその上に再送制御や誤り訂正を乗っけている

4. セキュリティ

セキュリティ課題・解決策、安全性に配慮したプロトコル選定方法に関する共有。

暗号化の必要性

  • 座標等のセンシティブじゃない情報のみが詰まってるメッセージ等は暗号化が不要か
  • 一部のリアルタイム通信フレームワークはメッセージ単位で暗号化の有無を切り替えられる
  • ★ QUIC を最近追えていないのですが、到達保証有り無し・順序保証有り無し・暗号化有り無しは今どれくらい柔軟性があるのか？
    • 暗号化無しはできない
      • 標準化としては暗号化無しはサポートし辛い
      • 更に QUIC はプロトコル設計的に暗号化を抜くのは厳しそう
      • 竹原が QUIC ではなくゲーム業界向けのプロトコルが必要だと考えている理由もここにある
    • ● 到達保証、順序保障有り無しは前述の QUIC Datagram を使うと可能です
  • ★ QUIC において暗号化の切り替えが難しいのは TLS が下層に組み込まれているというのも一因か？
    • QUIC のパケットの組み立てが暗号化と密結合している感じ
  • ★ 暗号化しないと CPU 負荷的に厳しい等、実際に困った例があれば知りたい
    • データ側で暗号化しているから不要、と割り切るケースもゲーム業界ではある
      • 雑に XOR で暗号化を行うようなケースもある
      • 下記の「安全性が定量的に評価されたアルゴリズムを用いる」という観点からも併せて考えるのが重要
  • ★ モバイルの場合クライアントは解析される前提なのでどこまで厳しくすべきか悩ましい
  • ★ IP 切り替わっても接続維持する関係上、むしろ接続の本人性を確認するために暗号化は必須にしている

ゲームに求める暗号化

WAF(Web Application Firewall）

  • HTTP/2,HTTP/3のWAF対応状況が気になる
  • ★ HTTP/2 はぼちぼち対応が増えてきているが HTTP/3 はまだまだの状況
    • HTTP は通っても Datagram は通らないというようなケースも多そう