地理位置与网络延迟的变化
为什么同一台新加坡服务器，深圳 30ms，而成都 220ms？
最近从深圳回到成都后，我发现自己的服务器访问体验明显变差。
深圳时：
1 | PING www.kris-zhang.com (47.236.74.227): 56 data bytes |
成都时：
1 | PING www.kris-zhang.com (47.236.74.227): 56 data bytes |
同一台服务器换了访问地点，延迟就从约 30 ms 上升到约 220 ms。
一、距离更远？
最开始的猜想很自然：
深圳离新加坡近，成都离新加坡远，所以成都访问新加坡更慢。
从地图上看，这个判断似乎成立。深圳靠近香港和华南出海方向，而成都位于中国西南内陆，物理距离确实更长。
但这个解释并不完整。
如果只是地理距离增加，延迟不应该从 30 ms 直接变成 220 ms。真正的问题应该不只是“离得远”，而是数据在网络中实际走过的路径发生了变化。
二、核心原因：路径变了，而不是服务器变了
可以先用一个简化模型理解。
深圳访问新加坡时，理想情况下可能是：
1 | 深圳 → 香港 → 新加坡 |
这条路径方向比较顺：深圳靠近华南和香港出口，访问东南亚节点时，天然更容易走南向链路。
而成都访问同一台新加坡服务器时，路径可能变成：
1 | 成都 → 中部节点 → 上海 / 广州 → 国际出口 → 海外骨干 → 新加坡 |
也就是说，成都并不是直接“向南”连到新加坡，而是先进入国内骨干网，再被汇聚到某个国际出口，然后才进入海外网络
这就是深圳和成都延迟差异的关键：
- 深圳：靠近南向出口，路径更短、更直接；
- 成都：属于内陆访问，需要先进入骨干网汇聚，再从沿海或核心出口出境。
因此，同一台服务器在不同城市访问时，体验差异可能非常大。
三、国际出口集中，出海后也不一定走最短线
中国大陆的国际出口并不是均匀分布在每个城市，而是集中在少数核心区域。
可以粗略理解为：
- 上海：东向出口，常见于日本、美国方向；
- 广州 / 深圳 / 香港：南向出口，常见于东南亚方向；
- 北京：北向出口，常见于日韩、俄罗斯等方向。
因此，内陆城市访问境外资源时，通常需要先经过运营商国内骨干网络，再汇聚到这些国际出口区域。
不过，即使流量已经到了沿海出口，也不代表它一定会沿着地理最短的海缆去新加坡。
东亚和东南亚之间存在多条海底光缆系统，例如：
- APG
- APCN-2
- EAC-C2C
- SJC / SJC2
这些线路不是用户自己选择的。实际走哪条，取决于运营商之间的路由策略、互联关系、链路成本和拥塞情况。
所以即使目标是新加坡，流量也可能出现：
1 | 成都 → 上海 → 日本 → 新加坡 |
而不是直觉中的：
1 | 成都 → 深圳 / 香港 → 新加坡 |
这也是为什么“距离近”不等于“延迟低”。
四、如何验证：用 traceroute 看路径方向
想知道自己的流量大概怎么走，最直接的方法是做路由追踪。
Linux / macOS 可以使用：
1 | mtr -rw 服务器域名 |
或：
1 | traceroute 服务器域名 |
Windows 可以使用：
1 | tracert 服务器域名 |
需要注意的是，traceroute / tracert 并不能还原完整网络拓扑。
它只能通过逐跳探测，大致观察数据包经过哪些路由节点。很多运营商骨干节点不会回复 ICMP，或者会隐藏真实名称，所以结果中经常出现：
1 | * * * 请求超时 |
这不一定代表链路断了，而是该节点没有响应探测包。
因此，路由追踪更适合用来判断三件事：
- 流量大致经过哪些运营商网络；
- 延迟在哪一段开始明显升高；
- 是否出现了绕路
五、traceroute 路径分析
为了确认流量到底走了什么路径，对 www.kris-zhang.com 做了一次 tracert。
1 | 通过最多 30 个跃点跟踪 |
需要说明的是：tracert 中的 * 并不等于链路中断。它通常表示该跳路由器没有回复 ICMP 探测包，或者对 traceroute 类型的探测做了限速或丢弃。因此，这份结果更适合用来判断路径方向和延迟突变位置，而不是还原完整网络拓扑。
从路径上看，可以把这次访问拆成四段。
1. 本地接入段：家庭网关与运营商内网
1 | 1 3 ms 2 ms 2 ms TianYi.Home [192.168.1.1] |
第 1 跳是家庭网关，也就是本地路由器。
第 2 跳的 100.77.47.1 属于 100.64.0.0/10 这个运营商级 NAT 常用地址段，通常出现在宽带运营商内部网络中。它不是公网目标服务器，而是用户接入运营商网络后的中间转发节点。
这一段延迟只有几毫秒，说明本地接入没有明显问题。
2. 四川电信 / ChinaNet 国内段
1 | 3 7 ms 4 ms 10 ms 61.139.108.202 |
第 3 到第 6 跳仍然属于中国电信网络范围。
其中 202.97.x.x 是典型的 ChinaNet 骨干网地址段。公开 ASN 数据显示，202.97.0.0/16 属于 AS4134 CHINANET BACKBONE，也就是中国电信骨干网。
这里的关键不是每个 IP 的城市归属，而是延迟变化：
1 | 本地 / 省内段：约 5–10 ms |
这说明流量已经从本地接入网络进入更高层级的国内骨干网。
IP 地理库可能会把某些骨干节点标注为成都、南京、北京或上海，但这类地理位置只能作为参考。骨干网 IP 经常存在地址注册地、设备物理位置、路由实际位置不完全一致的情况，因此不能只凭 IP 地理库判断真实机房位置。
3. ChinaNet 国际出口段：延迟第一次明显上升
1 | 7 * * * 请求超时。 |
第 9 跳是整条路径中第一个明显的转折点。
前面第 6 跳大约是 30 ms，到第 9 跳已经变成接近 200 ms。这说明流量很可能已经进入中国电信国际骨干 / 国际出口相关路径。
公开数据库显示，202.97.41.0/24 属于 AS4134 CHINANET BACKBONE，其 BGP 上级范围为 202.97.32.0/19。
这里可以得出一个重要判断：
延迟不是在最后到达阿里云服务器时才突然变高，而是在 ChinaNet 国际出口段附近已经被明显拉高。
4. Tata AS6453 海外骨干：日本千叶到新加坡
1 | 11 * * 358 ms if-bundle-6-2.qcore2.kv8-chiba.as6453.net [180.87.151.40] |
从第 11 跳开始，路径已经进入 Tata Communications 的国际骨干网。
这里的判断依据非常明确：反向域名中出现了 as6453.net，而公开路由数据库显示，180.87.151.0/24 属于 AS6453 TATA COMMUNICATIONS。
其中：
kv8-chiba.as6453.net：指向 Tata 在日本千叶 / 东京区域的骨干节点svw-singapore.as6453.net：指向 Tata 新加坡节点esin4-singapore.as6453.net：同样指向 Tata 新加坡方向骨干节点
也就是说，成都访问新加坡服务器时，并没有直接通过地理位置最优的：
成都 → 华南 / 香港 → 新加坡
而是出现了：
成都 → ChinaNet 国际出口 → Tata AS6453 → 日本千叶 → 新加坡
这也是延迟显著升高的核心原因之一：目标服务器在新加坡，但国际骨干路径中间绕到了日本方向。
5. 目标服务器：阿里云新加坡
1 | 17 223 ms 220 ms 219 ms www.kris-zhang.com [47.236.74.227] |
最后一跳回到目标服务器 47.236.74.227。
虽然中间 Tata 节点显示过 356–360 ms，但最终目标服务器响应约为 220 ms。这说明中间节点的 ICMP 响应延迟不能完全等同于真实业务延迟。部分骨干路由器可能对 ICMP 探测包进行限速，或者返回路径与实际业务流量路径不完全一致。
因此，最终服务器的 220 ms 更接近实际访问体验，而中间跳数更适合用来判断路径方向。
6. 小结
通过tracert的结果分析，不用太在意每个 IP 的城市地理位置。尤其是 202.97.x.x 这类骨干网地址，地理库可能给出北京、南京、上海等不同结果，但真实转发位置不一定完全对应。这里更可靠的判断依据是 ASN、反向域名和延迟突变。
358 ms 的 Tata 中间节点不一定代表业务请求真的有 358 ms。骨干路由器经常对 ICMP 探测低优先级处理，所以最终 47.236.74.227 的 219–223 ms 才更接近实际端到端延迟。
六、从 traceroute 看 AS 与 BGP
上一节的 traceroute 结果里，最关键的现象是：
1 | 202.97.x.x → 中国电信 ChinaNet |
也就是说，这次访问并不是在“中国电信自己的网络里一路走到新加坡”，而是经历了多个不同的网络：
1 | 成都电信 |
这就引出了一个重要概念：
互联网并不是一个统一的大网络，而是由很多独立网络拼接起来的。
这些独立网络就被称为：自治系统（AS，Autonomous System）
可以简单理解为 一个由同一组织管理、使用统一路由策略的网络。
例如：
- 中国电信 ChinaNet：AS4134
- Tata Communications：AS6453
- 阿里云：AS45102
- Cloudflare：AS13335
- Google：AS15169
每个 AS 都维护自己的网络，也会对外声明：
1 | 哪些 IP 网段可以从我这里到达 |
例如，阿里云会向上游网络宣告：
1 | 47.236.x.x 这一类地址可以从我这里到达 |
Tata 收到后，再把这条可达信息传播给其他网络。中国电信也会通过类似机制知道：
1 | 要去 47.236.74.227，可以把流量交给某个国际上游或互联网络 |
不同 AS 之间交换这种“可达信息”的协议，就是BGP（Border Gateway Protocol，边界网关协议）
BGP 的作用不是让数据全网搜索目标，而是让每个网络提前知道：去某个 IP 网段，大概应该往哪个方向交给下一跳
当用户访问 47.236.74.227 时，数据包并不会在互联网上到处寻找这台服务器，而是每到一个路由节点，就查一次路由表：
1 | 目标IP：47.236.74.227 |
每个节点只需要知道“下一跳”，不需要知道完整路径。
所以一次访问大致是：
1 | 你的电脑 |
BGP 并不是地理最短路径算法。它并不单纯按照地图距离选择路线，而会受到很多因素影响：
- 运营商之间的互联关系
- 链路成本
- 出口带宽
- 网络拥塞
- 商业结算关系
- 本地路由策略
- 某条线路是否可用或优先
所以，这次 traceroute 中出现的路径：成都 → 日本 → 新加坡，从地理直觉看并不理想，但从 BGP 策略角度看，它可能是中国电信到阿里云新加坡这段网络当前选择的一条国际路径。
因此，在服务器优化延迟的case中，选择更容易走到优路径的接入网络和目标节点往往是比较重要的。需要结合实际访问地区、运营商和 traceroute 结果一起判断。
七、路径虽无法控制，但网络识别仍可发生
BGP 负责：
1 | 这个数据包应该往哪里转发 |
而流量识别关注的是：
1 | 这个连接想访问什么 |
也就是说，网络设备并不需要知道数据包后面会经过哪些国家、哪些运营商、哪些海底光缆，它只需要在连接建立早期识别出你想访问哪个目标；
以访问 www.google.com 为例。
在真正建立网页连接之前，通常会先发生几类信息暴露。
第一类是 DNS 查询。
用户输入：
1 | www.google.com |
系统需要先把域名解析成 IP 地址。
如果 DNS 查询没有加密，中间网络就可能看到：
1 | 用户正在查询 www.google.com |
这时即使连接还没有真正建立，访问意图已经出现了。
第二类是 TLS SNI。
很多 HTTPS 连接在 TLS 握手阶段，会带上一个字段：
1 | Server Name Indication |
也就是 SNI。
它的作用是告诉服务器：
1 | 我要访问的是哪个域名 |
例如：
1 | www.google.com |
在传统 TLS 中，SNI 通常是明文可见的。也就是说，即使网页内容本身是 HTTPS 加密的，连接初期的目标域名仍可能被中间设备看到。
因此，网络设备不需要等数据真正到达 Google，也不需要知道后续路径，只要在国际出口或骨干网边界看到 SNI，就能判断这条连接的目标。
第三类是目标 IP。
有些服务的 IP 地址段本身就具有明显归属。
例如某些 Google、Meta、Cloudflare 或大型云服务商的 IP 段，在公开路由表中就可以看到所属 AS 和网段信息。
因此，即使不看域名，只看目标 IP，有时也可以大致判断访问对象。
第四类是流量特征。
除了域名和 IP，网络设备还可以根据连接行为判断流量类型，例如：
- TLS 指纹
- 连接频率
- 包大小分布
- 长连接特征
- 是否像代理或隧道流量
这类识别不一定依赖具体域名，而是通过行为模式判断流量性质。
因此，网络识别不需要控制 BGP，也不需要知道完整路径，它是在关键节点检查：
1 | 这条连接要去哪里？ |
常见处理方式包括：
- DNS 干扰
- TCP RST 重置
- 丢包
- 限速
- 针对特定 IP 或特征进行阻断
写不下去了，结束。
