Linux 是什么原因以及如何避免 [FIN, ACK] , [RST] 和 [RST, ACK]
声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow
原文地址: http://stackoverflow.com/questions/15182106/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
What is the reason and how to avoid the [FIN, ACK] , [RST] and [RST, ACK]
提问by Sergio Pettena
What is the reason and how to avoid the [FIN, ACK]
, [RST]
and [RST, ACK]
?
是什么原因以及如何避免[FIN, ACK]
,[RST]
和[RST, ACK]
?
Is it due to some mismatch between the TCP parameters of the SO′s? What does it mean when the server replies [FIN, ACK]
in a TCP/IP connection?
是否由于 SO 的 TCP 参数之间的某些不匹配?服务器[FIN, ACK]
在 TCP/IP 连接中回复是什么意思?
10.118.113.237
is a Solaris box, while 10.118.110.63
is a Linux box.
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
回答by isedev
Here is a rough explanation of the concepts.
这里是对概念的粗略解释。
[ACK]
is the acknowledgement that the previously sent data packet was received.
[ACK]
是对先前发送的数据包已收到的确认。
[FIN]
is sent by a host when it wants to terminate the connection; the TCP protocol requires both endpoints to send the termination request (i.e. FIN
).
[FIN]
由主机在要终止连接时发送;TCP 协议要求两个端点都发送终止请求(即FIN
)。
So, suppose
所以,假设
- host Asends a data packet to host B
- and then host Bwants to close the connection.
- Host B(depending on timing) can respond with
[FIN,ACK]
indicating that it received the sent packet and wants to close the session. - Host Ashould then respond with a
[FIN,ACK]
indicating that it received the termination request (theACK
part) and that it too will close the connection (theFIN
part).
- 主机 A向主机 B发送数据包
- 然后主机 B想要关闭连接。
- 主机 B(取决于时间)可以响应
[FIN,ACK]
指示它收到发送的数据包并希望关闭会话。 - 然后,主机 A应该响应一个
[FIN,ACK]
指示它收到终止请求(ACK
部分)并且它也将关闭连接(FIN
部分)。
However, if host Awants to close the session after sending the packet, it would only send a [FIN]
packet (nothing to acknowledge) but host Bwould respond with [FIN,ACK]
(acknowledges the request and responds with FIN
).
但是,如果主机 A在发送数据包后想要关闭会话,它只会发送一个[FIN]
数据包(无需确认),但主机 B会响应[FIN,ACK]
(确认请求并以 响应FIN
)。
Finally, some TCP stacks perform half-duplex termination, meaning that they can send [RST]
instead of the usual [FIN,ACK]
. This happens when the host actively closes the session without processing all the data that was sent to it. Linux is one operating system which does just this.
最后,一些 TCP 堆栈执行半双工终止,这意味着它们可以发送[RST]
而不是通常的[FIN,ACK]
. 当主机主动关闭会话而不处理发送给它的所有数据时,就会发生这种情况。Linux 是一种可以做到这一点的操作系统。
You can find a more detailed and comprehensive explanation here.
您可以在此处找到更详细和全面的说明。