TCP 

狀態機

TCP 穩定連線

三次握手，四次揮手。用於流量控制，擁塞控制。

左側為A，右側為B。

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 的強順序問題，對戰的遊戲，對網路的要求很簡單，玩家通過客戶端傳送給伺服器滑鼠和鍵盤行走的位置，伺服器會處理每個使用者傳送過來的所有場景，處理完再返回給客戶端，客戶端解析響應，渲染最新的場景展示給玩家。

如果出現一個數據包丟失，所有事情都需要停下來等待這個資料包重發。客戶端會出現等待接收資料，然而玩家並不關心過期的資料，激戰中卡 1 秒，等能動了都已經死了。

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

“城會玩”四：IoT 物聯網
一方面，物聯網領域終端資源少，很可能只是個記憶體非常小的嵌入式系統，而維護 TCP 協議代價太大；另一方面，物聯網對實時性要求也很高，而 TCP 還是因為上面的那些原因導致時延大。Google 旗下的 Nest 建立 Thread Group，推出了物聯網通訊協議 Thread，就是基於 UDP 協議的。

“城會玩”五：行動通訊領域
在 4G 網路裡，移動流量上網的資料面對的協議 GTP-U 是基於 UDP 的。因為行動網路協議比較複雜，而 GTP 協議本身就包含複雜的手機上線下線的通訊協議。如果基於 TCP，TCP 的機制就顯得非常多餘。