1樓：守護
服務端完成資料的處理和發生通常是分開的，不是同時完成的，所以一般情況下服務端的ack和fin是分開發的，而不是像三次握手那樣在第二次握手同時傳送sys+ack；
一般傳送FIN端是告訴對端，我這邊不會再發資料了，對端收到FIN後會回乙個ACK表示我知道了；當兩端都說不會發資料並相互確認後，最後再等2MSL時間，鏈結才會關閉。
2樓：
是可以合併的。
Wireshark 跟蹤下就發現只有 3 步，中間被合併了（第乙個 FIN + ACK 的 ACK 是響應前乙個包，第二個 FIN + ACK 才是合併）：
看下狀態圖，注意看從 FIN WAIT 1 是可以直接到 TIME WAIT 的。這個流程需要被動關閉一方合併 ACK 和 FIN（即上圖的第二個包），直接進入到 LAST ACK，而主動關閉一方就可以直接從 FIN WAIT 1 響應 ACK 並進入 TIME WAIT。
比較常見的是 HTTP 服務，服務端傳送完資料然後主動關閉，客戶端收到 FIN 的時候必然讀完了響應，也立即關閉，就可能出現上面截圖的情況。也許有延遲 ack 的關係，ack 延遲了然後和 fin 合併，達到了同時關閉的效果。
3樓：
合併也沒問題, 只要對方協議棧能識別兩個 flag, 但這樣的話, 發出 FIN+ACK 的主機的 TCP狀態切換邏輯就要改了, CLOSE-WAIT 要和LAST-ACK合併, 這樣的後果顯然就是反應不夠快, 不能馬上回覆第乙個 FIN
查了一下 RFC, 沒看到說合併
TCP 為什麼是三次握手，而不是兩次或四次？
xuanweiace 一些簡單好記的結論 首先明確一點，傳送方傳送的資料報包含資料，才需要進行ack確認 且必須進行ack確認 而如果傳送方傳送的只是ack確認而無資料，則無需再次確認 不然就會無限迴圈 所有的重傳，都由傳送方負責，接收方不負責。何時觸發重傳？傳送方在超時器計時結束後仍然沒有收到ac...
在TCP的四次分手當中，被動關閉方是如何知道資料已經接收完了
車小胖 既然被動關閉方B passive shutdown 已經接收到主動關閉方A active shutdown FIN，大體有以下三種不同的場景 1 TCP資料 FIN順序到達 這是正常情況，B接收到含有FIN標誌位的報文，該報文有sequence number，假定其為10000，B就會知道A...
四級兩次沒過，還該不該考研？
知乎首答一波為了我兩次沒過的四級。從2017年6月開始大一下第一次考，去年夏天的時候真的是純裸考。連四級有哪些考試內容都不知道，考過之後我室友和我說14.2一題聽力，我還驚訝一題分這麼高。四級功底本來就不好的我果然沒有考過,379.我沒有什麼特別意外和傷心的地方，畢竟是裸考。我們學校的四級考試的考場...