window size流控過程：

TCP是以資料段的形式傳輸資料的，一個數據段包含很多個位元組，相當於批次傳輸

為避免大量資料淹沒接收方，採用流控技術，利用的是段頭中的一個欄位叫視窗尺寸(window size)

一個簡單例子

從上往下過程：

sender傳送了一個2K的資料，因為SEQ=0，所以這個2K的位元組編號是從0一直到2047

這個資料到達receiver之後receiver的記憶體就被佔據了一半，還剩下2K，所以這個接收方會回發一個確認：ACK=2048，WIN=2048，分別表示（累計）確認和剩下空間的大小

sender再次傳送了一個2K的資料，接收方的快取全部被充滿，會發確認：ACK=4096，WIN=0

過一段時間接收方對快取裡面的資料進行了處理，從而空出了2K的空間，於是它馬上傳送了一個更新視窗，當然，這個更新視窗資料段裡面WIN=2048，而中間因為沒有再接受資料所以ACK=4096不變……

別忘了TCP傳輸是雙工的，也就是說sender/receiver可以交換，它們可以互為收發方

一些傳送策略：

當視窗數為0時傳送者不能正常傳送資料段，除非傳送緊急(Urgent)資料（例如使用者想殺掉遠端機器上的程序的時候）

傳送者可以傳送一個位元組的資料段，以便讓接收者再次傳送期待接收的位元組號和視窗數（避免死鎖）

傳送者不需要馬上傳送應用程式產生的資料，接收者也不需要馬上傳送應答（當收到資料的時候）

接收方/傳送方的最佳化

遠端互動telnet的最壞情形圖示：

最佳化方法：接收端可以推遲500ms傳送確認分組和視窗更新視窗，以便可以免費搭載在處理後的回顯分組內(free ride)

傳送端最佳化Nagle演算法

當資料以一次一位元組的速度到達的時候，只發送第一個位元組，然後將後續的位元組快取起來，直到發出的位元組得到確認

將快取起來的位元組在一個數據段中發出，再繼續快取，直到發出的資料得到確認

Nagle演算法在很多TCP上實現，但是有些時候最好禁用，例如當一個X-Windows應用在網際網路執行的時候，滑鼠的移動事件必須傳送給遠端計算機，把這些移動事件收集起來一批一批發送出去，使得滑鼠的移動極不連貫

傻瓜視窗綜合症

有大塊資料被傳遞給傳送端TCP實體，然而接收端的互動式應用每次只讀取一個位元組的時候，如下

Clark解決方案 ：阻止接收方傳送只有1個位元組的視窗更新，它必須等待一段時間，當有了一定數量的空間之後再告訴傳送方

總結