[FIN, ACK] , [RST] 和 [RST, ACK] 是什么原因以及如何避免答案

【问题标题】：What is the reason and how to avoid the [FIN, ACK] , [RST] and [RST, ACK][FIN, ACK] , [RST] 和 [RST, ACK] 是什么原因以及如何避免
【发布时间】：2013-02-17 09:25:48
【问题描述】：

[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

【问题讨论】：

标签： linux sockets tcp solaris wireshark

【解决方案1】：

这里是对概念的粗略解释。

[ACK]是确认收到之前发送的数据包。

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

所以，假设

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

然而，如果 host A 想在发送数据包后关闭会话，它只会发送一个 [FIN] 数据包（无需确认），但 host B 会回复[FIN,ACK]（确认请求并回复FIN）。

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

你可以找到更详细和全面的解释here。

【讨论】：

发送 RST 不是“半双工终止”，它正在中止连接的两端。正常的 FIN/ACK 协议是半双工终止。
独立的 [FIN, ACK] 包和 [RST] 包之间的连接都处于 ESTABLISHED 状态。由于错误的网络配置（一侧全双工 100Mbps、另一半双工 10Mbps、错误的防火墙配置、错误的操作系统 tcp 参数等），TCP Stack 是否可以发送 [RST] 和 [FIN, ACK]？
@EJP 请参阅 RFC 1122 的第 4.2.2.13 节：“主机可以实现“半双工”TCP 关闭序列，因此调用 CLOSE 的应用程序无法继续从连接中读取数据. 如果这样的主机发出 CLOSE 调用，而接收到的数据仍在 TCP 中等待处理，或者如果在调用 CLOSE 后接收到新数据，它的 TCP 应该发送 RST 以表明数据已丢失。当所有数据都被读取后，[FIN] 数据包从两个端点发送——这是全双工的，而不是半双工的，并且是完全同步的（在某种意义上，所有数据都必须预先读取）。
@SergioPettena 双工和/或链路速度不匹配通常会导致大量丢弃和重新传输的数据包（这可能导致更高的 [RST] 计数）。但是 [RST] 本身并不能明确表明这种配置错误；您应该检查 TCP 堆栈统计信息（例如 Unix/Linux 上的 netstat -s）。某些防火墙可能会在连接不活动超时时发送 RST。但是，从您的跟踪看来，大多数 [RST] 都是对 [FIN,ACK] 的响应，因此它更有可能是半双工终止序列。