早在2015年，我们就在我们的数据中心部署了ECMP路由——等成本多路径。这项技术使我们能够在多个物理设备上将数据传输到单个IP地址服务器。你可以把它看作是第三层负荷平衡。首先我们使用DNS。然后呢我们使用选角。最后, 我们在多个服务器上使用ECMP照片Sahra by sa/2.0在部署ECMP时，我们遇到了路径MTU发现的问题。发送到选播IP的ICMP数据包被丢弃。您可以在2015年的博客文章"路径MTU发现"中了解更多关于这一点（以及解决方案）练习。到我们开发了一个叫做pmtud的小软件来解决这个问题(https://github.com/cloudflare/pmtud). 自从部署pmtud以来，我们的ECMP设置一直工作顺利。硬编码IPv6 m时，最初的ECMP推出的事情被打破了。为了在pmtud完成之前保持服务的运行，我们部署了一个快速的黑客攻击。我们将IPv6流量的MTU降低到最小可能值：1280字节。这个在默认路由上作为标记完成。这就是我们的路由表过去的样子：$ip-6路由显示...默认通过2400:xxxx:：1 dev eth0 src 2400:xxxx:2公制1024 mtu 1280注意默认情况下的mtu1280路线。与这个设置我们的服务器从不传输大于1280字节的IPv6数据包，因此"修复"了这个问题。因为所有的IPv6路由器都必须有一个至少1280的MTU，所以我们可以预期不会有太大的消息发送到ICMP包我们。记得吗-ECMP引入的最初问题是，路由回选播地址的ICMP可能会转到ECMP组中的错误机器。因此我们变成了ICMP黑洞。Cloudflare会发送大数据包，它们会被丢弃，ICMP PTB数据包会飞回我们这里。反过来，由于ECMP。但是为什么IPv4流量没有出现这个问题？我们相信同样的问题也存在于IPv4上，但是由于网络的不同性质，它的破坏性较小。IPv4更为成熟，绝大多数终端主机都支持MTU 1500或其MSS选件配置良好，或者由一些中间设备固定。这与IPv6不同，在IPv6中，大部分用户使用隧道，路径MTU严格小于1500，并且在TCP报头中使用不正确的MSS设置。最后，Linux为IPv4而不是IPv6实现RFC4821。RFC4821（PLPMTUD）有它的缺点，但对缓解ICMP黑洞有一定帮助问题。我们的"修复"（将MTU减少到1280）对我们很好，我们没有迫切的理由恢复它。研究人员但我注意到了。我们被当场抓获两次：2017年Geoff Huston注意到（pdf）我们只发送了1280的DNS片段（旧的博客文章）。2018年6月，"探索互联网中可用路径MTU"（pdf）提到了我们的奇怪设置——我们可以接受1500字节的数据，但是传输被限制在1280。当小的MTU太小时，NH53 by/2.0的照片太小了，这一点最近发生了变化，当我们开始为UDP开发Cloudflare频谱支持时。Spectrum是一个终止代理，能够处理HTTP以外的协议。让频谱转发TCP相对简单（除非有几次骇人听闻的黑客攻击）。UDP是不一样。一个我们遇到的主要问题与我们的服务器。期间测试我们想通过频谱转发UDP-VPN包。可以想象，任何VPN都会将一个数据包封装在另一个数据包中。频谱接收包如下：+---------------------+------------------------------------------------++IPv6+UDP报头|封装1280字节数据包的UDP有效负载|+---------------------+------------------------------------------------+很明显，我们支持最大1280字节IPv6数据包的边缘服务器无法处理这种类型的流量。我们需要至少1280+40+8字节的MTU！如果您是internet上的终端节点，那么在IPv6中硬编码MTU=1280可能是可以接受的解决方案，但在转发隧道时，它肯定太小了交通。采摘一个新的MTUBut我们应该使用什么MTU值？让我们看看其他主要的互联网公司是怎么做的。下面是IPv6上TCP SYN+ACK数据包中公布的MSS值的两个示例：+---site--------MSS--+-estimated MTU-+| 谷歌|1360 | 1420年|+---------------+--------+-----------------+| 脸谱网|1410 | 1470|+---------------+--------+-----------------+| 维基百科.org|1440 | 1500|+---------------+--------+-----------------+我相信Google和Facebook调整MTU是因为他们使用了L4负载平衡器。它们的实现是IP-in-IP封装，因此需要为报头留出一点空间。阅读更多：谷歌-MaglevFacebook-KatranThere可能是拥有更小MTU的其他原因。减小的值可能会降低路径MTU检测算法启动的概率（即：依赖ICMP PTB）。我们可以从理论上解释眼球：MTU=1280永远不会运行路径MTU detectionMTU=1500将始终运行它。介于两者之间的值会增加遇到问题的不同机会。但有什么机会呢？对我们从眼球中看到的MSS值进行了一个快速的、不科学的研究，结果显示了以下分布。对于通过IPv4的连接：IPv4眼球在SYN中播发MSS：值|--------------------------------------------------累计计数1300英镑*1.28%98.53%1360 |****4.40%95.68%1370 |*1.15%91.05%1380 |***3.35%89.81%1400 |*******7.95%84.79%1410 |*1.17%76.66%1412 |****4.58%75.49%1440 |******6.14%65.71%1452 |*********11.50%58.94%1460 |*******************************************47.09%47.34%假设大多数客户机的MSS配置正确，我们可以说89.8%的连接公布MTU=1380+40=1420或更高。75%的MTU>=1452。对于IPv6连接，我们saw:IPv6眼球在SYN中公布的MSS:值|--------------------------------------------------累计计数1220 |***4.21%99.96%1340 |**3.11%93.23%1362 |*1.31%87.70%1368 |***3.38%86.36%1370 |***4.24%82.98%1380 |***3.52%78.65%1390 |*2.11%75.10%1400 |***3.89%72.25%1412 |***3.64%68.21%1420欧元*2.02%64.54%1440 |**********************************************54.31%54.34%在IPv6上，87.7%的连接的MTU>=1422（1362+60）。75%的患者MTU≥1450。（另请参阅：DNS服务器的MTU分布）。在我们继续之前，有必要重申一下最初的问题。从眼球到选播网络的每个连接都有三个与之相关的数字：客户端广告MTU-在TCP headerTrue Path的MSS选项中看到MTU值-在测量到边缘服务器MTU之前通常是未知的-在本练习中我们尝试优化的值（这是一个小小的简化，internet上的路径不是对称的，因此从Ebeball到Cloudflare的路径可能与反向路径的路径MTU不同。）为了使连接行为不当，必须满足以下三个条件met:客户广告MTU一定是"错误的"，也就是说：大于真实路径MTU您的边缘服务器必须愿意发送这样大的数据包：边缘服务器MTU>=真路径MTUThe ICMP PTB消息必须无法传递到我们的边缘服务器-阻止路径MTU检测正在工作。那个最后一种情况可能发生在原因：路由器在路上有一些行为不端也许防火墙icmpd由于互联网的非对称性，ICMP被路由到错误的选播数据中心我们这边出了问题，例如pmtud进程失败过去我们把边缘服务器的MTU值限制在尽可能小的范围内，以确保我们永远不会遇到问题。由于发展了对UDP频谱的支持，我们必须增加边缘服务器的MTU，同时仍然将问题发生的概率降到最低发生了。终于，在很大一部分流量中依赖ICMP-PTB消息是一个坏主意。很容易想象这将导致的代价：即使路径MTU检测工作正常，受影响的连接也会出现故障。在反向ICMP通过并重新配置保存的路径MTU值之前，将丢弃两个大数据包。这对潜伏期.进展素最近几天我们增加了ipv6mtu。作为过程的一部分，我们可以选择1300、1350或1400。我们选择1400是因为我们认为它是1280之后的下一个最佳值。在1400的情况下，我们相信93.2%的IPv6连接不需要依赖路径MTU检测/ICMP。在不久的将来，我们计划进一步提高这一价值。不过，我们不会满足于1500个——我们希望为IPv4封装留出几个字节，以便在路径MTU检测启动时，最流行的隧道能够继续工作而不会出现延迟从那以后我们一直在监视Icmp6InPktTooBigs计数器的推出：$nstat-az | grep icmp6inpktoobigsIcmp6InPktTooBigs 738748 0.0这是过去7天我们收到的ICMP PTB数据包的图表。您可以清楚地看到，当推出开始时，我们看到PTB-ICMP消息大量增加（Y标签-包计数-故意混淆）：有趣的是