19.1 引言

前一章我們介紹了TCP連接的建立與釋放：三握四揮，以及狀態(tài)轉(zhuǎn)移圖。
TCP報(bào)文段分為：交互數(shù)據(jù)，以及成塊數(shù)據(jù)(下一章介紹)。
交互數(shù)據(jù)：例如telnet，ssh，這種類型的協(xié)議在大多數(shù)情況下只是做小流量的數(shù)據(jù)交換，比如說按一下鍵盤，回顯一些文字等等。

一些關(guān)于通信量的研究發(fā)現(xiàn)：
按分組數(shù)量計(jì)算：一半的TCP報(bào)文段包含成塊數(shù)據(jù)(FTP，電子郵件，Usenet新聞)，另外一半則包含交互數(shù)據(jù)(Telnet和Rlogin)。
按字節(jié)計(jì)算：90% ： 10%。這是因?yàn)槌蓧K數(shù)據(jù)基本上都是滿長度的(full-sized)，一般為512字節(jié)的用戶數(shù)據(jù)。而交互數(shù)據(jù)小的多(約90%的交互數(shù)據(jù)小于10字節(jié))。

對(duì)于交互性要求比較高的應(yīng)用，TCP給出兩個(gè)策略來提高發(fā)送效率和減低網(wǎng)絡(luò)負(fù)擔(dān)：
(1)捎帶ACK。
(2)Nagle算法（一次盡量多的發(fā)數(shù)據(jù)）。

19.2 交互式輸入 以 Rlogin 為例

我們來觀察在一個(gè) Rlogin連接 上鍵入一個(gè)交互命令的時(shí)候產(chǎn)生的數(shù)據(jù)流。每一個(gè)交互按鍵都會(huì)產(chǎn)生一個(gè)數(shù)據(jù)分組。
一般有四個(gè)報(bào)文段：

• (1)來自客戶的交互數(shù)據(jù)鍵
• (2)來自服務(wù)器的按鍵確認(rèn)
• (3)來自服務(wù)器的按鍵回顯
• (4)來自客戶的回顯確認(rèn)

一般來說，上述的四個(gè)報(bào)文段中的第二個(gè)和第三個(gè)是一起發(fā)送的，稱為 經(jīng)受時(shí)延的確認(rèn)。

19.3 經(jīng)受時(shí)延的確認(rèn) 或者說 捎帶ack

TCP在收到數(shù)據(jù)的時(shí)候，一般不立刻進(jìn)行ack的發(fā)送，相反，它推遲ack的發(fā)送，以便將 ack 與 沿該方向傳送的數(shù)據(jù) 一起發(fā)送。這種現(xiàn)象也稱為 數(shù)據(jù)捎帶ack。
大多數(shù)實(shí)現(xiàn)采用的時(shí)延 為200ms，也就是說 TCP 將以200ms的時(shí)延等待是否有數(shù)據(jù)一起發(fā)送 ：采用了一個(gè)200ms的定時(shí)器，這個(gè)定時(shí)器以相對(duì)內(nèi)核引導(dǎo)的200ms固定時(shí)間溢出。

19.4 Nagle 算法

Rlogin連接 上客戶一般每次發(fā)送一個(gè)字節(jié)到服務(wù)器，這就產(chǎn)生了一些 41字節(jié)長的分組(20字節(jié)的IP首部，20字節(jié)的TCP首部，1字節(jié)數(shù)據(jù))，在局域網(wǎng)上(LAN)，這些微小分組(tinygram)通常不會(huì)引起麻煩，因?yàn)榫钟蚓W(wǎng)一般不會(huì)出現(xiàn) 網(wǎng)絡(luò)擁塞。但是在廣域網(wǎng)上，這些小分組則會(huì)增加擁塞出現(xiàn)的可能。一種好的方法：采用 Nagle算法。

Nagle算法要求 TCP連接上 最多只能有一個(gè)未被確認(rèn)的未完成的小分組。在該分組確認(rèn)到達(dá)之前不能發(fā)送其他的小分組，如果在分組確認(rèn)到達(dá)之前有分組準(zhǔn)備好了，TCP收集了放入緩存中，然后在確認(rèn)到來的時(shí)候一起發(fā)送出去。
該算法的優(yōu)越地方在于：自適應(yīng)。確認(rèn)到達(dá)的越快，發(fā)送的也越快。而在希望減小微小分組的廣域網(wǎng)上，則會(huì)發(fā)送更少的分組。

在局域網(wǎng)上兩個(gè)主機(jī)之間發(fā)送數(shù)據(jù)的時(shí)候很少使用這個(gè)算法。

簡(jiǎn)單的來說，這個(gè)算法的目的，是減少在廣域網(wǎng)上的小包的數(shù)量，以避免網(wǎng)絡(luò)擁塞。利用的原理是，在發(fā)送出去的包確認(rèn)到達(dá)之前，把準(zhǔn)備好的包存儲(chǔ)起來，等到確認(rèn)到來的時(shí)候，以一個(gè)大包的形式發(fā)送出去。

TCP可以在 應(yīng)用讀取并處理數(shù)據(jù)前 發(fā)送 所接收數(shù)據(jù)的確認(rèn)。這個(gè)TCP確認(rèn)僅僅只是表明 TCP已經(jīng)正確接收了數(shù)據(jù)。

19.4.1 關(guān)閉 Nagle算法

但是 我們有時(shí)候也需要關(guān)閉 Nagle 算法，比如 X窗口服務(wù)系統(tǒng)：小消息(鼠標(biāo)移動(dòng))必須無時(shí)延的發(fā)送，以便 進(jìn)行某種操作的交互用戶 進(jìn)行 及時(shí)反饋。
插口API用戶可以使用 TCP_NODELAY套接字 選項(xiàng)來關(guān)閉 Nagle 算法。

RFC 聲明，TCP必須實(shí)現(xiàn) Nagle算法，但是必須為應(yīng)用提供 關(guān)閉在某個(gè)連接上的 Nagle算法 的方法。

窗口大小通告 8192/4096

服務(wù)器通常的 通告窗口大小 為8192字節(jié)。這是因?yàn)榉?wù)器在 讀取并回顯 接收到的數(shù)據(jù)之前，TCP沒有數(shù)據(jù)發(fā)送。
但是，在ACK到來的時(shí)候，客戶的TCP總是有數(shù)據(jù)需要發(fā)送，這是因?yàn)樵?等待ACK 的過程中，積累了數(shù)據(jù)字符。當(dāng)客戶發(fā)送緩存的數(shù)據(jù)的時(shí)候，客戶并沒有時(shí)間讀取 來自服務(wù)器的數(shù)據(jù)，因此，客戶通告的 窗口大小 總小于 4096.

2016/8/14

轉(zhuǎn)載于:https://www.cnblogs.com/qq952693358/p/5771307.html

總結(jié)

以上是生活随笔為你收集整理的【TCP/IP详解 卷一：协议】第十九章 TCP的交互数据流的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

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