UDP協(xié)議是英文UserDatagramProtocol的縮寫，即用戶數(shù)據(jù)報協(xié)議，主要用來支持那些需要在計算機之間傳輸數(shù)據(jù)的網(wǎng)絡應用。包括網(wǎng)絡視頻會議系統(tǒng)在內的眾多的客戶/服務器模式的網(wǎng)絡應用都需要使用UDP協(xié)議。UDP協(xié)議從問世至今已經被使用了很多年，雖然其最初的光彩已經被一些類似協(xié)議所掩蓋，但是即使是在今天，UDP仍然不失為一項非常實用和可行的網(wǎng)絡傳輸層協(xié)議。
與我們所熟知的TCP（傳輸控制協(xié)議）協(xié)議一樣，UDP協(xié)議直接位于IP（網(wǎng)際協(xié)議）協(xié)議的頂層。根據(jù)OSI（開放系統(tǒng)互連）參考模型，UDP和TCP都屬于傳輸層協(xié)議。
UDP協(xié)議的主要作用是將網(wǎng)絡數(shù)據(jù)流量壓縮成數(shù)據(jù)報的形式。一個典型的數(shù)據(jù)報就是一個二進制數(shù)據(jù)的傳輸單位。每一個數(shù)據(jù)報的前8個字節(jié)用來包含報頭信息，剩余字節(jié)則用來包含具體的傳輸數(shù)據(jù)。
UDP報頭
UDP報頭由4個域組成，其中每個域各占用2個字節(jié)，具體如下：
源端口號
目標端口號
數(shù)據(jù)報長度
校驗值
UDP協(xié)議使用端口號為不同的應用保留其各自的數(shù)據(jù)傳輸通道。UDP和TCP協(xié)議正是采用這一機制實現(xiàn)對同一時刻內多項應用同時發(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ù)部分在內的總的字節(jié)數(shù)。因為報頭的長度是固定的，所以該域主要被用來計算可變長度的數(shù)據(jù)部分（又稱為數(shù)據(jù)負載）。數(shù)據(jù)報的最大長度根據(jù)操作環(huán)境的不同而各異。從理論上說，包含報頭在內的數(shù)據(jù)報的最大長度為65535字節(jié)。不過，一些實際應用往往會限制數(shù)據(jù)報的大小，有時會降低到8192字節(jié)。
UDP協(xié)議使用報頭中的校驗值來保證數(shù)據(jù)的安全。校驗值首先在數(shù)據(jù)發(fā)送方通過特殊的算法計算得出，在傳遞到接收方之后，還需要再重新計算。如果某個數(shù)據(jù)報在傳輸過程中被第三方篡改或者由于線路噪音等原因受到損壞，發(fā)送和接收方的校驗計算值將不會相符，由此UDP協(xié)議可以檢測是否出錯。這與TCP協(xié)議是不同的，后者要求必須具有校驗值。
UDPvs.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é)議的另外一個不同之處在于如何接收突法性的多個數(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ā)布。盡管時間已經很長，但是UDP協(xié)議仍然繼續(xù)在主流應用中發(fā)揮著作用。包括視頻電話會議系統(tǒng)在內的許多應用都證明了UDP協(xié)議的存在價值。因為相對于可靠性來說，這些應用更加注重實際性能，所以為了獲得更好的使用效果（例如，更高的畫面幀刷新速率）往往可以犧牲一定的可靠性（例如，會面質量）。這就是UDP和TCP兩種協(xié)議的權衡之處。根據(jù)不同的環(huán)境和特點，兩種傳輸協(xié)議都將在今后的網(wǎng)絡世界中發(fā)揮更加重要的作用。
下面我就UDP做一個示例程序。整個例子有兩個程序組成，一個發(fā)送數(shù)據(jù)，另一個程序接收數(shù)據(jù)后，完成繪圖工作。
本文程序運行效果圖如下:
一、發(fā)送程序
首先建立數(shù)據(jù)發(fā)送程序（Fason）。一共發(fā)送四個數(shù)據(jù)：圓心的X坐標、圓心的Y坐標、圓半徑R、圓的顏色。它的實現(xiàn)主要如下： void CFasonDlg::OnSend()
{
UpdateData(TRUE);
CString m_Getstring;
this->m_Cob.GetLBText(m_Cob.GetCurSel(),m_Getstring);
if(m_Getstring==_T("Red"))
yuan1.color=1;
if(m_Getstring==_T("Green"))
yuan1.color=2;
if(m_Getstring==_T("Blue"))
yuan1.color=3;
yuan1.x=m_x;
yuan1.y=m_y;
yuan1.r=m_r;
p=&yuan1;
CDSocket m_hSocket;
m_hSocket.Create(2330,SOCK_DGRAM);
m_hSocket.SendTo( p,sizeof(yuan1),3550,"127.0.0.1");//用結構體發(fā)送。
m_x=0;
m_y=0;
m_r=0;
m_hSocket.Close();
UpdateData(FALSE);
}發(fā)送數(shù)據(jù)時有一個技巧，就是所有數(shù)據(jù)放在一個結構體中來發(fā)送，不用一個一個發(fā)送。但是不能在結構體中包含CString等可以變長的數(shù)據(jù)類型。
二、接收程序
下面我們看一下接收數(shù)據(jù)端的程序（Jieshou）。如下： void CDASocket::OnReceive(int nErrorCode)
{
char buff[256];
int ret=0;
ret=Receive(buff,256);
if(ret==ERROR)
{
TRACE("ERROR!");
}
else
m_pDoc->Presscessding(buff);
class CAsyncSocket::OnReceive(nErrorCode);
}三、數(shù)據(jù)處理與顯示
我們設計程序時，數(shù)據(jù)通常在文檔中處理，顯示工作在視圖中完成。當整個程序較小時，這感覺不到有何好處，但整個程序較大時，程序的條理就會較清晰，易讀性好。所以一定要時時養(yǎng)成良好的設計習慣。數(shù)據(jù)在文檔中處理如下：void
CJieshouDoc::Presscessding(char* lbuff)
{
buff=(struct yuan*)lbuff;
p.x=buff->x;
p.y=buff->y;
p.r=buff->r;
p.color=buff->color;
UpdateAllViews(NULL);
}在視圖中的顯示如下： void CJieshouView::OnDraw(CDC* pDC)
{
CJieshouDoc* pDoc = GetDocument();
ASSERT_VALID(pDoc);
x=pDoc->p.x;
y=pDoc->p.y;
r=pDoc->p.r;
if(pDoc->p.color==1)
pDC->SelectObject(new CBrush(RGB(255,0,0)));
if(pDoc->p.color==2)
pDC->SelectObject(new CBrush(RGB(0,255,0)));
if(pDoc->p.color==3)
pDC->SelectObject(new CBrush(RGB(0,0,255)));
pDC->Ellipse(x-r,y-r,x+r,y+r);
