MRU : Monobit Reliable UDP ～5G世代のモバイルゲームに最適な通信プロトコルを目指して～

■ Monobit Reliable Udp β版（MRU) 詳細
MRU : Monobit Reliable UDP
〜5G世代のモバイルゲームに最適な通信プロトコルを目指して〜
• モノビットエンジン取締役CTO
• 中嶋謙互
• Twitter @ringo
• https://github.com/kengonakajima

■ Internet Protocol Stack
https://www.w3.org/People/Frystyk/thesis/TcpIp.html
ハードウェア
1個1個のパケットを
マシンまで届ける
マシンの中のプロセスや
ソケットにデータを届ける
それぞれのアプリケーション

■ IPv4, IPv6の基本動作
引用元: atmarkit

■ WeBの発達
• インターネット黎明期: 1994年より前
– サーバーのリモート操作(telnet/ssh)や電子メール、FTPのために、データを正しい順序
で確実に届ける方法が必要だった。 TCPがこのために普及し、標準になった。
• ウェブ普及期: 1994年〜2005年
– TCPの上に実装されたHTTPがウェブの発展を支えた。
• モバイル普及期: 2005年〜
– 特にモバイルにおいて、HTTP(TCP)の遅さやIPアドレス変化が問題になった。
– WebSocketのようなつなぎっぱなしアプリではさらに問題が悪化した。
• TCP限界期: 2012年〜
– TCPを今さら捨てることはできないので、UDPをうまく使って、TCPの問題を解決する
ための挑戦が始まった。 Google社がSPDYを提案した。その後QUIC、HTTP3と概念と
仕様の発展が続く。

http://itpro.nikkeibp.co.jp/atcl/column/17/040400119/040400003/
■ TCP改善の歴史
• 1981年の使用開始から現在に至るまで改善の連続。。！

■ TCPの時代分け
• 1980年代 : TCP登場、telnetでマシンを遠隔操作
• 1990年代 : メールやHTTPなどで大ブレイク
• 2000年代 : モバイルで長時間のストールを防ぎたい！
• 2010年代 : 動画や音声を高速送信したい!

■ ゲームにおける通信の歴史
• シリアル通信時代: 1990年台前半まで
– ゲームの通信は、RS-232Cを使ってPCを接続してローカルマルチプレイを行うことが多かった。
• PCマルチプレイ発展期: 1990年台後半
– Windows95以降はソケットライブラリを使えるようになり、IPv4/UDPを用いてマルチプレイを実装するのが普通に
なった。パケットの順序制御や再送を行うロジックは、ゲームごとに作っていた。MMOでは、TCPもよく使われるよ
うになった。
• ゲーム機でも通信: 2000年〜
– PS2のネットワークアダプタなど、ゲーム機でもIPv4で通信ができるようになった。UDPを使うことが多かった。
UDPとTCPの併用。
– スマホ以前の携帯電話ではUDPが使えないこともあった。
• モバイルゲーム時代: 2010年〜
– スマホが一般化し、IPv4/IPv6上でUDP/TCPを用いて自由にマルチプレイを実装できるようになった。
– UDPの再送や順序制御用のライブラリがオープンソースで利用可能になった。
ゲームは最初からUDPと友達であった

■ TCPとUDPのでどちらををつかえばいいの？
• TCPはどんどん良くなり続けてきた
• TCPはとても使いやすくアプリのバグを減らせる
。ゲームでもできればTCPを使いたい。でもTCP
はストールするから。。
• ネットワークプログラマは何十年も迷っている

■ TCPがどうしても解決できない問題
• ストリームが1本しかない : head-of-line
blocking
• IPアドレスの変化に対応できない

■ TCP: head of line blocking
TCP
こんなふうにしたい
packet1の影響で、全体が長時間ストールする
packet1はストールするがpacket2,3は早く届く
packet1の再送
packet1の再送

■ TCP: IPアドレスの変化に対応できない
TCPのヘッダ
送り元のIDがヘッダに含まれていないので、
TCPはIPアドレスを使って送り元を識別している。

