問題描述：假設現在有乙個tcp長連線a和b，b端突然遭遇停電斷網等突發事件close掉了，此時處於半開連線狀態，假設不考慮心跳包機制、a端的傳送核心緩衝區沒有滿，此時a端寫資料傳送會成功嗎？為什麼？
肯定會成功，send函式跟實際傳送其實沒啥關係，send函式更確切的含義是copy_data_from_userspace_to_kernelspace，只有核心空間有富餘就會成功，不過很顯然b端是接收不到資料的，a傳送後資料後期望收到b的ack包卻一直收不到，根據tcp機制，a端的協議棧會自動進行重傳，當重傳次數達到上限後就發傳送rst包重置連線，半開連線就徹底死掉了。
發散一下，如果說a和b都是好的，a端send成功的資料b端一定能收到嗎？
答案是未必，首先send成功表明資料已經放到了a的傳送核心緩衝區中，如果b端的接收核心緩衝區滿了是沒有辦法收到資料的，在b端用tcpdump也是抓不到包的。
windows 半開連線數
所謂 tcp半開連線 簡單的說就是發起了tcp連線請求，但尚處於建立連線階段，雙方還無法進行互相通訊的狀態。那麼 tcp半開連線數量限制 就是指，限制連線發起者最多同時存在 tcp半開連線 的數量。在windows xp sp2中，微軟首次引入了半開連線數限制，限制數量 10。限制包括了後續的xp ...
windows 半開連線數
所謂 tcp半開連線 簡單的說就是發起了tcp連線請求，但尚處於建立連線階段，雙方還無法進行互相通訊的狀態。那麼 tcp半開連線數量限制 就是指，限制連線發起者最多同時存在 tcp半開連線 的數量。在windows xp sp2中，微軟首次引入了半開連線數限制，限制數量 10。限制包括了後續的xp ...
網路程式設計釋疑之 TCP半開連線的處理
熟悉基於tcp協議進行linux高效能 高併發服務端程式設計的朋友肯定應該知道每個檔案描述符及其所佔的資源對併發量的影響。在這種7 24甚至 365不間斷執行的伺服器上，乙個描述符被浪費，兩個被浪費.如果被浪費的多了，那還何談高併發，高效能。除去檔案描述被正常占用的情況外，是什麼導致了我們可用的檔案...