评判一张托管网络，看的是它最糟糕的一天，而不是平均表现。我们的网络围绕一个简单的想法构建：每个枢纽节点至少有三条相互独立的出口通往互联网，同时尽可能让更多流量根本不经过 transit，而是在公共对等互联点直接交换。本文介绍这套组合、我们如何选路，以及某家运营商出问题的那一天会发生什么。
Transit：每个枢纽三家上游
法兰克福、纽约和新加坡各自接入三家 transit 服务商，线路经由物理上相互独立的路径进入机楼，并终结在不同的路由器上。选择服务商时，我们刻意追求骨干网本身的多样性：一家拥有全球网络的 Tier 1 运营商，一家在本国范围内覆盖密集的欧洲大型运营商或区域性运营商，第三家则拥有另一批不同的下游客户。阿姆斯特丹、赫尔辛基和洛杉矶各有两家上游，另有一条通往最近枢纽的私有骨干链路，当本地两家上游都出现性能下降时，由它承载流量。
有了三家，哪怕同一周里一家运营商发生故障、第二家正在维护、第三家又出现了路由泄漏，也没有人会察觉；这种情况已经出现过两次。
对等互联：就近交换
我们入驻了 DE-CIX Frankfurt、AMS-IX、位于纽约和新加坡的 Equinix IX，以及赫尔辛基和洛杉矶规模较小的本地交换中心，并奉行开放对等政策：只要有人提出申请，就能与我们建立会话。公共对等互联承载了我们在欧洲约 60% 的出站字节，在亚洲约 45%。发往大型内容网络、面向终端用户的 ISP 和云服务商的流量，会直接穿过交换中心的交换结构，只需一跳，完全不经过 transit 服务商的骨干网。
对您而言，这意味着到您的用户所在网络的跳数更少、抖动更低。对我们而言，则是 transit 出问题时只会影响少数流量，这正是故障切换波澜不惊的原因。
我们如何选路
BGP 默认选择 AS 路径最短的那条，而它往往并不是最快的。我们分三层来调整：
- 对等互联优先于 transit，通过 local preference 实现，因为直连会话几乎总是更好的路径。
- 优先选择最“干净”的 transit，前提是有多家上游通告了同一个前缀。一小批探针每分钟都会通过每一家上游，测量到数千个目标网络的丢包率和延迟。如果某家上游到某个目标的丢包率连续五分钟超过 0.5%，针对该目标就会被自动降低优先级；等测量结果恢复正常，它就会重新回来。
- 手工调校少数例外：对于个别遥远的目的地，如果最短路径要经过一个拥塞的交换中心，我们会为它们静态指定偏好，改走一条更长但更空闲的路线。
入站方向更难控制，因为互联网上的其他网络决定了如何到达我们。我们向每一家上游通告相同的前缀，只有当探针显示某条路径丢包时，才会用 prepend 和 community 引导流量绕开它，而绝不是为了省钱改走更便宜的运营商。
糟糕的一天是什么样子
上个季度，法兰克福的一家上游发生了骨干网故障，导致前往北美方向的目的地出现了 40% 的丢包，持续约一小时。探针在两分钟内就发现了问题，并针对受影响的前缀降低了该运营商的优先级；流量切换到另外两家上游，它们的容量按“任意一家都能承载整个节点”的标准规划。客户只感受到几分钟前往美国方向的延迟升高，别无其他影响。状态页为这段时间的法兰克福 transit 记录了一条“性能下降”，因为事实就是如此，尽管影响很小。
整个节点失去全部出口，才是这条骨干链路存在的意义：假如阿姆斯特丹的两家上游同时中断，它的流量会经由私有链路，从法兰克福出去。这条路径除了演练之外，从未承载过生产流量，而演练我们每年进行两次。
容量，以及容量规则
只要某条链路的第 95 百分位利用率连续两周超过 50%，我们就会为它扩容。这意味着，正常运行时，一条链路预计不会超过半满，另一半则留给相邻链路发生故障或需要吸收攻击的时刻。廉价托管之所以便宜，通常是因为有人跳过了这条规则；它是定价规则不会去触碰的少数几项成本之一。
亲自验证
- Looking Glass 可以展示从每个节点到任意地址的 BGP 路径、ping 和 traceroute 结果。
- 我们的 AS 已在 PeeringDB 登记，列明了所接入的交换中心和对等政策；通过那里的联系方式提交会话申请，几天之内就会得到回复。
- 状态页按节点把 transit 和对等互联列为独立组件，并保留历史记录，因此即使您没有感觉到，某家上游性能下降也一目了然。