Brian Snelson的2.0抄送我很高兴地宣布CloudFlare现在支持WebSockets。保护和加速WebSockets的能力是我们最需要的特性之一。截至目前，CloudFlare正在为任何企业客户和有限的CloudFlare业务客户推出WebSocket支持。在接下来的几个月里，我们希望为所有的商业和专业客户提供支持。我们正在缓慢推出WebSockets，因为它带来了一系列新的挑战。下面的故事记录了支持WebSockets的挑战，以及我们为克服这些挑战所做的努力。WebSockets之前的网络在深入研究WebSockets之前，了解HTTP（web的传统协议）是很重要的。HTTP支持许多不同的方法，通过这些方法可以将请求发送到服务器。当你点击一个传统的链接时，你正在向一个web服务器发送一个GET请求。web服务器接收请求，然后发送响应。当您提交一个web表单时（例如当您在登录一个帐户时提供用户名和密码时），您使用另一个名为POST的HTTP方法，但是交互功能是相同的。您的浏览器（称为"客户机"）将数据发送到等待接收数据的web服务器。然后，web服务器将响应发送回您的浏览器。您的浏览器接受响应，因为它在发送原始请求后正在等待响应。不管HTTP方法是什么，浏览器和web服务器之间的通信都是以这种锁步请求然后响应的方式进行的。一旦客户端的浏览器发送了请求，就不能对其进行修改。

为了获得新内容，用户必须刷新整个页面。直到1999年，outlookweb团队对糟糕的用户体验不满，引入了一个名为XMLHttpRequest（又称AJAX）的internetexplorer自定义扩展。从那时起，web应用程序可以使用JavaScript在后台以编程方式触发HTTP请求，而不需要刷新整个页面。但是，为了确保客户端浏览器上的页面是最新的，JavaScript需要每隔几秒钟触发一次AJAX请求。这就像一直在问web服务器：有什么新东西吗？有什么新鲜事吗？。。。这是可行的，但不是特别有效。理想情况下，您需要的是浏览器和服务器之间的持久开放连接，允许它们实时交换数据，而不仅仅是在请求数据时。在WebSockets之前，有一些尝试创建持久的开放连接。这将有效地打开一个HTTP请求，并将其保持打开一段时间。有各种各样的解决方案被称为"彗星"。尽管它们一般都能工作，但它们基本上是一种功能有限的黑客攻击，而且经常会造成超出必要的开销。我们需要的是一个同时支持浏览器和服务器的新协议。输入WebSockets2011年，WebSockets被采纳为标准的web协议。今天，所有主流浏览器的现代版本都支持它们。WebSocket协议是一种独特的基于TCP的协议，但是它是由一个HTTP请求发起的，然后该请求被"升级"以在浏览器和服务器之间创建一个持久的连接。WebSocket连接是双向的：服务器可以将数据发送到浏览器，而无需浏览器显式地请求数据。这使得多人游戏、聊天和其他需要通过标准web协议实时交换信息的服务成为可能。CloudFlare构建在NGINX web服务器的修改版本上，NGINX从版本1.3.13（2013年2月）开始支持WebSocket代理。一旦NGINX代理支持到位，我们就研究了如何为客户支持WebSockets。挑战在于WebSockets有一个非常不同的连接配置文件，而CloudFlare最初并没有针对该配置文件进行优化。

