前幾天拉的遠傳e指雲遊方案的500M光纖
我這拿到的無論是動態IP還是固定IP 中國聯通過來都是繞路的
但從這條網路 ping / traceroute / mtr 中國聯通的IP 延遲都異常的低
仔細一測之後發現 其實遠傳把去中國的ICMP協議封包給劫持了 背後出去的IP根本不一樣
也就是遠傳把這些ICMP協議的封包NAT成別的IP出去 所以所呈現出的結果當然跟實際應用不一樣
營造出直連+低延遲的假象
02:31:13.218913 IP 210.68.1.1 > 221.229.x.x: ICMP echo request, id 134, seq 22402, length 40
02:31:13.219100 IP 221.229.x.x > 210.68.1.1: ICMP echo reply, id 134, seq 22402, length 40
02:31:14.221277 IP 210.68.1.1 > 221.229.x.x: ICMP echo request, id 134, seq 22460, length 40
02:31:14.221531 IP 221.229.x.x > 210.68.1.1: ICMP echo reply, id 134, seq 22460, length 40
02:31:15.227568 IP 210.68.1.5 > 221.229.x.x: ICMP echo request, id 134, seq 24550, length 40
02:31:15.227762 IP 221.229.x.x > 210.68.1.5: ICMP echo reply, id 134, seq 24550, length 40
02:31:16.227297 IP 210.68.1.6 > 221.229.x.x: ICMP echo request, id 134, seq 25305, length 40
02:31:16.227511 IP 221.229.x.x > 210.68.1.6: ICMP echo reply, id 134, seq 25305, length 40
背後出去的IP變成 210.68.1.x 且出去的IP是會跳動的
=> ICMP往中國電信、聯通方向測都是假的結果 跟實際使用情況根本不同
(ps. 被造假ICMP的IP已知在ip header的 record route 數據一定會被丟棄)
換成TCP測試 就現出原形了 其實基本上都是繞路的 高延遲+慢
既然遠傳會玩ICMP造假 那speedtest上或許也有可能利用這樣的方式
讓測速點背後NAT去不同的IP 仔細一測 的確如此
隨便取一個中國電信廣州的測速點 名字是"ChinaTelecom-GZ" ID: 17251
其測試點所在位置為 gzspeedtest.com:8080
(ps. speedtest 現在預設是使用8080 port做測速 但仍會保留80 port做備用或者其他用途)
以下為tcp trace 測試結果
tcp trace是現在才做的 因為是半夜兩邊延遲差距不大 但實際上在尖峰時段 延遲跟速度差距當然是好幾倍
所以往中國電信、聯通測速卻在尖峰也有速度 延遲也低 八成也是實際連到測速點的時候 IP根本不一樣
遠傳 210.68段的路由是比較好 所以大概遠傳讓這些測速跟ICMP ping之類的東西都偷偷NAT用這個網段的IP出去
說真的 這樣造假不是很容易找到破綻啦 大陸測過來300ms 台灣測過去卻不到100ms 肯定有鬼
不過本來是做好本來大陸就不會直連的打算 連大陸就用其他ISP連
不過發現遠傳在營造直連假象 反而讓我有點不愉快
NeverGiveUp!! wrote:
參考某樓某張圖.若...(恕刪)
遠傳去 129.250.35.250 的確是連去台灣啊 只是 "回程繞路"罷了
如果正常去日本 延遲會是32ms左右
請善用 https://ssp.pme.gin.ntt.net/lg/lg.cgi 測試
簡單來說就是遠傳八成為了costdown
將遠傳的NTT 優先權降低 *AS path prepend - 即加長路徑 讓NTT選擇的最佳路徑變更
導致路由是 NTT -> FlagTel -> 遠傳
但NTT跟FlagTel這兩個ISP之間只在洛杉磯有互連
所以才會出現明明去台灣 卻是很高的延遲
====== 有關這點 遠傳根本不給改 他就是要costdown
關閉廣告