スロットルを回避する方法は？

私はネットワーク化されたiOSゲームを書いています。でパケットを送信するときGKMatchSendDataReliable（私はどの仮定 60のパケット毎秒（隣接パケット間のように16ミリ秒）、平均ping時間でUDPを書き込む自分のパケット受信コードであった）急速に悪化：私は次々 （以下7個のゲームセンターの一致を開い）、100パケットの「フラッド」を送信しました（毎秒60パケットのレートで）。私は平均往復時間を測定しました、そしてこれらは結果です：

[ 21:16:39 ]:  I saw an average roundtrip time of 52.342787 ms, he saw 54.496590 ms
[ 21:16:34 ]:  I saw an average roundtrip time of 62.631942 ms, he saw 61.991655 ms
[ 21:16:45 ]:  I saw an average roundtrip time of 88.394380 ms, he saw 83.619123 ms
[ 21:16:51 ]:  I saw an average roundtrip time of 179.053118 ms, he saw 156.869141 ms
[ 21:16:57 ]:  I saw an average roundtrip time of 75.025076 ms, he saw 75.419723 ms
[ 21:17:23 ]:  I saw an average roundtrip time of 8832.082488 ms, he saw 7616.877558 ms
[ 21:19:33 ]:  I saw an average roundtrip time of 25088.962344 ms, he saw 16833.064914 ms

最後の2つのテスト後の結果は約1000ミリ秒です。

おそらくISPによって調整されているようです。これはiOSゲームであるため、通常の住宅用接続を使用します。

パケット送信レートを10倍遅く（つまり、160ミリ秒ごとに1パケット）に変更すると、テストにかかる時間が大幅に長くなりますが、往復時間は一貫して低くなります。

[21:31:27]：平均往復時間が55.289109ミリ秒だったのに、69.032727ミリ秒だった

そのため、接続の遅延を低く抑えたい（そしてISPによって「罰せられない」）ように見えます。送信するパケットのレートを下げる必要があります。これらは最大40バイトのような非常に小さなパケットであることに注意してください。

スロットルを回避するために1秒あたりに送信できるUDPパケットの数に関するガイドラインを探しています！どこかに一般的なガイドラインはありますか？

家庭用PCベースのアクションゲームや大きなMMOでさえ、パケットを60Hzで実行しません。さらに、パケットサイズが本当に小さいことは必ずしも良いことではありません。これらの小さなパケットのそれぞれに、送信するだけで大​​きなオーバーヘッドがあります。

クライアント側の補間を使用して、10Hzの更新を撮影してみてください。常にpingの遅延があるので、あなたはすでに補間していると思います。

MTUサイズを確認し、より長い時間枠をカバーするためにそこに多くの情報を投入します。トランスポート層の平均パケットサイズは1400程度になるため、MTUサイズを超えるとメッセージが分割され、オーバーヘッドがさらに増加し​​ます。

まず、データ全体の大きさを確認する必要があります。ISPは、データグラムの量や頻度ではなく、実際に送信されるバイト数に注意を払う可能性があります。最大（65507ペイロードoctects）サイズのデータ​​グラムを毎秒60回送信する場合、約30 Mb / sのアップストリームを送信します。誰もがそのようなつながりを持っているわけではありません。

IPヘッダーは20オクテット長であり、UDPヘッダーは8オクテット長であることを忘れないでください。これは、データグラムごとに送信する追加の28オクテットです。

接続を最大限に活用していない場合、パケットが遅延する可能性のある場所がたくさんあります。つまり、クライアントのOS、ゲートウェイ（おそらくワイヤレスルーターまたはケーブルモデム）、ISP、他のピアのISP、他のピアのゲートウェイ、特に他のピアのOS。

まだ使用していない場合は、ネットワークの問題を診断するための非常に強力なツールであるWiresharkを使用することをお勧めします。ネットワーキングに関しては、デバッガと同等のものと考えてください。

Wiresharkでネットワークトラフィックを診断する方法はいくつかあります。

• 無差別ハブを使用してモバイルデバイスと同じネットワークのPCでWiresharkを使用し、ネットワークデバイスを無差別として設定する

• PCをワイヤレスゲートウェイとして設定し、モバイルデバイスをそのゲートウェイに接続してから、そのPCでWiresharkをリッスンします

• エミュレーターと同じマシンでWiresharkを実行する

• デバイス自体でtcpdumpを実行し（Androidでは簡単、iOSでは脱獄が必要）、Wiresharkでキャプチャされたデータを読み取ります。

• まったく同じことをする単純なプログラムを作成しますが、それはPCで動作し、そこでWiresharkを使用します。

