《趣談網路協議》筆記——UDP，TCP

TCP和UDP的區別

1. TCP是面向連接的，UDP是面向無連接的，

什么叫面向連接？
在互通之前，面向連接的協議會先建立連接， 建立連接就是客戶端和服務器之間維護互動狀態的資料結構，

2. TCP提供可靠交付；而UDP繼承了IP包的特性，不保證可靠

通過TCP連接的資料，無差錯，不丟失，不重復，并且按序到達，
UDP不保證不丟失，不保證按序到達，

3. TCP是面向位元組流的，UDP是基于資料報的

TCP是有緩沖區，UDP面向報文段是沒有緩沖區的，
TCP發送報文時，是將應用層資料寫入TCP緩沖區中，然后由TCP協議來控制發送這里面的資料，而發送的狀態是按位元組流的方式發送的，跟應用層寫下來的報文長度沒有任何關系，所以說是流，
UDP，它沒有緩沖區，應用層寫的報文資料會直接加包頭交給網路層，由網路層負責分片，所以是面向報文段的，

UDP包頭

埠號：根據埠號，將資料交給相應的應用程式，

UDP的三大特點：

1. 溝通簡單，沒有大量的資料結構，包頭欄位，處理邏輯等，
2. 輕信他人，不會建立連接，可以接收任何資料，也可以發送任何資料，
3. 愣頭青，不懂權變，沒有擁塞控制，不管網路好不好只管發，

UDP的三大使用場景

1. 需要的資源少，在網路情況比較好的內網，或者對于丟包不敏感的應用，

比如DHCP就是基于UDP協議的，一般獲取ip地址都是內網請求，并且一次獲取不到也沒關系，

2. 不需要一對一的建立連接，而是應用在廣播的應用中，

UDP的不面向連接的功能，可以使得可以承載廣播或者多播的協議，DHCP就是廣播的形式，

3. 需要處理的速度快，時延低，可以容忍少量的丟包，但要求即便網路擁塞也繼續傳輸的情況，

UDP簡單、處理速度快，不像TCP那樣，操這么多的心，各種重傳，保證順序，前面的不收到，后面的沒法處理，這樣會導致時延很大，
并且在網路不好丟包的時候，擁塞控制會進一步降低發送速率，這樣導致在本來卡的時候更卡了，

一些應用可以有自己的連接策略來保證可靠性（應用層保證），而通過UDP來保證時延要求，
比如：

1. 網頁或者APP的訪問.

目前的HTTP協議，往往采取多個資料通道共享一個連接的情況，這樣本來為了加快傳輸速度，但是TCP的嚴格順序策略使得哪怕共享通道，前一個不來，后一個和前一個即便沒關系，也要等著，時延也會加大，

QUIC（全稱Quick UDP Internet Connections，快速UDP互聯網連接），是一種基于UDP改進的通信協議，其目的是降低網路通信的延遲，提供更好的用戶互動體驗，
QUIC在應用層上，會自己實作快速連接建立、減少重傳時延，自適應擁塞控制，

2. 流媒體協議，

很多直播軟體都基于UDP實作了自己的視頻傳輸協議，

3. 實時游戲

游戲對實時要求較為嚴格的情況下，采用自定義的可靠UDP協議，自定義重傳策略，能夠把丟包產生的延遲降到最低，盡量減少網路問題對游戲性造成的影響，

4. IoT物聯網

一方面，物聯網領域終端資源少，很可能只是個記憶體非常小的嵌入式系統，而維護TCP協議代價太大；另一方面，物聯網對實時性要求也很高，而TCP還是因為上面的那些原因導致時延大，

TCP包頭格式

埠號：和UDP一樣，對應資料發給哪個應用，
序號：解決亂序問題，
確認序號：解決不丟包的問題，如果沒收到，需要重發直到送達，
一些狀態位：SYN是發起一個連接，ACK是回復，RST是重新連接，FIN是結束連接，
視窗大小：TCP要做流量控制，通信雙方標明自己能夠處理的能力，不要發太快也不要發太慢，除了流量控制外，還做擁塞控制，不能強人所難，控制自己的發送速度，改變不了世界，就改變自己，

因此掌握TCP協議需要掌握這幾點（分別對應以上欄位）：
1. 順序問題，穩重不亂
2. 丟包問題，承諾靠譜
3. 連接維護，有始有終
4. 流量控制，把握分寸
5. 擁塞控制，知進知退

TCP三次握手
首先建立一個連接，也即連接維護問題

因為TCP協議是全雙工的，對于單鏈接時要保證可靠需要一問一答：

也即客戶端發送SYN（sqe = x）想要建立連接，需要等待服務器的ACK（ack = x+1）回復，才能算是單方向的鏈接成功，

同樣，服務器端到客戶端建立可靠的通信鏈接也需要一問一答：

