如何选择服务器机房地点：延迟、线路与法律

机房地点是少数几个无法事后靠更快的 CPU 来弥补的基础设施决策之一。服务器与用户之间的距离决定了延迟的下限，任何硬件都无法消除；数据所在的国家则决定了它适用哪些法规。下面我们用与延迟估算相同的公式，带您把这两方面想清楚。

物理定律：每毫秒约 200 km

光在光纤中的传播速度约为真空中光速的三分之二：每秒约 200,000 km，即每毫秒 200 km。一次请求及其响应要把这段距离走两遍，因此您与用户之间每相隔 1,000 km，往返时间（RTT）就至少增加 10 ms。

实际路径总比地图上的更长。光缆沿着海岸线、铁路和公路铺设；流量要在特定的互联点切换网络；而 BGP 选路依据的是商业策略，而非地理位置。路由器在每一跳还会增加少许延迟。因此，我们的延迟数据这样计算：将大圆距离乘以 1.3 以计入路由绕行，除以 200 km/ms，再将结果翻倍得到往返时间，最后加上 2 ms 的设备延迟：

estimated RTT (ms) = 2 × (distance in km × 1.3 / 200) + 2

以上均为估算值，而非实测值：网络拥塞或绕路可能让延迟大幅增加，而且回程路径也可能与去程不同。

为什么往返时间比带宽更重要

互联网上的大多数交互都由一连串往返组成，而每一次往返都要受制于光速：

• 建立连接。基于 TCP 的新 HTTPS 连接，在收到响应的第一个字节之前，要在 TCP 握手上花一个往返，在 TLS 1.3 握手上花一个往返，请求本身再花一个往返。按预估 20 ms 计算，三个往返共需 60 ms；若为 150 ms，则需 450 ms。
• TCP 慢启动。新连接起初只发送约 10 个数据包（约 14 KB），此后每个往返大约翻一番。照这种方式传输 1 MB 数据，无论端口速率多高，都需要大约七个往返：RTT 为 20 ms 时约需 140 ms，RTT 为 150 ms 时则超过一秒。
• 网页与 API。先加载 HTML、再加载 CSS、然后加载字体的页面，会把一个个往返串联起来。依次发起 20 次调用的 API 客户端，就要付出 20 次 RTT。
• 数据库。每次查询至少要花一个往返。一个依次执行 30 条查询的请求，要在等待中耗费 30 个 RTT：在同一机房内，一次往返通常远低于一毫秒，这点开销可以忽略不计；而在 80 ms 的 RTT 下，则要耗费 2.4 秒。
• 游戏。RTT 就是玩家看到的 ping 值。服务器的 tick 率决定世界多久更新一次；ping 值则决定每次更新送达时已经滞后了多久。

正因如此，一台离用户近的服务器，往往比远在天边、性能更强的服务器感觉更快。

先看用户，再看数据

1. 找到您的用户。根据服务器日志，按国家或都市圈对流量或玩家群体进行分组，并按您最看重的指标为每组加权：收入、活跃玩家数或合同义务。
2. 估算 RTT：用延迟测试算出每组用户到各个候选机房的往返时间，再选出能让大部分加权用户落在目标值以内的机房。
3. 让计算靠近数据。如果您的数据库、对象存储或频繁调用的第三方 API 集中在某个地区，就把应用服务器也放在那里。应用与数据库之间的频繁交互，通常比用户到应用的流量对延迟更敏感。
4. 只有当一个机房无法很好地服务所有用户时，才考虑拆分。受众遍布欧洲、亚洲和美洲时，通常需要不止一个机房。

互联网交换中心与海底光缆

有两类公共基础设施，可以解释为什么有些城市比其他城市更适合充当枢纽。

互联网交换中心（IXP）是各个网络之间直接交换流量的地方。汇聚的网络越多，它们之间的路径往往越短。欧洲就是一个鲜明的例子：法兰克福有 DE-CIX，阿姆斯特丹有 AMS-IX，伦敦有 LINX，三者都跻身全球最大的互联网交换中心之列。

海底光缆承载着几乎所有的洲际流量，而它们只在少数几个地区登陆：

• 纽约是通往英国和欧洲大陆的跨大西洋海缆的传统登陆地区。
• 迈阿密是连接北美、加勒比地区和拉丁美洲的主要门户。
• 洛杉矶及美国西海岸其他地区，是众多通往亚洲和大洋洲的跨太平洋线路的枢纽。
• 新加坡连接着东南亚与印度、澳大利亚、中东和欧洲。
• 东京位于众多跨太平洋海缆的亚洲一端，是日本主要的网络互联枢纽，距首尔的预估延迟为 17 ms。

DediJet 的网络采用多线接入（multi-homed）：每个机房都通过 BGP 连接多家上游运营商，并配有冗余上行链路。不过，网络互联发达的城市并不能保证到每位用户的路径都很短，这正是实测之所以重要的原因。

法律：数据存放在哪里

服务器的地点还决定了数据的物理存放位置，而法规或合同可能对此有所要求。以下事实可以帮助您与法务团队展开讨论：

• 地点并不能决定一切。GDPR 适用于在欧盟设立的组织，也适用于向欧盟境内人士提供商品或服务、或监控其行为的组织，无论服务器位于何处。把服务器放在法兰克福并不会免除这些义务，放在纽约也无法规避它们。
• 跨境传输有规则。GDPR、英国 GDPR、新加坡的 PDPA 和日本的 APPI 都限制向境外传输个人数据，除非目的地能提供同等的保护，或适用其他保障措施，例如合同条款或当事人同意。
• 合同可能比法律更严格。公共部门、医疗和金融领域的客户可能要求数据必须留存在特定国家或地区。

一个机房不够用时

• 分区域部署服务器。用户遍布多个大洲的游戏社区和 SaaS 产品，通常会在每个区域各运行一台服务器，让每台都靠近当地用户，再通过 GeoDNS 或按区域划分的主机名（例如 eu.example.com）为用户分流。
• 跨区域采用异步复制。同步提交至少要等待副本一个往返：法兰克福与新加坡之间预估为 135 ms。请将同步副本放在同一机房内，对远端副本则采用异步复制。
• 机房之间使用加密链路。免费的私有 VLAN（可应要求开通）能连接同一机房内的服务器。跨机房的流量要经过公共互联网，因此请使用 WireGuard 或 IPsec 加以保护。
• 备份要异地存放。至少在主服务器所在机房之外保留一份备份。
• 各地硬件一致。Ryzen 5 7600 和 Ryzen 7 9700X 在全部 8 个机房均有提供，让多区域服务器集群保持配置统一。

跨区域复制的流量同样不按 GB 计费：每款配置的带宽均按其端口速率不限流量。

先估算，再实测

先用延迟测试根据用户所在城市筛选出候选机房，再查看我们 8 个机房各自的库存情况。服务器运行起来之后，再从用户所在的位置实测真实路径：

mtr -rwc 50 203.0.113.10
ping -c 20 203.0.113.10

mtr 结合了 traceroute 和 ping 的功能，能让您看清延迟或丢包出现在路径上的哪个环节。我们的网络测试指南介绍了如何解读输出结果。按月计费、没有长期合约束缚，日后要换到更合适的机房，只是一次迁移，而不是一场合同谈判。