Prayer

當一個進程向接收了RST的套接口進行寫操作時， 內核給該進程發一個SIGPIPE信號。
這個信號默認操作就是終止進程， 一般寫程序的時候都是屏蔽掉這個信號。


下面是我以前總結的一些：
原文：http://blog.chinaunix.net/u/6593/showart_304065.html

RST的含義為“復位”，它是TCP在某些錯誤情況下所發出的一種TCP分節。有三個條件可以產生RST:

1), SYN到達某端口但此端口上沒有正在監聽的服務器。

2), TCP想取消一個已有連接

3), TCP接收了一個根本不存在的連接上的分節。



1．  Connect 函數返回錯誤ECONNREFUSED:

如果對客戶的SYN的響應是RST，則表明該服務器主機在我們指定的端口上沒有進程在等待與之連接（例如服務器進程也許沒有啟動），這稱為硬錯（hard error），客戶一接收到RST，馬上就返回錯誤ECONNREFUSED.



TCP為監聽套接口維護兩個隊列。兩個隊列之和不超過listen函數第二個參數backlog。

當一個客戶SYN到達時，若兩個隊列都是滿的，TCP就忽略此分節，且不發送RST.這個因為：這種情況是暫時的，客戶TCP將重發SYN，期望不久就能在隊列中找到空閑條目。要是TCP服務器發送了一個RST，客戶connect函數將立即發送一個錯誤，強制應用進程處理這種情況，而不是讓TCP正常的重傳機制來處理。還有，客戶區別不了這兩種情況：作為SYN的響應，意為“此端口上沒有服務器”的RST和意為“有服務器在此端口上但其隊列滿”的RST.



Posix.1g允許以下兩種處理方法：忽略新的SYN，或為此SYN響應一個RST.歷史上，所有源自Berkeley的實現都是忽略新的SYN。





2．如果殺掉服務器端處理客戶端的子進程，進程退出后，關閉它打開的所有文件描述符，此時，當服務器TCP接收到來自此客戶端的數據時，由于先前打開的那個套接字接口的進程已終止，所以以RST響應。

      經常遇到的問題：

              如果不判斷read , write函數的返回值，就不知道服務器是否響應了RST, 此時客戶端如果向接收了RST的套接口進行寫操作時，內核給該進程發一個SIGPIPE信號。此信號的缺省行為就是終止進程，所以，進程必須捕獲它以免不情愿地被終止。

              進程不論是捕獲了該信號并從其信號處理程序返回，還是不理會該信號，寫操作都返回EPIPE錯誤。



3．  服務器主機崩潰后重啟

如果服務器主機與客戶端建立連接后崩潰，如果此時，客戶端向服務器發送數據，而服務器已經崩潰不能響應客戶端ACK，客戶TCP將持續重傳數據分節，試圖從服務器上接收一個ACK，如果服務器一直崩潰客戶端會發現服務器已經崩潰或目的地不可達，但可能需要比較長的時間； 如果服務器在客戶端發現崩潰前重啟，服務器的TCP丟失了崩潰前的所有連接信息，所以服務器TCP對接收的客戶數據分節以RST響應。