計算機網絡-tcp連接常見異常

目標端口未在監聽：(操作系統參與）
解決：TCP的服務端實際上就是從網卡的寄存器中讀取數據，然后進行解析。對于TCP自然會解析出目的端口這個關鍵信息，然后根據這個信息查看有沒有這樣的套接字。這個套接字是什么呢？在用戶層面是一個文件句柄，但在內核中實際是一個數據結構，里面記錄了很多信息。這個數據結構存儲在一個哈希表中，通過函數__inet_lookup_skb（net/inet_hashtables.h）可以實現對該數據結構的查找。對于上述情況，自然無法找到該套接字，因此TCP服務端會進行錯誤處理，處理的方式就是給客戶端發送一個RST（通過函數tcp_v4_send_reset進行發送），告訴客戶端發生錯誤。可以通過抓包來分析理解。
常見返回：[Errno 111] Connection refused（連接拒絕）

目標主機不存在：(自己的超時計時器）
這也是一種比較常見的情況，當某臺服務器主機宕機了，而客戶端并不知道，仍然嘗試去與其建立連接。這個時候由于宕機，操作系統幫不上忙，服務器處于一種完全沒有響應的狀態。那么此時客戶端的TCP會怎么辦呢？最多重傳默認為6次，每一次時間間隔都不一樣，而后仍未收到響應就會返回ETIMEDOUT錯誤。這是TCP建立連接自己的一個保護機制，但是我們要等待75s才能知道這個連接無法建立，對于我們所有服務來說都太長了。更好的做法是在代碼中給connect設置一個超時時間。

Server進程被阻塞：
由于某些情況，服務器端進程無法響應任何請求，比如所在主機的硬盤滿了，導致進程處于完全阻塞，通常我們測試時會用gdb模擬這種情況。上面提到過，建立連接的過程對應用程序是不可見的，那么，這時連接可以正常建立。當然，客戶端進程也可以通過這個連接給服務器端發送請求，服務器端TCP會應答ACK表示已經收到這個分節（這里的收到指的是數據已經在內核的緩沖區里準備好，由于進程被阻塞，無法將數據從內核的緩沖區復制到應用程序的緩沖區），但永遠不會返回結果。

Server進程暫時關閉：
這是線上最常見的操作，當一個模塊上線時，OP同學總是會先把舊的進程殺死，然后再啟動新的進程。那么在這個過程中TCP連接發生了什么呢。在進程正常退出時會自動調用close函數來關閉它所打開的文件描述符，這相當于服務器端來主動關閉連接——會發送一個FIN分節給客戶端TCP；客戶端要做的就是配合對端關閉連接，TCP會自動響應一個ACK，然后再由客戶端應用程序調用close函數，也就是我們上面所描述的關閉連接的4次揮手過程。接下來，客戶端還需要定時去重連，以便當服務器端進程重新啟動好時客戶端能夠繼續與之通信。

通信的過程中服務器端宕機：
客戶端向服務器端發送分節，由于服務器端宕機，不會有任何響應，客戶端持續重傳，然而服務器始終不能應答，重傳數次之后，大約4~10分鐘才停止，之后返回一個ETIMEDOUT錯誤。

總結

以上是生活随笔為你收集整理的计算机网络-tcp连接常见异常的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。