udp協(xié)議范文第1篇
關鍵詞:用戶數(shù)據(jù)報協(xié)議;通信;報文分析;Sniffer
中圖分類號:TP312 文獻標識碼: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體系結構中一種無連接的傳輸層協(xié)議,提供面向事務的簡單不可靠信息傳送服務。UDP 協(xié)議是 IP 協(xié)議與上層協(xié)議的接口,用端口號分別為運行在同一設備上的多個應用程序提供服務。它定義在IETF RFC 768中[1]。
UDP是分發(fā)信息的理想?yún)f(xié)議,適用于追求效率且不需要額外可靠機制的情形,如音、視頻流媒體分發(fā)、高層協(xié)議或應用程序提供錯誤和流控制功能時的快速數(shù)據(jù)分發(fā)。 UDP服務于很多知名應用,如網(wǎng)絡文件系統(tǒng)(NFS)、簡單網(wǎng)絡管理協(xié)議(SNMP)、域名系統(tǒng)(DNS)以及簡單文件傳輸系統(tǒng)(TFTP)、動態(tài)主機配置協(xié)議(DHCP)、路由信息協(xié)議(RIP)等。
1 UDP協(xié)議使用
在Windows下使用UDP不需要實現(xiàn)RFC 768中定義的UDP細節(jié),封閉的Windows操作系統(tǒng)為用戶實現(xiàn)了協(xié)議,以動態(tài)鏈接庫及API的形式提供給用戶程序調用。這種方式方便了程序設計,但也阻止了用戶對網(wǎng)絡協(xié)議的更深理解。為了更加深入研究UDP有必要對傳輸報文流進行分析;為了更好的分析,需要實現(xiàn)一個使用UDP的通信程序。
在windows下選用VC6.0編譯器。服務器端代碼如下:
#include //基本輸入輸出庫
#include //網(wǎng)絡API函數(shù)庫
#pragma comment (lib,"WS2_32.lib")/*將WS2_32.lib加入鏈接,不用再為這個鏈接文件設置鏈接選項了*/
void main()
{ WORD wVersionRequested;
WSADATA wsaData;
int err;
wVersionRequested = MAKEWORD( 1, 1 );
err = WSAStartup( wVersionRequested, &wsaData );
if ( err != 0 ) {
return; /* 處理找不到 WinSock DLL.*/}
/* 確認 WinSock DLL 支持的版本 */
if ( LOBYTE( wsaData.wVersion ) != 1 ||HIBYTE( wsaData.wVersion ) != 1 ) {
WSACleanup( ); return;
}/* [3]以上代碼為MSDN提供的設計windows下網(wǎng)絡程序的標準方法*/
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主機字節(jié)序變?yōu)榫W(wǎng)絡字節(jié)序*/
addrSrv.sin_family=AF_INET;
addrSrv.sin_port=htons(6666);
err=bind(sockSrv,(SOCKADDR *)&addrSrv,sizeof(SOCKADDR)); /*綁定主機從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初始化和服務器端一樣,不同的是socket函數(shù)的使用。
//頭文件和服務器端一樣
void main()
{…
//初始化和服務器端一樣
/* 以上代碼為MSDN提供的設計windows下網(wǎng)絡程序的標準方法,*/
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");/*設置目標地址,根據(jù)服務器端情況*/
addrSrv.sin_family=AF_INET;
addrSrv.sin_port=htons(6666);//與服務器端一致
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ǎng)絡地址為192.168.1.102?？蛻舳瞬幌?只要和服務間路由可達即可,本例中使用192.168.1.100。如不想更改服務器端IP地址,只要按照程序注釋,根據(jù)實際情況更改客戶程序的addrSrv.sin_addr.S_un.S_addr變量即可。
2 報文捕獲與分析
圖1為客戶端IP192.168.1.100向服務器端IP192.168.1.103發(fā)出數(shù)據(jù)“test”后,由服務器端的sniffer捕獲的報文。
UDP報文為灰色開始的0c 96 1a 0a 00 0d 6d 3e 74 65 73 74 00共13字節(jié)。UDP前45開始到67為標準IP報文頭共20個字節(jié),報文開頭的00到08 00(IP報文頭前)14個字節(jié)為DLC(Data Link Control)報文頭。UDP報文中,0c 96源端口號,兩字節(jié),客戶端用于接收信息的端口號,不需要回復可用全零。1a 0a 目的端口號,兩字節(jié),服務器端的接收端口號。00 0d 數(shù)據(jù)包長度,兩字節(jié),本示例為13。6d 3e 校驗和,兩字節(jié)。74 65 73 74 00 數(shù)據(jù)包的內容,74 65 73 74 為“test”的ASCII編碼,00通過源程序可以發(fā)現(xiàn),為了接收端處理方便多發(fā)的一個空字節(jié)。
圖2為服務器端103接收到“test”后,向客戶端發(fā)送“received test”數(shù)據(jù),由服務器端的sniffer軟件捕獲的報文。
UDP報文為灰色開始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目的端口號,與前一報文正好相反。00 16 數(shù)據(jù)包長度22字節(jié)。B6 78 校驗和,72 65 63 65 69 76 65 64 20 74 65 73 74 00 是數(shù)據(jù)報的內容,同樣多發(fā)了一個空字節(jié)。
由協(xié)議分析可知,UDP位于IP報文的數(shù)據(jù)域中,由源端口、目的端口、長度、校驗和、和數(shù)據(jù)域組成,采用明文傳遞應用數(shù)據(jù)。如果傳遞重要信息一定要在應用層加密,否則很容易被竊取。UDP在發(fā)送數(shù)據(jù)時附帶自身的端口號,接收時不需要確認,所以可以方便的進行一對一、一對多和多對多的交互通信,這種方式方便但存在缺陷,如果被攻擊者知道服務的端口號,控制多臺主機向服務器發(fā)送大量垃圾信息,可使服務器癱瘓。這是此類協(xié)議的共有的弱點。
3 結束語
傳輸層的UDP協(xié)議由于其簡潔、高效性而被廣泛使用,是一種重要的協(xié)議。該文介紹的UDP協(xié)議使用方法具有通用性,可作為開發(fā)、學習此類軟件參考。UDP協(xié)議由于沒有安全控制,采用UDP協(xié)議的系統(tǒng)在提供服務時最好放在防火墻內,由系統(tǒng)對它提供安全保證。
參考文獻:
[1] 謝希仁.計算機網(wǎng)絡[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].吳時霖,等,譯.北京:機械工業(yè)出版社,2007.7,445-472.
udp協(xié)議范文第2篇
關鍵詞：P2P；CDP；NAT 穿透；基于UDP的TCP
中圖分類號：TP317文獻標識碼：A 文章編號：1009-3044(2007)03-10736-02
1 引言
隨著互聯(lián)網(wǎng)應用廣泛推廣，基于各種P2P網(wǎng)絡技術的產(chǎn)品也越來越多的出現(xiàn)在我們的視野當中。從最早的Napster 到現(xiàn)在的Bittorrent、eMule、skype等產(chǎn)品，P2P這種網(wǎng)絡應用模式已經(jīng)從各個方面深入人心。這些產(chǎn)品在網(wǎng)絡實現(xiàn)技術上，都以各自的方法解決著同樣面臨的一個問題，如何讓他們的軟件產(chǎn)品在各異的網(wǎng)絡拓撲結構中順利的進行P2P通信。
眾所周知，在當今的網(wǎng)絡拓撲結構中，普遍使用NAT設備來進行網(wǎng)絡地址轉換，那么如何讓應用程序跨越這些NAT設備進行全雙工通信，就成為非常重要的問題。實現(xiàn)跨越NAT 通信有很多種辦法：首先是通過服務器進行轉發(fā)，這是比較粗暴的方法，在用戶量較大時，轉發(fā)服務器需要付出相當大的代價；其次，可以使用NAT 穿透技術。而在NAT 穿透中，UDP 穿透的成功率比起TCP 穿透要高出許多[1]。因此在UDP 協(xié)議上構建一些大型的網(wǎng)絡應用程序可能會成為很多人的需求。
由于UDP協(xié)議本身存在通信不可靠的缺點，對于基于UDP 進行可靠通信的需求就浮現(xiàn)出來了。目前在網(wǎng)絡上有許多人正在做著這一工作，UDT、RakNet、eNet 等都是構建在UDP之上的網(wǎng)絡可靠通信開發(fā)庫，但這些庫都是針對一些特殊應用進行設計的，不具備通用性。本文提出的CDP協(xié)議是在UDP基礎之上實現(xiàn)的TCP協(xié)議。同時具備了TCP的通用、高效和UDP的高穿透成功率，并提供了簡單易用的應用程序開發(fā)接口。
2 CDP設計目標
CDP主要的目標就是在UDP 層之上實現(xiàn)TCP 的協(xié)議算法，使得應用程序能夠在UDP 層之上獲得通用、可靠、高效的通信能力。CDP 網(wǎng)絡開發(fā)庫所實現(xiàn)的算法，都來自久經(jīng)考驗的TCP協(xié)議算法，以下協(xié)議設計部分主要講解CDP實現(xiàn)中與TCP標準不同的部分。
3 CDP協(xié)議設計
CDP協(xié)議主要在以下幾個方面與TCP有所不同：協(xié)議格式、連接建立（NAT UDP PUNCH模式）、保活機制、MTU發(fā)現(xiàn)與MSS通告。其他部分，如報文傳輸、流量控制、超時重傳、擁塞控制等，均參照TCP協(xié)議實現(xiàn)[2]。下面將對幾個不同部分分別進行說明。
3.1 協(xié)議格式
CDP的實現(xiàn)的算法雖然與TCP 實現(xiàn)的算法是大致相同的,但CDP 的協(xié)議格式只是從TCP協(xié)議格式獲得參考，但并不完全與他相同，CDP協(xié)議格式如圖1所示。
圖中各字段意義分別為：
4 位首部長度：表示用戶數(shù)據(jù)在數(shù)據(jù)包中的起始位置。
LIV：連接保活標志。
ACK：確認序號有效。
PSH：接收方應該盡快將這個報文段交給應用層。
RST：重置連接。
SYN：同步序號，用來發(fā)起一個連接。
FIN：發(fā)端完成發(fā)送任務。
16 位窗口大?。航邮斩丝山邮諗?shù)據(jù)的窗口大小。
選項：只有一個選項字段，為最長報文大小，即MSS。CDP 選項格式與TCP 選項格式一致，kind=0 時表示選項結束，kind=1 時表示無操作，kind=2 時表示最大報文段長度。如下圖：
圖2 CDP選項字段
數(shù)據(jù)：用戶通過CDP 傳輸?shù)臄?shù)據(jù)。
3.2 連接建立（NAT UDP PUNCH模式）
一般情況下，CDP連接的建立過程與TCP相同。但當CDP工作在UDP NAT 穿透（NAT UDP PUNCH）模式下時，在三次握手之前，先要向對端NAT 端口及預測端口以默認2ms的間隔發(fā)送默認為10個LIV報文，一來用于打開自已的NAT 端口，二來是用于進入對端NAT端口。默認值可以由用戶程序設置。這時的LIV 報文中初始序號及確認序號都為0。
當接收到對端LIV 報文后，CDP立即停止LIV 報文發(fā)送，發(fā)出SYN 報文進行連接建立。這時有兩種可能：一是對端直到接收到該SYN 報文，都沒有接收到LIV 報文，或是剛接收到LIV報文，但沒有來得及發(fā)送SYN 報文，此時將會和一般模式下連接建立的過程一致，經(jīng)歷三次握手；二是對端在接收到該SYN 報文之前，也已經(jīng)發(fā)送SYN報文，此時雙方都需要對SYN 報文段進行確認。
3.3 半打開連接及連接?；?span style="display:none">piD萬博士范文網(wǎng)-您身邊的范文參考網(wǎng)站Vanbs.com
半打開連接是指對端異常關閉，如網(wǎng)線拔掉、突然斷電等情況導致一端關閉，而另一端卻認為連接仍處于打開當中，這種情況稱之為半打開連接。CDP中的一個TDP SOCKET描述符由本地IP、本地端口、遠端IP、遠端端口唯一確定。當遠端客戶端連接請求到來時，服務端將接收到一個新的CDP SOCKET描述符，當這一個描述符唯一確定信息已經(jīng)存在時，對新的連接請求發(fā)送RST 報文段，通知其重置連接請求。對于舊的連接，由?；顧C制自動發(fā)現(xiàn)是否為半打開連接，如果是半打開連接，則自動關閉該連接。CDP的RST 報文與TCP 中的RST 報文是不一樣的。
連接建立之后，CDP 連接需要啟動?；顧C制。TCP 連接在沒有數(shù)據(jù)通信的情況下也能保持連接，但CDP 連接不行。CDP 連接在一定時間內如果沒有數(shù)據(jù)交互的話，將主動發(fā)送?；頛IV報文段。這個時間根據(jù)CDP 連接工作模塊不同有所差異，在NAT UDP PUNCH 模式下，默認值為1 分鐘（大多數(shù)的NAT中，UDP會話超時時間為2－5分鐘左右）；而在常規(guī)模塊下這個時間段默認值為5分鐘。默認值可以由用戶程序設置，用戶程序需要指明兩種模式下的?；顣r間周期。
3.4 路徑MTU 發(fā)現(xiàn)及MSS 通告
CDP連接建立過程中會通告初始MSS(Maximum Segment Size)，這個值可以由用戶程序進行設置。但這個初始值是靜態(tài)的，當通信雙方跨越多個網(wǎng)絡時，使用設置的MSS可能導致傳輸?shù)腎P 報文分片的產(chǎn)生。為了避免分片，CDP在數(shù)據(jù)傳輸過程中進行動態(tài)的路徑MTU(Maximum Transmission Unit)發(fā)現(xiàn)，并進行MSS 的更新及通告。
CDP創(chuàng)建UDP SOCKET時，即將IP選項設置為不允許分片： Setsockopt（clientSock, IPPROTO_IP, IP_DONTFRAGMENT, (char*)&dwFlags, sizeof(dwFlag) )。
在發(fā)送數(shù)據(jù)時先以當前MSS 大小進行發(fā)送，如果返回值為錯誤碼WSAEMSGSIZE（10040），則表示為報文尺寸大于MTU，需要進行IP 分片傳輸。此時，縮減MSS大小再次發(fā)送，直至不再返回錯誤碼WSAEMSGSIZE（10040）。當MSS 變更并能成功發(fā)送報文后，需要向對端通報新的MSS 值。每次MSS 縮小后，默認隔30 秒，CDP 將默認擴大MSS 大小，以檢查是否路徑MTU 是否增大了，之后隔30*2 秒、30*2*2 秒進行檢測，如果三次都未發(fā)現(xiàn)MTU 增大則停止進行檢測。網(wǎng)絡中MTU 值的個數(shù)是有限的[3]。因此MSS 的擴大及縮減，可依據(jù)一些由近似值按序構成的表，依照此表索引進行MSS 值的擴大與縮減計算。
CDP 中MSS 與MTU 之間關系的計算公式如下：MSS = MTUC20(IP首部)C8(UDP首部)C12(CDP首部)。
4 CDP應用程序開發(fā)接口（CDP Socket API）
使用CDP進行網(wǎng)絡程序開發(fā)是非常容易的，它API與標準socket API是非常相似的，對應功能的函數(shù)名稱都相同，只是CDP的所有API都處于名稱空間CDP 之下。此程序庫的實現(xiàn)也參考了BSD Socket的實現(xiàn)。CDP Socket API列表如下：
5 結束語
本文提出了一種基于UDP協(xié)議之上的TCP協(xié)議實現(xiàn)――CDP協(xié)議，并對現(xiàn)實的一些關鍵部分進行了討論，最后給出了CDP協(xié)議的應用開發(fā)接口。CDP協(xié)議同時具備了TCP通用、高效的特點，有利用的UDP的NAT穿透特性，可廣泛應用與構建各種P2P網(wǎng)絡應用。
參考文獻：
[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]，機械工業(yè)出版社，2000.4.1.
[3]J. Mogul, S. Deering, "Path MTU Discovery"[S], RFC1191, November 1990.
udp協(xié)議范文第3篇
關鍵詞：UDP協(xié)議；廣播；多播；Delphi5.0
中圖分類號：TP311.1 文獻標識碼：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ù)報協(xié)議）。TCP為兩臺主機提供高可靠性的數(shù)據(jù)通訊，UDP為應用層提供了一種非常簡單的服務，它只是把稱作數(shù)據(jù)報的分組從一臺主機發(fā)送到另一臺主機，但并不保證該數(shù)據(jù)報能到達另一端。與TCP相比UDP的優(yōu)勢就在于它排除了信息可靠傳遞機制，將安全和排序等功能移交給上層應用來完成，極大降低了執(zhí)行時間，保證了運行速度。單播、廣播、組播則表示的是數(shù)據(jù)在網(wǎng)絡中“播放”的形式，是指有一個人能聽到還是讓特定的人群聽得到，還是讓所有的人都聽的到的區(qū)別。一臺主機要向網(wǎng)上的所有其他主機發(fā)送幀，這就是廣播；多播處于單播和廣播之間，向屬于多播組的多個主機發(fā)送幀。
一、廣播與多播的實現(xiàn)
下面我們就詳細介紹一下Delphi5.0開發(fā)環(huán)境下廣播和多播的實現(xiàn)。軟件開發(fā)步驟如下：
（一）網(wǎng)絡初始化
1.首先初始化WinSock動態(tài)連接庫，創(chuàng)建Socket套接字，用下面語句綁定發(fā)送方Addr：
Addr.sin_family：=AF_INET；
Addr.sin_addr.S_addr：=INADDR_ANY；//本機接收地址設為任意地址
Addr.sin_port：=htons（UDPPORT）； //設定本機UDP端口號
函數(shù)htons將端口號由主機字節(jié)順序轉換為網(wǎng)絡字節(jié)順序，然后將套接字綁定到一個本地地址和端口上（bind），設置為異步選擇，設定接收端SockAddrIn：
FSockAddrIn.SIn_Family：=AF_INET；
FSockAddrIn.SIn_Port：=htons（UDPPORT）；//接收端端口設置
2.廣播接口設置。廣播方式有兩種，一種是limited broadcast，廣播地址是255.255.255.255；一種是directed broadcast。limited broadcast初始化時代碼如下： SetSockopt（FSocket，SOL_SOCKET，SO_BROADCAST，@broadcast，sizeof（broadcast））；
directed broadcast不需要SetSockopt（），以標準的C類網(wǎng)為例，直接發(fā)送x.x.x.255就可以了。這種廣播只有同一邏輯子網(wǎng)中的機器才能收到，也就是說對方地址應該是x.x.x.y，如果不是，即使在同一物理子網(wǎng)中也是收不到的。當然，這和子網(wǎng)掩碼有關。limited broadcast廣播的好處是只要在同一子網(wǎng)中的主機，就可以收到這種廣播，而不必非要在統(tǒng)一邏輯子網(wǎng)中。例如，如果你的地址是x.x.x.1，那么這種廣播，地址是x.y.z.a的主機也能收到。
3.多播接口設置。mreq.imr_multiaddr.S_addr：=inet_addr（pchar（MY_GROUP））；//設定多播地址mreq.imr_interface.S_addr：=htonl（INADDR_ANY）；//設定本機接收端口。
（二）網(wǎng)絡數(shù)據(jù)的讀取
flen：=sizeof（FSockAddrIn）；//獲取字節(jié)長度
FSockAddrIn.SIn_Port ：= htons（UDPPORT）；//設定本機接收端口
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)絡數(shù)據(jù)接收，buffer是緩沖區(qū)。
（三）網(wǎng)絡數(shù)據(jù)的發(fā)送。
首先定義一個string變量和一個integer變量，然后設置遠端主機地址：
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)絡數(shù)據(jù)發(fā)送
if（WSAGetLastError（） WSAEWOULDBLOCK）and（WSAGetLastError（） 0）then //網(wǎng)絡數(shù)據(jù)發(fā)送異常判斷
showmessage（inttostr（WSAGetLastError（）））；
（四）關閉網(wǎng)絡接口
CloseSocket（FSocket）；//關閉Socket
二、結束語
經(jīng)測試，該軟件能成功實現(xiàn)UDP協(xié)議下的廣播和多播。測試結果如圖1、圖2所示。
圖1 UDP廣播測試結果圖2UDP多播測試結果
參考文獻：
[1]袁振武.謝任東.談Delphi編程中UDP協(xié)議的應用[J].科技廣場,2008,05
udp協(xié)議范文第4篇
關鍵詞:UDP;RUDP;可靠性
中圖分類號:TP393文獻標識碼: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)絡層協(xié)議(IP),但它向應用層提供了與UDP完全不同的服務,它提供一種面向連接的、可靠的字節(jié)流服務。面向連接意味著兩個使用TCP的應用在彼此交換數(shù)據(jù)之前必須先建立一個TCP連接,數(shù)據(jù)傳輸完成后,再經(jīng)過4次握手終止雙方的連接。在數(shù)據(jù)傳輸?shù)倪^程中,TCP還通過對數(shù)據(jù)的確認、流量控制等手段提高通信的可靠性。
1.2 UDP協(xié)議
UDP(User Datagram Protocol),即用戶數(shù)據(jù)報協(xié)議。在TCP/IP網(wǎng)絡通信中, UDP協(xié)議是一種面向無連接的服務。它發(fā)送數(shù)據(jù)以獨立的數(shù)據(jù)包形式,不保證各數(shù)據(jù)包的發(fā)送順序,也不進行正確性檢查,因此,可能出現(xiàn)數(shù)據(jù)的重發(fā)、丟失、失序等現(xiàn)象[2]。使用UDP協(xié)議的常見服務有DNS、QQ等。
UDP協(xié)議直接向接收方發(fā)送數(shù)據(jù)而不關心對方計算機的狀態(tài),因此,它是一種相對不可靠的通信協(xié)議。正因為UDP協(xié)議不考慮網(wǎng)絡數(shù)據(jù)傳輸過程中的很多問題,所以能節(jié)省了大量的網(wǎng)絡狀態(tài)確認和數(shù)據(jù)確認的系統(tǒng)資源消耗,從而提高UDP協(xié)議的傳輸速度和網(wǎng)絡的利用效率。可是,如果既能充分利用UDP協(xié)議的這些優(yōu)勢,又能保證UDP通信的可靠性,網(wǎng)絡通信系統(tǒng)的性能將會得到更大程度地提高。
2 RUDP 協(xié)議的提出
2.1 嵌入式設備可靠通信面臨的問題
面向連接方式的服務功能明顯很強大,它能夠發(fā)揮面向連接的傳輸所具備的特性,例如流量控制,差錯處理以及順序交付等等,但是面向無連接的服務更適合于某些情況,在網(wǎng)絡層上使用IP協(xié)議就是一個面向無連接的服務而且這個面向無連接的服務顯得更加健壯,因為Internet本身就是一個不穩(wěn)定的環(huán)境,面向連接的服務反而不能很好的運行于其上。
如果使用TCP連接協(xié)議實現(xiàn)嵌入式設備之間的數(shù)據(jù)傳輸可能帶來許多的問題,嵌入式設備之間建立TCP連接并發(fā)送數(shù)據(jù)后,或者接收端向正在請求連接的設備發(fā)出SYN+ACK應答報文后,都可能無法接收到終端的ACK報文,在這種情況下發(fā)送端一般會重試并等待一段時間后終止這個連接。大量重傳數(shù)據(jù)會進一步加劇網(wǎng)絡的擁塞情況,嚴重時可以使網(wǎng)絡及服務器系統(tǒng)崩潰,同時也會對數(shù)據(jù)傳輸?shù)膶崟r性產(chǎn)生影響。同時目前嵌入式設備又存在多點分散、數(shù)據(jù)量小、實時性要求高等特點[3]。本文將在UDP協(xié)議的基礎上提出并實現(xiàn)嵌入式設備的可靠數(shù)據(jù)傳輸。
2.2 嵌入式可靠傳輸模型的體系結構
RUDP協(xié)議軟件模塊底層采用UDP作為承載協(xié)議,提供基于消息的可靠通信功能。根據(jù)計算機網(wǎng)絡層次體系的概念,RUDP協(xié)議的層次模型就是在原UDP/IP協(xié)議的傳輸層和應用層之間加入了RUDP層和標志層。RUDP協(xié)議的層次結構如表1所示。
RUDP層的功能是保證數(shù)據(jù)的可靠傳送。由于嵌入式設備通過網(wǎng)絡進行消息的收發(fā)是處于一個公共網(wǎng)絡的環(huán)境之中,可能會有大量無用的數(shù)據(jù)向嵌入式設備進行發(fā)送,大量的數(shù)據(jù)解析會極大地增加嵌入式設備的負擔。為了避免這個問題,我們增加了一個標志層,標志層可以讓嵌入式設備迅速的判斷所接收的數(shù)據(jù)包是否為有效數(shù)據(jù)包,如果標志層數(shù)據(jù)不可識別,則迅速將包丟棄。在可靠傳輸層進行可靠傳輸設計和實現(xiàn),在這一層,我們增加一系列可靠傳輸機制以保證嵌入式設備之間數(shù)據(jù)的可靠傳輸。這樣就形成了一個原UDP協(xié)議所在傳輸層和應用層之間加入了一層為保證可靠數(shù)據(jù)傳送而實現(xiàn)的RUDP軟件模塊和標志層的六層體系結構。從而,在UDP協(xié)議的基礎上實現(xiàn)一種基于消息的面向連接的,適合嵌入式設備的可靠數(shù)據(jù)傳遞機制。
2.3 嵌入式可靠傳輸模型的基本功能
嵌入式可靠傳輸模型RUDP主要功能有:
1) 基于消息的收發(fā)功能:RUDP的傳輸層利用基于消息的傳輸協(xié)議,所以不必考慮發(fā)送端可以接收多少數(shù)據(jù),只需知道能否接收數(shù)據(jù)即可。
2) 校驗和:RUDP的校驗和算法采用UDP的校驗功能保證數(shù)據(jù)包的正確和順序到達。UDP校驗和字段是對整個UDP報文頭和UDP所帶的數(shù)據(jù)的校驗和。
3) 丟棄重復包和保存失序包的功能:每當收到數(shù)據(jù)包后,便對數(shù)據(jù)包進行確認。保存未確認的數(shù)據(jù)包,丟棄已經(jīng)確認了的重復包。由于UDP傳送過程中,收到的數(shù)據(jù)包的順序可能會和發(fā)送的順序有一定的區(qū)別,所以保存失序包能夠有效的減少重發(fā)的次數(shù),也就是能相應的減少網(wǎng)絡的數(shù)據(jù)流量。
4) 超時重發(fā)功能:RUDP中借鑒TCP中的超時重發(fā)機制來保證數(shù)據(jù)包的可靠傳遞;同時TCP中的確認延遲功能也得到借鑒,這樣可以顯著降低網(wǎng)絡的流量,提高嵌入式系統(tǒng)的通信效率。
5) 服務器和客戶端保活功能:探測收發(fā)兩端的連接是否正常時嵌入式可靠傳輸模型中必須要實現(xiàn)的一個功能。如果連接已經(jīng)出錯,若干數(shù)據(jù)包仍然發(fā)送,當超時定時器到時后就會進行數(shù)據(jù)的重發(fā)。如果沒有判斷收發(fā)兩端的連接是否正常,則會導致數(shù)據(jù)無法正常而又高效的發(fā)送。
2.4 RUDP協(xié)議工作過程
RUDP協(xié)議的工作過程是:首先,建立連接。發(fā)送方和接收方通過三次握手的方式建立連接(三次握手過程如圖1所示)。第三次握手時,發(fā)送方發(fā)給接收方的數(shù)據(jù)幀中除了包含對接收方的確認信息之外,還包含將要發(fā)送的數(shù)據(jù)幀總數(shù)。接收方收到確認幀后,開始與發(fā)送方建立連接。與此同時將根據(jù)收到的幀總數(shù)設置接收窗口大小并將所有幀序號放入緩存。雙方連接建立好后保證了數(shù)據(jù)發(fā)送和接收的同步性。
接著,發(fā)送方開始發(fā)送數(shù)據(jù)幀,接收方收到數(shù)據(jù)幀并進行處理。能夠正確接收到的幀序號將會從序號緩存中刪除。發(fā)送方發(fā)送完數(shù)據(jù)幀后發(fā)送“發(fā)送完”標志給接收方。接收方收到此標志后,開始掃描幀序號緩存。如果數(shù)據(jù)幀全部接收到,接收方向發(fā)送方發(fā)送一“接收完”標志,發(fā)送方收到后斷開連接。如果序號緩存中有序號則說明有幀丟失,這時接收方將向發(fā)送方發(fā)出一個帶有丟失幀序號的確認幀。發(fā)送方收到此確認幀后將重新發(fā)送丟失幀。如此重復,直到接收方完全正確接收到數(shù)據(jù)幀。其工作過程如圖2所示。
3 總結
通過分析比較傳輸層協(xié)議TCP和UDP,能夠看到它們各自的特點,并分析出它們各自的優(yōu)勢和缺點。結合嵌入式設備數(shù)據(jù)傳輸?shù)奶攸c同時針對UDP在可靠性方面的不足進行了改進,簡單介紹了RUDP協(xié)議的原理和工作過程。通過分析可以看出采用RUDP的效率在嵌入式設備數(shù)據(jù)傳輸中要優(yōu)于UDP協(xié)議,這樣就可以實現(xiàn)一種更適合于嵌入式設備的可靠數(shù)據(jù)傳遞機制。
參考文獻:
[1] Wright G R,Stevens W R. TCP/ IP 詳解卷2:實現(xiàn)[M].陸雪瑩,蔣慧,譯.北京:機械工業(yè)出版社,1999.
[2] Comer D E. 用TCP/IP進行網(wǎng)絡互聯(lián)[M].張娟,王海,譯.卷2.北京:電子工業(yè)出版社,1998.
udp協(xié)議范文第5篇
引 言
超文本傳輸協(xié)議（HTTP）是目前通過Internet進行信息交換最主要的方式。HTTP協(xié)議是建立在請求/響應(request/response)模型上的。首先由客戶建立一條與服務器的TCP鏈接，并發(fā)送一個請求到服務器，請求中包含請求方法、URI、協(xié)議版本以及相關的MIME(Multipurpose Internet Mail Extensions)樣式的消息。服務器響應一個狀態(tài)行，包含消息的協(xié)議版本、一個成功和失敗碼以及相關的MIME式樣的消息(包含服務器的信息、資源實體的信息和可能的資源內容)。圖1給出了HTTP協(xié)議實現(xiàn)的一個簡單模型。HTTP/1.0[3]為每一次HTTP的請求/響應建立一條新的TCP鏈接，因此一個包含HTML內容和圖片的頁面將需要建立多次的短期的TCP鏈接。一次TCP鏈接的建立將需要3次握手。另外，為了獲得適當?shù)膫鬏斔俣?，則需要TCP花費額外的回路鏈接時間（RTT）。每一次鏈接的建立需要這種經(jīng)常性的開銷，而其并不帶有實際有用的數(shù)據(jù)，只是保證鏈接的可靠性，因此HTTP/1.1[4]提出了可持續(xù)鏈接的實現(xiàn)方法。HTTP/1.1將只建立一次TCP的鏈接而重復地使用它傳輸一系列的請求/響應消息，因此減少了鏈接建立的次數(shù)和經(jīng)常性的鏈接開銷。
可持續(xù)鏈接減少了每次TCP鏈接建立的時間，但是一個空閑的TCP鏈接將需要一個Socket和相應的存儲緩沖區(qū)。一個Socket緩沖區(qū)的最小長度必須大于一個TCP包的最大長度，即64 KB，而且很多實現(xiàn)方法在鏈接建立時將預分配一些緩沖區(qū)?？捎玫腟ocket的數(shù)量是有限的，很多基于BSD的操作系統(tǒng)對于能夠同時打開的鏈接數(shù)都有一個缺省的最大值。
無線掌上設備PDA的應用（如瀏覽器）[5]特點表現(xiàn)在：① 因為頁面是針對掌上設備制作的，一般在1 K~2 K字節(jié)，比較小；② 目前無線通信網(wǎng)絡的帶寬很窄，GSM的數(shù)據(jù)信道帶寬只有9.6 K。當前Web頁面的訪問大多通過HTTP協(xié)議，并使用TCP作為下層的傳輸控制協(xié)議。但不幸的是，TCP并不適合短會話的應用情況，不同于現(xiàn)在采用的使用單一TCP傳輸協(xié)議進行數(shù)據(jù)傳輸?shù)姆绞?。本文提出了采用動態(tài)選擇傳輸層協(xié)議（TCP、UDP）的方法來改善取回頁面的延遲、網(wǎng)絡擁塞以及服務器的負荷。
這種混合TCP-UDP的方法結合兩個方面的優(yōu)點：首先，對于需要比較少數(shù)據(jù)傳輸?shù)那闆r，它將使用UDP作為傳輸層的協(xié)議，從而避免了TCP鏈接的多次握手開銷；另外，對于需要較多數(shù)據(jù)傳輸?shù)那闆r，它將使用可靠的帶有重排序和擁塞控制的TCP協(xié)議作為傳輸層的協(xié)議?；旌蟃CP-UDP的實現(xiàn)方法只需要對應用層的改動，而操作系統(tǒng)的核心代碼不用任何更改。僅采用UDP協(xié)議的缺點在于，需要在應用層建立一套類似于TCP復雜的控制協(xié)議，從而進行重排序和擁塞控制來保證傳輸?shù)目煽啃浴?span style="display:none">piD萬博士范文網(wǎng)-您身邊的范文參考網(wǎng)站Vanbs.com
1 背 景
HTTP是一個請求/響應協(xié)議，客戶端的應用程序通過提供一個URL可以從服務器上得到所需的數(shù)據(jù)。HTTP可以用來訪問各種不同類型的資源，其中包括文本、圖形、影音、可執(zhí)行文件、數(shù)據(jù)庫查詢結果等等。
圖2給出了在客戶端發(fā)起HTTP GET請求后，在客戶端和服務器之間進行數(shù)據(jù)包交換的示意。圖中只有兩個數(shù)據(jù)包是有用的（即攜帶了數(shù)據(jù)）：一個是HTTP GET請求，另一個是HTTP的響應。其它的都是TCP用來進行握手操作的數(shù)據(jù)包。為了減輕Web服務器的負荷，經(jīng)常采用重定向機制。這樣從服務器發(fā)來的重定向響應報文是很短的數(shù)據(jù)包。使用TCP作為傳輸協(xié)議需要至少7個數(shù)據(jù)包，而使用UDP則只需要2個數(shù)據(jù)包就足夠了。
2 設 計
我們使用混合傳輸層[6]的方法即對于少量數(shù)據(jù)傳輸?shù)逆溄硬捎肬DP，而對于大量數(shù)據(jù)傳輸?shù)逆溄硬捎肨CP作為傳輸層協(xié)議。這樣對于短鏈接而言就避免了TCP經(jīng)常性的握手開銷，而對于長鏈接則仍可獲得TCP的優(yōu)點，如超時重傳、擁塞控制、錯誤恢復機制等。這種方法中，客戶端首先嘗試使用UDP作為傳輸層的協(xié)議，如果對于所請求的URL UDP并不適合，則再次使用TCP鏈接。這種方法提供了以下保證：
如果初始的UDP數(shù)據(jù)包丟失，將采用TCP重新鏈接而不會受到影響。
如果所鏈接的服務器沒有使用混合傳輸層的實現(xiàn)機制，客戶端將使用TCP重新進行鏈接。
圖3給出了混合TCP、UDP的實現(xiàn)算法。一個采用混合算法的HTTP客戶端首先使用UDP作為傳輸層的協(xié)議發(fā)出HTTP GET請求，同時啟動超時定時器。
當服務器處理客戶端發(fā)來的請求時，它可以從以下兩點做出選擇：
① 如果響應的數(shù)據(jù)足夠?。ū热?，可放到一個數(shù)據(jù)包中），服務器將使用UDP發(fā)回響應。像比較小的網(wǎng)頁或HTTP REDIRECT響應就屬于這一類。
② 如果響應的數(shù)據(jù)很大，無法放進一個UDP數(shù)據(jù)包中，服務器則要求客戶端使用TCP重試。這可以通過添加一個HTTP的頭部字段來解決如 TCPRETR。
在客戶端，將會出現(xiàn)以下三種情況：
客戶端從服務器接收到響應。如果響應中包含了所需的HTTP響應，客戶端將對數(shù)據(jù)進行處理。如果服務器要求客戶端重試，客戶端將使用TCP作為傳輸層重試。
如果服務器沒有處理通過UDP傳輸?shù)腍TTP包，客戶端就會收到ICMP錯誤消息（目的地址無法到達/協(xié)議無法到達）。此時客戶端將會使用TCP重試。
如果定時器超時，客戶端應使用TCP重試。
圖4給出了在定時器超時情況下，客戶端和服務器之間數(shù)據(jù)包的交換。這種超時機制提供了可靠性，以及與未使用混合TCP-UDP方法的服務器的兼容性。
圖5示意了服務器要求客戶端使用TCP重發(fā)請求時，客戶端和服務器之間的數(shù)據(jù)包交換。
3 結 語
混合TCP-UDP方法改善了參與HTTP傳輸?shù)娜齻€方面：客戶端、服務器和網(wǎng)絡。
對于客戶端而言，可以避免由于TCP而引入的三向握手的時間，從而減少了瀏覽的延遲時間。
對于服務器而言，由于所需的TCP的鏈接數(shù)量減少，從而降低了由于建立、維護、撤銷TCP鏈接所帶來的服務器的負荷。
udp協(xié)議范文第6篇
關鍵詞:通信網(wǎng)絡;基于樣本塊的方法;UDP協(xié)議;Mean-Shift方法
中圖分類號:TP311文獻標識碼:A文章編號:1009-3044(2010)21-5714-02
通信網(wǎng)絡為計算機信息的獲取、傳輸、處理、利用和共享提供一個安全可靠的環(huán)境和傳輸通道,但現(xiàn)實中通信網(wǎng)絡并非是絕對安全的,傳輸數(shù)據(jù)過程中數(shù)據(jù)包的丟失、泄密和篡改時有發(fā)生,且日趨嚴重。
目前在通信網(wǎng)絡中比較常用的兩個通信協(xié)議是TCP協(xié)議和UDP協(xié)議。TCP是一種面向連接的協(xié)議,采用“三次握手”方式來確保數(shù)據(jù)的準確接收,其工作機制是首先是建立連接;其次發(fā)送端發(fā)送數(shù)據(jù),接收端接收數(shù)據(jù);再次接收端向發(fā)送端發(fā)送反饋信息,如果發(fā)送數(shù)據(jù)被成功接收,則斷開連接,否則必須重傳發(fā)送失敗的數(shù)據(jù)。而UDP協(xié)議是一種無連接的協(xié)議,不提供可靠的信息發(fā)送機制,因此在數(shù)據(jù)傳輸過程當中更容易出現(xiàn)數(shù)據(jù)包的丟失現(xiàn)象。
TCP協(xié)議雖說提供安全的數(shù)據(jù)傳輸,但是傳輸效率不高,因此不適合于實時性較高的應用。UDP協(xié)議雖說不提供安全的數(shù)據(jù)傳輸,但是其傳輸效率很高,能實現(xiàn)實時傳輸,但是容易出現(xiàn)丟失數(shù)據(jù)包的問題。在實際當中很多實時性很高的珍貴數(shù)據(jù)是不容有失的,那么如何解決這一問題呢?
在2003年Shantanu D.Rane等提出無線電傳輸中丟失數(shù)據(jù)復原的問題,他們結合現(xiàn)有的圖像修復技術和紋理合成技術對傳輸過程中丟失的數(shù)據(jù)進行填充。在傳輸過程中,圖像被劃分為 的塊,計算其離散余弦變換,然后量化并進行哈弗曼編碼,最后傳輸圖像數(shù)據(jù)[1]。該文獻中對丟失數(shù)據(jù)填充過程如下:對丟失的塊分類,根據(jù)周圍的塊判斷丟失塊是紋理塊還是結構塊,如果是紋理塊使用紋理合成算法,否則使用結構修復算法。分析發(fā)現(xiàn)該方法對于塊的分類不夠準確,而且丟失數(shù)據(jù)的填充比較耗時。
本文針對上述缺陷直接使用基于樣本塊的方法[3]填充UDP協(xié)議丟包數(shù)據(jù)。在目前所有的圖像修復方法中,基于樣本塊的修復方法是非常有效用的一種,它不僅能夠填充圖像紋理部分,而且能夠修復圖像簡單的結構,對結構的修復主要是受修復的優(yōu)先權和樣本塊的大小控制,適合的修復順序和樣本塊大小是有利于圖像結構的保持。因此本文直接使用基于樣本塊的方法對丟失的圖像數(shù)據(jù)進行填充,這樣不僅能夠提高填充的效率,而且能夠減輕數(shù)據(jù)包的丟失造成嚴重損失。
1 基于樣本塊的丟失圖像數(shù)據(jù)填充
UDP協(xié)議的數(shù)據(jù)傳輸過程與無線電數(shù)據(jù)的傳輸是相似的,其優(yōu)點是傳輸過程中的部分數(shù)據(jù)丟失不會引起整個圖像數(shù)據(jù)的混亂,這就為數(shù)據(jù)的恢復提供了一定的可能,否則數(shù)據(jù)的恢復是非常困難的。在很多文獻中提到UDP協(xié)議的丟包率與具體網(wǎng)絡環(huán)境有關,沒有一個準確的數(shù)值,但是一般來說其平均丟包率總會小于無線電數(shù)據(jù)的丟包率3.6%[2]。
基于樣本塊的方法一種非常有效的丟失圖像數(shù)據(jù)的填充方法,它不僅能填充大塊的紋理破損,而且能夠修復較小的結構破損。UDP協(xié)議的丟包率一般來說很小,這也就為圖像的結構部分的復原提供了重要的保障?；跇颖緣K的圖像修復過程如下:
1) 確定丟失數(shù)據(jù)包的位置,因為圖像數(shù)據(jù)是經(jīng)過編碼后傳輸?shù)?因此即使丟包也不會使得整個圖像數(shù)據(jù)混亂,自然其丟失數(shù)據(jù)的位置容易確定;
2) 尋找破損區(qū)域的邊緣;
3) 按照優(yōu)先權計算方法確定當前優(yōu)先權最高的像素點,優(yōu)先權P(p)一般為信任度因子C(p)與數(shù)據(jù)因子D(p)的積。信任度因子和數(shù)據(jù)因子的計算如式(1)和式(2):
(1)
(2)
信任度因子確保了當前待修復塊上有更多的已知像素點來確保找到的最佳匹配塊的準確性,而數(shù)據(jù)因子表示破損區(qū)域邊界在優(yōu)先權最高像素點處的法線與該點處等照線的夾角,夾角越大則結構越強,否則結構越弱,結構越強的自然越先修復,這樣有利于圖像邊緣的保持;
4) 根據(jù)相似度的度量機制,尋找最佳匹配塊;
5) 將最佳匹配塊中的數(shù)據(jù)拷貝到當前待修復塊中,注意只拷貝當前塊中破損像素點對應的數(shù)據(jù);
6) 更新破損區(qū)域;
7) 判斷破損像素點的個數(shù)是否為0,如果為0,則轉8),否則返回到2);
8) 修復結束。
基于樣本塊的修復方法雖說有很好的修復效果,但是也必須注意其修復過程中存在的問題。首先誤差的累積問題,這必然導致錯誤的填充結果。其次是最佳匹配塊的選擇問題,如何在多個候選最佳匹配塊中選出真正最佳的匹配塊。
文獻[4]提出一種新的方法來解決這誤差累積的問題,首先使用Mean-Shift方法[5]對圖像進行了粗劃分,對最佳匹配塊的選擇區(qū)域作了限制,具體的最佳匹配塊的選擇原則如下:
1) 如果待修復塊屬于粗劃分Ti,則最佳匹配塊僅在Ti中選擇;
2) 如果待修復塊處于多個劃分Ti∪Ti+1∪...∪Ti+k的邊緣,則最佳匹配塊在Ti∪Ti+1∪...∪Ti+k中選擇。
上述方法相當于給匹配塊的選擇加了一些約束,使選擇范圍縮小。這樣不僅縮短了尋找匹配塊的時間,也避免了誤差的累積。
另外一個問題就是最佳匹配塊唯一的問題。假設目前找到的匹配塊為ψp1, ψp2,…ψpk,那么如何在這之中選擇一個真正的最佳匹配塊。文獻[6]提到了一種選取最佳匹配塊的方法,認為與當前待修復塊的空間距離越近,其相關程度越高。因此,通過計算待修復塊的核與匹配塊的核之間的空間距離來最終選定哪個塊是真正的最佳匹配塊。丟失數(shù)據(jù)的填充流程圖如圖1所示。
2 實驗結果
本文用VC++實現(xiàn)了該算法,通過大量的實驗說明了本文算法的有效性。由于傳輸圖像很容易獲得,因此本文采用峰值信噪比的方法對恢復結果進行客觀評價。峰值信噪比PSNR的計算如下式:
(3)
PSNR值越大,恢復的效果越好,越接近原圖;PSNR值越小,恢復效果越差,與原圖差異越大。恢復結果如圖2、圖3、圖4所示。
4 結論
本文分析了通信網(wǎng)絡中UDP協(xié)議的傳輸機制,發(fā)現(xiàn)UDP協(xié)議在傳輸數(shù)據(jù)時容易發(fā)生數(shù)據(jù)丟包問題,由此使用基于樣本塊的方法解決恢復丟失數(shù)據(jù)包的問題。盡管文獻[1]的作者提出了無線傳輸中圖像數(shù)據(jù)的恢復方法,但是該方法比較復雜,而且存在諸多的不穩(wěn)定性,諸如塊的分類等。本文結合基于樣本塊修復的優(yōu)點對丟失數(shù)據(jù)進行恢復,并通過實驗進行了驗證,確實取得了令人滿意的效果。這樣不僅很大程度上提高了UDP協(xié)議圖像數(shù)據(jù)傳輸?shù)陌踩?也提高了UDP協(xié)議的傳輸效率。
參考文獻:
[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] 盧小寶,王維蘭.基于樣本塊的唐卡圖像修復算法的改進[J].計算機應用.2010,30(4):943-946,2010.
udp協(xié)議范文第7篇
關鍵詞：UDP協(xié)議；Socket；網(wǎng)絡通信
中圖分類號：TP393文獻標識碼：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)絡環(huán)境中的進程間通信，它已成為當前許多操作系統(tǒng)的網(wǎng)絡API，也是網(wǎng)絡操作系統(tǒng)中必不可少的基礎功能。隨著Linux操作系統(tǒng)和Internet的不斷發(fā)展，Linux網(wǎng)絡環(huán)境下尤其是基于UDP的socket通信技術仍廣為注目。文章介紹了socket的編程原理，并通過一個Java編寫的客戶/服務器程序，描述了網(wǎng)絡中基于UDP的不同主機上的兩個進程之間的socket通信機制。
1 Socket通信機制
Socket（套接字）機制是一種API，是網(wǎng)絡應用程序的編程接口。Socket是通過標準文件描述符和其它程序通訊的一個方法。每一個套接字都用一個半相關描述：{協(xié)議，本地地址、本地端口}來表示；一個完整的套接字則用一個相關描述：{協(xié)議，本地地址、本地端口、遠程地址、遠程端口}，每一個套接字都有一個本地的由操作系統(tǒng)分配的唯一的套接字號。
根據(jù)傳輸數(shù)據(jù)類型的不同，Socket主要分為三類：1) 流式Socket（SOCK_STREAM），在這種方式下，兩個通訊的應用程序之間要先建立一種虛擬的連接，提供可靠的、面向連接的通信流，它使用TCP協(xié)議，從而保證了數(shù)據(jù)傳輸?shù)恼_性和順序的。2) 數(shù)據(jù)報Socket（SOCK_DGRAM），它使用數(shù)據(jù)報協(xié)議UDP，定義了一種無連接的服務，數(shù)據(jù)通過相互獨立的報文進行傳輸，是無序的，并且不保證可靠、無差錯。3) 原始Socket，原始套接字允許對底層協(xié)議如IP或ICMP直接訪問，它功能強大但使用較為不便，主要用于一些協(xié)議的開發(fā)。
2 UDP協(xié)議的工作原理
UDP協(xié)議是一個面向無連接的協(xié)議，其連接的建立不必像TCP那樣需要服務器端偵聽，也不需要有客戶機請求連接，屬于一種“強制”性的網(wǎng)絡連接。UDP提供一對一或一對多的、無連接的數(shù)據(jù)報服務。該服務對消息中傳輸?shù)臄?shù)據(jù)提供不可靠的、最大努力的傳送，這意味著它不保證數(shù)據(jù)的到達，也不保證所傳送的數(shù)據(jù)報的順序是否正確，UDP不重新傳輸丟失的數(shù)據(jù)。其主要工作是：將應用程序傳輸過來的數(shù)據(jù)分塊交給網(wǎng)絡層，確認接受到分組信息。
盡管UDP無法像TCP一樣提供可靠的數(shù)據(jù)傳輸，但UDP并不比TCP缺乏優(yōu)越性。UDP在傳輸效率方面比TCP要高一些，而且許多應用程序并不需要保證嚴格的傳輸可靠性，比如視頻會議系統(tǒng)等，需要實時的交互，但并不要求音頻視頻的絕對正確。
使用UDP協(xié)議傳輸數(shù)據(jù)時，首先設置客戶計算機的Local Port(本地端口)屬性，而作為服務器的計算機只需要設置Remoter Host(遠程主機)屬性為客戶計算機的IP地址或域名即可，并將其Remote Port屬性設置為客戶計算機上的Local Port屬性。使用UDP端口號時，端口提供了用于發(fā)送消息的位置，每個端口由一個唯一的編號來標識。當應用程序向另一臺計算機發(fā)送數(shù)據(jù)時，UDP生成一個數(shù)據(jù)頭，包括源端口，這些端口提供送達信息所需要的地址。UDP協(xié)議還為數(shù)據(jù)和數(shù)據(jù)頭計算出求和檢驗的值，在目標計算機中，數(shù)據(jù)包被傳遞至UDP協(xié)議程序并送到目的地端口。
3 UDP套接字的通信過程
中提供了兩個類DatagramSocket和DatagramPacket用來支持數(shù)據(jù)報通信。DatagramSoc ket用來在程序之間建立傳送數(shù)據(jù)報的通信連接，是數(shù)據(jù)報通信中的Socket。在數(shù)據(jù)報實現(xiàn)C/S通信程序時，無論在客戶端還是服務器端，都要首先建立一個DatagramSocket對象，用來表示數(shù)據(jù)報通信的端點，應用程序通過Socket接收或發(fā)送數(shù)據(jù)報。
DatagramPacket則用來表示一個數(shù)據(jù)報，它是傳輸數(shù)據(jù)的載體，封裝了數(shù)據(jù)、數(shù)據(jù)長度、數(shù)據(jù)報地址等信息。
采用UDP套接字方式實現(xiàn)C/S的通信程序由客戶端和服務器端兩部分組成。服務器進程依次按以下步驟進行：1) 調用Socket()創(chuàng)建一個數(shù)據(jù)報套接字；2) 調用bind()把服務器地址綁定在該套接字上；3) 調用recvform()等待客戶進程發(fā)來的請求，服務器此時處于無限循環(huán)狀態(tài)；4) 服務進程接收到客戶進程所發(fā)來的數(shù)據(jù)報后，進行處理，調用sendto()將處理結果返回給客戶進程，返回狀態(tài)3)，繼續(xù)監(jiān)聽；5)服務進程調用close()撤消套接字，終止服務。
客戶進程則按以下步驟進行：1) 調用Socket()創(chuàng)建一個數(shù)據(jù)流套接字；2) 調用sendto()向服務器進程發(fā)送數(shù)據(jù)報；3) 調用recvfrom()等待服務器進程返回該處理結果；4) 客戶進程調用close()撤消套接字。
4 數(shù)據(jù)報通信實例
程序由服務器端和客戶端兩部分組成，服務器端主機中有一個名為“udp_socket.txt”文件，文件中保存了一段英文。服務器端接收一個客戶端的請求，就從文件中讀取若干個英文字符發(fā)送給客戶端。當文件中所有內容發(fā)送給完畢，服務器端程序將退出?？蛻舳耸紫葮嬙煲粋€數(shù)據(jù)報發(fā)送給服務器端，然后等待接受服務器端響應，當接收到服務器端的數(shù)據(jù)報后，顯示數(shù)據(jù)并結束通信。
1) 服務器端程序
public class Server_Th
{ boolean m_q=true;
public void serverWork() throea IOException
{DatagramSocket ds=new DatagramSocket(2000)
//創(chuàng)建端口號為2000的數(shù)據(jù)報套接字
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ù)報對象
ds.receive(packet);//接收數(shù)據(jù)報
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 );
//構造要發(fā)送數(shù)據(jù)報
ds.send(packet);//發(fā)送數(shù)據(jù)報
}
ds.close();//關閉
}
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”);
//服務器IP地址
DatagramPacket packet=new DatagramPacket(buf,buf. Length,address,2000);//創(chuàng)建要發(fā)送的數(shù)據(jù)報對象
socket.send(packet);//接收數(shù)據(jù)報
packet=new DatagramPacket(buf,buf.length);
//創(chuàng)建要接收的數(shù)據(jù)報對象
socket.receive(packet);//接收數(shù)據(jù)報
String received=new String(packet.getData());
System.out.println(“The string form the server: ”+recerived);
//取得數(shù)據(jù)報中的數(shù)據(jù)并顯示
Socket.close();//關閉socket
}}
編寫程序時客戶端和服務器端的DatagramSocket必須用一個端口，因為客戶端向服務器端請求時，服務器需要知道從哪個端口監(jiān)聽請求。當數(shù)據(jù)進行傳輸時，服務器從接收到的數(shù)據(jù)報中得到客戶端的接收數(shù)據(jù)的端口，然后將數(shù)據(jù)報發(fā)送到這個端口，客戶端則監(jiān)聽這個端口而得到服務器端發(fā)送過來的數(shù)據(jù)報并顯示其內容。運行時要先運行服務器端程序，再運行客戶端程序。
5 小結
Socket在網(wǎng)絡編程方面發(fā)揮著很大的作用。UDP是可靠性無法得到保障的協(xié)議，但對于質量要求不是很高的網(wǎng)絡應用程序，UDP是一個很好的選擇。
參考文獻：
[1] 張桂珠.Java面向對象程序設計[M].北京:郵電出版社,2006.
[2] 周坤,傅德勝.基于Windows Socket的網(wǎng)絡數(shù)據(jù)傳輸及其安全[J].計算機工程與設計,2007,28(22):5381-5386.
[3] 趙文清.淺析用Socket的Java語言網(wǎng)絡通訊機制和程序設計[J].信息技術,2002(7):66-67.
udp協(xié)議范文第8篇
關鍵詞：UDP 協(xié)議 FPGA
中圖分類號：TP393 文獻標識碼：A 文章編號：1007-9416（2016）05-0000-00
傳輸控制協(xié)議/網(wǎng)際協(xié)議（Transmission Control Protocol/ Internet Protocol，TCP/IP）協(xié)議簇是Internet 和全球各地網(wǎng)絡互聯(lián)的引擎。本文針對網(wǎng)際層IP協(xié)議下的一項功能的實現(xiàn)，主要是針對從UDP協(xié)議下的數(shù)據(jù)包處理的過程。UDP是一個簡單的面向數(shù)據(jù)報的運輸層協(xié)議：進程的每個輸出操作都正好產(chǎn)生一個UDP數(shù)據(jù)報，并組裝成一份待發(fā)送的IP數(shù)據(jù)報。
1數(shù)據(jù)報處理方案
1.1端口設計
端口應該由外部端口和內部端口組成。外部端口是控制硬件（以FPGA為例），主要包括時鐘輸入信號和復位輸入信號。內部端口為運輸層與網(wǎng)絡層相互聯(lián)系為原則設計的，不僅需要數(shù)據(jù)輸入輸出，也需要這兩個模塊間的相互控制。具體內部端口主要包括數(shù)據(jù)輸入輸出信號及對應的數(shù)據(jù)同步信號，兩個準備信號，兩個IP地址輸入信號和輸入同步信號的結束信號。信號描述如下：
時鐘信號（clk）、復位信號（res）、UDP準備信號（udprd）、輸入數(shù)據(jù)信號（isd）：、輸入數(shù)據(jù)同步信號（iss）、輸入數(shù)據(jù)結束信號（ise）、源IP地址（sipa）：、目的IP地址（dipa）、IP準備信號（iprd）、輸出數(shù)據(jù)信號（osd）、輸出數(shù)據(jù)同步信號（oss）。
具體端口設置如圖1：
1.2 功能模塊
1.2.1 建立連接模塊
運輸層和網(wǎng)絡層之間有很多協(xié)議，不同協(xié)議對應不同數(shù)據(jù)包，如何選擇合適通路選擇特定數(shù)據(jù)包，這就要求有特定的連接過程完成特定的數(shù)據(jù)傳輸。
為了建立UDP協(xié)議數(shù)據(jù)和IP數(shù)據(jù)之間的相互通信，在方案中，選擇增添一個建立連接模塊，目的是完成兩個功能。首先是完成UDP協(xié)議下的數(shù)據(jù)在特定通道內向網(wǎng)絡層的傳輸，其次是產(chǎn)生控制信號，控制下一模塊工作狀態(tài)。在此過程中，主要涉及到兩個信號，其一是udprd信號，是建立連接第一步，這個信號旨在反映UDP數(shù)據(jù)報已經(jīng)準備好發(fā)送；其二是iprd信號，建立連接第二步，本信號是為了給運輸層的UDP協(xié)議的反饋信號，如果接到收此信號，UDP數(shù)據(jù)報就開始發(fā)送了。本信號還有一個功能：當網(wǎng)絡層對數(shù)據(jù)處理時，此信號會自動變低電平，將不會接收UDP數(shù)據(jù)報，直到在網(wǎng)絡層的數(shù)據(jù)處理完畢。
1.2.2 數(shù)據(jù)接收存儲模塊
在此模塊下，可分為數(shù)據(jù)接收部分和數(shù)據(jù)的存儲部分。
首先介紹一下數(shù)據(jù)的接收部分，當大量的數(shù)據(jù)報準備進入網(wǎng)絡層時，有些數(shù)據(jù)是沒有意義的，所以要準確有效的接收來自UDP協(xié)議下的數(shù)據(jù)報，需要在這一部分完成此功能。在端口的設置，增加了同步接收信號和終止信號，當同步信號有效，數(shù)據(jù)為有效數(shù)據(jù)，當終止信號有效，則一個完整的UDP數(shù)據(jù)包就發(fā)送完成了。
當大量的UDP數(shù)據(jù)包進入到IP協(xié)議下準備處理，而處理速度是遠遠小于接收的速度，會導致數(shù)據(jù)的滯留，甚至數(shù)據(jù)會丟失。為了解決該問題，增加了一個數(shù)據(jù)存儲模塊，把數(shù)據(jù)存儲下來，彌補了處理速度和接收速度的不匹配。
此模塊還額外的完成了一個功能：計數(shù)功能。在加I P數(shù)據(jù)頭需要每一包UDP數(shù)據(jù)包字節(jié)的長度信息進行存儲。
1.2.3 IP數(shù)據(jù)包頭處理及發(fā)送模塊
每一份的IP數(shù)據(jù)包都是有IP數(shù)據(jù)包頭和對應的UDP數(shù)據(jù)包組合成的。需要將其對應封裝。
當IP數(shù)據(jù)包頭處理完成了，緊接任務就是將其發(fā)送出去。在發(fā)送完IP數(shù)據(jù)包頭緊跟要發(fā)送其對應的UDP數(shù)據(jù)包，這就是一個完整的IP數(shù)據(jù)包。如果輸出同步信號有效，這些處理好的數(shù)據(jù)將發(fā)送到數(shù)據(jù)鏈路層供其使用。
2方案綜述
（1）運輸層和網(wǎng)絡層之間建立連接，保證數(shù)據(jù)準確無誤差的傳輸?shù)骄W(wǎng)絡層，產(chǎn)生控制信號，控制數(shù)據(jù)的接收；產(chǎn)生反饋信號，保證運輸層的UDP數(shù)據(jù)包適時的傳送過來。（2）讀取UDP數(shù)據(jù)包并準確的計數(shù)，將已讀的數(shù)據(jù)存入緩存中，產(chǎn)生信號，控制IP頭處理模塊的啟動，然后將必要數(shù)據(jù)傳遞到IP頭處理模塊。（3）處理數(shù)據(jù)，將對應的一包UDP數(shù)據(jù)產(chǎn)生相應的IP數(shù)據(jù)包頭，形成一個IP數(shù)據(jù)包。然后將包頭發(fā)送，產(chǎn)生輸出的同步信號，之后產(chǎn)生信號讀取緩存中的數(shù)據(jù)，通過輸出端口將其發(fā)送出去。
這就是一個UDP數(shù)據(jù)包的處理過程，不斷反復以上步驟，UDP數(shù)據(jù)段就轉變成了IP數(shù)據(jù)段。
本方案增加了同步數(shù)據(jù)的輸出信號，這就可以自由的控制輸入輸出數(shù)據(jù)，不會導致數(shù)據(jù)的意外丟失。而這些信號還可以支持數(shù)據(jù)間斷輸入，給運輸層數(shù)據(jù)傳輸很大的靈活性；還增加了udp和iprd信號，它們完成這兩個層連接，給數(shù)據(jù)傳輸提供良好的初始條件。
參考文獻
[1]TCP-IP詳解（中文）.pdf.
[2]張帆.《基于FPGA的IP協(xié)議處理器》.湖南大學碩士論文.
udp協(xié)議范文第9篇
關鍵詞：可靠UDP；確認重傳；滑動窗口
中圖分類號：TP311 文獻標識碼：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è)務不同，在數(shù)據(jù)傳輸?shù)乃俣群涂煽啃灾g不能達到很好的平衡。車險理賠系統(tǒng)中采用的是移動理賠的思想，手持終端機通過移動通信網(wǎng)絡和后臺中心系統(tǒng)進行數(shù)據(jù)交互。目前國內的通信事業(yè)并不是很發(fā)達，信號覆蓋率并不全面，移動通信網(wǎng)絡的帶寬和傳輸質量會受到地域的影響，為確保理賠現(xiàn)場與后臺系統(tǒng)間數(shù)據(jù)的及時可靠傳輸，需要基于移動通信的網(wǎng)絡環(huán)境設計高效可靠的數(shù)據(jù)傳輸功能。本章在UDP傳輸協(xié)議基礎上，通過應用層封裝和可靠性設計的方法，采用數(shù)據(jù)包的確認重傳、流量控制等機制，設計并實現(xiàn)基于UDP協(xié)議的可靠數(shù)據(jù)傳輸功能。
1 TCP與UDP的對比
TCP和UDP都屬于傳輸層協(xié)議，負責承擔數(shù)據(jù)傳輸?shù)娜蝿誟1]。兩者之間的主要區(qū)別有：
（1） TCP和UDP是傳輸層的兩個協(xié)議，它們最大的區(qū)別是是否面向連接。TCP，在客戶端和服務器端進行通信之前，首先要交換傳輸層控制信息，為雙方的通信做好準備。UDP是一個非連接的協(xié)議，傳輸數(shù)據(jù)之前雙方不建立連接，當傳送數(shù)據(jù)時，簡單的抓取來自應用程序的數(shù)據(jù)，并盡可能快的把數(shù)據(jù)傳送到網(wǎng)絡上。
（2） UDP協(xié)議的數(shù)據(jù)傳輸不需要維護收發(fā)狀態(tài)和連接狀態(tài)等，與TCP相比，網(wǎng)絡有效利用率得到很大的提高。
（3） TCP協(xié)議提供數(shù)據(jù)確認重傳、擁塞控制等可靠性保證，UDP協(xié)議不提供可靠性保證，也不提供流量控制。
TCP協(xié)議由于需要確認的狀態(tài)和對數(shù)據(jù)包的操作過多，數(shù)據(jù)傳輸?shù)乃俣炔桓咔揖W(wǎng)絡延遲較大，所以雖然協(xié)議可靠但并不適合面向移動通信的數(shù)據(jù)傳輸；而UDP協(xié)議由于不用建立連接，沒有超時重發(fā)等可靠機制，網(wǎng)絡延遲小且數(shù)據(jù)傳輸速度很快。本文設計的理賠系統(tǒng)面向移動通信網(wǎng)絡實現(xiàn)理賠現(xiàn)場與后臺系統(tǒng)間的數(shù)據(jù)傳輸，網(wǎng)絡環(huán)境不如光纖接入網(wǎng)絡穩(wěn)定可靠，對數(shù)據(jù)的高效可靠傳輸有著很高的要求。因此，本章選用UDP協(xié)議，并在其基礎上，設計了連接確認、數(shù)據(jù)確認等可靠機制，滿足了系統(tǒng)對于高效可靠傳輸功能的需求。
2基于UDP 改進的可靠傳輸協(xié)議實現(xiàn)
2.1 主要功能模塊及任務結構
綜合文獻【2】的可靠機制描述，可靠UDP數(shù)據(jù)傳輸協(xié)議的模塊結構如圖1所示。
從模塊結構上看，本模塊主要由以下幾個任務實現(xiàn)模塊功能：
? 通信處理模塊
1） 發(fā)送方發(fā)起數(shù)據(jù)傳輸請求，三次握手成功后，發(fā)送方進入數(shù)據(jù)包封裝模塊。
2） 超時定時器的啟動和關閉。
3） 當數(shù)據(jù)傳輸結束時，接收方向發(fā)送方主動發(fā)起傳輸結束的請求。
? 數(shù)據(jù)包封裝/解析模塊
1） 發(fā)送方將要發(fā)送的的數(shù)據(jù)按照協(xié)商大小分塊，排序。
2） 發(fā)送方將分塊的數(shù)據(jù)協(xié)商的數(shù)據(jù)報文結構封裝成要發(fā)送的消息包。
3） 接收方讀取數(shù)據(jù)包后根據(jù)協(xié)商的數(shù)據(jù)報文結構拆分數(shù)據(jù)包，根據(jù)數(shù)據(jù)包的類型讀取信息。
? 消息發(fā)送/接收模塊
1） 發(fā)送方判斷發(fā)送隊列和消息隊列是否為空后，將要發(fā)送的數(shù)據(jù)包處理后發(fā)送。
2） 接收方從接收隊列中讀取數(shù)據(jù)包。
? 數(shù)據(jù)重組模塊
1） 由于網(wǎng)絡問題，發(fā)送方按序發(fā)送的數(shù)據(jù)包不一定會按序到達，所以接收方在經(jīng)過數(shù)據(jù)包解析模塊讀取數(shù)據(jù)后，根據(jù)該消息的字節(jié)序號判斷是否為亂序的分組。
2） 若是順序的分組，將分組與以前收到的消息按序排列；若是要求重傳的分組，將該分組放入到所應在的位置中。
3） 如果滿足重發(fā)條件，則向發(fā)送方發(fā)送重發(fā)包請求。
2.2 核心事件處理流程
2.2.1 通信處理進程
通信處理模塊中的通信處理進程主要負責三次握手的發(fā)起和確認的請求，數(shù)據(jù)傳輸結束后結束連接等任務。具體流程見圖2。首先，通信的接收方發(fā)起握手的請求，即建立一個虛連接，雙方必須確保該連接成功建立后才可以進行下一步數(shù)據(jù)傳輸?shù)牟僮?。然后，在接收方一端啟動定時器，接收方的數(shù)據(jù)處理進程接收發(fā)送方發(fā)送的數(shù)據(jù)，同時接收方根據(jù)定時計時器發(fā)送反饋消息；或判斷接收到的報文數(shù)，當達到數(shù)據(jù)包累積計數(shù)器設定的數(shù)值時，向發(fā)送方發(fā)送反饋消息。
2.2.2 發(fā)送方發(fā)送報文
數(shù)據(jù)報文的發(fā)送，主要是發(fā)送方向接收方發(fā)送數(shù)據(jù)報文和消息報文，流程如圖3所示，具體的算法為：
if（發(fā)送隊列非空）
{
從隊列中取出消息；
if （消息類型為數(shù)據(jù)包）
發(fā)送數(shù)據(jù)包；
else 發(fā)送確認包；
}
else if （消息隊列非空）
{
打包要發(fā)送的數(shù)據(jù)并將數(shù)據(jù)放入發(fā)送隊列中；
套接口處當前序號加1；
}
3 實驗結果與分析
3.1 開發(fā)環(huán)境
系統(tǒng)的編程實現(xiàn)是在Windows XP上進行的，使用的編程工具為Visual C++6.0。
3.2 系統(tǒng)測試
3.2.1 測試環(huán)境
本測試是是在無線通信網(wǎng)絡下進行的，配置了兩臺計算機用作數(shù)據(jù)間收發(fā)的測試，操作系統(tǒng)為Windows XP。華為E261 3G上網(wǎng)卡兩張，用于連接無線網(wǎng)絡，測試拓撲結構如圖4所示。
3.2.2 測試內容
本測試采用傳輸不同大小文件的方式來對數(shù)據(jù)速度進行測試，每次傳輸重復測試三次，然后取平均值作為參考數(shù)據(jù)，測試結果見表1和表2。其中，表1是在最大連接速率7.2Mbps環(huán)境下的測試結果，表2是在連接速率為2.2Mbps環(huán)境下的測試結果。
由表1可見，在移動通信的網(wǎng)絡連接環(huán)境為7.2Mbps時，當傳輸1MB的數(shù)據(jù)時，TCP協(xié)議測試耗時9.75s，平均傳輸速度約為105KB/s；可靠UDP耗時8.25s，平均傳輸速度約為124KB/s。當傳輸數(shù)據(jù)為32MB時，TCP耗時295.89s，平均傳輸速度約為120KB/s；可靠UDP耗時197.05s平均傳輸速度約為168KB/s。
由表2可見，在移動通信的網(wǎng)絡連接環(huán)境為2.2Mbps時，由于連接環(huán)境較差，測試文件并不大，當傳輸0..36s，平均傳輸速度約為21KB/s；可靠UDP耗時190.81s，平均傳輸速度約為43KB/s。
由此可得出：
（1） 可靠UDP傳輸協(xié)議的優(yōu)勢隨著傳輸數(shù)據(jù)量的增大而越來越明顯。
（2） 可靠UDP傳輸協(xié)議的優(yōu)勢隨著網(wǎng)絡環(huán)境的變差而越來越明顯。
參考文獻：
[1] Douglas er. 用TCP/IP進行網(wǎng)際互聯(lián)――原理、協(xié)議與結構（第五版）[M]. 林瑤， 張娟， 王海，等譯. 北京：電子工業(yè)出版社，2009.
[2] 王玨， 何秋燕， 王露凱.基于UDP 改進的可靠傳輸協(xié)議設計[J].電子世界，2014（22）.
[3] 王繼剛， 顧國昌， 徐立峰，等.可靠UDP數(shù)據(jù)傳輸協(xié)議的研究與設計[J].計算機工程與應用，2006（15）：113-116.
[4] 靳海力.一種增強型可靠UDP的設計及應用[D].合肥：中國科學技術大學，2009.
本文鏈接：http://edgebase.com.cn/v-141-2653.htmludp協(xié)議范文10篇
相關文章：
防火宣傳標語11-09
個性的勵志語錄35條11-03
感謝同事對工作的支持的話07-26
高二班主任工作總結第二學期(十六篇)08-19
保護紅樹林生態(tài)系統(tǒng)國際日活動通知07-20
尋覓春天的蹤跡作文07-23
初二作文：好久不見07-23
高中第二冊第二單元作文：讓我感動的一件事07-23
劉禹錫《秋詞》測試題及答案10-11