朝花夕拾-报文缓存之二

前言
不同时代的数通网络技术，都有着其当时的贡献。让我们进入时光隧道，跟随前辈的足迹，去探访前辈们垦荒的年代吧。
本文既非产品工程技术文档，亦非原厂文宣，乃朝花夕拾，史海拾贝，温故而知新，文笔粗拙，贻笑大方。

<续前文>

突发报文流量(packet burst)

众所周知，报文缓存应该设计为管理流量的”突发”，但对于这意味着什么没有单一的定义。在较高级别，该术语通常是指不属于持续拥塞的流量的临时增加。例如，在一分钟内平均利用率为5%的链路如果出现输出下降，则可能会遇到超出其缓存容量的突发报文流量。

突发报文流量的构成或定义突发类型取决于网络上下文。从主机的角度来看，一种明显的微爆发情况是当主机生成大量报文以响应单个事件时。例如10GE连接的服务器收到的单个 TCP ACK传达了大量段已丢失，则发送端可能会立即替换所有这些段。无论接口速度低于10G，即使没有持续的拥塞，也需要对它们进行缓存。

每当沿路径出现接口速度下降时，微爆发行为就很常见。超额订阅（过载）也会发生这种情况，特别是当流量由Hadoop/MapReduce等应用程序同步时。

通常，应对措施是缓存突发，避免报文丢失，从而不向发送端发出减速的信号。在股票交易中，缓存甚至微突发而增加的延迟可能是不可接受的，唯一的解决方案是增加链路带宽。当存在一定范围的链路速度时，流的报文会分散在较快的链路上，因为通过慢速链路返回的ACK会为将来的传输计时。

缓存膨胀（bufferbloat）

Jim Gettys对缓存与TCP的交互进行了广泛的研究。其研究始于现实世界的经验，并专注于过多缓存的来源和影响。他在2011年发表的IEEE论文中表示：”虽然需要一些缓存来平滑通信系统中的突发，但忽略了基本原理：报文丢失（目前）是网络中信号拥塞的唯一方法，而TCP等避免拥塞的协议依赖于及时的拥塞通知来调节其传输速度。“未及时收到通知的结果是TCP无法以最佳性能运行，从而导致吞吐量降低、延迟高和重新传输，从而导致拥塞永久化。

应用拥塞控制概念

如果没有”足够”的缓存，它将在应用程序希望延迟的短暂拥塞期间丢弃报文。根据丢失检测机制，TCP将延迟慢启动斜坡上升，进入快速重新传输/恢复，或从避免拥塞返回到慢启动。当拥塞持续存在时，其中一些响应的影响最小（在Netflix电影中快速重新传输）是可以的，但当拥塞持续时间有限并且后续报文将以原始速率转发时，则不是。谷歌的实验强调了丢弃对网络流量的负面影响，导致会话完成延迟明显高于无丢弃延迟。

还存在缓存过多的风险。研究发现，TCP通常依靠报文丢弃信号来限制其传输。不丢弃报文可能会导致拥塞窗口变大到合理范围，从而进一步增加拥塞。不丢弃报文会向主机发送信号以提高其传输速率。膨胀的拥塞窗口还将阻止新流获取网络带宽，因为它允许现有流继续发送大型突发。过多缓存引入的延迟也会扭曲RTT和RTT方差计算，从而影响RTO定时器，从而导致损失检测速度变慢。

此外，如果本来会触发重复ACK的报文在缓存中延迟，则不太可能通过快速重新传输来检测和恢复丢失的报文。这会导致RTO和会话返回慢速启动，而不仅仅是通过快速恢复来缩小其窗口。此外，如果缓存显著增加了RTT，则性能将会降低，因为发送端只能为每个RTT 传输一定数量的段。缓存过多的风险可以通过可配置的队列长度、AQM技术（如WRED）和QoS机制来管理，以优先处理重要流量。

因此，存在缓存太小或太大的风险。给定链路的最佳大小将取决于许多因素，包括网络中的位置（例如，RTT，链路速度，超额订阅，流量计数和拥塞）和应用程序以及商业考虑因素，如价格和持续费用。

