最近Twitter(X)の読み込みが遅い件の検証

2025/02/27

お久しぶりです。

最近、旧Twitter（現X）の読み込みが遅いときがあります。とくに画像など。

https://x.com/1nagawa/status/1884072241740251188

Twitter上で様々な情報が出ていますが、

どうやらTwitterの画像をホストしているCDNのFastlyの挙動が怪しいとのこと。

具体的には、Twitterの画像はpbs.twimg.comドメインで配信されていますが、

その実態はFastlyのCDNのエイリアスです。

本来、CDNの権威DNSサーバーはアクセス元のIPアドレスに基づいて

地理的またはネットワーク的に近い最適なエッジサーバーのIPアドレスを返すことで

アクセスを最適化しています。

ところが、特定の条件下で、地理的に遠いサーバーが返されることが多発しており、

それによってアクセスが遅くなっているというのが皆さんの推測のようです。

検証

というわけで、私の環境ではどうなるのか試してみました。

今回利用した回線は、IPv6+IPv4デュアルスタック環境です。

フレッツ光回線、IPv6はIPoE接続、IPv4はDS-LiteによるIPoE v4 over v6接続です。

プロバイダ(VNE)はアルテリアネットワークス(Xpass)です。

まずDNSを見てみます。

> nslookup pbs.twimg.com
サーバー: UnKnown
Address: [プロバイダのDNSキャッシュサーバー]

権限のない回答:
名前: dualstack.twimg.twitter.map.fastly.net
Addresses: 2a04:4e42:11::159
151.101.108.159
Aliases: pbs.twimg.com

IPv4アドレスとIPv6アドレスが返ってきました。

まずIPv4アドレスにpingしてみます。

> ping 151.101.108.159

151.101.108.159 に ping を送信しています 32 バイトのデータ:
151.101.108.159 からの応答: バイト数 =32 時間 =3ms TTL=58
151.101.108.159 からの応答: バイト数 =32 時間 =2ms TTL=58
151.101.108.159 からの応答: バイト数 =32 時間 =3ms TTL=58
151.101.108.159 からの応答: バイト数 =32 時間 =3ms TTL=58

151.101.108.159 の ping 統計:
パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、
ラウンドトリップの概算時間 (ミリ秒):
最小 = 2ms、最大 = 3ms、平均 = 2ms

平均RTT 2msです。高速ですね。

次にIPv6にping

> ping 2a04:4e42:11::159

2a04:4e42:11::159 に ping を送信しています 32 バイトのデータ:
2a04:4e42:11::159 からの応答: 時間 =124ms
2a04:4e42:11::159 からの応答: 時間 =126ms
2a04:4e42:11::159 からの応答: 時間 =125ms
2a04:4e42:11::159 からの応答: 時間 =126ms

2a04:4e42:11::159 の ping 統計:
パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、
ラウンドトリップの概算時間 (ミリ秒):
最小 = 124ms、最大 = 126ms、平均 = 125ms

平均RTT 125ms、遅いですね。

では、tracerouteしてみましょう。

問題のIPv6

> tracert pbs.twimg.com

dualstack.twimg.twitter.map.fastly.net [2a04:4e42:11::159] へのルートをトレースしています
経由するホップ数は最大 30 です:

1 <1 ms <1 ms <1 ms [端末のIPv6アドレス]
(中略：プロバイダの内部アドレス)
9 120 ms 120 ms 120 ms be3080.ccr71.tyo01.atlas.cogentco.com [2001:550:0:1000::9a36:57fd]
10 124 ms 124 ms 124 ms be2915.ccr71.gum01.atlas.cogentco.com [2001:550:0:1000::9a36:5b7e]
11 121 ms 121 ms 121 ms be4130.ccr42.lax01.atlas.cogentco.com [2001:550:0:1000::9a36:5ae]
12 * * * 要求がタイムアウトしました。
13 * * * 要求がタイムアウトしました。
14 122 ms * * be2345.rcr21.lax06.atlas.cogentco.com [2001:550:0:1000::9a36:5aca]
15 121 ms 122 ms 122 ms 2001:550:2:1a::50:1d
16 124 ms 125 ms 125 ms 2a04:4e42:11::159

トレースを完了しました。

凄い経路を通っていますね。

プロバイダから、cogentcoのトランジット(?)を経由して、東京からグアム経由でロサンゼルスまで行って、

ロサンゼルス付近のサーバーからデータを取得しているようです。

それは遅くなるわけです。

ちなみにIPv4は

> tracert 151.101.108.159

151.101.108.159 へのルートをトレースしています。経由するホップ数は最大 30 です

1 <1 ms <1 ms <1 ms [端末のローカルIPv4アドレス]
2 2 ms 2 ms 2 ms [プロバイダのAFTRのIPv4アドレス？]
(中略:プロバイダの内部アドレス)
7 2 ms 2 ms 2 ms 151.101.108.159

トレースを完了しました。

151.101.108.159はipinfo.ioによると、Fastly東京のアドレスのようです。

なので、プロバイダと直接ピアリングしていて、地理的に近いところにアクセスしているから早いようです。