關(guān)于UDP、TCP、RTP三種協(xié)議的分析

一、RTP協(xié)議分析

1、? RTP概述

1.1.? RTP是什么

RTP全名是Real-timeTransport Protocol（實(shí)時傳輸協(xié)議）。它是IETF提出的一個標(biāo)準(zhǔn)，對應(yīng)的RFC文檔為RFC3550（RFC1889為其過期版本）。RFC3550不僅定義了RTP，而且定義了配套的相關(guān)協(xié)議RTCP（Real-time Transport ControlProtocol，即實(shí)時傳輸控制協(xié)議）。RTP用來為IP網(wǎng)上的語音、圖像、傳真等多種需要實(shí)時傳輸?shù)亩嗝襟w數(shù)據(jù)提供端到端的實(shí)時傳輸服務(wù)。RTP為Internet上端到端的實(shí)時傳輸提供時間信息和流同步，但并不保證服務(wù)質(zhì)量，服務(wù)質(zhì)量由RTCP來提供。

1.2.? RTP的應(yīng)用環(huán)境

RTP用于在單播或多播網(wǎng)絡(luò)中傳送實(shí)時數(shù)據(jù)。它們典型的應(yīng)用場合有如下幾個。

（1）簡單的多播音頻會議。語音通信通過一個多播地址和一對端口來實(shí)現(xiàn)。一個用于音頻數(shù)據(jù)（RTP），另一個用于控制包（RTCP）。

（2）音頻和視頻會議。如果在一次會議中同時使用了音頻和視頻會議，這兩種媒體將分別在不同的RTP會話中傳送，每一個會話使用不同的傳輸?shù)刂罚↖P地址＋端口）。如果一個用戶同時使用了兩個會話，則每個會話對應(yīng)的RTCP包都使用規(guī)范化名字CNAME（Canonical Name）。與會者可以根據(jù)RTCP包中的CNAME來獲取相關(guān)聯(lián)的音頻和視頻，然后根據(jù)RTCP包中的計時信息(Network time protocol)來實(shí)現(xiàn)音頻和視頻的同步。

（3）翻譯器和混合器。翻譯器和混合器都是RTP級的中繼系統(tǒng)。翻譯器用在通過IP多播不能直接到達(dá)的用戶區(qū)，例如發(fā)送者和接收者之間存在防火墻。當(dāng)與會者能接收的音頻編碼格式不一樣，比如有一個與會者通過一條低速鏈路接入到高速會議，這時就要使用混合器。在進(jìn)入音頻數(shù)據(jù)格式需要變化的網(wǎng)絡(luò)前，混合器將來自一個源或多個源的音頻包進(jìn)行重構(gòu)，并把重構(gòu)后的多個音頻合并，采用另一種音頻編碼進(jìn)行編碼后，再轉(zhuǎn)發(fā)這個新的RTP包。從一個混合器出來的所有數(shù)據(jù)包要用混合器作為它們的同步源（SSRC，見RTP的封裝）來識別，可以通過貢獻(xiàn)源列表（CSRC表，見RTP的封裝）可以確認(rèn)談話者。

1.3.??流媒體

流媒體是指Internet上使用流式傳輸技術(shù)的連續(xù)時基媒體。當(dāng)前在Internet上傳輸音頻和視頻等信息主要有兩種方式：下載和流式傳輸兩種方式。

下載情況下，用戶需要先下載整個媒體文件到本地，然后才能播放媒體文件。在視頻直播等應(yīng)用場合，由于生成整個媒體文件要等直播結(jié)束，也就是用戶至少要在直播結(jié)束后才能看到直播節(jié)目，所以用下載方式不能實(shí)現(xiàn)直播。

流式傳輸是實(shí)現(xiàn)流媒體的關(guān)鍵技術(shù)。使用流式傳輸可以邊下載邊觀看流媒體節(jié)目。由于Internet是基于分組傳輸?shù)模越邮斩耸盏降臄?shù)據(jù)包往往有延遲和亂序（流式傳輸構(gòu)建在UDP上）。要實(shí)現(xiàn)流式傳輸，就是要從降低延遲和恢復(fù)數(shù)據(jù)包時序入手。在發(fā)送端，為降低延遲，往往對傳輸數(shù)據(jù)進(jìn)行預(yù)處理（降低質(zhì)量和高效壓縮）。在接收端為了恢復(fù)時序，采用了接收緩沖；而為了實(shí)現(xiàn)媒體的流暢播放，則采用了播放緩沖。

