摘要：由于本身發(fā)送的就是一份一份的數(shù)據(jù)報，所以自然而然的就有一個上限的大小。并且由于本身的不可靠性以及無序性，如果發(fā)送了這三個數(shù)據(jù)報過來，端接收到的可能是任意順序任意個數(shù)三個數(shù)據(jù)報的排列組合。

最頭疼的問題莫過于到底該選TCP還是UDP作為傳輸層協(xié)議。通過快速對比分析 TCP 和 UDP 的區(qū)別，來幫助即時通訊初學(xué)者快速了解這些基礎(chǔ)的知識點，從而在IM、消息推送等網(wǎng)絡(luò)通信應(yīng)用場景中能準(zhǔn)確地選擇合適的傳輸層協(xié)議。

說到 TCP 建立連接，相信大多數(shù)人腦海里肯定可以浮現(xiàn)出一個詞，沒錯就是--“三次握手”。TCP 通過“三次握手”來建立連接，再通過“四次揮手”斷開一個連接。在每次揮手中 TCP 做了哪些操作呢？

流程如下圖所示（TCP的三次握手和四次揮手）：

上圖就從客戶端和服務(wù)端的角度，清楚的展示了 TCP 的三次握手和四次揮手。可以看到，當(dāng) TCP 試圖建立連接時，三次握手指的是客戶端主動觸發(fā)了兩次，服務(wù)端觸發(fā)了一次。

我們可以先明確一下 TCP 建立連接并且初始化的目標(biāo)是什么呢？

1初始化資源；

2告訴對方我的序列號。

所以三次握手的次序是這樣子的：

client端首先發(fā)送一個SYN包告訴Server端我的初始序列號是X；

Server端收到SYN包后回復(fù)給client一個ACK確認(rèn)包，告訴client說我收到了；

接著Server端也需要告訴client端自己的初始序列號，于是Server也發(fā)送一個SYN包告訴client我的初始序列號是Y；

Client收到后，回復(fù)Server一個ACK確認(rèn)包說我知道了。

其中的 2 、3 步驟可以簡化為一步，也就是說將 ACK 確認(rèn)包和 SYN 序列化包一同發(fā)送給 Client 端。到此我們就比較簡單的解釋了 TCP 建立連接的“三次握手”。

我們都知道 TCP 是面向連接的、可靠的、有序的傳輸層協(xié)議，而 UDP 是面向數(shù)據(jù)報的、不可靠的、無序的傳輸協(xié)議，所以 UDP 壓根不會建立什么連接。

就好比發(fā)短信一樣，UDP 只需要知道對方的 ip 地址，將數(shù)據(jù)報一份一份的發(fā)送過去就可以了，其他的作為發(fā)送方，都不需要關(guān)心。

關(guān)于 TCP、UDP 之間數(shù)據(jù)發(fā)送的差異，可以體現(xiàn)二者最大的不同之處：

TCP：
由于 TCP 是建立在兩端連接之上的協(xié)議，所以理論上發(fā)送的數(shù)據(jù)流不存在大小的限制。但是由于緩沖區(qū)有大小限制，所以你如果用 TCP 發(fā)送一段很大的數(shù)據(jù)，可能會截斷成好幾段，接收方依次的接收。

UDP：
由于 UDP 本身發(fā)送的就是一份一份的數(shù)據(jù)報，所以自然而然的就有一個上限的大小。

那么每次 UDP 發(fā)送的數(shù)據(jù)報大小由哪些因素共同決定呢？

UDP協(xié)議本身，UDP協(xié)議中有16位的UDP報文長度，那么UDP報文長度不能超過2^16=65536；

以太網(wǎng)(Ethernet)數(shù)據(jù)幀的長度，數(shù)據(jù)鏈路層的MTU(最大傳輸單元)；

socket的UDP發(fā)送緩存區(qū)大小

先來看第一個因素，UDP 本身協(xié)議的報文長度為 2^16 - 1，UDP 包頭占 8 個字節(jié)，IP 協(xié)議本身封裝后包頭占 20 個字節(jié)，所以最終長度為： 2^16 - 1 - 20 - 8 = 65507 字節(jié)。

只看第一個因素有點理想化了，因為 UDP 屬于不可靠協(xié)議，我們應(yīng)該盡量避免在傳輸過程中，數(shù)據(jù)包被分割。所以這里有一個非常重要的概念 MTU -- 也就是最大傳輸單元。

