上一期《业务延迟：当Nagle“攒数据” 遇上Delayed ACK“拖确认”》我们介绍了延迟确认与Nagle算法，接下来我们将围绕丢包和乱序，继续和大家探讨TCP相关内容。
什么是丢包和乱序？
丢包，顾名思义，数据包丢失的情况。丢包是指在网络传输过程中数据包未能成功到达目的地而被丢失的现象。造成这一现象的原因通常包括网络带宽不足、软硬件故障、安全拦截、配置不当等。
乱序，顾名思义，数据包顺序错乱的情况。乱序是指在网络传输过程中数据包到达接收端的顺序与发送端发出的顺序不一致的现象。造成这一现象的原因通常包括网络拥塞、路由路径不同、设备处理延迟等。
丢包和乱序对TCP带来的影响相同，会导致网络性能下降和业务连接不稳定。
时序图如何体现丢包和乱序？
科来CSNA系统中的时序图功能，通过发送方序列号的连续性判断数据是否出现丢包、乱序的异常情况，若发送方的两个数据包序列号不连续，则会标记为异常。具体的丢包、乱序的异常情况如下两图所示：
图1 TCP时序图下的丢包
如图1所示，服务器发送的9号包序列号为2203718610，载荷长度为1452
CSNA系统计算得出的Next Seq（下一包序列号）为：
2203718610+1452=2203720062。
随后，服务器发送了11号包，该包序列号为2203722966，与9号包的Next Seq数值相差2203722966-2203720062=2904，说明丢失了2904字节的载荷数据。再根据9号包和11号包的载荷长度1452字节来估测，丢失的2904字节载荷数据应该是2个数据包。因此判断11号包与9号包之间丢失了2个数据包。CSNA系统将11号数据包标记为红色，提示“TCP之前可能有数据包丢失”。
乱序的情况，如下图所示：
图2 TCP时序图下的乱序
在时序图中，乱序，通常出现在丢包之后。如图2所示，观察图中服务器发送的12号包和14号包，通过Seq和NextSeq观察分析，确定丢失了1873395574-1873395455=119，丢失了119字节的数据，因此14号包被标记为“TCP之前可能有数据包丢失”。
随后，服务器发送了15号包，该包长度恰好是119字节，且序列号能够与12号包的Next Seq相对应，且15号包与其前一个报文14号包的时间差小于一个RTT。因此软件判断15号包恰好是14号包之前丢失的那个数据包。因此，15号包被标记为“乱序”。
注：在本例中，通过服务器发送数据的顺序逻辑，也可分析乱序。14号包是传输层FIN包，15号包是应用层响应包。服务器应是先发出应用层响应（15号包），后发出传输层FIN（14号包），通过这点，能够非常明显能看出本图的示例中的乱序情况。
如何“实锤”丢包乱序设备
发送方发送数据时，不可能存在丢包乱序情况，丢包乱序等情况一定是在中间转发过程中出现的。假设出现故障的设备为防火墙A，那么防火墙A连接TCP发送方一侧（后文简称墙前，可能是客户端或服务器的任意一方）和连接接收方一侧（后文简称墙后，墙后也可能是客户端或服务器的任意一方）的流量捕获结果一定不同。
通常，如果怀疑墙是引发丢包的设备，需要实锤，则需要使用“墙前墙后流量对比”的分析方法，明确丢包位置。部署了科来UPM产品的客户则可以将此流程进行精简，无需对比墙前墙后流量，也无需额外测试抓包，仅需在UPM上对比墙前墙后指标有无增长，即可快速判断在此设备上是否出现故障。
下图3和图4分别展示了数据包丢包会话在墙后（服务器侧，已发生丢包）和墙前（客户端侧，未发生丢包）时的抓包现象对比：
图3 丢包会话在墙后的抓包情况
如图3所示，该会话发生了丢包。41号数据包与42号数据包Seq号不连续，41号包的Next Seq与42号包的Seq差值为4209747039-4209745579=1460，根据该会话中单包载荷长度1460推测，42号包与41号包之间丢失了一个数据包，该包序列号为4209745579。
再观察下图，下图为同一条会话在客户端侧的抓包情况：
图4 丢包会话在墙前的抓包情况
如图4所示，该位置观测到的流量，数据包序列号连续，未发生丢包。图3中丢失的序列号为4209745579的数据包，在本位置抓包也还健在，未丢失。
至此，通过对比Seq号，确定了图3第42号包、图4第43号包为同一数据包，墙前墙后抓包点流量存在差异，证实丢包设备为中间设备墙A。
注：丢包与乱序分析的方法相同，这里不再列举乱序的分析方法。此例中，服务器仅设置了1%的丢包率，就足以使传输时间多花好几倍。不要再小看丢包故障了，有丢包还是要尽快解决。
单点抓包，能否判断丢包/乱序位置？
通过流量对比分析法，能够精确判断丢包设备是哪一台。在实际数据中心网络运维工作中，网络情况较为复杂，一条业务完整的从外网进入，需要经过负载、防火墙、SSL等一系列设备的转发，最终到达服务器。若发生了丢包，使用流量对比分析法，需要对比负载、防火墙、SSL每一点位前后流量，在复杂网络架构情况下，对比分析法的的工作量显然过于复杂。
一个比较简便的方法是，通过单点位抓包，二分法观察，判断丢包是来自此位置前或此位置后。此方法不需要多点位流量对比，只需要单点位观察即可。仍以上一小节的丢包流量为例，图3发生了丢包，被红的数据包序列号为4209747039。由于该位置的流量已经被标记为异常红色，说明流量传至此位置时已经发生丢包，在本次举例中，我们假设该位置为C点。
以C点为基准点，沿着流量发送来的方向，继续向前检索B点和A点。假设B点不具备流量监测条件，而A点已部署科来回溯产品，则从A点调取该故障会话的历史流量。从A点流量中寻找C点中标红的、序列号为4209747039的数据包，结果如下图所示：
图5 故障会话在A点的流量
通过过滤发现，A点的流量并未标红，说明流量传至A点时未发生丢包。综合之前的分析结果，流量到达A点时未发生丢包，到达C点时已发生丢包，至此判断丢包点就在AC之间。下一步工作着重分析B点是否存在丢包情况。
乱序的分析方法与丢包同理，这里不再赘述。
实际的丢包分析案例
导致丢包的故障原因千千万，丢包故障实际现象却只有一种。下面的视频里展示了一个特定端口丢包的实际案例，通过更换位置压测、抓包分析定位到丢包故障点的案例：
结语
本文介绍了TCP的丢包和乱序，深入探讨了两种故障流量现象，以及两种故障的根因位置定位方法，以及在CSNAS时序图中对于此类问题的分析方法，通过深入理解和掌握此类分析技巧，能够提升流量分析工程师在工作中快速分析解决此类故障的能力。