對於每乙個tcp的socket來說，都有乙個傳送緩衝區和接受緩衝區與之對應，下面舉個例子說說傳送緩衝區、接受緩衝區、滑動視窗協議之間的關係。
一、recv端
在監聽套接字上準備accept，在accept結束以後不做什麼操作，直接sleep很久，也就是在recv端並不做接收資料的操作，在sleep結束之後再recv資料。
二、send端
通過檢視本系統核心支援的傳送緩衝區大小，cat/proc/sys/net/ipv4/tcp_wmem，三個引數分別最小值、預設值和最大值。接收緩衝區的配置檔案在tcp_rmen中。
將套接字設定為阻塞，一次傳送的buffer大於傳送緩衝區所能容納的資料量，一次send結束，在傳送返回後接著列印傳送的資料長度。
測試結果：
階段一：
recv端表現：在剛開始傳送資料時，接收端處於慢啟動狀態，滑動視窗值越來越大，但是由於接收端不處理接收緩衝區內的資料，其滑動視窗越來越小（因為接收端回應傳送端中的win大小表示接受端還能夠接受多少資料，傳送端下次傳送的資料大小不能超過回應中win的大小），最後傳送端回應給接受端的ack中顯示的win大小為0，表示接收端不能夠再接受資料。
send端表現：傳送端一直不能返回，如果接收端一直回應win為0的情況下，傳送端的send就會一直不能返回，這種僵局一直持續到接收端的sleep結束。
原因分析：首先需要明白幾個事實，阻塞式i/o會一直等待，直達這個操作完成；傳送端接受到接收端的回應後才能將傳送緩衝區中的資料進行清空。
在接收端不recv，那麼接收端的接收緩衝區內會一直有資料，接收緩衝區滿，導致滑動視窗為0，傳送端不能傳送資料。但是send操作為何不能返回呢？send操作只是將應用緩衝區的資料拷貝到傳送緩衝區，但是傳送緩衝區的資料並沒有完全得到接收端的ack回應，所以暫時不能將傳送緩衝區中的資料丟棄，導致傳送緩衝區的被填滿，這樣應用層中的資料也就不能拷貝到核心傳送緩衝區內，也就會一直阻塞在這裡，直到可以繼續將應用層的資料拷貝到傳送緩衝區中，何時觸發這個操作呢？等到傳送端回應win大於0時才有這樣的操作。
階段二：
recv端：在sleep結束以後，開始呼叫recv系統呼叫。這個時候接收端的滑動視窗又開始大於零，這樣就喚醒了傳送端繼續傳送資料。
send端：傳送端接收到接收端win大於0的回應，這個時候傳送端又可以將應用層buffer中的資料拷貝到核心的傳送緩衝區中。
由於接收端呼叫recv將核心接收緩衝區的資料拷貝到應用層中，這樣滑動視窗又大於0了，所以激發了傳送端繼續傳送資料。由於傳送端可以傳送資料了，核心協議棧便將傳送緩衝區中的資料傳送給接收端，這樣傳送緩衝區又有空間了，那麼send操作就可以將應用層的資料拷貝到傳送緩衝區了！這樣的操作一直保持到send操作返回，這樣代表著將應用層的資料全部拷貝到傳送緩衝區內，但不代表將資料傳送給對端。傳送給對端成功的標誌是接收到對端的ack回應，這個時候傳送端才可以將傳送緩衝區的資料丟棄。不丟棄的原因是時刻準備重發丟失/出錯的資料！
ps: tcp通訊為了保證可靠性，每次傳送的資料都需要得到對方的ack才確認對方收到了(僅保證對方tcp接收緩衝區收到資料了，但不保證對方應用程式取到資料了)，這時如果每次傳送一次就要停下來等著對方的ack訊息，顯然是一種極大的資源浪費和低下的效率，這時就有了滑動視窗的出現。
傳送方的滑動視窗維持著當前傳送的幀序號，已發出去幀的計時器，接收方當前的視窗大小(由接收方ack通知，大體等於接收緩衝大小-未處理的資料報)，接收方滑動視窗儲存的有已接收的幀資訊、期待的下一幀的幀號等，至於滑動視窗的具體工作原理這裡就不說了。
一 個socket有兩個滑動視窗(乙個sendbuf、乙個recvbuf)，兩個視窗的大小是通過setsockopt函式設定的，現在問題就出在這裡， 通過抓包顯示，設定的視窗大小沒有生效，最後排查發現setsockopt函式是後來加上的，寫到了listen函式的後面，這樣每次accept出的 socket並沒有繼承得到主socket設定的視窗大小，無語啊……
解決辦法：setsockopt函式提前到listen函式之前，這樣在伺服器程式啟動監聽前recvbuf就已經有了，accept後的鏈結得到的就是recvbuf了，啟動程式執行，抓包顯示視窗已經是指定的大小了。
結論：
1.tcp的滑動視窗大小實際上就是socket的接收緩衝區（so_rcvbuf）大小的位元組數
2.對於server端的socket一定要在listen之前設定緩衝區大小，因為，accept時新產生的socket會繼承監聽socket的緩衝區大 小。對於client端的socket一定要在connet之前設定緩衝區大小，因為connet時需要進行三次握手過程，會通知對方自己的視窗大小。在 connet之後再設定緩衝區，已經沒有什麼意義。
3.由於緩衝區大小在tcp頭部只有16位來表示，所以它的最大值是65536，但是對於一些情況來說需要使用更大的滑動視窗，這時候就要使用擴充套件的滑動視窗，如光纖高速通訊網路，或者是衛星長連線網路，需要視窗盡可能的大。這時會使用擴充套件的32位的滑動視窗大小。
這就是傳送緩衝區、接受緩衝區、滑動視窗協議之間的關係，不知道大家明白了沒有。由於優客的知識有限，可能描述不夠恰當，希望大家多多指教。
【個人補充】socket的傳送緩衝區與滑動視窗關係
socket/send成功與否與滑動視窗沒有任何關係，但是，存在邏輯上的先後作用關係，即
socket/send向緩衝區傳送資料報時，要看傳送緩衝區大小（so_sndbuf）--> tcp/send傳送緩衝區中的資料報時，看滑動視窗win的值。
socket 接收和傳送緩衝區
問題產生 在進行客戶端向服務端傳送資料時，每次傳送一定數量資料後傳送端就等不到send函式的返回，導致程式一直卡死在send函式。通過抓包發現 傳送端傳送過快而接收端處理速度過慢，導致快速傳送一定量資料後wireshark顯示傳送端傳送資料有window full提醒，幾次之後接收端會傳送zero ...
socket的傳送與接收緩衝區
應用程式可通過呼叫send write,sendmsg等 利用tcp socket向網路傳送應用資料，而tcp ip協議棧再通過網路裝置介面把已經組織成struct sk buff的應用資料 tcp資料報 真正傳送到網路上，由於應用程式呼叫send的速度跟網路介質傳送資料的速度存在差異，所以，一部分...
socket的傳送與接收緩衝區
應用程式可通過呼叫send write,sendmsg等 利用tcp socket向網路傳送應用資料，而tcp ip協議棧再通過網路裝置介面把已經組織成struct sk buff的應用資料 tcp資料報 真正傳送到網路上，由於應用程式呼叫send的速度跟網路介質傳送資料的速度存在差異，所以，一部分...