在 Internet 下 MTU 的值為 576 字節(jié)，所以在 internet 下使用 UDP 協(xié)議，每個數(shù)據(jù)報最大的字節(jié)數(shù)為： 576 - 20 - 8 = 548

對于 TCP 來說，本身 TCP 有著超時重傳、錯誤重傳、還有等等一系列復(fù)雜的算法保證了 TCP 的數(shù)據(jù)是有序的，假設(shè)你發(fā)送了數(shù)據(jù) 1、2、3，則只要發(fā)送端和接收端保持連接時，接收端收到的數(shù)據(jù)始終都是 1、2、3。

而 UDP 協(xié)議則要奔放的多，無論 server 端無論緩沖池的大小有多大，接收 client 端發(fā)來的消息總是一個一個的接收。

并且由于 UDP 本身的不可靠性以及無序性，如果 client 發(fā)送了 1、2、3 這三個數(shù)據(jù)報過來，server 端接收到的可能是任意順序、任意個數(shù)三個數(shù)據(jù)報的排列組合。

其實大家都知道 TCP 本身是可靠的協(xié)議，而 UDP 是不可靠的協(xié)議。

TCP 內(nèi)部的很多算法機制讓他保持連接的過程中是很可靠的。比如：TCP 的超時重傳、錯誤重傳、TCP 的流量控制、阻塞控制、慢熱啟動算法、擁塞避免算法、快速恢復(fù)算法 等等。

所以 TCP 是一個內(nèi)部原理復(fù)雜，但是使用起來比較簡單的這么一個協(xié)議。

UDP 是一個面向非連接的協(xié)議，UDP 發(fā)送的每個數(shù)據(jù)報帶有自己的 IP 地址和接收方的 IP 地址，它本身對這個數(shù)據(jù)報是否出錯，是否到達(dá)不關(guān)心，只要發(fā)出去了就好了。

所以來研究下，什么情況會導(dǎo)致 UDP 丟包：

數(shù)據(jù)報分片重組丟失：在文章之前我們就說過，UDP 的每個數(shù)據(jù)報大小多少最合適，事實上 UDP 協(xié)議本身規(guī)定的大小是 64kb，但是在數(shù)據(jù)鏈路層有 MTU 的限制，大小大概在 5kb，所以當(dāng)你發(fā)送一個很大的 UDP 包的時候，這個包會在 IP 層進行分片，然后重組。這個過程就有可能導(dǎo)致分片的包丟失。UDP 本身有 CRC 檢測機制，會拋棄掉丟失的 UDP 包；

UDP 緩沖區(qū)填滿：當(dāng) UDP 的緩沖區(qū)已經(jīng)被填滿的時候，接收方還沒有處理這部分的 UDP 數(shù)據(jù)報，這個時候再過來的數(shù)據(jù)報就沒有地方可以存了，自然就都被丟棄了。

在文章最后的一部分，聊聊 TCP、UDP 使用場景。

先來說 UDP 的吧，有很多人都會覺得 UDP 與 TCP 相比，在性能速度上是占優(yōu)勢的。

因為 UDP 并不用保持一個持續(xù)的連接，也不需要對收發(fā)包進行確認(rèn)。

但事實上經(jīng)過這么多年的發(fā)展 TCP 已經(jīng)擁有足夠多的算法和優(yōu)化，在網(wǎng)絡(luò)狀態(tài)不錯的情況下，TCP 的整體性能是優(yōu)于 UDP 的。

那在什么時候我們非用 UDP 不可呢？

對實時性要求高：比如實時會議，實時視頻這種情況下，如果使用 TCP，當(dāng)網(wǎng)絡(luò)不好發(fā)生重傳時，畫面肯定會有延時，甚至越堆越多。如果使用 UDP 的話，即使偶爾丟了幾個包，但是也不會影響什么，這種情況下使用 UDP 比較好；

多點通信：TCP 需要保持一個長連接，那么在涉及多點通訊的時候，肯定需要和多個通信節(jié)點建立其雙向連接，然后有時在NAT環(huán)境下，兩個通信節(jié)點建立其直接的 TCP 連接不是一個容易的事情，而 UDP 可以無需保持連接，直接發(fā)就可以了，所以成本會很低，而且穿透性好。這種情況下使用 UDP 也是沒錯的。

以上我們說了 UDP 的使用場景，在此之外的其他情況，使用 TCP 準(zhǔn)沒錯。

畢竟有一句話嘛：

when in doubt，use TCP。