高通信實時性要求和低持續(xù)性要求的場景下：

1，在分組交換通信當(dāng)中，協(xié)議棧的成本主要表現(xiàn)在以下兩方面：

• [1] 封裝帶來的空間復(fù)雜度;
• [2] 緩存帶來的時間復(fù)雜度。

以上兩者是對立影響的，如果想減少封裝消耗，那么就必須緩存用戶數(shù)據(jù)到一定量在一次性封裝發(fā)送出去，這樣每個協(xié)議包的有效載荷將達(dá)到***化，這無疑是節(jié)省了帶寬空間，帶寬利用率較高，但是延時增大了。如果想降低延時，那么就需要將用戶數(shù)據(jù)立馬封裝發(fā)出去，這樣顯然會造成消耗更多的協(xié)議頭等消耗，浪費帶寬空間。

因此，我們進(jìn)行協(xié)議選擇的時候，需要重點考慮一下空間復(fù)雜度和時間復(fù)雜度間的平衡。

2，通信的持續(xù)性對兩者的影響比較大，根據(jù)通信的持續(xù)性有兩種通信類型：

• [1] 短連接通信;
• [2] 長連接通信。

對于短連接通信，一方面如果業(yè)務(wù)只需要發(fā)一兩個包并且對丟包有一定的容忍度，同時業(yè)務(wù)自己有簡單的輪詢或重復(fù)機(jī)制，那么采用UDP會較為好些。在這樣的場景下，如果用TCP，僅僅握手就需要3個包，這樣顯然有點不劃算，一個典型的例子是DNS查詢。另一方面，如果業(yè)務(wù)實時性要求非常高，并且不能忍受重傳，那么首先就是UDP了或者只能用UDP了，例如NTP 協(xié)議，重傳NTP消息純屬添亂(為什么呢?重傳一個過期的時間***來，還不如發(fā)一個新的UDP包同步新的時間過來)。如果NTP協(xié)議采用TCP，撇開握手消耗較多數(shù)據(jù)包交互的問題，由于TCP受Nagel算法等影響，用戶數(shù)據(jù)會在一定情況下會被內(nèi)核緩存延后發(fā)送出去，這樣時間同步就會出現(xiàn)比較大的偏差，協(xié)議將不可用。

多點通信的場景下

對于一些多點通信的場景，如果采用有連接的TCP，那么就需要和多個通信節(jié)點建立其雙向連接，然后有時在NAT環(huán)境下，兩個通信節(jié)點建立其直接的TCP連接不是一個容易的事情，在涉及NAT穿越的時候，UDP協(xié)議的無連接性使得穿透成功率更高(原因詳見：由于UDP的無連接性，那么其完全可以向一個組播地址發(fā)送數(shù)據(jù)或者輪轉(zhuǎn)地向多個目的地持續(xù)發(fā)送相同的數(shù)據(jù)，從而更為容易實現(xiàn)多點通信。)

一個典型的場景是多人實時音視頻通信，這種場景下實時性要求比較高，可以容忍一定的丟包率。比如：對于音頻，對端連續(xù)發(fā)送p1、p2、p3三個包，另一端收到了p1和p3，在沒收到p2的保持p1的***一個音(也是為什么有時候網(wǎng)絡(luò)丟包就會聽到嗞嗞嗞嗞嗞嗞…或者卟卟卟卟卟卟卟卟…重音的原因)，等到到p3就接著播p3了，不需要也不能補(bǔ)幀，一補(bǔ)就越來越大的延時。對于這樣的場景就比較合適用UDP了，如果采用TCP，那么在出現(xiàn)丟包的時候，就可能會出現(xiàn)比較大的延時。

UDP的使用原則小結(jié)

通常情況下，UDP的使用范圍是較小的，在以下的場景下，使用UDP才是明智的。

• [1] 實時性要求很高，并且?guī)缀醪荒苋萑讨貍鳎?/li>
• 例子：NTP協(xié)議，實時音視頻通信，多人動作類游戲中人物動作、位置。
• [2] TCP實在不方便實現(xiàn)多點傳輸?shù)那闆r;
• [3] 需要進(jìn)行NAT穿越;
• [4] 對網(wǎng)絡(luò)狀態(tài)很熟悉，確保udp網(wǎng)絡(luò)中沒有氓流行為，瘋狂搶帶寬;
• [5] 熟悉UDP編程。