■ インターネットの性能
• パケットロス率
– 有線LAN : スイッチとケーブルがちゃんとしてたら、ほぼ0だが
、完全に0ではない
– 無線LAN : 負荷がないときでも10000個に1個ぐらい消える。負
荷が高いと、100個に1個消えるときもある
– モバイルネットワーク : 電波がいいときでも100個に1個消える
かも、電波が悪いと1割消えたりする

■ 1990年代からのゲームにおける解決策
• 信頼性を保証しないUDPを使うのでOK。最初からUDP。
– ただし、どうしても確実性が必要なデータだけ、再送の工夫を
追加して対処する。
– 確実さが必要な例：ショップでの売買。1回しかやらないから
。
– 確実さが不要な例：モブの座標。何度も送り続けるので、1個
消えても、後のやつが届いたらいいから。

■ RUDP (Relible UDP)
• UDPに信頼性を追加した通信プロトコル
• ビデオゲームでは、1990年代から、各ゲー
ムで独自に実装していた。
• Webでは、2012年ごろから、Googleが主導
して、QUICの標準化が進められている。

■ RUDPの実装
• ENet (2004~) MRSでも採用している。少人数用
• LiteNetLib(2016~) ピュアC#実装
• netcode.io (2016~) C, Glenn Fiedler氏による
• quicly (2017~) C, QUICのドラフト15？
• gQUIC : GoogleのQUIC実装、最新版ドラフト＋実験用
• iQUIC : IETFのリファレンス実装
• ほかにも用途に合わせて、数え切れないほどある

■ MRU : Monobit RUDP
• C++(ほぼC)
• IPアドレス変化への対応
• 正しい順序で送る
• 確実に送る (早めの再送)
• 順序も確実さも保証しない方法で送ることもできる
• 0RTTハンドシェイク
• チェックサム
• C10K以上のMMO向けにチューニング(少人数ももちろんOK)
• スロット飽和攻撃対策
– IP偽装対策
– 大量接続対策
• Linux/Windows/iOS/Android/MacOSに対応、ゲーム機は対応予定
• 実装していない機能
– ストリーム内の多重化チャネル (ゲームでは必要性が薄いため)
– 暗号化(MRSのレイヤで実装するため)

■ MRU: IPアドレス変化への対応
• MRUでは、すべてのパケットに、送り元ID(64bit)と送り先ID(64bit)が付加されているので、IPアドレ
スが変わっても、接続のやりなおしが不要で、0RTT(往復時間ゼロ)で通信が継続できる。
• IPv6からIPv4に変わっても問題なし。 (iOSでのNAT64にも対応)

■ MRU: 順序制御と再送制御
• TCPを単純にしたものでだいたい同じ
– 受信側でパケットをキューにためて順番どおり取
り出す(詳細は省略)
• QUICにはない「早めの再送」を実装している。
– データをあえて2回(設定次第でN回)づつ冗長に送
って、
再送の必要性自体を無くす

■ MRU: 早めの再送
早めの再送なし
早めの再送あり
1が消えたので再送が必要!
2,3はストールしている
1が消えたが、次のパケットに1が
含まれている。再送の必要なし
※IP/UDPのヘッダが48バイトあるので、
ゲームのデータが小さい場合は、送信量は単純
に2倍にはならない

■ 0RTTハンドシェイク
https://jacobianengineering.com/blog/2016/11/1543/
1RTT
(Round Trip Time,
往復時間)
2~3RTT
MRUはこれ

■ MRU: チェックサム
• CRC32を使っている
• ON/OFFができる。OFFにすると少し軽い。
• サーバ間通信ではOFFでOK

■ MRU: MMO向けのチューニング
• Linux カーネル3以降で追加された
send/recvmmsgシステムコールを使用。
– Linux以外ではsendmsgを使用
• カーネルコールオーバーヘッドを減らしている
• クラウドインスタンスでも効果を発揮している。
• 測定値は後述

■ MRU: IPアドレス偽装攻撃への対応
• IPアドレス偽装とは
– 典型的なDDoS攻撃であるスロット飽和攻撃
で使われる。使われていないIPアドレスを送
り元に設定したIPパケットを送って、サーバ
ーの接続スロットを飽和させる。

■スロット飽和攻撃 (IP偽装なし)

■スロット飽和攻撃 (IP偽装あり)

