學習&轉載文章："動圖圖解 | UDP就一定比TCP快嗎？"
UDP比TCP快嗎？
相信就算不是八股文老手，也會下意識的脫口而出："是"。
這要追問爲什麼，估計大家也能說出個大概。
但這也讓人好奇，用UDP就一定比用TCP快嗎？什麼情況下用UDP會比用TCP慢？
我們今天就來聊下這個話題。
使用socket進行數據傳輸
作爲一個程序員，假設我們需要在A電腦的進程發一段數據到B電腦的進程，我們一般會在代碼裏使用socket進行編程。
socket就像是一個電話或者郵箱（郵政的信箱）。當你想要發送消息的時候，撥通電話或者將信息塞到郵箱裏，socket內核會自動完成將數據傳給對方的這個過程。
基於socket我們可以選擇使用TCP或UDP協議進行通信。
對於TCP這樣的可靠性協議，每次消息發出後都能明確知道對方收沒收到，就像打電話一樣，只要"喂喂"兩下就能知道對方有沒有在聽。
而UDP就像是給郵政的信箱寄信一樣，你寄出去的信，根本就不知道對方有沒有正常收到，丟了也是有可能的。
這讓我想起了大概17年前，當時還沒有現在這麼發達的網購，想買一本《掌機迷》雜誌，還得往信封裏塞錢，然後一等就是一個月，好幾次都懷疑信是不是丟了。我至今印象深刻，因爲那是我和我哥攢了好久的錢。。。
回到socket編程的話題上。
創建socket的方式就像下面這樣。
fd = socket(AF_INET, 具體協議,0);
注意上面的"具體協議"，如果傳入的是SOCK_STREAM，是指使用字節流傳輸數據，說白了就是TCP協議。
如果傳入的是SOCK_DGRAM，是指使用數據報傳輸數據，也就是UDP協議。
返回的fd是指socket句柄，可以理解爲socket的身份證號。通過這個fd你可以在內核中找到唯一的socket結構。
如果想要通過這個socket發消息，只需要操作這個fd就行了，比如執行 send(fd, msg, ...)，內核就會通過這個fd句柄找到socket然後進行發數據的操作。
如果一切順利，此時對方執行接收消息的操作，也就是 recv(fd, msg, ...)，就能拿到你發的消息。
對於異常情況的處理
但如果不順利呢？
比如消息發到一半，丟包了呢?
那UDP和TCP的態度就不太一樣了。
UDP表示，"哦，是嗎？然後呢？關我x事"
TCP態度就截然相反了，"啊？那可不行，是不是我發太快了呢？是不是鏈路太堵被別人影響到了呢？不過你放心，我肯定給你補發"
TCP老實人石錘了。我們來看下這個老實人在背後都默默做了哪些事情。
重傳機制
對於TCP，它會給發出的消息打上一個編號（sequence），接收方收到後回一個確認(ack)。發送方可以通過ack的數值知道接收方收到了哪些sequence的包。
如果長時間等不到對方的確認，TCP就會重新發一次消息，這就是所謂的重傳機制。
流量控制機制
但重傳這件事本身對性能影響是比較嚴重的，所以是下下策。
於是TCP就需要思考有沒有辦法可以儘量避免重傳。
因爲數據發送方和接收方處理數據能力可能不同，因此如果可以根據雙方的能力去調整發送的數據量就好了，於是就有了發送和接收窗口，基本上從名字就能看出它的作用，比如接收窗口的大小就是指，接收方當前能接收的數據量大小，發送窗口的大小就指發送方當前能發的數據量大小。TCP根據窗口的大小去控制自己發送的數據量，這樣就能大大減少丟包的概率。
滑動窗口機制
接收方的接收到數據之後，會不斷處理，處理能力也不是一成不變的，有時候處理的快些，那就可以收多點數據，處理的慢點那就希望對方能少發點數據。畢竟發多了就有可能處理不過來導致丟包，丟包會導致重傳，這可是下下策。因此我們需要動態的去調節這個接收窗口的大小，於是就有了滑動窗口機制。
看到這裏大家可能就有點迷了，流量控制和滑動窗口機制貌似很像，它們之間是啥關係？我總結一下。其實現在TCP是通過滑動窗口機制來實現流量控制機制的。
擁塞控制機制
但這還不夠，有時候發生丟包，並不是因爲發送方和接收方的處理能力問題導致的。而是跟網絡環境有關，大家可以將網絡想象爲一條公路。馬路上可能堵滿了別人家的車，只留下一輛車的空間。那就算你家有5輛車，目的地也正好有5個停車位，你也沒辦法同時全部一起上路。於是TCP希望能感知到外部的網絡環境，根據網絡環境及時調整自己的發包數量，比如馬路只夠兩輛車跑，那我就只發兩輛車。但外部環境這麼複雜，TCP是怎麼感知到的呢？
TCP會先慢慢試探的發數據，不斷加碼數據量，越發越多，先發一個，再發2個，4個...。直到出現丟包，這樣TCP就知道現在當前網絡大概喫得消幾個包了，這既是所謂的擁塞控制機制。
不少人會疑惑流量控制和擁塞控制的關係。我這裏小小的總結下。流量控制針對的是單個連接數據處理能力的控制，擁塞控制針對的是整個網絡環境數據處理能力的控制。
分段機制
但上面提到的都是怎麼降低重傳的概率，似乎重傳這個事情就是無法避免的，那如果確實發生了，有沒有辦法降低它帶來的影響呢？
有。當我們需要發送一個超大的數據包時，如果這個數據包丟了，那就得重傳同樣大的數據包。但如果我能將其分成一小段一小段，那就算真丟了，那我也就只需要重傳那一小段就好了，大大減小了重傳的壓力，這就是TCP的分段機制。
而這個所謂的一小段的長度，在傳輸層叫MSS（Maximum Segment Size），數據包長度大於MSS則會分成N個小於等於MSS的包。
而在網絡層，如果數據包還大於MTU（Maximum Transmit Unit），那還會繼續分包。
一般情況下，MSS=MTU-40Byte，所以TCP分段後，到了IP層大概率就不會再分片了。
亂序重排機制
既然數據包會被分段，鏈路又這麼複雜還會丟包，那數據包亂序也就顯得不奇怪了。比如發數據包1,2,3。1號數據包走了其他網絡路徑，2和3數據包先到，1數據包後到，於是數據包順序就成了2,3,1。這一點TCP也考慮到了，依靠數據包的sequence，接收方就能知道數據包的先後順序。
後發的數據包先到是吧，那就先放到專門的亂序隊列中，等數據都到齊後，重新整理好亂序隊列的數據包順序後再給到用戶，這就是亂序重排機制。
連接機制
前面提到，UDP是無連接的，而TCP是面向連接的。
這裏提到的連接到底是啥？
TCP通過上面提到的各種機制實現了數據的可靠性。這些機制背後是通過一個個數據結構來實現的邏輯。而爲了實現這套邏輯，操作系統內核需要在兩端代碼裏維護一套複雜的狀態機（三次握手，四次揮手，RST，closing等異常處理機制），這套狀態機其實就是所謂的"連接"。這其實就是TCP的連接機制，而UDP用不上這套狀態機，因此它是"無連接"的。
網絡環境鏈路很長，還複雜，數據丟包是很常見的。
我們平常用TCP做各種數據傳輸，完全對這些事情無感知。
哪有什麼歲月靜好，是TCP替你負重前行。
這就是TCP三大特性"面向連接、可靠的、基於字節流"中"可靠"的含義。
不信你改用UDP試試，丟包那就是真丟了，丟到你懷疑人生。
用UDP就一定比用TCP快嗎？
這時候UDP就不服了："正因爲沒有這些複雜的TCP可靠性機制，所以我很快啊"
嗯，這也是大部分人認爲UDP比TCP快的原因。
實際上大部分情況下也確實是這樣的。這話沒毛病。
那問題就來了。
有沒有用了UDP但卻比TCP慢的情況呢？
其實也有。
在回答這個問題前，我需要先說下UDP的用途。
實際上，大部分人也不會嘗試直接拿裸udp放到生產環境中去做項目。
那UDP的價值在哪？
在我看來，UDP的存在，本質是內核提供的一個最小網絡傳輸功能。
很多時候，大家雖然號稱自己用了UDP，但實際上都很忌憚它的丟包問題，所以大部分情況下都會在UDP的基礎上做各種不同程度的應用層可靠性保證。比如王者農藥用的KCP，以及最近很火的QUIC（HTTP3.0），其實都在UDP的基礎上做了重傳邏輯，實現了一套類似TCP那樣的可靠性機制。
教科書上最愛提UDP適合用於音視頻傳輸，因爲這些場景允許丟包。但其實也不是什麼包都能丟的，比如重要的關鍵幀啥的，該重傳還得重傳。除此之外，還有一些亂序處理機制。舉個例子吧。
打音視頻電話的時候，你可能遇到過丟失中間某部分信息的情況，但應該從來沒遇到過亂序的情況吧。
比如對方打網絡電話給你，說了："我好想給小白來個點贊在看！"
這時候網絡信號不好，你可能會聽到"我....點贊在看"。
但卻從來沒遇到過"在看小白好想贊"這樣的亂序場景吧？
所以說，雖然選擇了使用UDP，但一般還是會在應用層上做一些重傳機制的。
於是問題就來了，如果現在我需要傳一個特別大的數據包。
在TCP裏，它內部會根據MSS的大小分段，這時候進入到IP層之後，每個包大小都不會超過MTU，因此IP層一般不會再進行分片。這時候發生丟包了，只需要重傳每個MSS分段就夠了。
但對於UDP，其本身並不會分段，如果數據過大，到了IP層，就會進行分片。此時發生丟包的話，再次重傳，就會重傳整個大數據包。
對於上面這種情況，使用UDP就比TCP要慢。
當然，解決起來也不復雜。這裏的關鍵點在於是否實現了數據分段機制，使用UDP的應用層如果也實現了分段機制的話，那就不會出現上述的問題了。
總結
- TCP爲了實現可靠性，引入了重傳機制、流量控制、滑動窗口、擁塞控制、分段以及亂序重排機制。而UDP則沒有實現，因此一般來說TCP比UDP快。
- TCP是面向連接的協議，而UDP是無連接的協議。這裏的"連接"其實是，操作系統內核在兩端代碼裏維護的一套複雜狀態機。
- 大部分項目，會在基於UDP的基礎上，模仿TCP，實現不同程度的可靠性機制。比如王者農藥用的KCP其實就在基於UDP在應用層裏實現了一套重傳機制。
- 對於UDP+重傳的場景，如果要傳超大數據包，並且沒有實現分段機制的話，那數據就會在IP層分片，一旦丟包，那就需要重傳整個超大數據包。而TCP則不需要考慮這個，內部會自動分段，丟包重傳分段就行了。這種場景下，其實TCP更快。