• ...その他多数

どのパッケージがいつ送信されるかを確認したいとします。たとえば、送信される前に遅延が発生した場合、OSによって抑制されています。一方、同じプログラムのデスクトップバージョンでも遅延が発生している場合、これは、ネットワークのどこかに制限されていることを意味します。

通常、ネットワークによって抑制されている場合は、ICMPタイプ4データグラムを取得する必要があるため、それらを使用して、抑制されている場所を正確に確認できます。

結論として、パッケージが遅延する理由はたくさんあります。問題の解決を始める前に、問題の場所を見つけることが賢明です。

私の仮定の1つが間違っていたようです。よると、この：

GKMatchSendDataUnreliableモード、いわゆるUDPで送信される画像。TCPによって送信されるGKMatchSendDataReliableモードのイメージ。通常はGKMatchSendDataUnreliableである必要があります。

送信モードを実際の UDP（つまりGKMatchSendDataUnreliable）に変更すると、1秒あたり60パケットという低いpingレートが維持されます。私はNaglesにもう一度打たれたようです。

それでも変な動作（ping時間が非常に長い期間）はありますが、根本的な原因（ISPまたはネットワークの輻輳）はわかりません。

[ 10:30:33 ]:  I saw an average roundtrip time of 39.908923 ms, he saw 48.437794 ms
[ 10:30:39 ]:  I saw an average roundtrip time of 26.278577 ms, he saw 27.023854 ms
[ 10:30:48 ]:  I saw an average roundtrip time of 23.254163 ms, he saw 24.495182 ms
[ 10:30:54 ]:  I saw an average roundtrip time of 37.333127 ms, he saw 34.780404 ms
[ 10:31:03 ]:  I saw an average roundtrip time of 29.198575 ms, he saw 29.071106 ms
[ 10:31:11 ]:  I saw an average roundtrip time of 49.030299 ms, he saw 48.675459 ms
[ 10:31:18 ]:  I saw an average roundtrip time of 34.031792 ms, he saw 34.698117 ms
[ 10:31:24 ]:  I saw an average roundtrip time of 30.058642 ms, he saw 32.814952 ms
[ 10:31:30 ]:  I saw an average roundtrip time of 53.110438 ms, he saw 54.271453 ms
[ 10:31:45 ]:  I saw an average roundtrip time of 119.693933 ms, he saw 107.616359 ms
[ 10:31:50 ]:  I saw an average roundtrip time of 222.644443 ms, he saw 229.589861 ms
[ 10:31:57 ]:  I saw an average roundtrip time of 166.827070 ms, he saw 167.647724 ms
[ 10:32:05 ]:  I saw an average roundtrip time of 765.356593 ms, he saw 859.600923 ms
[ 10:32:13 ]:  I saw an average roundtrip time of 357.522686 ms, he saw 339.648654 ms
[ 10:32:24 ]:  I saw an average roundtrip time of 1115.639593 ms, he saw 1060.574401 ms
[ 10:32:39 ]:  I saw an average roundtrip time of 175.845995 ms, he saw 171.112166 ms
[ 10:32:44 ]:  I saw an average roundtrip time of 47.262925 ms, he saw 41.987869 ms
[ 10:32:52 ]:  I saw an average roundtrip time of 74.524443 ms, he saw 78.868198 ms
[ 10:33:47 ]:  I saw an average roundtrip time of 20.943917 ms, he saw 21.217377 ms
[ 10:33:52 ]:  I saw an average roundtrip time of 28.944821 ms, he saw 29.303144 ms
[ 10:34:06 ]:  I saw an average roundtrip time of 25.581624 ms, he saw 25.439416 ms
[ 10:34:13 ]:  I saw an average roundtrip time of 25.565568 ms, he saw 25.655267 ms
[ 10:34:18 ]:  I saw an average roundtrip time of 38.609394 ms, he saw 37.462835 ms

後：

[ 10:38:11 ]:  I saw an average roundtrip time of 40.037623 ms, he saw 43.367524 ms
[ 10:38:21 ]:  I saw an average roundtrip time of 121.222703 ms, he saw 118.855264 ms
[ 10:38:28 ]:  I saw an average roundtrip time of 726.391897 ms, he saw 685.742454 ms
[ 10:38:33 ]:  I saw an average roundtrip time of 60.251207 ms, he saw 57.974503 ms
[ 10:38:42 ]:  I saw an average roundtrip time of 1133.909392 ms, he saw 1124.404501 ms     

したがって、散発的で波状になります。パケットの送信速度を下げるなど、他の投稿のいくつかの提案を試す必要があると思います。