什么是导致 [FIN, ACK]，[RST] 和 [RST, ACK] 的原因以及如何避免？

Question

什么是产生 [FIN, ACK]、[RST] 和 [RST, ACK] 的原因，以及如何避免这种情况?

这是由于SO的TCP参数之间存在某些不匹配吗？当服务器在TCP/IP连接中回复 [FIN, ACK] 时，它意味着什么？

10.118.113.237 是一个Solaris盒子，而 10.118.110.63 是一个Linux盒子。

No.     Time           Source                Destination           Protocol Length Info
  1 0.000000000    10.118.113.237        10.118.110.63         TCP      68     mmpft > 39679 [FIN, ACK] Seq=1 Ack=1 Win=49232 Len=0 TSval=62389927 TSecr=355193509
  2 0.000015000    10.118.110.63         10.118.113.237        TCP      56     39679 > mmpft [RST] Seq=1 Win=0 Len=0
  4 0.119357000    10.118.110.63         10.118.113.237        TCP      68     39707 > mmpft [ACK] Seq=1 Ack=93 Win=54 Len=0 TSval=355208473 TSecr=62389939
  5 0.119475000    10.118.113.237        10.118.110.63         TCP      62     mmpft > 39707 [RST, ACK] Seq=93 Ack=1 Win=0 Len=0
  6 0.321336000    10.118.110.63         10.118.113.237        TCP      76     55603 > mmpft [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSval=355208524 TSecr=0 WS=128
  7 0.321835000    10.118.113.237        10.118.110.63         TCP      80     mmpft > 55603 [SYN, ACK] Seq=0 Ack=1 Win=49232 Len=0 TSval=62389959 TSecr=355208524 MSS=1460 WS=1 SACK_PERM=1
  8 0.321854000    10.118.110.63         10.118.113.237        TCP      68     55603 > mmpft [ACK] Seq=1 Ack=1 Win=5888 Len=0 TSval=355208524 TSecr=62389959
  9 0.322552000    10.118.110.63         10.118.113.237        DIAMETER 276    cmd=Capabilities-ExchangeRequest(257) flags=R--- appl=Diameter Common Messages(0) h2h=3f3197c e2e=e9200846
 10 0.322891000    10.118.113.237        10.118.110.63         TCP      68     mmpft > 55603 [ACK] Seq=1 Ack=209 Win=49024 Len=0 TSval=62389959 TSecr=355208524
 11 0.342554000    10.118.113.237        10.118.110.63         TCP      68     mmpft > 39707 [FIN, ACK] Seq=93 Ack=1 Win=49232 Len=0 TSval=62389961 TSecr=355200968
 12 0.342567000    10.118.110.63         10.118.113.237        TCP      56     39707 > mmpft [RST] Seq=1 Win=0 Len=0
 13 0.346940000    10.118.113.237        10.118.110.63         DIAMETER 312    cmd=Capabilities-ExchangeAnswer(257) flags=---- appl=Diameter Common Messages(0) h2h=3f3197c e2e=e9200846
 14 0.347021000    10.118.110.63         10.118.113.237        TCP      68     55603 > mmpft [ACK] Seq=209 Ack=245 Win=6912 Len=0 TSval=355208530 TSecr=62389961
 15 4.288733000    10.118.113.237        10.118.110.63         TCP      68     mmpft > 39652 [FIN, ACK] Seq=1 Ack=1 Win=49232 Len=0 TSval=62390356 TSecr=355186382
 16 4.288757000    10.118.110.63         10.118.113.237        TCP      56     39652 > mmpft [RST] Seq=1 Win=0 Len=0
 17 4.398722000    10.118.113.237        10.118.110.63         DIAMETER 160    [TCP Retransmission] cmd=Device-WatchdogRequest(280) flags=R--- appl=Diameter Common Messages(0) h2h=f889ad2 e2e=5f8035e4
 18 4.398734000    10.118.110.63         10.118.113.237        TCP      56     39707 > mmpft [RST] Seq=1 Win=0 Len=0
 19 4.938748000    10.118.113.237        10.118.110.63         DIAMETER 160    cmd=Device-WatchdogRequest(280) flags=R--- appl=Diameter Common Messages(0) h2h=f889ad0 e2e=5f8035df
 20 4.938770000    10.118.110.63         10.118.113.237        TCP      56     39598 > mmpft [RST] Seq=1 Win=0 Len=0
 21 5.498759000    10.118.113.237        10.118.110.63         TCP      68     mmpft > 39544 [FIN, ACK] Seq=1 Ack=1 Win=49232 Len=0 TSval=62390477 TSecr=355156526
 22 5.498783000    10.118.110.63         10.118.113.237        TCP      56     39544 > mmpft [RST] Seq=1 Win=0 Len=0
 23 5.648780000    10.118.113.237        10.118.110.63         TCP      68     mmpft > 55774 [FIN, ACK] Seq=1 Ack=1 Win=49232 Len=0 TSval=62390492 TSecr=355111580
 24 5.648804000    10.118.110.63         10.118.113.237        TCP      56     55774 > mmpft [RST] Seq=1 Win=0 Len=0
 25 5.942885000    10.118.113.237        10.118.110.63         TCP      68     mmpft > 55828 [FIN, ACK] Seq=1 Ack=1 Win=49232 Len=0 TSval=62390521 TSecr=355126129
 26 5.942901000    10.118.110.63         10.118.113.237        TCP      56     55828 > mmpft [RST] Seq=1 Win=0 Len=0
 27 6.668742000    10.118.113.237        10.118.110.63         TCP      68     mmpft > 55666 [FIN, ACK] Seq=1 Ack=1 Win=49232 Len=0 TSval=62390594 TSecr=355081310
 28 6.668760000    10.118.110.63         10.118.113.237        TCP      56     55666 > mmpft [RST] Seq=1 Win=0 Len=0
 29 7.258815000    10.118.113.237        10.118.110.63         TCP      68     mmpft > 55720 [FIN, ACK] Seq=1 Ack=1 Win=49232 Len=0 TSval=62390653 TSecr=355096418
 31 7.418827000    10.118.113.237        10.118.110.63         DIAMETER 160    cmd=Device-WatchdogRequest(280) flags=R--- appl=Diameter Common Messages(0) h2h=f889acd e2e=5f8035d9
 32 7.418835000    10.118.110.63         10.118.113.237        TCP      56     39490 > mmpft [RST] Seq=1 Win=0 Len=0
 33 12.948752000   10.118.113.237        10.118.110.63         DIAMETER 160    [TCP Retransmission] cmd=Device-WatchdogRequest(280) flags=R--- appl=Diameter Common Messages(0) h2h=f889ad2 e2e=5f8035e4
 34 12.948776000   10.118.110.63         10.118.113.237        TCP      56     39707 > mmpft [RST] Seq=1 Win=0 Len=0
 35 30.030087000   10.118.113.237        10.118.110.63         DIAMETER 160    [TCP Retransmission] cmd=Device-WatchdogRequest(280) flags=R--- appl=Diameter Common Messages(0) h2h=f889ad2 e2e=5f8035e4
 36 30.030113000   10.118.110.63         10.118.113.237        TCP      56     39707 > mmpft [RST] Seq=1 Win=0 Len=0
 38 30.369302000   10.118.110.63         10.118.113.237        TCP      68     55603 > mmpft [ACK] Seq=209 Ack=337 Win=6912 Len=0 TSval=355216035 TSecr=62392964
 39 30.369413000   10.118.113.237        10.118.110.63         TCP      62     mmpft > 55603 [RST, ACK] Seq=337 Ack=209 Win=0 Len=0
 40 30.571231000   10.118.110.63         10.118.113.237        TCP      76     55630 > mmpft [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSval=355216086 TSecr=0 WS=128
 41 30.571603000   10.118.113.237        10.118.110.63         TCP      80     mmpft > 55630 [SYN, ACK] Seq=0 Ack=1 Win=49232 Len=0 TSval=62392984 TSecr=355216086 MSS=1460 WS=1 SACK_PERM=1
 42 30.571620000   10.118.110.63         10.118.113.237        TCP      68     55630 > mmpft [ACK] Seq=1 Ack=1 Win=5888 Len=0 TSval=355216086 TSecr=62392984
 43 30.572253000   10.118.110.63         10.118.113.237        DIAMETER 276    cmd=Capabilities-ExchangeRequest(257) flags=R--- appl=Diameter Common Messages(0) h2h=3f3197d e2e=e9200847
 44 30.572638000   10.118.113.237        10.118.110.63         TCP      68     mmpft > 55630 [ACK] Seq=1 Ack=209 Win=49232 Len=0 TSval=62392984 TSecr=355216086
 45 30.579815000   10.118.113.237        10.118.110.63         TCP      68     mmpft > 55603 [FIN, ACK] Seq=337 Ack=209 Win=49232 Len=0 TSval=62392985 TSecr=355208530
 46 30.579826000   10.118.110.63         10.118.113.237        TCP      56     55603 > mmpft [RST] Seq=209 Win=0 Len=0
 47 30.581517000   10.118.113.237        10.118.110.63         DIAMETER 312    cmd=Capabilities-ExchangeAnswer(257) flags=---- appl=Diameter Common Messages(0) h2h=3f3197d e2e=e9200847
 48 30.581553000   10.118.110.63         10.118.113.237        TCP      68     55630 > mmpft [ACK] Seq=209 Ack=245 Win=6912 Len=0 TSval=355216088 TSecr=62392985
 49 34.138766000   10.118.113.237        10.118.110.63         TCP      68     mmpft > 39679 [FIN, ACK] Seq=1 Ack=1 Win=49232 Len=0 TSval=62393341 TSecr=355193509
 50 34.138790000   10.118.110.63         10.118.113.237        TCP      56     39679 > mmpft [RST] Seq=1 Win=0 Len=0

- Sergio Pettena

Answer 1

以下是翻译的结果：

以下是相关概念的简单解释。

[ACK] 是确认之前发送的数据包已经被接收到的信号。

[FIN] 是在主机想要终止连接时发送的信号；TCP协议要求两个端点都发送终止请求（即FIN）。

因此，假设

• 主机 A 发送数据包给 主机 B
• 然后 主机 B 想要关闭连接。
• 主机 B （取决于时间）可以回复一个[FIN, ACK]，表示它已经接收到了发送的包，并希望关闭会话。
• 主机 A 应该回复一个[FIN, ACK]，表示它已经接收到了终止请求（ACK 部分），并且也将关闭连接（FIN 部分）。

然而，如果主机A在发送数据包后想要关闭会话，它只会发送一个[FIN]数据包（没有需要确认的内容），但是主机B会回复一个[FIN,ACK]数据包（确认请求并用FIN回复）。

最后，一些TCP堆栈执行半双工终止，这意味着它们可以发送[RST]而不是通常的[FIN,ACK]。当主机主动关闭会话而没有处理所有发送到它的数据时，就会发生这种情况。Linux是执行此操作的一种操作系统。

你可以在这里找到更详细和全面的解释。

- isedev

---

发送RST并不是“半双工终止”，而是中止连接的两端。正常的FIN/ACK协议才是半双工终止。 - user207421

独立地说，无论是[FIN，ACK]包还是[RST]包，两个主机之间的连接都处于已建立状态。由于错误的网络配置（一侧全双工100Mbps，另一侧半双工10Mbps，错误的防火墙配置，错误的操作系统TCP参数等），TCP堆栈是否会发送[RST]和[FIN，ACK]？ - Sergio Pettena

请参考 RFC 1122 的 4.2.2.13 节，其中提到：“主机可以实现‘半双工’TCP关闭序列，这样调用 CLOSE 的应用程序将无法继续从连接中读取数据。如果这样的主机在 TCP 中仍有待处理的接收数据时发出 CLOSE 调用，或者在调用 CLOSE 后接收到新数据，则其 TCP 应发送 RST 表示数据丢失。” 当所有数据都被读取后，[FIN] 数据包将从两个端点发送——这是全双工而不是半双工，并且完全同步（在此意义下，必须预先读取所有数据）。 - isedev

@SergioPettena 双工和/或链路速度不匹配通常会导致大量的丢包和重传数据包（这可能会导致更高的[RST]计数）。但是，[RST]本身并不一定表明这种错误配置；您应该检查TCP堆栈统计信息（例如，在Unix/Linux上使用netstat -s）。有些防火墙可能会在连接不活动超时时发送RST。然而，从您的跟踪中看来，大多数[RST]都是响应于[FIN，ACK]，因此更可能是半双工终止序列。 - isedev