udp協(xié)議范文第1篇
關(guān)鍵詞:用戶數(shù)據(jù)報(bào)協(xié)議;通信;報(bào)文分析;Sniffer
中圖分類號(hào):TP312 文獻(xiàn)標(biāo)識(shí)碼:A 文章編號(hào):1009-3044(2010)13-3319-02
Use UDP Protocol and Analysis
LIU Peng1, LIU Yan2
(puter Science and Information Engineering College, Guangxi Normal University, Guilin 541004, China; 2.Affiliated Hospital of Guilin Medical University,The Office of Teaching Management, Guilin 541001, China)
Abstract: UDP protocol is a compact, highly efficient protocol has been widely used. The method of how to design communication program with UDP protocol in windows operating system was introduced. Then test communication with the introduced program. The captured packets by Sniffer in communication experimental were analyzed in detail to verify the network model and the network communication program, summed up the advantages and disadvantages of UDP protocol.
Key words: UDP; communication; packet analysis; sniffer
UDP是User Datagram Protocol的簡稱,是TCP/IP體系結(jié)構(gòu)中一種無連接的傳輸層協(xié)議,提供面向事務(wù)的簡單不可靠信息傳送服務(wù)。UDP 協(xié)議是 IP 協(xié)議與上層協(xié)議的接口,用端口號(hào)分別為運(yùn)行在同一設(shè)備上的多個(gè)應(yīng)用程序提供服務(wù)。它定義在IETF RFC 768中[1]。
UDP是分發(fā)信息的理想?yún)f(xié)議,適用于追求效率且不需要額外可靠機(jī)制的情形,如音、視頻流媒體分發(fā)、高層協(xié)議或應(yīng)用程序提供錯(cuò)誤和流控制功能時(shí)的快速數(shù)據(jù)分發(fā)。 UDP服務(wù)于很多知名應(yīng)用,如網(wǎng)絡(luò)文件系統(tǒng)(NFS)、簡單網(wǎng)絡(luò)管理協(xié)議(SNMP)、域名系統(tǒng)(DNS)以及簡單文件傳輸系統(tǒng)(TFTP)、動(dòng)態(tài)主機(jī)配置協(xié)議(DHCP)、路由信息協(xié)議(RIP)等。
1 UDP協(xié)議使用
在Windows下使用UDP不需要實(shí)現(xiàn)RFC 768中定義的UDP細(xì)節(jié),封閉的Windows操作系統(tǒng)為用戶實(shí)現(xiàn)了協(xié)議,以動(dòng)態(tài)鏈接庫及API的形式提供給用戶程序調(diào)用。這種方式方便了程序設(shè)計(jì),但也阻止了用戶對(duì)網(wǎng)絡(luò)協(xié)議的更深理解。為了更加深入研究UDP有必要對(duì)傳輸報(bào)文流進(jìn)行分析;為了更好的分析,需要實(shí)現(xiàn)一個(gè)使用UDP的通信程序。
在windows下選用VC6.0編譯器。服務(wù)器端代碼如下:
#include //基本輸入輸出庫
#include //網(wǎng)絡(luò)API函數(shù)庫
#pragma comment (lib,"WS2_32.lib")/*將WS2_32.lib加入鏈接,不用再為這個(gè)鏈接文件設(shè)置鏈接選項(xiàng)了*/
void main()
{ WORD wVersionRequested;
WSADATA wsaData;
int err;
wVersionRequested = MAKEWORD( 1, 1 );
err = WSAStartup( wVersionRequested, &wsaData );
if ( err != 0 ) {
return; /* 處理找不到 WinSock DLL.*/}
/* 確認(rèn) WinSock DLL 支持的版本 */
if ( LOBYTE( wsaData.wVersion ) != 1 ||HIBYTE( wsaData.wVersion ) != 1 ) {
WSACleanup( ); return;
}/* [3]以上代碼為MSDN提供的設(shè)計(jì)windows下網(wǎng)絡(luò)程序的標(biāo)準(zhǔn)方法*/
SOCKET sockSrv=socket(AF_INET,SOCK_DGRAM,0);/*AF_INET因特網(wǎng)地址族UDP, TCP, 等.SOCK_DGRAM 基于upd的套接字。*/
SOCKADDR_IN addrSrv;
addrSrv.sin_addr.S_un.S_addr=htonl(INADDR_ANY);/*htonl主機(jī)字節(jié)序變?yōu)榫W(wǎng)絡(luò)字節(jié)序*/
addrSrv.sin_family=AF_INET;
addrSrv.sin_port=htons(6666);
err=bind(sockSrv,(SOCKADDR *)&addrSrv,sizeof(SOCKADDR)); /*綁定主機(jī)從6666端口接受數(shù)據(jù)*/
if ( err != 0 ) {
return; /* 處理幫定異常*/
} SOCKADDR_IN addrClient;
int len=sizeof(sockaddr);
char recvBuff[200];//接收緩存
char sendBuff[200];//發(fā)送緩存
char tempBuff[200];//暫時(shí)緩存
while (1){
recvfrom(sockSrv,recvBuff,200,0,(SOCKADDR*)&addrClient,&len); //接收數(shù)據(jù)
if('E'==recvBuff[0])
{sendto(sockSrv,"E",strlen("E"),0,(SOCKADDR*)&addrClient,len); //發(fā)送數(shù)據(jù)
printf("Communications end/n");
break;
}sprintf(tempBuff,"Recieve From IP %s :%s ",inet_ntoa(addrClient.sin_addr),recvBuff); //格式化
printf("%s/n",tempBuff);
printf("Please input data send to IP %s :/n ",inet_ntoa(addrClient.sin_addr));
gets(sendBuff);
sendto(sockSrv,sendBuff,strlen(sendBuff)+1,0,(SOCKADDR*)&addrClient,len);
}closesocket(sockSrv);
WSACleanup();
}客戶端程序頭文件及socket初始化和服務(wù)器端一樣,不同的是socket函數(shù)的使用。
//頭文件和服務(wù)器端一樣
void main()
{…
//初始化和服務(wù)器端一樣
/* 以上代碼為MSDN提供的設(shè)計(jì)windows下網(wǎng)絡(luò)程序的標(biāo)準(zhǔn)方法,*/
SOCKET sockCleit=socket(AF_INET,SOCK_DGRAM,0);//SOCK_DGRAM 基于upd的套接字
SOCKADDR_IN addrSrv;
addrSrv.sin_addr.S_un.S_addr=inet_addr("192.168.1.103");/*設(shè)置目標(biāo)地址,根據(jù)服務(wù)器端情況*/
addrSrv.sin_family=AF_INET;
addrSrv.sin_port=htons(6666);//與服務(wù)器端一致
char recvBuff[200];//接收緩存
char sendBuff[200];//發(fā)送緩存
char tempBuff[200];//暫時(shí)緩存
int len=sizeof(SOCKADDR);
while (1)
{printf("Please input data send to IP %s :/n",inet_ntoa(addrSrv.sin_addr));
gets(sendBuff);
sendto(sockCleit,sendBuff,strlen(sendBuff)+1,0,(SOCKADDR*)&addrSrv,len);//發(fā)送
recvfrom(sockCleit,recvBuff,200,0,(SOCKADDR*)&addrSrv,&len);//接收
if('E'==recvBuff[0])
{sendto(sockCleit,"q",strlen("q"),0,(SOCKADDR*)&addrSrv,len);
printf("Communications end/n");
break;
}sprintf(tempBuff,"Recieve From IP %s :%s ",inet_ntoa(addrSrv.sin_addr),recvBuff);
printf("%s/n",tempBuff);
}closesocket(sockCleit);
WSACleanup();
}
以上代碼可使用VC6.0、VS2005、 VS2008等軟件編譯器。服務(wù)器端的網(wǎng)絡(luò)地址為192.168.1.102。客戶端不限,只要和服務(wù)間路由可達(dá)即可,本例中使用192.168.1.100。如不想更改服務(wù)器端IP地址,只要按照程序注釋,根據(jù)實(shí)際情況更改客戶程序的addrSrv.sin_addr.S_un.S_addr變量即可。
2 報(bào)文捕獲與分析
圖1為客戶端IP192.168.1.100向服務(wù)器端IP192.168.1.103發(fā)出數(shù)據(jù)“test”后,由服務(wù)器端的sniffer捕獲的報(bào)文。
UDP報(bào)文為灰色開始的0c 96 1a 0a 00 0d 6d 3e 74 65 73 74 00共13字節(jié)。UDP前45開始到67為標(biāo)準(zhǔn)IP報(bào)文頭共20個(gè)字節(jié),報(bào)文開頭的00到08 00(IP報(bào)文頭前)14個(gè)字節(jié)為DLC(Data Link Control)報(bào)文頭。UDP報(bào)文中,0c 96源端口號(hào),兩字節(jié),客戶端用于接收信息的端口號(hào),不需要回復(fù)可用全零。1a 0a 目的端口號(hào),兩字節(jié),服務(wù)器端的接收端口號(hào)。00 0d 數(shù)據(jù)包長度,兩字節(jié),本示例為13。6d 3e 校驗(yàn)和,兩字節(jié)。74 65 73 74 00 數(shù)據(jù)包的內(nèi)容,74 65 73 74 為“test”的ASCII編碼,00通過源程序可以發(fā)現(xiàn),為了接收端處理方便多發(fā)的一個(gè)空字節(jié)。
圖2為服務(wù)器端103接收到“test”后,向客戶端發(fā)送“received test”數(shù)據(jù),由服務(wù)器端的sniffer軟件捕獲的報(bào)文。
UDP報(bào)文為灰色開始1a 0a 0c96 00 16 b6 78 72 65 63 65 69 76 65 64 20 74 65 73 74 00共22字節(jié)。1a 0a源端口號(hào),0b 96目的端口號(hào),與前一報(bào)文正好相反。00 16 數(shù)據(jù)包長度22字節(jié)。B6 78 校驗(yàn)和,72 65 63 65 69 76 65 64 20 74 65 73 74 00 是數(shù)據(jù)報(bào)的內(nèi)容,同樣多發(fā)了一個(gè)空字節(jié)。
由協(xié)議分析可知,UDP位于IP報(bào)文的數(shù)據(jù)域中,由源端口、目的端口、長度、校驗(yàn)和、和數(shù)據(jù)域組成,采用明文傳遞應(yīng)用數(shù)據(jù)。如果傳遞重要信息一定要在應(yīng)用層加密,否則很容易被竊取。UDP在發(fā)送數(shù)據(jù)時(shí)附帶自身的端口號(hào),接收時(shí)不需要確認(rèn),所以可以方便的進(jìn)行一對(duì)一、一對(duì)多和多對(duì)多的交互通信,這種方式方便但存在缺陷,如果被攻擊者知道服務(wù)的端口號(hào),控制多臺(tái)主機(jī)向服務(wù)器發(fā)送大量垃圾信息,可使服務(wù)器癱瘓。這是此類協(xié)議的共有的弱點(diǎn)。
3 結(jié)束語
傳輸層的UDP協(xié)議由于其簡潔、高效性而被廣泛使用,是一種重要的協(xié)議。該文介紹的UDP協(xié)議使用方法具有通用性,可作為開發(fā)、學(xué)習(xí)此類軟件參考。UDP協(xié)議由于沒有安全控制,采用UDP協(xié)議的系統(tǒng)在提供服務(wù)時(shí)最好放在防火墻內(nèi),由系統(tǒng)對(duì)它提供安全保證。
參考文獻(xiàn):
[1] 謝希仁.計(jì)算機(jī)網(wǎng)絡(luò)[M].5版.北京:電子工業(yè)出版社,2007:108-184.
[2] Stanley B Lippman. JoséeLajoi C++Primer[M].潘愛民,張麗,譯.北京:電力出版社,2005.
[4] Behrouz.A.Forouzan Sophia Chung Fegan.Data Communicatins and Networking[M].吳時(shí)霖,等,譯.北京:機(jī)械工業(yè)出版社,2007.7,445-472.
udp協(xié)議范文第2篇
關(guān)鍵詞：P2P；CDP；NAT 穿透；基于UDP的TCP
中圖分類號(hào)：TP317文獻(xiàn)標(biāo)識(shí)碼：A 文章編號(hào)：1009-3044(2007)03-10736-02
1 引言
隨著互聯(lián)網(wǎng)應(yīng)用廣泛推廣，基于各種P2P網(wǎng)絡(luò)技術(shù)的產(chǎn)品也越來越多的出現(xiàn)在我們的視野當(dāng)中。從最早的Napster 到現(xiàn)在的Bittorrent、eMule、skype等產(chǎn)品，P2P這種網(wǎng)絡(luò)應(yīng)用模式已經(jīng)從各個(gè)方面深入人心。這些產(chǎn)品在網(wǎng)絡(luò)實(shí)現(xiàn)技術(shù)上，都以各自的方法解決著同樣面臨的一個(gè)問題，如何讓他們的軟件產(chǎn)品在各異的網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)中順利的進(jìn)行P2P通信。
眾所周知，在當(dāng)今的網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)中，普遍使用NAT設(shè)備來進(jìn)行網(wǎng)絡(luò)地址轉(zhuǎn)換，那么如何讓應(yīng)用程序跨越這些NAT設(shè)備進(jìn)行全雙工通信，就成為非常重要的問題。實(shí)現(xiàn)跨越NAT 通信有很多種辦法：首先是通過服務(wù)器進(jìn)行轉(zhuǎn)發(fā)，這是比較粗暴的方法，在用戶量較大時(shí)，轉(zhuǎn)發(fā)服務(wù)器需要付出相當(dāng)大的代價(jià)；其次，可以使用NAT 穿透技術(shù)。而在NAT 穿透中，UDP 穿透的成功率比起TCP 穿透要高出許多[1]。因此在UDP 協(xié)議上構(gòu)建一些大型的網(wǎng)絡(luò)應(yīng)用程序可能會(huì)成為很多人的需求。
由于UDP協(xié)議本身存在通信不可靠的缺點(diǎn)，對(duì)于基于UDP 進(jìn)行可靠通信的需求就浮現(xiàn)出來了。目前在網(wǎng)絡(luò)上有許多人正在做著這一工作，UDT、RakNet、eNet 等都是構(gòu)建在UDP之上的網(wǎng)絡(luò)可靠通信開發(fā)庫，但這些庫都是針對(duì)一些特殊應(yīng)用進(jìn)行設(shè)計(jì)的，不具備通用性。本文提出的CDP協(xié)議是在UDP基礎(chǔ)之上實(shí)現(xiàn)的TCP協(xié)議。同時(shí)具備了TCP的通用、高效和UDP的高穿透成功率，并提供了簡單易用的應(yīng)用程序開發(fā)接口。
2 CDP設(shè)計(jì)目標(biāo)
CDP主要的目標(biāo)就是在UDP 層之上實(shí)現(xiàn)TCP 的協(xié)議算法，使得應(yīng)用程序能夠在UDP 層之上獲得通用、可靠、高效的通信能力。CDP 網(wǎng)絡(luò)開發(fā)庫所實(shí)現(xiàn)的算法，都來自久經(jīng)考驗(yàn)的TCP協(xié)議算法，以下協(xié)議設(shè)計(jì)部分主要講解CDP實(shí)現(xiàn)中與TCP標(biāo)準(zhǔn)不同的部分。
3 CDP協(xié)議設(shè)計(jì)
CDP協(xié)議主要在以下幾個(gè)方面與TCP有所不同：協(xié)議格式、連接建立（NAT UDP PUNCH模式）、保活機(jī)制、MTU發(fā)現(xiàn)與MSS通告。其他部分，如報(bào)文傳輸、流量控制、超時(shí)重傳、擁塞控制等，均參照TCP協(xié)議實(shí)現(xiàn)[2]。下面將對(duì)幾個(gè)不同部分分別進(jìn)行說明。
3.1 協(xié)議格式
CDP的實(shí)現(xiàn)的算法雖然與TCP 實(shí)現(xiàn)的算法是大致相同的,但CDP 的協(xié)議格式只是從TCP協(xié)議格式獲得參考，但并不完全與他相同，CDP協(xié)議格式如圖1所示。
圖中各字段意義分別為：
4 位首部長度：表示用戶數(shù)據(jù)在數(shù)據(jù)包中的起始位置。
LIV：連接保活標(biāo)志。
ACK：確認(rèn)序號(hào)有效。
PSH：接收方應(yīng)該盡快將這個(gè)報(bào)文段交給應(yīng)用層。
RST：重置連接。
SYN：同步序號(hào)，用來發(fā)起一個(gè)連接。
FIN：發(fā)端完成發(fā)送任務(wù)。
16 位窗口大小：接收端可接收數(shù)據(jù)的窗口大小。
選項(xiàng)：只有一個(gè)選項(xiàng)字段，為最長報(bào)文大小，即MSS。CDP 選項(xiàng)格式與TCP 選項(xiàng)格式一致，kind=0 時(shí)表示選項(xiàng)結(jié)束，kind=1 時(shí)表示無操作，kind=2 時(shí)表示最大報(bào)文段長度。如下圖：
圖2 CDP選項(xiàng)字段
數(shù)據(jù)：用戶通過CDP 傳輸?shù)臄?shù)據(jù)。
3.2 連接建立（NAT UDP PUNCH模式）
一般情況下，CDP連接的建立過程與TCP相同。但當(dāng)CDP工作在UDP NAT 穿透（NAT UDP PUNCH）模式下時(shí)，在三次握手之前，先要向?qū)Χ薔AT 端口及預(yù)測(cè)端口以默認(rèn)2ms的間隔發(fā)送默認(rèn)為10個(gè)LIV報(bào)文，一來用于打開自已的NAT 端口，二來是用于進(jìn)入對(duì)端NAT端口。默認(rèn)值可以由用戶程序設(shè)置。這時(shí)的LIV 報(bào)文中初始序號(hào)及確認(rèn)序號(hào)都為0。
當(dāng)接收到對(duì)端LIV 報(bào)文后，CDP立即停止LIV 報(bào)文發(fā)送，發(fā)出SYN 報(bào)文進(jìn)行連接建立。這時(shí)有兩種可能：一是對(duì)端直到接收到該SYN 報(bào)文，都沒有接收到LIV 報(bào)文，或是剛接收到LIV報(bào)文，但沒有來得及發(fā)送SYN 報(bào)文，此時(shí)將會(huì)和一般模式下連接建立的過程一致，經(jīng)歷三次握手；二是對(duì)端在接收到該SYN 報(bào)文之前，也已經(jīng)發(fā)送SYN報(bào)文，此時(shí)雙方都需要對(duì)SYN 報(bào)文段進(jìn)行確認(rèn)。
3.3 半打開連接及連接保活
半打開連接是指對(duì)端異常關(guān)閉，如網(wǎng)線拔掉、突然斷電等情況導(dǎo)致一端關(guān)閉，而另一端卻認(rèn)為連接仍處于打開當(dāng)中，這種情況稱之為半打開連接。CDP中的一個(gè)TDP SOCKET描述符由本地IP、本地端口、遠(yuǎn)端IP、遠(yuǎn)端端口唯一確定。當(dāng)遠(yuǎn)端客戶端連接請(qǐng)求到來時(shí)，服務(wù)端將接收到一個(gè)新的CDP SOCKET描述符，當(dāng)這一個(gè)描述符唯一確定信息已經(jīng)存在時(shí)，對(duì)新的連接請(qǐng)求發(fā)送RST 報(bào)文段，通知其重置連接請(qǐng)求。對(duì)于舊的連接，由保活機(jī)制自動(dòng)發(fā)現(xiàn)是否為半打開連接，如果是半打開連接，則自動(dòng)關(guān)閉該連接。CDP的RST 報(bào)文與TCP 中的RST 報(bào)文是不一樣的。
連接建立之后，CDP 連接需要啟動(dòng)保活機(jī)制。TCP 連接在沒有數(shù)據(jù)通信的情況下也能保持連接，但CDP 連接不行。CDP 連接在一定時(shí)間內(nèi)如果沒有數(shù)據(jù)交互的話，將主動(dòng)發(fā)送保活LIV報(bào)文段。這個(gè)時(shí)間根據(jù)CDP 連接工作模塊不同有所差異，在NAT UDP PUNCH 模式下，默認(rèn)值為1 分鐘（大多數(shù)的NAT中，UDP會(huì)話超時(shí)時(shí)間為2－5分鐘左右）；而在常規(guī)模塊下這個(gè)時(shí)間段默認(rèn)值為5分鐘。默認(rèn)值可以由用戶程序設(shè)置，用戶程序需要指明兩種模式下的保活時(shí)間周期。
3.4 路徑MTU 發(fā)現(xiàn)及MSS 通告
CDP連接建立過程中會(huì)通告初始MSS(Maximum Segment Size)，這個(gè)值可以由用戶程序進(jìn)行設(shè)置。但這個(gè)初始值是靜態(tài)的，當(dāng)通信雙方跨越多個(gè)網(wǎng)絡(luò)時(shí)，使用設(shè)置的MSS可能導(dǎo)致傳輸?shù)腎P 報(bào)文分片的產(chǎn)生。為了避免分片，CDP在數(shù)據(jù)傳輸過程中進(jìn)行動(dòng)態(tài)的路徑MTU(Maximum Transmission Unit)發(fā)現(xiàn)，并進(jìn)行MSS 的更新及通告。
CDP創(chuàng)建UDP SOCKET時(shí)，即將IP選項(xiàng)設(shè)置為不允許分片： Setsockopt（clientSock, IPPROTO_IP, IP_DONTFRAGMENT, (char*)&dwFlags, sizeof(dwFlag) )。
在發(fā)送數(shù)據(jù)時(shí)先以當(dāng)前MSS 大小進(jìn)行發(fā)送，如果返回值為錯(cuò)誤碼WSAEMSGSIZE（10040），則表示為報(bào)文尺寸大于MTU，需要進(jìn)行IP 分片傳輸。此時(shí)，縮減MSS大小再次發(fā)送，直至不再返回錯(cuò)誤碼WSAEMSGSIZE（10040）。當(dāng)MSS 變更并能成功發(fā)送報(bào)文后，需要向?qū)Χ送▓?bào)新的MSS 值。每次MSS 縮小后，默認(rèn)隔30 秒，CDP 將默認(rèn)擴(kuò)大MSS 大小，以檢查是否路徑MTU 是否增大了，之后隔30*2 秒、30*2*2 秒進(jìn)行檢測(cè)，如果三次都未發(fā)現(xiàn)MTU 增大則停止進(jìn)行檢測(cè)。網(wǎng)絡(luò)中MTU 值的個(gè)數(shù)是有限的[3]。因此MSS 的擴(kuò)大及縮減，可依據(jù)一些由近似值按序構(gòu)成的表，依照此表索引進(jìn)行MSS 值的擴(kuò)大與縮減計(jì)算。
CDP 中MSS 與MTU 之間關(guān)系的計(jì)算公式如下：MSS = MTUC20(IP首部)C8(UDP首部)C12(CDP首部)。
4 CDP應(yīng)用程序開發(fā)接口（CDP Socket API）
使用CDP進(jìn)行網(wǎng)絡(luò)程序開發(fā)是非常容易的，它API與標(biāo)準(zhǔn)socket API是非常相似的，對(duì)應(yīng)功能的函數(shù)名稱都相同，只是CDP的所有API都處于名稱空間CDP 之下。此程序庫的實(shí)現(xiàn)也參考了BSD Socket的實(shí)現(xiàn)。CDP Socket API列表如下：
5 結(jié)束語
本文提出了一種基于UDP協(xié)議之上的TCP協(xié)議實(shí)現(xiàn)――CDP協(xié)議，并對(duì)現(xiàn)實(shí)的一些關(guān)鍵部分進(jìn)行了討論，最后給出了CDP協(xié)議的應(yīng)用開發(fā)接口。CDP協(xié)議同時(shí)具備了TCP通用、高效的特點(diǎn)，有利用的UDP的NAT穿透特性，可廣泛應(yīng)用與構(gòu)建各種P2P網(wǎng)絡(luò)應(yīng)用。
參考文獻(xiàn)：
[1]B. Ford, P. Srisuresh, D. Kegel, Peer-to-Peer Communication across Network Address Translators [EB/OL], draft-ford-midcom-p2p,/pub/net/p2pnat, June 2004.
[2]W.Richard Stevens, 范建華,譯，TCP/IP詳解――卷Ⅰ：協(xié)議[M]，機(jī)械工業(yè)出版社，2000.4.1.
[3]J. Mogul, S. Deering, "Path MTU Discovery"[S], RFC1191, November 1990.
udp協(xié)議范文第3篇
關(guān)鍵詞：UDP協(xié)議；廣播；多播；Delphi5.0
中圖分類號(hào)：TP311.1 文獻(xiàn)標(biāo)識(shí)碼：A文章編號(hào)：1007-9599 (2011) 05-0000-01
Implementation of Broadcast and Multicast under the UDP Protocol
Zhang Wei12,Zhang Huanjun1,Cheng Xiao2
(1.Shenyang Ligong University,Shenyang110168,China;
2.Sicong Co.,Ltd.,Xian710043,China)
Abstract:UDP is a very practical and feasible network transmission layer protocols,now widely used in many fields in the future,and will play a greater role.This paper expounds the development environment Delphi5.0 next Broadcast and multicast a software design method.
Keywords:UDP protocol;Broadcast;Multicast;Delphi5.0
在TCP/IP協(xié)議族中，有兩個(gè)互不相同的傳輸協(xié)議：TCP（傳輸控制協(xié)議）和UDP（用戶數(shù)據(jù)報(bào)協(xié)議）。TCP為兩臺(tái)主機(jī)提供高可靠性的數(shù)據(jù)通訊，UDP為應(yīng)用層提供了一種非常簡單的服務(wù)，它只是把稱作數(shù)據(jù)報(bào)的分組從一臺(tái)主機(jī)發(fā)送到另一臺(tái)主機(jī)，但并不保證該數(shù)據(jù)報(bào)能到達(dá)另一端。與TCP相比UDP的優(yōu)勢(shì)就在于它排除了信息可靠傳遞機(jī)制，將安全和排序等功能移交給上層應(yīng)用來完成，極大降低了執(zhí)行時(shí)間，保證了運(yùn)行速度。單播、廣播、組播則表示的是數(shù)據(jù)在網(wǎng)絡(luò)中“播放”的形式，是指有一個(gè)人能聽到還是讓特定的人群聽得到，還是讓所有的人都聽的到的區(qū)別。一臺(tái)主機(jī)要向網(wǎng)上的所有其他主機(jī)發(fā)送幀，這就是廣播；多播處于單播和廣播之間，向?qū)儆诙嗖ソM的多個(gè)主機(jī)發(fā)送幀。
一、廣播與多播的實(shí)現(xiàn)
下面我們就詳細(xì)介紹一下Delphi5.0開發(fā)環(huán)境下廣播和多播的實(shí)現(xiàn)。軟件開發(fā)步驟如下：
（一）網(wǎng)絡(luò)初始化
1.首先初始化WinSock動(dòng)態(tài)連接庫，創(chuàng)建Socket套接字，用下面語句綁定發(fā)送方Addr：
Addr.sin_family：=AF_INET；
Addr.sin_addr.S_addr：=INADDR_ANY；//本機(jī)接收地址設(shè)為任意地址
Addr.sin_port：=htons（UDPPORT）； //設(shè)定本機(jī)UDP端口號(hào)
函數(shù)htons將端口號(hào)由主機(jī)字節(jié)順序轉(zhuǎn)換為網(wǎng)絡(luò)字節(jié)順序，然后將套接字綁定到一個(gè)本地地址和端口上（bind），設(shè)置為異步選擇，設(shè)定接收端SockAddrIn：
FSockAddrIn.SIn_Family：=AF_INET；
FSockAddrIn.SIn_Port：=htons（UDPPORT）；//接收端端口設(shè)置
2.廣播接口設(shè)置。廣播方式有兩種，一種是limited broadcast，廣播地址是255.255.255.255；一種是directed broadcast。limited broadcast初始化時(shí)代碼如下： SetSockopt（FSocket，SOL_SOCKET，SO_BROADCAST，@broadcast，sizeof（broadcast））；
directed broadcast不需要SetSockopt（），以標(biāo)準(zhǔn)的C類網(wǎng)為例，直接發(fā)送x.x.x.255就可以了。這種廣播只有同一邏輯子網(wǎng)中的機(jī)器才能收到，也就是說對(duì)方地址應(yīng)該是x.x.x.y，如果不是，即使在同一物理子網(wǎng)中也是收不到的。當(dāng)然，這和子網(wǎng)掩碼有關(guān)。limited broadcast廣播的好處是只要在同一子網(wǎng)中的主機(jī)，就可以收到這種廣播，而不必非要在統(tǒng)一邏輯子網(wǎng)中。例如，如果你的地址是x.x.x.1，那么這種廣播，地址是x.y.z.a的主機(jī)也能收到。
3.多播接口設(shè)置。mreq.imr_multiaddr.S_addr：=inet_addr（pchar（MY_GROUP））；//設(shè)定多播地址mreq.imr_interface.S_addr：=htonl（INADDR_ANY）；//設(shè)定本機(jī)接收端口。
（二）網(wǎng)絡(luò)數(shù)據(jù)的讀取
flen：=sizeof（FSockAddrIn）；//獲取字節(jié)長度
FSockAddrIn.SIn_Port ：= htons（UDPPORT）；//設(shè)定本機(jī)接收端口
Event：=WSAGetSelectEvent（Message.LParam）；//接收到數(shù)據(jù)后觸發(fā)消息事件
if Event=FD_READ then
begin
len：=recvfrom（FSocket，buffer，sizeof（buffer），0，F(xiàn)SockAddrIn，flen）；
value：=copy（buffer，1，len）；//網(wǎng)絡(luò)數(shù)據(jù)接收，buffer是緩沖區(qū)。
（三）網(wǎng)絡(luò)數(shù)據(jù)的發(fā)送。
首先定義一個(gè)string變量和一個(gè)integer變量，然后設(shè)置遠(yuǎn)端主機(jī)地址：
FSockAddrIn.SIn_Addr.S_addr：=inet_addr（pchar（Edit1.text））；
value：=Content；
len：=sendto（FSocket，value[1]，Length（value），0，F(xiàn)SockAddrIn， sizeof（FSockAddrIn））； //網(wǎng)絡(luò)數(shù)據(jù)發(fā)送
if（WSAGetLastError（） WSAEWOULDBLOCK）and（WSAGetLastError（） 0）then //網(wǎng)絡(luò)數(shù)據(jù)發(fā)送異常判斷
showmessage（inttostr（WSAGetLastError（）））；
（四）關(guān)閉網(wǎng)絡(luò)接口
CloseSocket（FSocket）；//關(guān)閉Socket
二、結(jié)束語
經(jīng)測(cè)試，該軟件能成功實(shí)現(xiàn)UDP協(xié)議下的廣播和多播。測(cè)試結(jié)果如圖1、圖2所示。
圖1 UDP廣播測(cè)試結(jié)果圖2UDP多播測(cè)試結(jié)果
參考文獻(xiàn)：
[1]袁振武.謝任東.談Delphi編程中UDP協(xié)議的應(yīng)用[J].科技廣場(chǎng),2008,05
udp協(xié)議范文第4篇
關(guān)鍵詞:UDP;RUDP;可靠性
中圖分類號(hào):TP393文獻(xiàn)標(biāo)識(shí)碼:A文章編號(hào):1009-3044(2010)16-4379-02
Reliable Improvement Agreement Based on UDP Agreement
YIN Ran-ran
(School of Computer & Information, Hefei University of Technology, Hefei 230009, China)
Abstract: This article will propose and realizes the embedded equipment's authentic data transmission and one kind of new many through the comparative analysis transmission level transport protocols UDP unreliability and the TCP low efficiency in the UDP agreement's foundation transmits the RUDP agreement wireless. The RUDP agreement software module provides based on the news reliable communication function, the correspondence is faces the connection, the first floor uses UDP to take the load bearing agreement.
Key words: UDP; RUDP; reliability
1 TCP協(xié)議和UDP協(xié)議
1.1 TCP協(xié)議
傳輸控制協(xié)議即TCP,盡管它和UDP都使用相同的網(wǎng)絡(luò)層協(xié)議(IP),但它向應(yīng)用層提供了與UDP完全不同的服務(wù),它提供一種面向連接的、可靠的字節(jié)流服務(wù)。面向連接意味著兩個(gè)使用TCP的應(yīng)用在彼此交換數(shù)據(jù)之前必須先建立一個(gè)TCP連接,數(shù)據(jù)傳輸完成后,再經(jīng)過4次握手終止雙方的連接。在數(shù)據(jù)傳輸?shù)倪^程中,TCP還通過對(duì)數(shù)據(jù)的確認(rèn)、流量控制等手段提高通信的可靠性。
1.2 UDP協(xié)議
UDP(User Datagram Protocol),即用戶數(shù)據(jù)報(bào)協(xié)議。在TCP/IP網(wǎng)絡(luò)通信中, UDP協(xié)議是一種面向無連接的服務(wù)。它發(fā)送數(shù)據(jù)以獨(dú)立的數(shù)據(jù)包形式,不保證各數(shù)據(jù)包的發(fā)送順序,也不進(jìn)行正確性檢查,因此,可能出現(xiàn)數(shù)據(jù)的重發(fā)、丟失、失序等現(xiàn)象[2]。使用UDP協(xié)議的常見服務(wù)有DNS、QQ等。
UDP協(xié)議直接向接收方發(fā)送數(shù)據(jù)而不關(guān)心對(duì)方計(jì)算機(jī)的狀態(tài),因此,它是一種相對(duì)不可靠的通信協(xié)議。正因?yàn)閁DP協(xié)議不考慮網(wǎng)絡(luò)數(shù)據(jù)傳輸過程中的很多問題,所以能節(jié)省了大量的網(wǎng)絡(luò)狀態(tài)確認(rèn)和數(shù)據(jù)確認(rèn)的系統(tǒng)資源消耗,從而提高UDP協(xié)議的傳輸速度和網(wǎng)絡(luò)的利用效率。可是,如果既能充分利用UDP協(xié)議的這些優(yōu)勢(shì),又能保證UDP通信的可靠性,網(wǎng)絡(luò)通信系統(tǒng)的性能將會(huì)得到更大程度地提高。
2 RUDP 協(xié)議的提出
2.1 嵌入式設(shè)備可靠通信面臨的問題
面向連接方式的服務(wù)功能明顯很強(qiáng)大,它能夠發(fā)揮面向連接的傳輸所具備的特性,例如流量控制,差錯(cuò)處理以及順序交付等等,但是面向無連接的服務(wù)更適合于某些情況,在網(wǎng)絡(luò)層上使用IP協(xié)議就是一個(gè)面向無連接的服務(wù)而且這個(gè)面向無連接的服務(wù)顯得更加健壯,因?yàn)镮nternet本身就是一個(gè)不穩(wěn)定的環(huán)境,面向連接的服務(wù)反而不能很好的運(yùn)行于其上。
如果使用TCP連接協(xié)議實(shí)現(xiàn)嵌入式設(shè)備之間的數(shù)據(jù)傳輸可能帶來許多的問題,嵌入式設(shè)備之間建立TCP連接并發(fā)送數(shù)據(jù)后,或者接收端向正在請(qǐng)求連接的設(shè)備發(fā)出SYN+ACK應(yīng)答報(bào)文后,都可能無法接收到終端的ACK報(bào)文,在這種情況下發(fā)送端一般會(huì)重試并等待一段時(shí)間后終止這個(gè)連接。大量重傳數(shù)據(jù)會(huì)進(jìn)一步加劇網(wǎng)絡(luò)的擁塞情況,嚴(yán)重時(shí)可以使網(wǎng)絡(luò)及服務(wù)器系統(tǒng)崩潰,同時(shí)也會(huì)對(duì)數(shù)據(jù)傳輸?shù)膶?shí)時(shí)性產(chǎn)生影響。同時(shí)目前嵌入式設(shè)備又存在多點(diǎn)分散、數(shù)據(jù)量小、實(shí)時(shí)性要求高等特點(diǎn)[3]。本文將在UDP協(xié)議的基礎(chǔ)上提出并實(shí)現(xiàn)嵌入式設(shè)備的可靠數(shù)據(jù)傳輸。
2.2 嵌入式可靠傳輸模型的體系結(jié)構(gòu)
RUDP協(xié)議軟件模塊底層采用UDP作為承載協(xié)議,提供基于消息的可靠通信功能。根據(jù)計(jì)算機(jī)網(wǎng)絡(luò)層次體系的概念,RUDP協(xié)議的層次模型就是在原UDP/IP協(xié)議的傳輸層和應(yīng)用層之間加入了RUDP層和標(biāo)志層。RUDP協(xié)議的層次結(jié)構(gòu)如表1所示。
RUDP層的功能是保證數(shù)據(jù)的可靠傳送。由于嵌入式設(shè)備通過網(wǎng)絡(luò)進(jìn)行消息的收發(fā)是處于一個(gè)公共網(wǎng)絡(luò)的環(huán)境之中,可能會(huì)有大量無用的數(shù)據(jù)向嵌入式設(shè)備進(jìn)行發(fā)送,大量的數(shù)據(jù)解析會(huì)極大地增加嵌入式設(shè)備的負(fù)擔(dān)。為了避免這個(gè)問題,我們?cè)黾恿艘粋€(gè)標(biāo)志層,標(biāo)志層可以讓嵌入式設(shè)備迅速的判斷所接收的數(shù)據(jù)包是否為有效數(shù)據(jù)包,如果標(biāo)志層數(shù)據(jù)不可識(shí)別,則迅速將包丟棄。在可靠傳輸層進(jìn)行可靠傳輸設(shè)計(jì)和實(shí)現(xiàn),在這一層,我們?cè)黾右幌盗锌煽總鬏敊C(jī)制以保證嵌入式設(shè)備之間數(shù)據(jù)的可靠傳輸。這樣就形成了一個(gè)原UDP協(xié)議所在傳輸層和應(yīng)用層之間加入了一層為保證可靠數(shù)據(jù)傳送而實(shí)現(xiàn)的RUDP軟件模塊和標(biāo)志層的六層體系結(jié)構(gòu)。從而,在UDP協(xié)議的基礎(chǔ)上實(shí)現(xiàn)一種基于消息的面向連接的,適合嵌入式設(shè)備的可靠數(shù)據(jù)傳遞機(jī)制。
2.3 嵌入式可靠傳輸模型的基本功能
嵌入式可靠傳輸模型RUDP主要功能有:
1) 基于消息的收發(fā)功能:RUDP的傳輸層利用基于消息的傳輸協(xié)議,所以不必考慮發(fā)送端可以接收多少數(shù)據(jù),只需知道能否接收數(shù)據(jù)即可。
2) 校驗(yàn)和:RUDP的校驗(yàn)和算法采用UDP的校驗(yàn)功能保證數(shù)據(jù)包的正確和順序到達(dá)。UDP校驗(yàn)和字段是對(duì)整個(gè)UDP報(bào)文頭和UDP所帶的數(shù)據(jù)的校驗(yàn)和。
3) 丟棄重復(fù)包和保存失序包的功能:每當(dāng)收到數(shù)據(jù)包后,便對(duì)數(shù)據(jù)包進(jìn)行確認(rèn)。保存未確認(rèn)的數(shù)據(jù)包,丟棄已經(jīng)確認(rèn)了的重復(fù)包。由于UDP傳送過程中,收到的數(shù)據(jù)包的順序可能會(huì)和發(fā)送的順序有一定的區(qū)別,所以保存失序包能夠有效的減少重發(fā)的次數(shù),也就是能相應(yīng)的減少網(wǎng)絡(luò)的數(shù)據(jù)流量。
4) 超時(shí)重發(fā)功能:RUDP中借鑒TCP中的超時(shí)重發(fā)機(jī)制來保證數(shù)據(jù)包的可靠傳遞;同時(shí)TCP中的確認(rèn)延遲功能也得到借鑒,這樣可以顯著降低網(wǎng)絡(luò)的流量,提高嵌入式系統(tǒng)的通信效率。
5) 服務(wù)器和客戶端保活功能:探測(cè)收發(fā)兩端的連接是否正常時(shí)嵌入式可靠傳輸模型中必須要實(shí)現(xiàn)的一個(gè)功能。如果連接已經(jīng)出錯(cuò),若干數(shù)據(jù)包仍然發(fā)送,當(dāng)超時(shí)定時(shí)器到時(shí)后就會(huì)進(jìn)行數(shù)據(jù)的重發(fā)。如果沒有判斷收發(fā)兩端的連接是否正常,則會(huì)導(dǎo)致數(shù)據(jù)無法正常而又高效的發(fā)送。
2.4 RUDP協(xié)議工作過程
RUDP協(xié)議的工作過程是:首先,建立連接。發(fā)送方和接收方通過三次握手的方式建立連接(三次握手過程如圖1所示)。第三次握手時(shí),發(fā)送方發(fā)給接收方的數(shù)據(jù)幀中除了包含對(duì)接收方的確認(rèn)信息之外,還包含將要發(fā)送的數(shù)據(jù)幀總數(shù)。接收方收到確認(rèn)幀后,開始與發(fā)送方建立連接。與此同時(shí)將根據(jù)收到的幀總數(shù)設(shè)置接收窗口大小并將所有幀序號(hào)放入緩存。雙方連接建立好后保證了數(shù)據(jù)發(fā)送和接收的同步性。
接著,發(fā)送方開始發(fā)送數(shù)據(jù)幀,接收方收到數(shù)據(jù)幀并進(jìn)行處理。能夠正確接收到的幀序號(hào)將會(huì)從序號(hào)緩存中刪除。發(fā)送方發(fā)送完數(shù)據(jù)幀后發(fā)送“發(fā)送完”標(biāo)志給接收方。接收方收到此標(biāo)志后,開始掃描幀序號(hào)緩存。如果數(shù)據(jù)幀全部接收到,接收方向發(fā)送方發(fā)送一“接收完”標(biāo)志,發(fā)送方收到后斷開連接。如果序號(hào)緩存中有序號(hào)則說明有幀丟失,這時(shí)接收方將向發(fā)送方發(fā)出一個(gè)帶有丟失幀序號(hào)的確認(rèn)幀。發(fā)送方收到此確認(rèn)幀后將重新發(fā)送丟失幀。如此重復(fù),直到接收方完全正確接收到數(shù)據(jù)幀。其工作過程如圖2所示。
3 總結(jié)
通過分析比較傳輸層協(xié)議TCP和UDP,能夠看到它們各自的特點(diǎn),并分析出它們各自的優(yōu)勢(shì)和缺點(diǎn)。結(jié)合嵌入式設(shè)備數(shù)據(jù)傳輸?shù)奶攸c(diǎn)同時(shí)針對(duì)UDP在可靠性方面的不足進(jìn)行了改進(jìn),簡單介紹了RUDP協(xié)議的原理和工作過程。通過分析可以看出采用RUDP的效率在嵌入式設(shè)備數(shù)據(jù)傳輸中要優(yōu)于UDP協(xié)議,這樣就可以實(shí)現(xiàn)一種更適合于嵌入式設(shè)備的可靠數(shù)據(jù)傳遞機(jī)制。
參考文獻(xiàn):
[1] Wright G R,Stevens W R. TCP/ IP 詳解卷2:實(shí)現(xiàn)[M].陸雪瑩,蔣慧,譯.北京:機(jī)械工業(yè)出版社,1999.
[2] Comer D E. 用TCP/IP進(jìn)行網(wǎng)絡(luò)互聯(lián)[M].張娟,王海,譯.卷2.北京:電子工業(yè)出版社,1998.
udp協(xié)議范文第5篇
引 言
超文本傳輸協(xié)議（HTTP）是目前通過Internet進(jìn)行信息交換最主要的方式。HTTP協(xié)議是建立在請(qǐng)求/響應(yīng)(request/response)模型上的。首先由客戶建立一條與服務(wù)器的TCP鏈接，并發(fā)送一個(gè)請(qǐng)求到服務(wù)器，請(qǐng)求中包含請(qǐng)求方法、URI、協(xié)議版本以及相關(guān)的MIME(Multipurpose Internet Mail Extensions)樣式的消息。服務(wù)器響應(yīng)一個(gè)狀態(tài)行，包含消息的協(xié)議版本、一個(gè)成功和失敗碼以及相關(guān)的MIME式樣的消息(包含服務(wù)器的信息、資源實(shí)體的信息和可能的資源內(nèi)容)。圖1給出了HTTP協(xié)議實(shí)現(xiàn)的一個(gè)簡單模型。HTTP/1.0[3]為每一次HTTP的請(qǐng)求/響應(yīng)建立一條新的TCP鏈接，因此一個(gè)包含HTML內(nèi)容和圖片的頁面將需要建立多次的短期的TCP鏈接。一次TCP鏈接的建立將需要3次握手。另外，為了獲得適當(dāng)?shù)膫鬏斔俣龋瑒t需要TCP花費(fèi)額外的回路鏈接時(shí)間（RTT）。每一次鏈接的建立需要這種經(jīng)常性的開銷，而其并不帶有實(shí)際有用的數(shù)據(jù)，只是保證鏈接的可靠性，因此HTTP/1.1[4]提出了可持續(xù)鏈接的實(shí)現(xiàn)方法。HTTP/1.1將只建立一次TCP的鏈接而重復(fù)地使用它傳輸一系列的請(qǐng)求/響應(yīng)消息，因此減少了鏈接建立的次數(shù)和經(jīng)常性的鏈接開銷。
可持續(xù)鏈接減少了每次TCP鏈接建立的時(shí)間，但是一個(gè)空閑的TCP鏈接將需要一個(gè)Socket和相應(yīng)的存儲(chǔ)緩沖區(qū)。一個(gè)Socket緩沖區(qū)的最小長度必須大于一個(gè)TCP包的最大長度，即64 KB，而且很多實(shí)現(xiàn)方法在鏈接建立時(shí)將預(yù)分配一些緩沖區(qū)。可用的Socket的數(shù)量是有限的，很多基于BSD的操作系統(tǒng)對(duì)于能夠同時(shí)打開的鏈接數(shù)都有一個(gè)缺省的最大值。
無線掌上設(shè)備PDA的應(yīng)用（如瀏覽器）[5]特點(diǎn)表現(xiàn)在：① 因?yàn)轫撁媸轻槍?duì)掌上設(shè)備制作的，一般在1 K~2 K字節(jié)，比較小；② 目前無線通信網(wǎng)絡(luò)的帶寬很窄，GSM的數(shù)據(jù)信道帶寬只有9.6 K。當(dāng)前Web頁面的訪問大多通過HTTP協(xié)議，并使用TCP作為下層的傳輸控制協(xié)議。但不幸的是，TCP并不適合短會(huì)話的應(yīng)用情況，不同于現(xiàn)在采用的使用單一TCP傳輸協(xié)議進(jìn)行數(shù)據(jù)傳輸?shù)姆绞健１疚奶岢隽瞬捎脛?dòng)態(tài)選擇傳輸層協(xié)議（TCP、UDP）的方法來改善取回頁面的延遲、網(wǎng)絡(luò)擁塞以及服務(wù)器的負(fù)荷。
這種混合TCP-UDP的方法結(jié)合兩個(gè)方面的優(yōu)點(diǎn)：首先，對(duì)于需要比較少數(shù)據(jù)傳輸?shù)那闆r，它將使用UDP作為傳輸層的協(xié)議，從而避免了TCP鏈接的多次握手開銷；另外，對(duì)于需要較多數(shù)據(jù)傳輸?shù)那闆r，它將使用可靠的帶有重排序和擁塞控制的TCP協(xié)議作為傳輸層的協(xié)議。混合TCP-UDP的實(shí)現(xiàn)方法只需要對(duì)應(yīng)用層的改動(dòng)，而操作系統(tǒng)的核心代碼不用任何更改。僅采用UDP協(xié)議的缺點(diǎn)在于，需要在應(yīng)用層建立一套類似于TCP復(fù)雜的控制協(xié)議，從而進(jìn)行重排序和擁塞控制來保證傳輸?shù)目煽啃浴?span style="display:none">gg2萬博士范文網(wǎng)-您身邊的范文參考網(wǎng)站Vanbs.com
1 背 景
HTTP是一個(gè)請(qǐng)求/響應(yīng)協(xié)議，客戶端的應(yīng)用程序通過提供一個(gè)URL可以從服務(wù)器上得到所需的數(shù)據(jù)。HTTP可以用來訪問各種不同類型的資源，其中包括文本、圖形、影音、可執(zhí)行文件、數(shù)據(jù)庫查詢結(jié)果等等。
圖2給出了在客戶端發(fā)起HTTP GET請(qǐng)求后，在客戶端和服務(wù)器之間進(jìn)行數(shù)據(jù)包交換的示意。圖中只有兩個(gè)數(shù)據(jù)包是有用的（即攜帶了數(shù)據(jù)）：一個(gè)是HTTP GET請(qǐng)求，另一個(gè)是HTTP的響應(yīng)。其它的都是TCP用來進(jìn)行握手操作的數(shù)據(jù)包。為了減輕Web服務(wù)器的負(fù)荷，經(jīng)常采用重定向機(jī)制。這樣從服務(wù)器發(fā)來的重定向響應(yīng)報(bào)文是很短的數(shù)據(jù)包。使用TCP作為傳輸協(xié)議需要至少7個(gè)數(shù)據(jù)包，而使用UDP則只需要2個(gè)數(shù)據(jù)包就足夠了。
2 設(shè) 計(jì)
我們使用混合傳輸層[6]的方法即對(duì)于少量數(shù)據(jù)傳輸?shù)逆溄硬捎肬DP，而對(duì)于大量數(shù)據(jù)傳輸?shù)逆溄硬捎肨CP作為傳輸層協(xié)議。這樣對(duì)于短鏈接而言就避免了TCP經(jīng)常性的握手開銷，而對(duì)于長鏈接則仍可獲得TCP的優(yōu)點(diǎn)，如超時(shí)重傳、擁塞控制、錯(cuò)誤恢復(fù)機(jī)制等。這種方法中，客戶端首先嘗試使用UDP作為傳輸層的協(xié)議，如果對(duì)于所請(qǐng)求的URL UDP并不適合，則再次使用TCP鏈接。這種方法提供了以下保證：
如果初始的UDP數(shù)據(jù)包丟失，將采用TCP重新鏈接而不會(huì)受到影響。
如果所鏈接的服務(wù)器沒有使用混合傳輸層的實(shí)現(xiàn)機(jī)制，客戶端將使用TCP重新進(jìn)行鏈接。
圖3給出了混合TCP、UDP的實(shí)現(xiàn)算法。一個(gè)采用混合算法的HTTP客戶端首先使用UDP作為傳輸層的協(xié)議發(fā)出HTTP GET請(qǐng)求，同時(shí)啟動(dòng)超時(shí)定時(shí)器。
當(dāng)服務(wù)器處理客戶端發(fā)來的請(qǐng)求時(shí)，它可以從以下兩點(diǎn)做出選擇：
① 如果響應(yīng)的數(shù)據(jù)足夠小（比如，可放到一個(gè)數(shù)據(jù)包中），服務(wù)器將使用UDP發(fā)回響應(yīng)。像比較小的網(wǎng)頁或HTTP REDIRECT響應(yīng)就屬于這一類。
② 如果響應(yīng)的數(shù)據(jù)很大，無法放進(jìn)一個(gè)UDP數(shù)據(jù)包中，服務(wù)器則要求客戶端使用TCP重試。這可以通過添加一個(gè)HTTP的頭部字段來解決如 TCPRETR。
在客戶端，將會(huì)出現(xiàn)以下三種情況：
客戶端從服務(wù)器接收到響應(yīng)。如果響應(yīng)中包含了所需的HTTP響應(yīng)，客戶端將對(duì)數(shù)據(jù)進(jìn)行處理。如果服務(wù)器要求客戶端重試，客戶端將使用TCP作為傳輸層重試。
如果服務(wù)器沒有處理通過UDP傳輸?shù)腍TTP包，客戶端就會(huì)收到ICMP錯(cuò)誤消息（目的地址無法到達(dá)/協(xié)議無法到達(dá)）。此時(shí)客戶端將會(huì)使用TCP重試。
如果定時(shí)器超時(shí)，客戶端應(yīng)使用TCP重試。
圖4給出了在定時(shí)器超時(shí)情況下，客戶端和服務(wù)器之間數(shù)據(jù)包的交換。這種超時(shí)機(jī)制提供了可靠性，以及與未使用混合TCP-UDP方法的服務(wù)器的兼容性。
圖5示意了服務(wù)器要求客戶端使用TCP重發(fā)請(qǐng)求時(shí)，客戶端和服務(wù)器之間的數(shù)據(jù)包交換。
3 結(jié) 語
混合TCP-UDP方法改善了參與HTTP傳輸?shù)娜齻€(gè)方面：客戶端、服務(wù)器和網(wǎng)絡(luò)。
對(duì)于客戶端而言，可以避免由于TCP而引入的三向握手的時(shí)間，從而減少了瀏覽的延遲時(shí)間。
對(duì)于服務(wù)器而言，由于所需的TCP的鏈接數(shù)量減少，從而降低了由于建立、維護(hù)、撤銷TCP鏈接所帶來的服務(wù)器的負(fù)荷。
udp協(xié)議范文第6篇
關(guān)鍵詞:通信網(wǎng)絡(luò);基于樣本塊的方法;UDP協(xié)議;Mean-Shift方法
中圖分類號(hào):TP311文獻(xiàn)標(biāo)識(shí)碼:A文章編號(hào):1009-3044(2010)21-5714-02
通信網(wǎng)絡(luò)為計(jì)算機(jī)信息的獲取、傳輸、處理、利用和共享提供一個(gè)安全可靠的環(huán)境和傳輸通道,但現(xiàn)實(shí)中通信網(wǎng)絡(luò)并非是絕對(duì)安全的,傳輸數(shù)據(jù)過程中數(shù)據(jù)包的丟失、泄密和篡改時(shí)有發(fā)生,且日趨嚴(yán)重。
目前在通信網(wǎng)絡(luò)中比較常用的兩個(gè)通信協(xié)議是TCP協(xié)議和UDP協(xié)議。TCP是一種面向連接的協(xié)議,采用“三次握手”方式來確保數(shù)據(jù)的準(zhǔn)確接收,其工作機(jī)制是首先是建立連接;其次發(fā)送端發(fā)送數(shù)據(jù),接收端接收數(shù)據(jù);再次接收端向發(fā)送端發(fā)送反饋信息,如果發(fā)送數(shù)據(jù)被成功接收,則斷開連接,否則必須重傳發(fā)送失敗的數(shù)據(jù)。而UDP協(xié)議是一種無連接的協(xié)議,不提供可靠的信息發(fā)送機(jī)制,因此在數(shù)據(jù)傳輸過程當(dāng)中更容易出現(xiàn)數(shù)據(jù)包的丟失現(xiàn)象。
TCP協(xié)議雖說提供安全的數(shù)據(jù)傳輸,但是傳輸效率不高,因此不適合于實(shí)時(shí)性較高的應(yīng)用。UDP協(xié)議雖說不提供安全的數(shù)據(jù)傳輸,但是其傳輸效率很高,能實(shí)現(xiàn)實(shí)時(shí)傳輸,但是容易出現(xiàn)丟失數(shù)據(jù)包的問題。在實(shí)際當(dāng)中很多實(shí)時(shí)性很高的珍貴數(shù)據(jù)是不容有失的,那么如何解決這一問題呢?
在2003年Shantanu D.Rane等提出無線電傳輸中丟失數(shù)據(jù)復(fù)原的問題,他們結(jié)合現(xiàn)有的圖像修復(fù)技術(shù)和紋理合成技術(shù)對(duì)傳輸過程中丟失的數(shù)據(jù)進(jìn)行填充。在傳輸過程中,圖像被劃分為 的塊,計(jì)算其離散余弦變換,然后量化并進(jìn)行哈弗曼編碼,最后傳輸圖像數(shù)據(jù)[1]。該文獻(xiàn)中對(duì)丟失數(shù)據(jù)填充過程如下:對(duì)丟失的塊分類,根據(jù)周圍的塊判斷丟失塊是紋理塊還是結(jié)構(gòu)塊,如果是紋理塊使用紋理合成算法,否則使用結(jié)構(gòu)修復(fù)算法。分析發(fā)現(xiàn)該方法對(duì)于塊的分類不夠準(zhǔn)確,而且丟失數(shù)據(jù)的填充比較耗時(shí)。
本文針對(duì)上述缺陷直接使用基于樣本塊的方法[3]填充UDP協(xié)議丟包數(shù)據(jù)。在目前所有的圖像修復(fù)方法中,基于樣本塊的修復(fù)方法是非常有效用的一種,它不僅能夠填充圖像紋理部分,而且能夠修復(fù)圖像簡單的結(jié)構(gòu),對(duì)結(jié)構(gòu)的修復(fù)主要是受修復(fù)的優(yōu)先權(quán)和樣本塊的大小控制,適合的修復(fù)順序和樣本塊大小是有利于圖像結(jié)構(gòu)的保持。因此本文直接使用基于樣本塊的方法對(duì)丟失的圖像數(shù)據(jù)進(jìn)行填充,這樣不僅能夠提高填充的效率,而且能夠減輕數(shù)據(jù)包的丟失造成嚴(yán)重?fù)p失。
1 基于樣本塊的丟失圖像數(shù)據(jù)填充
UDP協(xié)議的數(shù)據(jù)傳輸過程與無線電數(shù)據(jù)的傳輸是相似的,其優(yōu)點(diǎn)是傳輸過程中的部分?jǐn)?shù)據(jù)丟失不會(huì)引起整個(gè)圖像數(shù)據(jù)的混亂,這就為數(shù)據(jù)的恢復(fù)提供了一定的可能,否則數(shù)據(jù)的恢復(fù)是非常困難的。在很多文獻(xiàn)中提到UDP協(xié)議的丟包率與具體網(wǎng)絡(luò)環(huán)境有關(guān),沒有一個(gè)準(zhǔn)確的數(shù)值,但是一般來說其平均丟包率總會(huì)小于無線電數(shù)據(jù)的丟包率3.6%[2]。
基于樣本塊的方法一種非常有效的丟失圖像數(shù)據(jù)的填充方法,它不僅能填充大塊的紋理破損,而且能夠修復(fù)較小的結(jié)構(gòu)破損。UDP協(xié)議的丟包率一般來說很小,這也就為圖像的結(jié)構(gòu)部分的復(fù)原提供了重要的保障。基于樣本塊的圖像修復(fù)過程如下:
1) 確定丟失數(shù)據(jù)包的位置,因?yàn)閳D像數(shù)據(jù)是經(jīng)過編碼后傳輸?shù)?因此即使丟包也不會(huì)使得整個(gè)圖像數(shù)據(jù)混亂,自然其丟失數(shù)據(jù)的位置容易確定;
2) 尋找破損區(qū)域的邊緣;
3) 按照優(yōu)先權(quán)計(jì)算方法確定當(dāng)前優(yōu)先權(quán)最高的像素點(diǎn),優(yōu)先權(quán)P(p)一般為信任度因子C(p)與數(shù)據(jù)因子D(p)的積。信任度因子和數(shù)據(jù)因子的計(jì)算如式(1)和式(2):
(1)
(2)
信任度因子確保了當(dāng)前待修復(fù)塊上有更多的已知像素點(diǎn)來確保找到的最佳匹配塊的準(zhǔn)確性,而數(shù)據(jù)因子表示破損區(qū)域邊界在優(yōu)先權(quán)最高像素點(diǎn)處的法線與該點(diǎn)處等照線的夾角,夾角越大則結(jié)構(gòu)越強(qiáng),否則結(jié)構(gòu)越弱,結(jié)構(gòu)越強(qiáng)的自然越先修復(fù),這樣有利于圖像邊緣的保持;
4) 根據(jù)相似度的度量機(jī)制,尋找最佳匹配塊;
5) 將最佳匹配塊中的數(shù)據(jù)拷貝到當(dāng)前待修復(fù)塊中,注意只拷貝當(dāng)前塊中破損像素點(diǎn)對(duì)應(yīng)的數(shù)據(jù);
6) 更新破損區(qū)域;
7) 判斷破損像素點(diǎn)的個(gè)數(shù)是否為0,如果為0,則轉(zhuǎn)8),否則返回到2);
8) 修復(fù)結(jié)束。
基于樣本塊的修復(fù)方法雖說有很好的修復(fù)效果,但是也必須注意其修復(fù)過程中存在的問題。首先誤差的累積問題,這必然導(dǎo)致錯(cuò)誤的填充結(jié)果。其次是最佳匹配塊的選擇問題,如何在多個(gè)候選最佳匹配塊中選出真正最佳的匹配塊。
文獻(xiàn)[4]提出一種新的方法來解決這誤差累積的問題,首先使用Mean-Shift方法[5]對(duì)圖像進(jìn)行了粗劃分,對(duì)最佳匹配塊的選擇區(qū)域作了限制,具體的最佳匹配塊的選擇原則如下:
1) 如果待修復(fù)塊屬于粗劃分Ti,則最佳匹配塊僅在Ti中選擇;
2) 如果待修復(fù)塊處于多個(gè)劃分Ti∪Ti+1∪...∪Ti+k的邊緣,則最佳匹配塊在Ti∪Ti+1∪...∪Ti+k中選擇。
上述方法相當(dāng)于給匹配塊的選擇加了一些約束,使選擇范圍縮小。這樣不僅縮短了尋找匹配塊的時(shí)間,也避免了誤差的累積。
另外一個(gè)問題就是最佳匹配塊唯一的問題。假設(shè)目前找到的匹配塊為ψp1, ψp2,…ψpk,那么如何在這之中選擇一個(gè)真正的最佳匹配塊。文獻(xiàn)[6]提到了一種選取最佳匹配塊的方法,認(rèn)為與當(dāng)前待修復(fù)塊的空間距離越近,其相關(guān)程度越高。因此,通過計(jì)算待修復(fù)塊的核與匹配塊的核之間的空間距離來最終選定哪個(gè)塊是真正的最佳匹配塊。丟失數(shù)據(jù)的填充流程圖如圖1所示。
2 實(shí)驗(yàn)結(jié)果
本文用VC++實(shí)現(xiàn)了該算法,通過大量的實(shí)驗(yàn)說明了本文算法的有效性。由于傳輸圖像很容易獲得,因此本文采用峰值信噪比的方法對(duì)恢復(fù)結(jié)果進(jìn)行客觀評(píng)價(jià)。峰值信噪比PSNR的計(jì)算如下式:
(3)
PSNR值越大,恢復(fù)的效果越好,越接近原圖;PSNR值越小,恢復(fù)效果越差,與原圖差異越大。恢復(fù)結(jié)果如圖2、圖3、圖4所示。
4 結(jié)論
本文分析了通信網(wǎng)絡(luò)中UDP協(xié)議的傳輸機(jī)制,發(fā)現(xiàn)UDP協(xié)議在傳輸數(shù)據(jù)時(shí)容易發(fā)生數(shù)據(jù)丟包問題,由此使用基于樣本塊的方法解決恢復(fù)丟失數(shù)據(jù)包的問題。盡管文獻(xiàn)[1]的作者提出了無線傳輸中圖像數(shù)據(jù)的恢復(fù)方法,但是該方法比較復(fù)雜,而且存在諸多的不穩(wěn)定性,諸如塊的分類等。本文結(jié)合基于樣本塊修復(fù)的優(yōu)點(diǎn)對(duì)丟失數(shù)據(jù)進(jìn)行恢復(fù),并通過實(shí)驗(yàn)進(jìn)行了驗(yàn)證,確實(shí)取得了令人滿意的效果。這樣不僅很大程度上提高了UDP協(xié)議圖像數(shù)據(jù)傳輸?shù)陌踩?也提高了UDP協(xié)議的傳輸效率。
參考文獻(xiàn):
[1] Shantanu D.Rane,Guilloermo Sapiro and Marcelo Bertalmio. Structure and Texture Filling-in of Missing Image Blocks in Wireless Transmission and Compression Applications[J].IEEE TRANSACTIONS ON IMAGE PROCESSING,VOL.12,NO.3,MARCH 2003,pp.296-303.
[2] E.Chang. An image coding and reconstruction scheme for mobile computing.In proc.5th IDMS,Oslo,Norway,Sept.1998,pp.137-148.
[3] A.Criminisi,P.Perez and K.Toyama. Region Filling and Object Removal by Exemplar-Based Image Inpainting[J].IEEE TRANSACTIONS ON IMAGE PROCESSING,VOL.13,NO.9,SEP 2004.
[4] Feng Tang,Yiting Ying,Jin Wang,and Qunsheng Peng.A Novel Texture Synthesis Based Algorithm for Object Removal in Photographs. MJ Maher (Ed.): ASIAN 2004, LNCS 3321, pp. 248C258, 2004.
[5] Comaniciu D, Meer P.: Mean Shift: A Robust Approach toward Feature Space Analysis[J],IEEE Trans. Pattern Analysis Machine Intell,Vol.24, No.5,603-619,2002.
[6] 盧小寶,王維蘭.基于樣本塊的唐卡圖像修復(fù)算法的改進(jìn)[J].計(jì)算機(jī)應(yīng)用.2010,30(4):943-946,2010.
udp協(xié)議范文第7篇
關(guān)鍵詞：UDP協(xié)議；Socket；網(wǎng)絡(luò)通信
中圖分類號(hào)：TP393文獻(xiàn)標(biāo)識(shí)碼：A文章編號(hào)：1009-3044(2008)34-1867-02
Socket Network Programs Based on UDP Protocol
ZHOU Li-juan
(College of Science, Hunan University of Technology, Zhuzhou 412008, China)
Abstract: Windows Socket is a network programming interface,and applications can correspond to eachother in different domains without worrying about the different protocols by using it.This paper introduces the mechanism and principle of Socket network programs based on UDP protocol,and proposes a method of network with Java socket.
key words: UDP protocol;socket; network communication
Socket適用于網(wǎng)絡(luò)環(huán)境中的進(jìn)程間通信，它已成為當(dāng)前許多操作系統(tǒng)的網(wǎng)絡(luò)API，也是網(wǎng)絡(luò)操作系統(tǒng)中必不可少的基礎(chǔ)功能。隨著Linux操作系統(tǒng)和Internet的不斷發(fā)展，Linux網(wǎng)絡(luò)環(huán)境下尤其是基于UDP的socket通信技術(shù)仍廣為注目。文章介紹了socket的編程原理，并通過一個(gè)Java編寫的客戶/服務(wù)器程序，描述了網(wǎng)絡(luò)中基于UDP的不同主機(jī)上的兩個(gè)進(jìn)程之間的socket通信機(jī)制。
1 Socket通信機(jī)制
Socket（套接字）機(jī)制是一種API，是網(wǎng)絡(luò)應(yīng)用程序的編程接口。Socket是通過標(biāo)準(zhǔn)文件描述符和其它程序通訊的一個(gè)方法。每一個(gè)套接字都用一個(gè)半相關(guān)描述：{協(xié)議，本地地址、本地端口}來表示；一個(gè)完整的套接字則用一個(gè)相關(guān)描述：{協(xié)議，本地地址、本地端口、遠(yuǎn)程地址、遠(yuǎn)程端口}，每一個(gè)套接字都有一個(gè)本地的由操作系統(tǒng)分配的唯一的套接字號(hào)。
根據(jù)傳輸數(shù)據(jù)類型的不同，Socket主要分為三類：1) 流式Socket（SOCK_STREAM），在這種方式下，兩個(gè)通訊的應(yīng)用程序之間要先建立一種虛擬的連接，提供可靠的、面向連接的通信流，它使用TCP協(xié)議，從而保證了數(shù)據(jù)傳輸?shù)恼_性和順序的。2) 數(shù)據(jù)報(bào)Socket（SOCK_DGRAM），它使用數(shù)據(jù)報(bào)協(xié)議UDP，定義了一種無連接的服務(wù)，數(shù)據(jù)通過相互獨(dú)立的報(bào)文進(jìn)行傳輸，是無序的，并且不保證可靠、無差錯(cuò)。3) 原始Socket，原始套接字允許對(duì)底層協(xié)議如IP或ICMP直接訪問，它功能強(qiáng)大但使用較為不便，主要用于一些協(xié)議的開發(fā)。
2 UDP協(xié)議的工作原理
UDP協(xié)議是一個(gè)面向無連接的協(xié)議，其連接的建立不必像TCP那樣需要服務(wù)器端偵聽，也不需要有客戶機(jī)請(qǐng)求連接，屬于一種“強(qiáng)制”性的網(wǎng)絡(luò)連接。UDP提供一對(duì)一或一對(duì)多的、無連接的數(shù)據(jù)報(bào)服務(wù)。該服務(wù)對(duì)消息中傳輸?shù)臄?shù)據(jù)提供不可靠的、最大努力的傳送，這意味著它不保證數(shù)據(jù)的到達(dá)，也不保證所傳送的數(shù)據(jù)報(bào)的順序是否正確，UDP不重新傳輸丟失的數(shù)據(jù)。其主要工作是：將應(yīng)用程序傳輸過來的數(shù)據(jù)分塊交給網(wǎng)絡(luò)層，確認(rèn)接受到分組信息。
盡管UDP無法像TCP一樣提供可靠的數(shù)據(jù)傳輸，但UDP并不比TCP缺乏優(yōu)越性。UDP在傳輸效率方面比TCP要高一些，而且許多應(yīng)用程序并不需要保證嚴(yán)格的傳輸可靠性，比如視頻會(huì)議系統(tǒng)等，需要實(shí)時(shí)的交互，但并不要求音頻視頻的絕對(duì)正確。
使用UDP協(xié)議傳輸數(shù)據(jù)時(shí)，首先設(shè)置客戶計(jì)算機(jī)的Local Port(本地端口)屬性，而作為服務(wù)器的計(jì)算機(jī)只需要設(shè)置Remoter Host(遠(yuǎn)程主機(jī))屬性為客戶計(jì)算機(jī)的IP地址或域名即可，并將其Remote Port屬性設(shè)置為客戶計(jì)算機(jī)上的Local Port屬性。使用UDP端口號(hào)時(shí)，端口提供了用于發(fā)送消息的位置，每個(gè)端口由一個(gè)唯一的編號(hào)來標(biāo)識(shí)。當(dāng)應(yīng)用程序向另一臺(tái)計(jì)算機(jī)發(fā)送數(shù)據(jù)時(shí)，UDP生成一個(gè)數(shù)據(jù)頭，包括源端口，這些端口提供送達(dá)信息所需要的地址。UDP協(xié)議還為數(shù)據(jù)和數(shù)據(jù)頭計(jì)算出求和檢驗(yàn)的值，在目標(biāo)計(jì)算機(jī)中，數(shù)據(jù)包被傳遞至UDP協(xié)議程序并送到目的地端口。
3 UDP套接字的通信過程
中提供了兩個(gè)類DatagramSocket和DatagramPacket用來支持?jǐn)?shù)據(jù)報(bào)通信。DatagramSoc ket用來在程序之間建立傳送數(shù)據(jù)報(bào)的通信連接，是數(shù)據(jù)報(bào)通信中的Socket。在數(shù)據(jù)報(bào)實(shí)現(xiàn)C/S通信程序時(shí)，無論在客戶端還是服務(wù)器端，都要首先建立一個(gè)DatagramSocket對(duì)象，用來表示數(shù)據(jù)報(bào)通信的端點(diǎn)，應(yīng)用程序通過Socket接收或發(fā)送數(shù)據(jù)報(bào)。
DatagramPacket則用來表示一個(gè)數(shù)據(jù)報(bào)，它是傳輸數(shù)據(jù)的載體，封裝了數(shù)據(jù)、數(shù)據(jù)長度、數(shù)據(jù)報(bào)地址等信息。
采用UDP套接字方式實(shí)現(xiàn)C/S的通信程序由客戶端和服務(wù)器端兩部分組成。服務(wù)器進(jìn)程依次按以下步驟進(jìn)行：1) 調(diào)用Socket()創(chuàng)建一個(gè)數(shù)據(jù)報(bào)套接字；2) 調(diào)用bind()把服務(wù)器地址綁定在該套接字上；3) 調(diào)用recvform()等待客戶進(jìn)程發(fā)來的請(qǐng)求，服務(wù)器此時(shí)處于無限循環(huán)狀態(tài)；4) 服務(wù)進(jìn)程接收到客戶進(jìn)程所發(fā)來的數(shù)據(jù)報(bào)后，進(jìn)行處理，調(diào)用sendto()將處理結(jié)果返回給客戶進(jìn)程，返回狀態(tài)3)，繼續(xù)監(jiān)聽；5)服務(wù)進(jìn)程調(diào)用close()撤消套接字，終止服務(wù)。
客戶進(jìn)程則按以下步驟進(jìn)行：1) 調(diào)用Socket()創(chuàng)建一個(gè)數(shù)據(jù)流套接字；2) 調(diào)用sendto()向服務(wù)器進(jìn)程發(fā)送數(shù)據(jù)報(bào)；3) 調(diào)用recvfrom()等待服務(wù)器進(jìn)程返回該處理結(jié)果；4) 客戶進(jìn)程調(diào)用close()撤消套接字。
4 數(shù)據(jù)報(bào)通信實(shí)例
程序由服務(wù)器端和客戶端兩部分組成，服務(wù)器端主機(jī)中有一個(gè)名為“udp_socket.txt”文件，文件中保存了一段英文。服務(wù)器端接收一個(gè)客戶端的請(qǐng)求，就從文件中讀取若干個(gè)英文字符發(fā)送給客戶端。當(dāng)文件中所有內(nèi)容發(fā)送給完畢，服務(wù)器端程序?qū)⑼顺觥？蛻舳耸紫葮?gòu)造一個(gè)數(shù)據(jù)報(bào)發(fā)送給服務(wù)器端，然后等待接受服務(wù)器端響應(yīng)，當(dāng)接收到服務(wù)器端的數(shù)據(jù)報(bào)后，顯示數(shù)據(jù)并結(jié)束通信。
1) 服務(wù)器端程序
public class Server_Th
{ boolean m_q=true;
public void serverWork() throea IOException
{DatagramSocket ds=new DatagramSocket(2000)
//創(chuàng)建端口號(hào)為2000的數(shù)據(jù)報(bào)套接字
BufferedReader in=new BufferedReader(new FileReader (“udp_socket.txt”));
while(m_q)
{ byte buf[ ]=new byte[256];//創(chuàng)建緩沖區(qū)
DatagramPacket packet=new DatagramPacket (buf, buflength); //創(chuàng)建接收數(shù)據(jù)報(bào)對(duì)象
ds.receive(packet);//接收數(shù)據(jù)報(bào)
String dString=null;
if((dString=in.reaLine())==null)
{in.close();
m_q=false;
dString=”Good Morning!”;}
buf=dString.getBytes();//將數(shù)據(jù)存儲(chǔ)到buf中
inetAddress address=packet.getAddress();
//得到客戶端IP地址
int prot=packet.getPort();//得到客戶端的端口
packet=new DatagramPacket (buf,buf.length, address. port );
//構(gòu)造要發(fā)送數(shù)據(jù)報(bào)
ds.send(packet);//發(fā)送數(shù)據(jù)報(bào)
}
ds.close();//關(guān)閉
}
public void main(String args[])
{ Server_Th server=new Server_Th();
try
{server.serverWork();}
Catch(IOException e){}
}}
2) 客戶端程序
public class Client_Th
{public void main(String args[ ]) throws IOException
{ DatagramSocket socket=new DatagramSocket( );
//創(chuàng)建套接字對(duì)象
byte buf[ ]=new byte[256];
InetAdress address=InetAddress.getByName(“20.14.30.9”);
//服務(wù)器IP地址
DatagramPacket packet=new DatagramPacket(buf,buf. Length,address,2000);//創(chuàng)建要發(fā)送的數(shù)據(jù)報(bào)對(duì)象
socket.send(packet);//接收數(shù)據(jù)報(bào)
packet=new DatagramPacket(buf,buf.length);
//創(chuàng)建要接收的數(shù)據(jù)報(bào)對(duì)象
socket.receive(packet);//接收數(shù)據(jù)報(bào)
String received=new String(packet.getData());
System.out.println(“The string form the server: ”+recerived);
//取得數(shù)據(jù)報(bào)中的數(shù)據(jù)并顯示
Socket.close();//關(guān)閉socket
}}
編寫程序時(shí)客戶端和服務(wù)器端的DatagramSocket必須用一個(gè)端口，因?yàn)榭蛻舳讼蚍?wù)器端請(qǐng)求時(shí)，服務(wù)器需要知道從哪個(gè)端口監(jiān)聽請(qǐng)求。當(dāng)數(shù)據(jù)進(jìn)行傳輸時(shí)，服務(wù)器從接收到的數(shù)據(jù)報(bào)中得到客戶端的接收數(shù)據(jù)的端口，然后將數(shù)據(jù)報(bào)發(fā)送到這個(gè)端口，客戶端則監(jiān)聽這個(gè)端口而得到服務(wù)器端發(fā)送過來的數(shù)據(jù)報(bào)并顯示其內(nèi)容。運(yùn)行時(shí)要先運(yùn)行服務(wù)器端程序，再運(yùn)行客戶端程序。
5 小結(jié)
Socket在網(wǎng)絡(luò)編程方面發(fā)揮著很大的作用。UDP是可靠性無法得到保障的協(xié)議，但對(duì)于質(zhì)量要求不是很高的網(wǎng)絡(luò)應(yīng)用程序，UDP是一個(gè)很好的選擇。
參考文獻(xiàn)：
[1] 張桂珠.Java面向?qū)ο蟪绦蛟O(shè)計(jì)[M].北京:郵電出版社,2006.
[2] 周坤,傅德勝.基于Windows Socket的網(wǎng)絡(luò)數(shù)據(jù)傳輸及其安全[J].計(jì)算機(jī)工程與設(shè)計(jì),2007,28(22):5381-5386.
[3] 趙文清.淺析用Socket的Java語言網(wǎng)絡(luò)通訊機(jī)制和程序設(shè)計(jì)[J].信息技術(shù),2002(7):66-67.
udp協(xié)議范文第8篇
關(guān)鍵詞：UDP 協(xié)議 FPGA
中圖分類號(hào)：TP393 文獻(xiàn)標(biāo)識(shí)碼：A 文章編號(hào)：1007-9416（2016）05-0000-00
傳輸控制協(xié)議/網(wǎng)際協(xié)議（Transmission Control Protocol/ Internet Protocol，TCP/IP）協(xié)議簇是Internet 和全球各地網(wǎng)絡(luò)互聯(lián)的引擎。本文針對(duì)網(wǎng)際層IP協(xié)議下的一項(xiàng)功能的實(shí)現(xiàn)，主要是針對(duì)從UDP協(xié)議下的數(shù)據(jù)包處理的過程。UDP是一個(gè)簡單的面向數(shù)據(jù)報(bào)的運(yùn)輸層協(xié)議：進(jìn)程的每個(gè)輸出操作都正好產(chǎn)生一個(gè)UDP數(shù)據(jù)報(bào)，并組裝成一份待發(fā)送的IP數(shù)據(jù)報(bào)。
1數(shù)據(jù)報(bào)處理方案
1.1端口設(shè)計(jì)
端口應(yīng)該由外部端口和內(nèi)部端口組成。外部端口是控制硬件（以FPGA為例），主要包括時(shí)鐘輸入信號(hào)和復(fù)位輸入信號(hào)。內(nèi)部端口為運(yùn)輸層與網(wǎng)絡(luò)層相互聯(lián)系為原則設(shè)計(jì)的，不僅需要數(shù)據(jù)輸入輸出，也需要這兩個(gè)模塊間的相互控制。具體內(nèi)部端口主要包括數(shù)據(jù)輸入輸出信號(hào)及對(duì)應(yīng)的數(shù)據(jù)同步信號(hào)，兩個(gè)準(zhǔn)備信號(hào)，兩個(gè)IP地址輸入信號(hào)和輸入同步信號(hào)的結(jié)束信號(hào)。信號(hào)描述如下：
時(shí)鐘信號(hào)（clk）、復(fù)位信號(hào)（res）、UDP準(zhǔn)備信號(hào)（udprd）、輸入數(shù)據(jù)信號(hào)（isd）：、輸入數(shù)據(jù)同步信號(hào)（iss）、輸入數(shù)據(jù)結(jié)束信號(hào)（ise）、源IP地址（sipa）：、目的IP地址（dipa）、IP準(zhǔn)備信號(hào)（iprd）、輸出數(shù)據(jù)信號(hào)（osd）、輸出數(shù)據(jù)同步信號(hào)（oss）。
具體端口設(shè)置如圖1：
1.2 功能模塊
1.2.1 建立連接模塊
運(yùn)輸層和網(wǎng)絡(luò)層之間有很多協(xié)議，不同協(xié)議對(duì)應(yīng)不同數(shù)據(jù)包，如何選擇合適通路選擇特定數(shù)據(jù)包，這就要求有特定的連接過程完成特定的數(shù)據(jù)傳輸。
為了建立UDP協(xié)議數(shù)據(jù)和IP數(shù)據(jù)之間的相互通信，在方案中，選擇增添一個(gè)建立連接模塊，目的是完成兩個(gè)功能。首先是完成UDP協(xié)議下的數(shù)據(jù)在特定通道內(nèi)向網(wǎng)絡(luò)層的傳輸，其次是產(chǎn)生控制信號(hào)，控制下一模塊工作狀態(tài)。在此過程中，主要涉及到兩個(gè)信號(hào)，其一是udprd信號(hào)，是建立連接第一步，這個(gè)信號(hào)旨在反映UDP數(shù)據(jù)報(bào)已經(jīng)準(zhǔn)備好發(fā)送；其二是iprd信號(hào)，建立連接第二步，本信號(hào)是為了給運(yùn)輸層的UDP協(xié)議的反饋信號(hào)，如果接到收此信號(hào)，UDP數(shù)據(jù)報(bào)就開始發(fā)送了。本信號(hào)還有一個(gè)功能：當(dāng)網(wǎng)絡(luò)層對(duì)數(shù)據(jù)處理時(shí)，此信號(hào)會(huì)自動(dòng)變低電平，將不會(huì)接收UDP數(shù)據(jù)報(bào)，直到在網(wǎng)絡(luò)層的數(shù)據(jù)處理完畢。
1.2.2 數(shù)據(jù)接收存儲(chǔ)模塊
在此模塊下，可分為數(shù)據(jù)接收部分和數(shù)據(jù)的存儲(chǔ)部分。
首先介紹一下數(shù)據(jù)的接收部分，當(dāng)大量的數(shù)據(jù)報(bào)準(zhǔn)備進(jìn)入網(wǎng)絡(luò)層時(shí)，有些數(shù)據(jù)是沒有意義的，所以要準(zhǔn)確有效的接收來自UDP協(xié)議下的數(shù)據(jù)報(bào)，需要在這一部分完成此功能。在端口的設(shè)置，增加了同步接收信號(hào)和終止信號(hào)，當(dāng)同步信號(hào)有效，數(shù)據(jù)為有效數(shù)據(jù)，當(dāng)終止信號(hào)有效，則一個(gè)完整的UDP數(shù)據(jù)包就發(fā)送完成了。
當(dāng)大量的UDP數(shù)據(jù)包進(jìn)入到IP協(xié)議下準(zhǔn)備處理，而處理速度是遠(yuǎn)遠(yuǎn)小于接收的速度，會(huì)導(dǎo)致數(shù)據(jù)的滯留，甚至數(shù)據(jù)會(huì)丟失。為了解決該問題，增加了一個(gè)數(shù)據(jù)存儲(chǔ)模塊，把數(shù)據(jù)存儲(chǔ)下來，彌補(bǔ)了處理速度和接收速度的不匹配。
此模塊還額外的完成了一個(gè)功能：計(jì)數(shù)功能。在加I P數(shù)據(jù)頭需要每一包UDP數(shù)據(jù)包字節(jié)的長度信息進(jìn)行存儲(chǔ)。
1.2.3 IP數(shù)據(jù)包頭處理及發(fā)送模塊
每一份的IP數(shù)據(jù)包都是有IP數(shù)據(jù)包頭和對(duì)應(yīng)的UDP數(shù)據(jù)包組合成的。需要將其對(duì)應(yīng)封裝。
當(dāng)IP數(shù)據(jù)包頭處理完成了，緊接任務(wù)就是將其發(fā)送出去。在發(fā)送完IP數(shù)據(jù)包頭緊跟要發(fā)送其對(duì)應(yīng)的UDP數(shù)據(jù)包，這就是一個(gè)完整的IP數(shù)據(jù)包。如果輸出同步信號(hào)有效，這些處理好的數(shù)據(jù)將發(fā)送到數(shù)據(jù)鏈路層供其使用。
2方案綜述
（1）運(yùn)輸層和網(wǎng)絡(luò)層之間建立連接，保證數(shù)據(jù)準(zhǔn)確無誤差的傳輸?shù)骄W(wǎng)絡(luò)層，產(chǎn)生控制信號(hào)，控制數(shù)據(jù)的接收；產(chǎn)生反饋信號(hào)，保證運(yùn)輸層的UDP數(shù)據(jù)包適時(shí)的傳送過來。（2）讀取UDP數(shù)據(jù)包并準(zhǔn)確的計(jì)數(shù)，將已讀的數(shù)據(jù)存入緩存中，產(chǎn)生信號(hào)，控制IP頭處理模塊的啟動(dòng)，然后將必要數(shù)據(jù)傳遞到IP頭處理模塊。（3）處理數(shù)據(jù)，將對(duì)應(yīng)的一包UDP數(shù)據(jù)產(chǎn)生相應(yīng)的IP數(shù)據(jù)包頭，形成一個(gè)IP數(shù)據(jù)包。然后將包頭發(fā)送，產(chǎn)生輸出的同步信號(hào)，之后產(chǎn)生信號(hào)讀取緩存中的數(shù)據(jù)，通過輸出端口將其發(fā)送出去。
這就是一個(gè)UDP數(shù)據(jù)包的處理過程，不斷反復(fù)以上步驟，UDP數(shù)據(jù)段就轉(zhuǎn)變成了IP數(shù)據(jù)段。
本方案增加了同步數(shù)據(jù)的輸出信號(hào)，這就可以自由的控制輸入輸出數(shù)據(jù)，不會(huì)導(dǎo)致數(shù)據(jù)的意外丟失。而這些信號(hào)還可以支持?jǐn)?shù)據(jù)間斷輸入，給運(yùn)輸層數(shù)據(jù)傳輸很大的靈活性；還增加了udp和iprd信號(hào)，它們完成這兩個(gè)層連接，給數(shù)據(jù)傳輸提供良好的初始條件。
參考文獻(xiàn)
[1]TCP-IP詳解（中文）.pdf.
[2]張帆.《基于FPGA的IP協(xié)議處理器》.湖南大學(xué)碩士論文.
udp協(xié)議范文第9篇
關(guān)鍵詞：可靠UDP；確認(rèn)重傳；滑動(dòng)窗口
中圖分類號(hào)：TP311 文獻(xiàn)標(biāo)識(shí)碼：A 文章編號(hào)：1009-3044（2015）09-0071-03
Abstract：In data transmission network， compared with the other protocol， UDP protocol has certain advantages in speed， but there is also the transmission reliability is poor and the problem of lack of congestion control mechanism in this paper， on the basis of the UDP protocol， by adding a simple three-way handshake， confirm the retransmission mechanism， the sliding window mechanism， designed a reliable transport protocol based on UDP， make it between the reliability and efficiency to achieve a good unity and compromise， and implementation of the agreement of the main module has made a detailed description and the actual test.
Key words： reliable UDP； confirm the retransmission； the sliding window
由于傳統(tǒng)的數(shù)據(jù)傳輸協(xié)議所針對(duì)的業(yè)務(wù)不同，在數(shù)據(jù)傳輸?shù)乃俣群涂煽啃灾g不能達(dá)到很好的平衡。車險(xiǎn)理賠系統(tǒng)中采用的是移動(dòng)理賠的思想，手持終端機(jī)通過移動(dòng)通信網(wǎng)絡(luò)和后臺(tái)中心系統(tǒng)進(jìn)行數(shù)據(jù)交互。目前國內(nèi)的通信事業(yè)并不是很發(fā)達(dá)，信號(hào)覆蓋率并不全面，移動(dòng)通信網(wǎng)絡(luò)的帶寬和傳輸質(zhì)量會(huì)受到地域的影響，為確保理賠現(xiàn)場(chǎng)與后臺(tái)系統(tǒng)間數(shù)據(jù)的及時(shí)可靠傳輸，需要基于移動(dòng)通信的網(wǎng)絡(luò)環(huán)境設(shè)計(jì)高效可靠的數(shù)據(jù)傳輸功能。本章在UDP傳輸協(xié)議基礎(chǔ)上，通過應(yīng)用層封裝和可靠性設(shè)計(jì)的方法，采用數(shù)據(jù)包的確認(rèn)重傳、流量控制等機(jī)制，設(shè)計(jì)并實(shí)現(xiàn)基于UDP協(xié)議的可靠數(shù)據(jù)傳輸功能。
1 TCP與UDP的對(duì)比
TCP和UDP都屬于傳輸層協(xié)議，負(fù)責(zé)承擔(dān)數(shù)據(jù)傳輸?shù)娜蝿?wù)[1]。兩者之間的主要區(qū)別有：
（1） TCP和UDP是傳輸層的兩個(gè)協(xié)議，它們最大的區(qū)別是是否面向連接。TCP，在客戶端和服務(wù)器端進(jìn)行通信之前，首先要交換傳輸層控制信息，為雙方的通信做好準(zhǔn)備。UDP是一個(gè)非連接的協(xié)議，傳輸數(shù)據(jù)之前雙方不建立連接，當(dāng)傳送數(shù)據(jù)時(shí)，簡單的抓取來自應(yīng)用程序的數(shù)據(jù)，并盡可能快的把數(shù)據(jù)傳送到網(wǎng)絡(luò)上。
（2） UDP協(xié)議的數(shù)據(jù)傳輸不需要維護(hù)收發(fā)狀態(tài)和連接狀態(tài)等，與TCP相比，網(wǎng)絡(luò)有效利用率得到很大的提高。
（3） TCP協(xié)議提供數(shù)據(jù)確認(rèn)重傳、擁塞控制等可靠性保證，UDP協(xié)議不提供可靠性保證，也不提供流量控制。
TCP協(xié)議由于需要確認(rèn)的狀態(tài)和對(duì)數(shù)據(jù)包的操作過多，數(shù)據(jù)傳輸?shù)乃俣炔桓咔揖W(wǎng)絡(luò)延遲較大，所以雖然協(xié)議可靠但并不適合面向移動(dòng)通信的數(shù)據(jù)傳輸；而UDP協(xié)議由于不用建立連接，沒有超時(shí)重發(fā)等可靠機(jī)制，網(wǎng)絡(luò)延遲小且數(shù)據(jù)傳輸速度很快。本文設(shè)計(jì)的理賠系統(tǒng)面向移動(dòng)通信網(wǎng)絡(luò)實(shí)現(xiàn)理賠現(xiàn)場(chǎng)與后臺(tái)系統(tǒng)間的數(shù)據(jù)傳輸，網(wǎng)絡(luò)環(huán)境不如光纖接入網(wǎng)絡(luò)穩(wěn)定可靠，對(duì)數(shù)據(jù)的高效可靠傳輸有著很高的要求。因此，本章選用UDP協(xié)議，并在其基礎(chǔ)上，設(shè)計(jì)了連接確認(rèn)、數(shù)據(jù)確認(rèn)等可靠機(jī)制，滿足了系統(tǒng)對(duì)于高效可靠傳輸功能的需求。
2基于UDP 改進(jìn)的可靠傳輸協(xié)議實(shí)現(xiàn)
2.1 主要功能模塊及任務(wù)結(jié)構(gòu)
綜合文獻(xiàn)【2】的可靠機(jī)制描述，可靠UDP數(shù)據(jù)傳輸協(xié)議的模塊結(jié)構(gòu)如圖1所示。
從模塊結(jié)構(gòu)上看，本模塊主要由以下幾個(gè)任務(wù)實(shí)現(xiàn)模塊功能：
? 通信處理模塊
1） 發(fā)送方發(fā)起數(shù)據(jù)傳輸請(qǐng)求，三次握手成功后，發(fā)送方進(jìn)入數(shù)據(jù)包封裝模塊。
2） 超時(shí)定時(shí)器的啟動(dòng)和關(guān)閉。
3） 當(dāng)數(shù)據(jù)傳輸結(jié)束時(shí)，接收方向發(fā)送方主動(dòng)發(fā)起傳輸結(jié)束的請(qǐng)求。
? 數(shù)據(jù)包封裝/解析模塊
1） 發(fā)送方將要發(fā)送的的數(shù)據(jù)按照協(xié)商大小分塊，排序。
2） 發(fā)送方將分塊的數(shù)據(jù)協(xié)商的數(shù)據(jù)報(bào)文結(jié)構(gòu)封裝成要發(fā)送的消息包。
3） 接收方讀取數(shù)據(jù)包后根據(jù)協(xié)商的數(shù)據(jù)報(bào)文結(jié)構(gòu)拆分?jǐn)?shù)據(jù)包，根據(jù)數(shù)據(jù)包的類型讀取信息。
? 消息發(fā)送/接收模塊
1） 發(fā)送方判斷發(fā)送隊(duì)列和消息隊(duì)列是否為空后，將要發(fā)送的數(shù)據(jù)包處理后發(fā)送。
2） 接收方從接收隊(duì)列中讀取數(shù)據(jù)包。
? 數(shù)據(jù)重組模塊
1） 由于網(wǎng)絡(luò)問題，發(fā)送方按序發(fā)送的數(shù)據(jù)包不一定會(huì)按序到達(dá)，所以接收方在經(jīng)過數(shù)據(jù)包解析模塊讀取數(shù)據(jù)后，根據(jù)該消息的字節(jié)序號(hào)判斷是否為亂序的分組。
2） 若是順序的分組，將分組與以前收到的消息按序排列；若是要求重傳的分組，將該分組放入到所應(yīng)在的位置中。
3） 如果滿足重發(fā)條件，則向發(fā)送方發(fā)送重發(fā)包請(qǐng)求。
2.2 核心事件處理流程
2.2.1 通信處理進(jìn)程
通信處理模塊中的通信處理進(jìn)程主要負(fù)責(zé)三次握手的發(fā)起和確認(rèn)的請(qǐng)求，數(shù)據(jù)傳輸結(jié)束后結(jié)束連接等任務(wù)。具體流程見圖2。首先，通信的接收方發(fā)起握手的請(qǐng)求，即建立一個(gè)虛連接，雙方必須確保該連接成功建立后才可以進(jìn)行下一步數(shù)據(jù)傳輸?shù)牟僮鳌Ｈ缓螅诮邮辗揭欢藛?dòng)定時(shí)器，接收方的數(shù)據(jù)處理進(jìn)程接收發(fā)送方發(fā)送的數(shù)據(jù)，同時(shí)接收方根據(jù)定時(shí)計(jì)時(shí)器發(fā)送反饋消息；或判斷接收到的報(bào)文數(shù)，當(dāng)達(dá)到數(shù)據(jù)包累積計(jì)數(shù)器設(shè)定的數(shù)值時(shí)，向發(fā)送方發(fā)送反饋消息。
2.2.2 發(fā)送方發(fā)送報(bào)文
數(shù)據(jù)報(bào)文的發(fā)送，主要是發(fā)送方向接收方發(fā)送數(shù)據(jù)報(bào)文和消息報(bào)文，流程如圖3所示，具體的算法為：
if（發(fā)送隊(duì)列非空）
{
從隊(duì)列中取出消息；
if （消息類型為數(shù)據(jù)包）
發(fā)送數(shù)據(jù)包；
else 發(fā)送確認(rèn)包；
}
else if （消息隊(duì)列非空）
{
打包要發(fā)送的數(shù)據(jù)并將數(shù)據(jù)放入發(fā)送隊(duì)列中；
套接口處當(dāng)前序號(hào)加1；
}
3 實(shí)驗(yàn)結(jié)果與分析
3.1 開發(fā)環(huán)境
系統(tǒng)的編程實(shí)現(xiàn)是在Windows XP上進(jìn)行的，使用的編程工具為Visual C++6.0。
3.2 系統(tǒng)測(cè)試
3.2.1 測(cè)試環(huán)境
本測(cè)試是是在無線通信網(wǎng)絡(luò)下進(jìn)行的，配置了兩臺(tái)計(jì)算機(jī)用作數(shù)據(jù)間收發(fā)的測(cè)試，操作系統(tǒng)為Windows XP。華為E261 3G上網(wǎng)卡兩張，用于連接無線網(wǎng)絡(luò)，測(cè)試拓?fù)浣Y(jié)構(gòu)如圖4所示。
3.2.2 測(cè)試內(nèi)容
本測(cè)試采用傳輸不同大小文件的方式來對(duì)數(shù)據(jù)速度進(jìn)行測(cè)試，每次傳輸重復(fù)測(cè)試三次，然后取平均值作為參考數(shù)據(jù)，測(cè)試結(jié)果見表1和表2。其中，表1是在最大連接速率7.2Mbps環(huán)境下的測(cè)試結(jié)果，表2是在連接速率為2.2Mbps環(huán)境下的測(cè)試結(jié)果。
由表1可見，在移動(dòng)通信的網(wǎng)絡(luò)連接環(huán)境為7.2Mbps時(shí)，當(dāng)傳輸1MB的數(shù)據(jù)時(shí)，TCP協(xié)議測(cè)試耗時(shí)9.75s，平均傳輸速度約為105KB/s；可靠UDP耗時(shí)8.25s，平均傳輸速度約為124KB/s。當(dāng)傳輸數(shù)據(jù)為32MB時(shí)，TCP耗時(shí)295.89s，平均傳輸速度約為120KB/s；可靠UDP耗時(shí)197.05s平均傳輸速度約為168KB/s。
由表2可見，在移動(dòng)通信的網(wǎng)絡(luò)連接環(huán)境為2.2Mbps時(shí)，由于連接環(huán)境較差，測(cè)試文件并不大，當(dāng)傳輸0..36s，平均傳輸速度約為21KB/s；可靠UDP耗時(shí)190.81s，平均傳輸速度約為43KB/s。
由此可得出：
（1） 可靠UDP傳輸協(xié)議的優(yōu)勢(shì)隨著傳輸數(shù)據(jù)量的增大而越來越明顯。
（2） 可靠UDP傳輸協(xié)議的優(yōu)勢(shì)隨著網(wǎng)絡(luò)環(huán)境的變差而越來越明顯。
參考文獻(xiàn)：
[1] Douglas er. 用TCP/IP進(jìn)行網(wǎng)際互聯(lián)――原理、協(xié)議與結(jié)構(gòu)（第五版）[M]. 林瑤， 張娟， 王海，等譯. 北京：電子工業(yè)出版社，2009.
[2] 王玨， 何秋燕， 王露凱.基于UDP 改進(jìn)的可靠傳輸協(xié)議設(shè)計(jì)[J].電子世界，2014（22）.
[3] 王繼剛， 顧國昌， 徐立峰，等.可靠UDP數(shù)據(jù)傳輸協(xié)議的研究與設(shè)計(jì)[J].計(jì)算機(jī)工程與應(yīng)用，2006（15）：113-116.
[4] 靳海力.一種增強(qiáng)型可靠UDP的設(shè)計(jì)及應(yīng)用[D].合肥：中國科學(xué)技術(shù)大學(xué)，2009.
本文鏈接：http://m.9105763.cn/v-141-2653.htmludp協(xié)議范文10篇
相關(guān)文章：
一二三年級(jí)手抄報(bào)父親節(jié)06-16
二年級(jí)元宵節(jié)手抄報(bào)內(nèi)容03-26
績效管理自查報(bào)告12-11
小朋友生日快樂祝詞11-27
八個(gè)字祝福祖國的話09-27
勤奮好學(xué)的經(jīng)典語錄08-31
最新幼兒園班級(jí)管理工作總結(jié)名稱(13篇)10-14
簡單的員工年終總結(jié)08-24
讀水滸傳的讀書筆記800字06-02
小學(xué)生秋天作文04-21
貪吃的表妹作文03-10
描寫彩虹好詞和好句09-27
安徒生童話讀書筆記07-26
重慶工商大學(xué)和重慶理工大學(xué)哪個(gè)好02-24