當(dāng)前位置：首頁 > 文庫 > 文案

udp協(xié)議范文10篇

時間：2024-08-15 14:07:31 197

udp協(xié)議

udp協(xié)議范文第1篇

關(guān)鍵詞:用戶數(shù)據(jù)報(bào)協(xié)議;通信;報(bào)文分析;Sniffer

中圖分類號:TP312 文獻(xiàn)標(biāo)識碼:A 文章編號: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é)議的接口,用端口號分別為運(yùn)行在同一設(shè)備上的多個應(yīng)用程序提供服務(wù)。它定義在IETF RFC 768中[1]。

UDP是分發(fā)信息的理想?yún)f(xié)議,適用于追求效率且不需要額外可靠機(jī)制的情形,如音、視頻流媒體分發(fā)、高層協(xié)議或應(yīng)用程序提供錯誤和流控制功能時的快速數(shù)據(jù)分發(fā)。 UDP服務(wù)于很多知名應(yīng)用,如網(wǎng)絡(luò)文件系統(tǒng)(NFS)、簡單網(wǎng)絡(luò)管理協(xié)議(SNMP)、域名系統(tǒng)(DNS)以及簡單文件傳輸系統(tǒng)(TFTP)、動態(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é)議,以動態(tài)鏈接庫及API的形式提供給用戶程序調(diào)用。這種方式方便了程序設(shè)計(jì),但也阻止了用戶對網(wǎng)絡(luò)協(xié)議的更深理解。為了更加深入研究UDP有必要對傳輸報(bào)文流進(jìn)行分析;為了更好的分析,需要實(shí)現(xiàn)一個使用UDP的通信程序。

在windows下選用VC6.0編譯器。服務(wù)器端代碼如下:

#include //基本輸入輸出庫

#include //網(wǎng)絡(luò)API函數(shù)庫

#pragma comment (lib,"WS2_32.lib")/*將WS2_32.lib加入鏈接,不用再為這個鏈接文件設(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];//暫時緩存

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];//暫時緩存

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個字節(jié),報(bào)文開頭的00到08 00(IP報(bào)文頭前)14個字節(jié)為DLC(Data Link Control)報(bào)文頭。UDP報(bào)文中,0c 96源端口號,兩字節(jié),客戶端用于接收信息的端口號,不需要回復(fù)可用全零。1a 0a 目的端口號,兩字節(jié),服務(wù)器端的接收端口號。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ā)的一個空字節(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源端口號,0b 96目的端口號,與前一報(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ā)了一個空字節(jié)。

由協(xié)議分析可知,UDP位于IP報(bào)文的數(shù)據(jù)域中,由源端口、目的端口、長度、校驗(yàn)和、和數(shù)據(jù)域組成,采用明文傳遞應(yīng)用數(shù)據(jù)。如果傳遞重要信息一定要在應(yīng)用層加密,否則很容易被竊取。UDP在發(fā)送數(shù)據(jù)時附帶自身的端口號,接收時不需要確認(rèn),所以可以方便的進(jìn)行一對一、一對多和多對多的交互通信,這種方式方便但存在缺陷,如果被攻擊者知道服務(wù)的端口號,控制多臺主機(jī)向服務(wù)器發(fā)送大量垃圾信息,可使服務(wù)器癱瘓。這是此類協(xié)議的共有的弱點(diǎn)。

3 結(jié)束語

傳輸層的UDP協(xié)議由于其簡潔、高效性而被廣泛使用,是一種重要的協(xié)議。該文介紹的UDP協(xié)議使用方法具有通用性,可作為開發(fā)、學(xué)習(xí)此類軟件參考。UDP協(xié)議由于沒有安全控制,采用UDP協(xié)議的系統(tǒng)在提供服務(wù)時最好放在防火墻內(nèi),由系統(tǒng)對它提供安全保證。

參考文獻(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].吳時霖,等,譯.北京:機(jī)械工業(yè)出版社,2007.7,445-472.

udp協(xié)議范文第2篇

關(guān)鍵詞：P2P；CDP；NAT 穿透；基于UDP的TCP

中圖分類號：TP317文獻(xiàn)標(biāo)識碼：A 文章編號：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)從各個方面深入人心。這些產(chǎn)品在網(wǎng)絡(luò)實(shí)現(xiàn)技術(shù)上，都以各自的方法解決著同樣面臨的一個問題，如何讓他們的軟件產(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ā)，這是比較粗暴的方法，在用戶量較大時，轉(zhuǎn)發(fā)服務(wù)器需要付出相當(dāng)大的代價；其次，可以使用NAT 穿透技術(shù)。而在NAT 穿透中，UDP 穿透的成功率比起TCP 穿透要高出許多[1]。因此在UDP 協(xié)議上構(gòu)建一些大型的網(wǎng)絡(luò)應(yīng)用程序可能會成為很多人的需求。

由于UDP協(xié)議本身存在通信不可靠的缺點(diǎn)，對于基于UDP 進(jìn)行可靠通信的需求就浮現(xiàn)出來了。目前在網(wǎng)絡(luò)上有許多人正在做著這一工作，UDT、RakNet、eNet 等都是構(gòu)建在UDP之上的網(wǎng)絡(luò)可靠通信開發(fā)庫，但這些庫都是針對一些特殊應(yīng)用進(jìn)行設(shè)計(jì)的，不具備通用性。本文提出的CDP協(xié)議是在UDP基礎(chǔ)之上實(shí)現(xiàn)的TCP協(xié)議。同時具備了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é)議主要在以下幾個方面與TCP有所不同：協(xié)議格式、連接建立（NAT UDP PUNCH模式）、?；顧C(jī)制、MTU發(fā)現(xiàn)與MSS通告。其他部分，如報(bào)文傳輸、流量控制、超時重傳、擁塞控制等，均參照TCP協(xié)議實(shí)現(xiàn)[2]。下面將對幾個不同部分分別進(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)序號有效。

PSH：接收方應(yīng)該盡快將這個報(bào)文段交給應(yīng)用層。

RST：重置連接。

SYN：同步序號，用來發(fā)起一個連接。

FIN：發(fā)端完成發(fā)送任務(wù)。

16 位窗口大?。航邮斩丝山邮諗?shù)據(jù)的窗口大小。

選項(xiàng)：只有一個選項(xiàng)字段，為最長報(bào)文大小，即MSS。CDP 選項(xiàng)格式與TCP 選項(xiàng)格式一致，kind=0 時表示選項(xiàng)結(jié)束，kind=1 時表示無操作，kind=2 時表示最大報(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）模式下時，在三次握手之前，先要向?qū)Χ薔AT 端口及預(yù)測端口以默認(rèn)2ms的間隔發(fā)送默認(rèn)為10個LIV報(bào)文，一來用于打開自已的NAT 端口，二來是用于進(jìn)入對端NAT端口。默認(rèn)值可以由用戶程序設(shè)置。這時的LIV 報(bào)文中初始序號及確認(rèn)序號都為0。

