本節介紹tcp可能會出現的異常的時候以及部分原因, 提出來的問題大概都會在後面實驗中會有所涉及. tcp異常會出現在連線的任何時候, 比如三次握手, 四次揮手等階段.
三次握手
tcp在三次握手過程中的每一步都可能出錯, 這裡也就介紹以下問題.
服務端沒有監聽, 所以服務端tcp協議返回乙個rst段, 而客戶端收到後立即返回並停止連線. 客服端呼叫connect返回錯誤, 錯誤型別是econnrefused.
客戶端一直沒有收到對端的ack確認報文, 當超時後繼續傳送fin, 多次失敗之後客戶端停止嘗試連線. 客戶端connect函式返回錯誤, 錯誤型別是etimedout.
如果客戶機的syn段導致某個路由器產生「目的地不可到達」型別的icmp訊息, 超時重發後也是一樣, 最後斷開連線. 客服端呼叫connect返回錯誤, 錯誤型別是ehostunreach/enetunreach.
雖然三次握手成功了, 但是客戶端立馬傳送乙個rst段後斷開而服務端處於繁忙狀態, 等服務端返回時才發現對端已經關閉, 此時服務端也關閉. 客戶端connect後立即斷開, 服務端在accept函式返回前收到rst段, 則accept函式返回econnaborted.
通訊過程
在通訊過程中經常一端可能會突然斷網之類的, 導致通訊錯誤.
在通訊過程中, 對端因為斷網等原因斷開並且一直沒有聯網或重啟等, 但是另一端並不知情繼續傳送報文段, 直到超時重傳多次也沒有回應才知道對端已經斷開, 這時另一端傳送rst段表示錯誤並斷開
如果在通訊過程中, 對端因為斷網等原因斷開但是馬上一直聯網或重啟等原因, 那麼另一端傳送報文段過來, 重啟的的服務端沒有監聽, 所以服務端tcp協議返回乙個rst段(回到了三次握手中的第一種錯誤).
四次揮手
四次揮手的任意過程都可能發生錯誤, 這裡也就介紹以下問題.
主動斷開一端傳送fin段, 對端一直沒有ack確認, ….後續??
主動斷開一端傳送fin段並接收到ack, 卻始終沒有收到對端的fin, …後續??
tcp可以通過探測來檢測對端是否已經斷開, 這裡也有乙個詳細的介紹tcp 連線斷連問題剖析. 當然自己使用類似後面會分析到非阻塞connect實現定時 的方法來自己實現乙個保持活性定時器.
參考tcp/ip 錯誤
TCP之種種連線異常
1.connect出錯 1 若tcp客戶端沒有收到syn分節的響應，則返回etimeout錯誤 呼叫connect函式時，核心傳送乙個syn，若無響應則等待6s後再傳送乙個，若仍然無響應則等待24s後在傳送乙個，若總共等待75s後仍未收到響應則返回本錯誤 2 若對客戶的syn響應是rst，則表明該伺...
TCP之種種連線異常
1.connect出錯 1 若tcp客戶端沒有收到syn分節的響應，則返回etimeout錯誤 呼叫connect函式時，核心傳送乙個syn，若無響應則等待6s後再傳送乙個，若仍然無響應則等待24s後在傳送乙個，若總共等待75s後仍未收到響應則返回本錯誤 2 若對客戶的syn響應是rst，則表明該伺...
TCP之種種連線異常
1.connect出錯 1 若tcp客戶端沒有收到syn分節的響應，則返回etimeout錯誤 呼叫connect函式時，核心傳送乙個syn，若無響應則等待6s後再傳送乙個，若仍然無響應則等待24s後在傳送乙個，若總共等待75s後仍未收到響應則返回本錯誤 2 若對客戶的syn響應是rst，則表明該伺...