HTTP请求通常起源于客户端，并在处理请求并返回一些响应的web服务器上结束。这样的请求可能在到达请求的资源之前通过多个代理。如果其中一个代理配置错误（例如，返回到已经处理它的代理），则请求可能会被循环请求循环，意外的或恶意的，可以消耗资源和降低用户的互联网性能。这种循环甚至可以在CDN级别观察到。如此大规模的攻击将影响到该CDN的所有客户。自从Cloudflare认识到这种不合规或恶意请求循环的威力以来，已经有三年多了。在那篇博客文章中提出的解决方案很快就被发现有缺陷，并且循环保护已经以一种特定于每个提供商的特殊方式实现。缺乏凝聚力和合作导致了一套支离破碎的保护机制。我们最后很高兴地报告，最近多个CDN提供商（包括Cloudflare）之间的合作导致了一种新的循环保护机制。它现在在Cloudflare edge上运行，并与其他CDN兼容，允许我们提供针对环路的保护。回路保护机制目前是HTTPbis工作组正在研究的一个草案项目。它将作为一个RFC在不久的标准轨道上发布未来。未来最初的问题在上一篇博文中对最初的问题做了很好的总结，但我将在这里再次总结（用一些与原始帖子相似的图表，抱歉，尼克！）。您可能知道，Cloudflare是一个反向代理。当对Cloudflare网站发出请求时，Cloudflare边缘通过缓存的响应或通过向原始web服务器发出请求来返回原始内容。一些Cloudflare客户选择使用不同的CDN提供程序来实现不同的功能。这意味着在从接收源内容之前，请求将通过多个代理服务起源。这个有时事情会变得一团糟，可能是由于错误配置或故意造成的。可以在一个循环中为给定的源配置多个代理服务。例如，源站网站可以配置代理A，使代理B成为源，B配置为A起源。那么发送到源服务器的任何请求都将被捕获到两个代理之间的循环中（见上文）。如果这样一个循环未被检测到，那么这会很快耗尽两个代理的计算资源，特别是当请求需要在边缘进行大量处理时。在这些情况下，可以想象这样的攻击可能导致对一个或两个代理服务的DoS。事实上，NDSS 2016的一篇研究论文表明，当以所示方法利用多个CDN提供商（包括Cloudflare）时，这种攻击是可行的上面。那个原始解决方案上一篇博文主张在HTTP请求上使用Via头来记录以前处理过任何请求的代理服务。此头在RFC7230中指定，专门用于提供请求循环检测。其想法是，CDN提供者将在Via报头中记录每次通过其边缘体系结构的请求。任何到达边缘的请求都将被检查，看它以前是否使用Via头的值通过同一个CDN。如果报头指示它以前已经通过，那么在进行任何认真的处理之前，请求可以被丢弃地点。尼克的上一篇文章结束了对arms的调用，要求所有的服务代理请求都符合标准的根据通孔理论，通孔头可以解决回路保护问题。在实践中，很快发现Via的实现存在问题，这意味着使用头是不可行的。将头添加到来自Cloudflare边缘的出站请求会对大量Cloudflare产生严重的性能影响顾客。这样由于Via头的旧用法与用于跟踪循环检测的冲突而产生的问题。例如，大约8%的Cloudflare企业客户遇到gzip无法压缩包含Via头的请求的问题。这意味着他们的网络请求被传输到更大的规模上。在某些服务器实现中，这种性能下降甚至是意料之中的。例如，NGINX主动选择不压缩代理请求：默认情况下，NGINX不压缩对代理请求（来自代理服务器的请求）的响应。请求来自代理服务器的事实取决于请求。同时Cloudflare非常重视安全性，这样的性能问题是不可接受的。在实施后不久，基于Via报头的内容，做出了关闭环路保护的艰难决定。此后，Cloudflare基于CF连接IP和X-Forwarded-For报头实现了循环保护。本质上，当边缘处理请求时，在将请求发送到源服务器之前，这些头将被添加到请求中。然后，将丢弃边缘处理的任何请求，包括这些头中的任何一个。虽然这足以避免恶意循环攻击，但也有一些缺点接近。首先，这种方法自然意味着在不同的CDN提供者之间没有统一的方法来处理循环保护。如果没有一个标准化的方法，在实现中可能会出现错误，从而在将来导致问题上升。第二，Cloudflare客户可能需要通过边缘循环的请求超过一次。而这样的理由通常是相当深奥的，有这种需求的客户必须手动修改这些请求，这样他们就不会违反循环保护机制。例如，包括使用Cloudflare Workers的工作流可以通过子请求多次通过边缘发送请求，以将自定义内容返回给客户端。当前使用的报头意味着只要请求循环一次，请求就会被丢弃。这会给CDN服务的使用带来明显的摩擦，最好有一个更细粒度的循环检测解决方案，Fastly和Akamai开始为CDN。是的结果如下：该草案最近被HTTPbis标准轨道工作组接受。该文件已获得IESG的批准，它将加入RFC系列。TheCDN循环头设置了一种语法，允许单个CDN将请求标记为已由其边缘处理。这个头应该被添加到通过CDN体系结构向某个独立端点传递的任何请求中。当前草稿将头的语法定义为以下：CDN循环=#cdn信息info*"CDOWS参数"；（CDOWS参数）cdn id=（uri host["："端口]）/假名假名=令牌这一点一开始似乎有很多东西需要解开。本质上，cdnid是目标资源的URI主机id，或者是与处理请求的cdn相关的假名。在Cloudflare的例子中，我们可以选择pseudoname=Cloudflare，或者使用已经请求。那么，除了一些可选参数外，cdn info还包含cdn id。这由*（OWS"；"OWS参数）表示，其中"OWS"表示可选的空白，参数表示可能为特定请求提供信息的任何特定于CDN的信息。如果同一标头中包含不同的特定于CDN的CDN info参数，则这些参数以逗号分隔。例如，对于与具体要求，我们给出一些例子来描述CDN如何使用CDN循环头来标记请求已处理。如果到达cdna的请求没有当前的CDN循环头。然后A处理请求并添加：CDN循环：cdn信息（A）按要求标题。如果请求到达时包含以下内容标题：CDN循环：cdn信息（B）对于某些不同的CDN B，则A将头修改为：CDN Loop:CDN info（B），CDN info（A）或添加单独的标题：CDN循环：cdn信息（B）CDN循环：CDN信息（A）如果请求到达有：CDN循环：cdn信息（A）这表示请求已被处理。此时，A检测到一个循环，并且可以根据其自身的策略实现循环保护。这是规范中未定义的实现决策。选项可能包括放弃请求或只是重新标记它，因为示例：CDN循环：cdn信息（A）；cdn信息（A）CDN还可以使用可选参数来表示请求已经被已处理：CDN循环：cdn信息（A）；已处理=1在报头中使用不同参数的能力允许更细粒度的循环检测和保护。例如，CDN可以删除以前循环N>1次的请求，而不是只循环一次。此外，使用CDN循环头的优点是它不附带遗留行李。正如我们之前所经历的，基于Via头的循环检测可能会与web服务器实现中现有的报头使用冲突，最终导致压缩问题和性能下降。这使得CDN Loop成为检测循环保护攻击和应用预防的可行且有效的解决方案需要。实施CloudFlare的CDN循环IETF标准化过程欢迎在现实世界中运行代码和实现经验。Cloudflare最近为通过Cloudflare边缘的请求添加了对CDN循环头的支持。这取代了CF连接IP和X-Forwarded-For报头作为建立循环保护的主要手段。Cloudflare使用的结构与上面的示例类似，其中cdn info=Cloudflare。可以添加额外的参数