當(dāng)接收到對端LIV 報(bào)文后，CDP立即停止LIV 報(bào)文發(fā)送，發(fā)出SYN 報(bào)文進(jìn)行連接建立。這時有兩種可能：一是對端直到接收到該SYN 報(bào)文，都沒有接收到LIV 報(bào)文，或是剛接收到LIV報(bào)文，但沒有來得及發(fā)送SYN 報(bào)文，此時將會和一般模式下連接建立的過程一致，經(jīng)歷三次握手；二是對端在接收到該SYN 報(bào)文之前，也已經(jīng)發(fā)送SYN報(bào)文，此時雙方都需要對SYN 報(bào)文段進(jìn)行確認(rèn)。

3.3 半打開連接及連接?；?span style="display:none">UfH萬博士范文網(wǎng)-您身邊的范文參考網(wǎng)站Vanbs.com

半打開連接是指對端異常關(guān)閉，如網(wǎng)線拔掉、突然斷電等情況導(dǎo)致一端關(guān)閉，而另一端卻認(rèn)為連接仍處于打開當(dāng)中，這種情況稱之為半打開連接。CDP中的一個TDP SOCKET描述符由本地IP、本地端口、遠(yuǎn)端IP、遠(yuǎn)端端口唯一確定。當(dāng)遠(yuǎn)端客戶端連接請求到來時，服務(wù)端將接收到一個新的CDP SOCKET描述符，當(dāng)這一個描述符唯一確定信息已經(jīng)存在時，對新的連接請求發(fā)送RST 報(bào)文段，通知其重置連接請求。對于舊的連接，由?；顧C(jī)制自動發(fā)現(xiàn)是否為半打開連接，如果是半打開連接，則自動關(guān)閉該連接。CDP的RST 報(bào)文與TCP 中的RST 報(bào)文是不一樣的。

連接建立之后，CDP 連接需要啟動?；顧C(jī)制。TCP 連接在沒有數(shù)據(jù)通信的情況下也能保持連接，但CDP 連接不行。CDP 連接在一定時間內(nèi)如果沒有數(shù)據(jù)交互的話，將主動發(fā)送保活LIV報(bào)文段。這個時間根據(jù)CDP 連接工作模塊不同有所差異，在NAT UDP PUNCH 模式下，默認(rèn)值為1 分鐘（大多數(shù)的NAT中，UDP會話超時時間為2－5分鐘左右）；而在常規(guī)模塊下這個時間段默認(rèn)值為5分鐘。默認(rèn)值可以由用戶程序設(shè)置，用戶程序需要指明兩種模式下的?；顣r間周期。

3.4 路徑MTU 發(fā)現(xiàn)及MSS 通告

CDP連接建立過程中會通告初始MSS(Maximum Segment Size)，這個值可以由用戶程序進(jìn)行設(shè)置。但這個初始值是靜態(tài)的，當(dāng)通信雙方跨越多個網(wǎng)絡(luò)時，使用設(shè)置的MSS可能導(dǎo)致傳輸?shù)腎P 報(bào)文分片的產(chǎn)生。為了避免分片，CDP在數(shù)據(jù)傳輸過程中進(jìn)行動態(tài)的路徑MTU(Maximum Transmission Unit)發(fā)現(xiàn)，并進(jìn)行MSS 的更新及通告。

CDP創(chuàng)建UDP SOCKET時，即將IP選項(xiàng)設(shè)置為不允許分片： Setsockopt（clientSock, IPPROTO_IP, IP_DONTFRAGMENT, (char*)&dwFlags, sizeof(dwFlag) )。

在發(fā)送數(shù)據(jù)時先以當(dāng)前MSS 大小進(jìn)行發(fā)送，如果返回值為錯誤碼WSAEMSGSIZE（10040），則表示為報(bào)文尺寸大于MTU，需要進(jìn)行IP 分片傳輸。此時，縮減MSS大小再次發(fā)送，直至不再返回錯誤碼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)行檢測，如果三次都未發(fā)現(xiàn)MTU 增大則停止進(jìn)行檢測。網(wǎng)絡(luò)中MTU 值的個數(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是非常相似的，對應(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é)議，并對現(xiàn)實(shí)的一些關(guān)鍵部分進(jìn)行了討論，最后給出了CDP協(xié)議的應(yīng)用開發(fā)接口。CDP協(xié)議同時具備了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

中圖分類號：TP311.1 文獻(xiàn)標(biāo)識碼：A文章編號：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é)議族中，有兩個互不相同的傳輸協(xié)議：TCP（傳輸控制協(xié)議）和UDP（用戶數(shù)據(jù)報(bào)協(xié)議）。TCP為兩臺主機(jī)提供高可靠性的數(shù)據(jù)通訊，UDP為應(yīng)用層提供了一種非常簡單的服務(wù)，它只是把稱作數(shù)據(jù)報(bào)的分組從一臺主機(jī)發(fā)送到另一臺主機(jī)，但并不保證該數(shù)據(jù)報(bào)能到達(dá)另一端。與TCP相比UDP的優(yōu)勢就在于它排除了信息可靠傳遞機(jī)制，將安全和排序等功能移交給上層應(yīng)用來完成，極大降低了執(zhí)行時間，保證了運(yùn)行速度。單播、廣播、組播則表示的是數(shù)據(jù)在網(wǎng)絡(luò)中“播放”的形式，是指有一個人能聽到還是讓特定的人群聽得到，還是讓所有的人都聽的到的區(qū)別。一臺主機(jī)要向網(wǎng)上的所有其他主機(jī)發(fā)送幀，這就是廣播；多播處于單播和廣播之間，向?qū)儆诙嗖ソM的多個主機(jī)發(fā)送幀。

一、廣播與多播的實(shí)現(xiàn)

下面我們就詳細(xì)介紹一下Delphi5.0開發(fā)環(huán)境下廣播和多播的實(shí)現(xiàn)。軟件開發(fā)步驟如下：

（一）網(wǎng)絡(luò)初始化

1.首先初始化WinSock動態(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端口號

函數(shù)htons將端口號由主機(jī)字節(jié)順序轉(zhuǎn)換為網(wǎng)絡(luò)字節(jié)順序，然后將套接字綁定到一個本地地址和端口上（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初始化時代碼如下： 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ī)器才能收到，也就是說對方地址應(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ā)送。

首先定義一個string變量和一個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)測試，該軟件能成功實(shí)現(xiàn)UDP協(xié)議下的廣播和多播。測試結(jié)果如圖1、圖2所示。

圖1 UDP廣播測試結(jié)果圖2UDP多播測試結(jié)果

參考文獻(xiàn)：

[1]袁振武.謝任東.談Delphi編程中UDP協(xié)議的應(yīng)用[J].科技廣場,2008,05

udp協(xié)議范文第4篇

關(guān)鍵詞:UDP;RUDP;可靠性

中圖分類號:TP393文獻(xiàn)標(biāo)識碼:A文章編號: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ù)。面向連接意味著兩個使用TCP的應(yīng)用在彼此交換數(shù)據(jù)之前必須先建立一個TCP連接,數(shù)據(jù)傳輸完成后,再經(jīng)過4次握手終止雙方的連接。在數(shù)據(jù)傳輸?shù)倪^程中,TCP還通過對數(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)心對方計(jì)算機(jī)的狀態(tài),因此,它是一種相對不可靠的通信協(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)勢,又能保證UDP通信的可靠性,網(wǎng)絡(luò)通信系統(tǒng)的性能將會得到更大程度地提高。

