ミリ秒間の戦い。 ping が最も低いサーバーを選択する方法

オンライン ゲーム、ビデオ/音声会議、IP テレフォニー、VPN など、多くのタスクではクライアントとサーバー間の遅延が重要です。 IP ネットワーク レベルでサーバーがクライアントから遠すぎる場合、遅延 (一般に「ping」または「ラグ」と呼ばれます) によって作業が妨げられます。

サーバーの地理的な近接性は、IP ルーティング レベルでの近接性と必ずしも同じではありません。 したがって、たとえば、別の国のサーバーは、あなたの都市のサーバーよりも「近い」可能性があります。 すべてはルーティングとネットワーク構築の特殊性によるものです。

すべての潜在的なクライアントにできるだけ近いサーバーを選択するにはどうすればよいでしょうか? IPネットワーク接続とは何ですか? クライアントを最も近いサーバーに誘導するにはどうすればよいでしょうか? 記事で調べてみましょう。

遅延の測定

まず、遅延を測定する方法を学びましょう。 プロトコルやパケット サイズによって遅延が異なる可能性があるため、このタスクは思っているほど単純ではありません。 また、数ミリ秒続く急落などの短期的なイベントを見逃す可能性もあります。

ICMP - 通常の ping

Unix の ping ユーティリティを使用します。これを使用すると、パケットの送信間隔を手動で設定できますが、Windows の ping バージョンではこれができません。 パケット間に長い休止があると、パケット間に何が起こっているかが見えなくなる可能性があるため、これは重要です。

小包のサイズ (オプション -s) - デフォルトでは、ping ユーティリティはサイズが 64 バイトのパケットを送信します。 このような小さなパケットでは、大きなパケットで発生する現象が目立たない可能性があるため、パケット サイズを 1300 バイトに設定します。

パケット間の間隔 (オプション -i) — データ送信間の時間。 デフォルトでは、パケットは 0.1 秒に XNUMX 回送信されます。これは非常に長く、実際のプログラムは XNUMX 秒あたり数百、数千のパケットを送信するため、間隔を XNUMX 秒に設定します。 プログラムは単にそれ以下を許可しません。

その結果、コマンドは次のようになります。

ping -s 1300 -i 0.1 yandex.ru

この設計により、遅延をより現実的に把握できるようになります。

UDP および TCP 経由の ping

場合によっては、TCP 接続は ICMP パケットとは異なる方法で処理されるため、測定値はプロトコルによって異なる場合があります。 また、ホストが単に ICMP に応答せず、通常の ping が機能しないこともよくあります。 たとえば、これはホストが生涯を通じて行うことです。 microsoft.com.

ユーティリティ ピング 有名なスキャナーの開発者による nmap は、あらゆるパケットを生成できます。 遅延の測定にも使用できます。
UDP と TCP は特定のもので動作するため、特定のポートに「ping」する必要があります。 TCP 80、つまり Web サーバー ポートに ping を実行してみます。

$ sudo nping --tcp -p 80 --delay 0.1 -c 0 microsoft.com