使用接收緩沖，可以將接收到的數(shù)據(jù)包緩存起來，然后根據(jù)數(shù)據(jù)包的封裝信息（如包序號和時戳等），將亂序的包重新排序，最后將重新排序了的數(shù)據(jù)包放入播放緩沖播放。

為什么需要播放緩沖呢？容易想到，由于網(wǎng)絡(luò)不可能很理想，并且對數(shù)據(jù)包排序需要處理時耗，我們得到排序好的數(shù)據(jù)包的時間間隔是不等的。如果不用播放緩沖，那么播放節(jié)目會很卡，這叫時延抖動。相反，使用播放緩沖，在開始播放時，花費(fèi)幾十秒鐘先將播放緩沖填滿（例如PPLIVE），可以有效地消除時延抖動，從而在不太損失實(shí)時性的前提下實(shí)現(xiàn)流媒體的順暢播放。

到目前為止,Internet?上使用較多的流式視頻格式主要有以下三種:RealNetworks?公司的RealMedia ,Apple?公司的QuickTime?以及Microsoft?公司的Advanced Streaming Format (ASF)?。

上面在談接收緩沖時，說到了流媒體數(shù)據(jù)包的封裝信息（包序號和時戳等），這在后面的RTP封裝中會有體現(xiàn)。另外，RealMedia這些流式媒體格式只是編解碼有不同，但對于RTP來說，它們都是待封裝傳輸?shù)牧髅襟w數(shù)據(jù)而沒有什么不同。

2、?? RTP詳解

2.1.? RTP的協(xié)議層次

2.1.1.??傳輸層的子層

RTP（實(shí)時傳輸協(xié)議），顧名思義它是用來提供實(shí)時傳輸?shù)模蚨梢钥闯墒莻鬏攲拥囊粋€子層。圖?1給出了流媒體應(yīng)用中的一個典型的協(xié)議體系結(jié)構(gòu)。圖2給出了RTP協(xié)議與其他協(xié)議之間的關(guān)系。

圖1?流媒體體系結(jié)構(gòu)

圖2 RTP協(xié)議與其他協(xié)議的關(guān)系

?

?

從圖中可以看出，RTP被劃分在傳輸層，它建立在UDP上。同UDP協(xié)議一樣，為了實(shí)現(xiàn)其實(shí)時傳輸功能，RTP也有固??????????????式。RTP用來為端到端的實(shí)時傳輸提供時間信息和流同步，但并不保證服務(wù)質(zhì)量。服務(wù)質(zhì)量由RTCP來提供。

?

2.1.2.??應(yīng)用層的一部分

不少人也把RTP歸為應(yīng)用層的一部分，這是從應(yīng)用開發(fā)者的角度來說的。操作系統(tǒng)中的TCP/IP等協(xié)議棧所提供的是我們最常用的服務(wù)，而RTP的實(shí)現(xiàn)還是要靠開發(fā)者自己。因此從開發(fā)的角度來說，RTP的實(shí)現(xiàn)和應(yīng)用層協(xié)議的實(shí)現(xiàn)沒不同，所以可將RTP看成應(yīng)用層協(xié)議。

RTP實(shí)現(xiàn)者在發(fā)送RTP數(shù)據(jù)時，需先將數(shù)據(jù)封裝成RTP包，而在接收到RTP數(shù)據(jù)包，需要將數(shù)據(jù)從RTP包中提取出來。

2.2.? RTP的封裝

一個協(xié)議的封裝是為了滿足協(xié)議的功能需求的。從前面提出的功能需求，可以推測出RTP封裝中應(yīng)該有同步源和時戳等字段，但更為完整的封裝是什么樣子呢？請看圖3。

圖3 RTP的頭部格式

?

版本號（V）：2比特，用來標(biāo)志使用的RTP版本。

填充位（P）：1比特，如果該位置位，則該RTP包的尾部就包含附加的填充字節(jié)。

擴(kuò)展位（X）：1比特，如果該位置位的話，RTP固定頭部后面就跟有一個擴(kuò)展頭部。

CSRC計數(shù)器（CC）：4比特，含有固定頭部后面跟著的CSRC的數(shù)目。

標(biāo)記位（M）：1比特,該位的解釋由配置文檔（Profile）來承擔(dān).

