1、 fin拆鏈為啥4次握手，而syn建鏈只需要3次
2、 四次握手中，tcp協議棧和應用程式都做了什麼？
3、 半關閉、同時關閉。
fin拆鏈需要4次握手，如下圖：
討論fin為啥4次握手，這個要把tcp協議棧和應用程式結合起來看，下圖是fin拆鏈過程應用程式的動作。
fin報文是由自己的應用層進行「寫操作close」動作觸發的，而不是tcp協議棧自發的傳送fin報文。
比如上圖，當伺服器b收到對方的fin報文，僅僅意味著伺服器a的應用不再傳送資料(應用程式的寫操作close)，但是並不意味著伺服器b的應用也不傳送資料了。
tcp收到fin後，給應用程式傳送eof(end of file)，並響應ack。伺服器b的應用程式也寫close，tcp再傳送fin。
fin報文的響應(ack)不受應用層影響，所以這個ack一般不會延遲。而傳送fin報文則需要應用程式寫close觸發。所以這兩個報文一般不合併。
假如，如上圖，把第二個syn ack報文拆開(紅色的，現實和協議中規定這兩個紅色合為乙個syn ack報文傳送)，拆成乙個ack(響應伺服器a的syn)和乙個syn(伺服器b的syn)
伺服器b應用程式啟動後，它的tcp協議棧就處於listen狀態(等待對方建鏈)，由於tcp鏈結又是全雙工的，當伺服器b收到syn報文後，syn和ack都不需要應用層參與，所以可以將將ack和syn合併乙個報文。
tcp鏈結的一端(的應用程式)不再傳送資料(通知自己的tcp傳送了fin)，而另一端繼續傳送資料，這種狀態為半關閉。
以下是半關閉場景的tcp協議棧和應用程式的動作示意。
主動關閉(最先發起fin的一端為主動關閉，一般客戶端)
被動關閉(後發起fin的一端為被動關閉，一般伺服器)
同時關閉(同時發起fin，比較少見，但是tcp協議支援)
1、 主動關閉傳送fin並收到ack後，但是一直沒有收到對方的fin，(比如對方應用掛了，或者這時候網路突然斷了)，怎麼辦？
2、 主動關閉，收到了對方的ack，也收到了對方的fin，並且也對對方的fin傳送了ack，但是這個最後的ack在網路傳輸中丟了，怎麼辦？
TCP伺服器模型
迴圈伺服器 迴圈伺服器在同乙個時刻只可以響應乙個客戶端的請求 併發伺服器 併發伺服器在同乙個時刻可以響應多個客戶端的請求 9.1 迴圈伺服器 udp伺服器 udp迴圈伺服器的實現非常簡單 udp伺服器每次從套接字上讀取乙個客戶端的請求,處理,然後將結果返回給客戶機.可以用下面的演算法來實現.sock...
tcp 伺服器優化
vi etc sysctl.conf 編輯檔案，加入以下內容 net.ipv4.tcp syncookies 1 net.ipv4.tcp tw reuse 1 net.ipv4.tcp tw recycle 1 net.ipv4.tcp fin timeout 30 然後執行 sbin sysct...
伺服器TCP配置
net.ipv4.tcp syncookies 1 表示開啟syn cookies。當出現syn等待佇列溢位時，啟用cookies來處理，可防範少量syn攻擊，預設為0，表示關閉 net.ipv4.tcp tw reuse 1 表示開啟重用。允許將time wait sockets重新用於新的tcp...