高效排障：详解RST，判定连接重置根因（二）

TCP连接中为何会有RST包？

TCP RST包，即TCP头部中RST位设置为1的数据包。根据RFC 793，TCP RST包用于终止一个现有的连接或拒绝一个连接请求。当一个TCP端点希望立即终止一个连接时，它会发送一个RST包。

因此，当客户端或服务器的任意一方需要拒绝连接，或认为连接出现错误时，即可以发送RST包重置当前TCP连接。RST包在TCP时序图中的体现如图1所示：

图1：时序图中的TCP RST包

连接建立阶段的RST包如何分析？

在连接建立阶段，服务器可发送RST包拒绝连接建立，如图2所示，在连接建立阶段，服务器发送RST包，表示服务器拒绝连接。

图2：服务器拒绝连接

如果服务器发送RST包拒绝连接，一般可能由如下原因导致：

服务器端口未开放：服务器在该端口未运行网络服务，或服务器上客户所请求的服务失效，则服务器会通过RST拒绝新连接。
服务器TCP连接数达到极限：如果服务器设置了tcp_abort_on_overflow=1，那么服务器在队列满时会发送RST包拒绝连接。
Time_Wait状态：如果客户端使用的当前socket在上一个连接刚刚结束，且服务器当前socket处于time_wait状态，则此时使用该socket的新连接请求会被服务器拒绝，返回RST包。
SYN包格式错误：客户端发送的SYN包携带了其它未经允许的标记（例如FIN、URG或其他标记），则服务器会拒绝连接并直接返回RST
防火墙策略不允许：如果客户端IP被禁止连接，则会话中会出现RST包，此种情况在后文中具体讨论。

如果在会话连接建立阶段出现了服务器RST的情况，建议从服务器位置分析流量，或在系统层面排查连接建立失败的原因。

除服务器外，在连接建立阶段，客户端也有可能发送RST包，如图3、图4所示，在连接建立已经经历了SYN包、SYN/ACK包的交互后，甚至三次握手完成后，客户端突然发送RST包，表示客户端拒绝连接。

图3：客户端在收到SYN/ACK包后发送RST

图4：客户端在三次握手成功后立即发送RST

对于图3、图4中出现的情况，可以直接判断为客户端发生异常或客户端正在发起端口扫描攻击。其中图3的流量为典型客户端发起TCP SYN端口扫描时序图，图4的流量为典型的客户端发起TCP Connect端口扫描时序图，如遇到此类时序图，请使用策略封禁该客户端IP地址，并检查客户端IP地址的其它流量，观察其有无其它攻击行为。

数据传输阶段的RST包如何分析？

在数据传输阶段，客户端和服务器均可能随时发出RST，此时RST的原因一定是连接出现异常。对于此类故障，常见如下原因：

重传次数超限：TCP具有重传机制，当TCP尝试多次重传而无法收到对方的确认（或对方发来的确认无法被接收处理，例如序列号错误、校验和错误等种种字段错误）后，重传的一方将会认为连接出现错误，停止重传并发送RST包重置连接。如图5所示。

图5：多次重传后，服务器认为会话错误发送RST

连接长时间无数据交互：当客户端和服务器之间长时间（例如120秒）无数据交互时，其中一方可能认为会话超时，会向发送RST包重置连接。如图6所示。在客户端和服务器中间流量经过负载均衡或防火墙的场景，RST包也可能由负载或防火墙发出。

图6：120秒无交互后，服务器认为会话超时发送RST

如果在会话交互阶段出现了RST的情况，建议通过分析时序图判断重置的原因是错误或超时。如果怀疑RST包是从中间设备发出，可以通过对比多个位置的同时段流量，确定RST包来源，从而进一步排查故障原因。

被防火墙阻断的会话时序图是什么样的？

当ACL或安全策略匹配后的动作为Reject时，或安全设备是旁路部署无法直接丢弃流量时，安全设备会采用发送RST包方式去处理策略命中的会话。被RST的会话会因此中断。被安全策略阻断的会话如图7所示

图7：连接被其他设备RST阻断

通过图7可以看出，服务器响应了SYN/ACK包，而立刻回复了一个RST，这是由于发送RST包的设备为中间的安全设备，在进行旁路阻断时，只能通过发送RST进行阻断，而无法拦截服务器已发出的SYN/ACK包。因此，从客户端处能够看到服务器“同时回复”了SYN/ACK包和RST包。

如果要问，为什么能判断这个RST一定是旁路阻断包，那可以仔细观察这些RST包，本文图1、图2、图4、图5、图6中的RST包，均为携带RST,ACK这两个标志位的“真RST包”，而图3、图7中的RST包是仅携带RST标志位的“假RST包”，另外，如果能够对比RST包和SYN/ACK包的IP TTL，则可以发现这两个包的IP TTL可能不同（也有部分设备能对TCP RST包的IP TTL拟真），说明其来自于两个不同的网络位置，如图8所示：

图8：“假RST”与“真RST” 的TTL不同

图9则描述了一种更加容易理解的旁路阻断：客户端发送ClientHello包后，中间的旁路设备阻断了客户端，但未向服务器发送RST，导致服务器认为会话未中断，还在继续发送后续ServerHello数据包：

图9：旁路阻断RST

总之，如果会话过程中出现RST包，需要考虑该RST包是否由中间旁路阻断设备发出，可以通过该RST包的RST位、序列号、IP TTL等方式，或是直接多点抓包对比分析，综合判断。

连接断开阶段的RST包如何分析？

在连接断开阶段，也可能出现RST包，这种情况一般是由于接收FIN包的一方或中间的负载、安全设备存在关于连接断开的优化机制。因为会话如果经过FIN包四次断开结束，先发FIN包的一方会经过TCP TIME_WAIT状态，经过2MSL时间才会进入到close状态，彻底关闭连接。在2MSL时间段内，此socket不可用。而被RST重置的会话，则不存在TIME_WAIT状态，因此，一些连接在出现FIN包后，负载/安全设备认为该连接已经可以被结束，于是发送RST包快速关闭会话。这种方法虽然快捷但不符合TCP协议标准。被RST加速断开的会话如图10和图11所示：

图10：客户端FIN后出现RST快速断开连接

图11：服务器FIN后出现RST快速断开连接

在TCP连接的生命周期中，RST包扮演了一个关键角色，通过时序图观察RST包出现时机的分析，我们可以看到RST包在连接建立、数据传输、异常阻断、连接断开阶段的出现原因和影响。

了解RST包的发送原因，是维护网络稳定性和安全性的重要技能。通过细致的RST包分析，可以有效地分析网络故障、优化网络性能和提升网络的安全性。

↑↑↑长按图片识别二维码关註↑↑↑