載荷類型（PT）：7比特，標(biāo)識了RTP載荷的類型。

序列號（SN）：16比特，發(fā)送方在每發(fā)送完一個RTP包后就將該域的值增加1，接收方可以由該域檢測包的丟失及恢復(fù)包序列。序列號的初始值是隨機(jī)的。

時間戳：32比特，記錄了該包中數(shù)據(jù)的第一個字節(jié)的采樣時刻。在一次會話開始時，時間戳初始化成一個初始值。即使在沒有信號發(fā)送時，時間戳的數(shù)值也要隨時間而不斷地增加（時間在流逝嘛）。時間戳是去除抖動和實(shí)現(xiàn)同步不可缺少的。

同步源標(biāo)識符(SSRC)：32比特，同步源就是指RTP包流的來源。在同一個RTP會話中不能有兩個相同的SSRC值。該標(biāo)識符是隨機(jī)選取的?RFC1889推薦了MD5隨機(jī)算法。

貢獻(xiàn)源列表（CSRC List）：0～15項(xiàng)，每項(xiàng)32比特，用來標(biāo)志對一個RTP混合器產(chǎn)生的新包有貢獻(xiàn)的所有RTP包的源。由混合器將這些有貢獻(xiàn)的SSRC標(biāo)識符插入表中。SSRC標(biāo)識符都被列出來，以便接收端能正確指出交談雙方的身份。

?

2.3.? RTCP的封裝

RTP需要RTCP為其服務(wù)質(zhì)量提供保證，因此下面介紹一下RTCP的相關(guān)知識。

RTCP的主要功能是：服務(wù)質(zhì)量的監(jiān)視與反饋、媒體間的同步，以及多播組中成員的標(biāo)識。在RTP會話期間，各參與者周期性地傳送RTCP包。RTCP包中含有已發(fā)送的數(shù)據(jù)包的數(shù)量、丟失的數(shù)據(jù)包的數(shù)量等統(tǒng)計資料，因此，各參與者可以利用這些信息動態(tài)地改變傳輸速率，甚至改變有效載荷類型。RTP和RTCP配合使用，它們能以有效的反饋和最小的開銷使傳輸效率最佳化，因而特別適合傳送網(wǎng)上的實(shí)時數(shù)據(jù)。

從圖?1可以看到，RTCP也是用UDP來傳送的，但RTCP封裝的僅僅是一些控制信息，因而分組很短，所以可以將多個RTCP分組封裝在一個UDP包中。RTCP有如下五種分組

表?1 RTCP的5種分組類型

上述五種分組的封裝大同小異，下面只講述SR類型，而其它類型請參考RFC3550。

發(fā)送端報告分組SR（Sender Report）用來使發(fā)送端以多播方式向所有接收端報告發(fā)送情況。SR分組的主要內(nèi)容有：相應(yīng)的RTP流的SSRC，RTP流中最新產(chǎn)生的RTP分組的時間戳和NTP，RTP流包含的分組數(shù)，RTP流包含的字節(jié)數(shù)。SR包的封裝如圖3所示。

圖?3 RTCP頭部的格式

版本（V）：同RTP包頭域。

填充（P）：同RTP包頭域。

接收報告計數(shù)器（RC）：5比特，該SR包中的接收報告塊的數(shù)目，可以為零。

包類型（PT）：8比特，SR包是200。

長度域（Length）：16比特，其中存放的是該SR包以32比特為單位的總長度減一。

同步源（SSRC）：SR包發(fā)送者的同步源標(biāo)識符。與對應(yīng)RTP包中的SSRC一樣。

NTP Timestamp（Network time protocol）SR包發(fā)送時的絕對時間值。NTP的作用是同步不同的RTP媒體流。

RTP Timestamp：與NTP時間戳對應(yīng)，與RTP數(shù)據(jù)包中的RTP時間戳具有相同的單位和隨機(jī)初始值。

Sender’s packetcount：從開始發(fā)送包到產(chǎn)生這個SR包這段時間里，發(fā)送者發(fā)送的RTP數(shù)據(jù)包的總數(shù). SSRC改變時，這個域清零。

