了解 TCP 接收視窗
我目前正在學習 TCP，尤其是接收視窗方面。我已經從幾個來源閱讀過它，並且有一些我想確保我理解的東西。
據我所知，接收者會發布一個“接收視窗”，這是 - 這就是我感到困惑的地方 - 允許發送者在沒有被確認的情況下發送的字節數，或者換句話說，數據在飛行中。
現在，如果我想一想，我們在流控制中的主要目標是確保發送方不會發送超過接收方可以處理的數據，即我們要防止發送方發送接收方的數據的情況將不得不丟棄，因為它沒有地方存放它！
按照這個邏輯，我開始相信接收視窗應該對應於接收緩衝區的大小（不知道是否完全相同，但視窗大小應該是接收緩衝區的導數），並且我們限制發送方發送的飛行數據的原因是 - 如果發送方發送的視窗大小超過視窗大小（這也是接收緩衝區的派生值），並且接收方尚未確認某些數據（更新視窗大小），可能會出現接收端無法跟上的情況 - 即，它獲取數據的速度比使用它的應用程序處理它的速度要快，導致段被丟棄（希望很清楚）。
但是，閱讀這篇文章，@DavidShwartz 說，傳輸數據的目的不是避免過度填充緩衝區，而是處理通信通道引入的延遲。我不太明白。
問題是，每個談論這個主題的消息來源都沒有解釋流量控制的總體目標與傳輸數據的事物之間的聯繫。
有人可以更詳細地解釋一下嗎？
它兩者兼而有之。
接收視窗受可用緩衝區空間的限制，但這對於大多數接收器來說並不是什麼大問題。
接收視窗的另一個重要功能是及時分散傳輸，因此它不是一個連續十個數據包的大突發，然後是沉默，直到所有這些數據都被確認，然後是另一個突發。
相反，一種稱為“TCP 慢啟動”的機制會隨著數據的傳輸逐漸增加接收視窗，因此長時間執行的傳輸以大致相等的數據包流結束，並且數據包的確認恰好在視窗末尾的下一個數據包必鬚髮出的時間。
一旦建立了該流，視窗會進一步增加，以允許替換失去的數據包而不會停止。
如果視窗大小線性增長直到達到飛行中未確認的數據量，即傳輸延遲乘以傳輸速度，則可以實現良好的流程。
僅通過確認無法解決此問題的原因是，突發數據包很可能在途中被丟棄（丟棄數據包是網路指示擁塞的方式），因此在最終收斂之前連接開始會更加卡頓在一個穩定的流動。
如果接收緩衝區小於傳輸中的未確認數據量，則接收視窗將達到上限，並且流量將不均勻，除非接收堆棧通過延遲確認來補償這一點——但這是一種不典型的情況。