これは珍しい質問だとは思いますが、ここにいる人たちがおそらく助けてくれると思います。ゲームプレイ中に極端に遅延が発生する理由を ISP に問い合わせてデバッグしようとしています。
質問:接続のボトルネックがどこにあるかについてより詳細な情報が得られる、パケット実行時間とパケット損失を分析する良い方法は何ですか? 実際にゲームをプレイせずに、ある程度人工的にトラフィックを再現する簡単な方法はありますか?
私の状況は次のとおりです:
- 私の ISP は、メイン ケーブルに到達する前に 10 km ほどにわたって複数のアクセス ポイントを備えた大規模なワイヤレス ネットワーク経由で接続を提供しています。これは常に行われており、過去には非常に信頼性が高いことが証明されています。ハードウェアの変更や ISP のその他の設定変更により、数か月前にゲームプレイの品質が低下しました。私の ISP は非常に協力的で、問題の原因を見つけて修正しようとしています。
- 一般的に、私の ping は非常に良好で、プレイしているとき、ゲーム内情報には常に 20 ~ 30 ミリ秒の良好な ping が表示されます。
- Battlefield の特徴は、フレーム レートが低下したり、接続の応答時間が悪かったり、パケットが失われたりした場合に警告シンボルを表示することです。繰り返し発生する状況は、警告シンボルなしで約 10 ~ 60 秒間プレイできるものの、その後、深刻なパケット損失が発生し、遅延が発生し、BF があらゆる種類の接続警告を表示するというものです。その後、数秒間は再びプレイできますが、その後、この動作が再び発生します。
私は Linux のみで作業しており、、、、およびその他のネットワーク ツールにping
はある程度慣れています。BF が使用するハイポートを知っており、使用されているパケット サイズを調べることができ、もちろんゲーム サーバーから IP を抽出することもできます。ISP がネットワークで何が起こっているかをデバッグしている間に、パケット損失を人為的に引き起こすことができるように、この問題を追跡するための良い方法は何ですか?traceroute
nmap
分析
moonpoint の親切な提案に従って WireShark をインストールし、ラグのあるゲームプレイを数分間キャプチャしました。最初の分析では、ゲーム サーバーから送信されるパケットに集中しました。サーバーから自分の IP に送信されるすべての UDP パケットをフィルターし、時間を調整して、それらのパケット間の相対時間を確認しました。並べ替えた後、650 ミリ秒から 1300 ミリ秒の間を要したパケットが約 20 個ありました。これは、マップの半分をジャンプしているパケットであると思われます。他のほとんどのパケットは、ゲーム内で「Ping」として表示される約 30 ミリ秒の実行時間とほぼ同じです。
すべての重要なパケットをマークした後、フィルターをクリアしてすべてのトラフィックを調べ、重要なパケットの周りのすべてのパケットで何が起こっているかのパターンを見つけられるかどうかを確認しました。 2 つの状況があることがわかりました。 94.250.208.153 はゲーム サーバーであり、青いハイライトは重要な UDP ゲーム パッケージであることに注意してください。
まず、重要なパケットの約 10 ~ 15 パケット前に、MAC アドレスから送信される神秘的な SSDP M-Search パケットがあります。
2 番目の状況は、重要なパケットの前に(または場合によってはその前後に)主に Google サーバーへの TCP 再送信が行われる場合です。
私の側で実行できるさらなる手順はありますか? 神秘的な SSDP パケットを調査する方法を誰か教えてもらえますか?
答え1
MTRはpingとtracerouteの機能を組み合わせたもので、ネットワークパス上でパケットロスが発生しているポイントや、ジッターは高い (例)。
無料のオープンソースを使うこともできますワイヤーシャークパケットアナライザは問題のトラブルシューティングに役立ちますが、提供される情報を理解するには、基盤となるシステムがどのように機能するかについての知識が必要です。インターネットプロトコルTCP/IP などのネットワーク接続プロトコルは、インターネット上で簡単に使用できます。インターネット上には、その使用方法に関するコースやチュートリアルがあります。効果的な使用方法を習得するにはかなりの時間がかかりますが、Wireshark などのツールの使い方を習得すれば、ネットワーク接続に関するあらゆる問題をより簡単にトラブルシューティングできるようになります。
Wiresharkをご存知ない方は、YouTubeで初心者向けWireSharkチュートリアルそしてWireshark 101: Wireshark の使い方、ヒント 115; 「Wireshark チュートリアル」という語句で検索すると、他にも多くのチュートリアルが見つかります。チュートリアルのあるウェブサイトには、次のものがあります。簡単で分かりやすい Wireshark チュートリアル、Wireshark を使用してパケットをキャプチャ、フィルタリング、検査する方法、 そしてWireshark チュートリアルは、アンジェロス・スタヴロウ教授ジョージ・メイソン大学のコンピュータサイエンス学部で。Wireshark の使い方に関するオンライン コースも用意されています。
Wiresharkを使うか、tcpダンプ、Linux、OS X、Microsoft Windowsで利用可能なコマンドラインパケットキャプチャツール(ウィンダンプ)システムでは、問題が発生したときにシステムからシステムへ流れるパケットをキャプチャして、後で自分でデータを分析したり、リアルタイムで分析したりすることができます。また、どちらのツールもキャプチャしたデータをキャプチャpcap ファイルは、問題をデバッグする際にネットワーク エンジニア間でネットワークの問題に関するデータを交換する一般的な方法であるため、ISP のネットワーク サポート スタッフはこのようなデータの解釈に精通している可能性があるため、ファイルにデータを提供できます。
Wiresharkはネットワークインターフェース上のすべてのデータをキャプチャしますが、Battlefieldゲームサーバーに関連付けられたネットワークポート番号とIPアドレスがわかっているので、Wireshark フィルターを使用してポート番号や IP アドレスでフィルターする。
アップデート:
の16進数「SSDP M-Searchパケット」に関連付けられている数字はメディアアクセス制御 (MAC)アドレス。MACアドレスは50-c5-8d-26-c2-06に似ています。つまり、イーサネットとWi-FiのMACアドレスは通常、16進数の2桁ごとにダッシュまたはコロンで区切られ、合計12桁で表示されます。つまり、48ビットのアドレスです。代わりに、IPv6アドレス - 現在インターネットで使用されているインターネットプロトコルには2つのバージョンがあり、長く使用されているインターネット プロトコル バージョン 4 (IPv4)そして、より新しいインターネット プロトコル バージョン 6 (IPv6)。
SSDPとはシンプルサービス検出プロトコル、これは、ユニバーサル プラグ アンド プレイ (UPnP)ローカルネットワーク上のIPv6アドレスfe80::50e7:d4f0:db:c4dcのシステムがパケットを送信しています。IP マルチキャストアドレス ff02::c。 IPv4 の場合、マルチキャスト アドレスは 239.255.255.250 ですが、SSDP over IPv6 では、X で示されるすべてのスコープ範囲に対してアドレス セット ff0X::c が使用されます (確認したパケットの「X」は「2」です)。
システムがなぜ接続しているのか分かりませんアマゾン ウェブ サービス (AWS)IP アドレスも Google アドレスも使用しません。
C:\>nslookup 52.203.205.255 8.8.8.8
Server: google-public-dns-a.google.com
Address: 8.8.8.8
Name: ec2-52-203-205-255.compute-1.amazonaws.com
Address: 52.203.205.255
C:\>nslookup 216.58.212.78 8.8.8.8
Server: google-public-dns-a.google.com
Address: 8.8.8.8
Name: lhr35s05-in-f78.1e100.net
Address: 216.58.212.78
接続はポート443であることがわかります。よく知られているポートHTTPSトラフィックに対して52.203.205.255 逆IP検索DomainTools を使用する逆IP検索機能がないと、「検索に一致する結果が見つかりませんでした」と表示されます。多くの場合、その検索ツールにIPアドレスを入力すると、完全修飾ドメイン名 (FQDN)IP アドレスでホストされている Web サイトの場合 (複数の Web サイトが同じ IP アドレスでホストされる可能性があります)、この場合は該当しません。
あ216.58.212.78 逆IP検索同じメッセージが返されました。1e100.netが表示されている場合は、Googleシステムです。Googleが名前に「1e100」を使用するのは、「1」の後に100個のゼロが続くことを表す方法であるためです。グーゴル。
これらのパケットは両方とも、Battlefield サーバーとの通信とは無関係である可能性があります。ただし、これらが再送信であるという事実は、システムがパケットを送信したが、受信を示す確認パケットを相手側から受信しなかった場合に送信されるため、Battlefield サーバーで問題が発生しているのと同時に、他のサイトへのトラフィックでもパケット損失が発生している可能性があります。システムがこれらの 2 つの IP アドレスと通信している理由を知りたい場合は、これらの 2 つの IP アドレスでフィルター処理して、それらの IP アドレスとの間で送受信される他のパケットを表示し、パケット キャプチャにこれらのパケットが表示される理由をよりよく理解することができます。