fix 總結 流量 ont 大於 ews net div edit

在局域網中，發送方一開始便向網絡發送多個報文段，直至達到接收方通告的窗體大小為止。

可是。假設收發兩方不在同一個局域網中，那麽發送方一直發送可能會出問題，由於中間路由器有可能發生擁塞。擁塞是指一個或者多個交換點的數據報超載而導致時延劇烈添加的現象。
為了解決問題，TCP支持一種被稱為“慢啟動”的算法，該算法通過觀察到新分組進入網絡的速率應該與還有一端返回確認的速率同樣而進行工作。為了控制擁塞，TCP使用了第二個窗體（第一個是控制流量的滑動窗體）限制，即擁塞窗體限制。

擁塞窗體是發送方使用的流量控制，而滑動窗體則是接收方使用的流量控制

。
剛建立TCP時，擁塞窗體大小為1個報文段。此時。發送方一次僅僅能發送一個報文段。

每收到一個ACK。擁塞窗體就添加一個報文段。所以這是一種指數增長。發送方取擁塞窗體與滑動窗體中的較小值作為發送上限。當發送方窗體開得過大時。中間路由器開始丟棄分組，這就通知發送方要它的窗體變小。
對於擁塞窗體大小的限制採用慢開始和乘法減小兩種技術：

• 慢啟動：擁塞窗體隨著一個確認的到達，擁塞窗體的大小每次添加一個報文段。擁塞窗體大小呈指數增長。
• 乘法減小的擁塞避免策略：一旦發現報文段丟失。就把擁塞窗體的大小減半（直到減至最小的窗體，窗體中應至少包括一個報文段）。

以下通過離散的時間序列，觀察擁塞控制協議：

黑色部分就代表一個個報文段。每一個矩形上半部分表示發送方發往接收方的數據，下半部分表示接收方發往發送方的確認信號。左邊8個時間單元time0—time7就表示一個往返時間RTT。
發送方在time7收到一個ACK，此時擁塞窗體添加到2。time8—time9便發送了兩個報文段。當收到這兩個報文段的ACK後，擁塞窗體添加到4。例如以下所看到的：

最後在time31。管道被填滿。連接達到理想穩定狀態。
擁塞經常出如今下列情況：

• 大管道向小管道發送數據。如以太網向外網數據傳輸。

• 路由器的輸入流大於輸出流。

基本上能夠總結為網絡中某個節點忙只是來。
第一種情況例如以下圖所看到的：

中間帶寬較窄的為廣域網。兩側帶寬較寬的為局域網。瓶頸路由器R1在單位時間內的接收數據量始終大於發送數據量，導致擁塞，當R1接收到數據的累積量超過了它的緩存。終於會導致路由器R1丟棄分組。
參考： 《TCP/IP具體解釋》 P216-P221.

慢啟動與擁塞窗體