什么是微突发？

什么是微突发？
微突发的定义
微突发是指端口在很是短的时间（毫秒级别）内收到很是多的突发数据，以致于瞬时突发速率达到平均速率的数十倍、数百倍，甚至超过端口带宽的现象。
网管设备或网络性能监测软件一般是基于比较长的时间(数秒到数分钟)计算网络实时带宽。在这种状况下，看到流量速率一般是一条比较平稳的曲线（如图22-121所示）。可是，一秒钟对于一个高速收发数据包的接口来讲是很是长的一个时间段。若是将数据更改成毫秒级进行观察，流量速率极可能是带锯齿的（如图22-122所示）。若是锯齿突变很大，就称为微突发。
举个极端的微突发的例子：假设一个10GE链路上有平均1Gbps速率的流量，极端状况下能够是前100毫秒有10Gbps的流量，后面900毫秒的流量为0。这时，前100毫秒的10Gbps的流量对于设备而言就是微突发。
图22-121 宏观流量速率

图22-122 微观流量速率

微突发的常见误解
对于微突发的检测，一般有以下几种理解误区：
为何微突发的流量在交换机端口统计计数的Input peak rate中没有体现呢？
这是由于交换机上任何报文速率的计算，都是用一段时间内的总报文数除以统计时间获得的。对于CE系列交换机而言，Input peak rate和Last 300 seconds input rate默认都是按照300s的周期计算的平均值，其中Input peak rate记录的是历史上的全部统计周期的平均速率中的最大值。端口统计计数的周期能够配置，可是最小也只能配置为10s。
所以，秒级的端口统计计数周期，没法捕获到毫秒级的微突发流量，并在端口统计计数的Input peak rate中体现出来。
那么，为何端口统计计数的周期最小只能是10s呢？若是交换机按照10ms的周期统计端口流量，不就能够捕获到微突发了吗？
这是由于端口的报文统计计数须要CPU去轮询芯片才能得到。交换机的端口数量可能很是可观（好比多机堆叠+40GE/100GE端口拆分），10ms的周期将致使轮询很是频繁，这将极大消耗CPU性能，从而致使交换机响应慢，甚至无响应。
为何出现微突发时交换机没有上报缓存超限告警呢？
这是由于交换机要获取缓存的使用状况，只能依赖CPU的轮询机制，这就面临和端口速率计算相似的问题，CPU不能轮询太频繁，不然CPU利用率会升高，从而致使交换机响应慢，甚至无响应。
网管7*24小时不停地监控端口流量，为何网管上看到的流量曲线很平滑，没有看到微突发现象呢？
这是由于交换机上报数据的精度、网管监控流量的周期都是秒级，所以精度为秒级的流量图没法展现出毫秒级的微突发流量。
端口当前的利用率不高，速率不大，所以当前的突发也很小。
这是错误的理解。平均速率和突发速率的关系，就如同速度与加速度，虽然名字很类似，但并无简单的线性比例关系。端口的利用率不高，当前速率低，并不表示突发速率就小。
交换机记录了拥塞丢包计数，因此是交换机引发了突发或拥塞丢包。
这是错误的理解。突发流量是由业务终端产生的，除了少许协议报文外交换机不产生其余流量。可是，突发可能在交换机上加重，例如多端口同时向单端口发送数据，收敛比不合理，致使突发的峰值叠加。因此要从流量来源和组网上着手，寻找突发的源头。
终端服务器的业务是很随机的，不会有多大的突发。
业务的随机性在微观程度可能体现出很是极端的两面性。一个极端是时时刻刻都有业务流量，流量整体平稳；另外一个极端是一下子有大量流量高速发送，一下子又空闲下来没有数据发送，突发严重。
业务的随机性也不等同于TCP发包的随机性。传统的TCP在有数据发送且发送窗口未满的时候，老是想要尽快抢占带宽把数据发送完，因此传统的TCP发包在微观上突发性广泛很强。同时服务器的端口带宽越高，每每突发也就越强。
微突发的影响
当微突发流量的瞬时速率超过交换机的转发能力时，交换机会将突发的数据进行缓存以便稍后发送。若是交换机没有足够的缓存，那么超出的数据只能丢弃，这就产生了拥塞丢包。
图22-123 微突发影响

图22-123是一个典型的毫秒级微突发场景。假设Port一、Port2都以10Gbps的线速速率分别向Port3发送5MB的数据，则总发送速率为20Gbps。而Port3的速率为10Gbps，仅为总发送速率的一半，所以只能将一半的数据（5MB）发送出去，另外一半数据（5MB）则须要先缓存起来，待Port3有空闲能力时再发送。这时，因为交换机只有1MB的缓存，所以会有4MB的数据因为缓存不足而丢弃。在不考虑帧间隙、前导码、帧校验和、报文头等开销数据的状况下，这个突发持续的时间为5MB/10Gbps = 4ms。
当前交换机整机缓存大小通常为1～20MB。这样，对于上述10GE端口线速二打一的场景，最大可承受的突发持续时间 < 16ms（20MB/10Gbps）。在实际的网络中，不少场景不是二打一而是多打一，所以对缓存的消耗会更严重，微突发时产生的拥塞丢包也就会更多。
微突发的检测方法
能够借助捕获报文软件和Wireshark软件来检测网络中是否存在微突发。
如图22-124所示，使用Wireshark软件打开捕获报文软件记录的捕获到的报文文件，选择“统计 > I/O图表”，就能够看到流量图。
图22-124 使用Wireshark软件查看流量图

如图22-125所示，在IO图表中，须要将Y轴单位改成Bits，并将间隔改成1毫秒，这样就能看到毫秒级流量的突发。
图22-125 Wireshark IO图表

微突发的应对措施
能够经过以下几种方法，来下降微突发的发生，缓解微突发的影响：
针对传统TCP拥塞控制机制中存在的突发严重、过分消耗网络交换机缓存、有损线路上性能不佳、延时抖动大等问题，采用业界经常使用的改进技术，确保服务器不会过分、过快、突发过强地发包，从根源上减小微突发。
在网络业务流量规划时，尽可能避免多打一场景，避免收敛比太高的场景，及时扩容突发严重的出端口，消除突发瓶颈。
对于CE12800E、CE5850EI、CE5855EI、CE5850HI、CE5880EI、CE6800系列交换机、CE7800系列交换机、CE8800系列交换机，在转发设备发生拥塞时，能够在发生拥塞的接口下执行qos burst-mode enhanced命令配置接口下缓存管理的突发模式为加强模式，以尝试缓解网络拥塞。
在延时可控和缓存充足的状况下，在发生拥塞的转发设备的上游交换机下行接口经过qos queue queue-index shaping { percent cir cir-percent-value [ pir pir-percent-value ] | cir cir-value [ kbps | mbps | gbps ] [ cbs cbs-value [ bytes | kbytes | mbytes ] | pir pir-value [ kbps | mbps | gbps ] [ cbs cbs-value [ bytes | kbytes | mbytes ] pbs pbs-value [ bytes | kbytes | mbytes ] ] ] }命令开启流量×××功能，削弱流量的瞬时波峰，能够控制突发的程度。须要注意的是，此方案会致使报文转发时延加大。
网络中全部设备的接口均经过dcb pfc enable [ pfc-profile-name ] [ mode { auto | manual } ]命令开启流量控制功能，从而在转发设备发生拥塞时，通知上游设备下降发包速率甚至中止发包，待拥塞解除之后再恢复报文的正常发送。须要注意的是，此方案会致使报文转发时延加大。

参考连接：https://support.huawei.com/enterprise/zh/doc/EDOC1000052631/df738486