Starting Nping 0.7.80 ( https://nmap.org/nping ) at 2020-04-30 13:07 MSK
SENT (0.0078s) TCP 10.0.0.1:63236 > 13.77.161.179:80 S ttl=64 id=49156 iplen=40  seq=3401731188 win=1480
SENT (0.1099s) TCP 10.0.0.1:63236 > 13.77.161.179:80 S ttl=64 id=49156 iplen=40  seq=3401731188 win=1480
RCVD (0.2068s) TCP 13.77.161.179:80 > 10.0.0.1:63236 SA ttl=43 id=0 iplen=44  seq=1480267007 win=64240 <mss 1440>
SENT (0.2107s) TCP 10.0.0.1:63236 > 13.77.161.179:80 S ttl=64 id=49156 iplen=40  seq=3401731188 win=1480
RCVD (0.3046s) TCP 13.77.161.179:80 > 10.0.0.1:63236 SA ttl=43 id=0 iplen=44  seq=1480267007 win=64240 <mss 1440>
SENT (0.3122s) TCP 10.0.0.1:63236 > 13.77.161.179:80 S ttl=64 id=49156 iplen=40  seq=3401731188 win=1480
RCVD (0.4247s) TCP 13.77.161.179:80 > 10.0.0.1:63236 SA ttl=42 id=0 iplen=44  seq=2876862274 win=64240 <mss 1398>

Max rtt: 112.572ms | Min rtt: 93.866ms | Avg rtt: 101.093ms
Raw packets sent: 4 (160B) | Rcvd: 3 (132B) | Lost: 1 (25.00%)
Nping done: 1 IP address pinged in 0.43 seconds

デフォルトでは、nping は 4 パケットを送信して停止します。 オプション -c 0 無限のパケット送信を可能にします。プログラムを停止するには、Ctrl+C を押す必要があります。 最後に統計が表示されます。 平均 rtt (往復時間) 値が 101 ミリ秒であることがわかります。

MTR - 強化されたトレースルート

プログラム MTR My Traceroute は、リモート ホストへのルートをトレースするための高度なユーティリティです。 通常のシステム ユーティリティの traceroute (Windows では、tracert ユーティリティ) とは異なり、パケット チェーン内の各ホストへの遅延を表示できます。 ICMP だけでなく、UDP や TCP 経由でもルートを追跡できます。

$ sudo mtr microsoft.com

(クリック可能) MTR プログラム インターフェイス。 microsoft.com へのルート トレースが開始されました

MTR はチェーン内の各ホストへの ping を即座に表示し、プログラムの実行中データは常に更新され、短期的な変更を確認できます。
スクリーンショットは、ノード #6 でパケット損失があることを示していますが、実際には、これは完全に真実ではありません。一部のルータは、TTL が期限切れになったパケットを単純に破棄し、エラー応答を返さないため、ここではパケット損失データを無視できます。

WiFi とケーブル

このトピックはこの記事とはまったく関係ありませんが、遅延という観点からは非常に重要だと私は考えています。 私はWiFiが大好きなのですが、少しでもケーブルでインターネットに接続する機会があれば利用してしまいます。 また、私は人々に WiFi カメラの使用をいつもやめさせます。
本格的なオンライン シューティング ゲームをプレイしたり、ビデオをストリーミングしたり、証券取引所で取引したりする場合は、ケーブル経由でインターネットを使用してください。

WiFi とケーブル接続を比較するための視覚的なテストを次に示します。 これは WiFi ルーターへの ping です。つまり、まだインターネットへの ping ではありません。

(クリック可能) ケーブル経由と WiFi 経由の WiFi ルーターへの ping の比較

WiFi 経由では遅延が 1 ミリ秒長くなり、場合によっては 1 倍長い遅延を持つパケットがあることがわかります。 そして、これはほんの短い期間です。 同時に、同じルーターは XNUMXms 未満の安定した遅延を生成します。

上の例では、802.11GHz の WiFi 2.4n が使用されており、ラップトップと電話のみが WiFi アクセス ポイントに接続されています。 アクセス ポイント上にさらに多くのクライアントが存在する場合、結果はさらに悪化します。 これが、ケーブルでアクセスできる場合はすべてのオフィスのコンピューターを WiFi に切り替えることに私が反対する理由です。

IP接続

サーバーへの遅延を測定する方法を学習したので、最も近いサーバーを見つけてみましょう。 これを行うには、プロバイダーのルーティングがどのように機能するかを確認します。 こんな時にサービスを利用すると便利です bgp.he.net

サイトにアクセスすると、IP アドレスが自律システムに属していることがわかります。 AS42610.

自律システムの接続グラフを見ると、プロバイダーがどの上位レベルのプロバイダーを介して他の世界に接続されているかがわかります。 各ドットをクリックすると、その中に入ってプロバイダーの種類を読むことができます。

プロバイダーの自律システムの接続グラフ

このツールを使用すると、ホスティングを含むプロバイダーのチャネルがどのように構成されているかを調査できます。 どのプロバイダーに直接接続されているかを確認します。 これを行うには、サーバーの IP アドレスを bgp.he.net の検索に入力し、その自律システムのグラフを確認する必要があります。 また、あるデータセンターまたはホスティングプロバイダーが別のデータセンターまたはホスティングプロバイダーにどのように接続されているかを理解することもできます。

ほとんどのトラフィック交換ポイントには、ルッキング グラスと呼ばれる特別なツールが用意されており、これを使用すると、交換ポイントの特定のルーターから ping およびtraceroute を実行できます。

ここで、例えば、 探しているガラス MGTSから

そのため、サーバーを選択するときに、さまざまなトラフィック交換ポイントからサーバーがどのように見えるかを事前に確認できます。 また、潜在的なクライアントが特定の地理的エリアに位置している場合、サーバーの最適な場所を見つけることができます。

最も近いサーバーを選択してください

私たちは、クライアントにとって最適なサーバーを見つける手順を簡素化することにし、近くの場所を自動テストするページを作成しました。 RUVDS データセンター.
ページにアクセスすると、スクリプトはブラウザから各サーバーまでの遅延を測定し、インタラクティブなマップ上に表示します。 データセンターをクリックすると、テスト結果の情報が表示されます。

ボタンをクリックすると、すべてのデータ センターの遅延テスト ページに移動します。 テスト結果を表示するには、地図上のデータ センター ポイントをクリックします。

出所： habr.com