講完了 IP 層以后，接下來我們開始講傳輸層，傳輸層里比較重要的兩個協議，一個是 TCP，一個是 UDP，對于不從事底層開發的人員來講，或者對于開發應用的人來講，最常用的就是這兩個協議，由于面試的時候，這兩個協議經常會被放在一起問，因而我在講的時候，也會結合著來講，
TCP 和 UDP 有哪些區別？
一般面試的時候我問這兩個協議的區別，大部分人會回答，TCP 是面向連接的，UDP 是面向無連接的，
什么叫面向連接，什么叫無連接呢？在互通之前，面向連接的協議會先建立連接，例如，TCP 會三次握手，而 UDP 不會，為什么要建立連接呢？你 TCP 三次握手，我 UDP 也可以發三個包玩玩，有什么區別嗎？
所謂的建立連接，是為了在客戶端和服務端維護連接，而建立一定的資料結構來維護雙方互動的狀態，用這樣的資料結構來保證所謂的面向連接的特性，
例如，TCP 提供可靠交付，通過 TCP 連接傳輸的資料，無差錯、不丟失、不重復、并且按序到達，我們都知道 IP 包是沒有任何可靠性保證的，一旦發出去，就像西天取經，走丟了、被妖怪吃了，都只能隨它去，但是 TCP 號稱能做到那個連接維護的程式做的事情，這個下兩節我會詳細描述，而 UDP 繼承了 IP 包的特性，不保證不丟失，不保證按順序到達，
再如，TCP 是面向位元組流的，發送的時候發的是一個流，沒頭沒尾，IP 包可不是一個流，而是一個個的 IP 包，之所以變成了流，這也是 TCP 自己的狀態維護做的事情，而 UDP 繼承了 IP 的特性，基于資料報的，一個一個地發，一個一個地收，
還有 TCP 是可以有擁塞控制的，它意識到包丟棄了或者網路的環境不好了，就會根據情況調整自己的行為，看看是不是發快了，要不要發慢點，UDP 就不會，應用讓我發，我就發，管它洪水滔天，
因而 TCP 其實是一個有狀態服務，通俗地講就是有腦子的，里面精確地記著發送了沒有，接收到沒有，發送到哪個了，應該接收哪個了，錯一點兒都不行，而 UDP 則是無狀態服務，通俗地說是沒腦子的，天真無邪的，發出去就發出去了，
我們可以這樣比喻，如果 MAC 層定義了本地局域網的傳輸行為，IP 層定義了整個網路端到端的傳輸行為，這兩層基本定義了這樣的基因：網路傳輸是以包為單位的，二層叫幀，網路層叫包，傳輸層叫段，我們籠統地稱為包，包單獨傳輸，自行選路，在不同的設備封裝解封裝，不保證到達，基于這個基因，生下來的孩子 UDP 完全繼承了這些特性，幾乎沒有自己的思想，
UDP 包頭是什么樣的？
我們來看一下 UDP 包頭，
前面章節我已經講過包的傳輸程序，這里不再贅述，當我發送的 UDP 包到達目標機器后，發現 MAC 地址匹配，于是就取下來，將剩下的包傳給處理 IP 層的代碼，把 IP 頭取下來，發現目標 IP 匹配，接下來呢？這里面的資料包是給誰呢？
發送的時候，我知道我發的是一個 UDP 的包，收到的那臺機器咋知道的呢？所以在 IP 頭里面有個 8 位協議，這里會存放，資料里面到底是 TCP 還是 UDP，當然這里是 UDP，于是，如果我們知道 UDP 頭的格式，就能從資料里面，將它決議出來，決議出來以后呢？資料給誰處理呢？
處理完傳輸層的事情，內核的事情基本就干完了，里面的資料應該交給應用程式自己去處理，可是一臺機器上跑著這么多的應用程式，應該給誰呢？
無論應用程式寫的使用 TCP 傳資料，還是 UDP 傳資料，都要監聽一個埠，正是這個埠，用來區分應用程式，要不說埠不能沖突呢，兩個應用監聽一個埠，到時候包給誰呀？所以，按理說，無論是 TCP 還是 UDP 包頭里面應該有埠號，根據埠號，將資料交給相應的應用程式，
當我們看到 UDP 包頭的時候，發現的確有埠號，有源埠號和目標埠號，因為是兩端通信嘛，這很好理解，但是你還會發現，UDP 除了埠號，再沒有其他的了，和下兩節要講的 TCP 頭比起來，這個簡直簡單得一塌糊涂啊！
UDP 的三大特點
UDP 就像小孩子一樣，有以下這些特點：
第一，溝通簡單，不需要一肚子花花腸子（大量的資料結構、處理邏輯、包頭欄位），前提是它相信網路世界是美好的，秉承性善論，相信網路通路默認就是很容易送達的，不容易被丟棄的，
第二，輕信他人，它不會建立連接，雖然有埠號，但是監聽在這個地方，誰都可以傳給他資料，他也可以傳給任何人資料，甚至可以同時傳給多個人資料，
第三，愣頭青，做事不懂權變，不知道什么時候該堅持，什么時候該退讓，它不會根據網路的情況進行發包的擁塞控制，無論網路丟包丟成啥樣了，它該怎么發還怎么發，
UDP 的三大使用場景
基于 UDP 這種“小孩子”的特點，我們可以考慮在以下的場景中使用，
第一，需要資源少，在網路情況比較好的內網，或者對于丟包不敏感的應用，這很好理解，就像如果你是領導，你會讓你們組剛畢業的小朋友去做一些沒有那么難的專案，打一些沒有那么難的客戶，或者做一些失敗了也能忍受的實驗性專案，
我們在第四節講的 DHCP 就是基于 UDP 協議的，一般的獲取 IP 地址都是內網請求，而且一次獲取不到 IP 又沒事，過一會兒還有機會，我們講過 PXE 可以在啟動的時候自動安裝作業系統，作業系統鏡像的下載使用的 TFTP，這個也是基于 UDP 協議的，在還沒有作業系統的時候，客戶端擁有的資源很少，不適合維護一個復雜的狀態機，而且因為是內網，一般也沒啥問題，
第二，不需要一對一溝通，建立連接，而是可以廣播的應用，咱們小時候人都很簡單，大家在班級里面，誰成績好，誰寫作好，應該表揚誰懲罰誰，誰得幾個小紅花都是當著全班的面講的，公平公正公開，長大了人心復雜了，薪水、獎金要背靠背，和員工一對一溝通，
UDP 的不面向連接的功能，可以使得可以承載廣播或者多播的協議，DHCP 就是一種廣播的形式，就是基于 UDP 協議的，而廣播包的格式前面說過了，
對于多播，我們在講 IP 地址的時候，講過一個 D 類地址，也即組播地址，使用這個地址，可以將包組播給一批機器，當一臺機器上的某個行程想監聽某個組播地址的時候，需要發送 IGMP 包，所在網路的路由器就能收到這個包，知道有個機器上有個行程在監聽這個組播地址，當路由器收到這個組播地址的時候，會將包轉發給這臺機器，這樣就實作了跨路由器的組播，
在后面云中網路部分，有一個協議 VXLAN，也是需要用到組播，也是基于 UDP 協議的，
第三，需要處理速度快，時延低，可以容忍少數丟包，但是要求即便網路擁塞，也毫不退縮，一往無前的時候，記得曾國藩建立湘軍的時候，專門招出生牛犢不怕虎的新兵，而不用那些“老油條”的八旗兵，就是因為八旗兵經歷的事情多，遇到敵軍不敢舍死忘生，
同理，UDP 簡單、處理速度快，不像 TCP 那樣，操這么多的心，各種重傳啊，保證順序啊，前面的不收到，后面的沒法處理啊，不然等這些事情做完了，時延早就上去了，而 TCP 在網路不好出現丟包的時候，擁塞控制策略會主動的退縮，降低發送速度，這就相當于本來環境就差，還自斷臂膀，用戶本來就卡，這下更卡了，
當前很多應用都是要求低時延的，它們可不想用 TCP 如此復雜的機制，而是想根據自己的場景，實作自己的可靠和連接保證，例如，如果應用自己覺得，有的包丟了就丟了，沒必要重傳了，就可以算了，有的比較重要，則應用自己重傳，而不依賴于 TCP，有的前面的包沒到，后面的包到了，那就先給客戶展示后面的嘛，干嘛非得等到齊了呢？如果網路不好，丟了包，那不能退縮啊，要盡快傳啊，速度不能降下來啊，要擠占帶寬，搶在客戶失去耐心之前到達，
由于 UDP 十分簡單，基本啥都沒做，也就給了應用“城會玩”的機會，就像在和平年代，每個人應該有獨立的思考和行為，應該可靠并且禮讓；但是如果在戰爭年代，往往不太需要過于獨立的思考，而需要士兵簡單服從命令就可以了，
曾國藩說哪支部隊需要誘敵犧牲，也就犧牲了，相當于包丟了就丟了，兩軍狹路相逢的時候，曾國藩說上，沒有帶寬也要上，這才給了曾國藩運籌帷幄，城會玩的機會，同理如果你實作的應用需要有自己的連接策略，可靠保證，時延要求，使用 UDP，然后再應用層實作這些是再好不過了，
基于 UDP 的“城會玩”的五個例子
我列舉幾種“城會玩”的例子，
“城會玩”一：網頁或者 APP 的訪問
原來訪問網頁和手機 APP 都是基于 HTTP 協議的，HTTP 協議是基于 TCP 的，建立連接都需要多次互動，對于時延比較大的目前主流的移動互聯網來講，建立一次連接需要的時間會比較長，然而既然是移動中，TCP 可能還會斷了重連，也是很耗時的，而且目前的 HTTP 協議，往往采取多個資料通道共享一個連接的情況，這樣本來為了加快傳輸速度，但是 TCP 的嚴格順序策略使得哪怕共享通道，前一個不來，后一個和前一個即便沒關系，也要等著，時延也會加大，
而 QUIC（全稱 Quick UDP Internet Connections，快速 UDP 互聯網連接）是 Google 提出的一種基于 UDP 改進的通信協議，其目的是降低網路通信的延遲，提供更好的用戶互動體驗，
QUIC 在應用層上，會自己實作快速連接建立、減少重傳時延，自適應擁塞控制，是應用層“城會玩”的代表，這一節主要是講 UDP，QUIC 我們放到應用層去講，
“城會玩”二：流媒體的協議
現在直播比較火，直播協議多使用 RTMP，這個協議我們后面的章節也會講，而這個 RTMP 協議也是基于 TCP 的，TCP 的嚴格順序傳輸要保證前一個收到了，下一個才能確認，如果前一個收不到，下一個就算包已經收到了，在快取里面，也需要等著，對于直播來講，這顯然是不合適的，因為老的視頻幀丟了其實也就丟了，就算再傳過來用戶也不在意了，他們要看新的了，如果老是沒來就等著，卡頓了，新的也看不了，那就會丟失客戶，所以直播，實時性比較比較重要，寧可丟包，也不要卡頓的，
另外，對于丟包，其實對于視頻播放來講，有的包可以丟，有的包不能丟，因為視頻的連續幀里面，有的幀重要，有的不重要，如果必須要丟包，隔幾個幀丟一個，其實看視頻的人不會感知，但是如果連續丟幀，就會感知了，因而在網路不好的情況下，應用希望選擇性的丟幀，
還有就是當網路不好的時候，TCP 協議會主動降低發送速度，這對本來當時就卡的看視頻來講是要命的，應該應用層馬上重傳，而不是主動讓步，因而，很多直播應用，都基于 UDP 實作了自己的視頻傳輸協議，
“城會玩”三：實時游戲
游戲有一個特點，就是實時性比較高，快一秒你干掉別人，慢一秒你被別人爆頭，所以很多職業玩家會買非常專業的滑鼠和鍵盤，爭分奪秒，
因而，實時游戲中客戶端和服務端要建立長連接，來保證實時傳輸，但是游戲玩家很多，服務器卻不多，由于維護 TCP 連接需要在內核維護一些資料結構，因而一臺機器能夠支撐的 TCP 連接數目是有限的，然后 UDP 由于是沒有連接的，在異步 IO 機制引入之前，常常是應對海量客戶端連接的策略，
另外還是 TCP 的強順序問題，對戰的游戲，對網路的要求很簡單，玩家通過客戶端發送給服務器滑鼠和鍵盤行走的位置，服務器會處理每個用戶發送過來的所有場景，處理完再回傳給客戶端，客戶端決議回應，渲染最新的場景展示給玩家，
另外還是 TCP 的強順序問題，對戰的游戲，對網路的要求很簡單，玩家通過客戶端發送給服務器滑鼠和鍵盤行走的位置，服務器會處理每個用戶發送過來的所有場景，處理完再回傳給客戶端，客戶端決議回應，渲染最新的場景展示給玩家，
游戲對實時要求較為嚴格的情況下，采用自定義的可靠 UDP 協議，自定義重傳策略，能夠把丟包產生的延遲降到最低，盡量減少網路問題對游戲性造成的影響，
“城會玩”四：IoT 物聯網
一方面，物聯網領域終端資源少，很可能只是個記憶體非常小的嵌入式系統，而維護 TCP 協議代價太大；另一方面，物聯網對實時性要求也很高，而 TCP 還是因為上面的那些原因導致時延大，Google 旗下的 Nest 建立 Thread Group，推出了物聯網通信協議 Thread，就是基于 UDP 協議的，
“城會玩”五：移動通信領域
4G 網路里，移動流量上網的資料面對的協議 GTP-U 是基于 UDP 的，因為移動網路協議比較復雜，而 GTP 協議本身就包含復雜的手機上線下線的通信協議，如果基于 TCP，TCP 的機制就顯得非常多余，這部分協議我會在后面的章節單獨講解，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/172556.html
標籤：其他