講完了 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 的機制就顯得非常多余，這部分協議我會在后面的章節單獨講解。
小結
- 如果將 TCP 比作成熟的社會人，UDP 則是頭腦簡單的小朋友。TCP 復雜，UDP 簡單；TCP 維護連接，UDP 誰都相信；TCP 會堅持知進退；UDP 愣頭青一個，勇往直前；
- UDP 雖然簡單，但它有簡單的用法。它可以用在環境簡單、需要多播、應用層自己控制傳輸的地方。例如 DHCP、VXLAN、QUIC 等。