TCP之種種連線異常

1. connect出錯：

(1) 若tcp客戶端沒有收到syn分節的響應，則返回etimeout錯誤；呼叫connect函式時，核心傳送乙個syn，若無響應則等待6s後再傳送乙個，若仍然無響應則等待24s後在傳送乙個，若總共等待75s後仍未收到響應則返回本錯誤；

(2) 若對客戶的syn響應是rst，則表明該伺服器在我們指定的埠上沒有程序在等待與之連線，這是一種硬錯誤，客戶一收到rst馬上返回econnrefused錯誤；

(3) 若客戶傳送的syn在中間的某個路由器上引發了目的不可達icmp錯誤，則認為是一種軟錯誤。客戶主機核心儲存該訊息，並按照第一種情況的時間間隔繼續傳送syn，咋某個規定時間後仍未收到響應，則把儲存的訊息作為ehostunreach或者enetunreach錯誤返回給程序；

2. accept返回前連線中止：

在比較忙的伺服器中，在建立三次握手之後，呼叫accept之前，可能出現客戶端斷開連線的情況；如，三次握手之後，客戶端傳送rst，然後伺服器呼叫accept。posix指出這種情況errno設定為connaborted;

注意berkeley實現中，沒有返回這個錯誤，而是eproto，同時完成三次握手的連線會從已完成佇列中移除；在這種情況下，如果我們用select監聽到有新的連線完成，但之後又被從完成佇列中刪除，此時如果呼叫阻塞accept就會產生阻塞；

解決辦法：

(1) 使用select監聽套接字是否有完成連線的時候，總是把這個監聽套接字設定為非阻塞；

(2) 在後續的accept呼叫中忽略以下錯誤，ewouldblock(berkeley實現，客戶中止連線), econnaborted(posix實現，客戶中止連線), eproto(serv4實現，客戶中止連線)和eintr(如果有訊號**獲)；

3. 伺服器程序終止(崩潰)：

在客戶端和伺服器端建立連線之後，使用kill命令殺死伺服器程序，程序終止會關閉所有開啟的描述符，這導致了其向客戶端傳送了乙個fin，而客戶端則響應了乙個ack，這就完成了tcp連線終止的前半部分，只代表伺服器不在傳送資料了；但是客戶端並不知道伺服器端已經終止了，當客戶端向伺服器寫資料的時候，由於伺服器程序終止，所以響應了rst，如果我們使用select等方式，能夠立即知道當前連線狀態；如下：

(1) 如果對端tcp傳送資料，那麼套接字可讀，並且read返回乙個大於0的值(讀入位元組數)；

(2) 如果對端tcp傳送了fin(對端程序終止)，那麼該套接字變為可讀，並且read返回0(eof)；

(3) 如果對端tcp傳送rst(對端主機崩潰並重啟)，那麼該套接字變為可讀，並且read返回-1，errno中含有確切錯誤碼；

4. sigpipe訊號：

當乙個程序向某個收到rst的套接字執行寫操作的時候，核心向該程序傳送乙個sigpipe訊號，該訊號的預設行為是終止程序，因此程序必須捕獲它以免不情願的被終止；

不論程序是捕捉了該訊號並從訊號處理函式中返回，還是簡單忽略該訊號，寫操作都講返回epipe錯誤；

5. 伺服器主機崩潰：

建立連線之後，伺服器主機崩潰，此時如果客戶端傳送資料，會發現客戶端會在一定時間內持續重傳，檢視從伺服器端收到資料的ack，當重傳時間超過指定時間後，伺服器仍然沒有響應，那麼返回的是etimedout；

6. 伺服器主機不可達：

建立連線之後，伺服器主機未崩潰，但是由於中間路由器故障燈，判定主機或網路不可達，此時如果客戶端傳送資料，會發現客戶端會在一定時間內持續重傳，檢視從伺服器端收到資料的ack，當重傳時間超過指定時間後，伺服器仍然沒有響應，那麼返回的是ehostunreach或enetunreach；

7. 伺服器主機崩潰後重啟：

當伺服器主機崩潰重啟後，之前所有的tcp連線丟失，此時伺服器若收到來自客戶端的資料，會響應乙個rst；客戶端呼叫read將返回乙個econnreset錯誤；

8. 伺服器主機關機：

系統關機時，init程序給所有程序傳送sigterm訊號，等待固定的時間，然後給所有仍在執行的程序傳送sigkill訊號，我們的程序會被sigterm或者sigkill訊號終止，所以與前面伺服器程序終止相同，程序關閉所有描述符，並傳送fin，完成伺服器端的半關閉；

TCP之種種連線異常

TCP之種種連線異常

TCP之種種連線異常

Tcp 連線,Socket異常

相關推薦