2 RUDP 協(xié)議的提出

2.1 嵌入式設(shè)備可靠通信面臨的問題

面向連接方式的服務(wù)功能明顯很強(qiáng)大,它能夠發(fā)揮面向連接的傳輸所具備的特性,例如流量控制,差錯處理以及順序交付等等,但是面向無連接的服務(wù)更適合于某些情況,在網(wǎng)絡(luò)層上使用IP協(xié)議就是一個面向無連接的服務(wù)而且這個面向無連接的服務(wù)顯得更加健壯,因?yàn)镮nternet本身就是一個不穩(wěn)定的環(huán)境,面向連接的服務(wù)反而不能很好的運(yùn)行于其上。

如果使用TCP連接協(xié)議實(shí)現(xiàn)嵌入式設(shè)備之間的數(shù)據(jù)傳輸可能帶來許多的問題,嵌入式設(shè)備之間建立TCP連接并發(fā)送數(shù)據(jù)后,或者接收端向正在請求連接的設(shè)備發(fā)出SYN+ACK應(yīng)答報(bào)文后,都可能無法接收到終端的ACK報(bào)文,在這種情況下發(fā)送端一般會重試并等待一段時間后終止這個連接。大量重傳數(shù)據(jù)會進(jìn)一步加劇網(wǎng)絡(luò)的擁塞情況,嚴(yán)重時可以使網(wǎng)絡(luò)及服務(wù)器系統(tǒng)崩潰,同時也會對數(shù)據(jù)傳輸?shù)膶?shí)時性產(chǎn)生影響。同時目前嵌入式設(shè)備又存在多點(diǎn)分散、數(shù)據(jù)量小、實(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ā)是處于一個公共網(wǎng)絡(luò)的環(huán)境之中,可能會有大量無用的數(shù)據(jù)向嵌入式設(shè)備進(jìn)行發(fā)送,大量的數(shù)據(jù)解析會極大地增加嵌入式設(shè)備的負(fù)擔(dān)。為了避免這個問題,我們增加了一個標(biāo)志層,標(biāo)志層可以讓嵌入式設(shè)備迅速的判斷所接收的數(shù)據(jù)包是否為有效數(shù)據(jù)包,如果標(biāo)志層數(shù)據(jù)不可識別,則迅速將包丟棄。在可靠傳輸層進(jìn)行可靠傳輸設(shè)計(jì)和實(shí)現(xiàn),在這一層,我們增加一系列可靠傳輸機(jī)制以保證嵌入式設(shè)備之間數(shù)據(jù)的可靠傳輸。這樣就形成了一個原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)和字段是對整個UDP報(bào)文頭和UDP所帶的數(shù)據(jù)的校驗(yàn)和。

3) 丟棄重復(fù)包和保存失序包的功能:每當(dāng)收到數(shù)據(jù)包后,便對數(shù)據(jù)包進(jìn)行確認(rèn)。保存未確認(rèn)的數(shù)據(jù)包,丟棄已經(jīng)確認(rèn)了的重復(fù)包。由于UDP傳送過程中,收到的數(shù)據(jù)包的順序可能會和發(fā)送的順序有一定的區(qū)別,所以保存失序包能夠有效的減少重發(fā)的次數(shù),也就是能相應(yīng)的減少網(wǎng)絡(luò)的數(shù)據(jù)流量。

4) 超時重發(fā)功能:RUDP中借鑒TCP中的超時重發(fā)機(jī)制來保證數(shù)據(jù)包的可靠傳遞;同時TCP中的確認(rèn)延遲功能也得到借鑒,這樣可以顯著降低網(wǎng)絡(luò)的流量,提高嵌入式系統(tǒng)的通信效率。

5) 服務(wù)器和客戶端?；罟δ?探測收發(fā)兩端的連接是否正常時嵌入式可靠傳輸模型中必須要實(shí)現(xiàn)的一個功能。如果連接已經(jīng)出錯,若干數(shù)據(jù)包仍然發(fā)送,當(dāng)超時定時器到時后就會進(jìn)行數(shù)據(jù)的重發(fā)。如果沒有判斷收發(fā)兩端的連接是否正常,則會導(dǎo)致數(shù)據(jù)無法正常而又高效的發(fā)送。

2.4 RUDP協(xié)議工作過程

RUDP協(xié)議的工作過程是:首先,建立連接。發(fā)送方和接收方通過三次握手的方式建立連接(三次握手過程如圖1所示)。第三次握手時,發(fā)送方發(fā)給接收方的數(shù)據(jù)幀中除了包含對接收方的確認(rèn)信息之外,還包含將要發(fā)送的數(shù)據(jù)幀總數(shù)。接收方收到確認(rèn)幀后,開始與發(fā)送方建立連接。與此同時將根據(jù)收到的幀總數(shù)設(shè)置接收窗口大小并將所有幀序號放入緩存。雙方連接建立好后保證了數(shù)據(jù)發(fā)送和接收的同步性。

接著,發(fā)送方開始發(fā)送數(shù)據(jù)幀,接收方收到數(shù)據(jù)幀并進(jìn)行處理。能夠正確接收到的幀序號將會從序號緩存中刪除。發(fā)送方發(fā)送完數(shù)據(jù)幀后發(fā)送“發(fā)送完”標(biāo)志給接收方。接收方收到此標(biāo)志后,開始掃描幀序號緩存。如果數(shù)據(jù)幀全部接收到,接收方向發(fā)送方發(fā)送一“接收完”標(biāo)志,發(fā)送方收到后斷開連接。如果序號緩存中有序號則說明有幀丟失,這時接收方將向發(fā)送方發(fā)出一個帶有丟失幀序號的確認(rèn)幀。發(fā)送方收到此確認(rèn)幀后將重新發(fā)送丟失幀。如此重復(fù),直到接收方完全正確接收到數(shù)據(jù)幀。其工作過程如圖2所示。

3 總結(jié)

