一、tcp進程處理失敗的連接的方法

1.超時重傳

發送方不知道3 4 5 的接收情況，接收方一直在等 3，這中方式會有比較嚴重的問題。

發送方有兩種選擇：

A，默認 3 發送失敗，重新發送3 

b，默認 3 4 5 發送失敗，重傳 3 4 5 

a的方式，只傳 3可能會慢，b的方式傳 3 4 5 很快但是占用帶寬，timeout也可能很長，這兩個都不是最后的方法。

2.快速重傳

tcp還有一種快速重傳的算法，Fast-Retransmit是以數據驅動重傳，不是timeout時間驅動。

怎么是以數據驅動呢？

就是如果只收到 1 2 ，回復ack 3 ，隨后收到了 4 5 但是還沒收到 3， 4 5的ack也回復 3 3，這樣發送方會收到3個一樣的ack，會知道傳輸出了問題

這就是大部分tcp數據驅動重傳機制（什么？大部分tcp，總共是有幾個版本的..）。

這種方式還不是較好的，只是解決了timeout的問題，回傳的個數還是沒解決，比如一次發了20條，就不知道是哪3個發的ack了，需要回傳這20條。。

3.sack 重傳

選擇性重傳，Selective Acknowledgement（sack），tcp的頭會多一個SACK，快速重傳的ACK還在。

sack只回復已經到達的碎片，這樣發送端就能準確知道是重傳那部分字節流。在Linux可以用tcp_sack這個字段開啟這個功能，2.4版之后的Linux默認開啟。

延伸閱讀：

二、服務器進程終止處理方法

當服務器進程終止時，客戶TCP允許接著把數據發送給服務器。TCP允許這么做，因為客戶TCP接收到FIN只是表示服務器進程已關閉了連接的服務器端，從而不再往其中發送任何數據而已。FIN的接收并沒有告知客戶TCP服務器進程已經終止。

當服務器TCP接收到來自客戶的數據時，既然先前打開的那個套接字的進程已經終止，于是響應以一個RST。

然而客戶看不到這個RST，因為它在調用writen后立刻調用了readline，并且由于第二步中接收的FIIN，所調用的readline立刻返回0(表示EOF)。我們的客戶此時并為預期收到EOF，于是以出錯信息，“server terminated prematurely”（服務器過早終止）退出。

我們的上述討論還取決于本例子的時序。客戶調用readline即可能發生在服務器在的RST被客戶接收到之前，也可能發生在接收到之后，如果readline發生在收到RST之前（那么客戶接收到的是一個為預期的EOF；否則結果是由readline返回一個ECONNRESET 對方復位連接錯誤）。

以上就是關于tcp進程如何處理失敗的連接的內容希望對大家有幫助。

上一篇

er圖橢圓表示什么?

下一篇

怎么寫測試用例?