udp協(xié)議范文
時間：2023-03-25 02:16:33
導(dǎo)語：如何才能寫好一篇udp協(xié)議，這就需要搜集整理更多的資料和文獻(xiàn)，歡迎閱讀由公務(wù)員之家整理的十篇范文，供你借鑒。
篇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.
篇2
關(guān)鍵詞：arm；linux；交叉編譯環(huán)境；udp協(xié)議；重發(fā)機(jī)制；重發(fā)次數(shù)
中圖分類號：tp393文獻(xiàn)標(biāo)識碼：a文章編號：1009-3044(2011)13-3001-03
the application research of communicating based on arm-linux environment and udp-protocol
cui hao, shao ping-fan
(wuhan university of science and technology, wuhan 430000, china)
abstract: the sender and receiver are relatively independent when communicating under udp- protocol, the sender resending messages to receiver times instead of creating a connection. a resend-mechanism that the key-messages were send by upper computer in fixed times, was used in order to ensuring not to lost key-message. although the resend-mechanism can ensure that the key-message wouldn’t be lose anyway, but abundant of redundancy messages were send through the network device lead to inefficency, obviously more resend-times more inefficency. so, how to determine the resend-times become the crucial to improve the efficiency while ensuring the messages were send accurately. a method of determining the resend-times will be given as following.
key words: arm; linux; crossing compile evironment; udp-protocol; resend mechanism; resend times
udp協(xié)議以其高效性和應(yīng)用的簡單，被廣泛運(yùn)用于嵌入式網(wǎng)絡(luò)開發(fā)中。由于udp協(xié)議的應(yīng)用簡單，在嵌入式設(shè)備開發(fā)過程中，網(wǎng)絡(luò)資源的利用率并不高。以下將介紹一個udp具體項(xiàng)目實(shí)驗(yàn)過程，描述arm-linux環(huán)境的軟硬件環(huán)境構(gòu)建過程，并對udp協(xié)議下一種重發(fā)模式中上位機(jī)的重發(fā)次數(shù)的確定提出一種可行的方法。
1 研究背景
隨著嵌入式技術(shù)的快速發(fā)展，嵌入式設(shè)備已經(jīng)在許多領(lǐng)域取代了傳統(tǒng)的微型機(jī)設(shè)備。本文的選題主要來自于實(shí)習(xí)期間承接的一項(xiàng)改造項(xiàng)目：某院校特長生評分系統(tǒng)的改造。項(xiàng)目改造目的有：1) 保留原上位機(jī)。2) 改用手持式客戶端進(jìn)行顯示及評分操作。3)保留原有網(wǎng)絡(luò)設(shè)備。針對要求，我們使用s3c2440作為硬件平臺，移植linux操作系統(tǒng)，并在arm-linux環(huán)境下研究了udp協(xié)議的通信過程，進(jìn)行了上位機(jī)與嵌入式系統(tǒng)的udp協(xié)議通信實(shí)驗(yàn)及分析，并給出一種重發(fā)機(jī)制中的發(fā)送次數(shù)求法。
2 硬件平臺介紹
s3c2440處理速度達(dá)到了400mhz，具有較高的性價比。為了提高開發(fā)效率，我們采用公司自行研制開發(fā)的et-s3c2440開發(fā)板。
2.1 et-s3c2440開發(fā)板簡介
et-s3c2440是公司自行開發(fā)的一款arm9架構(gòu)的實(shí)驗(yàn)開發(fā)板，其結(jié)構(gòu)框圖如圖1。
核心板的主要器件有：32mb×2片sdram，64mb norflash，512mb nandflash。設(shè)計(jì)了啟動方式可選，通過開關(guān)選擇從nandflash或norflash啟動。
2.2 實(shí)驗(yàn)相關(guān)電路說明
底板電路主要功能是輸入輸出以及網(wǎng)絡(luò)通訊功能。按鍵輸入部分采用掃描方式獲得輸入，用一個單向地址鎖存器和一個雙向地址鎖存器與地址總線相連，可以通過掃描地址來獲得按鍵輸入。lcd采用三星的3.5寸tft屏作為顯示輸出設(shè)備。網(wǎng)卡芯片選用的是與原設(shè)備匹配的10m 的cs8900a，關(guān)于cs8900a與s3c2440的硬件連接，有眾多資源可供參考，本文不再贅述。
3 系統(tǒng)軟件平臺的構(gòu)建
硬件平臺搭建完畢后要將操作系統(tǒng)和應(yīng)用程序在硬件平臺上運(yùn)行起來。以下是對嵌入式linux操作系統(tǒng)移植的過程。
3.1 交叉編譯環(huán)境的構(gòu)建
linux 2.6.29.1版本的內(nèi)核可以登錄到kernel.org下載。本文選擇的是arm-linux-gcc-4.3.2工具鏈(ftp://ftp.arm.linux.org.uk/pub/armlinux/toolchain)
在宿主機(jī)上進(jìn)入linux系統(tǒng)，切換當(dāng)前目錄到工具鏈所在目錄，新建一個arm目錄保存解壓后的文件(mkdir /user/local/arm)并將arm-linux-gcc-4.3.2解壓到這個目錄中(tar jxvf arm-linux-gcc-4.3.2 –c /user/local/arm)。然后將環(huán)境變量$path修改一下，讓$path中包含有arm-linux-gcc所在的目錄(編輯/etc/profile 添加語句”export path=/user/local/arm/4.3.2/bin:$path”)，然后reboot一下，這樣交叉編譯環(huán)境就構(gòu)建好了。
3.2 bootloader的移植
vivi是一款相當(dāng)成熟和相對簡單的常用bootloader，我們以vivi為移植原型，將s3c2440所有io端口寄存器定義添加到頭文件2440add.inc，刪除部分硬件平臺使用不到的代碼，最后將修改過的vivi制作成鏡像燒錄到flash中。[1]
3.3 linux內(nèi)核移植
獲取linux-2.6.29.1源代碼并解壓后，首先修改內(nèi)核源代碼所在目錄中的makefile，將系統(tǒng)架構(gòu)修改為arm(arch ?=arm ),交叉編譯工具修改為arm-linux-gcc (cross_compile ?=arm-linux-)，修改輸入時鐘(arch/arm/mach-s3c2440/mach-smdk2440.c中的函數(shù)static void __init smdk2440_map_io中，修改s3c24xx_init_clocks(12000000)此處所用晶振為12m)。修改machine名稱(在arch/arm/mach-s3c2440/mach-smdk2440.c文件中的函數(shù)machine_start( ),修改為machine_start(s3c2440, “自定義機(jī)器名”)，修改nandflash分區(qū)信息(arch/arm/plat-s3c24xx/common-smdk.c結(jié)構(gòu)體static struct mtd_partition smdk_default_nand_part[]中保存的是nandflah的分區(qū)信息，將其修改為當(dāng)前使用的分區(qū)信息),然后修改nandflash的匹配時間(3c2410_platform_nand_smdk_nand_info smdk_nand_info ={})。
上述內(nèi)核源代碼修改完成后，還需要對一些設(shè)備的驅(qū)動進(jìn)行修改。本文使用的nec 3.5寸 320×240液晶屏，硬件平臺使用gpg4腳進(jìn)行背光控制，需要修改lcd背光(/arch/arm/mach-s3c2440/mach-smdk2440.c中static void __init smdk2440_machine_init(void)，將函數(shù)中的gpio口配置為gpg4)。關(guān)于cs8900a網(wǎng)卡的驅(qū)動移植，相關(guān)資源很豐富，本文也不再贅述。
本實(shí)驗(yàn)中nandflash采用的是yaffs2文件系統(tǒng)，所以打yaffs2文件系統(tǒng)補(bǔ)丁，壓縮包為cvs-root.tar.gz。
至此，linux的內(nèi)核源代碼修改工作完成了，下面還需要利用makefile,進(jìn)行內(nèi)核配置。
在linux 2.6.29.1內(nèi)核目錄下首先make s3c2410_defconfig使用2410的配置模板來配置2440；然后make menuconfig,這時我們可以在圖形化界面中，空格鍵可改變各個配置選項(xiàng)的被選中狀態(tài)，根據(jù)需要進(jìn)行配置即可。配置完成后保存好配置，最后進(jìn)行內(nèi)核的編譯(make dep 建立文件間依賴 make clean 清除編譯殘留文件make zimage 生成內(nèi)核壓縮鏡像文件)。
編譯過程完成后會在內(nèi)核目錄arch/arm/boot/下生成zimage內(nèi)核映像文件，將這個鏡像文件燒錄到flash中，調(diào)試檢驗(yàn)，經(jīng)上述修改后的內(nèi)核工作運(yùn)行正常。
3.4 根文件系統(tǒng)的制作
根文件系統(tǒng)是使用busybox-1.13.3來制作完成。下載busybox并解壓完成后，修改makefile中的架構(gòu)為arm架構(gòu)，編譯工具為arm-linux-gcc( arch ?=arm； cross_compile ?=arm-linux-),然后make menuconfig,通過圖形界面對busybox進(jìn)行配置，然后對busybox進(jìn)行編譯(make config_prefix=/opt/studyarm/rootfs install)，在目標(biāo)目錄下會生成目錄bin、sbin、usr和文件linuxrc的內(nèi)容。
基本目錄結(jié)構(gòu)生成后，應(yīng)該在目標(biāo)目錄下建立一些未生成的必要的系統(tǒng)目錄如dev、etc、lib等，并通過chmod命令改變目錄權(quán)限為可寫。再將一些必要的動態(tài)鏈接庫和靜態(tài)庫拷貝到lib下，然后在dev目錄下創(chuàng)建設(shè)備節(jié)點(diǎn)，最后創(chuàng)建該嵌入式linux系統(tǒng)的初始化配置文件(包括設(shè)備列表文件、口令、網(wǎng)絡(luò)分組組名、hostname主機(jī)名、etc/inittab初始化表單、etc/profile環(huán)境變量配置文件、用于系統(tǒng)初始化的.bash腳本文件等)。[2]由于本實(shí)驗(yàn)需對網(wǎng)絡(luò)編程，要求自動初始化cs8900a網(wǎng)卡芯片的ip地址、網(wǎng)關(guān)、子網(wǎng)掩碼等，所以在開機(jī)自啟動腳本中加入ifconfig語句，使得開機(jī)時自動配置網(wǎng)卡參數(shù)。
根文件系統(tǒng)構(gòu)建完成后，使用yaffs2文件系統(tǒng)制作工具mkyaffs2image.tgz，通過命令mkyaffs2image rootfs rootfs.img生成根文件系統(tǒng)鏡像，然后將鏡像燒寫入flash中。
4 arm-linux環(huán)境下的udp協(xié)議通信實(shí)驗(yàn)
經(jīng)過上述硬件設(shè)計(jì)和操作系統(tǒng)移植過程，本文所使用到的實(shí)驗(yàn)環(huán)境已經(jīng)構(gòu)建完畢，經(jīng)反復(fù)調(diào)試修改，嵌入式linux操作系統(tǒng)在平臺下運(yùn)行正常，于是進(jìn)行udp協(xié)議通信實(shí)驗(yàn)。
4.1 udp協(xié)議套接字編程基礎(chǔ)
udp是一個面向數(shù)據(jù)報(bào)和無連接的簡單傳輸層協(xié)議，它不像tcp那樣通過握手過程建立服務(wù)器與客戶端的連接才可以工作。在網(wǎng)絡(luò)通信質(zhì)量較好的情況下，udp體現(xiàn)出高效率，這適合于傳送少量報(bào)文的應(yīng)用。[3] linux系統(tǒng)是通過套接字結(jié)構(gòu)來進(jìn)行網(wǎng)絡(luò)編程的，應(yīng)用程序通過對套接字的幾個函數(shù)調(diào)用，會返回一個用于通信的套接字描述符,而linux應(yīng)用程序在進(jìn)行任何形式的i/o操作時，程序?qū)嶋H上是在讀寫一個文件描述符。[4]因此linux下的套接字編程，可以看成是對普通文件描述符的操作，這些操作與被使用的硬件平臺無關(guān)，這是linux設(shè)備無關(guān)性的優(yōu)點(diǎn)。udp協(xié)議的通信模型如圖3所示。
在上述流程中，客戶端所收到的報(bào)文被存儲在緩沖區(qū)中，recvfrom()函數(shù)返回了報(bào)文存儲緩沖區(qū)的首地址，我們可以很方便地對這個首地址進(jìn)行數(shù)組操作，從而實(shí)現(xiàn)對報(bào)文的解碼。
4.2 上位機(jī)報(bào)文結(jié)構(gòu)及重發(fā)機(jī)制分析
根據(jù)項(xiàng)目要求，上位機(jī)軟件依然保留，我們使用協(xié)議嗅探工具對上位機(jī)發(fā)送的報(bào)文進(jìn)行了嗅探，得到了上位機(jī)報(bào)文的結(jié)構(gòu)如表1所示。
表1 上位機(jī)報(bào)文結(jié)構(gòu)
上位機(jī)發(fā)出的每條報(bào)文由32個字節(jié)組成，第0位為版本信息。第1……12位為比賽信息和運(yùn)動員教練信息，是報(bào)文的關(guān)鍵信息部分，13……22位為服務(wù)器端和客戶端的ip地址及端口號信息，23位是上位機(jī)對客戶端的操作指令代碼，24位是相關(guān)重發(fā)機(jī)制的代碼，30和31兩位是checksum，用來保證數(shù)據(jù)傳輸?shù)恼_。上位機(jī)采用的重發(fā)機(jī)制是一種上位機(jī)按照固定重發(fā)次數(shù)多次發(fā)送同一關(guān)鍵內(nèi)容報(bào)文的機(jī)制，其第24位重發(fā)機(jī)制位被分為高4位和低4位兩部分，高四位的內(nèi)容是當(dāng)前發(fā)送的報(bào)文的索引號，每次發(fā)送一條新內(nèi)容的報(bào)文時索引號自增1，索引號的取值范圍在0x00—0xff范圍內(nèi)循環(huán)自增。低四位是重發(fā)編號，表示同一索引號的報(bào)文正在被第幾次重發(fā)，固定的重發(fā)次數(shù)由上位機(jī)初始化時設(shè)定。
4.3 嵌入式客戶端的實(shí)驗(yàn)程序設(shè)計(jì)
針對報(bào)文結(jié)構(gòu)，我們對接收端編寫實(shí)驗(yàn)程序代碼，代碼的主要功能是從上位機(jī)接收報(bào)文，將計(jì)算出的checksum校驗(yàn)和與收到的校驗(yàn)和對比判斷報(bào)文是否正確，然后從正確報(bào)文中取出主要信息并按照報(bào)文中的上位機(jī)指令碼進(jìn)行輸出。其結(jié)構(gòu)流程圖如圖3所示。
實(shí)驗(yàn)程序經(jīng)編碼、調(diào)試后在交叉編譯環(huán)境中交叉編譯，生成arm-linux環(huán)境下可執(zhí)行文件，在目標(biāo)板上執(zhí)行。經(jīng)測試試驗(yàn)程序能夠正確接收上位機(jī)發(fā)來的報(bào)文，對報(bào)文解碼，并能根據(jù)上位機(jī)命令對關(guān)鍵信息做輸出處理。
4.4 對上位機(jī)重發(fā)次數(shù)的研究
進(jìn)行udp協(xié)議通信時，發(fā)送端和接收端的狀態(tài)是相對獨(dú)立的，發(fā)送端不與接收端建立連接，而是不停向接收端發(fā)送，為了確保不丟失報(bào)文，上位機(jī)采取了按固定次數(shù)重發(fā)相同內(nèi)容報(bào)文的機(jī)制。然而這種機(jī)制雖然可以有效確保報(bào)文不丟失，但是大量冗余數(shù)據(jù)報(bào)被發(fā)送，網(wǎng)絡(luò)資源利用率不高。重發(fā)次數(shù)越多，冗余數(shù)據(jù)報(bào)越多，效率越低。要想有效保證數(shù)據(jù)報(bào)準(zhǔn)確發(fā)送的同時又不產(chǎn)生過多冗余數(shù)據(jù)報(bào)，那么重復(fù)發(fā)送的次數(shù)的確定就成為問題的關(guān)鍵。以下給出一種確定上位機(jī)重發(fā)次數(shù)的方法。
假設(shè)當(dāng)前網(wǎng)絡(luò)狀況下，每次報(bào)文發(fā)送被丟失的概率為p，系統(tǒng)允許接收端報(bào)文關(guān)鍵內(nèi)容丟失概率為q,那么如何確定以上重發(fā)機(jī)制中的重發(fā)次數(shù)k呢？
特殊情況下若報(bào)文重發(fā)次數(shù)為2，分別在每條報(bào)文重發(fā)機(jī)制位注明一個索引號和一個重發(fā)編號，發(fā)送端發(fā)送報(bào)文的次序應(yīng)形如 1.1 ,1.2 ,2.1 ,2.2 ,3.1 ,3.2……其中索引號相同的報(bào)文關(guān)鍵內(nèi)容相同，重發(fā)編號不同代表同一關(guān)鍵內(nèi)容報(bào)文的不同次發(fā)送。因此只有出現(xiàn)連續(xù)兩次丟失數(shù)據(jù)報(bào)的情況下，報(bào)文關(guān)鍵內(nèi)容才可能丟失。出現(xiàn)連續(xù)兩次丟失的情況有2種，當(dāng)x.1 , x.2丟失，此時索引號為x的報(bào)文關(guān)鍵信息將全部丟失。當(dāng)x.2,(x+1). 1丟失，丟失報(bào)文的索引號不同，此時不會發(fā)生報(bào)文關(guān)鍵信息丟失，因此報(bào)文關(guān)鍵內(nèi)容丟失的概率q=p2/2。
當(dāng)報(bào)文重發(fā)次數(shù)為3,依然在每條報(bào)文的重發(fā)機(jī)制位注明索引號和重發(fā)號，發(fā)送報(bào)文的次序應(yīng)為1.1 ,1.2 ,1.3 ,2.1 ,2.2 ,2.3 ,3.1 ,3.2……。只有出現(xiàn)連續(xù)3次丟失數(shù)據(jù)報(bào)的情況報(bào)文關(guān)鍵信息才可能丟失，列出連續(xù)3次丟失報(bào)文的情況有3種，當(dāng)x.1 , x.2 , x.3丟失，此時索引號為x的報(bào)文信息全部丟失。當(dāng)x.2 , x.3 ,(x+1).1或x.3 ,(x+1).1 ,(x+1).2丟失時不影響報(bào)文的準(zhǔn)確傳遞。因此此時報(bào)文關(guān)鍵內(nèi)容丟失的概率q=p3/3。
推廣至一般情況易得當(dāng)報(bào)文重發(fā)次數(shù)為k時，報(bào)文關(guān)鍵內(nèi)容丟失的概率q=pk/k，移項(xiàng)有kq=pk。于是我們得到求重發(fā)次數(shù)k的方法如下：
1) 根據(jù)網(wǎng)絡(luò)狀況獲得報(bào)文丟失概率p；
2) 根據(jù)客戶需求取得報(bào)文關(guān)鍵內(nèi)容的允許丟失率范圍q；
3) 分別作出y=px和y=qx的圖像；
4) 求得兩圖像的交點(diǎn)的x坐標(biāo)，并將x坐標(biāo)值取整加一即為所求重發(fā)次數(shù)k。
本文實(shí)驗(yàn)中，需求方允許報(bào)文關(guān)鍵信息丟失概率q=0.0001,我們分別對上位機(jī)發(fā)送端和下位機(jī)接收端收發(fā)的報(bào)文進(jìn)行了統(tǒng)計(jì)，在某一固定時間段內(nèi)，上位機(jī)共發(fā)送報(bào)文19665條，接收端接收報(bào)文18636條，傳輸過程中丟失的報(bào)文19665-18636=1029條，當(dāng)前網(wǎng)絡(luò)環(huán)境下的報(bào)文丟失率為，即p=0.0523。據(jù)此數(shù)值分別作出y=0.0001x的曲線和y=0.0523 x的曲線，取得兩曲線交點(diǎn)x坐標(biāo)為x≈2.78，最后將x=2.78取整加1得到k=3，即上位機(jī)對同一數(shù)據(jù)報(bào)的重發(fā)次數(shù)應(yīng)該定為3次就可保證系統(tǒng)丟失報(bào)文的概率低于0.0001。
5 結(jié)論與展望
本文從硬件平臺搭建、linux移植以及udp協(xié)議編程幾個方面介紹了arm-linux環(huán)境下udp協(xié)議通信的具體實(shí)現(xiàn)，并分析了一種在實(shí)際嵌入式項(xiàng)目中常用的上位機(jī)數(shù)據(jù)報(bào)重發(fā)機(jī)制，最后對這種機(jī)制中的重發(fā)次數(shù)的確定方法給出了求解過程，為后續(xù)的具體項(xiàng)目實(shí)施提供了實(shí)踐依據(jù)，也希望為其他應(yīng)用這種重發(fā)機(jī)制的嵌入式產(chǎn)品開發(fā)者們提供了借鑒。
參考文獻(xiàn)：
[1] 李偉.基于arm9的嵌入式linux手持平臺的設(shè)計(jì)與實(shí)現(xiàn)[d].武漢:武漢理工大學(xué)碩士學(xué)位論文,2009.
[2] 范艷開.基于arm的嵌入式linux操作系統(tǒng)移植[d].西安:西北工業(yè)大學(xué),2005.
篇3
0引言
用戶數(shù)據(jù)報(bào)協(xié)議（User Datagram Protocol，UDP）是一種無連接的傳輸層協(xié)議，沒有連接建立和連接終止的握手過程，所以UDP協(xié)議通信效率高，冗余性強(qiáng)，對個別數(shù)據(jù)包丟失不敏感，廣泛應(yīng)用于車輛檢測儀、氣象檢測儀和情報(bào)板等工程類項(xiàng)目中。在高速公路可變情報(bào)板系統(tǒng)中，UDP協(xié)議經(jīng)常在應(yīng)用層面利用后向差錯控制（Backward Error Control，BEC）技術(shù)實(shí)現(xiàn)對數(shù)據(jù)流的調(diào)節(jié)，以避免網(wǎng)絡(luò)的阻塞。接收端采用與發(fā)送端“一次握手”的方式來確保每一個獨(dú)立數(shù)據(jù)包的正確傳輸。如果接收數(shù)據(jù)包正確合法，接收端將回送確認(rèn)信息（ACK）來傳輸下一個數(shù)據(jù)包；否則自動請求重發(fā)（Automatic Repeat reQuest，ARQ），這一機(jī)制稱之為空閑ARQ[1]。
空閑ARQ因技術(shù)簡單而容易實(shí)現(xiàn)。但是，半雙工的通信方式致使其傳輸效率和帶寬利用率很低，在往返時延（RoundTrip Time，RTT）較高的情況下尤為明顯。相比之下，連續(xù)ARQ克服了空閑ARQ停止等待的缺點(diǎn)，它允許發(fā)送端在收到ACK之前連續(xù)發(fā)送多個數(shù)據(jù)包，也允許接收端連續(xù)接收[2]。然而在可變情報(bào)板系統(tǒng)中，負(fù)責(zé)數(shù)據(jù)接收的工控機(jī)配置情況差強(qiáng)人意，與發(fā)送端相去較遠(yuǎn)。一些終端自適應(yīng)協(xié)議（如RBUDP+[3]、RAPID[4]、PAPID+[5]、GTP（Group Transport Protocol）[6]、PAUDP[7]和RTsunami[8]等）已經(jīng)考慮到終端的性能問題，它們根據(jù)終端系統(tǒng)的接受能力實(shí)時調(diào)整發(fā)送速率，從而獲得更好的傳輸性能。這些協(xié)議在eScience等需要海量數(shù)據(jù)傳輸?shù)目蒲袘?yīng)用中效果顯著[9]，而對于工程中廣泛使用的小文件傳輸力不從心，因?yàn)樵趨f(xié)議作出調(diào)整之前文件已經(jīng)傳輸完畢，各種算法無用武之地。為了解決上述提到的諸多問題，本文探討了與終端性能相關(guān)的若干影響因子，并針對終端性能瓶頸提出一種基于UDP的自適應(yīng)傳輸協(xié)議。該協(xié)議無須用戶干預(yù)，可根據(jù)系統(tǒng)當(dāng)前狀態(tài)配置參數(shù)，針對不同大小的文件區(qū)分對待，采取多種措施保證數(shù)據(jù)可靠快速地傳輸。
篇4
【關(guān)鍵詞】可靠UDP;確認(rèn)重傳;滑動窗口
引言
由于傳統(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è)計(jì)
2.1 可靠UDP傳輸協(xié)議的層次結(jié)構(gòu)
本文設(shè)計(jì)的基于UDP改進(jìn)的傳輸協(xié)議的層次結(jié)構(gòu)如圖1所示：
從圖1中可以看出，本文在原來的TCP/IP模型的傳輸層和應(yīng)用層之間添加了一層為保證數(shù)據(jù)可靠傳輸?shù)母倪M(jìn)協(xié)議層。新組成的五層網(wǎng)絡(luò)體系結(jié)構(gòu)中，實(shí)際用來傳輸數(shù)據(jù)的仍然是傳輸層的UDP協(xié)議，新添加的協(xié)議是在UDP傳輸層的基礎(chǔ)上，通過應(yīng)用層對通信雙方進(jìn)行連接確認(rèn)、流量控制等功能，提供一種可靠的數(shù)據(jù)傳輸機(jī)制。改進(jìn)協(xié)議主要提供的功能有：
（1）面向消息包機(jī)制的數(shù)據(jù)接收和發(fā)送功能。改進(jìn)協(xié)議的數(shù)據(jù)傳輸層仍然使用UDP傳輸協(xié)議，本身又添加了可靠機(jī)制，因此可以提供基于消息包的可靠的數(shù)據(jù)傳輸功能。
（2）數(shù)據(jù)重傳功能。發(fā)送方收到接收方發(fā)來的重發(fā)請求，將需要重發(fā)的數(shù)據(jù)包發(fā)出。
（3）丟棄重復(fù)包功能。接收方對收到的重復(fù)消息包，進(jìn)行簡單的丟棄。
（4）流量控制功能。
圖1 協(xié)議層次結(jié)構(gòu)圖
2.2 可靠UDP傳輸協(xié)議報(bào)文結(jié)構(gòu)
可靠UDP傳輸協(xié)議的報(bào)文結(jié)構(gòu)如圖2所示，從圖中可以看出，可靠UDP傳輸協(xié)議的報(bào)文結(jié)構(gòu)就是在UDP報(bào)文的數(shù)據(jù)填充部分添加一些自定義字段與UDP包頭一起構(gòu)成可靠UDP傳輸協(xié)議的包頭，而剩余部分用來填充真實(shí)數(shù)據(jù)。其填充的字段分別為：
MessageType（消息類型）用于識別數(shù)據(jù)包類型，包括數(shù)據(jù)傳輸請求消息、數(shù)據(jù)包發(fā)送消息、數(shù)據(jù)包確認(rèn)消息等，占用兩個字節(jié)空間。
Length（數(shù)據(jù)包總長度）用于標(biāo)識數(shù)據(jù)包類型以及數(shù)據(jù)（Data）總長度，本文設(shè)計(jì)的可靠傳輸協(xié)議約定數(shù)據(jù)包長度最大不超過1436個字節(jié)，所以Length占用兩個字節(jié)空間即可。
MessageNumber （消息傳輸序號）用于標(biāo)識當(dāng)前發(fā)送的數(shù)據(jù)包在整個消息中的位置，占用四個字節(jié)空間。
圖2 改進(jìn)協(xié)議報(bào)文結(jié)構(gòu)
2.3 可靠傳輸內(nèi)部機(jī)制
2.3.1 三次握手機(jī)制
TCP協(xié)議建立連接需要一個3次握手的過程[2]，連接成功后，對連接進(jìn)行維護(hù)直到該連接被銷毀。因此，仿照TCP連接的建立過程，我們在連接開始的時候，模擬TCP協(xié)議的三次握手過程，通過改進(jìn)的可靠UDP協(xié)議也進(jìn)行了一個類似的過程。如圖3所示，該過程分為三個步驟：
第一次握手：建立連接時，網(wǎng)點(diǎn)A發(fā)送一個傳輸請求給網(wǎng)點(diǎn)B，并進(jìn)入等待網(wǎng)點(diǎn)B的確認(rèn)狀態(tài)中。
第二次握手：網(wǎng)點(diǎn)B收到請求后，對該請求進(jìn)行確認(rèn)，發(fā)送一個請求應(yīng)答的報(bào)文給網(wǎng)點(diǎn)A。
第三次握手：網(wǎng)點(diǎn)A收到網(wǎng)點(diǎn)B的請求應(yīng)答后，向網(wǎng)點(diǎn)B發(fā)送確認(rèn)（傳輸應(yīng)答），此確認(rèn)包發(fā)送完畢后，網(wǎng)點(diǎn)A和網(wǎng)點(diǎn)B都進(jìn)入完成狀態(tài)，三次握手成功建立。
圖3 簡單的3次握手
2.3.2 數(shù)據(jù)包確認(rèn)機(jī)制
由于若是僅僅使用基于時間的選擇性確認(rèn)機(jī)制時，當(dāng)傳輸大數(shù)據(jù)時，可能會由于帶寬問題，發(fā)送方A向接收方B發(fā)送大量數(shù)據(jù)包，而在預(yù)定時間間隔超時之前，發(fā)送方A由于待證實(shí)的隊(duì)列得不到證實(shí)而無法繼續(xù)發(fā)送（此時待證實(shí)的隊(duì)列已滿），只有等到接收方B定時器超時后，向A發(fā)送ACK包，證實(shí)發(fā)送隊(duì)列的消息，A才能繼續(xù)發(fā)送，大大降低了數(shù)據(jù)傳輸效率。所以本文采用基于時間的選擇性確認(rèn)和基于數(shù)據(jù)包數(shù)目的累積確認(rèn)相結(jié)合的確認(rèn)機(jī)制，其算法如下：
if（數(shù)據(jù)包時間確認(rèn)計(jì)時器到時）
{
接收方給發(fā)送方發(fā)送ACK包 AND
數(shù)據(jù)包時間確認(rèn)定時器歸零 AND
數(shù)據(jù)包接收計(jì)數(shù)器歸零;
}
else if （數(shù)據(jù)包接收計(jì)數(shù)器達(dá)到預(yù)定值）
{
接收方給發(fā)送方發(fā)送ACK包 AND
數(shù)據(jù)包時間確認(rèn)定時器歸零 AND
數(shù)據(jù)包接收計(jì)數(shù)器歸零;
}
在這種確認(rèn)機(jī)制下，當(dāng)移動網(wǎng)絡(luò)中帶寬不足，發(fā)送速率較小時，主要是基于時間的選擇性確認(rèn)機(jī)制起到作用。
2.3.3 流量控制機(jī)制
協(xié)議中采取滑動窗口的機(jī)制來實(shí)現(xiàn)數(shù)據(jù)傳輸中的流量控制的功能。滑動窗口的機(jī)制在文獻(xiàn)[3][4]中都有提及。協(xié)議中的數(shù)據(jù)報(bào)文中用于標(biāo)記數(shù)據(jù)傳遞的序號用2.2中設(shè)計(jì)的MessageNumber表示，采用無符號整數(shù)，取值為0～232-1，對應(yīng)圖中的大圓所代表的循環(huán);發(fā)送方和接收方的緩沖區(qū)大小設(shè)置相同，分別對應(yīng)圖中的兩個小循環(huán)。
利用滑動窗口實(shí)現(xiàn)流量控制的方法是：當(dāng)接收方收到一條消息之后就將滑動窗口中的接收窗口大小減1。只有在確定上層應(yīng)用將接收到的消息處理完成后才還原對接收窗口的大小的操作;接收方發(fā)現(xiàn)發(fā)送窗口的大小增加后，表明可以接收更多的數(shù)據(jù)，會向發(fā)送方發(fā)送相應(yīng)的請求，發(fā)送方根據(jù)請求調(diào)整發(fā)送窗口的大小。通過這樣就能夠有效的控制發(fā)送方發(fā)送數(shù)據(jù)的速度，達(dá)到流量控制的效果，防止網(wǎng)絡(luò)擁塞的情況發(fā)送。
3.總結(jié)
本文以對比的方式介紹了TCP和UDP傳輸協(xié)議，并指出了各自的優(yōu)缺點(diǎn)：TCP協(xié)議是面向連接的基于流模式的傳輸協(xié)議，高可靠但效率較低;UDP協(xié)議是面向無連接的基于數(shù)據(jù)報(bào)的傳輸協(xié)議，高效但不可靠。最后，在UDP協(xié)議的基礎(chǔ)上，通過增加簡單的三次握手，確認(rèn)重傳機(jī)制，滑動窗口機(jī)制，設(shè)計(jì)出了一種基于UDP的可靠傳輸協(xié)議，使其在可靠性和傳輸效率之間達(dá)到一個良好的統(tǒng)一與折衷。
參考文獻(xiàn)
[1]Douglas er，林瑤，張娟，王海等.用TCP/IP進(jìn)行網(wǎng)際互聯(lián)――原理、協(xié)議與結(jié)構(gòu)（第五版）[M].北京：電子工業(yè)出版社，2009.
篇5
C是與RCM2200配套使用的軟件開發(fā)語言，它擁有豐富的庫函數(shù)以便程序員編程時調(diào)用，結(jié)果表明，運(yùn)用該語言能實(shí)現(xiàn)基于RCM2200以太網(wǎng)與異步串口之間的成功通信。
關(guān)鍵詞 嵌入式系統(tǒng)；RCM2200；UDP報(bào)文；串口通信
1 引言
目前，嵌入式技術(shù)已經(jīng)廣泛滲入并應(yīng)用到各領(lǐng)域，涉及到多種傳統(tǒng)及現(xiàn)代技術(shù)，形成了前所未有的多學(xué)科、多領(lǐng)域的交叉與融合。由Z-World公司推出的RCM2200[1]是一款低成本的嵌入式微控制器核心模塊，它采用Dynamic C?[2]這一專門為Z-World產(chǎn)品創(chuàng)建的集成的C 編譯器、編輯器、鏈接器、裝載器和調(diào)試器，便于實(shí)現(xiàn)快速開發(fā)應(yīng)用，加快產(chǎn)品投放到市場。
UDP協(xié)議[3][4]是比較著名的傳輸層協(xié)議之一，它與TCP協(xié)議一樣是基于IP協(xié)議的，但與TCP不同的是它不需要協(xié)議層提供質(zhì)量保證，因此，在需要實(shí)時數(shù)據(jù)傳輸?shù)那闆r下應(yīng)用比較廣泛。并且，因?yàn)椴惶峁┵|(zhì)量保證，服務(wù)器沒有必要一直處于等待狀態(tài)，從而大大減輕了服務(wù)器的負(fù)擔(dān)。在某些情況下，還可以根據(jù)需要給UDP報(bào)文加上一些質(zhì)量保證控制，有很大的靈活度。
在不遠(yuǎn)的將來，將設(shè)備與網(wǎng)絡(luò)相連將成為一種趨勢。在諸如GPS串口數(shù)據(jù)網(wǎng)絡(luò)收發(fā)以及某些語音傳輸、實(shí)時監(jiān)控等多種場合，實(shí)現(xiàn)以太網(wǎng)與異步串口數(shù)據(jù)之間的通信是非常必要的。本文介紹了一種基于RCM2200嵌入式微控制器核心模塊利用UDP報(bào)文實(shí)現(xiàn)網(wǎng)絡(luò)與串口互通的方法，可以迅速實(shí)現(xiàn)將串口與網(wǎng)絡(luò)相連接。
2 系統(tǒng)原理及功能
RCM2200采用Rabbit半導(dǎo)體公司推出的高性能8位器件－Rabbit2000型微處理器；帶RJ-45插口的內(nèi)置10Base-T端口簡化了網(wǎng)絡(luò)連接，便于開發(fā)帶以太網(wǎng)接口的監(jiān)控、通訊設(shè)備；配備有4個串行口，方便擴(kuò)展聯(lián)接；擁有26根并行的I/O引線以及16根可設(shè)置的I/O引線，無須擴(kuò)展即可完成一般的I/O任務(wù)；擁有256K Flash，128K SRAM， 用于代碼存儲和數(shù)據(jù)存儲；時間、日期、看門狗、定時器等一應(yīng)俱全；且其采用雙列直插式引腳，尺寸僅為59 x 41 x 22 mm。這種結(jié)構(gòu)促進(jìn)了嵌
入式系統(tǒng)的快速開發(fā)，并可實(shí)現(xiàn)集成的以太網(wǎng)連接。
RCM2200系統(tǒng)的基本框架結(jié)構(gòu)如圖1所示。
圖1 RCM2200系統(tǒng)結(jié)構(gòu)
RCM2200采用Dynamic C?語言進(jìn)行軟件開發(fā)，與標(biāo)準(zhǔn)C語言相比，Dynamic C的改進(jìn)和差異在于使得在功能強(qiáng)大的嵌入式系統(tǒng)上進(jìn)行實(shí)時
編程變得非常容易。 語言的擴(kuò)展包括多任務(wù)和優(yōu)
先多任務(wù)的構(gòu)造，當(dāng)供電失敗時，能夠保護(hù)寫入變量， 能夠?qū)懭氲街袛喑绦蛑腥ァ?biāo)準(zhǔn)C函數(shù)庫，特定板的外圍驅(qū)動，芯片外圍設(shè)備，以及其他的性能以源代碼的形式包含在Dynamic C中。完全支持匯編語言，在對時間要求較高的應(yīng)用中，匯編代碼可以方便的與C代碼混用。
在該開發(fā)系統(tǒng)中將RCM2200的以太網(wǎng)接口與當(dāng)?shù)鼐钟蚓W(wǎng)相連，選擇一個串口與計(jì)算機(jī)的串口相連。由以太網(wǎng)發(fā)送UDP報(bào)文給RCM2200微控制器核心模塊經(jīng)過處理后通過串口發(fā)送給計(jì)算機(jī)，由計(jì)算機(jī)串口發(fā)送數(shù)據(jù)給RCM2200微控制器核心模塊經(jīng)過處理后通過其上的網(wǎng)絡(luò)口發(fā)送UDP報(bào)文給以太網(wǎng)，從而實(shí)現(xiàn)基于RCM2200以太網(wǎng)和串口之間的通信。
3 UDP協(xié)議的實(shí)現(xiàn)
UDP協(xié)議是比較著名的傳輸層協(xié)議之一，它使用IP作為網(wǎng)絡(luò)層協(xié)議，為應(yīng)用程序發(fā)送和接收數(shù)據(jù)報(bào)。但是，它提供無連接服務(wù)，是不可靠傳輸。因此，UDP報(bào)文主要用于需要實(shí)時數(shù)據(jù)傳輸?shù)那闆r，一次傳輸少量的數(shù)據(jù)。在某些對實(shí)時性要求很高的場合，利用UDP報(bào)文進(jìn)行數(shù)據(jù)傳輸是非常必要的，但往往要采用一些可靠性方案，以防止有漏傳、誤傳的現(xiàn)象發(fā)生。
3.1 客戶機(jī)/服務(wù)器程序設(shè)計(jì)模式
客戶機(jī)/服務(wù)器的程序設(shè)計(jì)模式在網(wǎng)絡(luò)程序設(shè)計(jì)中被大量的應(yīng)用。這種設(shè)計(jì)模式將整個系統(tǒng)分為兩大部分——服務(wù)器部分和客戶機(jī)部分。客戶機(jī)向服務(wù)器提出請求，服務(wù)器對請求作相應(yīng)的處理將結(jié)果返回給客戶機(jī)。
根據(jù)不同的實(shí)際情況，客戶機(jī)/服務(wù)器的通信存在對稱和非對稱兩種方式。在對稱的方式下，通信的每一方都可能扮演主從角色；在非對稱的方式下，一方不可改變的認(rèn)為是主機(jī)，而另一方則是從機(jī)。無論是對稱的或是非對稱的，當(dāng)服務(wù)被提供時必然存在客戶進(jìn)程和服務(wù)進(jìn)程。基于UDP協(xié)議的通信既可采用對稱方式也可采用非對稱方式。
3.2 數(shù)據(jù)報(bào)套接字
套接字（socket）是通信的基石，是支持TCP/IP協(xié)議的網(wǎng)絡(luò)通信的基本操作單元。它是網(wǎng)絡(luò)通信過程中端點(diǎn)的抽象表示，包含進(jìn)行網(wǎng)絡(luò)通信必須的五種信息：連接使用的協(xié)議，本地主機(jī)的IP地址，本地進(jìn)程的協(xié)議端口，遠(yuǎn)地主機(jī)的IP地址，遠(yuǎn)地進(jìn)程的協(xié)議端口。
UDP協(xié)議支持?jǐn)?shù)據(jù)報(bào)套接字。這種套接字可以采用客戶/服務(wù)器模式，以全雙工方式工作，接收發(fā)送可以同時進(jìn)行，但并不保證數(shù)據(jù)傳輸?shù)目煽啃浴⒂行蛐院蜔o重復(fù)性，需要由程序員負(fù)責(zé)管理數(shù)據(jù)報(bào)的排序和可靠性。
3.3 使用Dynamic C實(shí)現(xiàn)UDP報(bào)文的傳輸
Dynamic C提供了許多支持TCP/IP協(xié)議的庫函數(shù)。其中，DCRTCP.LIB是最主要的函數(shù)庫。
下面將簡要介紹UDP協(xié)議下的基本通信流程。
3.3.1 調(diào)用本地初始化函數(shù)
void sock_init(void)
該函數(shù)將使用默認(rèn)配置初始化本地信息包驅(qū)動器以及DCRTCP.LIB函數(shù)庫。該函數(shù)必須在其他網(wǎng)絡(luò)庫函數(shù)被使用前進(jìn)行調(diào)用。
3.3.2 打開數(shù)據(jù)報(bào)套接字
int udp_open( *s， lport， remote_IP， port， *data_handler ())
其中的參數(shù)解釋如下：
s : 指向UDP套接字的指針；
lport : 本地協(xié)議端口；
remote_IP : 可接受的遠(yuǎn)地主機(jī)IP地址，如果該項(xiàng)為-1，則支持廣播通信；
port : 可接受的遠(yuǎn)地進(jìn)程協(xié)議端口，如果該項(xiàng)為-1，則為廣播數(shù)據(jù)報(bào)；
data_handler() : 如果接收到數(shù)據(jù)則調(diào)用該函數(shù)；
該函數(shù)的返回值，如果成功返回非零，否則返回零值。
3.3.3 接收遠(yuǎn)地主機(jī)發(fā)送的數(shù)據(jù)報(bào)
int udp_recv( *s， *buf_recv， recv_len)
當(dāng)套接字初始化后用該函數(shù)掃描接收緩沖區(qū)，，察看是否有數(shù)據(jù)報(bào)到達(dá)。其中，
buf_recv : 指向用于存放已到達(dá)數(shù)據(jù)報(bào)的數(shù)組的指針；
recv_len : 存放數(shù)據(jù)報(bào)的數(shù)組的大小。
如果接收到數(shù)據(jù)報(bào)則返回?cái)?shù)據(jù)報(bào)的長度；否則返回-1。
3.3.4 發(fā)送數(shù)據(jù)報(bào)給遠(yuǎn)地主機(jī)
int udp_send( *s， *buf_send， send_len )
調(diào)用該函數(shù)發(fā)送數(shù)據(jù)報(bào)給遠(yuǎn)地主機(jī)。如果成功返回該數(shù)據(jù)報(bào)的長度，否則返回-1。
buf_send : 指向待發(fā)送數(shù)據(jù)報(bào)的指針；
send_len : 待發(fā)送數(shù)據(jù)報(bào)的長度。
3.3.5 網(wǎng)絡(luò)信息處理函
int tcp_tick( *s )
該函數(shù)將察看網(wǎng)絡(luò)連接狀態(tài)，檢查數(shù)據(jù)報(bào)的到達(dá)情況，處理新到數(shù)據(jù)報(bào)并重傳丟失的數(shù)據(jù)報(bào)。若出現(xiàn)網(wǎng)絡(luò)連接被復(fù)位及套接字已關(guān)閉的情況或參量s為NULL，則返回值為零；否則返回非零值。
3.3.6 關(guān)閉套接字
void sock_close( *s )
當(dāng)數(shù)據(jù)傳送工作完成或傳送過程中發(fā)生錯誤時，可調(diào)用該函數(shù)關(guān)閉套接字
4
串口通信的實(shí)現(xiàn)
4.1 RS232電平與TTL電平的轉(zhuǎn)換
PC機(jī)的串行接口是符合EIA RS-232C規(guī)范的外部總線標(biāo)準(zhǔn)接口，而RCM2200配備有四個串行接口，都是采用TTL電平，因此兩者之間必須進(jìn)行電平轉(zhuǎn)換。以RCM2200的串行口C（位于核心模塊的J4插槽上）為例，電平轉(zhuǎn)換如圖2所示。
圖2 RS232與TTL電平轉(zhuǎn)換圖
4.2 使用Dynamic C實(shí)現(xiàn)串口數(shù)據(jù)的傳輸
Dynamic C提供了一些與計(jì)算機(jī)串行口進(jìn)行通信的函數(shù)可供用戶程序調(diào)用，下面簡要介紹其中的一部分。
4.2.1 打開串行接口
int serXopen( bard )
bard : 長整型，每秒鐘傳送的比特?cái)?shù)。
該函數(shù)用于打開RCM2200的串行接口，由于RCM2200核心模塊擁有四個串行口，故X可根據(jù)需要取為A\B\C\D其中一個。在調(diào)用該函數(shù)之前，還必須先定義串行口的輸入輸出緩沖區(qū)大小，通常情況下設(shè)定為2n-1，否則就采用默認(rèn)值31，但在編譯時會給出警告。該函數(shù)的返回值：成功則為1，否則為0。
4.2.2 讀取PC機(jī)串行口數(shù)據(jù)
int serXgetc()
/* X = A|B|C|D */
程序可以調(diào)用該函數(shù)查詢串行口是否有字符來到，如果有，返回該字符值；否則，返回值-1。
4.2.3 發(fā)送數(shù)據(jù)到PC機(jī)串行口
int serXputs( *s )
int serXwrite( s， length ) /* X = A|B|C|D */
這兩個函數(shù)均可用于發(fā)送字符串給計(jì)算機(jī)的串行口，返回成功發(fā)送的字符數(shù)。
s : 待發(fā)送字符串的首地址；
length : 待發(fā)送字符串的長度。
4.2.4 關(guān)閉串行口
void serXclose()
/* X = A|B|C|D */
該函數(shù)用于關(guān)閉已經(jīng)打開的串行口。
5
實(shí)現(xiàn)以太網(wǎng)與串口之間的通信
5.1
定義網(wǎng)絡(luò)以及串口初始化數(shù)據(jù)
在程序的開頭，必須使用#define定義一些初
始化數(shù)據(jù)，比如：RCM2200所使用的本地IP地址以及端口，與之通信的遠(yuǎn)地IP地址以及端口以及串口輸入輸出緩沖區(qū)的大小等等。
5.2 主程序
在主程序中調(diào)用PC機(jī)串口發(fā)送字符串給RCM2200經(jīng)過處理后再由RCM2200發(fā)送UDP報(bào)文給以太網(wǎng)以及RCM2200接收以太網(wǎng)發(fā)送來的UDP報(bào)文后再送給計(jì)算機(jī)的串行口兩個子程序。
main()
{
sock_init(); //初始化網(wǎng)絡(luò)庫函數(shù)
: //打開串行口及網(wǎng)絡(luò)套接字
for(;;;)
{
tcp_tick(NULL);//察看套接字狀態(tài)
init_comm();//網(wǎng)絡(luò)發(fā)報(bào)文串口接收
comm_init();//串口發(fā)數(shù)據(jù)網(wǎng)絡(luò)接收
}
}
5.3網(wǎng)絡(luò)發(fā)報(bào)文串口接收
子程序init_comm() 使用庫函數(shù)udp_recv查詢RCM2200以太網(wǎng)接口是否有UDP報(bào)文來到，如果沒有則返回主程序，否則將UDP報(bào)文存放到buf_init數(shù)組中，然后調(diào)用serCputs(buf_init)通過RCM2200的串行口C發(fā)送到計(jì)算機(jī)的串行口。值得一提的是，當(dāng)RCM2200接收到了一次報(bào)文之后，它將自動關(guān)閉接收報(bào)文的套接字，因此，如果還想接受下一次發(fā)送的報(bào)文，必須再次調(diào)用函數(shù)udp_open打開該套接字。
5.4串口發(fā)字符串網(wǎng)絡(luò)接收
子程序 comm_init()調(diào)用函數(shù)serCgetc()用于查詢計(jì)算機(jī)的串行口是否有數(shù)據(jù)到來，如果沒有則返回主程序，否則將接收到的字符存儲到buf_comm數(shù)組中，直到檢測到結(jié)束符到來，將字符串以UDP報(bào)文的形式通過函數(shù)udp_send發(fā)送給以太網(wǎng)。如果發(fā)送成功，則返回主程序等待下一次數(shù)據(jù)的到來，否則關(guān)閉該套接字后重新打開再返回主程序等待。
5.5程序調(diào)試結(jié)果
在該程序的調(diào)試過程中，利用Visual C++語言編寫了一個接收和發(fā)送UDP報(bào)文的程序用于以太網(wǎng)的計(jì)算機(jī)上，另外還使用了從網(wǎng)上下載的串口調(diào)試幫助軟件，結(jié)果表明，該程序能實(shí)現(xiàn)基于RCM2200以太網(wǎng)與異步串口之間的成功通信。
結(jié)論
RCM2200是為了促進(jìn)嵌入式系統(tǒng)的快速開發(fā)和實(shí)現(xiàn)集成的以太網(wǎng)連接而設(shè)計(jì)的。集成的以太網(wǎng)口允許用戶通過使用經(jīng)濟(jì)的網(wǎng)絡(luò)軟件進(jìn)行瞬間的本地連接或全球范圍的連接。另外，RCM2200還提供了四個串行口用于和其他設(shè)備的串行口進(jìn)行數(shù)據(jù)交換。
RCM2200使用Dynamic C軟件開發(fā)環(huán)境，支持C語言、匯編語言，擁有豐富的庫函數(shù)可供用戶調(diào)用，并具有單步編譯、斷點(diǎn)設(shè)置、單步執(zhí)行、代碼分解、監(jiān)視表達(dá)式等優(yōu)秀性能。
使用Dynamic C接收和發(fā)送UDP報(bào)文時，由于網(wǎng)絡(luò)對該報(bào)文的傳輸不提供質(zhì)量保證，在每完成一次操作后，必須及時檢查套接字的狀態(tài)，避免發(fā)生誤傳、漏傳以及套接字關(guān)閉等現(xiàn)象。在發(fā)送和接收串口數(shù)據(jù)時，要注意使RCM2200的串口數(shù)據(jù)傳輸波特率與PC機(jī)保持一致，這樣，才能保證正確傳輸。
參考文獻(xiàn)
【1】Z-World， Inc. RabbitCore RCM2200 User’s Manual 2001年
【2】Z-World， Inc. Dynamic C premier User’s Manual
1999年
篇6
【關(guān)鍵詞】 無線網(wǎng)絡(luò) 多媒體 通信 傳輸技術(shù)
引言：隨著社會的發(fā)展，人們生活水平日漸提升，其安全防護(hù)意識也有所增強(qiáng)，在先進(jìn)技術(shù)支持下，無線網(wǎng)絡(luò)應(yīng)急多媒體通信的應(yīng)用愈加廣泛，不僅保證了人們的安全，還提高了其生活質(zhì)量。但實(shí)際應(yīng)用中，對應(yīng)急多媒體通信有著較高的要求，如：實(shí)時性、可靠性與連續(xù)性等，而無線網(wǎng)絡(luò)應(yīng)急多媒體通信未能滿足上述要求，因此，本文探討了其傳輸協(xié)議與通信終端系統(tǒng)，旨在進(jìn)一步提高其整體性能。
一、應(yīng)急多媒體通信的無線網(wǎng)絡(luò)特點(diǎn)
其一，低寬帶，通常情況下，其寬帶僅為1-2個數(shù)量級；其二，時變性，對于應(yīng)急通信終端來說，其主要用于移動情況，此時的應(yīng)用環(huán)境會影響無線網(wǎng)絡(luò)的寬帶變化，特別是移動處于高速狀態(tài)下，可能發(fā)生突變；其三，非對稱性，無線網(wǎng)絡(luò)的上行與下行寬帶各異；其四，影響較大，在實(shí)際數(shù)據(jù)傳輸中信道干擾較為嚴(yán)重，同時誤碼率較高，通常情況下，與有線傳輸相比，會高出幾個數(shù)量級。在實(shí)際研究與設(shè)計(jì)過程中，結(jié)合上述特點(diǎn)，要求應(yīng)急多媒體通信傳輸技術(shù)應(yīng)符合以下要求：第一點(diǎn)，在保證清晰度的前提下，占用較小的寬帶資源；第二點(diǎn)，寬帶大小變化過程中應(yīng)具備較強(qiáng)的自適應(yīng)性；第三點(diǎn)，多媒體數(shù)據(jù)傳輸時應(yīng)保證較小的延時；第四點(diǎn)，數(shù)據(jù)傳輸應(yīng)具備較高的可靠性與穩(wěn)定性。
二、 應(yīng)急多媒體通信流媒體協(xié)議的選用
目前，傳輸協(xié)議較多，其中使用頻率較高的有用戶數(shù)據(jù)報(bào)協(xié)議（UDP）與傳輸控制協(xié)議（TCP）。
1、UDP協(xié)議。此協(xié)議屬于無連接協(xié)議，其在網(wǎng)絡(luò)中主要用于處理數(shù)據(jù)包，它的優(yōu)點(diǎn)為簡單的分組格式、較小的頭部開銷、較快的處理速度，因此，UDP作為應(yīng)用層時，所提供的傳輸服務(wù)則會缺少可靠性。在選用UDP協(xié)議時，應(yīng)考慮UDP的特性，通常情況下，其可用于大信息量的音頻、視頻與普通數(shù)據(jù)的實(shí)時傳送[1]。UDP協(xié)議的快速與簡單等優(yōu)點(diǎn)較為顯著，滿足了大多數(shù)流媒體的應(yīng)用需求，但由于此協(xié)議缺少可靠性與可控性，導(dǎo)致其極易出現(xiàn)各種問題。
2、TCP協(xié)議。此協(xié)議的設(shè)計(jì)主要是為了服務(wù)有線網(wǎng)絡(luò)，當(dāng)前，其作為傳輸層協(xié)議的使用頻率較高。由于有線網(wǎng)絡(luò)擁塞問題較為嚴(yán)重，進(jìn)而極易出現(xiàn)報(bào)文丟失，同時其出錯率也相對較低，而使用TCP協(xié)議后，經(jīng)發(fā)送方、接收方與網(wǎng)絡(luò)的協(xié)調(diào)合作，進(jìn)而保證了有線網(wǎng)絡(luò)數(shù)據(jù)傳輸?shù)男Чτ跓o線網(wǎng)絡(luò)而言，如果其使用TCP協(xié)議，為了保證多媒體數(shù)據(jù)的高效傳輸，需要較大的緩沖區(qū)，同時也需要充足的寬帶，但在實(shí)際應(yīng)用中不具備上述條件，隨之出現(xiàn)了諸多問題，如：較高的丟包率、較差的網(wǎng)絡(luò)狀況等。
3、混合協(xié)議。現(xiàn)階段，流媒體傳輸協(xié)議中最為流行的為RTSP/RTP/RTCP/UDP協(xié)議，實(shí)時傳輸中應(yīng)使用RTP與RTCP兩個端口，前者借助UDP協(xié)議，以此保證了實(shí)時視音頻數(shù)據(jù)的快速傳輸，后者借助TRCP協(xié)議，從而實(shí)現(xiàn)了對傳輸信息的有效控制，通過二者，最終實(shí)現(xiàn)了高效傳輸[2]。UDP具有良好的實(shí)時性，但其不具備擁塞控制機(jī)制，導(dǎo)致UDP協(xié)議易丟失數(shù)據(jù)，進(jìn)而擦混熟速率也將受到較大的影響；TCP擁有擁塞控制機(jī)制、重傳機(jī)制與流量控制機(jī)制，其實(shí)施需要借助大量的反饋信息，而此時的信息會占用一定的寬帶。在此情況下，本文結(jié)合二者的優(yōu)缺點(diǎn)，設(shè)計(jì)了TCP/UDP混合協(xié)議，通過二者優(yōu)點(diǎn)的充分發(fā)揮，兼顧了傳輸效率與可靠性，以此保證了無線網(wǎng)絡(luò)視音頻的高質(zhì)量傳輸。
三、ARM/DSP雙核嵌入式系統(tǒng)
在無線網(wǎng)絡(luò)中傳輸視音頻時，利用TCP/UDP混合協(xié)議，保證了傳輸?shù)乃俣扰c質(zhì)量，但為了保證整個音視頻通信的效果，仍需要注重其終端，在強(qiáng)有力終端支持下，進(jìn)一步增加多媒體數(shù)據(jù)傳輸?shù)乃俣龋M(jìn)一步提高其通信的質(zhì)量。目前，國內(nèi)外學(xué)者在研究多媒體時，主要關(guān)注的內(nèi)容為嵌入式終端系統(tǒng)計(jì)算能力的提高。本文提出了ARM/DSP雙核移動多媒體嵌入式系統(tǒng)，其中ARM端的主控芯片為S3C2440A芯片，DSP端的主控芯片為BlackFin533芯片，它可支持WinCE與Linux系統(tǒng)，充分發(fā)揮了ARM的控制性能與DSP的視頻數(shù)據(jù)處理能力。ARM/DSP雙核嵌入式系統(tǒng)主要是由ARM、DSP及其相連接的SPI接口三部分構(gòu)成的，ARM作為操作系統(tǒng)，主要提供的功能有圖形界面、應(yīng)用程序與網(wǎng)絡(luò)通信功能；DSP需要提供SPI通信協(xié)議，從而實(shí)現(xiàn)了相應(yīng)的操作[3]。
總結(jié)：綜上所述，本文分析了無線網(wǎng)絡(luò)應(yīng)急多媒體通信傳輸技術(shù)，重點(diǎn)分析了其傳輸協(xié)議及終端系統(tǒng)，相信，通過TCP/UDP混合協(xié)議及ARM/DSP雙核嵌入式系統(tǒng)的應(yīng)用，無線網(wǎng)絡(luò)應(yīng)急多媒體通信的質(zhì)量將不斷提高。
參 考 文 獻(xiàn)
[1]何君燕，劉凱. 井下無線多媒體傳感器網(wǎng)絡(luò)圖像傳輸技術(shù)研究[J]. 軟件，2012，01：112-115.
篇7
關(guān)鍵詞：SOCKS；NAT；P2P；STUN；穿透
中圖分類號：TP393.03
IP網(wǎng)絡(luò)地址是整個互聯(lián)網(wǎng)的基礎(chǔ)，目前大多數(shù)網(wǎng)絡(luò)設(shè)備使用的都是IPv4地址。IPv4地址提出的時候沒有想到互聯(lián)網(wǎng)發(fā)展如此之快：根據(jù)2012年的思科報(bào)告，全球有23億互聯(lián)網(wǎng)用戶，到2017年，全球?qū)屑s36億互聯(lián)網(wǎng)用戶。到2017年，將會有超過190億全球網(wǎng)絡(luò)聯(lián)接（固定/移動個人設(shè)備、M2M聯(lián)接等）。現(xiàn)在IPv4的地址已經(jīng)不夠這些設(shè)備使用了，為了解決這個問題，IETF提供了NAT[1][2]方案，這個方案使用NAT將網(wǎng)絡(luò)分為外網(wǎng)和私網(wǎng)，每個私網(wǎng)都可以重用，這個方案大大緩解了IPv4地址匱乏的問題。但是這個方案導(dǎo)致了一個問題，對于想對外提供服務(wù)的NAT私網(wǎng)內(nèi)的用戶而言，這個功能會受到限制，最主要的原因是NAT外的用戶不能直接訪問到NAT內(nèi)私網(wǎng)中的計(jì)算機(jī)數(shù)據(jù)。這種情況導(dǎo)致了互聯(lián)網(wǎng)上P2P互相訪問的困難。不過目前還有很多應(yīng)用需要這種服務(wù)器式的被動訪問，比如SOCKS4/5[3][4]協(xié)議，這個是最為知名的一種協(xié)議，通過這個協(xié)議服務(wù)，能夠透明地中轉(zhuǎn)服務(wù)器和客戶端之間的數(shù)據(jù)。然而NAT的引入導(dǎo)致在NAT后面的用戶無法對外提供SOCKS4/5服務(wù)。本文試圖使用穿透NAT的P2P技術(shù)，使在NAT內(nèi)的SOCKS4/5服務(wù)也能提供給外部機(jī)器使用，真正實(shí)現(xiàn)對于互聯(lián)網(wǎng)的任何一個用戶都能夠直接訪問。
1 穿透NAT的協(xié)議
為了解決引入NAT設(shè)備后網(wǎng)絡(luò)互聯(lián)出現(xiàn)的問題，有大量協(xié)議被發(fā)明和使用，比如MIDCOM[5]、TURN[6]等，但是這些協(xié)議大都需要第三方介入，這會導(dǎo)致一些問題。如：中轉(zhuǎn)第三方的帶寬、處理能力以及實(shí)時性。這隨著NAT后面節(jié)點(diǎn)的增多，數(shù)據(jù)量的增長以及對于實(shí)時性的嚴(yán)格要求等，這些協(xié)議處理都存在問題。我們希望兩個機(jī)器能夠?qū)崿F(xiàn)真正溝通，而不是通過中繼的方式。UPNP和STUN這兩個協(xié)議能夠?qū)崿F(xiàn)這種真正直接的溝通。
1.1 UPNP[7]
UPNP（Universal Plug and Play）是由UPnP Forum推廣的一套網(wǎng)絡(luò)協(xié)議。該協(xié)議的目標(biāo)是使家庭網(wǎng)絡(luò)和公司網(wǎng)絡(luò)中的各種設(shè)備能夠相互無縫連接，并簡化相關(guān)網(wǎng)絡(luò)的實(shí)現(xiàn)。UPnP通過定義和基于開放、遵循因特網(wǎng)通訊網(wǎng)協(xié)議標(biāo)準(zhǔn)的UPnP設(shè)備控制協(xié)議來實(shí)現(xiàn)這一目標(biāo)。任何設(shè)備都能自動加入一個網(wǎng)絡(luò)，獲取自己的IP地址，宣布自己的名字，根據(jù)請求檢查自身功能并且檢測出其它設(shè)備和它們的功能。支持UPnP的設(shè)備允許UPnP數(shù)據(jù)包通過IGD協(xié)議在沒有用戶交互的情況下，無障礙的通過NAT。但是UPnP的缺點(diǎn)是：它要求所有網(wǎng)絡(luò)中的設(shè)備都支持UPnP，即使單臺設(shè)備不符合UPnP標(biāo)準(zhǔn)的，我們就無法實(shí)現(xiàn)一種P2P網(wǎng)絡(luò)。
1.2 STUN [8][9]
STUN協(xié)議是一種輕量級的客戶端-服務(wù)器模式的協(xié)議，它不需要任何管理員進(jìn)行網(wǎng)絡(luò)配置，就能發(fā)現(xiàn)它們和公網(wǎng)之間是否存在NAT，并確定NAT的類型。STUN協(xié)議目前僅僅支持使用UDP報(bào)文穿透Cone NAT[10]。此協(xié)議利用Cone NAT傳輸 UDP的原理進(jìn)行穿透[11][12][13]：私網(wǎng)內(nèi)某個機(jī)器通過Cone NAT發(fā)送UDP數(shù)據(jù)到外網(wǎng)某個機(jī)器，內(nèi)部IP地址和端口的UDP數(shù)據(jù)經(jīng)過Cone NAT被映射到一個外部地址，在某個時間段內(nèi)這個內(nèi)部IP地址和端口將被轉(zhuǎn)換為固定外部IP地址和端口（這個過程將被Cone NAT記錄，并且存儲為一個Session）。此后，如果外部Session對應(yīng)的機(jī)器發(fā)送UDP數(shù)據(jù)到這個Cone NAT，Cone NAT會把這個數(shù)據(jù)包轉(zhuǎn)發(fā)到內(nèi)部映射的這個地址上。目前IETF定義的STUN協(xié)議目前能夠穿透Cone NAT，但是不能穿透Symmetric NAT。不過我們可以通過修改STUN協(xié)議來實(shí)現(xiàn)穿透Symmetric NAT的目的。[14][15][16]
2 SOCKS4/5協(xié)議
SOCKS協(xié)議是一種應(yīng)用層次的協(xié)議，它提供一種通用方案，能為應(yīng)用程序提供基于TCP和UDP數(shù)據(jù)報(bào)文的服務(wù)，但是它不能ICMP之類的底層通訊協(xié)議，SOCKS協(xié)議從概念上來講是介于應(yīng)用層和傳輸層之間的“中介層（shim-layer）”，SOCKS V4協(xié)議為HTTP、FTP、TELNET、WAI和GOPHER等基于TCP協(xié)議的客戶/服務(wù)器程序提供了方案。新的SOCKS V5協(xié)議在SOCKS V4協(xié)議基礎(chǔ)上作了進(jìn)一步擴(kuò)展，從而可以支持UDP協(xié)議，并對其框架規(guī)定作了擴(kuò)展，以支持安全認(rèn)證方案。同時它還采用地址解析方案以支持域名和IPV6地址。
SOCKS協(xié)議利用握手（negotiation），請求（Requests），應(yīng)答（Replies）等過程完成對于上述協(xié)議的轉(zhuǎn)發(fā)。一般而言SOCKS4/5服務(wù)器通常綁定在1080端口上。
3 NAT穿透SOCKS4/5協(xié)議實(shí)現(xiàn)
3.1 協(xié)議方案
如圖1，為了實(shí)現(xiàn)雙方都在NAT后的機(jī)器的SOCKS4/5之間的直接通信，我們需要一個雙方都能訪問的中間服務(wù)先把兩邊的機(jī)器關(guān)聯(lián)起來。在公網(wǎng)上我們需要架設(shè)一個雙方都能夠聯(lián)系的服務(wù)器，然后通過STUN協(xié)議幫助雙方完成直接通信。一旦直接聯(lián)系完成，我們就不再需要公網(wǎng)中間服務(wù)了，此后我們采用可靠的UDP傳輸協(xié)議完成SOCKS4/5客戶端和服務(wù)器的直接數(shù)據(jù)傳輸。
此協(xié)議分為兩個部分，首先是通過STUN協(xié)議完成NAT后兩個機(jī)器的SOCKS4/5客戶端關(guān)聯(lián)器和SOCKS4/5服務(wù)器關(guān)聯(lián)器的直接通信，然后使用可靠的UDP協(xié)議完成SOCKS4/5客戶端服務(wù)器的數(shù)據(jù)通信。
3.2 建立直接通信
我們可以使用STUN協(xié)議來幫助雙方都在NAT后的機(jī)器建立直接的通信。STUN協(xié)議通過一種叫做UDP hole punching的機(jī)制來實(shí)現(xiàn)這一目的。一旦完成這個操作，兩個NAT設(shè)備后的機(jī)器就能夠?qū)崿F(xiàn)直接的網(wǎng)絡(luò)通信而不再需要STUN服務(wù)器的介入了。
如圖2顯示SOCKS4/5客戶端關(guān)聯(lián)器和SOCKS4/5服務(wù)端關(guān)聯(lián)器通過STUN協(xié)議幫助建立直接通信的過程。
（1）客戶端關(guān)聯(lián)器通過NAT A連接到服務(wù)器，服務(wù)端關(guān)聯(lián)器通過NAT B連接到服務(wù)器，服務(wù)器記錄客戶端關(guān)聯(lián)器和服務(wù)端關(guān)聯(lián)器的外網(wǎng)地址和端口。
（2）服務(wù)器向客戶端關(guān)聯(lián)器發(fā)送服務(wù)端管理器的外網(wǎng)地址和端口消息，服務(wù)器向服務(wù)端關(guān)聯(lián)器發(fā)送客戶端關(guān)聯(lián)器的外網(wǎng)地址和端口消息。
（3）客戶端關(guān)聯(lián)器向服務(wù)端關(guān)聯(lián)器的外網(wǎng)地址和端口發(fā)送hole punching消息。雖然這個數(shù)據(jù)包在NAT B的時候會被阻止（非Full Cone NAT禁止沒經(jīng)過關(guān)聯(lián)的外網(wǎng)IP直接訪問內(nèi)網(wǎng)），但是這個UDP數(shù)據(jù)包在經(jīng)過NAT A的時候，會在NAT A上建立一個Session，這個Session記錄了本地客戶端關(guān)聯(lián)器與服務(wù)端關(guān)聯(lián)器外網(wǎng)地址的關(guān)聯(lián)信息。
（4）服務(wù)端關(guān)聯(lián)器發(fā)送回應(yīng)消息到客戶端關(guān)聯(lián)器，NAT A由于有步驟3由hole punching消息建立的Session，NAT A將會把這個消息轉(zhuǎn)發(fā)到客戶端關(guān)聯(lián)器，完成后雙方建立直接的消息通信。
3.3 SOCKS4/5數(shù)據(jù)傳輸
由于STUN協(xié)議僅僅支持UDP的穿透，但是SOCKS4協(xié)議只支持TCP的連接，為了兼容SOCKS4/5協(xié)議，我們使用轉(zhuǎn)發(fā)的機(jī)制來保證我們的程序能夠完美匹配SOCKS4/5這兩種協(xié)議。
如圖3所示：
（1）SOCKS客戶端關(guān)聯(lián)器綁定本機(jī)端口1080。本地SOCKS客戶端程序（如IE等程序）設(shè)置本地SOCKS為本地127.0.0.1080。SOCKS客戶端按需要訪問某個公網(wǎng)服務(wù)器或者遠(yuǎn)端對方的私網(wǎng)服務(wù)器。
（2）客戶端關(guān)聯(lián)器接收到SOCKS客戶端發(fā)送過來的數(shù)據(jù)，不做任何改變，通過可靠的UDP（如UDT協(xié)議，此協(xié)議可以提供類似TCP的可靠數(shù)據(jù)傳輸）數(shù)據(jù)傳輸發(fā)送到已經(jīng)建立的直接通信的服務(wù)端關(guān)聯(lián)器。
（3）服務(wù)端關(guān)聯(lián)器接收到可靠的UDP傳輸過來的數(shù)據(jù)，然后不做任何改變的將這個數(shù)據(jù)通過TCP轉(zhuǎn)發(fā)到SOCKS4/5的真正服務(wù)器程序（127.0.0.1：1080）。
（4）SOCKS服務(wù)器連接實(shí)際需要訪問的公網(wǎng)或者私網(wǎng)服務(wù)器（如需要訪問的HTTP服務(wù)）。
4 實(shí)驗(yàn)測試
4.1 實(shí)驗(yàn)設(shè)備
系統(tǒng)硬件：三臺PC，配置：CPU P6 3.40GHz 4GM 內(nèi)存
NAT設(shè)備：兩臺NetGear WPN824路由器。
操作系統(tǒng)軟件：Windows7。
4.2 實(shí)驗(yàn)效果
程序經(jīng)過實(shí)際測試證明，支持NAT穿透的SOCKS協(xié)議完全可行。測試顯示瀏覽器瀏覽網(wǎng)站與直接使用SOCKS協(xié)議連接的效率基本接近，但是由于中轉(zhuǎn)過程的花費(fèi)，瀏覽大型網(wǎng)站可能相對于直接SOCKS連接慢了5%，不過這個基本不會影響用戶的感受。
5 結(jié)論
SOCKS協(xié)議是客戶端/服務(wù)器模式，這種模式由于NAT的引入導(dǎo)致如果服務(wù)在NAT后面將會出現(xiàn)問題。本論文使用一種新的客戶端-服務(wù)端關(guān)聯(lián)器方法使得SOCKS協(xié)議能夠支持NAT的穿透，這個使得SOCKS協(xié)議能夠被大多數(shù)工作在NAT后的計(jì)算機(jī)使用。并且這種關(guān)聯(lián)器方法與上層的協(xié)議沒有任何直接關(guān)系，我們可以擴(kuò)展此種協(xié)議，使得很多原來不支持NAT穿透的協(xié)議也能夠被支持，比如：SMTP、POP3、IMAP、SNMP等。同樣，這個方法也能支持我們定義新的協(xié)議，比如類似QQ一樣即時P2P通訊協(xié)議。
參考文獻(xiàn)：
[1]P Srisuresh， M Holdrege. IP network address translator （NAT）terminology and considerations.RFC 2663.August 1999.
[2]G Tsirtsis and P Srisuresh. Network address translation-protocol translation （NAT-PT）.RFC 2766.February 2000.
[3]Ying-Da Lee， SOCKS： A protocol for TCP proxy across firewalls， http：///txt/socks4.protocol.
[4]M. Leech ， M. Ganis， Y. Lee， R. Kuris， D. Koblas， L. Jones. SOCKS Protocol Version 5. RFC 1928.
[5]P Srisuresh， J Kuthan， J Rosenberg， A Molitor，A Rayhan. Middlebox communication architecture and framework.RFC 3303.August 2002.
[6]J. Rosenberg， C. Huitema， and R. Mahy. Traversal using relay NAT （TURN）. Draft-rosenberg-midcom-turn-03， October 2003.
[7]UpnP Forum. Internet gateway device （IGD） standardized device control protocol. November 2001.
[8]J. Rosenberg， J. Weinberger， C. Huitema， R. Mahy.STUNSimple traversal of user datagram protocol（UDP）through network address translators （NATs）.RFC 3489，2003.
[9]J Rosenberg， R Mahy， P Matthews， D Wing. Session traversal utilities for NAT （STUN）. RFC 5389. 2008.
[10]C Jennings. NAT classification results using STUN. RFC 5389. October 2008.
[11]T. Hain. Architectural implications of NAT. RFC 2993. November 2000.
[12]D Senie. Network address translator （NAT）-friendly application design guidelines. RFC 3235. January 2002.
[13]Saikat Guha， Paul Francis. Simple traversal of UDP through NATs and TCP too （STUNT）. http：//nutss.gforge.cis.cornell.edu/stunt.php.
[14]Yuan Wei，Daisuke，et al. A new method for symmetric NAT traversal in UDP and TCP，APAN Network Research Workshop.11-18，August 2008.
[15]王勇，崔修濤，呂釗，李子成.基于探測對Symmetric NAT與端口受限NAT的穿透方案[J].計(jì)算機(jī)應(yīng)用，2006，4（26）.
[16]楊璐，沈悅，蔣蕾.一種TCP協(xié)議穿透Symmetric NAT方案[J].計(jì)算機(jī)工程與應(yīng)用，2007，43（6）.
篇8
在大型企業(yè)自動化系統(tǒng)中，上層企業(yè)管理層和生產(chǎn)監(jiān)控層一般都采用以太網(wǎng)和PC機(jī)，而下層車間現(xiàn)場則采用現(xiàn)場總線和單片機(jī)測控設(shè)備。上下兩層的溝通，通常采用工業(yè)控制機(jī)加以太網(wǎng)卡，再加上PC機(jī)插槽上的接口卡或并行打印口的EPP接口卡實(shí)現(xiàn)。這種連接方式成本高，開發(fā)周期長。針對這種情況，筆者設(shè)計(jì)一種單獨(dú)的CAN以太網(wǎng)網(wǎng)關(guān)互連系統(tǒng)，成功地實(shí)現(xiàn)以太網(wǎng)與現(xiàn)有CAN總線網(wǎng)的直接數(shù)據(jù)互聯(lián)。
1 系統(tǒng)結(jié)構(gòu)
系統(tǒng)總體結(jié)構(gòu)分為三部分：現(xiàn)場測控網(wǎng)絡(luò)（CAN網(wǎng)絡(luò)）、嵌入式透明SX52網(wǎng)關(guān)、以太網(wǎng)信息管理終端（如監(jiān)控平臺和網(wǎng)絡(luò)數(shù)據(jù)庫等），如圖1所示。
CAN總線是一個設(shè)備互連總線型控制網(wǎng)絡(luò)。在CAN總線上可以掛接多達(dá)110個設(shè)備節(jié)點(diǎn)，各設(shè)備間可以自主相互通信，實(shí)現(xiàn)復(fù)雜網(wǎng)絡(luò)控制系統(tǒng)。但設(shè)備信息層無法直接到達(dá)信息管理層，要想設(shè)備信息進(jìn)入信息管理層需通過數(shù)據(jù)網(wǎng)關(guān)。嵌入式透明SX52網(wǎng)關(guān)就是為此而設(shè)計(jì)的。
透明式網(wǎng)關(guān)在以太網(wǎng)應(yīng)用層構(gòu)建和解析完整的CAN協(xié)議數(shù)據(jù)包。CAN協(xié)議數(shù)據(jù)包作為TCP／IP網(wǎng)絡(luò)應(yīng)用層的數(shù)據(jù)進(jìn)行傳輸，它對通信數(shù)據(jù)的具體實(shí)際意義不做任何解釋。透明式網(wǎng)關(guān)由通信處理器、CAN總線控制器和以太網(wǎng)控制器三部分組成。其中SX52單片機(jī)為核心處理器，它實(shí)現(xiàn)了CAN控制網(wǎng)絡(luò)與以太網(wǎng)之間的協(xié)議轉(zhuǎn)換。以太網(wǎng)信息管理層的控制指令發(fā)送到嵌入式透明SX52網(wǎng)關(guān)，將TCP／IP協(xié)議包數(shù)據(jù)轉(zhuǎn)換為CAN協(xié)議形式發(fā)送至CAN控制網(wǎng)絡(luò)中的指定設(shè)備節(jié)點(diǎn)，完成信息管理層對現(xiàn)場設(shè)備層的控制。同樣地，當(dāng)CAN網(wǎng)絡(luò)上的設(shè)備數(shù)據(jù)（如定時采樣數(shù)據(jù)或報(bào)警信息）要傳輸?shù)叫畔⒐芾韺訒r，可將數(shù)據(jù)發(fā)送到嵌入式透明SX52網(wǎng)關(guān)，再通過網(wǎng)關(guān)協(xié)議轉(zhuǎn)換程序?qū)AN協(xié)議數(shù)據(jù)封裝成TCP／IP協(xié)議的以太網(wǎng)數(shù)據(jù)幀發(fā)送至以太網(wǎng)上的監(jiān)控計(jì)算機(jī)。
以太網(wǎng)信息管理終端是一個根據(jù)用戶的具體要求而設(shè)計(jì)的用戶層應(yīng)用軟件。它可以是一個WIN32監(jiān)控程序或網(wǎng)絡(luò)數(shù)據(jù)庫（記錄CAN節(jié)點(diǎn)設(shè)備數(shù)據(jù)）軟件等；甚至可能是CAN節(jié)點(diǎn)設(shè)備的服務(wù)器軟件，為設(shè)備提供較復(fù)雜的數(shù)據(jù)處理工作。
2 硬件設(shè)計(jì)
系統(tǒng)硬件分為兩大部分：CAN總線網(wǎng)絡(luò)設(shè)備接口設(shè)計(jì)和嵌入式透明SX52網(wǎng)關(guān)設(shè)計(jì)。
2．1 CAN總線網(wǎng)絡(luò)設(shè)備接口設(shè)計(jì)
CAN總線網(wǎng)絡(luò)設(shè)備接口設(shè)計(jì)較網(wǎng)關(guān)設(shè)計(jì)簡單。它是在完成設(shè)備功能的基礎(chǔ)上加入一個CAN通信控制器接口芯片，實(shí)現(xiàn)與CAN總線網(wǎng)絡(luò)的連接。考慮到開發(fā)成本和靈活性，筆者在設(shè)計(jì)中選用PHILIPHS公司的獨(dú)立CAN通信控制器SJA1000芯片和CAN總線收發(fā)器82C250芯片。其結(jié)構(gòu)如圖2所示。
2．2 嵌入式透明SX52網(wǎng)關(guān)設(shè)計(jì)
嵌入式透明網(wǎng)關(guān)設(shè)計(jì)是整個系統(tǒng)設(shè)計(jì)的核心。其結(jié)構(gòu)如圖3所示。它由CAN控制器協(xié)議轉(zhuǎn)換模塊和以太網(wǎng)控制器協(xié)議轉(zhuǎn)換模塊兩部分組成。網(wǎng)關(guān)硬件中SX52微處理器起核心作用。它是由美國Ubicom公司研制的高速可配置通信控制器，其處理速度相當(dāng)高。在外接100MHz時鐘時，指令執(zhí)行速度可達(dá)100 MIPS。它可實(shí)現(xiàn)TCP／IP協(xié)議棧中的ARP、IP、UDP、TCP、HTTP、SMTP、ICMP等網(wǎng)絡(luò)協(xié)議。
CAN控制器協(xié)議轉(zhuǎn)換模塊硬件電路原理如圖3左框圖。它由三部分組成：微控制器SX52、獨(dú)立CAN通信控制器SJA1000、CAN總線收發(fā)器82C250。其中SX52為唯一的CPU核心，負(fù)責(zé)SJA1000的初始化，通過讀寫SJA1000內(nèi)部寄存器實(shí)現(xiàn)數(shù)據(jù)的接收、發(fā)送和錯誤處理等。PCA82C250則提供對總線的差動發(fā)送能力和對CAN控制器的差動接收能力。
以太網(wǎng)控制器協(xié)議轉(zhuǎn)換模塊主要由微控制器SX52、以太網(wǎng)通信控制器RTL8019AS和隔離濾波器FB2002組成。RTL8019AS是臺灣Realtek公司制造的一種高集成度的全雙工10Mbps以太網(wǎng)控制芯片，實(shí)現(xiàn)了基于Ethernet協(xié)議的MAC層的全部功能，內(nèi)置16KB的SRAM、雙DMA通道和FIFO完成數(shù)據(jù)包的接收和發(fā)送功能。在網(wǎng)關(guān)設(shè)計(jì)中，使用跳線模式（JP置為高）硬配置RTL8019AS為8位模式。使用RTL8019的低5位地址線A0～A4以及低8位數(shù)據(jù)線D0～D7。SX52的B口的B0～B4腳作為地址線連接RTL8019AS的低5位地址線，B5～B7作為控制線分別連接讀寫時序控制腳IORB、IOWB、IOCHRDY；C口作為數(shù)據(jù)線連接RTL8019AS的低8位數(shù)據(jù)線；A口保留，用作日后擴(kuò)展。圖3中AT24C64為8KB EEPROM，主要用來保存嵌入式透明SX－52網(wǎng)關(guān)的配置信息，如網(wǎng)關(guān)IP地址、MAC地址和SJA1000的ID網(wǎng)絡(luò)標(biāo)示符、網(wǎng)絡(luò)掩碼AMR和總線定時（BTR0、BTR1）等。這樣，可以靈活方便地修改網(wǎng)關(guān)參數(shù)，適應(yīng)不同環(huán)境，同時也考慮到以后的擴(kuò)展。
RTL8019AS除與SX52連接外，還將其網(wǎng)絡(luò)收發(fā)器的4根引腳TPOUT＋、TPOUT－、TPIN＋、TPIN－通過外接的隔離濾波器FB2002與以太網(wǎng)相連。采用隔離濾波器FB2002是為了提高網(wǎng)絡(luò)通信的抗干擾能力。
3 軟件設(shè)計(jì)
整個互聯(lián)系統(tǒng)的軟件設(shè)計(jì)可以分為三部分：CAN總線設(shè)備接口通信程序、透明網(wǎng)關(guān)協(xié)議轉(zhuǎn)換程序和以太網(wǎng)層應(yīng)用程序設(shè)計(jì)。其中，CAN總線設(shè)備接口通信程序和透明網(wǎng)關(guān)協(xié)議轉(zhuǎn)換程序的CAN控制器協(xié)議模塊在結(jié)構(gòu)上有較大的相似性，但有可能因采用微控制器不同而導(dǎo)致實(shí)現(xiàn)的程序語言相異。因而，在此不作論述，而主要討論后兩個方面的程序設(shè)計(jì)。
3．1 透明網(wǎng)關(guān)協(xié)議轉(zhuǎn)換程序
透明網(wǎng)關(guān)協(xié)議轉(zhuǎn)換程序的整體設(shè)計(jì)思路為：當(dāng)以太網(wǎng)應(yīng)用層有數(shù)據(jù)要發(fā)送到CAN節(jié)點(diǎn)時，首先，數(shù)據(jù)發(fā)送到透明網(wǎng)關(guān)由以太網(wǎng)控制器協(xié)議轉(zhuǎn)換模塊從傳輸層數(shù)據(jù)報(bào)文中解析出完整的CAN協(xié)議數(shù)據(jù)包，存放在數(shù)據(jù)緩沖區(qū)A?再通知總調(diào)度模塊，由它調(diào)用CAN控制器協(xié)議模塊將CAN協(xié)議數(shù)據(jù)包發(fā)送到CAN總線上。反過來，當(dāng)CAN設(shè)備有數(shù)據(jù)要發(fā)送到用戶層時，首先，數(shù)據(jù)發(fā)送到透明網(wǎng)關(guān)由CAN控制器協(xié)議模塊將完整的CAN協(xié)議數(shù)據(jù)包存放在數(shù)據(jù)緩沖區(qū)B?再通知總調(diào)度模塊，由它調(diào)用以太網(wǎng)控制器協(xié)議轉(zhuǎn)換模塊將完整的CAN協(xié)議數(shù)據(jù)包作為應(yīng)用層數(shù)據(jù)封裝起來，再發(fā)送到以太網(wǎng)的應(yīng)用層。其程序結(jié)構(gòu)如圖4所示。
3．1．1 CAN控制器協(xié)議模塊
CAN控制器協(xié)議轉(zhuǎn)換模塊程序主要由SJA1000的寄存器讀程序CANRead（）、寫程序CANWrite（）、初始化程序CANInit（）、發(fā)送程序txdsub（）、接收程序rxdsub（）程序組成。之所以要編寫單獨(dú)的SJA1000的寄存器讀、寫子程序，這是由SX52芯片只有I／O端口決定的。
選用CAN2．0A協(xié)議構(gòu)建CAN總線控制網(wǎng)絡(luò)，對SJA1000的初始化主要完成控制寄存器CR、驗(yàn)收代碼寄存器ACR、驗(yàn)收屏蔽寄存器AMR、總線定時寄存器BTR0，1和輸出控制寄存器OCR的設(shè)置。初始化完成后，由總調(diào)度模塊監(jiān)控SJA1000控制器。當(dāng)CAN總線上有數(shù)據(jù)到達(dá)時，它調(diào)用接收子程序rxdsub（），把這一幀數(shù)據(jù)包存入數(shù)據(jù)緩沖區(qū)B中，然后釋放接收緩沖器。同樣，當(dāng)有按CAN2．0A協(xié)議格式組合成的一幀數(shù)據(jù)報(bào)文在數(shù)據(jù)緩沖區(qū)A中要發(fā)送到CAN總線上去時，總調(diào)度模塊將調(diào)CAN發(fā)送子程序txdsub（）發(fā)送。
3．1．2 以太網(wǎng)控制器協(xié)議轉(zhuǎn)換模塊
以太網(wǎng)控制器協(xié)議轉(zhuǎn)換模塊主要負(fù)責(zé)從UDP數(shù)據(jù)包中解析出完整CAN協(xié)議報(bào)文，存入數(shù)據(jù)緩沖區(qū)A。同時，可能將數(shù)據(jù)緩沖區(qū)B中的完整CAN協(xié)議報(bào)文封裝成UDP數(shù)據(jù)報(bào)，然后將其發(fā)送到以太網(wǎng)上。
在通信傳輸層采用UDP協(xié)議是考慮到CAN協(xié)議數(shù)據(jù)報(bào)為短幀形式（每個數(shù)據(jù)幀最多為8字節(jié)）。如果采用TCP傳輸協(xié)議，要傳輸8字節(jié)CAN協(xié)議數(shù)據(jù)，要先通過3次握手建立連接，再傳輸數(shù)據(jù)，之后還要通過握手釋放連接。這樣傳輸效率對有限的網(wǎng)絡(luò)資源來說無疑是一種浪費(fèi)。而UDP是無連接的傳輸，可以提高網(wǎng)絡(luò)傳輸效率，同時，也減輕網(wǎng)關(guān)的處理任務(wù)。當(dāng)然，UDP傳輸協(xié)議是不可靠的，對于控制網(wǎng)絡(luò)來說，是不允許的。為了提高通信的可靠性，采用了回傳校驗(yàn)機(jī)制。通過實(shí)驗(yàn)測試表明這種方式是行之有效的。
以太網(wǎng)控制器協(xié)議轉(zhuǎn)換模塊主要由以太網(wǎng)卡驅(qū)動、ARP、UDP協(xié)議的若干個API函數(shù)組成，如NICInit（）、NICDMAInit（）、NICInitTxFrame（）、NICSendTxFrame（）、NICReadAgain（）、ARPCheckIfIs（）、ARPSendResponse（）、ARPSendStPacket（）、ICMPProcPktIn（）、UDPAppInit（）、IPGenCheckSum（）、、UDPAppProcPktIn（）、UDPStartPktOut（）和UDPEndPktOut（）等。所使用的變量有：remoteIP[3:0]、myIP[3:0]、UDPRxSrcPortMSB、UDPRxSrcPortLSB、UDPRxDataLenMSB、UDPRxDataLenLSB、UDPTxSrcPortMSB,UDPTxSrcPortLSB、UDPTxDestPortMSB、UDPTxDestPortLSB、DPTxDataLenMSB, UDPTxDataLenLSB等。
系統(tǒng)首次執(zhí)行或復(fù)位時，以太網(wǎng)控制器協(xié)議轉(zhuǎn)換模塊將首先調(diào)用NICInit()和UDPAppInit()等進(jìn)行NIC、ARP、IP、UDP和應(yīng)用程序的初始化。初始化完成后，即進(jìn)入主循環(huán)。在主循環(huán)中，SX52將反復(fù)檢測RTL8019AS是否接收以太網(wǎng)幀。當(dāng)有數(shù)據(jù)被接收時，SX52調(diào)用NICDMAInit()和NICReadAgain()讀入以太網(wǎng)幀首部?再調(diào)用ARPCheckIfIs()判斷接收幀是否為ARP數(shù)據(jù)。若是ARP，則轉(zhuǎn)入ARPSendResponse()和ARPSendStPacket()子程序進(jìn)行ARP處理并發(fā)送響應(yīng)ARP數(shù)據(jù)報(bào)；若不是ARP，則判斷是否為IP數(shù)據(jù)報(bào)。若非IP數(shù)據(jù)報(bào)則清除該以太網(wǎng)幀；當(dāng)所接收幀包含IP數(shù)據(jù)報(bào)時，則需進(jìn)一步判斷是ICMP數(shù)據(jù)報(bào)還是UDP數(shù)據(jù)報(bào)文。若是ICMP數(shù)據(jù)報(bào)則執(zhí)行ICMPProcPktIn()子程序處理ICMP數(shù)據(jù)報(bào)并重發(fā)IP數(shù)據(jù)報(bào)；若數(shù)據(jù)為UDP數(shù)據(jù)報(bào)文，則調(diào)用UDPProcPktIn()子程序。該程序?qū)⒆x入U(xiǎn)DP數(shù)據(jù)報(bào)文首部的數(shù)據(jù)并進(jìn)行相應(yīng)處理，還原出完整的CAN協(xié)議數(shù)據(jù)報(bào)文存入數(shù)據(jù)緩沖區(qū)B中，再通知總調(diào)度程序，由總調(diào)度程序調(diào)用CAN總線控制子程序?qū)AN協(xié)議數(shù)據(jù)報(bào)文發(fā)往CAN總線。
反過來，當(dāng)總調(diào)度程序通知以太網(wǎng)控制器協(xié)議轉(zhuǎn)換模塊將數(shù)據(jù)緩沖區(qū)B中準(zhǔn)備好的CAN協(xié)議數(shù)據(jù)發(fā)送到以太網(wǎng)上時，它將調(diào)用NICInitTxFrame()、UDPStartPktOut()、IPGenCheckSum()、IPStartPktOut()、NICSendTxFrame()、UDPEndPktOut()等子函數(shù)進(jìn)行發(fā)送處理，從而實(shí)現(xiàn)CAN總線到以太網(wǎng)的數(shù)據(jù)傳輸。
3．2 以太網(wǎng)層應(yīng)用程序設(shè)計(jì)
以太網(wǎng)上的通信協(xié)議一般采用TCP／IP協(xié)議。本文采用流行的SOCKET套接字編程，傳輸層協(xié)議選擇UDP（用戶數(shù)據(jù)報(bào)協(xié)議），通過Visual C＋＋編寫用戶層程序。
篇9
關(guān)于網(wǎng)絡(luò)工程實(shí)習(xí)自我鑒定
四個星期的實(shí)習(xí)在轉(zhuǎn)眼中已經(jīng)過去，回想當(dāng)初剛剛開始進(jìn)入實(shí)習(xí)的時候，腦子里是充滿著疑惑與好奇。好奇這次名為網(wǎng)絡(luò)工程實(shí)習(xí)的過程中，我們要開展什么樣的學(xué)習(xí)。而今在不知不覺中實(shí)習(xí)已進(jìn)入了尾聲。
在這次實(shí)習(xí)中，我們從開始的時候只有淺顯的網(wǎng)絡(luò)理論知識，轉(zhuǎn)變?yōu)楦私飧鞣N網(wǎng)絡(luò)器件，在虛擬機(jī)的安裝與配置中，掌握了各種服務(wù)器的安裝與配置，在路由器的配置中，掌握了路由器的基本配置命令以及路由器的各個模式。我們還學(xué)習(xí)了Vlan的劃分、動態(tài)路由的配置、交換機(jī)的配置、VPN的配置等等。實(shí)驗(yàn)中構(gòu)建拓?fù)鋱D，對各個實(shí)驗(yàn)器件進(jìn)行地址規(guī)劃和基礎(chǔ)配置這是每個實(shí)驗(yàn)都必須進(jìn)行的。如果這兩步做不好，就無法連通各個器件，它們之間是無法進(jìn)行通信的。無法進(jìn)行通信，也就意味著后面的各種配置都無法再進(jìn)行下去。所以構(gòu)建網(wǎng)絡(luò)拓?fù)浜瓦M(jìn)行地址規(guī)劃使網(wǎng)絡(luò)連通是進(jìn)行實(shí)驗(yàn)的基礎(chǔ)。在第十四個實(shí)驗(yàn)之前的實(shí)驗(yàn)，對路由器的配置時應(yīng)該在哪種模式下進(jìn)行，指導(dǎo)書里都是給出的;然而，在第十四個實(shí)驗(yàn)之后，路由器的模式就沒有給出了，這是對我們的要求的一個提升，要求我們更熟悉對路由器的配置模式以及配置命令才能完成實(shí)驗(yàn)。
在第十三個實(shí)驗(yàn) 無線網(wǎng)絡(luò)設(shè)計(jì)及配置中第一次用到Serial接口 ，這與之前常用的FastEthernet接口有區(qū)別，在實(shí)驗(yàn)中其中一個路有設(shè)置了clock rate，而另外一個沒有設(shè)置，或設(shè)置里不一樣的參數(shù)，導(dǎo)致兩個路由器無法通信，后來在同學(xué)的指導(dǎo)下找出了問題所在，從而解決了問題。在DHCP中繼實(shí)驗(yàn)中，由于不了解DHCP中繼的具體實(shí)現(xiàn)過程以及沒有弄明白地址池的配置所以遇到了麻煩，連接好網(wǎng)絡(luò)并連通后無法自動獲取IP地址雖然在同學(xué)的協(xié)助下完成了實(shí)驗(yàn)，但是始終沒有很清晰的實(shí)驗(yàn)思路。
實(shí)習(xí)中所涉及的內(nèi)容都是比較接近實(shí)際的，很有實(shí)際意義，特別是VPN的設(shè)計(jì)及配置部分，對認(rèn)識現(xiàn)在的網(wǎng)絡(luò)構(gòu)建都是有重大的指導(dǎo)意義的，它將我們之前學(xué)的理論知識與實(shí)際聯(lián)系起來。加強(qiáng)了我們對知識的運(yùn)用的能力。
在實(shí)驗(yàn)中除了學(xué)會了安裝虛擬機(jī)以為，還掌握了思科的仿真軟件的實(shí)驗(yàn)，雖然是用仿真軟件，并沒有接觸到實(shí)物，但是軟件的高仿真性讓我們對實(shí)驗(yàn)充滿著樂趣。實(shí)習(xí)中對各種網(wǎng)絡(luò)協(xié)議的內(nèi)容都需要我們?nèi)チ私狻⒍蠋熃o出的指導(dǎo)書里面，有些知識并不是很詳細(xì)，這就培養(yǎng)了我們自己查看資料的能力。
通過這次實(shí)習(xí)，使我對網(wǎng)絡(luò)知識的興趣有了更大的提升，這對我以后的學(xué)習(xí)中也是至關(guān)重要的。
網(wǎng)絡(luò)工程實(shí)習(xí)自我鑒定閱讀
我實(shí)習(xí)的單位是學(xué)院，這是一所由市教委、(集團(tuán))公司與德國基金會合作的一所探索、實(shí)踐德國“雙元制”職業(yè)教育模式的全日制中等專業(yè)學(xué)校。我在學(xué)校里主要是負(fù)責(zé)校園內(nèi)網(wǎng)的管理，其涉及到校園網(wǎng)網(wǎng)站的正常登陸和訪問，校園內(nèi)各系部主機(jī)是否正常互聯(lián)，有無被病毒感染、傳播。使得校園網(wǎng)內(nèi)的計(jì)算機(jī)能夠正常運(yùn)行，做好校園網(wǎng)的管理和維護(hù)工作。
從學(xué)生到實(shí)習(xí)工程師，短短幾個月的工作過程使我受益匪淺。 不僅是在專業(yè)知識方面，最主要是在為人處事方面。社會在加速度地發(fā)生變化，對人才的要求也越來越高，要用發(fā)展的眼光看問題，得不斷提高思想認(rèn)識，完善自己。作為一名it從業(yè)者，所受的社會壓力將比其他行業(yè)更加沉重，要學(xué)會創(chuàng)新求變，以適應(yīng)社會的需要。在單位里，小到計(jì)算機(jī)的組裝維修，大到服務(wù)器的維護(hù)與測試，都需要一個人獨(dú)立完成。可以說，近3個月的工作使我成長了不少，從中有不少感悟，下面就是我的一點(diǎn)心得：
第一是要真誠：你可以偽裝你的面孔你的心，但絕不可以忽略真誠的力量。 第一天去網(wǎng)絡(luò)中心實(shí)習(xí)，心里不可避免的有些疑惑：不知道老師怎么樣，應(yīng)該去怎么做啊，要去干些什么呢等等吧!踏進(jìn)辦公室，只見幾個陌生的臉孔。我微笑著和他們打招呼。從那天起，我養(yǎng)成了一個習(xí)慣，每天早上見到他們都要微笑的說聲：“老師早”，那是我心底真誠的問候。我總覺得，經(jīng)常有一些細(xì)微的東西容易被我們忽略，比如輕輕的一聲問候，但它卻表達(dá)了對老師同事對朋友的尊重關(guān)心，也讓他人感覺到被重視與被關(guān)心。僅僅幾天的時間，我就和老師們打成一片，很好的跟他們交流溝通學(xué)習(xí)，我想，應(yīng)該是我的真誠，換得了老師的信任。他們把我當(dāng)朋友也愿意指導(dǎo)我，愿意分配給我任務(wù)。
第二是溝通：要想在短暫的實(shí)習(xí)時間內(nèi)，盡可能多的學(xué)一些東西，這就需要跟老師有很好的溝通，加深彼此的了解 ，剛到網(wǎng)絡(luò)中心，老師并不了解你的工作學(xué)習(xí)能力，不清楚你會做那些工作，不清楚你想了解的知識，所以跟老師很好的溝通是很必要的。同時我覺得這也是我們將來走上社會的一把不可缺少的鑰匙。通過溝通了解，老師我我有了大體了解，邊有針對性的教我一些知識，我對網(wǎng)絡(luò)部線，電腦硬件安裝，網(wǎng)絡(luò)故障排除，工作原理應(yīng)用比叫感興趣，所以老師就讓我獨(dú)立的完成校內(nèi)大小部門的網(wǎng)絡(luò)檢修與電腦故障排除工作。
如秘書處的辦公室內(nèi)局域網(wǎng)的組件，中心服務(wù)機(jī)房的服務(wù)器監(jiān)測等，直接或間接保證了校園網(wǎng)的正常運(yùn)行和使用，在這方面的工作中，真正學(xué)到了計(jì)算機(jī)教科書上所沒有或者真正用到了課本上的知識，鞏固了舊知識，掌握了新知識，甚至在實(shí)踐中****了書本上舊有的不合實(shí)際的知識，這才真正體現(xiàn)了知識的真正價值，學(xué)以致用。
第三是激情與耐心： 激情與耐心，就像火與冰，看似兩種完全不同的東西，卻能碰撞出最美麗的火花。在中心時，老師就跟我說，想做電腦網(wǎng)絡(luò)這一塊，激情與耐心必不可少，在產(chǎn)品更新方面，這一行業(yè)就像做新聞工作，補(bǔ)斷的更新，這就需要你有激情，耐心的去不斷的學(xué)習(xí)提高自己的專業(yè)水平。在一些具體的工作當(dāng)中也是這樣的：記得剛來學(xué)校實(shí)習(xí)的時候老師安排我去綜合部安裝win98操作系統(tǒng)，我本想對我來說是非常簡單的事，可沒想到出現(xiàn)了很多問題，開始是硬件問題：光驅(qū)不能用使我在一開始安裝系統(tǒng)時就出現(xiàn)了急躁的情緒，然后順利解決后，98系統(tǒng)的驅(qū)動問題又讓我大傷腦筋!
從一開始的u驅(qū)動慢慢的安裝，再通過硬件監(jiān)測軟件查看硬件型號， 到最后把系統(tǒng)安裝成功，用了整整兩天的時間，通過自己的捉摸，調(diào)試，自此，我算是真正的搞明白的計(jì)算機(jī)的硬件安裝，維護(hù)和更新，接著我又進(jìn)行了各種計(jì)算機(jī)操作系統(tǒng)的反復(fù)安裝調(diào)試，一遍又一遍的調(diào)試安裝，自然有些煩，但我用我的熱情耐心克服這些困難，問老師，查資料，一個個問題迎刃而解，自己在這方面的知識得到了充實(shí)。這些在平常的書本上僅僅是獲得感性的認(rèn)識在這里真的實(shí)踐了，才算是真正的掌握了，也讓我認(rèn)識到了自己的不足，告誡自己，不管做什么，切忌眼高手低，要善于鉆研。
還有我感觸比較深的就是查看log日志記錄，因?yàn)榉?wù)器的維護(hù)是復(fù)雜又艱辛的，既要保障物理安全又要保證系統(tǒng)安全，這就需要通過查詢log日志記錄，每一分鐘的服務(wù)器狀況都有l(wèi)og日志記錄，而且它一是數(shù)據(jù)量大、二是有大量無用信息，所以查看log使非常“痛苦”的事情。像這些工作我深深地感覺到?jīng)]有激情與耐心是做不好的。
網(wǎng)絡(luò)工程實(shí)習(xí)個人自我鑒定
一、實(shí)習(xí)的基本概況
時間：20xx年x月x日—20xx年x月x日
地點(diǎn)：E607
(一)理論指導(dǎo)
1、 IEEE802標(biāo)準(zhǔn)和以太網(wǎng)：
㈠ OSI模型和TCP/IP協(xié)議：OSI模型中包括物理層、數(shù)據(jù)鏈路層、網(wǎng)絡(luò)層、傳輸層、會話層、表示層、應(yīng)用層。㈡ IEEE802參考模型：物理層被分為上下兩個子層：對電纜介質(zhì)的說明;介質(zhì)訪問單元(MAU)。數(shù)據(jù)鏈路層也被分為兩個子層：媒體訪問控制子層(MAC);邏輯鏈路控制子層(LLC)。㈢ 以太網(wǎng)簡介：①以太網(wǎng)的物理地址可分為三類：單播地址、廣播地址和多播地址。② 以太網(wǎng)訪問模式：CSMA/CD③ 以太網(wǎng)的MAC幀格式：一種是DIX Ethernet V2標(biāo)準(zhǔn)，另一種是IEEE的802.3標(biāo)準(zhǔn)。兩種幀格式可以在同一以太網(wǎng)絡(luò)共存。兩種幀格式都具有7個域：前導(dǎo)碼、幀首定界符、目的MAC地址、源MAC地址、協(xié)議類型或數(shù)據(jù)長度、數(shù)據(jù)、幀校驗(yàn)序列。
2、地址解析協(xié)議(ARP)
㈠ 物理地址與邏輯地址 ㈡ ARP協(xié)議簡介 ㈢ ARP報(bào)文格式 ㈣ ARP封裝 ㈤ ARP的運(yùn)行過程 ㈥ ARP高速緩存 ㈦ ARP ㈧ 協(xié)議棧實(shí)現(xiàn)代碼解析 ㈨ 各模塊推薦流程：(1) ARP請求發(fā)送流程(2)輸入ARP數(shù)據(jù)包處理流程
3、網(wǎng)絡(luò)協(xié)議(IP)
㈠ IP協(xié)議簡介
㈡ ①IP地址：地址空間 。
②IP地址的表示方法 ：IP地址有三種常用的表示方法：二進(jìn)制表示方法、點(diǎn)分十進(jìn)制表示方法和十六進(jìn)制表示方法。
③IP地址的分類： IP地址分成5類：A類，B類，C類，D類和E類。其中A類、B類和C類地址是基本的Internet地址，是用戶使用的地址，D類地址用于廣播，E類地址為保留地址。
④網(wǎng)絡(luò)號和主機(jī) ：在分類編址的A類，B類和C類地址中，IP地址可劃分為網(wǎng)絡(luò)號(net-id)和主機(jī)號(host-id)。這兩部分長度都是可變的，取決于地址的類型。
⑤地址類和地址塊：A類地址共分為128個地址塊，每個地址塊都包含有16777216個地址。這表明要使用這類地址的機(jī)構(gòu)一定是一個非常龐大的機(jī)構(gòu)。B類地址共劃分為16384個地址塊，每個地址塊都包含有65536個地址。 C類地址共劃分為2097152個地址塊，每個地址塊都包含有256個地址。D類地址只有一個地址塊。它用來進(jìn)行多播。E類地址只有一個地址塊。它是保留地址。
㈢ 特殊的IP地址：1) 網(wǎng)絡(luò)地址：主機(jī)號為全“0”的IP地址不分配給任何主機(jī)，而是作為網(wǎng)絡(luò)本身的標(biāo)識。
2) 直接廣播地址：主機(jī)號為全“1”的IP地址不分配給任何主機(jī)，用作廣播地址。
3) 有限廣播地址：32位為全“1”的IP地址(255.255.255.255)稱為有限廣播地址。
4) 主機(jī)本身地址：32位全“0”的IP地址(0.0.0.0)稱為主機(jī)本身地址。
5) 回環(huán)地址：127.0.0.1稱為回環(huán)地址，常用于本機(jī)上軟件測試和本機(jī)上網(wǎng)絡(luò)應(yīng)用程序之間的通信地址。
㈣子網(wǎng)劃分
㈤IP報(bào)文格式
㈥IP封裝
㈦IP數(shù)據(jù)報(bào)分片
㈧IP數(shù)據(jù)報(bào)校驗(yàn)和
4、用戶數(shù)據(jù)報(bào)協(xié)議(UDP)
UDP協(xié)議簡介：UDP(用戶數(shù)據(jù)報(bào)協(xié)議)，主要用來支持那些需要在計(jì)算機(jī)之間傳輸數(shù)據(jù)的網(wǎng)絡(luò)應(yīng)用。包括網(wǎng)絡(luò)視頻會議系統(tǒng)在內(nèi)的眾多的客戶/服務(wù)器模式的網(wǎng)絡(luò)應(yīng)用都需要使用UDP協(xié)議。UDP報(bào)文格式：每個UDP報(bào)文稱為一個用戶數(shù)據(jù)報(bào)(User Datagram)，用戶數(shù)據(jù)報(bào)分為兩個部分：UDP首部和UDP數(shù)據(jù)。首部被分為四個16位的字段，分別代表源端口號﹑目的端口號﹑報(bào)文的長度以及UDP校驗(yàn)和。
UDP應(yīng)用：1)UDP適用于這樣的進(jìn)程，它需要簡單的請求——響應(yīng)通信，而較少考慮流量控制和差錯控制。對于需要傳送成塊數(shù)據(jù)的進(jìn)程，如FTP，則通常不使用UD;2)UDP適用于具有內(nèi)部流量控制和差錯控制機(jī)制的進(jìn)程;3)對多播和廣播來說，UDP是個比較合適的傳輸層協(xié)議;;4)UDP可用于管理進(jìn)程，如SNMP協(xié)議;5)UDP可用于某些路由選擇更新協(xié)議。
5、傳輸控制協(xié)議(TCP)
TCP(傳輸控制協(xié)議)協(xié)議是TCP/IP協(xié)議族中的面向連接的、可靠的傳輸層協(xié)議。
6、域名服務(wù)(DNS)
DNS(域名服務(wù))是一種能夠完成從域名到地址或從地址到域名的映射系統(tǒng)。使用DNS，計(jì)算機(jī)用戶可以間接的通過域名來完成通信。
7、超文本傳輸協(xié)議(HTTP)
HTTP(超文本傳輸協(xié)議)主要用于訪問萬維網(wǎng)上的數(shù)據(jù)。HTTP在熟知端口80上使用TCP服務(wù)。
8、遠(yuǎn)程登錄與文件傳輸協(xié)議(TELNET與FTP )
FTP(文件傳輸協(xié)議)提供了一種通過TCP傳送文件的方法，可以將一個文件從一個系統(tǒng)復(fù)制到另一個系統(tǒng)中。
(二)實(shí)習(xí)過程或步驟
1、領(lǐng)略真實(shí)的MAC幀：
將主機(jī)A和B作為一組，主機(jī)B啟動協(xié)議分析器，新建捕獲窗口進(jìn)行數(shù)據(jù)捕獲并設(shè)置過濾條件(提取ICMP協(xié)議);主機(jī)A ping 主機(jī)B，察看主機(jī)B協(xié)議
分析器捕獲的數(shù)據(jù)包，分析MAC幀格式。然后將主機(jī)B的過濾器恢復(fù)為默認(rèn)狀態(tài)。實(shí)驗(yàn)結(jié)果為: MAC幀格式：
其中目的MAC地址：00142A—503336 ;源MAC地址：00142A—522C15;型或數(shù)據(jù)長度：0800
2、ARP報(bào)文
將主機(jī)A、B、C、D、E、F作為一組進(jìn)行實(shí)驗(yàn)。
①主機(jī)B在命令行方式下輸入staticroute_config命令，開啟靜態(tài)路由服務(wù)。
②主機(jī)A、B、C、D、E、F在命令行下運(yùn)行“arp -d”命令，清空ARP高速緩存。
③機(jī)A、B、C、D、E、F重新啟動協(xié)議分析器，打開捕獲窗口進(jìn)行數(shù)據(jù)捕獲并設(shè)置過濾條件(提取ARP、ICMP)。
④主機(jī)A ping 主機(jī)E(172.16.0.2)。
⑤主機(jī)A、B、C、D、E、F停止數(shù)據(jù)捕獲，察看協(xié)議分析器中采集到的ARP報(bào)文。通過實(shí)驗(yàn)了解到：單一ARP請求報(bào)文不能跨越子網(wǎng)進(jìn)行地址解析，ARP報(bào)文的存活空間只限在子網(wǎng)內(nèi)。因?yàn)锳RP報(bào)文的請求是在網(wǎng)關(guān)下的數(shù)據(jù)請求，脫離子網(wǎng)ARP報(bào)文也就自動失效，并且ARP請求是以廣播的方式進(jìn)行，而廣播報(bào)文不能跨越子網(wǎng)。ARP地址解析在跨越子網(wǎng)的通信中所起到的作用：作用是解析網(wǎng)關(guān)的MAC地址，ARP本身無法跨躍不同網(wǎng)段。當(dāng)數(shù)據(jù)要發(fā)往外部網(wǎng)絡(luò)時，通常是首先使用ARP請求網(wǎng)關(guān)路由器的MAC地址，之后將數(shù)據(jù)發(fā)往網(wǎng)關(guān)路由器，由網(wǎng)關(guān)路由器進(jìn)行轉(zhuǎn)發(fā)。
3、編輯并發(fā)送IP數(shù)據(jù)報(bào)：
將主機(jī)A、B、C、D、E、F作為一組進(jìn)行實(shí)驗(yàn)。
①主機(jī)B在命令行方式下輸入staticroute_config命令，開啟靜態(tài)路由服務(wù)。
②主機(jī)A啟動協(xié)議編輯器，編輯一個IP數(shù)據(jù)報(bào)，其中：MAC層：目的MAC地址：主機(jī)B的MAC地址(對應(yīng)于172.16.1.1接口的MAC) 源MAC地址：主機(jī)A的MAC地址。協(xié)議類型或數(shù)據(jù)長度：0800。IP層：總長度：IP層長度。生存時間：128。源IP地址：主機(jī)A的IP地址(172.16.1.2)。目的IP地址：主機(jī)E的IP地址(172.16.0.2)。校驗(yàn)和：在其它所有字段填充完畢后計(jì)算并填充。自定義字段：數(shù)據(jù)：填入大于1字節(jié)的用戶數(shù)據(jù)。
③在主機(jī)B(兩塊網(wǎng)卡分別打開兩個捕獲窗口)、E上啟動協(xié)議分析器，設(shè)置過濾條件(提取IP協(xié)議)，開始捕獲數(shù)據(jù)。
④主機(jī)A發(fā)送第1步中編輯好的報(bào)文。
⑤主機(jī)B、E停止捕獲數(shù)據(jù)，在捕獲到的數(shù)據(jù)中查找主機(jī)A所發(fā)送的數(shù)據(jù)報(bào)。
⑥將第1步中主機(jī)A所編輯的報(bào)文的“生存時間”設(shè)置為1，重新計(jì)算校驗(yàn)和。
⑦主機(jī)B、E重新開始捕獲數(shù)據(jù)。
⑧主機(jī)A發(fā)送第5步中編輯好的報(bào)文。
⑨主機(jī)B、E停止捕獲數(shù)據(jù)，在捕獲到的數(shù)據(jù)中查找主機(jī)A所發(fā)送的數(shù)據(jù)報(bào)。觀察實(shí)驗(yàn)過程得：在實(shí)驗(yàn)過程中主機(jī)A所編輯的報(bào)文，經(jīng)過主機(jī)B到達(dá)主機(jī)E后，報(bào)文數(shù)據(jù)發(fā)生變化，變化的原因是：他們不在一個子網(wǎng)上。主機(jī)B能接受到A發(fā)送的報(bào)文，主機(jī)E不能，因?yàn)榇藞?bào)文的生存時間太短，致使主機(jī)E無法捕獲此報(bào)文。
4、UDP單播通信
將主機(jī)A、B、C、D、E、F作為一組進(jìn)行實(shí)驗(yàn)。
①主機(jī)B、C、D、E、F上啟動“實(shí)驗(yàn)平臺工具欄中的UDP工具”，作為服務(wù)器端，監(jiān)聽端口設(shè)置為2483，“創(chuàng)建”成功。
②主機(jī)C、E上啟動協(xié)議分析器開始捕獲數(shù)據(jù)，并設(shè)置過濾條件(提取UDP協(xié)議)。
③主機(jī)A上啟動“實(shí)驗(yàn)平臺工具欄中的UDP工具”，作為客戶端，以主機(jī)C的IP為目的IP地址，以2483為端口，填寫數(shù)據(jù)并發(fā)送。
④察看主機(jī)B、C、D、E、F上的“UDP工具”接收的信息。
⑤察看主機(jī)C協(xié)議分析器上的UDP報(bào)文
⑥主機(jī)A上使用協(xié)議編輯器向主機(jī)E發(fā)送UDP報(bào)文，其中： 目的MAC地址：E的MAC地址;目的IP地址：主機(jī)E的IP地址;目的端口：2483;校驗(yàn)和：0發(fā)送此報(bào)文 ⑦主機(jī)B、C、D、E、F關(guān)閉服務(wù)端，主機(jī)A關(guān)閉客戶端。從實(shí)驗(yàn)中得出結(jié)論：UDP是一個無連接協(xié)議，傳輸數(shù)據(jù)之前源端和終端不建立連接，當(dāng)它想傳送時就簡單地去抓取來自應(yīng)用程序的數(shù)據(jù)，并盡可能快地把它扔到網(wǎng)絡(luò)上。在發(fā)送端，UDP傳送數(shù)據(jù)的速度僅僅是受應(yīng)用程序生成數(shù)據(jù)的速度、計(jì)算機(jī)的能力和傳輸帶寬的限制;在接收端，UDP把每個消息段放在隊(duì)列中，應(yīng)用程序每次從隊(duì)列中讀一個消息段。
(2) 由于傳輸數(shù)據(jù)不建立連接，因此也就不需要維護(hù)連接狀態(tài)，包括收發(fā)狀態(tài)等，因此一臺服務(wù)機(jī)可同時向多個客戶機(jī)傳輸相同的消息。
5、頁面訪問
①將主機(jī)A和B作為一組
② 主機(jī)A清空IE緩存。
③主機(jī)B啟動協(xié)議分析器開始捕獲數(shù)據(jù)，并設(shè)置過濾條件(提取HTTP協(xié)議)。
④主機(jī)A啟動IE瀏覽器，在“地址”框中輸入服務(wù)器的ip/experiment，并連接，服務(wù)器IP默認(rèn)為172.16.0.253。主機(jī)B停止捕獲數(shù)據(jù)，分析捕獲到的數(shù)據(jù)。分析實(shí)驗(yàn)可知，實(shí)驗(yàn)中使用http的get方法 (從服務(wù)器請求一個文檔)。作用：請求獲取Request-URI所標(biāo)識的資源。
6、使用TCP連接工具與服務(wù)器進(jìn)行命令交互
將主機(jī)A和B作為一組;1、主機(jī)B啟動協(xié)議分析器開始捕獲數(shù)據(jù)并設(shè)置過濾條件(提取TCP協(xié)議)。2、主機(jī)A啟動TCP工具連接FTP服務(wù)器。
(1)主機(jī)A啟動“實(shí)驗(yàn)平臺工具欄中的TCP工具”。①選中“客戶端”單選框。②在“地址”文本框中填入FTP服務(wù)器的IP地址。③在“端口”文本框中填入主機(jī)FTP服務(wù)器進(jìn)程的端口號21。④點(diǎn)擊“連接”按鈕，建立與FTP服務(wù)器的TCP連接。
(2)連接成功(將該次連接記為w_cmd)，在接收窗口會顯示成功連接的信息。然后在發(fā)送窗口發(fā)送數(shù)據(jù)，觀察服務(wù)器回復(fù)的信息。由實(shí)驗(yàn)總結(jié)出FTP服務(wù)器是使用什么方式創(chuàng)建數(shù)據(jù)連接的。
二、實(shí)習(xí)感受
(一)成績與收獲
經(jīng)過為期幾周的網(wǎng)絡(luò)工程實(shí)習(xí)我對IPV4協(xié)議中的各個協(xié)議有了更深入的了解。在實(shí)驗(yàn)一中掌握了什么是IEEE802標(biāo)準(zhǔn)和以太網(wǎng)、太網(wǎng)的報(bào)文格式;掌握MAC地址的作用;MAC廣播地址的作用;LLC幀報(bào)文格式;協(xié)議編輯器和協(xié)議分析器的使用方法;協(xié)議棧發(fā)送和接收以太網(wǎng)數(shù)據(jù)幀的過程。通過動手實(shí)驗(yàn)捕獲數(shù)據(jù)包分析出MAC幀格式。同時學(xué)會了編寫LLC幀，更加明白LLC幀是由目的MAC地址、源MAC地址、協(xié)議類型和數(shù)據(jù)長度、用戶定義數(shù)據(jù)/數(shù)據(jù)字段等組成。在實(shí)驗(yàn)三中熟練掌握了IP校驗(yàn)和計(jì)算方法，可手動計(jì)算也可使用協(xié)議編輯器的“自動計(jì)算”校驗(yàn)和。
同時還懂得受限廣播地址的作用：受限的廣播地址是255.255.255.255。該地址用于主機(jī)配置過程中IP數(shù)據(jù)報(bào)的目的地址，此時，主機(jī)可能還不知道它所在網(wǎng)絡(luò)的網(wǎng)絡(luò)掩碼，甚至連它的IP地址也不知道。在任何情況下，路由器都不轉(zhuǎn)發(fā)目的地址為受限的廣播地址的數(shù)據(jù)報(bào)，這樣的數(shù)據(jù)報(bào)僅出現(xiàn)在本地網(wǎng)絡(luò)中。最重要的是，在學(xué)習(xí)的過程中組內(nèi)成員互相幫助，遇到困難大家共同解決，真正認(rèn)識到團(tuán)結(jié)協(xié)作精神的重要，同時我們積極利用網(wǎng)絡(luò)搜集大量資料并從中摘取與自己課題相關(guān)的內(nèi)容，這樣在研究過程中又增加了不少課外知識，對大一學(xué)過的網(wǎng)絡(luò)原理是個很好的復(fù)習(xí)和回顧。另外，通過實(shí)習(xí)我發(fā)現(xiàn)自己目前掌握的東西還是少，在今后的學(xué)習(xí)中要不斷學(xué)習(xí)不斷總結(jié)，必須拓寬自己的知識面、開闊自己的視野。
(二)問題與不足
篇10
關(guān)鍵字 TCP/IP；教學(xué)平臺；數(shù)據(jù)包截獲；包過濾；協(xié)議分析
1 引言
TCP/IP協(xié)議族是計(jì)算機(jī)網(wǎng)絡(luò)軟件組成的核心部分，同時也是很抽象和難以掌握的部分。目前，對于TCP/IP協(xié)議族的研究，一般是基于協(xié)議應(yīng)用本身的研究，也就是研究如何將指定的協(xié)議嵌入產(chǎn)品，使該產(chǎn)品能夠支持上層產(chǎn)品應(yīng)用該協(xié)議或自身產(chǎn)品對該協(xié)議的應(yīng)用。作為高校計(jì)算機(jī)網(wǎng)絡(luò)課程中所介紹的協(xié)議，對于很大一部分老師和同學(xué)來講，都還只是停留在了解和使用這個協(xié)議上，并沒有深入到協(xié)議本身的原理中去。
本系統(tǒng)通過對TCP/IP協(xié)議族的研究，將其中的部分常用協(xié)議（如TCP、IP、UDP等）的具體結(jié)構(gòu)、工作方式和工作過程，用人機(jī)交互方式和圖形化界面形象生動展現(xiàn)在學(xué)生面前。教學(xué)中通過對本套系統(tǒng)的利用，可以達(dá)到提高學(xué)習(xí)效率，改善學(xué)習(xí)效果，使學(xué)生對協(xié)議的學(xué)習(xí)不僅達(dá)到對使用方法的了解，同時達(dá)到對協(xié)議結(jié)構(gòu)以及工作原理的領(lǐng)悟，使學(xué)生對網(wǎng)絡(luò)課程的學(xué)習(xí)達(dá)到一個新的層次。
2 系統(tǒng)設(shè)計(jì)依據(jù)
2.1 設(shè)計(jì)思路及設(shè)計(jì)目的
本系統(tǒng)開發(fā)的目的是針對大學(xué)本科學(xué)生對《計(jì)算機(jī)網(wǎng)絡(luò)》課程中關(guān)于網(wǎng)絡(luò)傳輸以及協(xié)議原理部分的學(xué)習(xí)，使學(xué)生可以自己定制傳輸內(nèi)容，并親眼看到所有內(nèi)容傳輸?shù)倪^程形式等，增強(qiáng)對協(xié)議結(jié)構(gòu)的記憶，并可以親自動手控制協(xié)議的狀態(tài)，達(dá)到對協(xié)議原理及工作方式的深入了解。
2.2 系統(tǒng)設(shè)計(jì)中所用到的原理
2.2.1 數(shù)據(jù)傳輸?shù)脑?/p>
在基于TCP/IP的網(wǎng)絡(luò)中，應(yīng)用層的數(shù)據(jù)傳輸通常是基于TCP或者UDP協(xié)議的，而兩種協(xié)議最大的區(qū)別在于是否面向連接。
在面向連接的TCP協(xié)議中，傳輸數(shù)據(jù)首先要求傳輸雙方建立一條虛電路連接。通信雙方通過自身的sockets（或稱為通訊端點(diǎn)） 建立sockets的連接，從而達(dá)到傳輸?shù)哪康摹?/p>
UDP是一種是無連接的用戶數(shù)據(jù)報(bào)傳輸協(xié)議，與TCP操作不同，計(jì)算機(jī)間并不需要建立一個明確、可靠的鏈路，一個UDP應(yīng)用可同時作為客戶方或服務(wù)器方。UDP向應(yīng)用程序提供了一種發(fā)送封裝的原始IP數(shù)據(jù)包的方法。雖然UDP數(shù)據(jù)報(bào)只能提供不可靠的交付，但在許多方面UDP可以簡化連接，這樣可以避免建立和釋放連接的麻煩。
2.2.2 網(wǎng)絡(luò)包截獲的原理
通常在同一個網(wǎng)段的所有網(wǎng)絡(luò)接口都有訪問在物理媒體上傳輸?shù)乃袛?shù)據(jù)的能力，而每個網(wǎng)絡(luò)接口都還應(yīng)該有一個硬件地址，該硬件地址不同于網(wǎng)絡(luò)中存在的其他網(wǎng)絡(luò)接口的硬件地址，同時，每個網(wǎng)絡(luò)至少還要一個廣播地址（代表所有的接口地址），在正常情況下，一個合法的網(wǎng)絡(luò)接口應(yīng)該只響應(yīng)這樣的兩種數(shù)據(jù)幀：
（1）幀的目標(biāo)區(qū)域具有和本地網(wǎng)絡(luò)接口相匹配的硬件地址。
（2）幀的目標(biāo)區(qū)域具有"廣播地址"。
在接受到上面兩種情況的數(shù)據(jù)包時，網(wǎng)卡通過CPU產(chǎn)生一個硬件中斷，該中斷能引起操作系統(tǒng)注意，然后將幀中所包含的數(shù)據(jù)傳送給系統(tǒng)進(jìn)一步處理。
本系統(tǒng)中對數(shù)據(jù)幀的截獲就是利用將本地網(wǎng)卡模式設(shè)成混雜（promiscuous）狀態(tài)的機(jī)制，混雜模式就是接收所有經(jīng)過網(wǎng)卡的數(shù)據(jù)包，包括不是發(fā)給本機(jī)的包。當(dāng)網(wǎng)卡處于這種"混雜"方式時，使網(wǎng)卡對所有遭遇到的每一個幀都產(chǎn)生一個硬件中斷以便提醒操作系統(tǒng)處理流經(jīng)該物理媒體上的每一個報(bào)文包。
2.2.3 協(xié)議狀態(tài)跳轉(zhuǎn)的原理