通過分析比較傳輸層協(xié)議TCP和UDP,能夠看到它們各自的特點(diǎn),并分析出它們各自的優(yōu)勢和缺點(diǎn)。結(jié)合嵌入式設(shè)備數(shù)據(jù)傳輸?shù)奶攸c(diǎn)同時針對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é)議是建立在請求/響應(yīng)(request/response)模型上的。首先由客戶建立一條與服務(wù)器的TCP鏈接，并發(fā)送一個請求到服務(wù)器，請求中包含請求方法、URI、協(xié)議版本以及相關(guān)的MIME(Multipurpose Internet Mail Extensions)樣式的消息。服務(wù)器響應(yīng)一個狀態(tài)行，包含消息的協(xié)議版本、一個成功和失敗碼以及相關(guān)的MIME式樣的消息(包含服務(wù)器的信息、資源實(shí)體的信息和可能的資源內(nèi)容)。圖1給出了HTTP協(xié)議實(shí)現(xiàn)的一個簡單模型。HTTP/1.0[3]為每一次HTTP的請求/響應(yīng)建立一條新的TCP鏈接，因此一個包含HTML內(nèi)容和圖片的頁面將需要建立多次的短期的TCP鏈接。一次TCP鏈接的建立將需要3次握手。另外，為了獲得適當(dāng)?shù)膫鬏斔俣?，則需要TCP花費(fèi)額外的回路鏈接時間（RTT）。每一次鏈接的建立需要這種經(jīng)常性的開銷，而其并不帶有實(shí)際有用的數(shù)據(jù)，只是保證鏈接的可靠性，因此HTTP/1.1[4]提出了可持續(xù)鏈接的實(shí)現(xiàn)方法。HTTP/1.1將只建立一次TCP的鏈接而重復(fù)地使用它傳輸一系列的請求/響應(yīng)消息，因此減少了鏈接建立的次數(shù)和經(jīng)常性的鏈接開銷。

可持續(xù)鏈接減少了每次TCP鏈接建立的時間，但是一個空閑的TCP鏈接將需要一個Socket和相應(yīng)的存儲緩沖區(qū)。一個Socket緩沖區(qū)的最小長度必須大于一個TCP包的最大長度，即64 KB，而且很多實(shí)現(xiàn)方法在鏈接建立時將預(yù)分配一些緩沖區(qū)。可用的Socket的數(shù)量是有限的，很多基于BSD的操作系統(tǒng)對于能夠同時打開的鏈接數(shù)都有一個缺省的最大值。

無線掌上設(shè)備PDA的應(yīng)用（如瀏覽器）[5]特點(diǎn)表現(xiàn)在：① 因?yàn)轫撁媸轻槍φ粕显O(shè)備制作的，一般在1 K~2 K字節(jié)，比較??；② 目前無線通信網(wǎng)絡(luò)的帶寬很窄，GSM的數(shù)據(jù)信道帶寬只有9.6 K。當(dāng)前Web頁面的訪問大多通過HTTP協(xié)議，并使用TCP作為下層的傳輸控制協(xié)議。但不幸的是，TCP并不適合短會話的應(yīng)用情況，不同于現(xiàn)在采用的使用單一TCP傳輸協(xié)議進(jìn)行數(shù)據(jù)傳輸?shù)姆绞?。本文提出了采用動態(tài)選擇傳輸層協(xié)議（TCP、UDP）的方法來改善取回頁面的延遲、網(wǎng)絡(luò)擁塞以及服務(wù)器的負(fù)荷。

這種混合TCP-UDP的方法結(jié)合兩個方面的優(yōu)點(diǎn)：首先，對于需要比較少數(shù)據(jù)傳輸?shù)那闆r，它將使用UDP作為傳輸層的協(xié)議，從而避免了TCP鏈接的多次握手開銷；另外，對于需要較多數(shù)據(jù)傳輸?shù)那闆r，它將使用可靠的帶有重排序和擁塞控制的TCP協(xié)議作為傳輸層的協(xié)議。混合TCP-UDP的實(shí)現(xiàn)方法只需要對應(yīng)用層的改動，而操作系統(tǒng)的核心代碼不用任何更改。僅采用UDP協(xié)議的缺點(diǎn)在于，需要在應(yīng)用層建立一套類似于TCP復(fù)雜的控制協(xié)議，從而進(jìn)行重排序和擁塞控制來保證傳輸?shù)目煽啃浴?span style="display:none">UfH萬博士范文網(wǎng)-您身邊的范文參考網(wǎng)站Vanbs.com

1 背景

HTTP是一個請求/響應(yīng)協(xié)議，客戶端的應(yīng)用程序通過提供一個URL可以從服務(wù)器上得到所需的數(shù)據(jù)。HTTP可以用來訪問各種不同類型的資源，其中包括文本、圖形、影音、可執(zhí)行文件、數(shù)據(jù)庫查詢結(jié)果等等。

圖2給出了在客戶端發(fā)起HTTP GET請求后，在客戶端和服務(wù)器之間進(jìn)行數(shù)據(jù)包交換的示意。圖中只有兩個數(shù)據(jù)包是有用的（即攜帶了數(shù)據(jù)）：一個是HTTP GET請求，另一個是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個數(shù)據(jù)包，而使用UDP則只需要2個數(shù)據(jù)包就足夠了。

2 設(shè) 計(jì)

我們使用混合傳輸層[6]的方法即對于少量數(shù)據(jù)傳輸?shù)逆溄硬捎肬DP，而對于大量數(shù)據(jù)傳輸?shù)逆溄硬捎肨CP作為傳輸層協(xié)議。這樣對于短鏈接而言就避免了TCP經(jīng)常性的握手開銷，而對于長鏈接則仍可獲得TCP的優(yōu)點(diǎn)，如超時重傳、擁塞控制、錯誤恢復(fù)機(jī)制等。這種方法中，客戶端首先嘗試使用UDP作為傳輸層的協(xié)議，如果對于所請求的URL UDP并不適合，則再次使用TCP鏈接。這種方法提供了以下保證：

如果初始的UDP數(shù)據(jù)包丟失，將采用TCP重新鏈接而不會受到影響。

如果所鏈接的服務(wù)器沒有使用混合傳輸層的實(shí)現(xiàn)機(jī)制，客戶端將使用TCP重新進(jìn)行鏈接。

圖3給出了混合TCP、UDP的實(shí)現(xiàn)算法。一個采用混合算法的HTTP客戶端首先使用UDP作為傳輸層的協(xié)議發(fā)出HTTP GET請求，同時啟動超時定時器。

當(dāng)服務(wù)器處理客戶端發(fā)來的請求時，它可以從以下兩點(diǎn)做出選擇：

① 如果響應(yīng)的數(shù)據(jù)足夠?。ū热?，可放到一個數(shù)據(jù)包中），服務(wù)器將使用UDP發(fā)回響應(yīng)。像比較小的網(wǎng)頁或HTTP REDIRECT響應(yīng)就屬于這一類。

② 如果響應(yīng)的數(shù)據(jù)很大，無法放進(jìn)一個UDP數(shù)據(jù)包中，服務(wù)器則要求客戶端使用TCP重試。這可以通過添加一個HTTP的頭部字段來解決如 TCPRETR。

在客戶端，將會出現(xiàn)以下三種情況：

客戶端從服務(wù)器接收到響應(yīng)。如果響應(yīng)中包含了所需的HTTP響應(yīng)，客戶端將對數(shù)據(jù)進(jìn)行處理。如果服務(wù)器要求客戶端重試，客戶端將使用TCP作為傳輸層重試。

如果服務(wù)器沒有處理通過UDP傳輸?shù)腍TTP包，客戶端就會收到ICMP錯誤消息（目的地址無法到達(dá)/協(xié)議無法到達(dá)）。此時客戶端將會使用TCP重試。

如果定時器超時，客戶端應(yīng)使用TCP重試。

圖4給出了在定時器超時情況下，客戶端和服務(wù)器之間數(shù)據(jù)包的交換。這種超時機(jī)制提供了可靠性，以及與未使用混合TCP-UDP方法的服務(wù)器的兼容性。

