一、tcp進(jìn)程處理失敗的連接的方法

1.超時(shí)重傳

發(fā)送方不知道3 4 5 的接收情況，接收方一直在等 3，這中方式會(huì)有比較嚴(yán)重的問題。

發(fā)送方有兩種選擇：

A，默認(rèn) 3 發(fā)送失敗，重新發(fā)送3 

b，默認(rèn) 3 4 5 發(fā)送失敗，重傳 3 4 5 

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

2.快速重傳

tcp還有一種快速重傳的算法，F(xiàn)ast-Retransmit是以數(shù)據(jù)驅(qū)動(dòng)重傳，不是timeout時(shí)間驅(qū)動(dòng)。

怎么是以數(shù)據(jù)驅(qū)動(dòng)呢？

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

這就是大部分tcp數(shù)據(jù)驅(qū)動(dòng)重傳機(jī)制（什么？大部分tcp，總共是有幾個(gè)版本的..）。

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

3.sack 重傳

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

sack只回復(fù)已經(jīng)到達(dá)的碎片，這樣發(fā)送端就能準(zhǔn)確知道是重傳那部分字節(jié)流。在Linux可以用tcp_sack這個(gè)字段開啟這個(gè)功能，2.4版之后的Linux默認(rèn)開啟。

延伸閱讀：

二、服務(wù)器進(jìn)程終止處理方法

當(dāng)服務(wù)器進(jìn)程終止時(shí)，客戶TCP允許接著把數(shù)據(jù)發(fā)送給服務(wù)器。TCP允許這么做，因?yàn)榭蛻鬞CP接收到FIN只是表示服務(wù)器進(jìn)程已關(guān)閉了連接的服務(wù)器端，從而不再往其中發(fā)送任何數(shù)據(jù)而已。FIN的接收并沒有告知客戶TCP服務(wù)器進(jìn)程已經(jīng)終止。

當(dāng)服務(wù)器TCP接收到來自客戶的數(shù)據(jù)時(shí)，既然先前打開的那個(gè)套接字的進(jìn)程已經(jīng)終止，于是響應(yīng)以一個(gè)RST。

然而客戶看不到這個(gè)RST，因?yàn)樗谡{(diào)用writen后立刻調(diào)用了readline，并且由于第二步中接收的FIIN，所調(diào)用的readline立刻返回0(表示EOF)。我們的客戶此時(shí)并為預(yù)期收到EOF，于是以出錯(cuò)信息，“server terminated prematurely”（服務(wù)器過早終止）退出。

我們的上述討論還取決于本例子的時(shí)序。客戶調(diào)用readline即可能發(fā)生在服務(wù)器在的RST被客戶接收到之前，也可能發(fā)生在接收到之后，如果readline發(fā)生在收到RST之前（那么客戶接收到的是一個(gè)為預(yù)期的EOF；否則結(jié)果是由readline返回一個(gè)ECONNRESET 對(duì)方復(fù)位連接錯(cuò)誤）。

以上就是關(guān)于tcp進(jìn)程如何處理失敗的連接的內(nèi)容希望對(duì)大家有幫助。

上一篇

怎么寫測(cè)試用例?

下一篇

boxcode是什么軟件?