UDP協(xié)議的全稱是用戶數(shù)據(jù)報,在網(wǎng)絡中它與TCP協(xié)議一樣用于處理數(shù)據(jù)包。在OSI模型中,在第四層——傳輸層,處于IP協(xié)議的上一層。UDP有不提供數(shù)據(jù)報分組、組裝和不能對數(shù)據(jù)包的排序的缺點,也就是說,當報文發(fā)送之后,是無法得知其是否安全完整到達的。
UDP用來支持那些需要在計算機之間傳輸數(shù)據(jù)的網(wǎng)絡應用。包括網(wǎng)絡視頻會以系統(tǒng)在內(nèi)的眾多的客戶/服務器模式的網(wǎng)絡應用都需要使用UDP協(xié)議。UDP協(xié)議從問世至今已經(jīng)被使用了很多年,雖然其最初的光彩已經(jīng)被一些類似協(xié)議所掩蓋,但是即使是在今天,UDP仍然不失為一項非常實用和可行的網(wǎng)絡傳輸層協(xié)議。
UDP協(xié)議的主要作用是將網(wǎng)絡數(shù)據(jù)流量壓縮成數(shù)據(jù)包的形式。一個典型的數(shù)據(jù)包就是一個二進制數(shù)據(jù)的傳輸單位。每一個數(shù)據(jù)包的前8個字節(jié)用來包含報頭信息,剩余字節(jié)則用來包含具體的傳輸數(shù)據(jù)。
UDP的特性:它不屬于連接型協(xié)議,因而具有資源消耗小,處理速度快的優(yōu)點,所以通常音頻、視頻和普通數(shù)據(jù)在傳送時使用UDP較多,因為它們即使偶爾丟失一兩個數(shù)據(jù)包,也不會對接 收結果產(chǎn)生太大影響。比如我們聊天用的ICQ和QQ就是使用的UDP協(xié)議。
UDP報頭由4個域組成,其中每個域各占用2個字節(jié),具體如下: 源端口號 目標端口號 數(shù)據(jù)報長度 校驗值
UDP協(xié)議使用端口號為不同的應用保留其各自的數(shù)據(jù)傳輸通道。UDP和TCP協(xié)議正是采用這一機制實現(xiàn)對同一時刻內(nèi)多項應用同時發(fā)送和接收數(shù)據(jù)的支持。數(shù)據(jù)發(fā)送一方(可以是客戶端或服務器端)將UDP數(shù)據(jù)報通過源端口發(fā)送出去,而數(shù)據(jù)接收一方則通過目標端口接收數(shù)據(jù)。有的網(wǎng)絡應用只能使用預先為其預留或注冊的靜態(tài)端口;而另外一些網(wǎng)絡應用則可以使用未被注冊的動態(tài)端口。因為UDP報頭使用兩個字節(jié)存放端口號,所以端口號的有效范圍是從0到65535。一般來說,大于49151的端口號都代表動態(tài)端口。
數(shù)據(jù)報的長度是指包括報頭和數(shù)據(jù)部分在內(nèi)的總字節(jié)數(shù)。因為報頭的長度是固定的,所以該域主要被 用來計算可變長度的數(shù)據(jù)部分(又稱為數(shù)據(jù)負載)。數(shù)據(jù)報的最大長度根據(jù)操作環(huán)境的不同而各異。從理論上說,包含報頭在內(nèi)的數(shù)據(jù)報的最大長度為65535字 節(jié)。不過,一些實際應用往往會限制數(shù)據(jù)報的大小,有時會降低到8192字節(jié)。
UDP協(xié)議使用報頭中的校驗值來保證數(shù)據(jù)的安全。校驗值首先在數(shù)據(jù)發(fā)送方通過特殊的算法計算得 出,在傳遞到接收方之后,還需要再重新計算。如果某個數(shù)據(jù)報在傳輸過程中被第三方篡改或者由于線路噪音等原因受到損壞,發(fā)送和接收方的校驗計算值將不會相符,由此UDP協(xié)議可以檢測是否出錯。這與TCP協(xié)議是不同的,后者要求必須具有校驗值。
許多鏈路層協(xié)議都提供錯誤檢查,包括流行的以太網(wǎng)協(xié)議,也許想知道為什么UDP也要提供檢查,其原因是鏈路層以下的協(xié)議在源端和終端間的某些通道可能不提供錯誤檢測。雖然UDP提供有錯誤檢測,但檢測到錯誤時,UDP不做錯誤校正,只是簡單地把損壞的消息段扔掉,或者給應用程序提供警告信息。
UDP協(xié)議的幾個特性
。1) UDP是一個無連接協(xié)議,傳輸數(shù)據(jù)之前源端和終端不建立連接,當UDP它想傳送時就簡單地去抓取來自應用程序的數(shù)據(jù),并盡可能快地把它扔到網(wǎng)絡上。在發(fā)送端,UDP傳送數(shù)據(jù)的速度僅僅是受應用程序生成數(shù)據(jù)的速度、計算機的能力和傳輸帶寬的限制;在接收端,UDP把每個消息段放在隊列中,應用程序每次從隊列中讀一個消息段。
(2) 由于傳輸數(shù)據(jù)不建立連接,因此也就不需要維護連接狀態(tài),包括收發(fā)狀態(tài)等,因此一臺服務機可同時向多個客戶機傳輸相同的消息。
。3) UDP信息包的標題很短,只有8個字節(jié),相對于TCP的20個字節(jié)信息包的額外開銷很小。
(4) 吞吐量不受擁擠控制算法的調(diào)節(jié),只受應用程序生產(chǎn)數(shù)據(jù)的速率、傳輸帶寬、源端和終端主機性能的限制。
(5)UDP使用盡最大努力交付,即不保證可靠交付,因此主機不需要維持復雜的鏈接狀態(tài)表(這里面有許多參數(shù))。
(6)UDP是面向報文的。發(fā)送方的UDP對應用程序交下來的報文,在添加首部后就向下交付給IP層。既不拆分,也不合并,而是保留這些報文的邊界,因此,應用程序需要選擇合適的報文大小。
雖然UDP是一個不可靠的協(xié)議,但它是分發(fā)信息的一個理想?yún)f(xié)議。例如,在屏幕上報告股票市場、在屏幕上顯示航空信息等等。UDP也用在路由信息協(xié)議RIP(Routing
Information Protocol)中修改路由表。在這些應用場合下,如果有一個消息丟失,在幾秒之后另一個新的消息就會替換它。UDP廣泛用在多媒體應用中,例如,Progressive Networks公司開發(fā)的RealAudio軟件,它是在因特網(wǎng)上把預先錄制的或者現(xiàn)場音樂實時傳送給客戶機的一種軟件,該軟件使用的RealAudio audio-on-demand
protocol協(xié)議就是運行在UDP之上的協(xié)議,大多數(shù)因特網(wǎng)電話軟件產(chǎn)品也都運行在UDP之上。
UDP vs TCP
UDP和TCP協(xié)議的主要區(qū)別是兩者在如何實現(xiàn)信息的可靠傳遞方面不同。
TCP 協(xié)議中包含了專門的傳遞保證機制,當數(shù)據(jù)接收方收到發(fā)送方傳來的信息時,會自動向發(fā)送方發(fā)出確認消息;發(fā)送方只有在接收到該確認消息之后才繼續(xù)傳送其它信息,否則將一直等待直到收到確認信息為止。
與TCP不同,UDP協(xié)議并不提供數(shù)據(jù)傳送的保證機制。如果在從發(fā)送方到接收方的傳遞過程中出現(xiàn)數(shù)據(jù)報的丟失,協(xié)議本身并不能做出任何檢測或提示。因此,
通常人們把UDP協(xié)議稱為不可靠的傳輸協(xié)議。
相對于TCP協(xié)議,UDP協(xié)議的另外一個不同之處在于如何接收突發(fā)性的多個數(shù)據(jù)報。不同于TCP,UDP并不能確保數(shù)據(jù)的發(fā)送和接收順序。例如,一個位于客戶端的應用程序向服務器發(fā)出了以下4個數(shù)據(jù)報
D1
D22
D333
D4444
但是UDP有可能按照以下順序將所接收的數(shù)據(jù)提交到服務端的應用:
D333
D1
D4444
D22
事實上,UDP協(xié)議的這種亂序性基本上很少出現(xiàn),通常只會在網(wǎng)絡非常擁擠的情況下才有可能發(fā)生。
UDP協(xié)議的應用
既然UDP是一種不可靠的網(wǎng)絡協(xié)議,那么還有什么使用價值或必要呢?其實不然,在有些情況下UDP協(xié)議可能會變得非常有用。因為UDP具有TCP所望塵莫及的速度優(yōu)勢。雖然TCP協(xié)議中植入了各種安全保障功能,但是在實際執(zhí)行的過程中會占用大量的系統(tǒng)開銷,無疑使速度受到嚴重的影響。反觀UDP由于排除了信息可靠傳遞機制,將安全和排序等功能移交給上層應用來完成,極大降低了執(zhí)行時間,使速度得到了保證。
關于UDP協(xié)議的最早規(guī)范是RFC768,1980年發(fā)布。盡管時間已經(jīng)很長,但是UDP協(xié)議仍然繼續(xù)在主流應用中發(fā)揮著作用。包括視頻電話會議系統(tǒng)在內(nèi)的許多應用都證明了UDP協(xié)議的存在價值。因為相對于可靠性來說,這些應用更加注重實際性能,所以為了獲得更好的使用效果(例如,更高的畫面幀刷新速
率)往往可以犧牲一定的可靠性(例如,畫面質量)。這就是UDP和TCP兩種協(xié)議的權衡之處。根據(jù)不同的環(huán)境和特點,兩種傳輸協(xié)議都將在今后的網(wǎng)絡世界中
發(fā)揮更加重要的作用。
|