同學 luffy 給你打**，讓你記下一串手機號碼，可是你記憶力不太好，你跟 luffy 約定，一次只最多只能報 4 個數字，luffy 念一遍，如果你聽到了就把他說的話重複一遍。接下來：最後，你接收到的完整的號碼就是 139-7548-2669.
上面的場景，你一次最多只能接受 4 個數字，表示你的滑動視窗大小就是 4. 在 tcp 協議中，也有這樣的滑動視窗，它的大小表示目前還能接收多少位元組的資料。
tcp 每次收到對方發來的報文，都會檢查視窗大小字段，見圖 1.
圖1 tcp 首部中有乙個字段——16 位視窗大小
知道了對方的視窗大小後，就知道對方目前還能接收多少資料，接收的資料位元組序號是 tcp 段中的 ack 的值到 ack + 視窗大小，即
">[ack,ack+視窗大小)」 role=」presentation」 style=」position: relative;」>[ac
k,ac
k+視窗
大小)[ack,ack+視窗大小)
.比如，你給對方傳送了乙個段攜帶位元組序號為 [400, 500) 的資料。對方回送了乙個 tcp 段，ack = 500, win = 100，就表示，我已經收到 [400, 500) 的資料我還能接收位元組序號為 [500, 600) 之間的資料，見圖 2。
圖2 滑動視窗
如果對方回送了乙個 tcp 段，ack = 500, win = 0，就表示，我已經收到了 [400, 500) 的資料，但是我現在不能再接收資料了，你待會再發。
圖3 對方回送 0 大小的視窗，接收端的反應
回顧本文開頭給出的打**的例子，為什麼你要告訴對方一次最多只能報 4 個數字？原因在於你的接受能力有限，不是說你無法記憶很多數字，只是在短期內，你記不住，你需要一段一段的記憶（一段一段的將資料放入緩衝區）。
所以，在 tcp 中，滑動視窗是為了實現流量控制。如果對方傳送資料過快，接收方就來不及接收（你來不急記住），接收方就需要通告對方，減慢資料的傳送（圖 3）。
需要特別注意的是，在學習滑動視窗的時候，我們假設網路無限好，不擁塞。只要你傳送了資料，對方一定可以收到。再解釋一下網路擁塞的含義，它是指你傳送的資料滯留在網路中，遲遲未到達接收方。
圖4 滑動視窗模擬
修正：圖4 中最後乙個小圖修正一下文字，應該為『傳送方收到 ack=41, win=10, 知道對方希望接收序號為 [41, 51) 的資料』
需要注意的是，接收方接收 tcp 報文的順序是不確定的，並非是一定先收到 35 再收到 36，也可能是先收到 36，37，再收到 35.
**自:
TCP 滑動視窗協議
什麼是滑動視窗協議？一圖勝千言，看下面的圖。簡單解釋下，傳送和接受方都會維護乙個資料幀的序列，這個序列被稱作視窗。傳送方的視窗大小由接受方確定，目的在於控制傳送速度，以免接受方的快取不夠大，而導致溢位，同時控制流量也可以避免網路擁塞。下面圖中的4,5,6號資料幀已經被傳送出去，但是未收到關聯的ack...
TCP 滑動視窗協議
本系列文章是博主學習tcp協議以來的個人筆記。博主不能保證本文所述 內容絕對正確，所 以請讀者抱著懷疑的態度閱讀本部落格內的文字。如果讀 者因本部落格內的文字造成損失，本人 無力負責。如果有任何謬誤或者問題，希望讀者不吝賜教。在遍布世界的網際網路線路上進行可靠的資料傳輸談何容易，一來傳輸介質 有差異...
TCP 滑動視窗協議
什麼是滑動視窗協議？一圖勝千言，看下面的圖。簡單解釋下，傳送和接受方都會維護乙個資料幀的序列，這個序列被稱作視窗。傳送方的視窗大小由接受方確定，目的在於控制傳送速度，以免接受方的快取不夠大，而導致溢位，同時控制流量也可以避免網路擁塞。下面圖中的4,5,6號資料幀已經被傳送出去，但是未收到關聯的ack...