系列TCP/IP協議-數據交互(013)

1、引言

當TCP鏈接創建上了，如今就須要通信了。可是在不一樣的場景下，咱們關心的地方不同。如對於交互型的應用，咱們關心實時性；對於視頻文件傳輸等，咱們更多的關心速度。交互數據流與成塊數據流將能夠解決這些問題。在一些關於TCP通訊量的研究中，交互數據流與成塊數據流的比例是1：9。

2、交互數據流

1.交互式例子

咱們經過Rlogin命令（程序）來了解交互式輸入，如圖是一次按鍵的交互結果：

一次按鍵就會產生4個數據包。

• 1.客戶端到服務器的按鍵數據包。
• 2.服務器到客戶端的按鍵確認數據包。
• 3.服務器到客戶端的按鍵回顯數據包。
• 4.客戶端到服務器的按鍵回顯確認數據包。

在這裏特地用Rlogin做爲例子，由於它每次老是從客戶發送一個字節到服務器。事實上，Telnet容許客戶發送一行到服務器，經過使用這個選項能夠減小網絡的負載。

2.通過時延的確認數據包

在上面的例子中，每發送一次按鍵信息，都會產生4個數據包。事實上2數據包與3數據包能夠合併在一塊兒發送的。這樣會減小很多數據包。一般TCP在接收到數據時並不當即發送ACK；相反，它推遲發送，以便將ACK與須要沿該方向發送的數據一塊兒發送（有時稱這種現象爲數據捎帶ACK）。絕大多數實現採用的時延爲 200ms，也就是說，TCP將以最大200ms的時延等待是否有數據一塊兒發送。

3.Nagle算法

像這種交互數據流，每一次都發送一個字節（一個數據包）到服務器，在網上會產生不少微小的分組，在局域網中，這些分組一般不會引發麻煩，可是在廣域網上，這些分組可能增長擁塞出現的可能。Nagle算法的出現就是爲了解決這些問題。   Nagle算法要求一個TCP鏈接上最多有一個沒有被確認的未完成分租，在該分組的確認到達以前不能發送其餘分組。在等待確認數據包的時候，它會把須要發送的幾個小分組合並在一塊兒，在確認到達後，發送出去。   該算法的優勢是它是自適應的：確認到達越快，數據就發送得越快。在但願減小小分組的低速網絡上，會發送更少的分組。

3、成塊數據流

1.正常塊數據流例子

定義A爲主機svr4.1056,B爲主機bsdi.7777。作以下說明：

• 1-3：A發起主動鏈接，交換mss(最大數據包長度)，以及window窗口大小。
• 4-6：A連續3次發送數據包，通告己方窗口大小。
• 7：B迴應4，5的數據包接收，時延了的ack包，因此兩個合併在一塊兒。
• 8：B迴應6的數據包接收，經過己方剩餘窗口大小。該窗口大小小於初始值，說明還有部分數據沒有被TCP接收。
• 9：A發送一個數據包。
• 10：B對9的響應。
• 11-13：A連續3次發送數據包，通告己方窗口大小。
• 14：B對11，12的響應。
• 15：A發送一個數據包。
• 16：B對13，15的響應。
• 17-20：四次握手關閉鏈接。

2.滑動窗口

一次正常的數據包交互是你發送一個數據包給我，我發送一個確認數據包給你，如此反覆循環。雖然這樣也能夠傳輸數據。可是這樣不是很傻嘛，相似於程序的同步執行或單進程執行。數據的傳輸效率很低的。能不能像程序多開幾個進程加快執行速度同樣一次多發幾個數據包，加快傳輸速度。這就是滑動窗口。

當接收方確認數據後，這個滑動窗口不時地向右移動。窗口兩個邊沿的相對運動增長或減小了窗口的大小。

• 窗口合攏：稱窗口左邊沿向右邊沿靠近爲窗口合攏。這種現象發生在數據被髮送和確認時。
• 窗口張開：當窗口右邊沿向右移動時將容許發送更多的數據，咱們稱之爲窗口張開。這種現象發生在另外一端的接收進程讀取已經確認的數據並釋放了 T C P的接收緩存時。
• 窗口收縮：當右邊沿向左移動時，咱們稱之爲窗口收縮。RFC強烈建議不要使用這種方式。但TCP必須可以在某一端產生這種狀況時進行處理。

整個數據傳輸的如同蝸牛的直線行走（蠕動）。

有個問題：假如後發送的數據包先到達，咋發送確認信號呢？找到答案再來寫

3.PUSH標誌

在以前的TCP概述中，看到頭部中有個標識PUSH，他的做用是，發送方使用該標誌通知接收方將所收到的數據所有提交給接收進程。這裏的數據包括與PUSH一塊兒傳送的數據以及接收方TCP已經爲接收進程收到的其餘數據。

4.慢啓動

發送方一開始便向網絡發送多個報文段，直至達到接收方通告的窗口大小爲止。當發送方和接收方處於同一個局域網時，這種方式是能夠的。可是若是在發送方和接收方之間存在多個路由器和速率較慢的鏈路時，就有可能出現一些問題。一些中間路由器必須緩存分組，並有可能耗盡存儲器的空間。   TCP須要支持一種被稱爲「慢啓動 (slow start)」的算法。該算法經過觀察到新分組進入網絡的速率應該與另外一端返回確認的速率相同而進行工做。 慢啓動爲發送方的TCP增長了另外一個窗口：擁塞窗口 (congestion window)，記爲cwnd。

• 與另外一個網絡的主機創建 T C P鏈接時，擁塞窗口被初始化爲 1個報文段。
• 每收到一個ACK，擁塞窗口就增長一個報文段。
• 發送方取擁塞窗口與接收方滑動窗口中的最小值做爲發送上限。
• 發送方開始時發送一個報文段，而後等待 A C K。當收到該A C K時，擁塞窗口從1增長爲2，便可以發送兩個報文段。當收到這兩個報文段的 A C K時，擁塞窗口就增長爲 4。這是一種指數增長的關係。
• 在某些點上可能達到了互聯網的容量，因而中間路由器開始丟棄分組。這就通知發送方它的擁塞窗口開得過大。

都看到這裏了，要不要掃二維碼關注一下微信公衆號林灣村龍貓。