老鼠流和大象流

网络和缓存设计中的复杂因素是TCP流的变化。大象流每次流量消耗大量带宽。它们的寿命相对较长，因此大部分时间都处于拥塞避免模式，网络中的网段窗口很大。如果管理不当，它们可能会使其他流量挨饿。

老鼠流是短暂的，许多老鼠流在没有离开慢启动的情况下完成。大象流往往占用带宽，而老鼠流则多为短时流量。当老鼠和大象共享缓存时，对老鼠流来说并不总是效果很好，特别是当大象流对拥堵没反应的时候。它们在应用程序（如Map/Reduce）中的数据中心中提出了独特的缓存挑战，其中一台服务器可能启动与数百或数千台其他服务器的连接，从而创建多对一响应。因为它们是短暂的，老鼠流不容易与控制大象流的拥堵和队列管理方案共存。它们不需要减慢速度，因为它们会很快完成，降速会造成流量延迟传输。

当存在多个路径（如L3 ECMP）时，大象流还会引起问题。如果太多的大象流散列在同一链路上，即使其他链路上仍有可用带宽，也可能会发生严重的拥塞。

并非所有的个体流都是大象流或老鼠流。HTTPv2支持低容量长期会话，因此不会经常创建新套接字。在这种情况下，TCP仍应遵守在处于非活动状态后减少拥塞窗口的准则。

老鼠流和大象流的存在及其行为是难以为数据中心网络提出任何通用解决方法的原因之一。学术界和工业界目前还正在研究这些不同类型的流共存的最佳方式。诸如调度，划分或识别和引导大象流等解决方案也都还在不断探索中。

TCP摘要

TCP通过返回慢启动（RTO检测）、停止窗口增长（在使用未解析的段进行快速重新传输期间）或减少拥塞窗口（快速恢复）来响应报文丢失。报文丢失本身对传输TCP流量的网络并不有害。实际上，使用当前部署的拥塞控制算法，它是TCP在存在拥塞的情况下正常运行的必要工具。当可以通过SACK和快速重新传输恢复分段时，相对于大多数应用程序的要求，分段丢失可能不会显著降低会话的总体吞吐量。通过RTO检测到的报文丢失更有害，因为它会使TCP会话返回到慢速启动。多个RTO是最坏的情况，如果可能的话，应该避免，因为它会大大减慢会话速度。无限缓存不会阻止RTO，但它可能会通过延迟以后的报文来防止快速重新传输。

TCP还响应报文丢失以外的信号。当网络中需要持续缓存时，TCP通过增加RTO来响应增加的RTT和RTT方差。这会减慢通过RTO超时检测丢失的速度。

关于为TCP流量设计网络，目标应该是管理良好的缓存和应用程序要求定义的适当报文丢弃。网络的理想缓存量应由应用程序、带宽、往返时间和流量特性的组合确定。

缓存相关的学术研究

在缓存大小调整方面被引用最多的早期论文是Curtis Villamizar和ChengSong在1994年发表的”ANSNET中的高性能TCP”。本文探讨了使用非常少量的长寿命TCP流最大限度地提高链路利用率所需的缓存。对于少量会话，报文丢失可能导致所有会话同时返回慢速启动，从而同时以指数方式增加其速率。当再次发生拥塞时，会话将变为同步状态，并重复TCP 同步的循环。该论文的结论是，通过将缓存大小调整为带宽和路由行程时间的乘积，瓶颈链路利用率最大化。此值称为带宽延迟积（BDP）。例如，作为总RTT为0.2秒的路径的一部分的10 Gbps链路将具有2千兆位或250 MB的缓存。作者认为，增加流量将导致不同的结果。二位作者为缓存与 TCP的交互提供了宝贵的见解。可惜，这个特定案例的建议多年来一直成为教条，并导致在其条件不适用的地方造成过度配置网络缓存。

斯坦福和佐治亚理工学院

由尼克·麦克欧文（NickMcKeown）领导的斯坦福大学高性能网络小组（High Performance Networking Group）一直是对网络的许多方面进行重要研究的来源。Guido Appenzeller 2005年的论文”调整路由器缓存的大小”为具有许多流的Internet核心路由器提供了有价值的见解和基于统计数据的缓存大小调整方法。对于许多流，流量可能不同步，从而导致聚合平滑效果，因此需要较少的缓存。这项研究的主要建议是，缓存的大小应基于BDP和通过链路的大象流（TCP流不是慢速启动）的数量。具体而言：BW * RTT / sqrt（n），其中n 是大象流量的数目。n还引入了一种表示应用程序特征的方法，因为不同的应用程序（视频与小型Web下载）在避免拥塞方面花费的时间可能会有所不同。这很重要，因为许多TCP 流从不离开慢启动。其研究和模拟侧重于核心链接，但缓存和流动之间比例的一般概念可以应用于其他情况。例如，边缘路由器面向核心的上行链路可能具有中等数量的流，因此需要的缓存比同一路由器上面向客户的链路少，而同一路由器上的所有带宽可能被单个流消耗。

佐治亚理工学院的研究人员的论文认为，虽然斯坦福模型对于实现高链路利用率是有效的，但在某些情况下，它可能导致严重的报文丢失（在模拟中为5-15%）。他们认为，这种数量的报文丢失会导致高水平的重新传输和降低应用程序性能。他们的引入了几个新概念。首先，它建议将链接归类为它们是否”可满足”。即使没有进一步的研究，这个概念对于缓存设计的实际应用也很重要。例如，如果特定的数据中心环境允许以相对较低的成本添加其他链路，则可以将缓存限制在速度匹配和微突发所需的水平，因为可以避免持续的拥塞。在另一个极端，DSL，或”最后一公里”可能会遇到严重的持续拥塞。他们的研究与斯坦福模型一致，即”小”缓存足以用于骨干链接，但出于不同的原因：根据当前的服务提供商部署实践，它们无法满足。

佐治亚理工学院的研究还指出，任何基于TCP流数量的结论都必须将流的计数限制为长TCP流，这些流在其他链路上没有瓶颈，也不会受到最终主机窗口或连接速度的瓶颈。他们还提出了一些计算结果，其中表明，在斯坦福模型中，损失率随着该链路上瓶颈的流量数量的平方而增加。

斯坦福大学2006年的一篇论文讨论了佐治亚理工学院的发现，并提出了一种核心链接的启发式方法。他们认为：”在互联网的核心，流量数量非常大，缓存可以减少十倍，而不会期望对网络行为产生任何不利变化，事实上，预计延迟和延迟变化会减少。

互联网RTT为250毫秒，这个”十倍”为服务于全球互联网核心的路由器会产生25毫秒的缓存。主要服务于区域内流量的网络将需要按比例缩小的缓存。

学术界有这样一种观点，即缓存需求取决于许多因素，包括期望的结果（例如，保持链路充分利用，限制损失或最大化每流量吞吐量），超额定购和拥塞的水平，流量的数量，类型和同步。这是在考虑应用程序对丢失、延迟和抖动的敏感性之前。虽然这项研究没有提供单一的答案，但它开辟了一些新的方法来看待这个问题，并在它们在网络中的位置来评估替代方案。关于边缘和访问缓存大小的研究较少，但可用的内容往往支持这样一种观点，即在单个流可以占用链路所有带宽的位置，该链路可能需要BDP大小调整。如果共享缓存，则聚合缓存可能会减少。

其他研究观点

许多研究模型依赖于报文到达泊松分布的假设（到达时间不依赖于其他报文）。有论文认为通过ACK的步调会产生站立队列和非泊松报文到达。另但现实是，业务考虑因素可能会压倒对理想设计的渴望。与具有更深片外缓存的路由器相比，具有小型片上缓存的路由器的密度要高得多，成本要低得多，并且功耗也更低。

真实应用中的缓存研究

Facebook – 链接和缓存利用率

