本節介紹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,則表明該伺...