服務器發送SYN（sqe = y）狀態位想要建立連接，需要等待客戶端的ACK（ack = y+1）回復，這條單向通信鏈路連接成功，

而其中的服務器端回復確認ACK的時候可以一起將建立連接的SYN一起發送給客戶端，最終就成了三次握手，

這里有個疑問是，如果客戶端最后一次握手的ACK丟了咋辦？或者服務器發送完SYN和ACK后掛了咋辦？
因為在客戶端與服務器建立三次握手后，客戶端就會立即發送資料了，一旦客戶端開始發送資料了，很多問題就迎刃而解了，此時服務器收到客戶端的資料，即便沒有收到前面客戶端的ACK，服務器可以認為這個連接已經建立；
如果服務器掛掉了，客戶端發送資料，會報錯說服務器不可達，客戶端就知道了服務器出問題了，（報錯說服務器不可達，這是在IP層中的ICMP協議可以反饋的），

然后又有疑問：說建立完成三次握手就緊接著發送資料，要是客戶端建立連接后就是不發送資料呢？
在設計程式的時候可以要求開啟keepalive機制，即使沒有發送資料包，也會發送探活包，當然，對于服務器端可以設計長時間客戶端不發送資料，可以主動關閉，

TCP三次握手除了雙方建立連接外，還有溝通雙方TCP包的序號問題，

TCP四次揮手

四次揮手可以類比于上面說的三次握手，當客戶端A想要結束連接（FIN，sqe = p）的時候，必須服務器B回復（ACK， ack = p+1）后才能單端關閉，
但是此時第二步和第三步不能合并，因為此時服務器B還依然在傳送資料，還不想立即關閉連接的，
當服務器B也想要結束連接（FIN， sqe = q，ACK，ack = p+1）時候，等待客戶端A回復（ACK， ack = q+1），但是客戶端A回復ACK后還要等待2MSL，

為什么要等待2MSL？

1. 如果客戶端A發送完ACK后直接跑路了，可能服務器B并沒有收到這個ACK，當服務器B長時間未收到ACK回復后，會重新發送，對應客戶端也要重新發送回復，
2. MSL是Maximum Segment Lifetime，報文最大生存時間，它是任何報文在網路上存在的最長時間，

如何實作一個靠譜的協議？

為了保證順序性，TCP協議在每個包都有一個ID號，這個ID號是在三次握手建立連接的時候商定好的，為了保證不丟包，需要每個包都進行應答，但也不是接收端收到哪個就立即應答哪個，而是應答之前的某個ID，表示前面都收到了，這稱為累計確認或累計應答，

為了記錄這些包ID，發送端和接收端分別都要有快取來記錄，

下圖是發送端快取狀態的資料結構，分為四個部分：1. 發送的并且已經收到ACK確認的，2. 發送出去了但是還未收到ACK確認的部分， 3. 還沒有發送，即將發送的部分， 4. 還沒有發送但是超過自己能力范圍的部分，

第三部分和第四部分不合在一起的原因是：前面說到的流量控制，要把握分寸，接收端做不過來就不能發送了，

視窗大小為：黑色加粗部分的，也即第三部分加上第四部分，

以下為接收端快取的資料結構：分為三個部分，1. 接收到了并且已經回復ACK了，但是還沒有提交給應用層的部分，2. 等待接識訓沒回復ACK的部分，3. 不能接收的部分，超過最大處理能力的部分，

視窗大小為：NextByteExpected至MaxRcvBuffer指向的區間，
也就是：AdvertisedWindow=MaxRcvBuffer - ((NextByteExpected-1)-LastByteRead)

通過上面介紹的基本的發送端和接收端的資料結構，接下來說明一下順序問題個丟包問題的具體實作，

從發送端看：1，2，3是已發送并確認的，4，5，6，7，8，9都是發送了還沒確認，
從接收端看：1，2，3，4，5是已經完成ACK但是應用層還沒讀取的，6，7是等待接收，8，9是已經接收但是沒有ACK的部分，

（從這里看出來6，7沒有ACK之前，8，9是不發送ACK的，對應前面的累計確認，因為一旦發送了ACK，視窗會向后滑動的，因此需要保證前面的都要ACK才可以）

例如：發送端和接收端當前的狀態如下：

• 1，2，3沒有問題，雙方達成了一致，
• 4，5接收方說ACK了，但發送方還未收到，有可能丟了，有可能在路上，
• 6，7，8，9發送方肯定都發了，但接收方是8，9已經到了，但是6，7沒到，出現了亂序，快取著但是沒辦法ACK，

如果發送端4的ACK接收到了，但是5的ACK丟了怎么辦？
如果接收端6，7的資料包丟了怎么辦？
答：超時重發，超過一定時間就重新嘗試發送，這個時間的設定是根據往返時間RTT得到的，并且是根據網路情況不斷變化的，由于重傳時間是不斷變化的，因此稱為自適應自動重傳演算法，

