买服务器的时候，大多数人只看一个指标：延迟。Ping 一下测试 IP，看到 50ms 就觉得“稳了”。但这个数字只告诉你一半的事实。它衡量的是数据包从你的电脑出发、到达服务器、再返回的时间总和，却无法告诉你这两段路程各自走了什么路。而恰恰是这两段路程的差异，决定了你的服务器在真实使用中会不会出现“白天正常、晚高峰炸裂”的窘境。

　　去程和回程，说的是什么

　　网络通信是双向的。你访问一个网站，请求从你的设备发往服务器，这是去程;服务器处理完请求后把数据返回给你，这是回程。

　　在理想世界里，去程和回程应该走同一条路——从 A 到 B 经过哪些路由器，从 B 到 A 就反向经过同样的节点。这种状态叫“对称路由”。但互联网的现实运行方式决定了，对称反而是特例，不对称才是常态。

　　APNIC 的技术博客里解释得很清楚：传统的 IP 路由决策只基于目的地址。当一个网络有多个出口、多条可用路径时，去程和回程完全可能选择不同的线路。非对称路由在拥有多条网络路径的企业环境中是“常见现象”。

　　学术研究的数据更直观。IEEE 的一项大规模测量发现，超过 90% 的 TCP 流在传输过程中经历了某种形式的非对称路由，超过 70% 的流在 IP 层面就出现了去程和回程走不同链路的情况。

　　为什么去程和回程会“分道扬镳”

　　根本原因在于，互联网不是一个统一调度的网络，而是数万个自治系统(AS)通过 BGP 协议互相“协商”出来的。每个 AS 独立决定自己的流量往哪里送，决策依据往往是自身的成本结构和商业策略，而不是端到端的全局最优。

　　最典型的机制是“热土豆路由”(Hot Potato Routing)。假设你在加利福尼亚，访问纽约的一台服务器。你的 ISP 和对方的 ISP 都在全美有网络覆盖。当数据包需要跨东西海岸传输时，两边的 ISP 都想让对方承担这段昂贵的跨州链路。于是你的 ISP 会尽可能早地把包“扔”给对方的网络——在加州就交接了。反过来，对方的服务器回数据给你时，对方的 ISP 也会用同样的逻辑，在纽约就把包扔回给你的 ISP。

　　结果是：去程可能在加州交接，回程在纽约交接。两段路程经过的路由器、链路、甚至运营商都完全不同。这就是去程和回程分化的底层逻辑。

　　除了“热土豆”，还有其他因素会加剧这种不对称：BGP 的路径选择规则(比如优先选择子网掩码更长的路由)、多出口网络的负载均衡策略、以及网络故障后的临时路由调整，都会让去程和回程走上不同的路。

　　为什么“只看去程”会害了你

　　理解了去程和回程可能走不同的路，就能明白为什么很多人在选服务器时会“踩坑”。

　　一个最常见的场景是：你在国内 Ping 一台美国服务器，看到延迟 160ms，觉得还可以接受。但这个 Ping 测的是去程 + 回程的总和，你并不知道其中哪一段是瓶颈。如果去程走了优质线路(比如 CN2 GIA)，但回程走了拥堵的普通 163 骨干网，实际体验会是什么样?你发出的请求很快到达服务器，服务器处理也很快，但返回的数据卡在了回程的拥堵链路上。用户感受到的就是“点了一下，等半天才出来”。

　　一个真实案例：一台香港服务器，去程确实走 CN2 直连，但回程却绕道了美国或新加坡。这种非对称路由导致数据包在长途绕行中出现高丢包率，用户端表现为“连接频繁中断”。

　　这就是为什么服务商的 Looking Glass 工具如此重要。普通的 Ping 只能从你的位置往外测去程，而 Looking Glass 允许你从服务器端往外 Trace 回程——也就是“站在服务器的角度看数据包返回中国会经过哪些节点”。只有两段都测过，你才知道这条线路是不是“双向优化”。

　　CN2 的“半程优化”陷阱

　　中美线路市场是理解去程/回程不对称的最佳案例。

　　CN2 是中国电信的下一代承载网，其中 CN2 GIA 是最高等级的线路，有独立的回国通道，优先级最高，晚高峰丢包率可以控制在极低水平。但市场上大量标着“CN2”的美国服务器，实际上只做了回程优化。

　　原因在于：回程(美国→中国)的路径由服务器所在的机房和其上游带宽提供商控制。服务商只要接入了 AS4809(CN2 的 AS 号)，就能保证从服务器返回中国的数据走 CN2。但去程(中国→美国)的路径由中国电信的路由策略决定，服务商几乎无法“强制”中国电信把去程流量送到自己这里。

