如果你看过我们的另一篇文章，你就会知道我们今天发布了WARP到我们等待名单的最后一个成员。通过WARP，我们的目标是保护和改善移动设备和互联网之间的连接。在这个过程中，我们遇到了手机和操作系统版本、多样化网络和我们自己的基础设施的问题，所有这些都是为了满足近200万人被压抑的候补需求长。到了解所有这些问题以及我们如何解决这些问题，我们首先需要向您介绍一下Cloudflare网络是如何工作的工作：如何网络工作Cloudflare网络由分布在194个城市和90多个城市的数据中心组成国家。每个Cloudflare数据中心都由许多服务器组成，这些服务器接收源源不断的请求，并且必须在处理这些请求的服务器之间分发这些请求。我们使用一组路由器来实现这一点操作：我们的路由器监听在公共互联网上公布的选播IP地址。如果您在Cloudflare上有一个站点，那么您的站点可以通过以下两个地址访问。在这种情况下，我正在对"工人.dev"，由Cloudflare提供动力的站点：➜dig工人.dev；；问题部分：;工人.dev.在一个；；答案部分：工人.devA 198.41.215.162中的0.161工人.devA 198.41.214.162中的0.161；服务器：1.1.1.1#53（1.1.1.1）工人.dev位于两个地址198.41.215.162和198.41.214.162（以及通过AAAA DNS查询提供的两个IPv6地址）。这两个地址是从我们在世界各地的每个数据中心公布的。当有人连接到Cloudflare上的任何Internet属性时，其数据包通过的每个网络设备将选择从其计算机或电话。一次数据包到达我们的数据中心，我们将它们发送到在那里运行的众多服务器中的一个。传统上，可以使用负载平衡器跨多台机器进行这种类型的流量分配。不幸的是，在每个数据中心放置一组能够处理我们的流量的负载平衡器将非常昂贵，而且不会像我们的服务器那样容易扩展。取而代之的是，我们使用的设备是为在异常流量下运行而构建的：网络路由器。一次数据包到达我们的数据中心，由路由器处理。该路由器使用称为ECMP（等成本多路径）的路由策略将流量发送到负责处理该地址的一组服务器中的一个。ECMP指的是路由器在多条路由之间没有一个明确的"赢家"，它有多个好的下一跳，都指向同一个最终目的地。在我们的例子中，我们稍微改变了这个概念，而不是使用ECMP来平衡多个中间链接，而是让中间链接地址成为我们流量的最终目的地：我们的服务器。这里这是一个Juniper品牌路由器的配置，它可能位于我们的某个数据中心中，它的配置是为了平衡流量穿过三个目的地：user@host\显示路由选项静态{路线172.16.1.0/24下一跳[172.16.2.1 172.16.2.2 172.16.2.3]；}转发表{出口负载平衡策略；}因为"下一跳"是我们的服务器，所以流量将在多台机器上进行拆分高效.TCPIP和ECMPIP负责通过Internet将数据包从地址93.184.216.34发送到208.80.153.224（对于IPv6，则为[2606:2800:220:1:248:1893:25c8:1946]发送到[2620:0:860:ed1a:：1]）。它是"因特网协议"。TCP（传输控制协议）运行在IP这样的协议之上，它可以将数据包从一个地方发送到另一个地方，使数据传输在一次多个进程中可靠和有用。它负责接收不可靠和顺序错误的数据包，这些数据包可能通过IP等协议到达，并以正确的顺序可靠地传递它们。它还引入了"端口"的概念，即1-65535之间的数字，它帮助将计算机或电话上的流量路由到特定的服务（如web或电子邮件）。每个TCP连接都有一个源端口和目标端口，该端口包含在TCP添加到每个数据包开头的报头中。如果没有端口的概念，就很难确定哪些消息将发送给哪个程序。例如，googlechrome和Mail可能希望同时通过你的WiFi连接发送消息，因此他们将各自使用自己的消息港口。这里这是一个请求https://cloudflare.com/在198.41.215.162，在HTTPS的默认端口上：443。我的计算机随机地给我分配了51602端口，它将监听它的响应，它将（希望）接收站点：Internet协议版本4，Src:19.5.7.21，Dst:198.41.215.162协议：TCP（6）来源：19.5.7.21目的地：198.41.215.162传输控制协议，Src端口：51602，Dst端口：443，序列：0，长度：0源端口：51602目的港：443从Cloudflare端查看相同的请求将是一个镜像映像，一个来自我的公共IP地址的请求，源于我的源端口，目的地是端口443（我暂时忽略NAT，稍后详细介绍）：Internet协议版本4，Src:198.41.215.16，Dst:19.5.7.21协议：TCP（6）来源：198.41.215.162目的地：19.5.7.21传输控制协议，Src端口：443，Dst端口：51602，序列：0，长度：0源端口：443目的港：51602我们现在可以回到ECMP！从理论上讲，使用ECMP随机平衡服务器之间的数据包是可能的，但您几乎永远不想这样做。因特网上的消息通常由多个TCP包组成。如果每个数据包被发送到不同的服务器，就不可能在任何一个地方重建原始消息并对其进行操作。除此之外，它对性能的影响也会很糟糕：我们依赖于能够维护长期存在的TCP和TLS会话，这些会话需要到单个服务器的持久连接。为了提供持久性，我们的路由器不会随机平衡流量，它们使用四个值的组合：源地址、源端口、目标地址和目标端口。具有这四个值的相同组合的流量将始终到达同一个服务器。在我上面的例子中，我所有的信息都注定cloudflare.com网站将它放到一个服务器上，它可以将TCP包重新构造到我的请求中，并在回答。输入对于传统的请求，在请求期间，我们的ECMP路由将您的所有数据包发送到同一个服务器是非常重要的。在web上，一个请求通常持续不到10秒，系统运行良好。不幸的是，我们很快就遇到了翘曲。翘曲使用与公钥加密协商的会话密钥来保护数据包。对于成功的连接，双方都必须协商一个连接，然后该连接只对特定的客户端和正在与之通信的特定服务器有效。此协商需要时间，并且必须在客户机与新服务器对话时完成。更糟糕的是，如果发送的数据包预期是一台服务器，而最终却在另一台服务器上，它们就无法被解密，从而中断了连接。检测那些失败的数据包并重新启动连接需要花费大量的时间，我们的alpha测试人员将其视为完全失去了互联网连接。正如您可以想象的那样，测试人员不会在WARP阻止他们使用互联网.WARP因为设备切换服务器的频率比我们预期的要频繁得多。如果您还记得，我们的ECMP路由器配置使用（源IP、源端口、目的IP、目的端口）的组合来将数据包与服务器匹配。目标IP一般不会改变，WARP客户端总是连接到相同的选播地址。同样，目的端口也不会改变，我们总是在同一个端口上监听翘曲流量。另外两个值，源IP和源端口的变化比我们以前更频繁有计划。一个这些变化的来源是预料之中的。WARP运行在手机上，手机通常从蜂窝网络切换到Wi-Fi连接。当你切换时，你会突然从通过手机运营商（如AT&T或Verizon）的IP地址空间进行互联网通信，转而使用Wi-Fi连接所使用的互联网服务提供商（如康卡斯特或谷歌光纤）。基本上不可能你的IP地址在你之间移动时不会改变连接。The然而，端口更改的频率甚至比网络交换机所能解释的还要频繁。为了理解为什么我们需要介绍另一个互联网知识的组成部分：网络地址翻译.NATAnIPv4地址由32位组成（通常写为4个8位数字）。如果排除不能使用的保留地址，则只剩下3706452992个可能的地址。自1983年在ARPANET上部署IPv4以来，这个数字一直保持不变，尽管设备数量爆炸式增长（尽管如果0.0.0.0/8可用，这个数字可能会很快上升）。该数据基于Gartner Research的预测估计：IPv6是这个问题的最终解决方案。它将地址的长度从32位扩展到128位，目前一个有效的互联网地址中有125位可用（所有公共IPv6地址的前三位都设置为001，其余87.5%的IPv6地址空间还不需要）。2^125是一个不可能的大数字，足以让地球上的每个设备都有自己的地址。不幸的是，IPv6发布21年后，许多网络仍然不支持IPv6。互联网的大部分仍然依赖于IPv4，如上所述，没有足够的IPv4地址让每台设备都拥有自己的IPv4地址拥有。到解决这个问题许多设备通常放在一个单一的因特网可寻址IP地址后面。路由器是用来进行网络地址转换的；用来接收到达的信息