TCP 傳輸策略

防止黏包現(xiàn)象的出現(xiàn)

當(dāng)窗口數(shù)為 0 時(shí)，發(fā)送者不能正常發(fā)送數(shù)據(jù)段，除非:
-Urgent數(shù)據(jù)。比如，用戶想殺掉遠(yuǎn)端機(jī)器上的進(jìn)程的時(shí)候，可以發(fā)送數(shù)據(jù)
-發(fā)送者可以發(fā)送一個(gè)字節(jié)的數(shù)據(jù)段，以便讓接收者再次發(fā)送期待接收的字節(jié)號(hào)和窗口數(shù)(避免死鎖)

考慮一個(gè)指向某交互式編輯器(遠(yuǎn)程)的TELNET 連接，該編輯器對(duì)用戶的每次擊鍵都作出響應(yīng)，在最壞的情況下：
當(dāng)用戶敲入一個(gè)字符的時(shí)候，被送到傳輸實(shí)體，創(chuàng)建一個(gè)21字節(jié)的數(shù)據(jù)段，在傳到網(wǎng)絡(luò)層，變成了41字節(jié)的IP分組
接收方(運(yùn)行著編輯器的遠(yuǎn)端機(jī))收到這個(gè)信息后，會(huì)立發(fā)送一個(gè)40字節(jié)的確認(rèn)分組 (20字節(jié)的 TCP段頭和20字節(jié)的IP頭)

隨后，當(dāng)編輯器讀取出這個(gè)字節(jié)，TCP實(shí)體發(fā)送一個(gè)窗口更新， 這個(gè)分組也是40字節(jié)
最后，當(dāng)編輯器處理了這個(gè)字符，它發(fā)送一個(gè)41字節(jié)的分組作為該字符的回顯
總共累計(jì)起來，對(duì)于每個(gè)敲入的字符，需要至少 162 字節(jié)的帶寬(還沒有考慮到鏈路層的開銷)，發(fā)送4個(gè)數(shù)據(jù)段。

遠(yuǎn)程交互telnet的最壞情形圖示

怎樣優(yōu)化接收端
接收端可以推遲500ms發(fā)送確認(rèn)分組和窗口更新窗口，以便可以免費(fèi)搭載在處理后的回顯分組內(nèi)(free ride)

怎樣優(yōu)化發(fā)送端
Nagle's algorithm (1984):
- 當(dāng)數(shù)據(jù)以一次一字節(jié)的速度到達(dá)的時(shí)候，只發(fā)送第一個(gè)字節(jié)，然后將后續(xù)的字節(jié)緩存起來，直到發(fā)出的字節(jié)得到確認(rèn)
- 將緩存起來的字節(jié)在一個(gè)數(shù)據(jù)段中發(fā)出，再繼續(xù)緩存，直到發(fā)出的數(shù)據(jù)得到確認(rèn)
- Nagle算法在很多TCP上實(shí)現(xiàn)，但是有些時(shí)候最好禁用，比如： 當(dāng)一個(gè)X-Windows應(yīng)用在互聯(lián)網(wǎng)運(yùn)行的時(shí)候，鼠標(biāo)的移動(dòng)事件必須發(fā)送給遠(yuǎn)程計(jì)算機(jī)，把這些移動(dòng)事件收集起來一批一 批發(fā)送出去，使得鼠標(biāo)的移動(dòng)極不連貫

Nagle’s 算法圖示

傻瓜窗口綜合癥

另一個(gè)使TCP性能退化的問題是傻瓜窗口綜合癥(silly window syndrome problem)：當(dāng)有大塊數(shù)據(jù)被傳遞給發(fā)送端TCP實(shí)體，
但接收端的交互式應(yīng)用每次只讀取一個(gè)字節(jié)的時(shí)候，問題就來了

每次接收1字節(jié)

? Clark解決方案 ：阻止接收方發(fā)送只有1個(gè)字節(jié)的窗口更新，相反，它必須等待一段時(shí)間，當(dāng)有了一定數(shù)量的空間之后再告訴發(fā)送方
? 接收方可以可以維護(hù)一個(gè)內(nèi)部緩沖，且阻塞上層應(yīng)用的 READ 請(qǐng)求，直到它有大塊的數(shù)據(jù)提供

Clark解決方案

發(fā)送方和接收方

TCP傳輸?shù)氖侨p工的字節(jié)流。
TCP適配收發(fā)雙方的數(shù)據(jù)流量
-Window size
TCP還需要效率
-發(fā)方優(yōu)化： Nagle’s algorithm
-收方優(yōu)化： Clark’s solution

總結(jié)

以上是生活随笔為你收集整理的s6-7 TCP 传输策略的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。