　　这就造成了“单向 CN2”的现象：回程很快，去程还是走普通 163 骨干网。白天感觉不明显，晚高峰 163 拥堵时，你的请求发出去了，但卡在去程的路上迟迟到不了服务器。

　　非对称路由带来的实际问题

　　去程和回程不一致，不只是“慢一点”的问题。它会引发一系列连锁反应。

　　状态防火墙会误杀数据包。 防火墙是“有状态”的设备：它看到流量的第一个包通过时，会在状态表里记录这条连接的信息，后续的包只要匹配状态表就放行。但如果回程的包从另一个接口到达，防火墙没有这条连接的记录，就会把它当作非法流量直接丢弃。

　　源地址验证会误判。 网络中的 uRPF(单播反向路径转发)机制通过检查数据包的源地址是否从“正确”的接口到达来防止 IP 欺骗。但在非对称路由下，合法流量的回程可能从非预期接口进入，严格的 uRPF 会将其判定为伪造流量并丢弃。

　　故障定位会变得极其困难。 如果你只从一端做 traceroute，你看到的只是去程的路径。如果问题出在回程的某个节点——比如某条链路拥塞、某个路由器故障——你在去程的 traceroute 里完全看不到。这就是为什么排障时需要“双向追踪”：从两端分别 trace，才能拼出完整的路径图。

　　双向测试到底该怎么测

　　理论说完了，落到操作层面其实不复杂。核心原则是：从两个方向分别做路由追踪，而不是只从一端 Ping。

　　具体来说，你需要做两件事：

　　从本地到服务器，测去程。 在你自己的电脑或国内测试节点上执行 traceroute 或 mtr 到服务器 IP。观察路径中经过的节点，判断是否走了你预期的线路(比如 CN2 的 59.43.x.x 段、联通的 9929 段、移动的 CMIN2 段)。

　　从服务器到本地，测回程。 这才是大多数人忽略的一步。你需要在服务器上执行 traceroute 到你的本地 IP(或者国内知名测试节点)。回程测试应该通过服务商的 Looking Glass 工具来做，因为这相当于“站在服务器的角度看世界”。

　　一个实操技巧：用 MTR 代替单纯 traceroute。 MTR 结合了 traceroute 和 ping 的功能，能显示每一跳的延迟和丢包率，更容易定位瓶颈出现在哪个节点。

　　测试时机也很重要。 白天测和晚高峰(20:00-23:00)测，结果可能完全不同。很多非对称路由的问题在低负载时段不会暴露，只有网络拥塞时才会显现。

　　常见问答

　　问：为什么我 Ping 服务器延迟很低，但访问还是很慢?

　　答：Ping 测的是往返总延迟，但不反映丢包率和路径质量。如果去程或回程的某一段有隐性丢包(比如 1%-3%)，Ping 的平均值可能看起来正常，但实际传输中 TCP 会频繁重传，用户感受到的就是“卡顿”而非“延迟高”。用 MTR 分别测去程和回程，看每一跳的丢包率，才能找到真正的问题。

　　问：服务商说“CN2 优化”，我怎么判断是不是双向的?

　　答：要求服务商提供 Looking Glass 地址或测试 IP。从国内 traceroute 到服务器测去程，再从服务器 traceroute 回国内测回程。如果回程出现了 41.144 或 183 开头的 IP 段，那很可能是 163 回程，不是真正的双向 CN2 GIA。双向 CN2 GIA 的回程应该全程走 59.43.x.x 段。

　　问：非对称路由对我的业务有什么实际影响?

　　答：取决于业务类型。以内容下发为主的业务(图片、视频、静态页面)，回程质量影响更大，因为用户主要是“接收”数据。以交互为主的业务(SSH 操作、数据库查询、游戏)，去程质量同样关键，因为你的指令需要快速到达服务器。如果两端都有大量交互，去程和回程都必须稳定。

　　问：为什么有些服务商只保证回程 CN2，不保证去程?

　　答：因为去程的路径由中国电信、联通、移动等 ISP 的路由策略决定，服务商无法“强制”这些 ISP 把流量送到自己的网络。服务商能做的是接入 CN2 的上游，保证自己发出的流量走 CN2(回程)。去程优化需要 ISP 端的配合，这不是单个服务商能完全控制的。

　　问：用 CDN 能不能绕过非对称路由的问题?

　　答：部分能。CDN 的本质是把静态内容缓存到离用户更近的边缘节点，用户请求动态内容时才会回源。如果回源路径有问题，动态请求仍然会受影响。但静态资源的加载速度会明显改善，整体体验会有提升。对于交互密集型的应用(如在线编辑、实时协作)，CDN 无法替代源站线路本身的优化。