鲁达 阅读本文约需要8分钟，您可以先关注我们，避免下次无法找到。
今天系统运维负责人找到成哥反馈，昨天晚上有很多业务超时日志，说是不是网络抖动了？成哥心里一沉，又怪到网络抖动了？网络真的这么容易抖动吗？网络的抖动会造成业务超时吗？
01 网络抖动概念
网络抖动简单来说就是报文在传输过程，正常10ms可以到达对端。网络抖动期间，延迟不稳定，可能50ms甚至100ms才到达对端。
那造成网络抖动的原因是什么呢？一般是网络中发生了网络拥塞，比如接口带宽1000Mbps，但是某一时刻的流量超过了这个值。
当网络中发生拥塞时，QoS（Quality of Service，服务质量）功能生效，设备在转发报文的时候队列机制开始工作。
默认情况下使用的是硬件队列，硬件队列采取的是FIFO，即先进到队列的报文优先转发出去，如果队列中排在前面的数据包较多则延迟增大。
当然在实际的生产环境中，我们会对重要的业务流量打标签，当发生网络拥塞时，采取差分服务，即对延迟比较敏感的业务优先转发，比如音频、视频、云游戏等。
02 网络抖动的影响
偶尔出现的网络抖动到底对业务交互影响大不大呢？这个只能说和业务的健壮性和具体的网络抖动程度相关。
但是一般来说几十、几百毫秒的延迟抖动是不会对业务有明显影响的（非延迟敏感业务）。有人说延迟几百毫秒不会被判定为丢包了吗？
只要你用的是TCP协议，这个问题就不是问题，大家都知道TCP协议是有重传机制的，当报文在规定时间内没有收到确认ACK时，TCP会触发重传机制。
如果您对TCP的知识还不甚了解，可以前往@IT管理局查看成哥写的《一文秒懂 TCPIP实际五层结构》系列文章。
TCP默认会重传16次，耗时是9分钟，网络延迟不至于大到9分钟吧。
当然实际的业务部署环境中，系统内核不会允许TCP重传16次的，一般都是重传3~6次就会发送RST报文来重置链接。
有图有真相，6次TCP重传后连接被RST，共计耗时29秒：
因为延迟几分钟达到的报文已经没有意义了，因此业务层面也会通过代码限定数据交互的超时时间，避免让用户等待太久，从而影响体验。
03 网络异常模拟工具
上一段也说了网络延迟对业务的影响到底大不大和业务的健壮性、具体的网络抖动程度相关，那我们怎么确定这两者之间的具体关系呢。
接下来给大家介绍一个网络异常的模拟工具，可以模拟网络抖动、延迟、丢包等情况。
netem 是 Linux 2.6 及以上内核版本提供的一个网络模拟功能模块，该功能模块可以用来在性能良好的局域网中模拟出复杂的互联网传输性能。
TC (Traffic Control，流量控制)是Linux 系统中的一个工具。文本介绍的就是通过TC来控制netem来实现网络异常的情况。
废话不多说，直接上命令，下述名命令的意思是将eth0网卡的传输延迟设置为50ms：
# tc qdisc add dev eth0 root netem delay 50ms网络抖动实际上就是不规则的延迟，我们通过如下命令来模拟网络抖动，下述命令的意思是网络延迟40~60ms之间：
# tc qdisc add dev eth0 root netem delay 50ms 10ms我们再加一个参数，实现更加随机的网络抖动，下述命令的意思是在50ms的延迟基础上，10%的报文延迟在40~60ms之间波动：
# tc qdisc add dev eth0 root netem delay 50ms 10ms 10%下述命令是模拟网卡丢包2%的场景：
# tc qdisc add dev eth0 root netem loss 2%下述命令是模拟网卡报文重传2%的场景：
# tc qdisc add dev eth0 root netem duplicate 2%下述命令是查看网卡已经配置的tc策略：
# tc qdisc show dev eth0最后大家做完测试后，别忘记删除配置策略，命令很简单，下述命令是将eth0网卡上的tc xxx策略删除：
#tc qdisc del dev eth0 xxx04 总结
通过TC工具，可以模拟不同级别的网络异常情况，看看网络抖动到什么程度才会影响业务体验。
当然我们通过模拟网络异常不是最终目的，更不是一种甩锅的手段。只是为了协助应用系统做更好的调优，机房内的网络异常我们可以解决，但是互联网的网络异常我们没有手段处理的，这时就需要业务系统本身的强大来减少网络异常给用户带来的不佳体验。
--END--
@IT管理局专注计算机领域技术、大学生活、学习方法、求职招聘、职业规划、职场感悟等类型的原创内容。期待与你相遇，和你一同成长。
相关文章：
- 一文秒懂 TCP/IP实际五层结构（上篇）
- 一文秒懂 TCP/IP实际五层结构（中篇）
- 一文秒懂 TCP/IP实际五层结构（下篇）