• 1秒あたりの接続回数が設定値を越えたときは、攻撃防御モードに入る。
• 攻撃防御モードでは、0RTTハンドシェイクをやめて、3Wayハンドシェ
イク(1RTT)を採用する。このとき、サーバのメモリを確保しない。
• 3Wayハンドシェイクでは、サーバーが発行した予測できない鍵(32ビッ
ト値)をクライアントに送り、それを返したクライアントだけ、メモリを
確保する。
サーバークライアント
接続要求
鍵
ここではメモリを確保しない
ここでメモリを確保する
鍵
※TCPの SYN クッキーとだいたい同じ
■MRU: IPアドレス偽装攻撃への対応

• IPアドレスを偽装しなくても、大量に接続をす
ることで攻撃ができる。
• 同じIPアドレスからの連続的な接続は設定され
た頻度以上ではできない。
■MRU: 一般的飽和攻撃への対応

低品質ネットワークのシミュレーション機能
– パケットロス率
– パケット重複率
– パケット遅延
– CRCエラー率
※TCPの SYN クッキーとだいたい同じ
■MRU:デバッグ機能

■MRU: ベンチマーク
• ハードウェア
・ニフクラ east-1
・Large8インスタンス x 2
・Intel Xeon CPU E5-2697A @ 2.6GHz
・4vCPU, 8GB RAM
・10Gbps ネットワーク(観測による)
・Linux カーネル 3.10.0, CentOS 7.6

Linux
Socket
MRU
MRS
アプリコード
libuvENet
マシン
物理層ベンチマーク
MRU層ベンチマーク
MRS層ベンチマーク
■MRU: システム階層(Linux)

• udpmax (MRUを使わない、UDP高負荷ツール)
– iperf3は性能が不足しているため、自作した
sv1 sv2
シングルスレッド
sendmmsgテスト size=1
udpmax udpmax
71万pkt/s
40Mbytes/s
sv1 sv2
4スレッド
udpmax udpmax
108万pkt/s
78Mbytes/s
udpmax
udpmax
udpmax
udpmax
udpmax
udpmax
4スレッド
70万pkt/s
1.06Gbytes/s
8Gbps出ている、速い
■物理層ベンチマーク

• udptestプログラム
– 同時接続数32768までのテストに使える
– 早めの再送 ON/OFF
– CRC ON/OFF
– エコーON/OFF
– 攻撃防御モードの閾値設定
– 送信サイズ、送信頻度設定
■MRU層ベンチマーク

sv1 sv2
udptest
udptest
シングルスレッドサーバの限界性能測定を行う。
負荷
udptest
udptest
・・・
■ベンチマーク構成

• データ受信コールバック関数の呼び出し回数を
測定する。
– 送信側でアプリケーションデータを送るとき
は、mru_peer_send(data) を1回呼び出す。
– それに対応して、受信側で受信関数が1回呼ば
れる。この1秒あたり回数を数える。
• 送信タイミングが近いと、1個のMRUパケット
に複数のアプリケーションデータが詰め込まれ
る場合がある。
■MRU層の測定内容

• 同時接続1, 間隔0.1秒、サイズ24, 早めの再送OFF
– ./udptest 10.100.xx.xx —interval=0.1 --
fast_retransmit=0 --conn=1
– 10コールバック/s
– 20pkt/s(send+recv)
– 平均パケットサイズ 60bytes
– サーバCPU : 5% (ほぼ空ループ毎秒1万回、調整可
能)
■MRU層の動作確認

• 同時接続12000, 間隔0.01秒、サイズ24,早めの再
送OFF
– ./udptest 10.100.xx.xx --interval=0.01 --
fast_retransmit=0 --conn=4000 x 3プロセス
– 108万コールバック/s
– 71万8000pkt/s (物理限界)
– 84Mbytes/s, 平均パケットサイズ 111bytes
– サーバ側CPU : 80% (1スレッド. 4vCPUなので
最大400％)
これ以上負荷をかけると、物理層が耐えられないので再送が増えすぎ、
接続が切れてエラー。
■MRU層最大帯域毎秒