圖5示意了服務(wù)器要求客戶端使用TCP重發(fā)請求時，客戶端和服務(wù)器之間的數(shù)據(jù)包交換。

3 結(jié) 語

混合TCP-UDP方法改善了參與HTTP傳輸?shù)娜齻€方面：客戶端、服務(wù)器和網(wǎng)絡(luò)。

對于客戶端而言，可以避免由于TCP而引入的三向握手的時間，從而減少了瀏覽的延遲時間。

對于服務(wù)器而言，由于所需的TCP的鏈接數(shù)量減少，從而降低了由于建立、維護(hù)、撤銷TCP鏈接所帶來的服務(wù)器的負(fù)荷。

udp協(xié)議范文第6篇

關(guān)鍵詞:通信網(wǎng)絡(luò);基于樣本塊的方法;UDP協(xié)議;Mean-Shift方法

中圖分類號:TP311文獻(xiàn)標(biāo)識碼:A文章編號:1009-3044(2010)21-5714-02

通信網(wǎng)絡(luò)為計(jì)算機(jī)信息的獲取、傳輸、處理、利用和共享提供一個安全可靠的環(huán)境和傳輸通道,但現(xiàn)實(shí)中通信網(wǎng)絡(luò)并非是絕對安全的,傳輸數(shù)據(jù)過程中數(shù)據(jù)包的丟失、泄密和篡改時有發(fā)生,且日趨嚴(yán)重。

目前在通信網(wǎng)絡(luò)中比較常用的兩個通信協(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í)時性較高的應(yīng)用。UDP協(xié)議雖說不提供安全的數(shù)據(jù)傳輸,但是其傳輸效率很高,能實(shí)現(xiàn)實(shí)時傳輸,但是容易出現(xiàn)丟失數(shù)據(jù)包的問題。在實(shí)際當(dāng)中很多實(shí)時性很高的珍貴數(shù)據(jù)是不容有失的,那么如何解決這一問題呢?

在2003年Shantanu D.Rane等提出無線電傳輸中丟失數(shù)據(jù)復(fù)原的問題,他們結(jié)合現(xiàn)有的圖像修復(fù)技術(shù)和紋理合成技術(shù)對傳輸過程中丟失的數(shù)據(jù)進(jìn)行填充。在傳輸過程中,圖像被劃分為的塊,計(jì)算其離散余弦變換,然后量化并進(jìn)行哈弗曼編碼,最后傳輸圖像數(shù)據(jù)[1]。該文獻(xiàn)中對丟失數(shù)據(jù)填充過程如下:對丟失的塊分類,根據(jù)周圍的塊判斷丟失塊是紋理塊還是結(jié)構(gòu)塊,如果是紋理塊使用紋理合成算法,否則使用結(jié)構(gòu)修復(fù)算法。分析發(fā)現(xiàn)該方法對于塊的分類不夠準(zhǔn)確,而且丟失數(shù)據(jù)的填充比較耗時。

本文針對上述缺陷直接使用基于樣本塊的方法[3]填充UDP協(xié)議丟包數(shù)據(jù)。在目前所有的圖像修復(fù)方法中,基于樣本塊的修復(fù)方法是非常有效用的一種,它不僅能夠填充圖像紋理部分,而且能夠修復(fù)圖像簡單的結(jié)構(gòu),對結(jié)構(gòu)的修復(fù)主要是受修復(fù)的優(yōu)先權(quán)和樣本塊的大小控制,適合的修復(fù)順序和樣本塊大小是有利于圖像結(jié)構(gòu)的保持。因此本文直接使用基于樣本塊的方法對丟失的圖像數(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ù)丟失不會引起整個圖像數(shù)據(jù)的混亂,這就為數(shù)據(jù)的恢復(fù)提供了一定的可能,否則數(shù)據(jù)的恢復(fù)是非常困難的。在很多文獻(xiàn)中提到UDP協(xié)議的丟包率與具體網(wǎng)絡(luò)環(huán)境有關(guān),沒有一個準(zhǔn)確的數(shù)值,但是一般來說其平均丟包率總會小于無線電數(shù)據(jù)的丟包率3.6%[2]。

基于樣本塊的方法一種非常有效的丟失圖像數(shù)據(jù)的填充方法,它不僅能填充大塊的紋理破損,而且能夠修復(fù)較小的結(jié)構(gòu)破損。UDP協(xié)議的丟包率一般來說很小,這也就為圖像的結(jié)構(gòu)部分的復(fù)原提供了重要的保障?；跇颖緣K的圖像修復(fù)過程如下:

1) 確定丟失數(shù)據(jù)包的位置,因?yàn)閳D像數(shù)據(jù)是經(jīng)過編碼后傳輸?shù)?因此即使丟包也不會使得整個圖像數(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)對應(yīng)的數(shù)據(jù);

6) 更新破損區(qū)域;

7) 判斷破損像素點(diǎn)的個數(shù)是否為0,如果為0,則轉(zhuǎn)8),否則返回到2);

8) 修復(fù)結(jié)束。

基于樣本塊的修復(fù)方法雖說有很好的修復(fù)效果,但是也必須注意其修復(fù)過程中存在的問題。首先誤差的累積問題,這必然導(dǎo)致錯誤的填充結(jié)果。其次是最佳匹配塊的選擇問題,如何在多個候選最佳匹配塊中選出真正最佳的匹配塊。

文獻(xiàn)[4]提出一種新的方法來解決這誤差累積的問題,首先使用Mean-Shift方法[5]對圖像進(jìn)行了粗劃分,對最佳匹配塊的選擇區(qū)域作了限制,具體的最佳匹配塊的選擇原則如下:

1) 如果待修復(fù)塊屬于粗劃分Ti,則最佳匹配塊僅在Ti中選擇;

2) 如果待修復(fù)塊處于多個劃分Ti∪Ti+1∪...∪Ti+k的邊緣,則最佳匹配塊在Ti∪Ti+1∪...∪Ti+k中選擇。

上述方法相當(dāng)于給匹配塊的選擇加了一些約束,使選擇范圍縮小。這樣不僅縮短了尋找匹配塊的時間,也避免了誤差的累積。

另外一個問題就是最佳匹配塊唯一的問題。假設(shè)目前找到的匹配塊為ψp1, ψp2,…ψpk,那么如何在這之中選擇一個真正的最佳匹配塊。文獻(xiàn)[6]提到了一種選取最佳匹配塊的方法,認(rèn)為與當(dāng)前待修復(fù)塊的空間距離越近,其相關(guān)程度越高。因此,通過計(jì)算待修復(fù)塊的核與匹配塊的核之間的空間距離來最終選定哪個塊是真正的最佳匹配塊。丟失數(shù)據(jù)的填充流程圖如圖1所示。

2 實(shí)驗(yàn)結(jié)果

