傳輸層

接收視窗(receive window)

想像一個容量有限的信箱。你可以告訴郵差「我還能放十封信」——有禮貌的郵差在你清出一些之前不會硬塞進第十一封。接收視窗就是那則「我還剩多少空間」的訊息。它是 TCP 接收端廣告出去的值,用來告訴寄件者它目前還準備好再接收多少位元組。

機制上,接收端為「應用程式尚未消化的到達資料」維護一個緩衝區。接收視窗等於那個緩衝區此刻的空閒空間:緩衝區總大小,減去已收到且等著被讀取的位元組。接收端把這個數字寫進它回送的區段(常搭在 ACK 上)的 TCP 標頭視窗欄位裡。寄件者把它當成硬上限:它在途的未確認資料量不得超過最新廣告的接收視窗。當應用程式排空緩衝區,視窗就變大;若應用程式停止讀取,視窗就縮小,可能縮到零,等於告訴寄件者暫停。

為什麼重要:接收視窗是 TCP 流量控制的具體控制訊號——它就是慢的接收者用來節流快的寄件者的方式。兩個實務提醒。16 位元的視窗欄位上限是 65,535 位元組,對今天又快又遠的連結來說遠遠太小;連線建立時協商的視窗縮放選項會把它放大,讓視窗能達到數 MB(否則吞吐量會被頻寬延遲乘積卡住)。還有,接收視窗只是寄件者兩個限制中的一個——另一個是壅塞視窗——寄件者永遠遵守兩者中較小的那個。

接收端有一個 128 KB 的緩衝區,裡頭擺著 30 KB 未讀資料,於是它廣告一個 98 KB 的接收視窗。寄件者可讓在途的未確認資料最多達 98 KB。若應用程式接著把那 30 KB 全讀掉,下一次廣告就跳回接近 128 KB。

接收視窗 = 接收者此刻廣告的空閒緩衝空間。

原始 16 位元視窗上限是 64 KB;沒有視窗縮放選項,又快又遠的連結會被頻寬延遲乘積卡住。接收視窗限制寄件者只是為了接收者——壅塞是另一個分開的限制。

又稱
rwndadvertised window接收視窗通告視窗