「2014/04/26-02」の編集履歴(バックアップ)一覧はこちら
「2014/04/26-02」(2014/04/26 (土) 23:31:28) の最新版変更点
追加された行は緑色になります。
削除された行は赤色になります。
**国内サーバなのにPingが3桁
またおかしなタイトルになりました。
相変わらず通信経路障害が多発しているらしく、
ぽつぽつとお問い合わせを頂きますので一度まとめておきましょう。
余計なことを書くとまた脱線してしまうので最短コースで行きましょう。
----
****そもそも通信経路って何だろう?
インターネットの「ネット」とは直訳すれば「網」ですね。
実際には網の目ほど綺麗ではありませんが、
&b(){通信元と通信先が一本道ではなく途中にいくつもの分岐点が存在する}
ネットワークになっています。
----
&b(){クライアントPCからゲームサーバまでのイメージ図}
&image(NetworkDiagram_20140426_01.png)
途中にいくつもの分岐点が存在し、どのルートを辿っても正常に到着出来るようになっています。
----
&b(){分岐のパターンを挙げると膨大な量になりますが、その中で最適と考えられるルートを自動的に探索し目的のサーバと通信する機能が備わっています。}
&b(){そして、実際に通信に使われたルートが&color(red){通信経路}と呼ばれます。}
&image(NetworkDiagram_20140426_02.png)
この参考例ではi3D東京DCまでPing10で接続可能なルートを自動選択し、
GS東京DCへはPing16で接続可能なルートが選択されています。
----
***では通信経路障害とは?
インターネットでは我々の関知しないところで膨大な量の通信回線や通信機器が活躍しています。
しかし、それらも機械ですのでいずれは故障します。
&b(){いつものルートで障害発生}
&image(NetworkDiagram_20140426_03.png)
&b(){故障してしまった赤い通信機器を迂回するルートが選択されたため、i3D東京DCまでのPingが16と少々悪化しました。}
&b(){&color(red){これはインターネットが持つすばらしい機能であり、障害発生時には一切人手を介さずに全自動で迂回ルートを探索します。}}
一昔前のコンピュータネットワークではどこか一カ所で障害が発生すると、
その地点を経由する通信は全て遮断されてしまいました。
さすが戦略核攻撃を想定した軍事ネットワーク(脱線するからこの話はやめます)
尚、このルート選択は障害発生時だけでなくトラフィック(通信中のデータ量)が一カ所に集中していることにより
速度低下が発生している場合の迂回策としても用いられるため、ユーザが知らぬ間に変化しています。
----
***Ping10が18になるなら良いのですが...
障害発生箇所を迂回して自動的に最適なルートを探索する高度な機構を備えているものの、
稀に残念なルートを選択してしまうのはカーナビゲーションそっくりです。
渋滞回避機能が付いているカーナビゲーションは
&b(){「遠回りするけど平均速度の高いルート」と「最短距離だが渋滞に突入するルート」を天秤にかけて最適なルートを割り出します。}
&b(){しかし、遠回りした先で大渋滞が発生していたなどと言うことも稀には起こります。}
&b(){同じようにインターネットの経路探索も稀に残念な結果になります。}
&image(NetworkDiagram_20140426_04.png)
&b(){この例では一度海外へ出て国内に戻ってくるルートが選択されています。}
&b(){海外も色々ですが一番多いケースは米国の西海岸まで往復するケース。}
&b(){往復18,000kmに達しますので光の速さでも無視出来ない時間を要します。}
&b(){&color(red){その結果、Ping16から一気に132にまで悪化しました。}}
----
***障害発生箇所の修理が終わったら元に戻るのか?
ここが難しいところなのですが障害が発生した設備を所有している会社のポリシーに依存するようです。
ある通信キャリアでは障害が復旧すると自動的に元のルートに復帰するよう構成されているように感じられます。
しかし、別の通信キャリアではルートの復帰は手動制御になっているらしく、
比較的長期間迂回ルートを使用する状況が続く傾向があるようです。
また、そもそも障害が発生してから障害復旧までの所要時間が全く異なるかもしれません。
前述の通り「インターネットは別のルートで通信出来ればそれで良い」のがポリシーですので、
別のルートが使える間は慌てて修理しなくても良いとも考えられます。
また、ブラウザでHPなどをアクセスする際、Ping10だったサイトが132になっても、体感的な差はほとんど無いと思います。
そのため、一般的にはこの程度の差は大きな問題では無いと捉えられがちです。
&b(){&color(red){しかし、リアルタイムなゲームの世界では致命傷ですね。}}
&b(){そのため「早く元に戻して」と頼むのがお勧めです。}
----
***復旧依頼のための情報収集(1)
&b(){Pingが悪化しているサーバのIPアドレスを調べます。}
&image(NetworkDiagram_20140426_11.png)
&b(){上記赤枠の通り、BattleLogのサーバ詳細ページにIPアドレスは表記されています。}
----
***復旧依頼のための情報収集(2)
&b(){次にWindowsコマンドのPingを使って再度Ping値を測定してみよう。}
コマンドプロンプトから下記の通り入力します。
ping [目的のサーバのIPアドレス] (Enter)
結果は下記の通り。
&image(NetworkDiagram_20140426_12.png)
&b(){ここで得られたPing値(ラウンドトリップの概算時間)はBattleLog内に表示されるPing値と概ね一致するはずです。}
&b(){もし著しく異なる場合は、そもそも別の問題が発生していると考えられますので、}
&b(){大変残念ですがこの記事の内容は無用と考えられます。}
----
***復旧依頼のための情報収集(3)
あと一歩で証拠が押さえられます。
同じくコマンドプロンプトより下記の通り実行しましょう。
tracert [目的のサーバのIPアドレス] (Enter)
(参考実行結果)
C:\Temp>tracert 173.199.82.173
173.199.82.173.choopa.net [173.199.82.173] へのルートをトレースしています
経由するホップ数は最大 30 です:
1 <1 ms <1 ms <1 ms 192.168.254.251
2 3 ms 2 ms 3 ms nas89c.setagaya.jp.bb.gin.ntt.net [129.250.11.53]
3 4 ms 4 ms 4 ms e1-7-n-otemachi.tokyjp01.jp.bb.gin.ntt.net [129.241.20.129]
4 5 ms 4 ms 4 ms 210.173.174.49
5 4 ms 4 ms 4 ms tky001bf00.IIJ.Net [58.138.82.1]
6 5 ms 5 ms 5 ms tky001ip59.IIJ.Net [58.138.82.82]
7 10 ms 5 ms 5 ms 210.130.154.38
9 120 ms 120 ms 119 ms te0-1-0-6.gw02.lax3.widegw.net [203.192.82.65]
10 * * * 要求がタイムアウトしました。
11 * * * 要求がタイムアウトしました。
12 124 ms 124 ms 124 ms xe-1-1-1.gw401.ty1.ap.equinix.com [183.177.32.146]
13 125 ms 125 ms 125 ms 202.177.202.226
14 126 ms 126 ms 125 ms 71.ae1.sw1.tko1.jp.scnet.net [50.31.249.110]
15 126 ms 126 ms 126 ms unknown.servercentral.net [50.31.249.202]
16 127 ms 127 ms 127 ms 173.199.82.173.choopa.net [173.199.82.173]
トレースを完了しました。
C:\Temp>
&b(){1から16までの番号と共に色々な情報が出力されていますが、}
&b(){この番号は概ね通信経路上に存在する通信機器と理解して問題ありません。}
ちなみに1は通信経路上、最初の通信機器であるクライアントPCに接続されたルータですね
&b(){&color(red){そして、このケースでは9番目から一気に応答時間(ほぼPing値に一致)が悪化します。}}
&b(){&color(red){この9番目のIPアドレス(203.192.82.65)が日本国外で使用されていることが確認出来れば完璧でしょう。}}
----
***あとはプロバイダのサポートデスクに連絡するだけ
私はこのような状況に陥ったことが無いため一度も直接対応したことが無いのですが、
何度か伺った話では「いままでpingが○○ぐらいだったのに急に○○○になったまま戻らない」とそのまま伝えれば調べてくれるようです。
&b(){&color(red){ここでサポートデスクのお姉さんが残念な方だった場合には上記tracertの結果を送付しましょう。}}
----
***その他
クライアントPCから送信されたデータは下記の順でネットワークを通過してゲームサーバに到達します。
1.宅内通信機器(ブロードバンドルータなど)
2.クライアント側プロバイダ管轄ネットワーク
3.IX
4.GSP(サーバレンタル業者)側プロバイダ管轄ネットワーク
ここまでの説明は原則的に2.で障害が発生しているケースを想定しています。
この場合は前述の通りプロバイダが対処してくれるはずです。
1.の場合には頑張って自力で対処して下さい。(笑)
4.の場合も過去に何度かありましたが、この場合はほぼ全てのプレイヤーが影響を受けるため、
ゲームサーバの管理者がGSPに連絡するでしょう。
ここで特殊なのはIXで障害が発生しているケース。
これはプロバイダ間を接続するTbps級の超高速ネットワークなのですが、
どこのプロバイダにも属さないためプロバイダに連絡しても対処してくれません。
しかし、膨大な人数が障害の影響を受けることや、一般的にはプロバイダよりも高いレベルの管理能力を有するため、
通信経路障害が長期間続くと考える必要はありません。
----
まずはtracertの結果を確認してプロバイダのサポートデスクに連絡しましょう。
(&Counter())
**国内サーバなのにPingが3桁
またおかしなタイトルになりました。
相変わらず通信経路障害が多発しているらしく、
ぽつぽつとお問い合わせを頂きますので一度まとめておきましょう。
余計なことを書くとまた脱線してしまうので最短コースで行きましょう。
----
****そもそも通信経路って何だろう?
インターネットの「ネット」とは直訳すれば「網」ですね。
実際には網の目ほど綺麗ではありませんが、
&b(){通信元と通信先が一本道ではなく途中にいくつもの分岐点が存在する}
ネットワークになっています。
----
&b(){クライアントPCからゲームサーバまでのイメージ図}
&image(NetworkDiagram_20140426_01.png)
途中にいくつもの分岐点が存在し、どのルートを辿っても正常に到着出来るようになっています。
----
&b(){分岐のパターンを挙げると膨大な量になりますが、その中で最適と考えられるルートを自動的に探索し目的のサーバと通信する機能が備わっています。}
&b(){そして、実際に通信に使われたルートが&color(red){通信経路}と呼ばれます。}
&image(NetworkDiagram_20140426_02.png)
この参考例ではi3D東京DCまでPing10で接続可能なルートを自動選択し、
GS東京DCへはPing16で接続可能なルートが選択されています。
----
***では通信経路障害とは?
インターネットでは我々の関知しないところで膨大な量の通信回線や通信機器が活躍しています。
しかし、それらも機械ですのでいずれは故障します。
&b(){いつものルートで障害発生}
&image(NetworkDiagram_20140426_03.png)
&b(){故障してしまった赤い通信機器を迂回するルートが選択されたため、i3D東京DCまでのPingが16と少々悪化しました。}
&b(){&color(red){これはインターネットが持つすばらしい機能であり、障害発生時には一切人手を介さずに全自動で迂回ルートを探索します。}}
一昔前のコンピュータネットワークではどこか一カ所で障害が発生すると、
その地点を経由する通信は全て遮断されてしまいました。
さすが戦略核攻撃を想定した軍事ネットワーク(脱線するからこの話はやめます)
尚、このルート選択は障害発生時だけでなくトラフィック(通信中のデータ量)が一カ所に集中していることにより
速度低下が発生している場合の迂回策としても用いられるため、ユーザが知らぬ間に変化しています。
----
***Ping10が18になるなら良いのですが...
障害発生箇所を迂回して自動的に最適なルートを探索する高度な機構を備えているものの、
稀に残念なルートを選択してしまうのはカーナビゲーションそっくりです。
渋滞回避機能が付いているカーナビゲーションは
&b(){「遠回りするけど平均速度の高いルート」と「最短距離だが渋滞に突入するルート」を天秤にかけて最適なルートを割り出します。}
&b(){しかし、遠回りした先で大渋滞が発生していたなどと言うことも稀には起こります。}
&b(){同じようにインターネットの経路探索も稀に残念な結果になります。}
&image(NetworkDiagram_20140426_04.png)
&b(){この例では一度海外へ出て国内に戻ってくるルートが選択されています。}
&b(){海外も色々ですが一番多いケースは米国の西海岸まで往復するケース。}
&b(){往復18,000kmに達しますので光の速さでも無視出来ない時間を要します。}
&b(){&color(red){その結果、Ping16から一気に132にまで悪化しました。}}
----
***障害発生箇所の修理が終わったら元に戻るのか?
ここが難しいところなのですが障害が発生した設備を所有している会社のポリシーに依存するようです。
ある通信キャリアでは障害が復旧すると自動的に元のルートに復帰するよう構成されているように感じられます。
しかし、別の通信キャリアではルートの復帰は手動制御になっているらしく、
比較的長期間迂回ルートを使用する状況が続く傾向があるようです。
また、そもそも障害が発生してから障害復旧までの所要時間が全く異なるかもしれません。
前述の通り「インターネットは別のルートで通信出来ればそれで良い」のがポリシーですので、
別のルートが使える間は慌てて修理しなくても良いとも考えられます。
また、ブラウザでHPなどをアクセスする際、Ping10だったサイトが132になっても、体感的な差はほとんど無いと思います。
そのため、一般的にはこの程度の差は大きな問題では無いと捉えられがちです。
&b(){&color(red){しかし、リアルタイムなゲームの世界では致命傷ですね。}}
&b(){そのため「早く元に戻して」と頼むのがお勧めです。}
----
***復旧依頼のための情報収集(1)
&b(){Pingが悪化しているサーバのIPアドレスを調べます。}
&image(NetworkDiagram_20140426_11.png)
&b(){上記赤枠の通り、BattleLogのサーバ詳細ページにIPアドレスは表記されています。}
----
***復旧依頼のための情報収集(2)
&b(){次にWindowsコマンドのPingを使って再度Ping値を測定してみよう。}
コマンドプロンプトから下記の通り入力します。
ping [目的のサーバのIPアドレス] (Enter)
結果は下記の通り。
&image(NetworkDiagram_20140426_12.png)
&b(){ここで得られたPing値(ラウンドトリップの概算時間)はBattleLog内に表示されるPing値と概ね一致するはずです。}
&b(){もし著しく異なる場合は、そもそも別の問題が発生していると考えられますので、}
&b(){大変残念ですがこの記事の内容は無用と考えられます。}
----
***復旧依頼のための情報収集(3)
あと一歩で証拠が押さえられます。
同じくコマンドプロンプトより下記の通り実行しましょう。
tracert [目的のサーバのIPアドレス] (Enter)
(参考実行結果)
C:\Temp>tracert 173.199.82.173
173.199.82.173.choopa.net [173.199.82.173] へのルートをトレースしています
経由するホップ数は最大 30 です:
1 <1 ms <1 ms <1 ms 192.168.254.251
2 3 ms 2 ms 3 ms nas89c.setagaya.jp.bb.gin.ntt.net [129.250.11.53]
3 4 ms 4 ms 4 ms e1-7-n-otemachi.tokyjp01.jp.bb.gin.ntt.net [129.241.20.129]
4 5 ms 4 ms 4 ms 210.173.174.49
5 4 ms 4 ms 4 ms tky001bf00.IIJ.Net [58.138.82.1]
6 5 ms 5 ms 5 ms tky001ip59.IIJ.Net [58.138.82.82]
7 10 ms 5 ms 5 ms 210.130.154.38
9 120 ms 120 ms 119 ms te0-1-0-6.gw02.lax3.widegw.net [203.192.82.65]
10 * * * 要求がタイムアウトしました。
11 * * * 要求がタイムアウトしました。
12 124 ms 124 ms 124 ms xe-1-1-1.gw401.ty1.ap.equinix.com [183.177.32.146]
13 125 ms 125 ms 125 ms 202.177.202.226
14 126 ms 126 ms 125 ms 71.ae1.sw1.tko1.jp.scnet.net [50.31.249.110]
15 126 ms 126 ms 126 ms unknown.servercentral.net [50.31.249.202]
16 127 ms 127 ms 127 ms 173.199.82.173.choopa.net [173.199.82.173]
トレースを完了しました。
C:\Temp>
&b(){1から16までの番号と共に色々な情報が出力されていますが、}
&b(){この番号は概ね通信経路上に存在する通信機器と理解して問題ありません。}
ちなみに1は通信経路上、最初の通信機器であるクライアントPCに接続されたルータですね
&b(){&color(red){そして、このケースでは9番目から一気に応答時間(ほぼPing値に一致)が悪化します。}}
&b(){&color(red){この9番目のIPアドレス(203.192.82.65)が日本国外で使用されていることが確認出来れば完璧でしょう。}}
----
***あとはプロバイダのサポートデスクに連絡するだけ
私はこのような状況に陥ったことが無いため一度も直接対応したことが無いのですが、
何度か伺った話では「いままでpingが○○ぐらいだったのに急に○○○になったまま戻らない」とそのまま伝えれば調べてくれるようです。
&b(){&color(red){ここでサポートデスクのお姉さんが残念な方だった場合には上記tracertの結果を送付しましょう。}}
----
***その他
クライアントPCから送信されたデータは下記の順でネットワークを通過してゲームサーバに到達します。
1.宅内通信機器(ブロードバンドルータなど)
2.クライアント側プロバイダ管轄ネットワーク
3.IX
4.GSP(サーバレンタル業者)側プロバイダ管轄ネットワーク
ここまでの説明は原則的に2.で障害が発生しているケースを想定しています。
この場合は前述の通りプロバイダが対処してくれるはずです。
1.の場合には頑張って自力で対処して下さい。(笑)
4.の場合も過去に何度かありましたが、この場合はほぼ全てのプレイヤーが影響を受けるため、
ゲームサーバの管理者がGSPに連絡するでしょう。
ここで特殊なのはIXで障害が発生しているケース。
これはプロバイダ間を接続するTbps級の超高速ネットワークなのですが、
どこのプロバイダにも属さないためプロバイダに連絡しても対処してくれません。
しかし、膨大な人数が障害の影響を受けることや、一般的にはプロバイダよりも高いレベルの管理能力を有するため、
通信経路障害が長期間続くと考える必要はありません。
----
&b(){&color(red){まずはtracertの結果を確認してプロバイダのサポートデスクに連絡しましょう。}
----
(追伸)
私の本職はネットワーク関連ではありません。
これらの知識が無いとご飯が食べられないのでやむを得ず知っているだけの話です。
(&Counter())
表示オプション
横に並べて表示:
変化行の前後のみ表示: