前言
不同时代的数通网络技术，都有着其当时的贡献。让我们进入时光隧道，跟随前辈的足迹，去探访前辈们垦荒的年代吧。
本文既非产品工程技术文档，亦非原厂文宣，乃朝花夕拾，史海拾贝，温故而知新，文笔粗拙，贻笑大方。
<续前文>
非直播流媒体视频
2014年视频占消费者互联网流量的64%，现在超过80%。使用类似流媒体技术的网站产生出绝大多数视频流量。有的视频网站通过HTTP（TCP）流式传输视频，并且通常能够进行足够的主机端缓存，以重新传输丢失的报文，并容忍延迟的适度增加。除非存在重大报文丢失，否则整体质量主要依赖于带宽。当主机端缓存为空时，视频将暂停以重建缓存。建立主机端缓存后，非实时流视频可以容忍大多数网络环境，但不会长时间丢失连接或带宽。单报文丢失是可以容忍的，因为丢失的报文可以通过快速重新传输技术来重新传输，并且TCP使报文能够在解决丢失时保持流动。通过足够的主机缓存，也可以容忍有限的RTO事件，而不会影响最终用户体验。大多数用户通过CDN缓存而不是直接访问服务器，例如，Netflix几乎在美国的每个托管中心都有机柜，其RTT通常低于20毫秒。考虑到视频量，这会显著影响路由器缓存要求。如果通过边缘路由器的大多数流量都发往RTT在20毫秒以下的视频缓存，则TCP对丢失的响应速度将比传统假设的最大RTT（250毫秒）更快。因此，只要及时将信号发送到主机，就可以在边缘路由器上的硬件大小调整时考虑加权RTT。
直播视频
实时视频对网络要求更高，即使是主机端缓存也无法替代次优的网络条件。视频重传实际上是没有实际意义的。实时视频本质上是突发流量的，由于视频压缩算法，当运动画面较少时，不需要发送更多的数据。实时视频包括视频会议、体育、观看游戏等。所需带宽和可用带宽可能会有很大差异。高清电视会议在高质量的1080p模式下每方向约5Mbps带宽。建议的最大延迟为150毫秒。一般会建议用户可感知的延迟为250到350毫秒。实时流对报文延迟变化（PDV）也很敏感。”抖动缓存”初始设置为85毫秒，如果需要，可以增加到245毫秒。丢弃或延迟到达（超出抖动缓存）的报文会导致视频像素化。在1080p下，未压缩的视频流为1.5Gbps，压缩流为4Mbps，每个报文都包含大量的视频数据。一般建议将丢失率（包括延迟报文）设置为0.05%。在企业网络中，高清视频会议服务一般会在网络中得到优先保障。
其他视频会议应用程序需要使用的可用带宽通常非常高，并可根据可用带宽调整其要求。它们将遇到类似的报文丢失、延迟和延迟变化问题。
IP语音
VoIP通常使用TCP进行设置，并使用UDP为呼叫传输报文。VoIP使用相对较低的带宽，并且对丢失，抖动和延迟敏感，类似于视频。这些特性使其成为流量差异化的网络设计中优先处理的选项。最大延迟的准则通常在150-250毫秒之间，损耗要求低于1%。在没有任何优先级的情况下，VOIP具有高度可变的质量，具体取决于网络条件。VoIP不应由于缓存而显着增加延迟。
域名系统
DNS使用UDP进行名称解析。通过避免TCP握手实现了更快的响应，TCP握手使请求能够在单个RTT中完成。由于这是相对简单的任务，因此不需要TCP – 如果没有收到响应，DNS可以重试或尝试连接另一台服务器。因此，DNS通常不需要在网络中进行任何特殊处理，但过度排队会影响用户体验，因此应该最小化。DNS的延迟也可以通过提供区域DNS服务器来管理。DNS服务器通常是攻击者的目标，因此会受到正常排队假设之外的异常流量模式的影响。
网站
网络浏览占互联网流量的大多数。总带宽小于视频，但小流量却很多。Web流量包括HTML、CSS、Javascript、图形、Flash和其他类型的内容。虽然目前平均访问速度不断提高，但平均网页的大小也在继续增长。2010年，网页的平均值为626KB，目前会超过2MB。从理论上讲，在没有带宽限制的情况下，2MB为Reno算法需要8个RTT，初始窗口为10（第一个RTT为14.6 KB，第二个RTT为29.2 KB。第7个为934 KB，第8个为1.9 MB）。实际上，有线环境下网站整页加载平均约为7秒，移动设备上通常超过10秒。一旦有足够的带宽级别可用，页面加载时间就会通过减少RTT而不是增加额外的带宽来改善。这导致内容的放置尽可能靠近最终客户端的位置。
高效传输Web信息需要内容、服务器和客户端优化。内容（图像压缩和页面结构）可能是需要改进的最大和成本最低的领域，但网络可以帮助掩盖臃肿的内容。在客户端，大多数浏览器并行打开多个TCP会话。这允许一次下载多个对象，但不允许客户端评估容量并调整为丢弃。从网络的角度来看，它还将资源置于来自同一主机的多个会话中，并行执行慢启动（并且通常永远不会达到拥塞避免），这违背了拥塞控制算法的假设。SPDY是通过压缩和允许并行执行多个操作来减少页面加载时间的协议。它无需等待每个对象完成，然后再请求下一个对象，而是可以一次发出所有请求，服务器可以按可用情况并以优先方式返回对象。SPDY和更大的初始拥塞窗口共同缓解了对大量会话的需求。HTTPv2实现了这种方法，并将取代SPDY。HTTPv2需要在客户端和服务器上进行升级。在服务器端，较大的初始拥塞窗口减少了会话完成时间，而较新版本的TCP算法（如CUBIC和复合TCP）允许在高RTT网络中实现更快的窗口增长。由于大部分流量从服务器发送回客户端，因此只需更新服务器的TCP算法即可实现大部分好处。
由于上述原因，部署的HTTPv1.1（并行会话）对缓存不是很友好。它导致主机无法按照构建TCP的假设进行传输。随着HTTPv2的部署越来越广泛，更多的主机将打开更少的会话，并使用它们在每个会话中传输更多的分段。这应该具有减少缓存需求的净效果。
P2P点对点协议
P2P对等协议实际上也用于各种正规用途，如下载游戏更新，分发科学数据和分发Linux。如果没有对等文件，就很难免费提供大文件。当前的实现是使用在UDP上运行的微传输协议（uTP）。uTP使用低额外延迟后台传输方法来避免增加网络拥塞。它是基于延迟的算法，当检测到增加的延迟时，它会减慢速度。它还可以与TCP一起用于较低优先级的任务，例如软件更新等。
通过对等传输的数据通常没有会话完成限制或保证带宽的期望。因此，对等流量不需要任何特殊考虑的缓存。
分布式计算和存储 – MapReduce，HDFS
Hadoop是应用程序行为导致不同网络流量模式的典型案例。Hadoop使用TCP，并期望分布式操作在特定截止日期之前完成，并且可能会忽略延迟响应，这可能导致不完整或次优结果。Hadoop依赖于集群中多个节点上的并行计算，然后将结果返回给Master。这既会导致高”机架局部性”（流量保持在机架内）又会导致TCP Incast的流量同步。Incast是由应用程序触发的多对一响应引起的拥塞。在这种情况下，拥塞不是由于持续的高流量或随机冲突造成的，而是应用程序的固有行为。
对于老鼠流，最好是缓存而不是丢弃和重新传输。除了初始突发流量之外，可能没有其他数据，因此对报文丢失的”信号”没有任何反应。这种缓存可以发生在网络中，也可以发生在服务器本身上。当流量超过允许TCP立即发送的数据量时，服务器上的缓存已经开始进行。较新的TCP机制可以通过使用抖动，来使用缓存，该方法可能比在路由器或交换机上添加额外的缓存更可取。该方法的另一个好处是提高链接速度，从而减少发生的超额订阅量。Incast的最佳解决方案仍在研究讨论中。
网络设备缓存架构
片外与片上缓存
网络设备需要做出的权衡之一是，将报文缓存到NPU/转发芯片内部的内存中，还是缓存在查找引擎外部的内存中（或连接到单独的排队芯片）。
片内缓存可最大限度地减少功耗和电路板空间，但不允许使用非常大的缓存器。片上缓存允许更密集的网络设备，因为它允许将更多的芯片资源用于物理端口。例如，大规模深度缓存网络处理器可以在片外FIB、片外缓存、结构连接和接口连接之间大致平均分配I/O 引脚。相比之下，片上系统网络设备可以将几乎所有的芯片I/O容量分配给外部接口。这是当前网络设备的广泛端口数量和功耗背后的关键因素之一。
使用片外缓存时，必须满足两个关键前提要求。首先，内存必须足够大以缓存所需的报文。其次，它必须足够快以保持转发速率。虽然不像FIB内存要求（每秒极高的操作数）那么高，但后者还是一个挑战，因为商用存储器不是为网络应用的速度而设计的。因此，定制高性能存储器或大量商用存储器通常是达到存储器带宽要求的唯一选择。此外，内存部件的大小可能无法实现最佳缓存。在这些情况下，厂家必须允许通过软件配置来限制队列大小。
定制存储器可以根据各种规格进行定制，包括带宽、每秒操作数、容量和物理尺寸。对于深度缓存，必须在高速自定义存储器或大型商用存储器库之间进行选择。定制存储器可节省电路板空间，但价格明显更高。他们还可能在内部或向厂商支付大量硬件开发费用。使用商用存储器的片外缓存成本较低，但由于需要过度配置存储器大小以获得足够的存储器带宽，因此通常比定制存储器需要更多的电路板空间。使用更高性能的商用内存（如图形内存， GDDR5）会有所帮助，但仍然无法提供专为应用设计的内存的速度和效率。
目前网络处理器的片外存储器可能高达16GB。这与数据中心和互联网流量之间的RTT变化大致相同。
设备平台
缓存可能发生在任何拥塞点，最常见的是转发芯片、交换矩阵和出口接口。有几种常见的体系架构可以促进不同的缓存方案。它们在缓存的大小和位置、缓存的分配方式以及队列管理机制方面存在差异。没有一个架构在所有情况下都是最优的。越大并不总是越好，还有影响其他设计领域（如密度和功耗）的权衡。最常见的缓存体系架构是：
具有小型片上共享存储器的单芯片系统
带深度缓存器的单芯片系统
具有交换矩阵互连和VOQ缓存的多个转发芯片
具有交换矩阵互连和VOQ以及完全出口缓存的多个转发芯片
具有入口和出口缓存功能的多个转发芯片
具有小型片上缓存和以太网结构的多个转发芯片
具有中央片上缓存的单转发处理器 – 按机箱数量，最常见的缓存架构是中央片上共享内存，可用于任何端口的入口和出口排队。通常将少量内存分配给入口上的每个接口，作为传入报文的FIFO，为每个端口分配少量内存用于出口，并且对拥塞的端口，可以将剩余内存灵活地分配给出口。由于目前片上存储器相对较小，这些器件在没有拥塞（仅限微突发）或低RTT的环境中工作得很好。由于其简单性和低成本而在大批量应用场景中很常见，如ToR。10MB范围内的”小型”片上存储器能够在低RTT环境中提供显着的缓存，因为低RTT允许长寿命流对拥塞做出快速反应。
这种架构的扩展是为单芯片系统增加更深的片外缓存器。这通常用于需要WAN缓存但不需要模块化机箱规模的接入或较小的边缘设备。
虚拟输出队列(VoQ)– 要将网络设备扩展到单个转发节点之外，必须通过交换矩阵连接节点。这可以是一组交换矩阵芯片，用于在节点之间转发帧或单元，也可以是直接连接转发处理器的交换矩阵。该架构可能会引入其他潜在的拥塞源。这可以通过包括调度和缓存或加速在内的多种方式解决。一些早期的基于交换矩阵的网络设备遇到线头阻塞，其中发送到拥塞出口卡或接口的报文阻止了发送到其他目的地的报文，该问题可以通过虚拟输出队列解决。在VoQ模型中，在每个输出队列的入口处创建单独的队列。然后，可以对任何目标的报文进行取消排队，而不会阻止其他队列。VoQ可以仅用于管理具有单独出口队列的交换机架构拥塞，也可以是网络设备上的主缓存。对于仅VoQ模型，入口流量管理器可能知道也可能不知道其他VoQ上的队列深度。如果它不知道其他队列的状态，则总最大缓存量是转发芯片上为该目标缓存报文的所有可用缓存的总和。例如，将VoQ配置为20毫秒的缓存，并且将到拥塞队列的流量缓存到10个转发芯片上，则总缓存可能达到200毫秒，这通常对网络不利。在大容量拥塞的情况下，可能会需要更多的缓存。
出口队列 – 与VOQ一样，出口队列在不同的网络设备上可能有多个角色。在VOQ是拥塞接口的主要队列的系统中，出口队列可能只是小FIFO，用于重新组合和平滑链路速度的流量。在这种情况下，出口队列没有明显的缓存，可以放在芯片上。其他系统使用出口队列为接口拥塞提供主要缓存。在这种情况下，可以实现一整套活动队列管理和优先级/整形行为。在所有条件相同的情况下，将一个端口的所有传出报文放在一组出口队列中比多个VOQ更可取，因为它允许在执行依赖于队列深度的操作时具有更高的可见性。VOQ设计仍然可以非常有效地实现QoS策略，并且一些VOQ系统可以提供对其他模块上队列深度的全局可见性，从而允许AQM决策具有全局可见性。
入口和出口队列-是网络设备可能同时具有入口和出口缓存。在此体系架构中，入口缓存用于管理任何架构拥塞以及任何出口资源（例如，出口报文处理器，而不是输出队列）的超额订阅。入口缓存可以通过背压或请求/授予机制触发。通过在交换矩阵中具有足够的”加速”来最大程度地消除作为拥塞源的交换矩阵，可以最大限度地减少入口缓存。通过加速，交换矩阵具有比入口容量更高的出口容量，因此允许多个发送方同时向出口卡发送高速率流量。
除了可见缓存之外，通常还使用少量的缓存来平滑报文从网络设备的一级到下一级的转换。例如，一个芯片可以发送11 Gbps的突发数据，而另一个芯片可以10 Gbps的速度接收，则使用一个小缓存来解决速度不匹配问题。这通常是由FIFO缓存器实现的。这将产生标准时延，因为每个内存复制到缓存都会增加序列化时延。因此，在超低时延应用中，最大限度地减少FIFO的数量非常重要。对于WAN或边缘应用程序，FIFO比接口拥塞或传播延迟小得多，因此对于具有这些角色的网络设备来说不太重要。这种类型的缓存也可以在输入接口和转发芯片之间使用，并且某些网络设备可以通过预分类和非FIFO队列在此阶段对流量进行优先级排序。
<未完待续>
希望本文能对了解数通网络设备提供一点粗浅的感性认识。
本文有关信息均来自公开资料