因此一段時間后發送端未收到5，6，7的ACK就會重發5，6，7的資料包，接收端發現5已經之前有了就會丟棄5，并將6，7的ACK回傳，

快速重傳的機制，當接收方收到一個序號大于下一個所期望的報文段時，就檢測到了資料流中的一個間格，于是發送三個冗余的ACK，客戶端收到后，就在定時器過期之前，重傳丟失的報文段，

例如，接收方發現6、8.9都已經接收了，就是7沒來，那肯定是丟了，于是發送三個6的ACK，要求下一個是7，客戶端收到3個，就會發現7的確又丟了，不等超時，馬上重發，

流量控制問題
我們再來看流量控制機制，在對于包的確認中，同時會攜帶一個視窗的大小，
在視窗不變的情況下，大小固定為9，發送端收到4的確認后，視窗會右移一下，此時13包可發送，

此時，若發送端發送太猛，一下把10，11，12，13發送出去，之后就停止發送了，未發送部分變為0.

如果接收方實在處理的太慢，導致快取中沒有空間了，可以通過確認資訊ACK修改視窗的大小，甚至可以設定為0，則發送方將暫時停止發送，

我們假設一個極端情況，接收端的應用一直不讀取快取中的資料，當資料包6確認后，視窗大小就不能再是9了，就要縮小一個變為8，

我們通過上面接收端快取的資料結構發現，最大接收快取量MaxRcvBuffer是固定的，如果應用層一直不讀取資料，通過視窗的計算運算式，視窗會越來越小，

對應發送端的視窗大小通過接收到6的ACK攜帶的視窗大小資訊，發送端的視窗不會整體右移，而是視窗的最左端右移一下，視窗大小從9變成8，

如果接收端應用層還是一直不處理資料，隨著發送端收到確認包越來越多，視窗將越來越小，直至到0，

這就是常說的流量控制，

擁塞控制問題
擁塞控制的問題，也是通過視窗的大小來控制的，前面的滑動視窗rwnd是怕發送方把接收方快取塞滿，而擁塞視窗cwnd，是怕把網路塞滿，

LastByteSent - LastByteAcked <= min(cwnd，rwnd)，擁塞視窗和滑動視窗共同控制發送的速度，

假設從發送端到接收端要經過4個網路設備（路由器網元什么的），每個設備處理一個包需要耗時1秒，所以到達另一端需要耗時4秒，如果發送的更加快速，則單位時間內，會有更多的包到達這些中間設備，這些設備還是只能每秒處理一個包的話，多出來的包就會被丟棄，
解決上面這個問題可以在每個中間設備上加快取，這樣處理不完的時候先放在快取里，但是這樣快取里放的多了就會超時重傳，也是個問題，

于是TCP的擁塞控制主要來避免兩種現象，包丟失和超時重傳，一旦出現了這些現象就說明，發送速度太快了，要慢一點，但是一開始我怎么知道速度多快呢，我怎么知道應該把視窗調整到多大呢？

慢啟動

如果我們通過漏斗往瓶子里灌水，我們就知道，不能一桶水一下子倒進去，肯定會濺出來，要一開始慢慢的倒，然后發現總能夠倒進去，就可以越倒越快，這叫作慢啟動，

一條TCP連接開始，cwnd設定為一個報文段，一次只能發送一個；當收到這一個確認的時候，cwnd加一，于是一次能夠發送兩個；當這兩個的確認到來的時候，每個確認cwnd加一，兩個確認cwnd加二，于是一次能夠發送四個，可以看出這是指數性的增長，

當超過ssthresh = 65535這個值的時候，可能快滿了，速度降下來，后面每收到一個確認后，cwnd增加1/cwnd（多個確認到來的時候才增加1），線性增長了，

但不斷增加就會有水滿則溢位現擁塞的時候，一旦丟包超時重傳，cwnd會一下變回1，將高速的傳輸速度一下子降下來，一夜回到解放前，這種方式不太可取，
采用前面說的快速重傳演算法，發現中間缺了某個包，前一個包就連續發三次ACK，不會等待超時再重傳，會立即重傳，并且此時cwnd減半為cwnd/2，然后sshthresh =cwnd，并沒有一夜回到解放前，

其實上面還會產生兩個問題就是：

1. 有時候公網上帶寬沒滿的時候也會有丟包的情況，這時候發送端誤以為擁塞了，
2. TCP的擁塞控制要等到將中間設備都填充滿了，才發生丟包，從而降低速度，這時候已經晚了，

為了優化以上兩個問題采用TCP BBR擁塞演算法，就是找到個平衡點，只把管道加滿，不把路徑上中間設備的快取填滿，可以很好的達到高帶寬低時延的平衡，

擁塞控制是通過擁塞視窗來解決的，相當于往管道里面倒水，快了容易溢位，慢了浪費帶寬，要摸著石頭過河，找到最優值，