《我的用户在海外，为什么网站访问这么慢？——跨国网络延迟的奥秘》
首先，我们必须打破一个美丽的幻想：互联网，它不是一朵飘在天上的“云”，它是一个由无数根深埋地下的、横跨大洋的物理电缆，以及无数个分布在全球各地的物理设备组成的，一个巨大的、实实在在的“地球蜘蛛网”。
你的网站数据，从你位于上海的服务器，传到一个纽约用户的手机上，它不是靠“魔法”瞬间转移过去的。它，需要一场真实的、漫长的“跨国旅行”。
而这场旅行的速度，有一个无法被打破的物理学天花板——光速。
即便是在真空中，光速旅行也需要时间。一个光信号绕地球一圈，大约需要134毫秒。而在光纤电缆里，由于介质的折射，它的速度还要再打个七折。
这意味着，仅仅是数据在光缆里跑个来回，从上海到纽约，就要花掉上百毫秒。这还只是理论上的最佳情况。
在现实世界里，你的数据经历的这场“跨国旅行”，远比这要复杂和颠簸得多。
一场充满“转机”和“安检”的跨洋航班
把你的网站数据包，想象成一个要去纽约的旅客。而你的服务器，就是上海的始发机场。
这位“旅客”的旅程，并不是“嗖”地一下，从上海直飞纽约。它的真实路线更像是这样：
无数次的“转机”——路由节点数据包在互联网上的传输，需要经过一个个“路由节点”的指引。每一个节点，就像一个“中转机场”。数据包每到一个“机场”，就需要“下飞机”（被路由器接收），查看一下“登机牌”（目标地址），然后被分配到下一个航班的“登机口”（被转发到下一个节点）。 从上海到纽约，你的数据包可能要经历几十次这样的“转机”。每一次“转机”，哪怕只增加几毫秒的“逗留时间”，几十次累加起来，也是一个非常可观的数字。
拥挤的“空中管制”——网络拥堵连接各大洲的，是有限的几条海底光缆。你可以把它们想象成连接上海和纽约的几条固定航线。 在上网高峰期，这几条航线上会挤满来自全球各地的“航班”（数据包）。当“航班”数量超过航线容量时，就会发生“空中管制”——也就是网络拥堵。你的数据包可能会被要求“在空中盘旋等待”，甚至被告知“本次航班取消，请换乘下一班”。
颠簸的“气流”——丢包在长距离传输中，由于网络拥堵或设备故障，总有一些数据包会“失踪”，我们称之为“丢包”。 这就好比，你托运了三件行李，结果到了纽约，只找到两件。航空公司（网络协议）必须启动一套复杂的查询、确认流程，然后从始发地（你的服务器）重新把那件丢失的行李再发一次。 这个“重新发送”的过程，带来的延迟是巨大的。在跨国网络中，哪怕只有1%的丢包率，都可能让你的网站加载时间翻倍。
跨越太平洋的“礼貌问候”：致命的握手延迟
好了，即便我们假设旅途一路顺畅，没有任何拥堵和丢包，跨国访问还有一个最致命的延迟来源——连接“握手”。
你的用户的浏览器，在能下载任何东西之前，必须先和你的服务器建立一个稳定、安全的连接。这个过程，就像两个初次见面的生意伙伴，需要经过一套礼貌的、一来一回的“握手”流程。
TCP握手：浏览器先发一个请求：“嗨，你在吗？我想和你建个连接。”（第一次跨洋）服务器收到后回复：“在呢，我准备好了，你呢？”（第二次跨洋）浏览器再回复：“我也准备好了，开始吧！”（第三次跨洋）。这“三步握手”，至少需要1.5个跨洋往返的时间。
TLS/SSL握手：如果你的网站是HTTPS的（现在必须是），那在TCP握手之后，还需要进行更复杂的“安全握手”。双方需要交换证书、验证身份、商定加密密钥……这个过程，根据配置不同，可能需要1-2个额外的跨洋往返。
现在，我们来算一笔简单的账。
假设从纽约到你的上海服务器，单程物理延迟是120毫秒，那么一个往返（Round-Trip Time, RTT）就是240毫秒。
那么，在你的网站开始传输任何一个字节的内容之前，仅仅是为了完成这套“礼貌的问候”，就需要花费：(1.5 + 2) * 240毫秒 = 840毫秒。
将近1秒钟的时间就这么过去了！而你的用户看到的，依旧是一片白屏。这个“建立连接的延迟”，就是为什么海外用户访问你的网站时，会感觉“半天没反应”的根本原因。
“千刀万剐”的加载过程
完成了漫长的“握手”，终于可以开始加载网站内容了。但你别忘了，一个现代网页，通常由上百个独立的“小文件”组成：CSS文件、JS脚本、几十张图片、字体文件……
浏览器需要为每一个文件，都向你的服务器发起一次请求。
虽然现代技术（如HTTP/2）可以并行处理很多请求，但每一次请求，依然包含了一次跨越太平洋的“旅行”。
你的本地用户访问，RTT可能是20毫秒。加载100个文件，累积的延迟可能并不明显。
你的纽约用户访问，RTT是240毫秒。加载100个文件，这“千刀万剐”累积起来的延迟，就是灾难性的。
这就是为什么，一个在你本地1秒就能打开的网站，一个海外用户可能需要等到8秒、10秒甚至更久。这中间的巨大鸿沟，就是“物理距离”这道不可逾越的墙。
所以，现在你明白了。你的海外用户访问慢，可能不是你的服务器性能差，不是你的图片没压缩，而是因为你和你的用户之间，隔着一个浩瀚的太平洋。你无法打破光速的限制，也无法搬走那些路由节点，更无法填平这片大洋。
那么，问题来了。
既然服务器只能放在一个地方，而你的用户遍布全世界，这个由物理定律决定的“死结”，到底该怎么解？
如果……我是说如果，你有一种方法，可以把你的网站“复制”无数份，在全球每个大洲、每个国家，都放一个“分身”呢？这样，纽约的用户，就可以直接从你位于纽约的“分身”那里拿数据，伦敦的用户，可以从伦敦的“分身”那里拿……
这样一来，所有跨国旅行，不就都变成了“同城快递”了吗？
