1. 當對方意外崩潰後（如斷電或網路中斷），並且沒有發出fin包時，處於傳送端無法得知這種情況，處於傳送緩衝區的資料會不斷向對方傳送，但由於對方離開會不斷因為超時重傳，重傳12次左右 大概9分鐘 依然沒有響應就會返回乙個超時通知 如果傳送端此時有乙個read操作會讀取到這個訊號，但如果在之後你繼續通過這個套接字進行寫資料的話，會觸發sigpipe 訊號 如果不對訊號進行處理 程式將直接退出。
2. 收到對方傳送的fin包會有三種情況 正常關閉、shutdown、意外崩潰作業系統系統核心清理資源時傳送。
當出現第三種情況時，傳送端可以read這個fin 並解析為eof 感知對方已經離開 如果傳送端還一直傳送資料給服務端 會收到服務端傳送的rst分節。（假設後面有read操作的話 會返回econnreset錯誤）
3. 若是對方斷電關閉了，沒有發出這個fin包的話同時 另外一端卻一直在等待接收的話，那就只能傻等了。之後估計只能依靠kepp-alive來關閉連線。
沒發fin包後續操作分為三種情況：
由於對方不在了， 處於傳送緩衝區的資料一直無法得到應答，將會不停重發在發了12次左右 9分鐘後的樣子 傳送端的read會收到乙個超時通知，如果此時繼續往那個套接字進行傳送操作的話，會收到sigpipe訊號 進行呼叫對應處理例程。
如果一直都是write操作的話 沒有理會超時通知，最終也會收到sigpipe訊號 關閉程序
若是對方斷電關閉了，沒有發出這個fin包的話同時 另外一端卻一直在等待接收的話，那就只能傻等了。之後估計只能依靠kepp-alive來關閉連線。或者通過給read和write函式設定超時時間
同上一樣 只能通過keep-alive知道對方是否離開或者通過給read和write函式設定超時時間
發了fin包後續操作也分為三種情況
客戶端--------伺服器
1. 客戶端傳送fin包，處於傳送緩衝區的資料會逐一傳送（可能通過一次或多次write操作傳送），fin包處於這段資料的末尾，當資料到達接收端的接收緩衝區時，fin起到了乙個結束符的作用，當接收端接收資料時遇到fin包，read操作返回eof通知應用層。然後接收端返回乙個ack表示對這次傳送的確認。（此時客戶端進入fin_wait1，服務端進入close_wait狀態）
2. 客戶端接收到ack之後，關閉自己的傳送通道，客戶端此時處於半關閉狀態。等待伺服器傳送fin包。
(客戶端進入fin_wait2狀態)
3. 服務端傳送fin包，同上類似處於傳送緩衝區的內容會連同fin包一起發過去，當客戶端接收成功後同時將fin解析為eof訊號使得上層呼叫返回。（客戶端進入time_wait狀態 服務端進入last_ack狀態）
4. 客戶端等待2msl的時間，在此期間向伺服器傳送ack。如果丟包進行重傳。如果伺服器收到ack後 伺服器進入closed狀態 客戶端也進入closed狀態。
5. 連線關閉
當出現第三種情況時，另一端可以read這個fin 並解析為eof 感知對方已經離開 如果還一直傳送資料給崩潰一方的話 會收到崩潰一方作業系統核心協議棧傳送的rst分節從而關閉整個連線。
分為三種情況
1. 一直read 通過收到的fin可以感知連線斷開
2. 先write後read 由於已經發收到fin包 如果繼續向這條連線傳送資料的話 對方作業系統核心收到發現是給一條已關閉的連線傳送資料 會返回乙個rst分節 如果你馬上read的話 會因為之前已經收到的fin包立即返回 並感知對方斷開但是這個rst分節你也是收到了的
3. 一直write 由於之前的write觸發使得對端返回rst分節 如果你繼續向乙個已經收到rst分節的套接字傳送資料的話 核心將會向該程序傳送sigpipe訊號 預設訊號處理函式則是關閉此程序
TCP並不總是「可靠」的？
tcp 是可靠的？傳送端通過呼叫send函式之後，資料流並沒有傳輸出去，資料會先儲存到套接字的傳送緩衝區中，通過網路協議棧決定何時傳送 如何傳送。當對應的資料傳送給接收端，接收端回應ack，這時儲存到傳送緩衝區的資料可以刪除了，但傳送端無法獲取對應資料流的ack情況 無法判斷對端是否接收到資料流 如...
新的並不總是最好的
不知道大家是否接受這種觀點 新的並不總是最好的 new doesn t always mean better.我們在平時習慣於接受新的產品，立刻放棄舊的，我們習慣於對新產品的追逐，新產品給我們帶了對未來希望的憧憬，它給我們煩悶的生活注入新鮮，讓我們為之一振，讓我們感受到我們還活在不斷前進的社會中，與...
TCP的可靠傳輸
可靠傳輸 能夠有序的都到達接受方 tcp使用滑動視窗 學習三個機制 超時重傳 快速重傳 選擇確認 累計確認 先了解背景 超時重傳很簡單 超時重傳的時間設定是個難點 簡單來說時依據多個往返時間確認平均往返時間，超時重傳設定比平均往返時間要長一點，記住超時時間時動態設定不斷變化的 以後有必要的時候來了解...