CC BY-SA 2.0费尔南多·德索萨连接计数CloudFlare看到大量传统HTTP请求，这些请求生成的连接相对较短。传统上，我们的目标是优化我们的网络来支持这些请求。WebSockets提出了新的挑战，因为它们需要比传统web请求长得多的连接，这就需要对我们的网络堆栈进行更改。一个现代的操作系统可以处理到不同网络服务的多个并发连接，只要有一种方法可以区分这些连接。进行这些区分的一种方法称为"元组"。理论上，有五个不同的元素组成一个元组来区分并发连接：协议（例如，TCP或UDP）、源IP地址、源端口、目标IP地址和目标端口。因为CloudFlare是一个代理，所以有两个连接很重要：从浏览器到我们的网络的连接，从我们的网络到我们客户的原始web服务器的连接。从浏览器到我们网络的连接具有高度多样的源IP，因此它们不会造成并发连接瓶颈。另一方面，甚至在我们实现WebSockets之前，我们已经看到了基于到客户源服务器的并发连接的约束。元组问题使用五元组元素区分连接，如果五个不同变量中的任何一个不同，则可以区分两个连接。然而，在实践中，这一套更为有限。在CloudFlare连接到客户源的情况下，连接的协议（无论是WebSocket还是HTTP）始终是TCP。如果是非加密连接，则目标端口也固定为80；如果是加密连接，则将其固定为443。当CloudFlare首次启动时，每个源服务器的所有流量仅来自每个CloudFlare服务器的一个IP地址。我们发现这导致主机提供商的反滥用系统出现问题。他们会看到来自单个IP的大量请求并阻止它。我们解决这个问题的方法是将请求分散到多个源IP地址。我们对客户端的IP地址进行哈希处理，以确保同一浏览器通过相同的IP地址进行连接，因为一些旧的web应用程序将连接IP地址用作会话公式的一部分。现在每个数据中心至少有256个IP用于源站流量。每台服务器都将有一小部分地址用于往返于源服务器的通信。虽然在元组中有五个不同的变量，可能的连接数几乎是无限的，但实际情况很快限制了连接数。协议、目标端口和目标IP只有一种可能。对于源IP，我们受专用于连接到源站的IP地址数的限制。剩下的是源端口，它最终成为每个服务器可以支持的连接数中最大的驱动程序。

抄送BY-ND 2.0拣选港口可用端口的数量定义为16位数字。这允许理论上最多有65536个端口，但实际上，可用作源端口的端口数量更为有限。可以用作源端口的端口列表称为临时端口范围。负责这类事情的标准组织，即IANA，建议操作系统在49152和65535之间选择一个源端口。如果您遵循IANA对临时端口范围的建议，那么只有16384个可用的源端口。范围1-1023的端口被称为"知名端口"，是专门保留并排除在临时端口范围之外的。在CloudFlare，我们很清楚网络上的IP将连接什么，因此我们可以轻松地将临时端口范围从9024扩展到65535，从而为我们提供56512个可能的源端口。从我们网络上任何给定服务器到任何给定CloudFlare客户源站的同时传出连接的最大数量应为：56512乘以分配给服务器的源IP数。你可能认为这会有很多联系，但有一个陷阱。先绑定后连接正如我在上面写的，为了防止来自单个IP的太多流量，我们将请求分散到多个源IP地址。我们在Debian家族中使用Linux的一个版本。在Linux中，为了将出站请求固定到特定的IP，需要将套接字绑定到特定的源IP和源端口（使用bind（）函数），然后建立连接（使用connect（）函数）。例如，如果要将源IP设置为1.1.1.1，将源端口设置为1234，然后打开与位于的web服务器的连接，您将使用以下代码：s=插座.插座(插座, socket.SOCK_流)s、 绑定（（"1.1.1.1"，1234））s、 连接（（"www.google.com"，80）如果在调用bind（）时指定源端口0，则指示操作系统随机为您找到可用端口：s=插座.插座(插座, socket.SOCK_流)#将source port设置为0，指示操作系统查找可用端口s、 绑定（（"1.1.1.1"，0））s、 连接（（"www.google.com"，80）这很好用，但是Linux的bind函数是保守的。因为它不知道您要将端口用于什么目的，所以当一个端口被保留时，无论协议、目标IP或目标端口是什么，bind函数都会保留它。换句话说，如果用这种方式绑定，那么只使用连接元组中可能的五个变量中的两个。在CloudFlare，这限制了每个服务器的并发连接数，从全局每个源IP的64k，到每个目标主机的每个源IP的64k。这实际上消除了CloudFlare传出连接的限制。在p中