Sender`s octet count：從開始發(fā)送包到產(chǎn)生這個SR包這段時間里，發(fā)送者發(fā)送的凈荷數(shù)據(jù)的總字節(jié)數(shù)（不包括頭部和填充）。發(fā)送者改變其SSRC時，這個域要清零。

同步源n的SSRC標(biāo)識符：該報告塊中包含的是從該源接收到的包的統(tǒng)計信息。

丟失率（Fraction Lost）：表明從上一個SR或RR包發(fā)出以來從同步源n(SSRC_n)來的RTP數(shù)據(jù)包的丟失率。

累計的包丟失數(shù)目：從開始接收到SSRC_n的包到發(fā)送SR,從SSRC_n傳過來的RTP數(shù)據(jù)包的丟失總數(shù)。

收到的擴(kuò)展最大序列號：從SSRC_n收到的RTP數(shù)據(jù)包中最大的序列號，

接收抖動（Interarrival jitter）：RTP數(shù)據(jù)包接受時間的統(tǒng)計方差估計

上次SR時間戳（Last SR,LSR）：取最近從SSRC_n收到的SR包中的NTP時間戳的中間32比特。如果目前還沒收到SR包，則該域清零。

上次SR以來的延時（Delay since last SR,DLSR）：上次從SSRC_n收到SR包到發(fā)送本報告的延時。

2.4.? RTP的會話過程

當(dāng)應(yīng)用程序建立一個RTP會話時，應(yīng)用程序?qū)⒋_定一對目的傳輸?shù)刂?。目的傳輸?shù)刂酚梢粋€網(wǎng)絡(luò)地址和一對端口組成，有兩個端口：一個給RTP包，一個給RTCP包，使得RTP/RTCP數(shù)據(jù)能夠正確發(fā)送。RTP數(shù)據(jù)發(fā)向偶數(shù)的UDP端口，而對應(yīng)的控制信號RTCP數(shù)據(jù)發(fā)向相鄰的奇數(shù)UDP端口（偶數(shù)的UDP端口＋1），這樣就構(gòu)成一個UDP端口對。?RTP的發(fā)送過程如下，接收過程則相反。

1)RTP協(xié)議從上層接收流媒體信息碼流（如H.263），封裝成RTP數(shù)據(jù)包；RTCP從上層接收控制信息，封裝成RTCP控制包。

2)RTP將RTP?數(shù)據(jù)包發(fā)往UDP端口對中偶數(shù)端口；RTCP將RTCP控制包發(fā)往UDP端口對中的接收端口。

?

二、??????????TCP協(xié)議分析

1、?TCP協(xié)議簡介

TCP，全稱TransferControl Protocol，中文名為傳輸控制協(xié)議，它工作在OSI的傳輸層，提供面向連接的可靠傳輸服務(wù)。

TCP的工作主要是建立連接，然后從應(yīng)用層程序中接收數(shù)據(jù)并進(jìn)行傳輸。TCP采用虛電路連接方式進(jìn)行工作，在發(fā)送數(shù)據(jù)前它需要在發(fā)送方和接收方建立一個連接，數(shù)據(jù)在發(fā)送出去后，發(fā)送方會等待接收方給出一個確認(rèn)性的應(yīng)答，否則發(fā)送方將認(rèn)為此數(shù)據(jù)丟失，并重新發(fā)送此數(shù)據(jù)。

2、TCP報頭

TCP報頭總長最小為20個字節(jié)，其報頭結(jié)構(gòu)如下圖（圖1）所示；

源端口：指定了發(fā)送端的端口

目的端口：指定了接受端的端口號

序號：指明了段在即將傳輸?shù)亩涡蛄兄械奈恢?/p>

確認(rèn)號：規(guī)定成功收到段的序列號，確認(rèn)序號包含發(fā)送確認(rèn)的一端所期望收到的下一個序號

TCP偏移量：指定了段頭的長度。段頭的長度取決與段頭選項(xiàng)字段中設(shè)置的選項(xiàng)

保留：指定了一個保留字段，以備將來使用

標(biāo)志：SYN、ACK、PSH、RST、URG、FIN

????? SYN：?表示同步

????? ACK：表示確認(rèn)

????? PSH：表示盡快的將數(shù)據(jù)送往接收進(jìn)程

????? RST：表示復(fù)位連接

????? URG：表示緊急指針

?? ???FIN：表示發(fā)送方完成數(shù)據(jù)發(fā)送

窗口：指定關(guān)于發(fā)送端能傳輸?shù)南乱欢蔚拇笮〉闹噶?/p>

校驗(yàn)和：校驗(yàn)和包含TCP段頭和數(shù)據(jù)部分，用來校驗(yàn)段頭和數(shù)據(jù)部分的可靠性

緊急：指明段中包含緊急信息，只有當(dāng)U R G標(biāo)志置1時緊急指針才有效

選項(xiàng)：指定了公認(rèn)的段大小，時間戳，選項(xiàng)字段的末端，以及指定了選項(xiàng)字段的邊界選項(xiàng)

3、TCP工作原理

TCP連接建立：TCP的連接建立過程又稱為TCP三次握手。首先發(fā)送方主機(jī)向接收方主機(jī)發(fā)起一個建立連接的同步（SYN）請求；接收方主機(jī)在收到這個請求后向送方主機(jī)回復(fù)一個同步/確認(rèn)（SYN/ACK）應(yīng)答；發(fā)送方主機(jī)收到此包后再向接收方主機(jī)發(fā)送一個確認(rèn)（ACK），此時TCP連接成功建立；

TCP連接關(guān)閉：發(fā)送方主機(jī)和目的主機(jī)建立TCP連接并完成數(shù)據(jù)傳輸后，會發(fā)送一個將結(jié)束標(biāo)記置1的數(shù)據(jù)包，以關(guān)閉這個TCP連接，并同時釋放該連接占用的緩沖區(qū)空間；??? TCP重置：TCP允許在傳輸?shù)倪^程中突然中斷連接，這稱為TCP重置；

TCP數(shù)據(jù)排序和確認(rèn)：TCP是一種可靠傳輸?shù)膮f(xié)議，它在傳輸?shù)倪^程中使用序列號和確認(rèn)號來跟蹤數(shù)據(jù)的接收情況；

TCP重傳：在TCP的傳輸過程中，如果在重傳超時時間內(nèi)沒有收到接收方主機(jī)對某數(shù)據(jù)包的確認(rèn)回復(fù)，發(fā)送方主機(jī)就認(rèn)為此數(shù)據(jù)包丟失，并再次發(fā)送這個數(shù)據(jù)包給接收方，這稱為TCP重傳；

TCP延遲確認(rèn)：TCP并不總是在接收到數(shù)據(jù)后立即對其進(jìn)行確認(rèn)，它允許主機(jī)在接收數(shù)據(jù)的同時發(fā)送自己的確認(rèn)信息給對方。

TCP數(shù)據(jù)保護(hù)（校驗(yàn)和）：TCP是可靠傳輸?shù)膮f(xié)議，它提供校驗(yàn)和計算來實(shí)現(xiàn)數(shù)據(jù)在傳輸過程中的完整性。

?

三、??????????UDP協(xié)議分析

?1、UDP簡介

UDP協(xié)議是英文UserDatagramProtocol的縮寫，即用戶數(shù)據(jù)報協(xié)議，主要用來支持那些需要在計算機(jī)之間傳輸數(shù)據(jù)的網(wǎng)絡(luò)應(yīng)用。包括網(wǎng)絡(luò)視頻會議系統(tǒng)在內(nèi)的眾多的客戶/服務(wù)器模式的網(wǎng)絡(luò)應(yīng)用都需要使用UDP協(xié)議。UDP協(xié)議從問世至今已經(jīng)被使用了很多年，雖然其最初的光彩已經(jīng)被一些類似協(xié)議所掩蓋，但是即使是在今天，UDP仍然不失為一項(xiàng)非常實(shí)用和可行的網(wǎng)絡(luò)傳輸層協(xié)議。?
????與我們所熟知的TCP（傳輸控制協(xié)議）協(xié)議一樣，UDP協(xié)議直接位于IP（網(wǎng)際協(xié)議）協(xié)議的頂層。根據(jù)OSI（開放系統(tǒng)互連）參考模型，UDP和TCP都屬于傳輸層協(xié)議。?
??? UDP協(xié)議的主要作用是將網(wǎng)絡(luò)數(shù)據(jù)流量壓縮成數(shù)據(jù)報的形式。一個典型的數(shù)據(jù)報就是一個二進(jìn)制數(shù)據(jù)的傳輸單位。每一個數(shù)據(jù)報的前8個字節(jié)用來包含報頭信息，剩余字節(jié)則用來包含具體的傳輸數(shù)據(jù)。?
2、UDP協(xié)議結(jié)構(gòu)
??? UDP報頭由4個域組成，其中每個域各占用2個字節(jié)，具體如下：?
源端口號、目標(biāo)端口號、數(shù)據(jù)報長度和校驗(yàn)值。
??? UDP協(xié)議使用端口號為不同的應(yīng)用保留其各自的數(shù)據(jù)傳輸通道。UDP和TCP協(xié)議正是采用這一機(jī)制實(shí)現(xiàn)對同一時刻內(nèi)多項(xiàng)應(yīng)用同時發(fā)送和接收數(shù)據(jù)的支持。數(shù)據(jù)發(fā)送一方（可以是客戶端或服務(wù)器端）將UDP數(shù)據(jù)報通過源端口發(fā)送出去，而數(shù)據(jù)接收一方則通過目標(biāo)端口接收數(shù)據(jù)。有的網(wǎng)絡(luò)應(yīng)用只能使用預(yù)先為其預(yù)留或注冊的靜態(tài)端口；而另外一些網(wǎng)絡(luò)應(yīng)用則可以使用未被注冊的動態(tài)端口。因?yàn)閁DP報頭使用兩個字節(jié)存放端口號，所以端口號的有效范圍是從0到65535。一般來說，大于49151的端口號都代表動態(tài)端口。?
????數(shù)據(jù)報的長度是指包括報頭和數(shù)據(jù)部分在內(nèi)的總的字節(jié)數(shù)。因?yàn)閳箢^的長度是固定的，所以該域主要被用來計算可變長度的數(shù)據(jù)部分（又稱為數(shù)據(jù)負(fù)載）。數(shù)據(jù)報的最大長度根據(jù)操作環(huán)境的不同而各異。從理論上說，包含報頭在內(nèi)的數(shù)據(jù)報的最大長度為65535字節(jié)。不過，一些實(shí)際應(yīng)用往往會限制數(shù)據(jù)報的大小，有時會降低到8192字節(jié)。
?? ?UDP協(xié)議使用報頭中的校驗(yàn)值來保證數(shù)據(jù)的安全。校驗(yàn)值首先在數(shù)據(jù)發(fā)送方通過特殊的算法計算得出，在傳遞到接收方之后，還需要再重新計算。如果某個數(shù)據(jù)報在傳輸過程中被第三方篡改或者由于線路噪音等原因受到損壞，發(fā)送和接收方的校驗(yàn)計算值將不會相符，由此UDP協(xié)議可以檢測是否出錯。這與TCP協(xié)議是不同的，后者要求必須具有校驗(yàn)值。

四、三種協(xié)議對比

RTP位于UDP之上，UDP雖然沒有TCP那么可靠，并且無法保證實(shí)時業(yè)務(wù)的服務(wù)質(zhì)量，需要RTCP實(shí)時監(jiān)控數(shù)據(jù)傳輸和服務(wù)質(zhì)量，但是，由于UDP的傳輸時延低于TCP，能與視頻和音頻很好匹配。因此，在實(shí)際應(yīng)用中，RTP/RTCP/UDP用于音頻/視頻媒體，而TCP用于數(shù)據(jù)和控制信令的傳輸。

UDP和TCP協(xié)議的主要區(qū)別是兩者在如何實(shí)現(xiàn)信息的可靠傳遞方面不同。TCP協(xié)議中包含了專門的傳遞保證機(jī)制，當(dāng)數(shù)據(jù)接收方收到發(fā)送方傳來的信息時，會自動向發(fā)送方發(fā)出確認(rèn)消息；發(fā)送方只有在接收到該確認(rèn)消息之后才繼續(xù)傳送其它信息，否則將一直等待直到收到確認(rèn)信息為止。

所以TCP必UDP多了建立連接的時間。相對UDP而言，TCP具有更高的安全性和可靠性。TCP協(xié)議傳輸?shù)拇笮〔幌拗?，一旦連接被建立，雙方可以按照一定的格式傳輸大量的數(shù)據(jù)，而UDP是一個不可靠的協(xié)議，大小有限制，每次不能超過64K。

相對于TCP協(xié)議，UDP協(xié)議的另外一個不同之處在于如何接收突法性的多個數(shù)據(jù)報。不同于TCP，UDP并不能確保數(shù)據(jù)的發(fā)送和接收順序。

三者的性能對比見表1。

?

表1?三種協(xié)議的性能對比