高效排障：快速重传与虚假重传的根因及处置

上一篇《高效排障：不同情况下的重传根因及处置建议》中，我们分享了TCP异常流量标记“重传”的几种常见场景及解决方案，今天让我们一起来展开聊聊其中的“快速重传”和“虚假重传”。

  快速重传  

众所周知，为提高TCP传输性能，当接收方收到序列号不连续的TCP分段时，会发送重复的ACK报文，连续三个重复的ACK报文就会触发TCP的快速重传机制。

标记原理

在一个TCP报文满足重传的基本条件情况下，如果：

则该报文被标记为“快速重传”。

那么，什么情况下会引起快速重传呢？我们来看典型的场景。

情况1

报文在转发方向上采集点之后丢失。

如图1所示，报文①的”Next Seq=855774175”，报文②的“Ack=855772715”，说明客户端确认的是报文①的上一个报文，而不是确认的报文①。报文③和报文④被标记为“重复ACK”，说明客户端暂未收到服务器发送的报文①及之后的报文。报文⑤则是因触发了TCP快速重传机制后，服务器对该报文进行的“快速重传”。

根因及处置建议

根据上述分析，此场景可能的情况是报文在服务器向客户端转发方向上采集点之后丢失。应排查该段服务器到客户端方向的安全设备是否存在对应报文的阻断日志。

情况2

报文在转发方向上采集点之前丢失。

图2

如图2所示，报文①的”Next Seq=3928999908”，报文②的“Ack=3928999908”，说明客户端确认的是报文①。此后服务器发送了报文③“Seq=3929007208”，并不等于报文①的“Next Seq=3928999908”，被认为“TCP之前可能有数据包丢失”，此后服务器继续发送报文则触发客户端发送“重复ACK” （④⑤），触发TCP快速重传机制，服务器对该报文进行“快速重传”⑥。

根因及处置建议

根据上述分析，此场景可能的情况是报文在服务器向客户端转发方向上采集点之前丢失。应排查该段服务器到客户端方向的安全设备是否存在对应报文的阻断日志。

  虚假重传  

现在我们来说说虚假重传。

标记原理

在满足TCP重传条件的前提下，当前报文计算的下一序列号小于等于对端报文ACK的序列号。

图3

通俗来讲，就是一个已经被ACK确认过的TCP分段，再次被传输（重传），那么这个分段就会被标记为“虚假重传”，如图1。那么什么情况会导致“虚假重传”呢？

报文传输被延迟，导致超时重传。

图4

如图2所示，报文①被标记为“虚假重传”，其Seq=4037091112小于对向确认报文③的Ack=4037103763。注意观察报文②的Ack=4037092098与报文①的Next Seq=4037092098相等，说明这是对报文①收到的字节序确认。而报文②的Ack=4037092098小于文③的Ack=4037103763，TCP是累计确认机制，因此可以判断报文①、②的产生时间早于报文③，只是在转发过程中被延迟了。

根因及处置建议

在大型业务系统中，报文被延迟转发并不是完全不允许的，如果只是偶尔的个别情况通常无需关心，但若经常出现这类重传情况，则应关注网络层面是否存在转发瓶颈。

如果是通过TAP交换机结合网络交换机端口镜像技术采集而来的流量，则应注意是否是由于镜像报文失序而导致了CSNAS将其误判为“虚假重传”。

分析TCP交易时序图是运维人员和流量分析工程师的“日常”。了解科来网络分析系统TCP流分析视图中TCP交易时序图的TCP异常流量标记，能够做到在分析TCP流量时事半功倍。及时的定位故障层面，定位故障节点，定位故障根因。