1.TCP的交互數據流
對於交互性要求比較高的應用,TCP給出兩個策略來提高發送效率和減低網絡負擔:(1)捎帶ACK。(2)Nagle算法(壹次盡量多的發數據)。通常,在網絡速度很快的情況下,比如用lo接口進行telnet通信,當按下字母鍵並要求回顯的時候,客戶端和服務器將經歷 發送按鍵數據->服務器發送按鍵數據的ack -> 服務器端發送回顯數據->客戶端發送回顯數據的ACK的過程,而其中的數據流量將是40bit + 41bit+41bit+40bit = 162bit,如果在廣域網裏面,這種小分組的TCP流量將會造成很大的網絡負擔。
1.1.捎帶ACK的發送方式
這個策略是說,當主機收到遠程主機的TCP數據報之後,通常不馬上發送ACK數據報,而是等上壹個短暫的時間,如果這段時間裏面主機還有發送到遠程主機的TCP數據報,那麽就把這個ACK數據報“捎帶”著發送出去,把本來兩個TCP數據報整合成壹個發送。壹般的,這個時間是200ms。可以明顯地看到這個策略可以把TCP數據報的利用率提高很多。
1.2.Nagle算法
上過bbs的人應該都會有感受,就是在網絡慢的時候發貼,有時鍵入壹串字符串以後,經過壹段時間,客戶端“發瘋”壹樣突然回顯出很多內容,就好像數據壹下子傳過來了壹樣,這就是Nagle算法的作用。
Nagle算法是說,當主機A給主機B發送了壹個TCP數據報並進入等待主機B的ACK數據報的狀態時,TCP的輸出緩沖區裏面只能有壹個TCP數據報,並且,這個數據報不斷地收集後來的數據,整合成壹個大的數據報,等到B主機的ACK包壹到,就把這些數據“壹股腦”的發送出去。雖然這樣的描述有些不準確,但還算形象和易於理解,我們同樣可以體會到這個策略對於低減網絡負擔的好處。
在編寫插口程序的時候,可以通過TCP_NODELAY來關閉這個算法。並且,使用這個算法看情況的,比如基於TCP的X窗口協議,如果處理鼠標事件時還是用這個算法,那麽“延遲”可就非常大了。
2.TCP的成塊數據流
對於FTP這樣對於數據吞吐量有較高要求的要求,將總是希望每次盡量多的發送數據到對方主機,就算是有點“延遲”也無所謂。TCP也提供了壹整套的策略來支持這樣的需求。TCP協議中有16個bit表示“窗口”的大小,這是這些策略的核心。
2.1.傳輸數據時ACK的問題
在解釋滑動窗口前,需要看看ACK的應答策略,壹般來說,發送端發送壹個TCP數據報,那麽接收端就應該發送壹個ACK數據報。但是事實上卻不是這樣,發送端將會連續發送數據盡量填滿接受方的緩沖區,而接受方對這些數據只要發送壹個ACK報文來回應就可以了,這就是ACK的累積特性,這個特性大大減少了發送端和接收端的負擔。
2.2.滑動窗口
滑動窗口本質上是描述接受方的TCP數據報緩沖區大小的數據,發送方根據這個數據來計算自己最多能發送多長的數據。如果發送方收到接受方的窗口大小為0的TCP數據報,那麽發送方將停止發送數據,等到接受方發送窗口大小不為0的數據報的到來。書中的P211和P212很好的解釋了這壹點。
關於滑動窗口協議,書上還介紹了三個術語,分別是:
窗口合攏:當窗口從左邊向右邊靠近的時候,這種現象發生在數據被發送和確認的時候。
窗口張開:當窗口的右邊沿向右邊移動的時候,這種現象發生在接受端處理了數據以後。
窗口收縮:當窗口的右邊沿向左邊移動的時候,這種現象不常發生。
TCP就是用這個窗口,慢慢的從數據的左邊移動到右邊,把處於窗口範圍內的數據發送出去(但不用發送所有,只是處於窗口內的數據可以發送。)。這就是窗口的意義。圖20-6解釋了這壹點。窗口的大小是可以通過socket來制定的,4096並不是最理想的窗口大小,而16384則可以使吞吐量大大的增加。
2.3.數據擁塞
上面的策略用於局域網內傳輸還可以,但是用在廣域網中就可能會出現問題,最大的問題就是當傳輸時出現了瓶頸(比如說壹定要經過壹個slip低速鏈路)所產生的大量數據堵塞問題(擁塞),為了解決這個問題,TCP發送方需要確認連接雙方的線路的數據最大吞吐量是多少。這,就是所謂的擁塞窗口。
擁塞窗口的原理很簡單,TCP發送方首先發送壹個數據報,然後等待對方的回應,得到回應後就把這個窗口的大小加倍,然後連續發送兩個數據報,等到對方回應以後,再把這個窗口加倍(先是2的指數倍,到壹定程度後就變成現行增長,這就是所謂的慢啟動),發送更多的數據報,直到出現超時錯誤,這樣,發送端就了解到了通信雙方的線路承載能力,也就確定了擁塞窗口的大小,發送方就用這個擁塞窗口的大小發送數據。要觀察這個現象是非常容易的,我們壹般在下載數據的時候,速度都是慢慢“沖起來的”
以上就是TCP數據傳輸的大致流程,雖然並不細致,但是足以描述TCP的工作原理,重點是TCP的流量控制原理,滑動窗口,擁塞窗口,ACK累計確認等知識點。