1樓：沙耶里
正常來說，Fin也是被TCP的重傳機制保護的。在持續收不到ACK的狀況下，由於TCP timeout機制的存在連線仍舊會正常關閉。
過程大概是：在使用者程式關閉連線的時候，Fin被從使用者緩衝區拷貝進核心緩衝區由核心接管，同時核心會把當前連線標記為半關閉不再接受使用者資料，核心會傳送當前緩衝區所有的TCP包並且進行必要的重傳，如果過程中重傳超過最大重傳上限，系統會認為連線已經關閉。
From RFC 793:
Case 1: Local user initiates the close
In this case, a FIN segment can be constructed and placed on the
outgoing segment queue. No further SENDs from the user will be
accepted by the TCP, and it enters the FIN-WAIT-1 state. RECEIVEs
are allowed in this state. All segments preceding and including FIN
will be retransmitted until acknowledged. When the other TCP has
both acknowledged the FIN and sent a FIN of its own, the first TCP
can ACK this FIN. Note that a TCP receiving a FIN will ACK but not
send its own FIN until its user has CLOSED the connection also.
TCP四次分手是在幹什麼？
抱抱 流程好像是 a發FinAck Fin b回Ack b發Fin a發Ack 書上說一是允許一方關閉另一方繼續通訊，像單工的那種二是b發Ack和Fin中間的時間可以給b留處理的時間 包括人的一些操作 好像也有直接讓b發FinAck的叭 不知道對不對 求教 丁祈夜 也許你是沒搞懂為啥握手才要三次，為...
為什麼TCP4次揮手時等待為2MSL？
Old Debugger 研究了各位的回答，寫寫自己的思考。第一步先回答題主為什麼是2MSL而不是3MSL的疑問。等待時間至少是 B的timeout FIN的傳輸時間 順著題主的思路，有個計算問題是 把B的timeout全部算到了A頭上，B從發出FIN開始倒計時，而A是收到FIN發出ACK後才開始倒...
TCP四次分手中第三次的SEQ序號由什麼決定？
吳大飛娃兒 首先直接回答題主的問題，在題主提供的示意圖中，第三次的SEQ的確是由第二次的SEQ決定的，第二次的SEQ是由第一次的ACK決定的。事實上，更加通用的四次揮手示意圖是這樣的 當主機1 主動方 發出FIN報文段時，只是表示主機1已經沒有資料要傳送了，主機1告訴主機2 被動方 它的資料已經全部...