ネットワークがビジー状態になると非常に待ち時間が長くなる、TCP、libevent

Question

私たちのC/Sベースのオンラインゲームプロジェクトでは、TCPをネットワーク伝送に使用しています。 Libeventを含めると、ネットワークI/Oで自動的に処理するための接続ごとにbuffereventを使用します。

これは以前はうまくいきましたが、最近遅れの問題が表面に現れています。ネットワークをもっと忙しくするためにいくつかのストレステストを行うと、待ち時間は非常に長くなり、数秒かそれ以上になります。サーバは混乱状態に沈む：

平均CPU使用率が減少し

• （0％-60％-0％-60％リピート、待っている何か？）ネットトラフィックが（nethogs）
• を減少
• 何かが魔法のようにすべてのシステムを遅くしますが、サーバーへの新しい接続が時間内に終了答えたように、まだ生きているサーバに接続されたクライアント（netstatの& tcpdumpの）

は、それは見えます。

プロトコルをUDPに変更したとき、同じ状況で正常に動作します。明らかな遅延はなく、システムは高速に動作します。純交通量は約3M/Sです。

プロジェクトはイントラネット上で実行されています。私はまた、最大ダウンロード速度、ほぼ18M/Sをテストしました。

私はLibeventのヘッダファイルと文書の一部を研究し、すべての接続にレート制限を設定しようとしました。いくつかの改良を加えましたが、いくつかの異なる構成を試みても問題は完全に解決されませんでした。私のパラメータは次のとおりです：read_rate 163840、read_burst 163840、write_rate 163840、write_burst 163840、tick_len 500ms。

ありがとうございました！

Answer 1

TCP =伝送制御プロトコル。遅れた後、未確認のパケットを再送信することによって、パケット損失に応答します。繰返し損失の場合、指数関数的に逆戻りします。応答していないことをホストへの接続をオープンしようとする試みのこのネットワークキャプチャを見てみましょう：それは最初のSYN送信し、その後、1秒のためにACKを得ていない後、再び試みる

。 ackを取得しないと、〜2秒後、〜4秒後、〜8秒後などに別のものを送信します。したがって、繰り返しのパケット損失に直面して深刻な遅延が発生することがわかります。

意図的にネットワークに負荷をかけており、CPU使用率が矛盾していると言われたため、TCPが紛失したパケットを再送するのを待っている可能性があります。

実際に何が起こっているのかを知る最も良い方法は、実際に送信されたものをネットワークで取得することです。ホストが1つのスイッチに接続されている場合は、目的のポートをキャプチャできる別のホストのポートに「スパン」できます。

スイッチがこれに対応していない場合、またはスイッチの管理権限がない場合は、オンラインゲームに関係するホストの1人からキャプチャを取得する必要があります。これの欠点は、キャプチャをとることで何が起こるかが変わる可能性があり、実際にワイヤ上に何が表示されているのかわからないことです。たとえば、インターフェイスでTCPセグメンテーションオフロードを有効にすると、キャプチャでネットワークインターフェイスによって分割される大きなパケットが表示されます。

ネットワークキャプチャを分析するためにwiresharkをインストールすることをお勧めします（wiresharkを使用してリアルタイムでキャプチャを行うことができます）。ネットワーク化されたシステムを使って作業しているときは、wiresharkの使用を推奨して、実際にネットワーク上で何が起こっているかを見えるようにしてください。あなたが使用することを提案する最初のフィルタは、問題を示唆するパケットを表示するtcp.analysis.flagsです。

私はまた、何が起こっているのかを調べるためにレートリミットを最初にオフにすることを提案します。レート制限は、を別のパケットを送信しない理由を追加します。 ）。また、あなたのゲームの仕方によっては、500msは長くてtick_lenかもしれません。あなたのバースト構成でレートが100ミリ秒で使い切れるのであれば、もう一度送信する前に400ミリ秒待つことになります。 IOグラフはこの点でWiresharkの非常に役立つ機能です。これは、伝送速度を見るのに役立ちますが、デフォルトのティック間隔と単位はこの点ではあまり役に立ちません。ここで200mbit/sのレート制限されバーストフローの例である：ティック間隔は1msであり、単位は、チャート1ギガバイト/秒の上部を作るれ、ビット/ティックであること

注、問題のインタフェースの速度。