本文用VC++實(shí)現(xiàn)了該算法,通過大量的實(shí)驗(yàn)說明了本文算法的有效性。由于傳輸圖像很容易獲得,因此本文采用峰值信噪比的方法對恢復(fù)結(jié)果進(jìn)行客觀評價。峰值信噪比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ù)時容易發(fā)生數(shù)據(jù)丟包問題,由此使用基于樣本塊的方法解決恢復(fù)丟失數(shù)據(jù)包的問題。盡管文獻(xiàn)[1]的作者提出了無線傳輸中圖像數(shù)據(jù)的恢復(fù)方法,但是該方法比較復(fù)雜,而且存在諸多的不穩(wěn)定性,諸如塊的分類等。本文結(jié)合基于樣本塊修復(fù)的優(yōu)點(diǎn)對丟失數(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ò)通信

中圖分類號：TP393文獻(xiàn)標(biāo)識碼：A文章編號：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的編程原理，并通過一個Java編寫的客戶/服務(wù)器程序，描述了網(wǎng)絡(luò)中基于UDP的不同主機(jī)上的兩個進(jìn)程之間的socket通信機(jī)制。

1 Socket通信機(jī)制

Socket（套接字）機(jī)制是一種API，是網(wǎng)絡(luò)應(yīng)用程序的編程接口。Socket是通過標(biāo)準(zhǔn)文件描述符和其它程序通訊的一個方法。每一個套接字都用一個半相關(guān)描述：{協(xié)議，本地地址、本地端口}來表示；一個完整的套接字則用一個相關(guān)描述：{協(xié)議，本地地址、本地端口、遠(yuǎn)程地址、遠(yuǎn)程端口}，每一個套接字都有一個本地的由操作系統(tǒng)分配的唯一的套接字號。

根據(jù)傳輸數(shù)據(jù)類型的不同，Socket主要分為三類：1) 流式Socket（SOCK_STREAM），在這種方式下，兩個通訊的應(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)行傳輸，是無序的，并且不保證可靠、無差錯。3) 原始Socket，原始套接字允許對底層協(xié)議如IP或ICMP直接訪問，它功能強(qiáng)大但使用較為不便，主要用于一些協(xié)議的開發(fā)。

2 UDP協(xié)議的工作原理

UDP協(xié)議是一個面向無連接的協(xié)議，其連接的建立不必像TCP那樣需要服務(wù)器端偵聽，也不需要有客戶機(jī)請求連接，屬于一種“強(qiáng)制”性的網(wǎng)絡(luò)連接。UDP提供一對一或一對多的、無連接的數(shù)據(jù)報(bào)服務(wù)。該服務(wù)對消息中傳輸?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)格的傳輸可靠性，比如視頻會議系統(tǒng)等，需要實(shí)時的交互，但并不要求音頻視頻的絕對正確。

使用UDP協(xié)議傳輸數(shù)據(jù)時，首先設(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端口號時，端口提供了用于發(fā)送消息的位置，每個端口由一個唯一的編號來標(biāo)識。當(dāng)應(yīng)用程序向另一臺計(jì)算機(jī)發(fā)送數(shù)據(jù)時，UDP生成一個數(shù)據(jù)頭，包括源端口，這些端口提供送達(dá)信息所需要的地址。UDP協(xié)議還為數(shù)據(jù)和數(shù)據(jù)頭計(jì)算出求和檢驗(yàn)的值，在目標(biāo)計(jì)算機(jī)中，數(shù)據(jù)包被傳遞至UDP協(xié)議程序并送到目的地端口。

3 UDP套接字的通信過程

中提供了兩個類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通信程序時，無論在客戶端還是服務(wù)器端，都要首先建立一個DatagramSocket對象，用來表示數(shù)據(jù)報(bào)通信的端點(diǎn)，應(yīng)用程序通過Socket接收或發(fā)送數(shù)據(jù)報(bào)。

DatagramPacket則用來表示一個數(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)建一個數(shù)據(jù)報(bào)套接字；2) 調(diào)用bind()把服務(wù)器地址綁定在該套接字上；3) 調(diào)用recvform()等待客戶進(jìn)程發(fā)來的請求，服務(wù)器此時處于無限循環(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)建一個數(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ī)中有一個名為“udp_socket.txt”文件，文件中保存了一段英文。服務(wù)器端接收一個客戶端的請求，就從文件中讀取若干個英文字符發(fā)送給客戶端。當(dāng)文件中所有內(nèi)容發(fā)送給完畢，服務(wù)器端程序?qū)⑼顺觥？蛻舳耸紫葮?gòu)造一個數(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)建端口號為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)對象

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ù)存儲到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)建套接字對象

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)對象

socket.send(packet);//接收數(shù)據(jù)報(bào)

packet=new DatagramPacket(buf,buf.length);

//創(chuàng)建要接收的數(shù)據(jù)報(bào)對象

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

}}

編寫程序時客戶端和服務(wù)器端的DatagramSocket必須用一個端口，因?yàn)榭蛻舳讼蚍?wù)器端請求時，服務(wù)器需要知道從哪個端口監(jiān)聽請求。當(dāng)數(shù)據(jù)進(jìn)行傳輸時，服務(wù)器從接收到的數(shù)據(jù)報(bào)中得到客戶端的接收數(shù)據(jù)的端口，然后將數(shù)據(jù)報(bào)發(fā)送到這個端口，客戶端則監(jiān)聽這個端口而得到服務(wù)器端發(fā)送過來的數(shù)據(jù)報(bào)并顯示其內(nèi)容。運(yùn)行時要先運(yùn)行服務(wù)器端程序，再運(yùn)行客戶端程序。

5 小結(jié)

Socket在網(wǎng)絡(luò)編程方面發(fā)揮著很大的作用。UDP是可靠性無法得到保障的協(xié)議，但對于質(zhì)量要求不是很高的網(wǎng)絡(luò)應(yīng)用程序，UDP是一個很好的選擇。

