为什么我看到的是RST，ACK包而不是RST包？

Question

在Wireshark中，我经常看到TCP流以RST，ACK数据包而不是RST数据包结尾。有人知道这是为什么吗？

我看到的一个例子是：

...data.雷斯特角

Wireshark不会在RST、ACK数据包之前接收RST数据包。

Answer 1

RST/ACK不是对RST的确认，与SYN/ACK不完全是对SYN的确认相同。TCP建立实际上是一个四通八达的过程:初始化主机向接收主机发送一个SYN，接收主机为该SYN发送一个ACK。接收主机向发起主机发送SYN，该主机将ACK发回。这就建立了有状态的通信。

SYN --> 
    <-- ACK
    <-- SYN
ACK -->

为了提高效率，接收主机可以ACK SYN，并在同一个数据包中发送自己的SYN，创建我们习惯的三路进程。

SYN -->
    <-- SYN/ACK
ACK -->

在RST/ACK的情况下，该设备正在确认以ACK顺序在前一个数据包(S)中发送的任何数据，然后通知发送方该连接已与RST关闭。该设备只是简单地将两个包组合成一个，就像SYN/ACK一样。在关闭TCP会话时，RST/ACK通常不是正常的响应，但也不一定表示存在问题。

Answer 2

一旦建立了连接，所有数据包都需要设置ACK并与接收到的数据包的序列号相匹配，以获得可靠的传输/安全性。没有ACK的RST将不被接受。当一方发送RST时，套接字立即关闭，接收方也在接收有效RST后立即关闭该套接字。它不需要也不能被承认。

TCP握手后

A->B Syn=x，Ack=y，len=z，ACK旗帜

B-->A Syn=y，Ack=x+z，len=o，ACK旗帜

A->B Syn=x+z，Ack=y+o，len=p，ACK旗帜

B->A Syn=y+o，ACK=x+z+p，len=q，RST，ACK旗帜

B在发送最后一个数据包后关闭套接字，A在接收到套接字后关闭该套接字。

(此处不考虑TCP窗口，否则可能会有更多来自一端的数据包。)

会旗、确认号和确认程序是相关的，但不是一回事。

每RFC793 793

RFC793

确认号: 32位

If the ACK control bit is set this field contains the value of the
next sequence number the sender of the segment is expecting to
receive.  Once a connection is established this is always sent.

复位处理

在除SYN发送之外的所有状态中，所有重置(RST)段都通过检查其SEQ-字段来验证.如果重设的序列号在窗口中，则重置是有效的。在SYN发送状态(响应于初始SYN接收的RST )中，如果ACK字段确认SYN，则RST是可以接受的。

RST的接收方首先验证它，然后更改状态。如果接收者处于侦听状态，则忽略它。如果接收器处于SYN接收状态，并且先前处于侦听状态，则接收器返回侦听状态，否则接收器中止连接并进入关闭状态。如果接收器处于任何其他状态，则中止连接并通知用户并进入关闭状态。