はじめに
ハードコア系のFPSゲーム「Escape From Tarkov」で、アジア圏のサーバを選んだときに稀にPing（RTT）が異常に悪くなる問題を調査してみます。
前提
- 日本（名古屋市）のマンション在住
- タルコフのサーバ設定は「China」「Korea」「Japan」「Singapore」の4つ
- インターネット回線は以下の3回線を自由に選択可能
- フレッツ光ネクスト PPPoE接続 IIJmioひかり（1Gbps回線）
- フレッツ光ネクスト IPoE接続 transix接続（1Gbps回線）
- コミュファ光マンションタイプ（1Gbps回線）
接続先サーバについて
サーバIPアドレスを抽出
ゲームインストールフォルダ内の
Battlestate Games\eft\Logs\log_YYYY.MM.DD_hh-mm-ss_VERSION
フォルダ内に吐き出されるログファイルのうち、
YYYY.MM.DD_hh-mm-ss_VERSION traces.log
というログファイルには以下のようなログが記録されており、マッチング完了後のスポーン直前に「接続先IPアドレス」や「接続先ポート番号」の情報が出力されます。
2023-09-05 21:58:33.413 +09:00|0.13.5.0.25837|Debug|application|TRACE-NetworkGameCreate profileStatus: 'Profileid: 5f884eed9423ab2f61459109, Status: Busy, RaidMode: Online, Ip: 103.244.112.162, Port: 17010, Location: bigmap, Sid: 103.244.112.162-17010_PID_05.09.23_12.45.29, GameMode: deathmatch, shortId: GW6065'
2023-09-05 22:14:36.340 +09:00|0.13.5.0.25837|Debug|application|TRACE-NetworkGameCreate profileStatus: 'Profileid: 5f884eed9423ab2f61459108, Status: Busy, RaidMode: Online, Ip: 84.17.37.172, Port: 17032, Location: RezervBase, Sid: 84.17.37.172-17032_PID_05.09.23_12.51.37, GameMode: deathmatch, shortId: GWTWTS'
2023-09-05 22:28:43.042 +09:00|0.13.5.0.25837|Debug|application|TRACE-NetworkGameCreate profileStatus: 'Profileid: 5f884eed9423ab2f61459109, Status: Busy, RaidMode: Online, Ip: 209.58.169.122, Port: 17030, Location: bigmap, Sid: 209.58.169.122-17030_PID_05.09.23_13.26.38, GameMode: deathmatch, shortId: GWXDQC'
このログファイルを元に、2022年1月～2023年9月までの21ヶ月間の接続先サーバ情報を洗い出し、出現回数順にソートしてみます。
各サーバごとのロケーションを探す
IPアドレスが分かれば、該当サーバがどの国のサーバかまでは絞り込む事ができます。
以前はwhoisと呼ばれるプロトコルで調査するのが定番でしたが、現在はRDAPと呼ばれるWeb APIを使って任意のIPアドレスに関する情報を取り出すことが出来ます。
例えば、前述のリストで1番目にある「103.208.221.213」について情報を抽出すると、以下のようなデータを取り出すことが出来ます。
このデータのうち、[country] の情報を取り出すことで、該当IPアドレスのサーバの所在地を概ね取得することが出来ます。
※必ずしも正確ではない場合もあります
これらを使い、上記のリストの各サーバの所在地をリストアップしました。
各サーバのレイテンシを調査する
上記の各サーバに対して、手持ちの3回線からPingコマンドでICMPパケットを送信し、レイテンシ（RTT=Round Trip Time）とホップ数（TTL=Time To Live）を確認してみます。
以下のようなワンライナーで一括実行し、結果をExcelにまとめてカラースケール表示してみました。
cat address.txt | xargs -n1 -I{} bash -c "ping -I 192.168.1.xxx -c1 {} | grep -e icmp_seq; ping -I 192.168.1.yyy -c1 {} | grep -e icmp_seq; ping -I 192.168.1.zzz -c1 {} | grep -e icmp_seq;" | flat ifs="\n" 3※ flat コマンドは、ワンライナー便利ツールこと「egzact」パッケージに含まれるコマンドで、任意の列数で整理できるものです。
greymd/egzact: Generate flexible patterns on the shell
我が家の環境では、送信元IPアドレスにより出力経路が変わるため、pingコマンドの -I オプションでIPアドレスを切り替えながらコマンドを実行しています。
結果として、上記の画像のようなデータが取得できます。
このうち、9行目のJPサーバのように、利用する回線によってレイテンシの値が大きく異なっている物について特に注目して抽出してみます。
回線によってレイテンシが異なるサーバについて
レイテンシ差の大きいサーバの傾向調査
前述の「利用する回線によってレイテンシの値が大きく異なるもの」について抽出した結果が上記の表となります。
傾向としては以下のような傾向が見受けられます。
- 日本サーバのごく一部にて、IIJおよびtransixのみレイテンシが高くなる
- 香港サーバの一部にて、IIJのみレイテンシが高くなる
- シンガポールサーバの多くにて、コミュファのレイテンシが高くなる
- シンガポールサーバの一部にて、IIJのレイテンシが高くなる
- ロシアサーバの一部にて、IIJおよびtransixのレイテンシが高くなる
日本サーバの事例を深く調査してみる
上記の表における日本サーバのレイテンシが高い事例について、tracerouteコマンドを利用して宛先サーバへの経路を調査比較してみます。
コミュファ回線からの接続経路
~$ sudo traceroute -IA -s 192.168.1.ZZZ 103.208.220.218traceroute to 103.208.220.218 (103.208.220.218), 30 hops max, 60 byte packets1 _gateway (192.168.1.1) [*] 0.478 ms 0.536 ms 0.657 ms2 r-210-173-146-45.commufa.jp (210.173.146.45) [AS18126] 6.453 ms 6.493 ms 6.517 ms3 r-210-173-145-121.commufa.jp (210.173.145.121) [AS18126] 6.626 ms 8.145 ms 8.182 ms4 r-210-173-150-97.commufa.jp (210.173.150.97) [AS18126] 15.714 ms 15.756 ms 15.800 ms5 210.171.225.41 (210.171.225.41) [*] 11.482 ms 11.511 ms 11.606 ms6 103.208.220.39 (103.208.220.39) [as46562/AS46562] 11.235 ms 9.375 ms 10.731 ms7 103.208.220.218 (103.208.220.218) [as46562/AS46562] 10.746 ms 10.735 ms 10.807 ms
中部電力系の通信事業者であるコミュファは、レイテンシから推測すると4ホップ目で大阪のDCに到達後、大手事業者のバックボーンを経由して5番目のJPIXのアドレスを経由し、タルコフサーバの稼働している Performive のネットワークに到達しているようです。
IIJ回線からの接続経路
~$ sudo traceroute -IA -s 192.168.1.YYY 103.208.220.218traceroute to 103.208.220.218 (103.208.220.218), 30 hops max, 60 byte packets1 _gateway (192.168.1.1) [*] 0.374 ms 0.438 ms 0.516 ms2 aichi01-z18.flets.2iij.net (160.13.169.107) [AS2497] 7.818 ms 7.836 ms 7.876 ms3 AICHI1-NTTwest0.flets.2iij.net (160.13.169.69) [AS2497] 2.808 ms 3.074 ms 3.400 ms4 ngy007lip30.IIJ.Net (202.214.41.1) [AS2497] 3.176 ms 3.224 ms 3.252 ms5 ngy007bb00.IIJ.Net (210.130.143.1) [AS2497] 3.650 ms 3.795 ms 3.898 ms6 lax002bb12.IIJ.Net (58.138.80.57) [AS2497] 113.261 ms 112.405 ms 112.584 ms7 ldn001bb10.IIJ.Net (58.138.83.185) [AS2497] 243.553 ms 243.549 ms 243.578 ms8 193.251.248.125 (193.251.248.125) [AS5511] 243.621 ms 243.660 ms 243.688 ms9 bundle-ether302.martr1.marseille.opentransit.net (193.251.131.117) [AS5511] 259.566 ms 260.049 ms 260.093 ms10 * * *11 ae1-2.RT.EQX.TYO.JP.retn.net (87.245.232.7) [AS9002] 285.593 ms 285.581 ms 285.549 ms12 GW-ColoAt.retn.net (87.245.240.201) [AS9002] 240.153 ms 241.918 ms 241.926 ms13 103.208.220.35 (103.208.220.35) [as46562/AS46562] 240.223 ms 240.216 ms 240.600 ms14 103.208.220.218 (103.208.220.218) [as46562/AS46562] 240.570 ms 240.560 ms 240.543 ms
IIJはTier1と称されるバックボーンを有する通信事業者ですが、4ホップ目で名古屋のバックボーンルータを通過した後、5ホップ目で何故かLAX（＝ロサンゼルス？）を経由し、6ホップ目ではLDN（＝ロンドン？）に行った後、7～8ホップ目ではフランスの事業者（Orange）のマルセイユを経由しています。
その後、9ホップ目が隠れていますが10ホップ目で再び東京に戻ってきています。
実際のバックボーン上の通信が上記のような直線の経路にはならないと思いますが、最短距離でも往復で約56,000キロを超える距離を移動しています。
送信元も宛先もどちらも日本ですが、インターネット上では通信はこのような経路となっているのです。
シンガポールサーバの事例を深く調査してみる
一方で、前述の表におけるシンガポールサーバのレイテンシが高い事例について、tracerouteコマンドを利用して宛先サーバへの経路を調査比較してみます。
transix回線からの接続経路
~$ sudo traceroute -IA -s 192.168.1.XXX 103.244.112.170 traceroute to 103.244.112.170 (103.244.112.170), 30 hops max, 60 byte packets 1 _gateway (192.168.1.1) [*] 0.403 ms 0.482 ms 0.569 ms 2 dj2-bbrt10.transix.jp (14.1.5.69) [AS55392] 12.558 ms 12.556 ms 12.564 ms 3 210.173.179.81 (210.173.179.81) [AS7521] 13.637 ms 13.681 ms 13.685 ms 4 ae-8.r27.osakjp02.jp.bb.gin.ntt.net (129.250.7.32) [AS2914] 13.732 ms 13.761 ms 13.797 ms 5 ae-0.r26.osakjp02.jp.bb.gin.ntt.net (129.250.3.44) [AS2914] 15.437 ms 15.022 ms 15.372 ms 6 * * ae-4.r27.tkokhk01.hk.bb.gin.ntt.net (129.250.2.43) [AS2914] 55.400 ms 7 ae-7.r22.sngpsi07.sg.bb.gin.ntt.net (129.250.7.66) [AS2914] 95.377 ms * 96.362 ms 8 ae-0.a01.sngpsi07.sg.bb.gin.ntt.net (129.250.2.122) [AS2914] 94.692 ms 94.764 ms 94.806 ms 9 ae-0.godaddy.sngpsi07.sg.bb.gin.ntt.net (116.51.18.183) [AS2914] 93.929 ms 93.945 ms 94.017 ms 10 ae1.sin2-pesa0206-01.bb.gdinf.net (148.72.204.153) [AS19905] 93.764 ms 93.760 ms 93.758 ms 11 148.72.204.181 (148.72.204.181) [AS19905] 90.203 ms 89.127 ms 89.102 ms 12 103.244.112.170 (103.244.112.170) [AS19905/AS398109] 98.267 ms 98.304 ms 98.325 ms
transix回線経由でシンガポールサーバにアクセスを行うと、2ホップ目として大阪のtransix終端（AFTR）でDS-Liteのカプセリングが外された後、3ホップ目でJPNAP Osakaを経由し、4ホップ目以降はNTT Communicationsの回線を利用して大阪→東京→香港→シンガポールの順で接続していることがわかります。
IIJ回線からの接続経路
~$ sudo traceroute -IA -s 192.168.1.YYY 103.244.112.170 traceroute to 103.244.112.170 (103.244.112.170), 30 hops max, 60 byte packets 1 _gateway (192.168.1.1) [*] 0.435 ms 0.527 ms 0.622 ms 2 aichi01-z18.flets.2iij.net (160.13.169.107) [AS2497] 8.190 ms 8.188 ms 8.185 ms 3 AICHI1-NTTwest0.flets.2iij.net (160.13.169.69) [AS2497] 3.830 ms 4.099 ms 4.365 ms 4 ngy007lip30.IIJ.Net (202.214.41.1) [AS2497] 4.047 ms 4.082 ms 4.122 ms 5 ngy007bb00.IIJ.Net (210.130.143.1) [AS2497] 4.083 ms 4.112 ms 4.150 ms 6 osk004bb00.IIJ.Net (58.138.80.9) [AS2497] 6.616 ms 6.506 ms 5.220 ms 7 osk004ix51.IIJ.Net (58.138.107.26) [AS2497] 5.206 ms 5.212 ms 5.234 ms 8 210.173.171.226 (210.173.171.226) [AS7521] 5.264 ms 5.720 ms 5.739 ms 9 ae-2.r27.osakjp02.jp.bb.gin.ntt.net (129.250.4.218) [AS2914] 6.893 ms 6.855 ms 6.818 ms 10 ae-0.r26.osakjp02.jp.bb.gin.ntt.net (129.250.3.44) [AS2914] 6.574 ms 6.297 ms 6.282 ms 11 ae-4.r27.tkokhk01.hk.bb.gin.ntt.net (129.250.2.43) [AS2914] 56.708 ms 56.676 ms 56.609 ms 12 ae-7.r22.sngpsi07.sg.bb.gin.ntt.net (129.250.7.66) [AS2914] 87.500 ms * 87.519 ms 13 ae-0.a01.sngpsi07.sg.bb.gin.ntt.net (129.250.2.122) [AS2914] 396.220 ms 396.223 ms 396.268 ms 14 ae-0.godaddy.sngpsi07.sg.bb.gin.ntt.net (116.51.18.183) [AS2914] 286.559 ms 286.553 ms 286.536 ms 15 ae1.sin2-pesa0206-01.bb.gdinf.net (148.72.204.153) [AS19905] 185.752 ms 185.743 ms 185.737 ms 16 148.72.204.181 (148.72.204.181) [AS19905] 328.125 ms 328.172 ms 328.193 ms 17 103.244.112.170 (103.244.112.170) [AS19905/AS398109] 381.003 ms 391.954 ms 391.935 ms
IIJ回線経由でシンガポールサーバにアクセスを行うと、5～6ホップ目で名古屋から大阪に向かったあと、8ホップ目でJPNAP Osakaに接続し、その後はtransixと同様にNTT Communicationsの経路を通っていきます。
前述のtransix経路と比較した場合の違いとして、12ホップ目となる "ae-7.r22.sngpsi07.sg.bb.gin.ntt.net" まではほぼ同一経路ですが、その後となる13ホップ目の "ae-0.a01.sngpsi07.sg.bb.gin.ntt.net" のルータでtransixでは93ミリ秒程度のレイテンシだったものが、IIJ回線では396ミリ秒と非常にレイテンシが高くなっています。
コミュファ回線からの接続経路
~$ sudo traceroute -IA -s 192.168.1.ZZZ 103.244.112.170 traceroute to 103.244.112.170 (103.244.112.170), 30 hops max, 60 byte packets 1 _gateway (192.168.1.1) [*] 0.375 ms 0.462 ms 0.559 ms 2 r-210-173-146-45.commufa.jp (210.173.146.45) [AS18126] 5.978 ms 5.985 ms 6.130 ms 3 r-210-173-145-121.commufa.jp (210.173.145.121) [AS18126] 5.970 ms 6.004 ms 6.102 ms 4 r-210-173-150-101.commufa.jp (210.173.150.101) [AS18126] 6.060 ms 6.070 ms 6.167 ms 5 ae-12-2041.r00.tokyjp08.jp.bb.gin.ntt.net (61.120.147.65) [AS2914] 19.174 ms 19.207 ms 19.296 ms 6 ae-21.r33.tokyjp05.jp.bb.gin.ntt.net (129.250.6.128) [AS2914] 15.944 ms * 13.926 ms 7 ae-4.r32.tokyjp05.jp.bb.gin.ntt.net (129.250.5.55) [AS2914] 17.736 ms 17.731 ms 17.726 ms 8 ae-2.r26.tkokhk01.hk.bb.gin.ntt.net (129.250.2.51) [AS2914] 62.615 ms 62.659 ms 62.604 ms 9 * * * 10 * * * 11 ae-2.r23.sngpsi07.sg.bb.gin.ntt.net (129.250.4.74) [AS2914] 92.192 ms 92.262 ms 92.165 ms 12 ae-1.a01.sngpsi07.sg.bb.gin.ntt.net (129.250.2.240) [AS2914] 406.514 ms 387.192 ms 387.180 ms 13 ae-0.godaddy.sngpsi07.sg.bb.gin.ntt.net (116.51.18.183) [AS2914] 433.709 ms 412.118 ms 412.069 ms 14 ae1.sin2-pesa0206-01.bb.gdinf.net (148.72.204.153) [AS19905] 350.852 ms 350.841 ms 350.873 ms 15 148.72.204.181 (148.72.204.181) [AS19905] 315.198 ms 315.173 ms 310.411 ms 16 103.244.112.170 (103.244.112.170) [AS19905/AS398109] 392.827 ms 391.614 ms 399.548 ms
コミュファ回線経由でシンガポールサーバにアクセスを行った際も、IIJ回線経由の場合と同様にNTT Communicationsを経由してシンガポールへ向かった後の "ae-1.a01.sngpsi07.sg.bb.gin.ntt.net"のルータにてレイテンシが400ミリ秒を超えており、非常にレイテンシが高くなっています。
戻りの接続経路を確認してみる
上記で確認した各回線からのTracerouteはあくまで自宅→サーバ方向の通信経路のみが表示され、戻りの通信がどのような経路となっているかは分かりません。
こんな時のために、上記に登場してきたNTT Communicationsでは「Lookng Glass」と呼ばれるネットワーク疎通確認用のツールを公開してくれており、シンガポール側のルータからどのような経路となるかを調査することが出来ます。
Looking Glass Landing - NTT-GIN
このツールを使い、NTT Communicationsのシンガポールルータから見てIIJ、transix、コミュファの各ゲートウェイがどのような経路となるか確認してみます。
transix宛の戻り経路
1 ae-2.r22.sngpsi07.sg.bb.gin.ntt.net (129.250.2.148) 5 msec 1 msec2 ae-10.r27.tkokhk01.hk.bb.gin.ntt.net (129.250.7.67) [MPLS: Label 110569 Exp 0] 42 msec 39 msec 39 msec3 ae-4.r26.osakjp02.jp.bb.gin.ntt.net (129.250.2.42) [MPLS: Label 85979 Exp 0] 74 msec * *4 ae-0.r27.osakjp02.jp.bb.gin.ntt.net (129.250.3.45) 82 msec 75 msec 75 msec5 ae-2.r03.osakjp02.jp.bb.gin.ntt.net (129.250.7.33) 72 msec 82 msec 70 msec6 dj2-bbrt10.transix.jp (14.1.5.69) 66 msec 80 msec 66 msec
前述の自宅側を起点としたTraceroute結果を逆順にした結果とほぼ変わらない内容となっています。
IIJ宛の戻り経路
1 ae-1.r23.sngpsi07.sg.bb.gin.ntt.net (129.250.4.93) [MPLS: Label 700 Exp 0] 7 msec * 1 msec2 * *ae-13.r33.tokyjp05.jp.bb.gin.ntt.net (129.250.2.243) [MPLS: Label 16 Exp 0] 380 msec3 ae-9.r03.tokyjp05.jp.bb.gin.ntt.net (129.250.5.45) 378 msec 315 msec 328 msec4 210.173.174.170 378 msec 343 msec 384 msec5 tky001bb00.IIJ.Net (58.138.100.201) 72 msec *tky009bb00.IIJ.Net (58.138.114.5) 553 msec6 ngy007bb00.IIJ.Net (58.138.89.242) 70 msec 358 msecngy007bb00.IIJ.Net (58.138.80.2) 384 msec7 ngy007lip30.IIJ.Net (202.214.41.1) 385 msec 367 msec 389 msec
自宅側を起点としたTraceroute結果では「名古屋→大阪→東京→香港→シンガポール」だった経路が、戻りルートでは「シンガポール→東京→名古屋」に変わっています。
そして、2ホップ目に記載されているシンガポールと東京を結ぶ経路のレイテンシが異常に悪いようです。
コミュファ宛の戻り経路
1 * * *2 ae-13.r33.tokyjp05.jp.bb.gin.ntt.net (129.250.2.243) 391 msec * 389 msec3 ae-3.r00.tokyjp08.jp.bb.gin.ntt.net (129.250.6.129) 389 msec 395 msec *4 * * *5 * * *6 * * *7 * * *
コミュファ宛の場合、経路の問題か1ホップ目の応答がなく経路が全て表示されませんでしたが、前述のIIJ宛経路同様に2ホップ目で東京に戻っていることからも、IIJ同様に戻りルートが「シンガポール→東京→名古屋」となっていることが予想されます。
結論と対策
国内サーバ宛の接続性について
結論としては、日本国内で閉じた接続であっても、通信経路の事情によって海外を経由する形となってしまい、レイテンシが非常に高くなる場合があるということでした。
国内同士にも関わらずなぜ国外を経由するのか？という点は、インターネットの仕組みに深く関わる部分となるのですが、端的に説明するならば以下のような事情が推察されます。
- インターネットは通信事業者同士が接続しあって出来ている
- 必ずしも事業者同士が直接の接続（ピアリング）をしているとは限らない
- IXと呼ばれる中継事業者を介して相互接続する場合が多い
- 利用者が契約しているプロバイダの通信事業者と、相手サーバの通信事業者の間において、接続し合う適切な事業者が居ない場合がある
- プロバイダA社とサーバB社が共通で利用している事業者が居ないなど
- そのような場合、相手サーバと接続している事業者を探すために国外まで行ってしまう場合がある
- 今回の場合は共通で利用している事業者がフランスとなってしまっていた
- インターネットの出口を変える以外に事象を改善する方法はない
- wikiなどで言われている「ルータを変える」「DNSを変える」などは無意味
- 「VPNを使う」に関しては、インターネットの出口が変わるため効果あり
- プロバイダA社とVPN事業者が共通で利用している中継事業者がいる＋VPN事業者とサーバB社が共通で利用している中継事業者がいる＝改善される
ちなみに、国内には複数のインターネットプロバイダがありますが、今やその殆どは大手事業者の回線を仕入れて名前を変えて再販するだけの存在です。
特に「IPoE接続で高速」と謳っている事業者の殆どは通信経路を以下の数社に依存しているため、別のプロバイダを選んでいたとしても結局以下の各社経路に準じてしまいます。
- インターネットマルチフィード（transix接続）
- JPNE / JPIX（v6プラス接続）
- BBIX（IPv6高速ハイブリッド）
- ビッグローブ（v6プラス接続）
- ASAHIネット（IPv4 over IPv6接続）
- OCN（OCNバーチャルコネクト）
- フリービット（ISPプレミアム）
- アルテリア・ネットワークス（Xpass接続）
そのため、例えばtransix接続を使うプロバイダA社から、同じくtransix接続を使うプロバイダC社に契約変更しても経路はほぼ変わらないため改善されることは無いと思われます。
国外サーバ宛の接続について
海外サーバ宛の経路については、単純な距離の問題などとは別で戻り経路が最適な経路とならず、遅い回線を経由して戻ってきてしまう場合があるようです。
これについても、前述の国内サーバの問題同様に「インターネットの出口を変える」といった対応で経路を変えるしかありませんが、必ずしも解消する方法とはならないため確実性が低くなってしまいます。
最も有効な解決策としては、このような事象が発生しているサーバがある地域は選択しない、というものになるかと思います。
まとめ
大手のオンラインゲームなどと異なり、依然としてベータ版を貫くタルコフでは、利用しているサーバ事業者が有名な大手事業者というわけでもなく接続性が担保されたサーバとはなっていないようです。
自身の機器や設定を見直して解消するものであればなんとか出来ますが、回線そのものに依存する事象は契約変更や回線の引き直し等によってしか解消することは出来ないため、一般の方にはなかなかハードルが高いなと感じます。
こういった事情はなかなかゲーム事業者側は把握しにくいとも聞くため、適宜サポート経由で問い合わせるなどして「接続性が悪い」ということを知らせていく必要があるとも感じました。