參考文獻(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

中圖分類號：TP393 文獻(xiàn)標(biāo)識碼：A 文章編號：1007-9416（2016）05-0000-00

傳輸控制協(xié)議/網(wǎng)際協(xié)議（Transmission Control Protocol/ Internet Protocol，TCP/IP）協(xié)議簇是Internet 和全球各地網(wǎng)絡(luò)互聯(lián)的引擎。本文針對網(wǎng)際層IP協(xié)議下的一項(xiàng)功能的實(shí)現(xiàn)，主要是針對從UDP協(xié)議下的數(shù)據(jù)包處理的過程。UDP是一個簡單的面向數(shù)據(jù)報(bào)的運(yùn)輸層協(xié)議：進(jìn)程的每個輸出操作都正好產(chǎn)生一個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為例），主要包括時鐘輸入信號和復(fù)位輸入信號。內(nèi)部端口為運(yùn)輸層與網(wǎng)絡(luò)層相互聯(lián)系為原則設(shè)計(jì)的，不僅需要數(shù)據(jù)輸入輸出，也需要這兩個模塊間的相互控制。具體內(nèi)部端口主要包括數(shù)據(jù)輸入輸出信號及對應(yīng)的數(shù)據(jù)同步信號，兩個準(zhǔn)備信號，兩個IP地址輸入信號和輸入同步信號的結(jié)束信號。信號描述如下：

時鐘信號（clk）、復(fù)位信號（res）、UDP準(zhǔn)備信號（udprd）、輸入數(shù)據(jù)信號（isd）：、輸入數(shù)據(jù)同步信號（iss）、輸入數(shù)據(jù)結(jié)束信號（ise）、源IP地址（sipa）：、目的IP地址（dipa）、IP準(zhǔn)備信號（iprd）、輸出數(shù)據(jù)信號（osd）、輸出數(shù)據(jù)同步信號（oss）。

具體端口設(shè)置如圖1：

1.2 功能模塊

1.2.1 建立連接模塊

運(yùn)輸層和網(wǎng)絡(luò)層之間有很多協(xié)議，不同協(xié)議對應(yīng)不同數(shù)據(jù)包，如何選擇合適通路選擇特定數(shù)據(jù)包，這就要求有特定的連接過程完成特定的數(shù)據(jù)傳輸。

為了建立UDP協(xié)議數(shù)據(jù)和IP數(shù)據(jù)之間的相互通信，在方案中，選擇增添一個建立連接模塊，目的是完成兩個功能。首先是完成UDP協(xié)議下的數(shù)據(jù)在特定通道內(nèi)向網(wǎng)絡(luò)層的傳輸，其次是產(chǎn)生控制信號，控制下一模塊工作狀態(tài)。在此過程中，主要涉及到兩個信號，其一是udprd信號，是建立連接第一步，這個信號旨在反映UDP數(shù)據(jù)報(bào)已經(jīng)準(zhǔn)備好發(fā)送；其二是iprd信號，建立連接第二步，本信號是為了給運(yùn)輸層的UDP協(xié)議的反饋信號，如果接到收此信號，UDP數(shù)據(jù)報(bào)就開始發(fā)送了。本信號還有一個功能：當(dāng)網(wǎng)絡(luò)層對數(shù)據(jù)處理時，此信號會自動變低電平，將不會接收UDP數(shù)據(jù)報(bào)，直到在網(wǎng)絡(luò)層的數(shù)據(jù)處理完畢。

1.2.2 數(shù)據(jù)接收存儲模塊

在此模塊下，可分為數(shù)據(jù)接收部分和數(shù)據(jù)的存儲部分。

首先介紹一下數(shù)據(jù)的接收部分，當(dāng)大量的數(shù)據(jù)報(bào)準(zhǔn)備進(jìn)入網(wǎng)絡(luò)層時，有些數(shù)據(jù)是沒有意義的，所以要準(zhǔn)確有效的接收來自UDP協(xié)議下的數(shù)據(jù)報(bào)，需要在這一部分完成此功能。在端口的設(shè)置，增加了同步接收信號和終止信號，當(dāng)同步信號有效，數(shù)據(jù)為有效數(shù)據(jù)，當(dāng)終止信號有效，則一個完整的UDP數(shù)據(jù)包就發(fā)送完成了。

當(dāng)大量的UDP數(shù)據(jù)包進(jìn)入到IP協(xié)議下準(zhǔn)備處理，而處理速度是遠(yuǎn)遠(yuǎn)小于接收的速度，會導(dǎo)致數(shù)據(jù)的滯留，甚至數(shù)據(jù)會丟失。為了解決該問題，增加了一個數(shù)據(jù)存儲模塊，把數(shù)據(jù)存儲下來，彌補(bǔ)了處理速度和接收速度的不匹配。

此模塊還額外的完成了一個功能：計(jì)數(shù)功能。在加I P數(shù)據(jù)頭需要每一包UDP數(shù)據(jù)包字節(jié)的長度信息進(jìn)行存儲。

1.2.3 IP數(shù)據(jù)包頭處理及發(fā)送模塊

每一份的IP數(shù)據(jù)包都是有IP數(shù)據(jù)包頭和對應(yīng)的UDP數(shù)據(jù)包組合成的。需要將其對應(yīng)封裝。

當(dāng)IP數(shù)據(jù)包頭處理完成了，緊接任務(wù)就是將其發(fā)送出去。在發(fā)送完IP數(shù)據(jù)包頭緊跟要發(fā)送其對應(yīng)的UDP數(shù)據(jù)包，這就是一個完整的IP數(shù)據(jù)包。如果輸出同步信號有效，這些處理好的數(shù)據(jù)將發(fā)送到數(shù)據(jù)鏈路層供其使用。

2方案綜述

（1）運(yùn)輸層和網(wǎng)絡(luò)層之間建立連接，保證數(shù)據(jù)準(zhǔn)確無誤差的傳輸?shù)骄W(wǎng)絡(luò)層，產(chǎn)生控制信號，控制數(shù)據(jù)的接收；產(chǎn)生反饋信號，保證運(yùn)輸層的UDP數(shù)據(jù)包適時的傳送過來。（2）讀取UDP數(shù)據(jù)包并準(zhǔn)確的計(jì)數(shù)，將已讀的數(shù)據(jù)存入緩存中，產(chǎn)生信號，控制IP頭處理模塊的啟動，然后將必要數(shù)據(jù)傳遞到IP頭處理模塊。（3）處理數(shù)據(jù)，將對應(yīng)的一包UDP數(shù)據(jù)產(chǎn)生相應(yīng)的IP數(shù)據(jù)包頭，形成一個IP數(shù)據(jù)包。然后將包頭發(fā)送，產(chǎn)生輸出的同步信號，之后產(chǎn)生信號讀取緩存中的數(shù)據(jù)，通過輸出端口將其發(fā)送出去。

這就是一個UDP數(shù)據(jù)包的處理過程，不斷反復(fù)以上步驟，UDP數(shù)據(jù)段就轉(zhuǎn)變成了IP數(shù)據(jù)段。

本方案增加了同步數(shù)據(jù)的輸出信號，這就可以自由的控制輸入輸出數(shù)據(jù)，不會導(dǎo)致數(shù)據(jù)的意外丟失。而這些信號還可以支持?jǐn)?shù)據(jù)間斷輸入，給運(yùn)輸層數(shù)據(jù)傳輸很大的靈活性；還增加了udp和iprd信號，它們完成這兩個層連接，給數(shù)據(jù)傳輸提供良好的初始條件。

參考文獻(xiàn)

[1]TCP-IP詳解（中文）.pdf.

[2]張帆.《基于FPGA的IP協(xié)議處理器》.湖南大學(xué)碩士論文.

udp協(xié)議范文第9篇

關(guān)鍵詞：可靠UDP；確認(rèn)重傳；滑動窗口

中圖分類號：TP311 文獻(xiàn)標(biāo)識碼：A 文章編號：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é)議所針對的業(yè)務(wù)不同，在數(shù)據(jù)傳輸?shù)乃俣群涂煽啃灾g不能達(dá)到很好的平衡。車險(xiǎn)理賠系統(tǒng)中采用的是移動理賠的思想，手持終端機(jī)通過移動通信網(wǎng)絡(luò)和后臺中心系統(tǒng)進(jìn)行數(shù)據(jù)交互。目前國內(nèi)的通信事業(yè)并不是很發(fā)達(dá)，信號覆蓋率并不全面，移動通信網(wǎng)絡(luò)的帶寬和傳輸質(zhì)量會受到地域的影響，為確保理賠現(xiàn)場與后臺系統(tǒng)間數(shù)據(jù)的及時可靠傳輸，需要基于移動通信的網(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的對比

TCP和UDP都屬于傳輸層協(xié)議，負(fù)責(zé)承擔(dān)數(shù)據(jù)傳輸?shù)娜蝿?wù)[1]。兩者之間的主要區(qū)別有：