研究人员对Facebook的流量进行了深入分析，他们的论文包括一系列发现，其中许多与缓存设计有关。服务器连接了10G，平均不到1%的1分钟链路利用率，90%的利用率低于10%。Hadoop流量表现出极高的机架局部性 – 大部分流量位于同一机架中的主站和从站之间。Hadoop流程很短。70%发送的容量小于10KB，持续时间不到10秒。Hadoop流的中位数小于1KB和1秒，因此不会进入拥塞避免状态。只有5%超过1MB。有关缓存利用率的数据以10 usec的间隔进行收集，用于链接到Web服务器和缓存节点。即使总利用率较低，缓存也经常在ToR交换机上使用。尽管链路利用率在大多数时间内约为1%，但在每个10us间隔内，超过三分之二的可用共享缓存被使用。

谷歌 – 初始拥塞窗口

谷歌研究将TCP初始拥塞窗口增加到10个或更高的段的效果。在一个RTT内可以完成的网络交易数量大幅增加，完成时间也相应减少。在大多数情况下，这种变化的负面影响是有限的，是可以接受的。这种方法作为打开大量并行TCP连接的替代方案。许多大型网站现在正在采用这种方法，其中60%的初始拥堵窗口在10到16个段之间。TCP的这种演变确实表明，即使流量本身没有，流量的基本流行为也可能随着时间的推移而改变，并且提供了在选择硬件时允许一些更改空间的动机，特别是在流向流数量较少的网络的边缘和访问层。

自从斯坦福大学和佐治亚理工学院的缓存研究和实验以来，初始拥堵窗口的演变需要在今天应用结论时加以考虑。之前常见的TCP堆栈使用2-4个段的初始窗口（RFC 3390）。2010年，谷歌提出了10个初始窗口，并已被广泛采用。由于拥塞算法和设置对于每个发送端都是独立的，并且大多数流量都是服务器到客户端的，因此只需要少数顶级提供商采用此更改即可显著更改Internet上的聚合TCP行为。

高频交易

高频交易（HFT）是一个众所周知的延迟和PDV敏感型应用程序。金融服务提供商为了节省几毫秒的传播延迟，就可以投入很多资金改造光纤线路。在这种情况下，必须消除所有可能的设备标准延迟，并最大限度地减少缓存。这可以通过最大限度地减少内存操作的数量和使用直通切换来实现。

游戏

游戏包括一系列具有不同要求的应用。其中许多具有延迟约束，避免高延迟而不是最小化延迟最为重要。此外，财务驱动因素是不同的，ISP提供的游戏优化服务产品也很少。更多的带宽，支持QoS的家用路由器，以及降低其他大流量应用通常是最终用户改善游戏体验的唯一选择。

游戏设置和聊天主要使用TCP执行，没有严格的延迟要求。游戏玩法通常通过UDP进行操作。游戏玩法要求取决于游戏类型（例如，第一人称射击游戏或实时战略）以及取决于其他玩家位置的个人动作所需的精度。大多数在线游戏的带宽要求相对较低（10 kbps），并且容忍延迟约为150-200毫秒。往返延迟在游戏圈中称为”ping”，通常在选择潜在对手时显示。大多数游戏都有通过允许客户端预测其操作的结果来掩盖延迟到此级别的方法。例如，角色可以在播放声音时移动并显示动画。如果服务器稍后对游戏状态存在分歧，则会对状态进行更正。如果需要更正，客户端将重新运行更正后发生的所有内容，这可能会导致客户端看到的游戏中的”跳跃”。

为了扩展和管理延迟，主要游戏将具有按地理位置分布的服务器集，因为单个托管位置无法满足每个人的这些要求。例如，暴雪在美国、欧洲和亚洲都有服务站点，这些站点托管着《魔兽世界》、《风暴英雄》和《星际争霸》。这仍然不允许太多的缓存，因为在亚洲或南美和美国之间，未拥堵的ping可能会达到150毫秒。在美国和欧洲，未拥塞的延迟大多低于100 毫秒。因此，对于单个流，游戏不太可能受益于超过50毫秒的整体缓存。

<未完待续>

Related Posts