乙個例子明白傳送緩衝區、接受緩衝區、滑動視窗協議之間的關係。
在上面的幾篇文章中簡單介紹了上述幾個概念在tcp網路程式設計中的關係，也對應了幾個基本socket系統呼叫的幾個行為，這裡再列舉乙個例子，由於對於每乙個tcp的socket來說，都有乙個傳送緩衝區和接受緩衝區與之對應，所以這裡只做單方向jiāo流，不做互動，在recv端不send,在send端不recv。細細揣摩其中的含義。
一、recv端
在監聽套接字上準備accept，在accept結束以後不做什麼操作，直接sleep很久，也就是在recv端並不做接受資料的操作，在sleep結束之後再recv資料。
二、send端
通過檢視本系統核心預設的支援的最大傳送緩衝區大小，cat/proc/sys/net/ipv4/tcp_wmem，最後乙個引數為傳送緩衝區的最大大小。接受緩衝區最大的配置檔案在tcp_rmen中。
將套接字設定為阻塞，一次傳送的buffer大於最大傳送緩衝區所能容納的資料量，一次send結束，在傳送返回後接著答應傳送的資料長度
測試結果：
階段一：
接受端表現：在剛開始傳送資料時，接收端chǔ於慢啟動狀態，滑動視窗大小越來愈大，但是由於接收端不chǔ理接受緩衝區內的資料，其滑動視窗越來越小（因為接受端回應傳送端中的win大小表示接受端還能夠接受多少資料，傳送端下次傳送的資料大小不能超過回應中win的大小），最後傳送端回應給接受端的ack中顯示的win大小為0，表示接收端不能夠再接受資料。
傳送端表現：傳送端一直不能返回，如果接受端一直回應win為0的情況下，傳送端的send就會一直不能返回，這種僵局一直持續到接收端的sleep結束。
原因分析：首先需要明白幾個事實，阻塞式i/o會一直等待，直達這個操作完成；傳送端接受到接收端的回應後才能將傳送緩衝區中的資料進行清空。
在接收端不recv，那麼接收端的接受緩衝區內會一直有資料，接受緩衝區滿，導致滑動視窗為0，導致傳送端不能傳送資料。但是send操作為何不能反悔呢？send操作只是將應用緩衝區的資料拷貝到傳送緩衝區，但是傳送緩衝區的資料並沒有完全得到接收端的ack回應，所以暫時不能將傳送緩衝區中的資料丟棄，導致傳送緩衝區的被填滿，這樣應用層中的資料也就不能拷貝到核心傳送緩衝區內，也就會一直阻塞在這裡，直到可以繼續講應用層的資料拷貝到傳送緩衝區中，何時觸發這個操作呢？等到傳送端回應win大於0時才有這樣的操作。
階段二;
接受端：在sleep結束以後，開始呼叫recv系統呼叫。這個時候接受端的滑動視窗又開始大於零。那麼這樣就喚醒了傳送端繼續傳送資料。
傳送端：傳送端接受到接收端win大於0的回應，這個時候傳送端又可以將應用層buffer中的資料拷貝到核心的傳送緩衝區中。
原因分析：由於接受端呼叫recv將核心接受緩衝區的資料拷貝到應用層中，這樣滑動視窗又大於0了所以激發了傳送端繼續傳送資料，由於傳送端可以傳送資料了，核心協議棧便將傳送緩衝區中的資料傳送給接受端，這樣傳送緩衝區又有空間了，那麼send操作就可以將應用層的資料拷貝到傳送緩衝區了！這樣的操作一直保持到send操作返回，這樣代表著將應用層的資料全部拷貝到傳送緩衝區內，但不代表將資料傳送給對端。傳送給對端成功的標誌是接受到對端的ack回應，這個時候傳送端才可以將傳送緩衝區的資料丟棄。不丟棄的原因是時刻準備重發丟失/出錯的資料！
ps: tcp通訊為了保證可靠xìng，每次傳送的資料都需要得到對方的ack才確認對方收到了(僅保證對方tcp接收緩衝收到 資料了，但不保證對方應用程式取到資料了)，這時如果每次傳送一次就要停下來等著對方的ack訊息，顯然是一種極大的資源浪費和低下的效率，這時就有了滑動視窗的出現。
傳送方的滑動視窗維持著當前傳送的幀序號，已發出去幀的計時器，接收方當前的視窗大小(由接收方ack通知，大體等於接收緩衝大小-未chǔ理的訊息包)，接收方滑動視窗儲存的有已接收的幀資訊、期待的下一幀的幀號等，至於滑動視窗的具體工作原理這裡就不說了。
一 個socket有兩個滑動視窗(乙個sendbuf、乙個recvbuf)，兩個視窗的大小是通過setsockopt函式設定的，現在問題就出在這裡， 通過抓包顯示，設定的視窗大小沒有生效，最後排查發現setsockopt函式是後來加上的，寫到了listen函式的後面，這樣每次accept出的 socket並沒有繼承得到主socket設定的視窗大小，無語啊……
解決辦法：setsockopt函式提前到listen函式之前，這樣在伺服器程式啟動監聽前recvbuf就已經有了，accept後的鏈結得到的就是recvbuf了，啟動程式執行，抓包顯示視窗已經是指定的大小了。
一、tcp的滑動視窗大小實際上就是socket的接收緩衝區大小的位元組數
二、 對於server端的socket一定要在listen之前設定緩衝區大小，因為，accept時新產生的socket會繼承監聽socket的緩衝區大 小。對於client端的socket一定要在connet之前設定緩衝區大小，因為connet時需要進行三次握手過程，會通知對方自己的視窗大小。在 connet之後再設定緩衝區，已經沒有什麼意義。
三、由於緩衝區大小在tcp頭部只有16位來表示，所以它的最大值是65536，但是對於一些情況來說需要使用更大的滑動視窗，這時候就要使用擴充套件的滑動視窗，如光纖高速通訊網路，或者是衛星長連線網路，需要視窗盡可能的大。這時會使用擴充套件的32位的滑動視窗大小。
TCP IP滑動視窗
t c p使用一種視窗 w i n d o w 機制來控制資料流。當乙個連線建立時，連線的每一端分配乙個緩衝區來儲存輸入的資料，並將緩衝區的尺寸傳送給另一端。當資料到達時，接收方傳送確認，其中包含了自己剩餘的緩衝區尺寸。剩餘的緩衝區空間的大小被稱為視窗 w i n d o w 指出視窗大小的通知稱為...
TCP IP 滑動視窗
這樣的傳輸方式有乙個缺點 資料報的往返時間越長，通訊的效率就越低。為解決這個問題，tcp 引入了視窗這個概念。即使在往返時間較長的情況下，它也不會降低網路通訊的效率。那麼有了視窗，就可以指定視窗大小，視窗大小就是指無需等待確認應答，而可以繼續傳送資料的最大值。視窗的實現實際上是作業系統開闢的乙個快取...
滑動視窗協議
只有在接收視窗向前滑動時 與此同時也傳送了確認 傳送視窗才有可能向前滑動。收發兩端的視窗按照以上規律不斷地向前滑動，因此這種協議又稱為滑動視窗協議。當傳送視窗和接收視窗的大小都等於 1時，就是停止等待協議。當傳送視窗大於1，接收視窗等於1時，就是回退n步協議。當傳送視窗和接收視窗的大小均大於1時，就...