TCP滑動窗口/擁塞控制/流量控制

TCP和UDP的區別

1. 有連接和無連接

二、UDP一對一, 一對多和一對全 ，TCP一對一

三、UDP面向報文，TCP面向字節流

四、可靠性

五、報文頭信息

小結

滑動窗口

1. 發送方：

一個報文的狀態：

• 已經發送，並且收到確認報文（已結束）（窗口外）

• 已經發送，但還未收到確認報文（等待ACK） （窗口內）

• 可以發送，但尚未發送（已就緒，等待發送）（窗口內）

• 不可以發送（受窗口限制，不允許發送） （窗口外）
  
  如果出現丟包，那麼就會重複對丟包報文前的那個報文進行確認，例如在上圖中，如果發送了31，32，33，34，45，其中32丟包，31，33，34，35按序號到達，那麼當33到的時候，34到的時候，35到的時候，都是發的對31的確認報文，相當於多發了3次對31的確認報文（當對同一個報文重複確認3次的時候，則會觸發快重傳）。

  因此，在上圖中，31～41一定都是未收到確認的，當31確認收到了以後，那麼窗口就會向右滑動，直到最左方的首個元素是“發送了但尚未收到確認報文的” 或者“尚未發送的”。 繼續上面這個例子，當31，33，34，35到達，接收方發送了3個對31號報文的ACK，就會觸發“快重傳”，重新傳送32。

2. 接收方

接收方窗口左邊爲已經發送過的確認報文，右邊爲當前不能接收的報文。

接收方窗口：

• 最左邊報文一定是尚未收到的報文
• 如果31沒到，32，33先到，就先把32，33緩存在接收緩衝區中，並且會發送2個對30的確認報文，當收到了31的確認報文，那麼窗口就繼續滑動到34的位置.

---

擁塞控制

在理想情況下，隨着請求數的增長，網絡的吞吐量也會增長，當用戶的請求出超出了網絡所能承載的負荷時，吞吐量將保持不變。。

而實際情況是，當用戶對網絡資源的請求數量超過了網路所能抗住的負荷時，吞吐量會隨着請求的增多而減少，直到變爲0。
而擁塞控制就是爲了防止這一情況的產生，其實現的方式就是，通過調整發送窗口的大小，來控制發送速率，從而起到減少網絡流量的作用。

發送方需要維護3個變量( 發送窗口(cwnd), 擁塞窗口(swnd), 窗口閾值(ssthresh))：
實際上，發送方發送窗口大小 = min（擁塞窗口大小（擁塞控制）, 接收方接收窗口大小（流量控制））

擁塞控制包括了4個算法策略分別是：慢開始，擁塞避免，快重傳，快恢復。

慢開始：

cwnd = 1, 每發送一輪窗口大小的數據併成功接收到確認報文，就給窗口大小乘2，
當窗口大小超過ssthresh時，使用擁塞避免算法。

擁塞避免：

每發送一輪窗口大小的數據併成功接收到確認報文，就給窗口大小加1，一旦出現超時重傳，則判定網絡可能出現了擁堵，將cwnd置爲1，ssthresh變爲原來的一半

快重傳：

快重傳就是：並不是等超時了纔再重傳，而是連續收到3個重複的ACK報文時，就開始重傳！

快恢復

快恢復就是：出現了需要重傳的情況，並不是把cwnd置爲1，而是置成原來大小的一半,（ssthresh也置爲原來的一半）。

---

流量控制

流量控制就是，讓接收方的發送速率能夠匹配上接收方的接收速率，具體實現體現在：控制發送方的發送窗口大小（如果發送的太快了，就把窗口調小點，如果發的太慢了，就把窗口調大點），發送方窗口的大小根據接收方窗口的大小來決定。

實際上，發送方發送窗口大小 = min（擁塞窗口大小（擁塞控制）, 接收方接收窗口大小（流量控制））

該視頻的例子講的非常棒。

• 發送方在接收到接收方的確認報文段後，會根據報文中的接收方窗口大小值，來重新調整當前的發送窗口大小。（初始大小在TCP三次握手的時候確定）

• 發送方窗口可以被設成零。 當發送方窗口大小爲0時，會定時發送零窗口探測報文，詢問接收方的窗口大小，如果還是0，那麼就重置這個定時器，如果不是0就重新調整窗口大小。

• TCP規定，接收方接收窗口即使爲0，也應接收零窗口探測報文，確認報文段，以及攜帶緊急數據的報文段。