（1） TCP和UDP是傳輸層的兩個協(xié)議，它們最大的區(qū)別是是否面向連接。TCP，在客戶端和服務(wù)器端進(jìn)行通信之前，首先要交換傳輸層控制信息，為雙方的通信做好準(zhǔn)備。UDP是一個非連接的協(xié)議，傳輸數(shù)據(jù)之前雙方不建立連接，當(dāng)傳送數(shù)據(jù)時，簡單的抓取來自應(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)和對數(shù)據(jù)包的操作過多，數(shù)據(jù)傳輸?shù)乃俣炔桓咔揖W(wǎng)絡(luò)延遲較大，所以雖然協(xié)議可靠但并不適合面向移動通信的數(shù)據(jù)傳輸；而UDP協(xié)議由于不用建立連接，沒有超時重發(fā)等可靠機(jī)制，網(wǎng)絡(luò)延遲小且數(shù)據(jù)傳輸速度很快。本文設(shè)計(jì)的理賠系統(tǒng)面向移動通信網(wǎng)絡(luò)實(shí)現(xiàn)理賠現(xiàn)場與后臺系統(tǒng)間的數(shù)據(jù)傳輸，網(wǎng)絡(luò)環(huán)境不如光纖接入網(wǎng)絡(luò)穩(wěn)定可靠，對數(shù)據(jù)的高效可靠傳輸有著很高的要求。因此，本章選用UDP協(xié)議，并在其基礎(chǔ)上，設(shè)計(jì)了連接確認(rèn)、數(shù)據(jù)確認(rèn)等可靠機(jī)制，滿足了系統(tǒng)對于高效可靠傳輸功能的需求。

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)上看，本模塊主要由以下幾個任務(wù)實(shí)現(xiàn)模塊功能：

? 通信處理模塊

1）發(fā)送方發(fā)起數(shù)據(jù)傳輸請求，三次握手成功后，發(fā)送方進(jìn)入數(shù)據(jù)包封裝模塊。

2）超時定時器的啟動和關(guān)閉。

3）當(dāng)數(shù)據(jù)傳輸結(jié)束時，接收方向發(fā)送方主動發(fā)起傳輸結(jié)束的請求。

? 數(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ù)包不一定會按序到達(dá)，所以接收方在經(jīng)過數(shù)據(jù)包解析模塊讀取數(shù)據(jù)后，根據(jù)該消息的字節(jié)序號判斷是否為亂序的分組。

2）若是順序的分組，將分組與以前收到的消息按序排列；若是要求重傳的分組，將該分組放入到所應(yīng)在的位置中。

3）如果滿足重發(fā)條件，則向發(fā)送方發(fā)送重發(fā)包請求。

2.2 核心事件處理流程

2.2.1 通信處理進(jìn)程

通信處理模塊中的通信處理進(jìn)程主要負(fù)責(zé)三次握手的發(fā)起和確認(rèn)的請求，數(shù)據(jù)傳輸結(jié)束后結(jié)束連接等任務(wù)。具體流程見圖2。首先，通信的接收方發(fā)起握手的請求，即建立一個虛連接，雙方必須確保該連接成功建立后才可以進(jìn)行下一步數(shù)據(jù)傳輸?shù)牟僮?。然后，在接收方一端啟動定時器，接收方的數(shù)據(jù)處理進(jìn)程接收發(fā)送方發(fā)送的數(shù)據(jù)，同時接收方根據(jù)定時計(jì)時器發(fā)送反饋消息；或判斷接收到的報(bào)文數(shù)，當(dāng)達(dá)到數(shù)據(jù)包累積計(jì)數(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)前序號加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)測試

3.2.1 測試環(huán)境

本測試是是在無線通信網(wǎng)絡(luò)下進(jìn)行的，配置了兩臺計(jì)算機(jī)用作數(shù)據(jù)間收發(fā)的測試，操作系統(tǒng)為Windows XP。華為E261 3G上網(wǎng)卡兩張，用于連接無線網(wǎng)絡(luò)，測試拓?fù)浣Y(jié)構(gòu)如圖4所示。

3.2.2 測試內(nèi)容

本測試采用傳輸不同大小文件的方式來對數(shù)據(jù)速度進(jìn)行測試，每次傳輸重復(fù)測試三次，然后取平均值作為參考數(shù)據(jù)，測試結(jié)果見表1和表2。其中，表1是在最大連接速率7.2Mbps環(huán)境下的測試結(jié)果，表2是在連接速率為2.2Mbps環(huán)境下的測試結(jié)果。

由表1可見，在移動通信的網(wǎng)絡(luò)連接環(huán)境為7.2Mbps時，當(dāng)傳輸1MB的數(shù)據(jù)時，TCP協(xié)議測試耗時9.75s，平均傳輸速度約為105KB/s；可靠UDP耗時8.25s，平均傳輸速度約為124KB/s。當(dāng)傳輸數(shù)據(jù)為32MB時，TCP耗時295.89s，平均傳輸速度約為120KB/s；可靠UDP耗時197.05s平均傳輸速度約為168KB/s。

由表2可見，在移動通信的網(wǎng)絡(luò)連接環(huán)境為2.2Mbps時，由于連接環(huán)境較差，測試文件并不大，當(dāng)傳輸0..36s，平均傳輸速度約為21KB/s；可靠UDP耗時190.81s，平均傳輸速度約為43KB/s。

由此可得出：

（1）可靠UDP傳輸協(xié)議的優(yōu)勢隨著傳輸數(shù)據(jù)量的增大而越來越明顯。

（2）可靠UDP傳輸協(xié)議的優(yōu)勢隨著網(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://www.bizone66.com/v-141-2653.htmludp協(xié)議范文10篇

聲明：本網(wǎng)頁內(nèi)容由互聯(lián)網(wǎng)博主自發(fā)貢獻(xiàn)，不代表本站觀點(diǎn)，本站不承擔(dān)任何法律責(zé)任。天上不會到餡餅，請大家謹(jǐn)防詐騙！若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系，我們將在第一時間刪除處理。

顯示全文

上一篇：ui設(shè)計(jì)論文范文10篇

下一篇：ui設(shè)計(jì)范文10篇

相關(guān)文章：

歡度春節(jié)宣傳標(biāo)語01-30

求職時自我介紹簡短01-21

環(huán)境調(diào)查報(bào)告11-09

酸楚的傷感文案心里酸楚的文案09-21

蘋果返校季教育優(yōu)惠開啟：買Mac、iPad送AirPods、Apple Pencil07-10

qq空間傷感句子96條02-12

訂婚紀(jì)念日對老婆說的話10-26

元宵猜燈謎活動總結(jié)05-08