• 同時接続12000, 間隔0.1秒, 早めの再送なし, エコーあ
り、サイズ1000
–./udptest 10.100.xx.xx --interval=0.1 --
fast_retransmit=0 --echo --conn=4000 --
size=1000 x 3
–39000コールバック/s
–25万pkt/s
–256Mbytes/s, 平均パケットサイズ 1026bytes
–サーバ側CPU : 70%(1スレッド)
■MRU層最大域毎秒

• mrs_bench
– MRUだけでなくTCP,ENet,WebSocket,と切
り替えて比較が可能
– 暗号化通信 ON/OFF (今回は省略)
– 受信コールバック関数の呼び出し回数を測定
する。
■MRS層ベンチマーク

• MRU, 同時接続1、間隔0.1秒、サイズ24、早めの再送な
し
–./mrsbenchcl 10.100.xx.xx 1 100 —
fast_retransmit=0
–10コールバック/s
–20pkt/s(send+recv)
–平均パケットサイズ 72bytes (MRSのヘッダ12バイト)
–サーバCPU : 6% (ほぼ空ループ毎秒1万回、調整可能)
■MRS層の動作確認

・MRU, 同時接続4800、間隔0.005秒、サイズ24、早めの再送なし echoなし
・./mrsbenchcl 10.100.102.80 1200 5 —fast_retransmit=0 x 4
・62万コールバック/s
・72万pkt/s(send+recv) 物理限73Mbytes/s
・平均パケットサイズ 100bytes
・サーバCPU : 58% (1スレッド)
■MRS層の最大コールバック毎秒(MRU)

• TCP, 同時接続2000、間隔0.005秒、サイズ24、echoなし
・./mrsbenchcl 10.100.102.80 1000 5 —tcp x 4
・69万pkt/s(send+recv) 物理限界 56Mbytes/s
■MRS層の最大コールバック毎秒(TCP)

• MRU, 同時接続3000、間隔0.01秒、サイズ512、早めの再送なし echo
なし
・./mrsbenchcl 10.100.102.80 1500 10 —fast_retransmit=0 —
size=512 x 2スレッド
・55.7万pkt/s(send+recv) 303Mbytes/s
■MRS層の最大帯域毎秒(MRU)

• TCP, 同時接続1200、間隔0.01秒、サイズ1400、
echoなし
・./mrsbenchcl 10.100.102.80 1200 10 —size=1400 x 2スレッド
・55.7万pkt/s(send+recv) 340Mbytes/s
■MRS層の最大帯域毎秒(TCP)

TCP MRU
最大コールバック回数 34万/s 62万/s
上記時点での
サーバCPU
100% 58%
上記時点での
UDPパケット数
69万pkt/s 72万pkt/s
最大帯域 340Mbytes/s 303Mbytes/s
上記時点での
サーバCPU
90% 70%
上記時点での
データサイズ
1400 (MTU合わせ) 512 (MRS現状仕様による)
シングルスレッドサーバーの最高性能を示している。

• 同時接続1万のとき、UDPはソケット1個で
よいが、TCPはソケットが1万個必要。
• 1万のソケットに対して1回のシステムコー
ルで書き込みをするAPIがLinuxでは存在し
ない。(デバイスドライバを直接叩くライ
ブラリを使えば可能)
• Linuxのシステムコールをまとめて呼び出
せるようにする議論が、カーネルメーリン
グリストで進行中。早く実現されたら素晴
らしい! (今後に期待)
■TCP性能がなぜ低いのか

• MRS側を長いメッセージに対応させる
• パケットヘッダ圧縮 (長いIDをパックする)
• さらなる高速化：ゼロコピーに近づける(MRSも)
• 暗号化する場合も0RTTにする
■MRUロードマップ

• モノビットエンジン MRS バージョン 2.0.0から
、MRUは選択可能です。ぜひお試しください!

MRU : Monobit Reliable UDP ～5G世代のモバイルゲームに最適な通信プロトコルを目指して～

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a MRU : Monobit Reliable UDP ～5G世代のモバイルゲームに最適な通信プロトコルを目指して～

Similar a MRU : Monobit Reliable UDP ～5G世代のモバイルゲームに最適な通信プロトコルを目指して～ (20)

Más de モノビットエンジン

Más de モノビットエンジン (20)

Último

Último (11)