udp協議范文
時間：2023-03-25 02:16:33
導語：如何才(cai)能寫好一篇(pian)udp協議(yi)，這就(jiu)需(xu)要(yao)搜集整理更多的(de)資料和(he)文獻，歡迎閱(yue)讀由(you)公務員之家整理的(de)十篇(pian)范(fan)文，供你借鑒。
篇1
關(guan)鍵詞(ci):用戶數(shu)據(ju)報(bao)協議(yi);通信;報(bao)文分析;Sniffer
中(zhong)圖分類號(hao):TP312 文(wen)(wen)獻標識碼:A 文(wen)(wen)章編號(hao):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體系結構中一種無連接的傳輸層協議,提供面向事務(wu)(wu)的(de)簡單不可靠信息傳送服務(wu)(wu)。UDP 協(xie)議(yi)是(shi) IP 協(xie)議(yi)與上層協(xie)議(yi)的(de)接口(kou),用端口(kou)號(hao)分(fen)別為(wei)運行在同一設(she)備上的(de)多個應用程序(xu)提供服務(wu)(wu)。它定義在IETF RFC 768中[1]。
UDP是分發(fa)信(xin)(xin)息的理想協議(yi)(yi),適用于追求效率且不需(xu)要額外(wai)可靠機制的情形,如(ru)音(yin)、視頻流媒體(ti)分發(fa)、高(gao)層協議(yi)(yi)或應用程序提供錯誤(wu)和(he)流控制功能時的快速數據分發(fa)。 UDP服(fu)務(wu)于很多知名應用,如(ru)網絡文件系(xi)(xi)統(tong)(tong)(NFS)、簡單網絡管理協議(yi)(yi)(SNMP)、域名系(xi)(xi)統(tong)(tong)(DNS)以及簡單文件傳輸(shu)系(xi)(xi)統(tong)(tong)(TFTP)、動態主機配置協議(yi)(yi)(DHCP)、路由(you)信(xin)(xin)息協議(yi)(yi)(RIP)等。
1 UDP協議使用
在Windows下使(shi)用(yong)UDP不需要實現(xian)RFC 768中定義的(de)(de)UDP細節,封(feng)閉(bi)的(de)(de)Windows操作系統為(wei)用(yong)戶(hu)實現(xian)了協議,以(yi)動(dong)態鏈接庫及API的(de)(de)形式提供(gong)給用(yong)戶(hu)程(cheng)序調用(yong)。這(zhe)種方式方便(bian)了程(cheng)序設計,但也(ye)阻(zu)止了用(yong)戶(hu)對網絡協議的(de)(de)更(geng)深理解。為(wei)了更(geng)加(jia)深入(ru)研究UDP有(you)必要對傳輸報文流進(jin)行分析;為(wei)了更(geng)好的(de)(de)分析,需要實現(xian)一個使(shi)用(yong)UDP的(de)(de)通(tong)信(xin)程(cheng)序。
在windows下選用(yong)VC6.0編譯(yi)器。服務器端代碼如(ru)下:
#include //基本(ben)輸(shu)入輸(shu)出庫
#include //網(wang)絡API函數庫
#pragma comment (lib,"WS2_32.lib")/*將WS2_32.lib加(jia)入(ru)鏈(lian)接,不用再為這個鏈(lian)接文(wen)件設置鏈(lian)接選項了*/
void main()
{ WORD wVersionRequested;
WSADATA wsaData;
int err;
wVersionRequested = MAKEWORD( 1, 1 );
err = WSAStartup( wVersionRequested, &wsaData );
if ( err != 0 ) {
return; /* 處理找不到 WinSock DLL.*/}
/* 確認(ren) WinSock DLL 支持的(de)版本 */
if ( LOBYTE( wsaData.wVersion ) != 1 ||HIBYTE( wsaData.wVersion ) != 1 ) {
WSACleanup( ); return;
}/* [3]以上代碼為MSDN提(ti)供的(de)設計(ji)windows下(xia)網絡程序的(de)標準方法*/
SOCKET sockSrv=socket(AF_INET,SOCK_DGRAM,0);/*AF_INET因(yin)特網地(di)址族UDP, TCP, 等.SOCK_DGRAM 基于upd的套接字(zi)。*/
SOCKADDR_IN addrSrv;
addrSrv.sin_addr.S_un.S_addr=htonl(INADDR_ANY);/*htonl主機字節(jie)序變為網絡字節(jie)序*/
addrSrv.sin_family=AF_INET;
addrSrv.sin_port=htons(6666);
err=bind(sockSrv,(SOCKADDR *)&addrSrv,sizeof(SOCKADDR)); /*綁定(ding)主機從(cong)6666端口接受數(shu)據*/
if ( err != 0 ) {
return; /* 處理幫(bang)定異常*/
} SOCKADDR_IN addrClient;
int len=sizeof(sockaddr);
char recvBuff[200];//接收緩存
char sendBuff[200];//發送緩存
char tempBuff[200];//暫時緩存
while (1){
recvfrom(sockSrv,recvBuff,200,0,(SOCKADDR*)&addrClient,&len); //接收數據
if('E'==recvBuff[0])
{sendto(sockSrv,"E",strlen("E"),0,(SOCKADDR*)&addrClient,len); //發送數據
printf("Communications end\n");
break;
}sprintf(tempBuff,"Recieve From IP %s :%s ",inet_ntoa(addrClient.sin_addr),recvBuff); //格(ge)式化
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();
}客戶端(duan)程序頭文(wen)件及(ji)socket初始化和服務器端(duan)一樣,不同的是socket函數的使用(yong)。
//頭文(wen)件和服務器端一樣
void main()
{…
//初(chu)始化和服務(wu)器端一樣
/* 以(yi)上代碼為(wei)MSDN提(ti)供的設計windows下(xia)網(wang)絡程(cheng)序的標準方法,*/
SOCKET sockCleit=socket(AF_INET,SOCK_DGRAM,0);//SOCK_DGRAM 基于(yu)upd的套(tao)接字
SOCKADDR_IN addrSrv;
addrSrv.sin_addr.S_un.S_addr=inet_addr("192.168.1.103");/*設(she)置目標地址(zhi),根據服務器端情況*/
addrSrv.sin_family=AF_INET;
addrSrv.sin_port=htons(6666);//與服務器端(duan)一致(zhi)
char recvBuff[200];//接(jie)收緩存(cun)
char sendBuff[200];//發(fa)送(song)緩存
char tempBuff[200];//暫(zan)時緩(huan)存
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);//發送(song)
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();
}
以上代碼可(ke)(ke)使用VC6.0、VS2005、 VS2008等軟件編譯器。服(fu)務器端的網絡地址為192.168.1.102。客戶(hu)(hu)端不限,只要(yao)(yao)和服(fu)務間路由可(ke)(ke)達即可(ke)(ke),本例中使用192.168.1.100。如不想更改服(fu)務器端IP地址,只要(yao)(yao)按(an)照(zhao)程(cheng)(cheng)序(xu)注釋,根據實際情況更改客戶(hu)(hu)程(cheng)(cheng)序(xu)的addrSrv.sin_addr.S_un.S_addr變量即可(ke)(ke)。
2 報文捕獲與(yu)分析
圖(tu)1為客(ke)戶端(duan)IP192.168.1.100向服務(wu)器端(duan)IP192.168.1.103發出數(shu)據“test”后,由服務(wu)器端(duan)的sniffer捕獲(huo)的報文。
UDP報(bao)(bao)文(wen)(wen)為灰色開(kai)始的(de)(de)(de)0c 96 1a 0a 00 0d 6d 3e 74 65 73 74 00共13字(zi)(zi)(zi)(zi)(zi)節(jie)。UDP前45開(kai)始到67為標準IP報(bao)(bao)文(wen)(wen)頭共20個(ge)字(zi)(zi)(zi)(zi)(zi)節(jie),報(bao)(bao)文(wen)(wen)開(kai)頭的(de)(de)(de)00到08 00(IP報(bao)(bao)文(wen)(wen)頭前)14個(ge)字(zi)(zi)(zi)(zi)(zi)節(jie)為DLC(Data Link Control)報(bao)(bao)文(wen)(wen)頭。UDP報(bao)(bao)文(wen)(wen)中(zhong),0c 96源(yuan)(yuan)端口號(hao),兩(liang)字(zi)(zi)(zi)(zi)(zi)節(jie),客(ke)戶端用于接收(shou)信(xin)息的(de)(de)(de)端口號(hao),不需(xu)要回復(fu)可用全零(ling)。1a 0a 目的(de)(de)(de)端口號(hao),兩(liang)字(zi)(zi)(zi)(zi)(zi)節(jie),服務器(qi)端的(de)(de)(de)接收(shou)端口號(hao)。00 0d 數據(ju)包(bao)長度,兩(liang)字(zi)(zi)(zi)(zi)(zi)節(jie),本示(shi)例(li)為13。6d 3e 校驗(yan)和,兩(liang)字(zi)(zi)(zi)(zi)(zi)節(jie)。74 65 73 74 00 數據(ju)包(bao)的(de)(de)(de)內容,74 65 73 74 為“test”的(de)(de)(de)ASCII編(bian)碼,00通過源(yuan)(yuan)程序(xu)可以發現,為了接收(shou)端處理方便多(duo)發的(de)(de)(de)一個(ge)空字(zi)(zi)(zi)(zi)(zi)節(jie)。
圖(tu)2為服(fu)務(wu)器端103接收(shou)到(dao)“test”后(hou),向(xiang)客(ke)戶端發(fa)送“received test”數據(ju),由(you)服(fu)務(wu)器端的sniffer軟件捕獲的報(bao)文。
UDP報(bao)文為灰(hui)色開(kai)始1a 0a 0c96 00 16 b6 78 72 65 63 65 69 76 65 64 20 74 65 73 74 00共22字(zi)節。1a 0a源端口號(hao),0b 96目的(de)端口號(hao),與(yu)前一(yi)報(bao)文正好相反(fan)。00 16 數(shu)據包長度22字(zi)節。B6 78 校驗和,72 65 63 65 69 76 65 64 20 74 65 73 74 00 是數(shu)據報(bao)的(de)內容,同樣多發了一(yi)個(ge)空(kong)字(zi)節。
由協(xie)議分析可(ke)知,UDP位于IP報文的(de)數(shu)據(ju)(ju)(ju)域中,由源端口(kou)、目(mu)的(de)端口(kou)、長(chang)度、校驗和(he)、和(he)數(shu)據(ju)(ju)(ju)域組成(cheng),采用(yong)明文傳遞(di)應用(yong)數(shu)據(ju)(ju)(ju)。如(ru)果傳遞(di)重要信(xin)息一(yi)定要在(zai)應用(yong)層加密,否則很容易被(bei)竊取。UDP在(zai)發送(song)數(shu)據(ju)(ju)(ju)時(shi)附帶(dai)自(zi)身(shen)的(de)端口(kou)號,接收時(shi)不需要確認(ren),所以可(ke)以方便的(de)進行一(yi)對一(yi)、一(yi)對多(duo)和(he)多(duo)對多(duo)的(de)交互通信(xin),這種方式方便但存在(zai)缺陷,如(ru)果被(bei)攻擊(ji)者知道(dao)服務(wu)的(de)端口(kou)號,控制多(duo)臺(tai)主機向服務(wu)器(qi)發送(song)大量(liang)垃圾信(xin)息,可(ke)使服務(wu)器(qi)癱瘓。這是此類(lei)協(xie)議的(de)共有的(de)弱點。
3 結束語
傳輸層的UDP協(xie)議由(you)于其簡(jian)潔、高效性(xing)而被廣泛使用(yong),是一種重要的協(xie)議。該(gai)文(wen)介紹(shao)的UDP協(xie)議使用(yong)方法具有通用(yong)性(xing),可作為開發、學習(xi)此(ci)類軟件參考。UDP協(xie)議由(you)于沒有安(an)全控制(zhi),采(cai)用(yong)UDP協(xie)議的系統(tong)在提供(gong)服務時(shi)最好(hao)放在防火(huo)墻內,由(you)系統(tong)對它提供(gong)安(an)全保證。
參考文獻:
[1] 謝希仁.計算機網絡[M].5版.北京(jing):電(dian)子工業出版社,2007:108-184.
[2] Stanley B Lippman. JoséeLajoi C++Primer[M].潘(pan)愛民,張麗,譯.北京:電力(li)出版社,2005.
篇2
關鍵詞：arm；linux；交叉編(bian)譯環境；udp協議(yi)；重(zhong)發(fa)機制；重(zhong)發(fa)次數
中(zhong)圖(tu)分類號：tp393文(wen)獻標識碼：a文(wen)章(zhang)編(bian)號：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協議(yi)以(yi)其高效性和(he)應(ying)用(yong)的簡單，被廣泛(fan)運用(yong)于嵌入(ru)式網絡開(kai)發(fa)(fa)中(zhong)(zhong)。由(you)于udp協議(yi)的應(ying)用(yong)簡單，在嵌入(ru)式設備開(kai)發(fa)(fa)過(guo)(guo)程(cheng)(cheng)中(zhong)(zhong)，網絡資源的利用(yong)率(lv)并不高。以(yi)下(xia)將介紹(shao)一(yi)個udp具(ju)體(ti)項目實驗過(guo)(guo)程(cheng)(cheng)，描述arm-linux環境的軟硬件(jian)環境構建過(guo)(guo)程(cheng)(cheng)，并對udp協議(yi)下(xia)一(yi)種重(zhong)發(fa)(fa)模式中(zhong)(zhong)上(shang)位機的重(zhong)發(fa)(fa)次(ci)數(shu)的確定(ding)提出一(yi)種可行(xing)的方法。
1 研究背景
隨著嵌(qian)(qian)入(ru)式(shi)(shi)技術的快速發(fa)展，嵌(qian)(qian)入(ru)式(shi)(shi)設(she)備已經在許多領域(yu)取代了傳統(tong)(tong)的微型機設(she)備。本文的選(xuan)題主要(yao)來自(zi)于(yu)實習期間承接的一項改造項目：某院校特長(chang)生評分(fen)系統(tong)(tong)的改造。項目改造目的有(you)：1) 保留(liu)原上(shang)位(wei)機。2) 改用手持式(shi)(shi)客戶(hu)端進(jin)行顯示及(ji)評分(fen)操(cao)作。3)保留(liu)原有(you)網絡設(she)備。針對要(yao)求，我們(men)使用s3c2440作為(wei)硬件平臺，移植(zhi)linux操(cao)作系統(tong)(tong)，并在arm-linux環境下研究了udp協議的通信過程，進(jin)行了上(shang)位(wei)機與嵌(qian)(qian)入(ru)式(shi)(shi)系統(tong)(tong)的udp協議通信實驗及(ji)分(fen)析，并給出一種(zhong)重發(fa)機制中的發(fa)送次數求法。
2 硬件平臺介紹
s3c2440處理速度達到了400mhz，具(ju)有較(jiao)高(gao)的(de)性價比。為了提高(gao)開發(fa)(fa)效率，我(wo)們采(cai)用公司自行(xing)研制開發(fa)(fa)的(de)et-s3c2440開發(fa)(fa)板。
2.1 et-s3c2440開發(fa)板簡介
et-s3c2440是公(gong)司自行開(kai)發的(de)一款arm9架構的(de)實驗開(kai)發板，其結構框圖如圖1。
核心板(ban)的主(zhu)要器件有：32mb×2片sdram，64mb norflash，512mb nandflash。設計(ji)了啟(qi)動(dong)方(fang)式可選(xuan)，通過開關選(xuan)擇從nandflash或norflash啟(qi)動(dong)。
2.2 實驗相關(guan)電路說(shuo)明(ming)
底板(ban)電路主要功能是輸入(ru)輸出以(yi)及(ji)網絡通訊(xun)功能。按(an)鍵輸入(ru)部分采用掃描方式獲得輸入(ru)，用一個單(dan)向地址(zhi)鎖(suo)存(cun)器和一個雙向地址(zhi)鎖(suo)存(cun)器與(yu)地址(zhi)總線相(xiang)連(lian)，可以(yi)通過掃描地址(zhi)來獲得按(an)鍵輸入(ru)。lcd采用三星的(de)3.5寸tft屏(ping)作為顯示(shi)輸出設備。網卡芯片選(xuan)用的(de)是與(yu)原設備匹配的(de)10m 的(de)cs8900a，關于cs8900a與(yu)s3c2440的(de)硬件連(lian)接，有眾多資源(yuan)可供參考，本(ben)文不再贅述。
3 系統(tong)軟件平臺(tai)的構建(jian)
硬件平臺搭建完畢后要將操作(zuo)系統和應用程序在(zai)硬件平臺上運行起來。以(yi)下是(shi)對嵌入(ru)式linux操作(zuo)系統移(yi)植的過(guo)程。
3.1 交叉(cha)編譯(yi)環(huan)境的構建
linux 2.6.29.1版本的(de)內核可(ke)以登(deng)錄(lu)到kernel.org下載。本文選擇的(de)是arm-linux-gcc-4.3.2工具(ju)鏈(ftp://ftp.arm.linux.org.uk/pub/armlinux/toolchain)
在宿主(zhu)機上進入linux系統(tong)，切換當(dang)前目(mu)錄(lu)(lu)到工具鏈(lian)所(suo)在目(mu)錄(lu)(lu)，新建(jian)一個arm目(mu)錄(lu)(lu)保存(cun)解壓后(hou)的文件(mkdir /user/local/arm)并(bing)將arm-linux-gcc-4.3.2解壓到這個目(mu)錄(lu)(lu)中(tar jxvf arm-linux-gcc-4.3.2 –c /user/local/arm)。然后(hou)將環(huan)境變量$path修改一下，讓$path中包(bao)含(han)有arm-linux-gcc所(suo)在的目(mu)錄(lu)(lu)(編輯/etc/profile 添加語句”export path=/user/local/arm/4.3.2/bin:$path”)，然后(hou)reboot一下，這樣交叉編譯環(huan)境就構建(jian)好了。
3.2 bootloader的移植
vivi是(shi)一款相當(dang)成(cheng)熟和相對簡(jian)單的常用bootloader，我們以vivi為移植原型(xing)，將s3c2440所有io端口寄(ji)存器定義添加到頭文件(jian)2440add.inc，刪除部分硬件(jian)平臺使(shi)用不到的代碼，最后將修改過(guo)的vivi制作成(cheng)鏡像燒錄到flash中。[1]
3.3 linux內核移植
獲取linux-2.6.29.1源代(dai)碼(ma)并(bing)解壓后(hou)，首先修(xiu)(xiu)(xiu)改(gai)(gai)內核(he)源代(dai)碼(ma)所在(zai)目錄中(zhong)(zhong)(zhong)的(de)(de)makefile，將系統(tong)架構修(xiu)(xiu)(xiu)改(gai)(gai)為arm(arch ?=arm ),交叉編(bian)譯工具修(xiu)(xiu)(xiu)改(gai)(gai)為arm-linux-gcc (cross_compile ?=arm-linux-)，修(xiu)(xiu)(xiu)改(gai)(gai)輸入時(shi)鐘(arch/arm/mach-s3c2440/mach-smdk2440.c中(zhong)(zhong)(zhong)的(de)(de)函(han)數static void __init smdk2440_map_io中(zhong)(zhong)(zhong)，修(xiu)(xiu)(xiu)改(gai)(gai)s3c24xx_init_clocks(12000000)此處所用(yong)晶振為12m)。修(xiu)(xiu)(xiu)改(gai)(gai)machine名稱(在(zai)arch/arm/mach-s3c2440/mach-smdk2440.c文(wen)件中(zhong)(zhong)(zhong)的(de)(de)函(han)數machine_start( ),修(xiu)(xiu)(xiu)改(gai)(gai)為machine_start(s3c2440, “自定義機器(qi)名”)，修(xiu)(xiu)(xiu)改(gai)(gai)nandflash分(fen)區信(xin)息(arch/arm/plat-s3c24xx/common-smdk.c結(jie)構體static struct mtd_partition smdk_default_nand_part[]中(zhong)(zhong)(zhong)保存的(de)(de)是(shi)nandflah的(de)(de)分(fen)區信(xin)息，將其修(xiu)(xiu)(xiu)改(gai)(gai)為當前使用(yong)的(de)(de)分(fen)區信(xin)息),然后(hou)修(xiu)(xiu)(xiu)改(gai)(gai)nandflash的(de)(de)匹配時(shi)間(3c2410_platform_nand_smdk_nand_info smdk_nand_info ={})。
上述內核源代碼修(xiu)改完成后，還(huan)需(xu)要(yao)(yao)對(dui)一些(xie)設備的(de)(de)驅(qu)(qu)動(dong)進行(xing)修(xiu)改。本文使用(yong)的(de)(de)nec 3.5寸 320×240液晶屏，硬件(jian)平臺使用(yong)gpg4腳進行(xing)背光控制，需(xu)要(yao)(yao)修(xiu)改lcd背光(/arch/arm/mach-s3c2440/mach-smdk2440.c中static void __init smdk2440_machine_init(void)，將函(han)數中的(de)(de)gpio口配置(zhi)為(wei)gpg4)。關于(yu)cs8900a網(wang)卡的(de)(de)驅(qu)(qu)動(dong)移植，相關資源很豐富，本文也不再贅述。
本實驗中nandflash采用的是yaffs2文件系(xi)統，所以打yaffs2文件系(xi)統補丁(ding)，壓縮包為cvs-root.tar.gz。
至此，linux的內(nei)(nei)核源代(dai)碼修改工作完(wan)成了，下面還需要利用makefile,進行內(nei)(nei)核配置。
在linux 2.6.29.1內(nei)核(he)(he)目錄下首先make s3c2410_defconfig使用2410的(de)配(pei)(pei)置(zhi)模板來(lai)配(pei)(pei)置(zhi)2440；然后make menuconfig,這時我(wo)們可(ke)以(yi)在圖形化(hua)界面中，空格鍵可(ke)改變各個(ge)配(pei)(pei)置(zhi)選(xuan)(xuan)項(xiang)的(de)被選(xuan)(xuan)中狀(zhuang)態，根據需要(yao)進(jin)行(xing)配(pei)(pei)置(zhi)即可(ke)。配(pei)(pei)置(zhi)完成(cheng)后保存好配(pei)(pei)置(zhi)，最后進(jin)行(xing)內(nei)核(he)(he)的(de)編(bian)譯(make dep 建(jian)立文(wen)件間依賴(lai) make clean 清除編(bian)譯殘留(liu)文(wen)件make zimage 生(sheng)成(cheng)內(nei)核(he)(he)壓縮(suo)鏡像文(wen)件)。
編譯過程完成(cheng)后會在內(nei)核目錄arch/arm/boot/下生(sheng)成(cheng)zimage內(nei)核映像(xiang)文件，將這(zhe)個鏡像(xiang)文件燒錄到flash中，調試檢(jian)驗，經上述修改后的內(nei)核工作運行正常。
3.4 根文件系統(tong)的制作
根(gen)文(wen)件系統是使用busybox-1.13.3來制作完(wan)成(cheng)(cheng)。下載busybox并(bing)解壓完(wan)成(cheng)(cheng)后，修(xiu)改makefile中的架構(gou)為arm架構(gou)，編譯(yi)工具為arm-linux-gcc( arch ?=arm； cross_compile ?=arm-linux-),然后make menuconfig,通過圖(tu)形界面對busybox進行配置，然后對busybox進行編譯(yi)(make config_prefix=/opt/studyarm/rootfs install)，在目(mu)標目(mu)錄下會(hui)生成(cheng)(cheng)目(mu)錄bin、sbin、usr和文(wen)件linuxrc的內容(rong)。
基本(ben)目錄(lu)(lu)結構生成后，應該在目標目錄(lu)(lu)下建(jian)立(li)一(yi)些(xie)未生成的必要(yao)的系統(tong)目錄(lu)(lu)如(ru)dev、etc、lib等(deng)(deng)，并通過chmod命令(ling)改變(bian)目錄(lu)(lu)權限為(wei)可寫。再將一(yi)些(xie)必要(yao)的動(dong)(dong)態鏈接庫和靜(jing)態庫拷貝(bei)到lib下，然后在dev目錄(lu)(lu)下創(chuang)建(jian)設備(bei)節點，最后創(chuang)建(jian)該嵌入式(shi)linux系統(tong)的初始(shi)(shi)化(hua)(hua)配置文(wen)件(包括設備(bei)列(lie)表文(wen)件、口(kou)令(ling)、網(wang)絡(luo)分組組名(ming)、hostname主機名(ming)、etc/inittab初始(shi)(shi)化(hua)(hua)表單、etc/profile環境變(bian)量配置文(wen)件、用于系統(tong)初始(shi)(shi)化(hua)(hua)的.bash腳本(ben)文(wen)件等(deng)(deng))。[2]由于本(ben)實驗需對網(wang)絡(luo)編程，要(yao)求自動(dong)(dong)初始(shi)(shi)化(hua)(hua)cs8900a網(wang)卡芯片(pian)的ip地址、網(wang)關、子網(wang)掩碼等(deng)(deng)，所以在開機自啟動(dong)(dong)腳本(ben)中加(jia)入ifconfig語句，使得開機時自動(dong)(dong)配置網(wang)卡參數。
根文件系(xi)(xi)統(tong)構建(jian)完成后，使(shi)用yaffs2文件系(xi)(xi)統(tong)制(zhi)作工具mkyaffs2image.tgz，通過命令(ling)mkyaffs2image rootfs rootfs.img生成根文件系(xi)(xi)統(tong)鏡像，然后將鏡像燒寫入flash中(zhong)。
4 arm-linux環境下(xia)的udp協議通信實(shi)驗(yan)
經(jing)(jing)過上述硬件(jian)設計和操作(zuo)(zuo)系統(tong)移(yi)植過程，本文所(suo)使(shi)用到的實驗(yan)環境已經(jing)(jing)構建(jian)完畢，經(jing)(jing)反復調試(shi)修改，嵌入(ru)式linux操作(zuo)(zuo)系統(tong)在(zai)平臺下運行正常(chang)，于是進行udp協議(yi)通信實驗(yan)。
4.1 udp協議套接字編程基礎
udp是(shi)(shi)一(yi)個(ge)(ge)面向數據報和(he)無連接(jie)的簡單(dan)傳輸層協(xie)議(yi)，它不像tcp那樣通過(guo)(guo)(guo)(guo)握手過(guo)(guo)(guo)(guo)程建立服務器與客(ke)戶(hu)端的連接(jie)才可以(yi)工作(zuo)。在網(wang)絡(luo)通信(xin)質量(liang)較好的情況下(xia)，udp體現出(chu)高效率，這適合(he)于傳送少量(liang)報文的應用(yong)(yong)。[3] linux系(xi)統是(shi)(shi)通過(guo)(guo)(guo)(guo)套(tao)接(jie)字結構來進行(xing)(xing)網(wang)絡(luo)編(bian)程的，應用(yong)(yong)程序通過(guo)(guo)(guo)(guo)對套(tao)接(jie)字的幾(ji)個(ge)(ge)函數調(diao)用(yong)(yong)，會返回一(yi)個(ge)(ge)用(yong)(yong)于通信(xin)的套(tao)接(jie)字描(miao)述符(fu),而(er)linux應用(yong)(yong)程序在進行(xing)(xing)任何形式(shi)的i/o操(cao)作(zuo)時，程序實際上是(shi)(shi)在讀寫(xie)一(yi)個(ge)(ge)文件(jian)描(miao)述符(fu)。[4]因此linux下(xia)的套(tao)接(jie)字編(bian)程，可以(yi)看(kan)成是(shi)(shi)對普通文件(jian)描(miao)述符(fu)的操(cao)作(zuo)，這些操(cao)作(zuo)與被(bei)使(shi)用(yong)(yong)的硬件(jian)平(ping)臺(tai)無關，這是(shi)(shi)linux設備(bei)無關性的優點。udp協(xie)議(yi)的通信(xin)模型(xing)如圖(tu)3所示。
在上述流程中，客戶(hu)端所(suo)收到的(de)報文(wen)被存儲在緩沖(chong)區中，recvfrom()函數(shu)返回了報文(wen)存儲緩沖(chong)區的(de)首地址，我們可以(yi)很方便地對這個首地址進行(xing)數(shu)組(zu)操作，從而實現對報文(wen)的(de)解碼。
4.2 上(shang)位機(ji)報文(wen)結構及(ji)重發機(ji)制(zhi)分析(xi)
根(gen)據項目要(yao)求，上位(wei)(wei)機軟件依(yi)然保留，我們使用(yong)協議(yi)嗅探(tan)工具(ju)對上位(wei)(wei)機發送的報文進行(xing)了(le)嗅探(tan)，得到(dao)了(le)上位(wei)(wei)機報文的結構如(ru)表1所示。
表1 上位(wei)機報(bao)文(wen)結構
上(shang)位(wei)(wei)機(ji)發(fa)出的(de)(de)每條報(bao)(bao)(bao)(bao)文(wen)由32個(ge)字節組成(cheng)，第(di)(di)(di)0位(wei)(wei)為版(ban)本信(xin)息(xi)。第(di)(di)(di)1……12位(wei)(wei)為比賽信(xin)息(xi)和運動員教(jiao)練信(xin)息(xi)，是(shi)報(bao)(bao)(bao)(bao)文(wen)的(de)(de)關(guan)鍵(jian)信(xin)息(xi)部分，13……22位(wei)(wei)為服(fu)務器端和客戶端的(de)(de)ip地址(zhi)及(ji)端口(kou)號(hao)信(xin)息(xi)，23位(wei)(wei)是(shi)上(shang)位(wei)(wei)機(ji)對(dui)客戶端的(de)(de)操作指(zhi)令代碼，24位(wei)(wei)是(shi)相關(guan)重(zhong)發(fa)機(ji)制(zhi)的(de)(de)代碼，30和31兩位(wei)(wei)是(shi)checksum，用(yong)來保(bao)證數據(ju)傳輸(shu)的(de)(de)正確。上(shang)位(wei)(wei)機(ji)采用(yong)的(de)(de)重(zhong)發(fa)機(ji)制(zhi)是(shi)一(yi)種上(shang)位(wei)(wei)機(ji)按照固定重(zhong)發(fa)次數多次發(fa)送同一(yi)關(guan)鍵(jian)內(nei)容報(bao)(bao)(bao)(bao)文(wen)的(de)(de)機(ji)制(zhi)，其第(di)(di)(di)24位(wei)(wei)重(zhong)發(fa)機(ji)制(zhi)位(wei)(wei)被(bei)分為高(gao)4位(wei)(wei)和低(di)4位(wei)(wei)兩部分，高(gao)四位(wei)(wei)的(de)(de)內(nei)容是(shi)當(dang)前(qian)發(fa)送的(de)(de)報(bao)(bao)(bao)(bao)文(wen)的(de)(de)索(suo)引號(hao)，每次發(fa)送一(yi)條新內(nei)容的(de)(de)報(bao)(bao)(bao)(bao)文(wen)時索(suo)引號(hao)自(zi)增(zeng)1，索(suo)引號(hao)的(de)(de)取值(zhi)范圍(wei)在(zai)0x00—0xff范圍(wei)內(nei)循環自(zi)增(zeng)。低(di)四位(wei)(wei)是(shi)重(zhong)發(fa)編號(hao)，表示同一(yi)索(suo)引號(hao)的(de)(de)報(bao)(bao)(bao)(bao)文(wen)正在(zai)被(bei)第(di)(di)(di)幾次重(zhong)發(fa)，固定的(de)(de)重(zhong)發(fa)次數由上(shang)位(wei)(wei)機(ji)初(chu)始(shi)化時設(she)定。
4.3 嵌入式客戶(hu)端的實驗程序設計
針(zhen)對(dui)報(bao)文(wen)結(jie)構，我們(men)對(dui)接(jie)收端(duan)編(bian)寫實驗(yan)程序代碼(ma)，代碼(ma)的主(zhu)要功能是(shi)從上位(wei)機(ji)接(jie)收報(bao)文(wen)，將計算出(chu)的checksum校驗(yan)和與收到的校驗(yan)和對(dui)比判斷(duan)報(bao)文(wen)是(shi)否正確(que)，然后從正確(que)報(bao)文(wen)中取出(chu)主(zhu)要信息并按照(zhao)報(bao)文(wen)中的上位(wei)機(ji)指令碼(ma)進行輸出(chu)。其結(jie)構流程圖如圖3所(suo)示(shi)。
實(shi)驗(yan)程序經編碼(ma)、調試(shi)后在交(jiao)叉編譯環境中交(jiao)叉編譯，生成arm-linux環境下可執(zhi)行(xing)(xing)文件(jian)，在目(mu)標板上(shang)執(zhi)行(xing)(xing)。經測試(shi)試(shi)驗(yan)程序能(neng)夠(gou)正確接收上(shang)位(wei)機發來的(de)報文，對報文解碼(ma)，并(bing)能(neng)根據上(shang)位(wei)機命令(ling)對關鍵(jian)信息做輸出(chu)處理。
4.4 對(dui)上位機重發次數的(de)研(yan)究
進行udp協(xie)議通信時(shi)，發(fa)(fa)送(song)端和接(jie)(jie)(jie)收(shou)端的(de)狀(zhuang)態是相(xiang)對獨立的(de)，發(fa)(fa)送(song)端不與接(jie)(jie)(jie)收(shou)端建立連接(jie)(jie)(jie)，而(er)是不停向接(jie)(jie)(jie)收(shou)端發(fa)(fa)送(song)，為(wei)了確(que)保(bao)(bao)不丟失(shi)報文(wen)，上位機(ji)采(cai)取了按固(gu)定次數(shu)重(zhong)發(fa)(fa)相(xiang)同內容報文(wen)的(de)機(ji)制。然(ran)而(er)這種(zhong)機(ji)制雖然(ran)可以(yi)有效(xiao)確(que)保(bao)(bao)報文(wen)不丟失(shi)，但是大量冗(rong)(rong)余(yu)數(shu)據(ju)(ju)報被(bei)發(fa)(fa)送(song)，網(wang)絡資源利(li)用率(lv)不高。重(zhong)發(fa)(fa)次數(shu)越多，冗(rong)(rong)余(yu)數(shu)據(ju)(ju)報越多，效(xiao)率(lv)越低(di)。要想有效(xiao)保(bao)(bao)證數(shu)據(ju)(ju)報準確(que)發(fa)(fa)送(song)的(de)同時(shi)又不產生過多冗(rong)(rong)余(yu)數(shu)據(ju)(ju)報，那么重(zhong)復(fu)發(fa)(fa)送(song)的(de)次數(shu)的(de)確(que)定就成為(wei)問題的(de)關鍵。以(yi)下(xia)給(gei)出一(yi)種(zhong)確(que)定上位機(ji)重(zhong)發(fa)(fa)次數(shu)的(de)方法。
假(jia)設當前網絡狀況下(xia)，每次報(bao)文發(fa)送被丟失的概率為p，系統允(yun)許接收端報(bao)文關鍵內(nei)容(rong)丟失概率為q,那么如何確定以上(shang)重發(fa)機制中的重發(fa)次數(shu)k呢？
特殊情(qing)況下(xia)若報(bao)文(wen)(wen)(wen)(wen)重(zhong)發(fa)(fa)(fa)(fa)次(ci)(ci)數為2，分別在每(mei)條(tiao)報(bao)文(wen)(wen)(wen)(wen)重(zhong)發(fa)(fa)(fa)(fa)機制(zhi)位注(zhu)明一個(ge)索引(yin)號(hao)和一個(ge)重(zhong)發(fa)(fa)(fa)(fa)編號(hao)，發(fa)(fa)(fa)(fa)送端發(fa)(fa)(fa)(fa)送報(bao)文(wen)(wen)(wen)(wen)的(de)次(ci)(ci)序應形如 1.1 ,1.2 ,2.1 ,2.2 ,3.1 ,3.2……其(qi)中索引(yin)號(hao)相(xiang)同(tong)的(de)報(bao)文(wen)(wen)(wen)(wen)關(guan)鍵(jian)(jian)內(nei)容(rong)(rong)相(xiang)同(tong)，重(zhong)發(fa)(fa)(fa)(fa)編號(hao)不同(tong)代表同(tong)一關(guan)鍵(jian)(jian)內(nei)容(rong)(rong)報(bao)文(wen)(wen)(wen)(wen)的(de)不同(tong)次(ci)(ci)發(fa)(fa)(fa)(fa)送。因此(ci)只有出(chu)現(xian)連(lian)續兩次(ci)(ci)丟(diu)(diu)(diu)失數據報(bao)的(de)情(qing)況下(xia)，報(bao)文(wen)(wen)(wen)(wen)關(guan)鍵(jian)(jian)內(nei)容(rong)(rong)才可能丟(diu)(diu)(diu)失。出(chu)現(xian)連(lian)續兩次(ci)(ci)丟(diu)(diu)(diu)失的(de)情(qing)況有2種，當(dang)x.1 , x.2丟(diu)(diu)(diu)失，此(ci)時索引(yin)號(hao)為x的(de)報(bao)文(wen)(wen)(wen)(wen)關(guan)鍵(jian)(jian)信息(xi)將全部丟(diu)(diu)(diu)失。當(dang)x.2,(x+1). 1丟(diu)(diu)(diu)失，丟(diu)(diu)(diu)失報(bao)文(wen)(wen)(wen)(wen)的(de)索引(yin)號(hao)不同(tong)，此(ci)時不會(hui)發(fa)(fa)(fa)(fa)生報(bao)文(wen)(wen)(wen)(wen)關(guan)鍵(jian)(jian)信息(xi)丟(diu)(diu)(diu)失，因此(ci)報(bao)文(wen)(wen)(wen)(wen)關(guan)鍵(jian)(jian)內(nei)容(rong)(rong)丟(diu)(diu)(diu)失的(de)概率q=p2/2。
當報(bao)文(wen)(wen)重(zhong)(zhong)發(fa)次(ci)數為(wei)3,依然在每條(tiao)報(bao)文(wen)(wen)的(de)(de)重(zhong)(zhong)發(fa)機制位注明索引(yin)號(hao)(hao)和重(zhong)(zhong)發(fa)號(hao)(hao)，發(fa)送報(bao)文(wen)(wen)的(de)(de)次(ci)序應為(wei)1.1 ,1.2 ,1.3 ,2.1 ,2.2 ,2.3 ,3.1 ,3.2……。只(zhi)有出(chu)現連續3次(ci)丟失(shi)(shi)數據報(bao)的(de)(de)情(qing)(qing)況報(bao)文(wen)(wen)關鍵(jian)信(xin)息才可(ke)能丟失(shi)(shi)，列出(chu)連續3次(ci)丟失(shi)(shi)報(bao)文(wen)(wen)的(de)(de)情(qing)(qing)況有3種，當x.1 , x.2 , x.3丟失(shi)(shi)，此(ci)(ci)時(shi)索引(yin)號(hao)(hao)為(wei)x的(de)(de)報(bao)文(wen)(wen)信(xin)息全部(bu)丟失(shi)(shi)。當x.2 , x.3 ,(x+1).1或x.3 ,(x+1).1 ,(x+1).2丟失(shi)(shi)時(shi)不影響(xiang)報(bao)文(wen)(wen)的(de)(de)準確(que)傳遞。因此(ci)(ci)此(ci)(ci)時(shi)報(bao)文(wen)(wen)關鍵(jian)內容丟失(shi)(shi)的(de)(de)概率q=p3/3。
推廣至一(yi)般情況易得(de)當(dang)報(bao)文重(zhong)發(fa)(fa)次數(shu)為k時，報(bao)文關鍵內容(rong)丟失的(de)概率(lv)q=pk/k，移項(xiang)有(you)kq=pk。于是我們得(de)到求重(zhong)發(fa)(fa)次數(shu)k的(de)方法如下：
1) 根據網(wang)絡狀(zhuang)況獲得報文丟失概率p；
2) 根據客戶需求取得(de)報文關(guan)鍵內容的允許丟失率范圍q；
3) 分別作出y=px和y=qx的圖(tu)像；
4) 求得兩圖像的交點的x坐標，并將x坐標值(zhi)取整加一即為所(suo)求重發次數k。
本(ben)文實驗(yan)中，需求方允(yun)許報(bao)文關鍵(jian)信(xin)息丟失概率q=0.0001,我們分別(bie)對(dui)上(shang)(shang)位(wei)(wei)機發(fa)送端(duan)和下(xia)位(wei)(wei)機接(jie)(jie)收(shou)端(duan)收(shou)發(fa)的(de)報(bao)文進行了(le)統計，在某一(yi)固定時間段內(nei)，上(shang)(shang)位(wei)(wei)機共發(fa)送報(bao)文19665條(tiao)，接(jie)(jie)收(shou)端(duan)接(jie)(jie)收(shou)報(bao)文18636條(tiao)，傳輸過程中丟失的(de)報(bao)文19665-18636=1029條(tiao)，當前網(wang)絡環境下(xia)的(de)報(bao)文丟失率為，即(ji)p=0.0523。據(ju)此數(shu)值分別(bie)作出y=0.0001x的(de)曲(qu)線和y=0.0523 x的(de)曲(qu)線，取得兩曲(qu)線交點x坐標為x≈2.78，最后將(jiang)x=2.78取整加1得到k=3，即(ji)上(shang)(shang)位(wei)(wei)機對(dui)同一(yi)數(shu)據(ju)報(bao)的(de)重發(fa)次(ci)數(shu)應該(gai)定為3次(ci)就可保證(zheng)系統丟失報(bao)文的(de)概率低(di)于0.0001。
5 結論與展望
本文從硬件平臺搭建、linux移(yi)植(zhi)以及udp協(xie)議(yi)編程幾個方面介(jie)紹了(le)(le)(le)arm-linux環境下udp協(xie)議(yi)通(tong)信(xin)的(de)具體(ti)實現，并分(fen)析了(le)(le)(le)一種在實際嵌入(ru)式(shi)項目中(zhong)常用(yong)(yong)的(de)上位機數據報重(zhong)發機制，最后對這(zhe)種機制中(zhong)的(de)重(zhong)發次數的(de)確定(ding)方法(fa)給出了(le)(le)(le)求解(jie)過程，為后續(xu)的(de)具體(ti)項目實施提供了(le)(le)(le)實踐依據，也希望為其他應用(yong)(yong)這(zhe)種重(zhong)發機制的(de)嵌入(ru)式(shi)產品開發者們提供了(le)(le)(le)借(jie)鑒。
參考文獻：
[1] 李偉.基于arm9的嵌入式linux手持平臺的設計與(yu)實現[d].武(wu)漢(han):武(wu)漢(han)理工(gong)大學(xue)碩士學(xue)位論(lun)文(wen),2009.
[2] 范(fan)艷(yan)開.基于arm的嵌(qian)入式linux操作系統移植[d].西(xi)安:西(xi)北工業大學,2005.
篇3
0引言
用(yong)(yong)戶數(shu)據(ju)報(bao)協(xie)議(yi)（User Datagram Protocol，UDP）是一(yi)種(zhong)無連接(jie)的(de)(de)傳(chuan)輸層協(xie)議(yi)，沒有連接(jie)建立和連接(jie)終止的(de)(de)握手過程，所(suo)以UDP協(xie)議(yi)通信效率(lv)高(gao)，冗余性(xing)強，對(dui)個(ge)(ge)(ge)別數(shu)據(ju)包丟失不敏感，廣泛應用(yong)(yong)于車輛檢(jian)測儀、氣象檢(jian)測儀和情報(bao)板(ban)等工程類項目中。在高(gao)速公路可變情報(bao)板(ban)系統中，UDP協(xie)議(yi)經(jing)常在應用(yong)(yong)層面利用(yong)(yong)后(hou)向差錯控制(zhi)（Backward Error Control，BEC）技術實(shi)現對(dui)數(shu)據(ju)流(liu)的(de)(de)調(diao)節，以避免網(wang)絡的(de)(de)阻塞。接(jie)收端(duan)采(cai)用(yong)(yong)與發(fa)送(song)端(duan)“一(yi)次(ci)握手”的(de)(de)方式來(lai)確保(bao)每(mei)一(yi)個(ge)(ge)(ge)獨立數(shu)據(ju)包的(de)(de)正確傳(chuan)輸。如果接(jie)收數(shu)據(ju)包正確合法(fa)，接(jie)收端(duan)將回(hui)送(song)確認信息（ACK）來(lai)傳(chuan)輸下一(yi)個(ge)(ge)(ge)數(shu)據(ju)包；否則自動請求重(zhong)發(fa)（Automatic Repeat reQuest，ARQ），這一(yi)機制(zhi)稱之為空閑ARQ[1]。
空(kong)閑ARQ因(yin)技術簡單而(er)(er)容易(yi)實現。但是(shi)，半雙工的(de)(de)(de)通(tong)信方式(shi)致使其傳輸(shu)(shu)效率和(he)帶寬利用(yong)率很(hen)低(di)，在(zai)往返時延(yan)（RoundTrip Time，RTT）較(jiao)高的(de)(de)(de)情(qing)況下尤(you)為(wei)明顯。相(xiang)(xiang)比(bi)之下，連(lian)續ARQ克服了空(kong)閑ARQ停止等待(dai)的(de)(de)(de)缺(que)點，它(ta)允許發(fa)(fa)送(song)(song)端(duan)(duan)(duan)在(zai)收(shou)(shou)到(dao)ACK之前(qian)連(lian)續發(fa)(fa)送(song)(song)多個數(shu)(shu)據(ju)包(bao)，也允許接收(shou)(shou)端(duan)(duan)(duan)連(lian)續接收(shou)(shou)[2]。然(ran)而(er)(er)在(zai)可(ke)(ke)變(bian)情(qing)報板(ban)系(xi)統(tong)中(zhong)，負責數(shu)(shu)據(ju)接收(shou)(shou)的(de)(de)(de)工控機(ji)配置(zhi)情(qing)況差(cha)強人意，與發(fa)(fa)送(song)(song)端(duan)(duan)(duan)相(xiang)(xiang)去較(jiao)遠。一(yi)些(xie)終(zhong)(zhong)端(duan)(duan)(duan)自適應協(xie)議(yi)(yi)（如RBUDP+[3]、RAPID[4]、PAPID+[5]、GTP（Group Transport Protocol）[6]、PAUDP[7]和(he)RTsunami[8]等）已(yi)經考慮到(dao)終(zhong)(zhong)端(duan)(duan)(duan)的(de)(de)(de)性(xing)能(neng)問題，它(ta)們根據(ju)終(zhong)(zhong)端(duan)(duan)(duan)系(xi)統(tong)的(de)(de)(de)接受能(neng)力實時調(diao)(diao)整(zheng)發(fa)(fa)送(song)(song)速率，從而(er)(er)獲(huo)得更(geng)好的(de)(de)(de)傳輸(shu)(shu)性(xing)能(neng)。這些(xie)協(xie)議(yi)(yi)在(zai)eScience等需要海量數(shu)(shu)據(ju)傳輸(shu)(shu)的(de)(de)(de)科(ke)研(yan)應用(yong)中(zhong)效果顯著(zhu)[9]，而(er)(er)對(dui)于工程(cheng)中(zhong)廣泛(fan)使用(yong)的(de)(de)(de)小文(wen)件(jian)傳輸(shu)(shu)力不從心，因(yin)為(wei)在(zai)協(xie)議(yi)(yi)作出調(diao)(diao)整(zheng)之前(qian)文(wen)件(jian)已(yi)經傳輸(shu)(shu)完(wan)畢，各種算法(fa)無用(yong)武(wu)之地(di)。為(wei)了解決(jue)上述提到(dao)的(de)(de)(de)諸多問題，本文(wen)探討(tao)了與終(zhong)(zhong)端(duan)(duan)(duan)性(xing)能(neng)相(xiang)(xiang)關的(de)(de)(de)若干影響因(yin)子(zi)，并(bing)針對(dui)終(zhong)(zhong)端(duan)(duan)(duan)性(xing)能(neng)瓶頸提出一(yi)種基于UDP的(de)(de)(de)自適應傳輸(shu)(shu)協(xie)議(yi)(yi)。該協(xie)議(yi)(yi)無須用(yong)戶干預，可(ke)(ke)根據(ju)系(xi)統(tong)當前(qian)狀態配置(zhi)參數(shu)(shu)，針對(dui)不同大小的(de)(de)(de)文(wen)件(jian)區(qu)分對(dui)待(dai)，采(cai)取多種措施保證數(shu)(shu)據(ju)可(ke)(ke)靠快速地(di)傳輸(shu)(shu)。
篇4
【關鍵詞(ci)】可靠UDP;確認重傳;滑動窗(chuang)口
引言
由于傳(chuan)統(tong)(tong)的(de)(de)數(shu)(shu)據(ju)(ju)傳(chuan)輸(shu)協(xie)議所針(zhen)對的(de)(de)業務不同(tong)，在(zai)數(shu)(shu)據(ju)(ju)傳(chuan)輸(shu)的(de)(de)速度(du)和可(ke)靠(kao)(kao)性(xing)之間不能(neng)達到很好的(de)(de)平衡。車(che)險理(li)賠系(xi)統(tong)(tong)中(zhong)采用的(de)(de)是(shi)移動(dong)理(li)賠的(de)(de)思想，手持終端機通(tong)(tong)過移動(dong)通(tong)(tong)信網(wang)絡和后臺中(zhong)心系(xi)統(tong)(tong)進行數(shu)(shu)據(ju)(ju)交(jiao)互。目前國內的(de)(de)通(tong)(tong)信事業并(bing)不是(shi)很發(fa)達，信號(hao)覆蓋(gai)率并(bing)不全面，移動(dong)通(tong)(tong)信網(wang)絡的(de)(de)帶寬和傳(chuan)輸(shu)質(zhi)量會受到地(di)域的(de)(de)影響，為確保理(li)賠現場與(yu)后臺系(xi)統(tong)(tong)間數(shu)(shu)據(ju)(ju)的(de)(de)及時可(ke)靠(kao)(kao)傳(chuan)輸(shu)，需(xu)要基于移動(dong)通(tong)(tong)信的(de)(de)網(wang)絡環境設計(ji)高(gao)效(xiao)可(ke)靠(kao)(kao)的(de)(de)數(shu)(shu)據(ju)(ju)傳(chuan)輸(shu)功(gong)能(neng)。本章在(zai)UDP傳(chuan)輸(shu)協(xie)議基礎(chu)上，通(tong)(tong)過應(ying)用層封(feng)裝和可(ke)靠(kao)(kao)性(xing)設計(ji)的(de)(de)方法，采用數(shu)(shu)據(ju)(ju)包的(de)(de)確認重傳(chuan)、流量控制等機制，設計(ji)并(bing)實現基于UDP協(xie)議的(de)(de)可(ke)靠(kao)(kao)數(shu)(shu)據(ju)(ju)傳(chuan)輸(shu)功(gong)能(neng)。
1.TCP與UDP的對比
TCP和(he)UDP都屬于傳輸(shu)層(ceng)協議，負責承擔數據傳輸(shu)的(de)任務[1]。兩者之(zhi)間的(de)主要區別有：
（1）TCP和(he)UDP是(shi)(shi)(shi)(shi)傳輸層的(de)兩個(ge)協議，它們最(zui)大的(de)區別(bie)是(shi)(shi)(shi)(shi)是(shi)(shi)(shi)(shi)否面向連接。TCP，在客戶端和(he)服務(wu)器(qi)端進(jin)行通信(xin)之(zhi)前，首(shou)先要交換傳輸層控(kong)制信(xin)息，為(wei)雙(shuang)方的(de)通信(xin)做好準備。UDP是(shi)(shi)(shi)(shi)一個(ge)非連接的(de)協議，傳輸數(shu)據(ju)之(zhi)前雙(shuang)方不建立連接，當傳送數(shu)據(ju)時，簡單的(de)抓取來自應用程序的(de)數(shu)據(ju)，并(bing)盡可能(neng)快的(de)把(ba)數(shu)據(ju)傳送到(dao)網絡上。
（2）UDP協議的數據傳輸(shu)不需要(yao)維護收發狀(zhuang)態(tai)和(he)連(lian)接狀(zhuang)態(tai)等(deng)，與TCP相(xiang)比，網(wang)絡有效利用率得(de)到很大的提高(gao)。
（3）TCP協(xie)(xie)議提(ti)供數據確認重傳、擁塞控制(zhi)等可(ke)靠性(xing)保證，UDP協(xie)(xie)議不(bu)提(ti)供可(ke)靠性(xing)保證，也不(bu)提(ti)供流(liu)量控制(zhi)。
TCP協(xie)(xie)議(yi)由于(yu)需(xu)(xu)要確(que)認的(de)狀態和對(dui)數據(ju)包的(de)操作過多，數據(ju)傳(chuan)(chuan)輸(shu)(shu)的(de)速度不高且網(wang)絡(luo)延遲(chi)較(jiao)大，所以雖然協(xie)(xie)議(yi)可(ke)(ke)靠(kao)(kao)但并不適(shi)合面向(xiang)移動通信的(de)數據(ju)傳(chuan)(chuan)輸(shu)(shu);而UDP協(xie)(xie)議(yi)由于(yu)不用建立連(lian)接(jie)，沒有(you)超時重發等(deng)可(ke)(ke)靠(kao)(kao)機制，網(wang)絡(luo)延遲(chi)小且數據(ju)傳(chuan)(chuan)輸(shu)(shu)速度很(hen)快。本(ben)文設(she)計的(de)理(li)賠系(xi)統(tong)面向(xiang)移動通信網(wang)絡(luo)實現(xian)理(li)賠現(xian)場與后(hou)臺系(xi)統(tong)間的(de)數據(ju)傳(chuan)(chuan)輸(shu)(shu)，網(wang)絡(luo)環境(jing)不如光纖(xian)接(jie)入(ru)網(wang)絡(luo)穩定可(ke)(ke)靠(kao)(kao)，對(dui)數據(ju)的(de)高效可(ke)(ke)靠(kao)(kao)傳(chuan)(chuan)輸(shu)(shu)有(you)著很(hen)高的(de)要求。因此(ci)，本(ben)章選用UDP協(xie)(xie)議(yi)，并在其基礎上，設(she)計了(le)連(lian)接(jie)確(que)認、數據(ju)確(que)認等(deng)可(ke)(ke)靠(kao)(kao)機制，滿足了(le)系(xi)統(tong)對(dui)于(yu)高效可(ke)(ke)靠(kao)(kao)傳(chuan)(chuan)輸(shu)(shu)功能(neng)的(de)需(xu)(xu)求。
2.基于UDP改進的可(ke)靠傳輸協(xie)議(yi)設計(ji)
2.1 可靠(kao)UDP傳輸協議(yi)的層次(ci)結構
本文(wen)設計的基于UDP改進的傳輸協議的層次結構如(ru)圖1所(suo)示(shi)：
從圖1中(zhong)可以看出，本(ben)文在原來(lai)的(de)(de)(de)TCP/IP模型的(de)(de)(de)傳(chuan)(chuan)輸(shu)層(ceng)(ceng)和應用層(ceng)(ceng)之間添(tian)加(jia)(jia)了一層(ceng)(ceng)為(wei)保證數據(ju)可靠傳(chuan)(chuan)輸(shu)的(de)(de)(de)改進協(xie)(xie)議(yi)(yi)層(ceng)(ceng)。新組成的(de)(de)(de)五層(ceng)(ceng)網(wang)絡體(ti)系(xi)結(jie)構中(zhong)，實際用來(lai)傳(chuan)(chuan)輸(shu)數據(ju)的(de)(de)(de)仍然是(shi)傳(chuan)(chuan)輸(shu)層(ceng)(ceng)的(de)(de)(de)UDP協(xie)(xie)議(yi)(yi)，新添(tian)加(jia)(jia)的(de)(de)(de)協(xie)(xie)議(yi)(yi)是(shi)在UDP傳(chuan)(chuan)輸(shu)層(ceng)(ceng)的(de)(de)(de)基(ji)礎上，通過(guo)應用層(ceng)(ceng)對通信雙方(fang)進行連接確認(ren)、流量(liang)控制等功能，提(ti)供一種可靠的(de)(de)(de)數據(ju)傳(chuan)(chuan)輸(shu)機制。改進協(xie)(xie)議(yi)(yi)主要提(ti)供的(de)(de)(de)功能有(you)：
（1）面(mian)向消息包機制的(de)數(shu)(shu)據(ju)接(jie)收和發送(song)功能。改(gai)進協(xie)議的(de)數(shu)(shu)據(ju)傳(chuan)輸(shu)(shu)層仍然使用UDP傳(chuan)輸(shu)(shu)協(xie)議，本身又添加了可靠(kao)機制，因(yin)此可以提供基于消息包的(de)可靠(kao)的(de)數(shu)(shu)據(ju)傳(chuan)輸(shu)(shu)功能。
（2）數據重傳功能(neng)。發(fa)(fa)送(song)方收到接收方發(fa)(fa)來的重發(fa)(fa)請求，將需要重發(fa)(fa)的數據包發(fa)(fa)出(chu)。
（3）丟棄重(zhong)復(fu)包(bao)功能。接收(shou)方對收(shou)到的重(zhong)復(fu)消息包(bao)，進行簡單的丟棄。
（4）流量控制功能。
圖1 協議(yi)層(ceng)次結構圖
2.2 可靠UDP傳輸(shu)協(xie)議(yi)報文結構(gou)
可靠(kao)UDP傳輸(shu)協(xie)議(yi)的(de)(de)報(bao)文結構如圖2所(suo)示，從圖中可以看出，可靠(kao)UDP傳輸(shu)協(xie)議(yi)的(de)(de)報(bao)文結構就是在(zai)UDP報(bao)文的(de)(de)數據填(tian)充部(bu)分(fen)添(tian)加一些自定義字(zi)段(duan)與UDP包頭(tou)一起構成(cheng)可靠(kao)UDP傳輸(shu)協(xie)議(yi)的(de)(de)包頭(tou)，而剩(sheng)余部(bu)分(fen)用來(lai)填(tian)充真實數據。其填(tian)充的(de)(de)字(zi)段(duan)分(fen)別(bie)為：
MessageType（消息(xi)類型(xing)）用(yong)于識別數據包類型(xing)，包括(kuo)數據傳(chuan)輸請(qing)求消息(xi)、數據包發送消息(xi)、數據包確認消息(xi)等，占用(yong)兩(liang)個字節空間。
Length（數(shu)(shu)據包(bao)總長度）用(yong)(yong)于標識數(shu)(shu)據包(bao)類(lei)型以及數(shu)(shu)據（Data）總長度，本文設計(ji)的可靠(kao)傳(chuan)輸協議約(yue)定數(shu)(shu)據包(bao)長度最大不超過1436個字節(jie)，所以Length占用(yong)(yong)兩個字節(jie)空(kong)間即可。
MessageNumber （消(xiao)息傳輸序號）用(yong)于標識當前發送的(de)數據包在整(zheng)個消(xiao)息中的(de)位(wei)置，占用(yong)四個字節空(kong)間。
圖(tu)2 改進協議(yi)報文結(jie)構(gou)
2.3 可靠傳(chuan)輸內(nei)部機制
2.3.1 三次握手(shou)機制
TCP協議建立連(lian)接(jie)需(xu)要一個3次握手(shou)的(de)(de)(de)過(guo)(guo)程(cheng)[2]，連(lian)接(jie)成功后，對連(lian)接(jie)進(jin)行維護(hu)直到該連(lian)接(jie)被銷(xiao)毀。因此，仿照TCP連(lian)接(jie)的(de)(de)(de)建立過(guo)(guo)程(cheng)，我(wo)們(men)在連(lian)接(jie)開始(shi)的(de)(de)(de)時(shi)候，模擬TCP協議的(de)(de)(de)三次握手(shou)過(guo)(guo)程(cheng)，通過(guo)(guo)改進(jin)的(de)(de)(de)可靠UDP協議也進(jin)行了一個類似的(de)(de)(de)過(guo)(guo)程(cheng)。如圖3所示(shi)，該過(guo)(guo)程(cheng)分(fen)為(wei)三個步驟：
第一次握(wo)手(shou)：建立(li)連接時(shi)，網點A發送一個(ge)傳輸請(qing)求給網點B，并(bing)進入等待網點B的確認狀態中。
第(di)二次握手：網(wang)點B收到請(qing)求后，對該請(qing)求進行確認，發送一個請(qing)求應答的報文給網(wang)點A。
第三次(ci)握(wo)手(shou)：網點(dian)(dian)A收到網點(dian)(dian)B的(de)請求應答后，向網點(dian)(dian)B發(fa)送(song)確認（傳(chuan)輸應答），此確認包發(fa)送(song)完畢后，網點(dian)(dian)A和(he)網點(dian)(dian)B都進入完成狀態(tai)，三次(ci)握(wo)手(shou)成功建立。
圖3 簡單的3次握手
2.3.2 數(shu)據包確認機制
由于(yu)(yu)若是(shi)僅僅使用基于(yu)(yu)時(shi)間(jian)的(de)(de)選(xuan)擇性確(que)認機制(zhi)時(shi)，當傳輸(shu)大數據時(shi)，可能(neng)會由于(yu)(yu)帶寬問題，發(fa)(fa)送(song)(song)方A向接收(shou)方B發(fa)(fa)送(song)(song)大量(liang)數據包，而在預定時(shi)間(jian)間(jian)隔超時(shi)之(zhi)前，發(fa)(fa)送(song)(song)方A由于(yu)(yu)待證實(shi)的(de)(de)隊(dui)列(lie)得不(bu)到證實(shi)而無法繼續發(fa)(fa)送(song)(song)（此(ci)時(shi)待證實(shi)的(de)(de)隊(dui)列(lie)已滿），只(zhi)有等到接收(shou)方B定時(shi)器(qi)超時(shi)后，向A發(fa)(fa)送(song)(song)ACK包，證實(shi)發(fa)(fa)送(song)(song)隊(dui)列(lie)的(de)(de)消息，A才能(neng)繼續發(fa)(fa)送(song)(song)，大大降低了(le)數據傳輸(shu)效率。所以本文采用基于(yu)(yu)時(shi)間(jian)的(de)(de)選(xuan)擇性確(que)認和基于(yu)(yu)數據包數目的(de)(de)累積確(que)認相結合的(de)(de)確(que)認機制(zhi)，其(qi)算法如下：
if（數據包時間(jian)確認(ren)計時器到時）
{
接收方(fang)給發(fa)送方(fang)發(fa)送ACK包(bao) AND
數據包時(shi)間確認定(ding)時(shi)器歸零 AND
數(shu)據包(bao)接收計數(shu)器(qi)歸零;
}
else if （數據包接收計數器達到預定值）
{
接收(shou)方(fang)給發送方(fang)發送ACK包 AND
數據包時(shi)(shi)間確認(ren)定時(shi)(shi)器(qi)歸零 AND
數據包接收計數器(qi)歸零;
}
在這種確認機(ji)制(zhi)下，當移動(dong)網絡中帶(dai)寬不足，發送速率(lv)較小時(shi)，主要是基于時(shi)間(jian)的(de)選(xuan)擇性確認機(ji)制(zhi)起到(dao)作(zuo)用。
2.3.3 流量控制機制
協(xie)議(yi)中(zhong)(zhong)采取(qu)滑(hua)動(dong)窗(chuang)口的機制來(lai)實現數(shu)據(ju)傳輸中(zhong)(zhong)的流量控(kong)制的功能。滑(hua)動(dong)窗(chuang)口的機制在文獻[3][4]中(zhong)(zhong)都有提及。協(xie)議(yi)中(zhong)(zhong)的數(shu)據(ju)報文中(zhong)(zhong)用于標(biao)記數(shu)據(ju)傳遞的序(xu)號用2.2中(zhong)(zhong)設(she)計的MessageNumber表示，采用無符號整數(shu)，取(qu)值為0～232-1，對應(ying)圖(tu)中(zhong)(zhong)的大圓所(suo)代表的循環;發送方和(he)接收方的緩(huan)沖區(qu)大小設(she)置(zhi)相(xiang)同(tong)，分(fen)別對應(ying)圖(tu)中(zhong)(zhong)的兩個(ge)小循環。
利用(yong)滑(hua)(hua)動(dong)窗口(kou)(kou)(kou)(kou)實現流量(liang)控制(zhi)(zhi)的(de)(de)方法是：當接(jie)收方收到一(yi)條消息之后就將滑(hua)(hua)動(dong)窗口(kou)(kou)(kou)(kou)中(zhong)的(de)(de)接(jie)收窗口(kou)(kou)(kou)(kou)大小減1。只有在確定(ding)上層應(ying)(ying)用(yong)將接(jie)收到的(de)(de)消息處理(li)完成后才還原對(dui)接(jie)收窗口(kou)(kou)(kou)(kou)的(de)(de)大小的(de)(de)操作;接(jie)收方發(fa)現發(fa)送(song)(song)窗口(kou)(kou)(kou)(kou)的(de)(de)大小增加后，表明可(ke)以接(jie)收更多的(de)(de)數據(ju)，會向發(fa)送(song)(song)方發(fa)送(song)(song)相應(ying)(ying)的(de)(de)請求(qiu)，發(fa)送(song)(song)方根(gen)據(ju)請求(qiu)調整發(fa)送(song)(song)窗口(kou)(kou)(kou)(kou)的(de)(de)大小。通過這樣(yang)就能夠有效(xiao)的(de)(de)控制(zhi)(zhi)發(fa)送(song)(song)方發(fa)送(song)(song)數據(ju)的(de)(de)速度，達到流量(liang)控制(zhi)(zhi)的(de)(de)效(xiao)果，防止網絡擁塞(sai)的(de)(de)情況發(fa)送(song)(song)。
3.總結
本文以對比的(de)(de)方式介(jie)紹了(le)TCP和UDP傳(chuan)(chuan)輸(shu)協(xie)(xie)議(yi)，并(bing)指出了(le)各自的(de)(de)優缺(que)點：TCP協(xie)(xie)議(yi)是(shi)面向(xiang)連(lian)接的(de)(de)基(ji)(ji)于流模式的(de)(de)傳(chuan)(chuan)輸(shu)協(xie)(xie)議(yi)，高可(ke)靠(kao)但效(xiao)率(lv)較低;UDP協(xie)(xie)議(yi)是(shi)面向(xiang)無連(lian)接的(de)(de)基(ji)(ji)于數據報的(de)(de)傳(chuan)(chuan)輸(shu)協(xie)(xie)議(yi)，高效(xiao)但不可(ke)靠(kao)。最后(hou)，在UDP協(xie)(xie)議(yi)的(de)(de)基(ji)(ji)礎上，通過(guo)增加(jia)簡單的(de)(de)三次握手，確認重傳(chuan)(chuan)機制，滑動窗口機制，設計出了(le)一(yi)種基(ji)(ji)于UDP的(de)(de)可(ke)靠(kao)傳(chuan)(chuan)輸(shu)協(xie)(xie)議(yi)，使其在可(ke)靠(kao)性和傳(chuan)(chuan)輸(shu)效(xiao)率(lv)之(zhi)間達(da)到一(yi)個良好的(de)(de)統一(yi)與折(zhe)衷。
參考文獻
[1]Douglas er，林(lin)瑤，張(zhang)娟，王海等.用TCP/IP進行網際互聯(lian)――原理、協議與(yu)結構（第五版）[M].北京：電子(zi)工業出版社，2009.
篇5
C是與RCM2200配套使用的軟件開(kai)發語言(yan)，它擁(yong)有豐(feng)富的庫函數以便程序(xu)員編程時調用，結果表明，運用該語言(yan)能實(shi)現基于RCM2200以太網與異步串口之間的成(cheng)功通(tong)信(xin)。
關鍵詞 嵌入式系統；RCM2200；UDP報(bao)文；串口通信(xin)
1 引言
目前(qian)，嵌入(ru)(ru)(ru)式(shi)技術(shu)已經(jing)廣泛(fan)滲入(ru)(ru)(ru)并應用到各領(ling)域(yu)，涉(she)及(ji)到多種傳統及(ji)現代技術(shu)，形成(cheng)了前(qian)所未有的(de)(de)(de)多學科、多領(ling)域(yu)的(de)(de)(de)交叉與(yu)融合。由Z-World公(gong)司推出的(de)(de)(de)RCM2200[1]是(shi)一款低(di)成(cheng)本的(de)(de)(de)嵌入(ru)(ru)(ru)式(shi)微控制器(qi)核(he)心模塊，它采用Dynamic C?[2]這一專門為Z-World產品(pin)創建的(de)(de)(de)集成(cheng)的(de)(de)(de)C 編(bian)譯器(qi)、編(bian)輯器(qi)、鏈接(jie)器(qi)、裝載器(qi)和調試(shi)器(qi)，便于實現快速開(kai)發應用，加(jia)快產品(pin)投放(fang)到市場。
UDP協(xie)議[3][4]是比(bi)(bi)較著名的傳(chuan)輸層協(xie)議之一，它與TCP協(xie)議一樣是基于IP協(xie)議的，但與TCP不同(tong)的是它不需要(yao)(yao)協(xie)議層提供(gong)質量保證(zheng)(zheng)，因此，在(zai)需要(yao)(yao)實時數據傳(chuan)輸的情(qing)況下(xia)應用比(bi)(bi)較廣泛。并且，因為(wei)不提供(gong)質量保證(zheng)(zheng)，服(fu)務器沒有必要(yao)(yao)一直(zhi)處于等(deng)待狀(zhuang)態，從而大大減(jian)輕了服(fu)務器的負擔。在(zai)某些情(qing)況下(xia)，還可以根據需要(yao)(yao)給UDP報文(wen)加上一些質量保證(zheng)(zheng)控(kong)制，有很大的靈活度。
在不(bu)遠的(de)將來，將設(she)備與網絡相連將成為一(yi)種趨(qu)勢(shi)。在諸如GPS串(chuan)口數(shu)據網絡收發以及(ji)某(mou)些語(yu)音傳輸、實時監控等多種場合，實現以太網與異(yi)步串(chuan)口數(shu)據之間的(de)通信是非常必要的(de)。本文介(jie)紹了一(yi)種基于RCM2200嵌入式微(wei)控制器(qi)核心模塊利用(yong)UDP報文實現網絡與串(chuan)口互通的(de)方(fang)法，可(ke)以迅速實現將串(chuan)口與網絡相連接。
2 系統原理(li)及功能(neng)
RCM2200采用Rabbit半導體(ti)公司推出的(de)高性能8位器件－Rabbit2000型微處理器；帶RJ-45插口(kou)的(de)內置10Base-T端口(kou)簡(jian)化(hua)了網絡(luo)連(lian)接，便于(yu)開發帶以太網接口(kou)的(de)監控、通訊設備；配備有4個串(chuan)行口(kou)，方便擴(kuo)展聯接；擁(yong)有26根(gen)(gen)并行的(de)I/O引(yin)線以及16根(gen)(gen)可設置的(de)I/O引(yin)線，無須(xu)擴(kuo)展即可完成一(yi)般的(de)I/O任務；擁(yong)有256K Flash，128K SRAM， 用于(yu)代碼存儲(chu)和數據(ju)存儲(chu)；時間、日(ri)期、看門狗、定時器等一(yi)應俱全；且其采用雙列直插式引(yin)腳(jiao)，尺(chi)寸僅(jin)為59 x 41 x 22 mm。這種結構促進了嵌
入式系統的快速開發(fa)，并可實(shi)現(xian)集成(cheng)的以太網連接(jie)。
RCM2200系(xi)統的基本(ben)框架(jia)結構(gou)如圖1所示。
圖1 RCM2200系統結構
RCM2200采用Dynamic C?語(yu)言進(jin)行軟件開發(fa)，與(yu)標準C語(yu)言相比(bi)，Dynamic C的(de)改進(jin)和差(cha)異在(zai)于(yu)使得在(zai)功能強大(da)的(de)嵌入式系統上進(jin)行實時
編程變得非常容易。 語(yu)言的(de)擴展包括(kuo)多任務和優
先(xian)多任務的(de)(de)(de)構造(zao)，當(dang)供電失敗時，能夠(gou)(gou)保護(hu)寫入(ru)變量， 能夠(gou)(gou)寫入(ru)到中(zhong)斷程(cheng)序中(zhong)去(qu)。標準C函數(shu)庫，特(te)定板(ban)的(de)(de)(de)外圍(wei)驅動，芯片外圍(wei)設備，以(yi)(yi)及(ji)其他的(de)(de)(de)性(xing)能以(yi)(yi)源代碼的(de)(de)(de)形式包含在(zai)Dynamic C中(zhong)。完全支(zhi)持匯(hui)編語言(yan)，在(zai)對時間要求較高的(de)(de)(de)應用(yong)中(zhong)，匯(hui)編代碼可以(yi)(yi)方便的(de)(de)(de)與(yu)C代碼混用(yong)。
在該開發系統(tong)中將RCM2200的以(yi)太(tai)(tai)(tai)網(wang)(wang)(wang)接口與當地局域(yu)網(wang)(wang)(wang)相連(lian)，選擇一個串口與計算(suan)機(ji)的串口相連(lian)。由以(yi)太(tai)(tai)(tai)網(wang)(wang)(wang)發送(song)UDP報文給(gei)RCM2200微控制器(qi)核(he)心模塊經過(guo)(guo)處理(li)后通過(guo)(guo)串口發送(song)給(gei)計算(suan)機(ji)，由計算(suan)機(ji)串口發送(song)數據給(gei)RCM2200微控制器(qi)核(he)心模塊經過(guo)(guo)處理(li)后通過(guo)(guo)其上的網(wang)(wang)(wang)絡口發送(song)UDP報文給(gei)以(yi)太(tai)(tai)(tai)網(wang)(wang)(wang)，從而實現基于RCM2200以(yi)太(tai)(tai)(tai)網(wang)(wang)(wang)和(he)串口之間的通信(xin)。
3 UDP協議的實現(xian)
UDP協議是(shi)比較著名的傳(chuan)輸(shu)(shu)層協議之一，它使用(yong)IP作為網絡層協議，為應用(yong)程序發送(song)和接收數據報(bao)。但是(shi)，它提供無(wu)連(lian)接服務，是(shi)不可靠(kao)傳(chuan)輸(shu)(shu)。因此，UDP報(bao)文主要(yao)用(yong)于需要(yao)實時數據傳(chuan)輸(shu)(shu)的情(qing)況，一次傳(chuan)輸(shu)(shu)少量的數據。在(zai)某些(xie)對(dui)實時性要(yao)求(qiu)很高的場(chang)合，利用(yong)UDP報(bao)文進(jin)行(xing)數據傳(chuan)輸(shu)(shu)是(shi)非常必要(yao)的，但往(wang)(wang)往(wang)(wang)要(yao)采用(yong)一些(xie)可靠(kao)性方(fang)案(an)，以防(fang)止有漏傳(chuan)、誤傳(chuan)的現象發生。
3.1 客戶(hu)機/服(fu)務器程序(xu)設計模(mo)式
客(ke)戶機(ji)/服務器(qi)的(de)程序設計模式在網絡程序設計中被大量的(de)應(ying)用。這(zhe)種設計模式將(jiang)(jiang)整(zheng)個系統分(fen)為(wei)兩大部分(fen)——服務器(qi)部分(fen)和客(ke)戶機(ji)部分(fen)。客(ke)戶機(ji)向服務器(qi)提(ti)出請(qing)求，服務器(qi)對請(qing)求作相應(ying)的(de)處理將(jiang)(jiang)結果返(fan)回給客(ke)戶機(ji)。
根據不(bu)同的(de)(de)(de)實際情況，客戶(hu)機(ji)/服務器的(de)(de)(de)通信(xin)(xin)存在(zai)對(dui)稱(cheng)和(he)非(fei)對(dui)稱(cheng)兩種方(fang)(fang)式(shi)。在(zai)對(dui)稱(cheng)的(de)(de)(de)方(fang)(fang)式(shi)下(xia)，通信(xin)(xin)的(de)(de)(de)每一方(fang)(fang)都可能扮演主從(cong)角色；在(zai)非(fei)對(dui)稱(cheng)的(de)(de)(de)方(fang)(fang)式(shi)下(xia)，一方(fang)(fang)不(bu)可改變(bian)的(de)(de)(de)認為是(shi)主機(ji)，而另一方(fang)(fang)則是(shi)從(cong)機(ji)。無論是(shi)對(dui)稱(cheng)的(de)(de)(de)或是(shi)非(fei)對(dui)稱(cheng)的(de)(de)(de)，當服務被提供時必然存在(zai)客戶(hu)進程和(he)服務進程。基(ji)于UDP協議的(de)(de)(de)通信(xin)(xin)既(ji)可采(cai)用(yong)對(dui)稱(cheng)方(fang)(fang)式(shi)也可采(cai)用(yong)非(fei)對(dui)稱(cheng)方(fang)(fang)式(shi)。
3.2 數(shu)據報套接字
套接字（socket）是(shi)通信(xin)(xin)的(de)(de)(de)基石，是(shi)支(zhi)持TCP/IP協議(yi)的(de)(de)(de)網(wang)絡通信(xin)(xin)的(de)(de)(de)基本操作單(dan)元。它是(shi)網(wang)絡通信(xin)(xin)過程(cheng)(cheng)中(zhong)端點的(de)(de)(de)抽(chou)象表(biao)示，包含進行(xing)網(wang)絡通信(xin)(xin)必須的(de)(de)(de)五(wu)種信(xin)(xin)息：連接使用的(de)(de)(de)協議(yi)，本地(di)主機(ji)的(de)(de)(de)IP地(di)址(zhi)(zhi)，本地(di)進程(cheng)(cheng)的(de)(de)(de)協議(yi)端口，遠(yuan)地(di)主機(ji)的(de)(de)(de)IP地(di)址(zhi)(zhi)，遠(yuan)地(di)進程(cheng)(cheng)的(de)(de)(de)協議(yi)端口。
UDP協議支持(chi)數(shu)據報套(tao)接(jie)字(zi)。這種套(tao)接(jie)字(zi)可以(yi)采用(yong)客(ke)戶/服務器模(mo)式，以(yi)全雙工方(fang)式工作，接(jie)收(shou)發送可以(yi)同(tong)時進行，但并不保(bao)證數(shu)據傳(chuan)輸的可靠性、有序性和(he)無重(zhong)復(fu)性，需要由程序員負責管理數(shu)據報的排序和(he)可靠性。
3.3 使用(yong)Dynamic C實現(xian)UDP報文的傳(chuan)輸
Dynamic C提供(gong)了(le)許多支(zhi)持(chi)TCP/IP協議的(de)庫函(han)數。其中(zhong)，DCRTCP.LIB是最主要的(de)函(han)數庫。
下面將簡要介紹UDP協議下的基本通信流程。
3.3.1 調用(yong)本地初始化函數
void sock_init(void)
該(gai)函(han)(han)數(shu)將使(shi)用(yong)(yong)默(mo)認配(pei)置初始(shi)化本(ben)地信息包(bao)驅(qu)動器(qi)以及DCRTCP.LIB函(han)(han)數(shu)庫(ku)。該(gai)函(han)(han)數(shu)必須在其他網絡(luo)庫(ku)函(han)(han)數(shu)被使(shi)用(yong)(yong)前(qian)進行調用(yong)(yong)。
3.3.2 打開數據報套接(jie)字(zi)
int udp_open( *s， lport， remote_IP， port， *data_handler ())
其中的參(can)數(shu)解釋如下：
s : 指(zhi)向UDP套接字的指(zhi)針；
lport : 本地(di)協議端口(kou)；
remote_IP : 可接受的遠地主機IP地址，如(ru)果(guo)該項為-1，則支持廣播通(tong)信；
port : 可接受的(de)遠地進程協議端(duan)口，如果該項為-1，則為廣播數(shu)據報(bao)；
data_handler() : 如果(guo)接收到數據則調用該(gai)函數；
該(gai)函(han)數的返回值，如果成功返回非零，否則返回零值。
3.3.3 接收遠地主機發(fa)送的數據報
int udp_recv( *s， *buf_recv， recv_len)
當套接字初始化后用該(gai)函數掃(sao)描(miao)接收緩沖區，，察看(kan)是否有(you)數據報到達。其中，
buf_recv : 指向用于存放已到達數(shu)據報的(de)數(shu)組的(de)指針；
recv_len : 存(cun)放(fang)數據報的(de)(de)數組的(de)(de)大(da)小(xiao)。
如果(guo)接收到(dao)數據報(bao)則返回數據報(bao)的長度；否則返回-1。
3.3.4 發送(song)數據(ju)報(bao)給(gei)遠地(di)主機
int udp_send( *s， *buf_send， send_len )
調用該(gai)函數發(fa)送(song)數據報給遠地主機。如果成功返(fan)回(hui)(hui)該(gai)數據報的(de)長度，否則(ze)返(fan)回(hui)(hui)-1。
buf_send : 指向待(dai)發送數據報的(de)指針(zhen)；
send_len : 待發送數據報(bao)的長度。
3.3.5 網絡信息(xi)處理函
int tcp_tick( *s )
該函數(shu)將察(cha)看網(wang)絡連接(jie)(jie)狀態，檢查數(shu)據報(bao)(bao)的到達情況，處理新到數(shu)據報(bao)(bao)并重(zhong)傳丟失的數(shu)據報(bao)(bao)。若出(chu)現網(wang)絡連接(jie)(jie)被(bei)復位及套接(jie)(jie)字已關閉的情況或參量s為NULL，則返回(hui)值(zhi)為零；否則返回(hui)非零值(zhi)。
3.3.6 關閉套(tao)接(jie)字(zi)
void sock_close( *s )
當數據傳送工作完(wan)成(cheng)或傳送過程中發(fa)生(sheng)錯誤時，可調用該(gai)函數關閉套(tao)接字(zi)
4
串口通信的實現
4.1 RS232電平(ping)與TTL電平(ping)的轉換
PC機(ji)的串(chuan)行(xing)接口是符合EIA RS-232C規范的外部總線標準(zhun)接口，而(er)RCM2200配備有四個串(chuan)行(xing)接口，都是采用TTL電平，因此兩者之間必須進行(xing)電平轉(zhuan)換。以RCM2200的串(chuan)行(xing)口C（位于核(he)心模(mo)塊的J4插槽上）為例，電平轉(zhuan)換如圖2所示。
圖2 RS232與(yu)TTL電平轉(zhuan)換圖
4.2 使(shi)用Dynamic C實現(xian)串口數據的傳(chuan)輸(shu)
Dynamic C提(ti)供了一些與計(ji)算機串行口進行通信(xin)的(de)(de)函數可供用戶程序調用，下面(mian)簡要介紹其(qi)中的(de)(de)一部(bu)分(fen)。
4.2.1 打開串(chuan)行接(jie)口(kou)
int serXopen( bard )
bard : 長(chang)整(zheng)型(xing)，每秒鐘傳(chuan)送的比特(te)數。
該(gai)函(han)(han)數(shu)用于打開RCM2200的(de)串行接口，由于RCM2200核心(xin)模塊擁有四個串行口，故X可根據需要取為A\B\C\D其中一個。在調(diao)用該(gai)函(han)(han)數(shu)之前(qian)，還必須先定(ding)義(yi)串行口的(de)輸入輸出緩沖區大小，通常情況(kuang)下設(she)定(ding)為2n-1，否則(ze)就采(cai)用默(mo)認值31，但在編(bian)譯時(shi)會給(gei)出警告。該(gai)函(han)(han)數(shu)的(de)返回值：成功(gong)則(ze)為1，否則(ze)為0。
4.2.2 讀取(qu)PC機串行口數(shu)據
int serXgetc()
/* X = A|B|C|D */
程序可(ke)以調(diao)用該函數(shu)查詢串行口是否有字(zi)符(fu)來到(dao)，如果有，返回(hui)該字(zi)符(fu)值(zhi)；否則(ze)，返回(hui)值(zhi)-1。
4.2.3 發送(song)數據到PC機串行口
int serXputs( *s )
int serXwrite( s， length ) /* X = A|B|C|D */
這兩個函(han)數均可用于發(fa)送(song)字符串(chuan)給計算機的(de)串(chuan)行口，返回成功發(fa)送(song)的(de)字符數。
s : 待發送字符串的(de)首地址；
length : 待發送字(zi)符串的長度(du)。
4.2.4 關閉串(chuan)行口
void serXclose()
/* X = A|B|C|D */
該函數用于關(guan)閉已(yi)經打開的(de)串行口。
5
實現以太(tai)網(wang)與(yu)串口之間的通信
5.1
定義網絡以(yi)及串口初始化數(shu)據
在(zai)程序(xu)的開(kai)頭，必(bi)須使用#define定(ding)義一些初
始化數據，比如：RCM2200所使用(yong)的本地(di)IP地(di)址(zhi)以(yi)及(ji)端(duan)口(kou)，與之(zhi)通信(xin)的遠地(di)IP地(di)址(zhi)以(yi)及(ji)端(duan)口(kou)以(yi)及(ji)串口(kou)輸入輸出緩沖區的大小等等。
5.2 主程序
在主程(cheng)序(xu)中(zhong)調(diao)用PC機(ji)串(chuan)口發(fa)送(song)字(zi)符串(chuan)給(gei)RCM2200經過處理后再由RCM2200發(fa)送(song)UDP報(bao)文(wen)給(gei)以太網(wang)以及RCM2200接收以太網(wang)發(fa)送(song)來的(de)UDP報(bao)文(wen)后再送(song)給(gei)計算機(ji)的(de)串(chuan)行口兩個子程(cheng)序(xu)。
main()
{
sock_init(); //初始化網絡庫函數
: //打開串行口及網絡套接字
for(;;;)
{
tcp_tick(NULL);//察看套接字狀態
init_comm();//網絡發報文串口接收
comm_init();//串口(kou)發數據(ju)網絡接收(shou)
}
}
5.3網(wang)絡發報(bao)文(wen)串口接收
子程(cheng)序init_comm() 使用庫函數udp_recv查詢RCM2200以太網接(jie)(jie)口(kou)是否有UDP報(bao)(bao)文(wen)(wen)(wen)來到(dao)，如果沒(mei)有則返回(hui)主程(cheng)序，否則將UDP報(bao)(bao)文(wen)(wen)(wen)存(cun)放(fang)到(dao)buf_init數組(zu)中，然后調用serCputs(buf_init)通過RCM2200的(de)串(chuan)行口(kou)C發(fa)(fa)送(song)到(dao)計算機的(de)串(chuan)行口(kou)。值得一(yi)(yi)提(ti)的(de)是，當RCM2200接(jie)(jie)收(shou)到(dao)了(le)一(yi)(yi)次(ci)(ci)報(bao)(bao)文(wen)(wen)(wen)之后，它將自(zi)動關閉(bi)接(jie)(jie)收(shou)報(bao)(bao)文(wen)(wen)(wen)的(de)套(tao)接(jie)(jie)字(zi)，因此，如果還想(xiang)接(jie)(jie)受下一(yi)(yi)次(ci)(ci)發(fa)(fa)送(song)的(de)報(bao)(bao)文(wen)(wen)(wen)，必須再(zai)次(ci)(ci)調用函數udp_open打開(kai)該套(tao)接(jie)(jie)字(zi)。
5.4串(chuan)口發字(zi)符(fu)串(chuan)網絡接收
子(zi)程(cheng)序 comm_init()調用函數serCgetc()用于查詢計算機的(de)串(chuan)行口是否有(you)數據(ju)到(dao)(dao)來(lai)，如果(guo)沒有(you)則返回(hui)主程(cheng)序，否則將(jiang)接收(shou)到(dao)(dao)的(de)字符(fu)存儲到(dao)(dao)buf_comm數組(zu)中，直到(dao)(dao)檢(jian)測(ce)到(dao)(dao)結(jie)束(shu)符(fu)到(dao)(dao)來(lai)，將(jiang)字符(fu)串(chuan)以(yi)UDP報文的(de)形式(shi)通(tong)過(guo)函數udp_send發(fa)送(song)給以(yi)太網。如果(guo)發(fa)送(song)成功，則返回(hui)主程(cheng)序等待下一次數據(ju)的(de)到(dao)(dao)來(lai)，否則關(guan)閉(bi)該套(tao)接字后重新打開再返回(hui)主程(cheng)序等待。
5.5程序調試結果
在該(gai)程(cheng)序的調試過(guo)程(cheng)中，利用(yong)Visual C++語言(yan)編(bian)寫了一個接(jie)收和發送UDP報文的程(cheng)序用(yong)于以(yi)太(tai)網(wang)的計算機上，另外還使(shi)用(yong)了從網(wang)上下載(zai)的串口調試幫助軟件，結(jie)果(guo)表(biao)明，該(gai)程(cheng)序能實現基于RCM2200以(yi)太(tai)網(wang)與異(yi)步串口之間的成功通信。
結論
RCM2200是為了促進嵌入式系統的快速(su)開(kai)發和實現(xian)集成的以太網(wang)連接(jie)而設計的。集成的以太網(wang)口允許用(yong)戶通過使用(yong)經濟的網(wang)絡軟件(jian)進行(xing)瞬間的本地(di)連接(jie)或(huo)全球范圍的連接(jie)。另外，RCM2200還提供了四(si)個串行(xing)口用(yong)于(yu)和其他設備的串行(xing)口進行(xing)數(shu)據交換。
RCM2200使用Dynamic C軟件開發環境，支持C語言、匯編語言，擁有(you)豐富的庫函數可供用戶調(diao)用，并具(ju)有(you)單步編譯、斷點(dian)設(she)置、單步執行、代碼分(fen)解、監視表達式等優秀性能(neng)。
使用Dynamic C接收和發送UDP報文時，由于網絡對該報文的傳(chuan)輸不提供質量保證，在每完(wan)成一次操作后(hou)，必須及時檢查套接字的狀態，避免發生誤傳(chuan)、漏傳(chuan)以及套接字關閉等(deng)現象。在發送和接收串(chuan)口數據時，要注意使RCM2200的串(chuan)口數據傳(chuan)輸波特率與PC機保持一致，這(zhe)樣，才能(neng)保證正(zheng)確傳(chuan)輸。
參考文獻
【1】Z-World， Inc. RabbitCore RCM2200 User’s Manual 2001年
【2】Z-World， Inc. Dynamic C premier User’s Manual
1999年
篇6
【關鍵詞】 無線網(wang)絡(luo) 多媒體 通信 傳輸技術
引言：隨著(zhu)社會的發展，人們(men)生活水平日漸提升，其(qi)安全防護意識也有所增強，在先進技術支持下，無(wu)線網(wang)絡應(ying)急(ji)多(duo)媒(mei)(mei)體通(tong)信(xin)的應(ying)用(yong)(yong)愈加廣泛(fan)，不僅保證了(le)人們(men)的安全，還(huan)提高(gao)了(le)其(qi)生活質(zhi)量。但實(shi)際(ji)應(ying)用(yong)(yong)中，對應(ying)急(ji)多(duo)媒(mei)(mei)體通(tong)信(xin)有著(zhu)較高(gao)的要求，如：實(shi)時性(xing)、可(ke)靠性(xing)與(yu)連(lian)續性(xing)等，而無(wu)線網(wang)絡應(ying)急(ji)多(duo)媒(mei)(mei)體通(tong)信(xin)未能(neng)滿足上述(shu)要求，因(yin)此，本文探討了(le)其(qi)傳輸協議與(yu)通(tong)信(xin)終端系統(tong)，旨(zhi)在進一步提高(gao)其(qi)整體性(xing)能(neng)。
一、應急(ji)多媒體通信的無線網(wang)絡特點
其(qi)(qi)一，低(di)寬(kuan)(kuan)帶(dai)(dai)，通(tong)常(chang)情(qing)況下(xia)(xia)，其(qi)(qi)寬(kuan)(kuan)帶(dai)(dai)僅為1-2個(ge)數量級；其(qi)(qi)二(er)，時(shi)變(bian)性(xing)，對(dui)于(yu)應(ying)(ying)(ying)急(ji)通(tong)信終端來(lai)說，其(qi)(qi)主要(yao)用于(yu)移動(dong)情(qing)況，此時(shi)的應(ying)(ying)(ying)用環境會影(ying)響無線網絡的寬(kuan)(kuan)帶(dai)(dai)變(bian)化(hua)，特(te)(te)別(bie)是移動(dong)處于(yu)高(gao)速狀態下(xia)(xia)，可(ke)能發生突變(bian)；其(qi)(qi)三，非對(dui)稱性(xing)，無線網絡的上(shang)行與(yu)下(xia)(xia)行寬(kuan)(kuan)帶(dai)(dai)各異；其(qi)(qi)四，影(ying)響較(jiao)(jiao)大，在實際(ji)數據(ju)傳(chuan)(chuan)輸(shu)中(zhong)信道干擾較(jiao)(jiao)為嚴重(zhong)，同時(shi)誤碼率較(jiao)(jiao)高(gao)，通(tong)常(chang)情(qing)況下(xia)(xia)，與(yu)有線傳(chuan)(chuan)輸(shu)相(xiang)比(bi)，會高(gao)出幾(ji)個(ge)數量級。在實際(ji)研究與(yu)設(she)計過(guo)程中(zhong)，結合上(shang)述(shu)特(te)(te)點(dian)，要(yao)求應(ying)(ying)(ying)急(ji)多媒(mei)體通(tong)信傳(chuan)(chuan)輸(shu)技術(shu)應(ying)(ying)(ying)符合以(yi)下(xia)(xia)要(yao)求：第(di)一點(dian)，在保(bao)證(zheng)清晰(xi)度的前提下(xia)(xia)，占用較(jiao)(jiao)小的寬(kuan)(kuan)帶(dai)(dai)資源；第(di)二(er)點(dian)，寬(kuan)(kuan)帶(dai)(dai)大小變(bian)化(hua)過(guo)程中(zhong)應(ying)(ying)(ying)具備(bei)(bei)較(jiao)(jiao)強的自適應(ying)(ying)(ying)性(xing)；第(di)三點(dian)，多媒(mei)體數據(ju)傳(chuan)(chuan)輸(shu)時(shi)應(ying)(ying)(ying)保(bao)證(zheng)較(jiao)(jiao)小的延時(shi)；第(di)四點(dian)，數據(ju)傳(chuan)(chuan)輸(shu)應(ying)(ying)(ying)具備(bei)(bei)較(jiao)(jiao)高(gao)的可(ke)靠性(xing)與(yu)穩定性(xing)。
二、 應急多媒體通信(xin)流(liu)媒體協議(yi)的(de)選(xuan)用
目(mu)前，傳輸協議較多，其中使(shi)用(yong)(yong)頻率較高(gao)的有用(yong)(yong)戶數據報協議（UDP）與(yu)傳輸控制協議（TCP）。
1、UDP協(xie)議。此(ci)協(xie)議屬于無連(lian)接(jie)協(xie)議，其在(zai)網絡中主要用于處理數據(ju)(ju)包(bao)，它的(de)(de)(de)(de)(de)優(you)點為簡單的(de)(de)(de)(de)(de)分組(zu)格式、較(jiao)小(xiao)的(de)(de)(de)(de)(de)頭部(bu)開銷、較(jiao)快的(de)(de)(de)(de)(de)處理速度(du)，因此(ci)，UDP作為應用層時，所提供的(de)(de)(de)(de)(de)傳(chuan)輸服務則會缺少(shao)可(ke)靠性。在(zai)選用UDP協(xie)議時，應考慮UDP的(de)(de)(de)(de)(de)特性，通(tong)常情況下，其可(ke)用于大(da)信(xin)息(xi)量的(de)(de)(de)(de)(de)音頻(pin)(pin)、視頻(pin)(pin)與普通(tong)數據(ju)(ju)的(de)(de)(de)(de)(de)實(shi)時傳(chuan)送[1]。UDP協(xie)議的(de)(de)(de)(de)(de)快速與簡單等優(you)點較(jiao)為顯(xian)著，滿足了大(da)多數流媒體(ti)的(de)(de)(de)(de)(de)應用需求，但由于此(ci)協(xie)議缺少(shao)可(ke)靠性與可(ke)控(kong)性，導致其極易(yi)出現各種問題。
2、TCP協(xie)議。此協(xie)議的(de)(de)(de)設計主要是為(wei)了服務有線網絡(luo)，當前，其(qi)作(zuo)為(wei)傳輸層協(xie)議的(de)(de)(de)使用頻率較(jiao)高。由于有線網絡(luo)擁塞問題較(jiao)為(wei)嚴重，進(jin)而極易(yi)出現(xian)報文丟(diu)失，同時其(qi)出錯率也(ye)相對較(jiao)低，而使用TCP協(xie)議后，經發送方、接收(shou)方與網絡(luo)的(de)(de)(de)協(xie)調合作(zuo)，進(jin)而保證了有線網絡(luo)數據傳輸的(de)(de)(de)效(xiao)果。對于無線網絡(luo)而言，如(ru)果其(qi)使用TCP協(xie)議，為(wei)了保證多媒體數據的(de)(de)(de)高效(xiao)傳輸，需要較(jiao)大的(de)(de)(de)緩沖區，同時也(ye)需要充足(zu)的(de)(de)(de)寬帶，但在實(shi)際應用中不具備上述條件，隨之出現(xian)了諸多問題，如(ru)：較(jiao)高的(de)(de)(de)丟(diu)包率、較(jiao)差的(de)(de)(de)網絡(luo)狀況(kuang)等。
3、混(hun)(hun)合協(xie)議。現階段，流(liu)(liu)媒(mei)體傳(chuan)輸協(xie)議中最為流(liu)(liu)行的為RTSP/RTP/RTCP/UDP協(xie)議，實(shi)時(shi)傳(chuan)輸中應使用RTP與RTCP兩個端(duan)口，前(qian)者(zhe)(zhe)借(jie)助(zhu)UDP協(xie)議，以(yi)此(ci)保(bao)證了(le)實(shi)時(shi)視音頻(pin)數(shu)據的快速傳(chuan)輸，后者(zhe)(zhe)借(jie)助(zhu)TRCP協(xie)議，從而實(shi)現了(le)對傳(chuan)輸信息(xi)的有(you)效控(kong)制(zhi)(zhi)(zhi)(zhi)，通過二者(zhe)(zhe)，最終(zhong)實(shi)現了(le)高效傳(chuan)輸[2]。UDP具有(you)良好(hao)的實(shi)時(shi)性，但(dan)其不具備擁塞(sai)控(kong)制(zhi)(zhi)(zhi)(zhi)機(ji)制(zhi)(zhi)(zhi)(zhi)，導(dao)致UDP協(xie)議易丟失數(shu)據，進而擦混(hun)(hun)熟(shu)速率(lv)也將受到較大的影(ying)響；TCP擁有(you)擁塞(sai)控(kong)制(zhi)(zhi)(zhi)(zhi)機(ji)制(zhi)(zhi)(zhi)(zhi)、重傳(chuan)機(ji)制(zhi)(zhi)(zhi)(zhi)與流(liu)(liu)量(liang)控(kong)制(zhi)(zhi)(zhi)(zhi)機(ji)制(zhi)(zhi)(zhi)(zhi)，其實(shi)施需要借(jie)助(zhu)大量(liang)的反(fan)饋信息(xi)，而此(ci)時(shi)的信息(xi)會(hui)占用一(yi)定的寬(kuan)帶。在此(ci)情況下，本(ben)文結(jie)合二者(zhe)(zhe)的優(you)缺點，設計了(le)TCP/UDP混(hun)(hun)合協(xie)議，通過二者(zhe)(zhe)優(you)點的充分發揮，兼顧了(le)傳(chuan)輸效率(lv)與可靠性，以(yi)此(ci)保(bao)證了(le)無線(xian)網絡視音頻(pin)的高質(zhi)量(liang)傳(chuan)輸。
三(san)、ARM/DSP雙核嵌(qian)入(ru)式系統
在無(wu)線網絡中傳(chuan)(chuan)輸(shu)視(shi)音頻時(shi)，利用TCP/UDP混(hun)合協議(yi)，保(bao)證了(le)傳(chuan)(chuan)輸(shu)的(de)(de)(de)(de)(de)(de)(de)速度與(yu)質量，但為(wei)了(le)保(bao)證整個(ge)音視(shi)頻通信的(de)(de)(de)(de)(de)(de)(de)效果，仍需要(yao)(yao)注重其終端(duan)，在強有(you)力(li)終端(duan)支持下(xia)，進一步(bu)增加多(duo)媒(mei)體(ti)數(shu)據傳(chuan)(chuan)輸(shu)的(de)(de)(de)(de)(de)(de)(de)速度，進一步(bu)提(ti)高其通信的(de)(de)(de)(de)(de)(de)(de)質量。目前，國內外學者在研究(jiu)多(duo)媒(mei)體(ti)時(shi)，主(zhu)(zhu)(zhu)要(yao)(yao)關(guan)注的(de)(de)(de)(de)(de)(de)(de)內容為(wei)嵌(qian)入式終端(duan)系(xi)統(tong)(tong)計(ji)算能力(li)的(de)(de)(de)(de)(de)(de)(de)提(ti)高。本文提(ti)出(chu)了(le)ARM/DSP雙核移動多(duo)媒(mei)體(ti)嵌(qian)入式系(xi)統(tong)(tong)，其中ARM端(duan)的(de)(de)(de)(de)(de)(de)(de)主(zhu)(zhu)(zhu)控芯(xin)片為(wei)S3C2440A芯(xin)片，DSP端(duan)的(de)(de)(de)(de)(de)(de)(de)主(zhu)(zhu)(zhu)控芯(xin)片為(wei)BlackFin533芯(xin)片，它(ta)可支持WinCE與(yu)Linux系(xi)統(tong)(tong)，充(chong)分發揮了(le)ARM的(de)(de)(de)(de)(de)(de)(de)控制性能與(yu)DSP的(de)(de)(de)(de)(de)(de)(de)視(shi)頻數(shu)據處理能力(li)。ARM/DSP雙核嵌(qian)入式系(xi)統(tong)(tong)主(zhu)(zhu)(zhu)要(yao)(yao)是由ARM、DSP及(ji)其相(xiang)連接(jie)的(de)(de)(de)(de)(de)(de)(de)SPI接(jie)口三部分構成的(de)(de)(de)(de)(de)(de)(de)，ARM作為(wei)操(cao)作系(xi)統(tong)(tong)，主(zhu)(zhu)(zhu)要(yao)(yao)提(ti)供的(de)(de)(de)(de)(de)(de)(de)功能有(you)圖(tu)形界面、應(ying)用程(cheng)序與(yu)網絡通信功能；DSP需要(yao)(yao)提(ti)供SPI通信協議(yi)，從而實現了(le)相(xiang)應(ying)的(de)(de)(de)(de)(de)(de)(de)操(cao)作[3]。
總結：綜(zong)上所(suo)述，本文分析了(le)無(wu)線網絡應急多媒(mei)體(ti)通(tong)信(xin)傳輸(shu)技(ji)術，重點分析了(le)其傳輸(shu)協(xie)議及(ji)終端(duan)系(xi)統，相信(xin)，通(tong)過TCP/UDP混(hun)合協(xie)議及(ji)ARM/DSP雙核嵌入式系(xi)統的應用(yong)，無(wu)線網絡應急多媒(mei)體(ti)通(tong)信(xin)的質量將不(bu)斷提高。
參 考 文 獻
[1]何君燕，劉凱(kai). 井下無(wu)線多媒體傳感器網絡(luo)圖像傳輸技術研究[J]. 軟(ruan)件，2012，01：112-115.
篇7
關鍵詞：SOCKS；NAT；P2P；STUN；穿透
中圖分類號：TP393.03
IP網(wang)(wang)(wang)絡地(di)址(zhi)是整個(ge)(ge)(ge)互聯網(wang)(wang)(wang)的(de)(de)基(ji)礎，目前大多數(shu)網(wang)(wang)(wang)絡設備(bei)使用(yong)(yong)的(de)(de)都(dou)是IPv4地(di)址(zhi)。IPv4地(di)址(zhi)提(ti)出的(de)(de)時候沒有(you)(you)想到(dao)(dao)互聯網(wang)(wang)(wang)發展如此之(zhi)(zhi)快：根(gen)據2012年的(de)(de)思科報告(gao)，全球有(you)(you)23億(yi)互聯網(wang)(wang)(wang)用(yong)(yong)戶(hu)，到(dao)(dao)2017年，全球將(jiang)(jiang)會有(you)(you)約36億(yi)互聯網(wang)(wang)(wang)用(yong)(yong)戶(hu)。到(dao)(dao)2017年，將(jiang)(jiang)會有(you)(you)超過(guo)(guo)190億(yi)全球網(wang)(wang)(wang)絡聯接(jie)(jie)（固定/移動個(ge)(ge)(ge)人(ren)設備(bei)、M2M聯接(jie)(jie)等）。現(xian)(xian)在IPv4的(de)(de)地(di)址(zhi)已經不(bu)夠這(zhe)(zhe)些設備(bei)使用(yong)(yong)了(le)，為了(le)解(jie)決這(zhe)(zhe)個(ge)(ge)(ge)問題，IETF提(ti)供了(le)NAT[1][2]方(fang)案(an)，這(zhe)(zhe)個(ge)(ge)(ge)方(fang)案(an)使用(yong)(yong)NAT將(jiang)(jiang)網(wang)(wang)(wang)絡分為外(wai)網(wang)(wang)(wang)和私網(wang)(wang)(wang)，每個(ge)(ge)(ge)私網(wang)(wang)(wang)都(dou)可以重用(yong)(yong)，這(zhe)(zhe)個(ge)(ge)(ge)方(fang)案(an)大大緩解(jie)了(le)IPv4地(di)址(zhi)匱乏的(de)(de)問題。但是這(zhe)(zhe)個(ge)(ge)(ge)方(fang)案(an)導致(zhi)了(le)一(yi)(yi)個(ge)(ge)(ge)問題，對(dui)于想對(dui)外(wai)提(ti)供服務(wu)(wu)的(de)(de)NAT私網(wang)(wang)(wang)內(nei)的(de)(de)用(yong)(yong)戶(hu)而(er)(er)言(yan)，這(zhe)(zhe)個(ge)(ge)(ge)功能(neng)(neng)(neng)會受到(dao)(dao)限制，最主要的(de)(de)原(yuan)因是NAT外(wai)的(de)(de)用(yong)(yong)戶(hu)不(bu)能(neng)(neng)(neng)直接(jie)(jie)訪(fang)問到(dao)(dao)NAT內(nei)私網(wang)(wang)(wang)中(zhong)的(de)(de)計算(suan)機數(shu)據。這(zhe)(zhe)種情況導致(zhi)了(le)互聯網(wang)(wang)(wang)上P2P互相訪(fang)問的(de)(de)困難。不(bu)過(guo)(guo)目前還有(you)(you)很多應(ying)用(yong)(yong)需要這(zhe)(zhe)種服務(wu)(wu)器(qi)式的(de)(de)被動訪(fang)問，比如SOCKS4/5[3][4]協(xie)議(yi)，這(zhe)(zhe)個(ge)(ge)(ge)是最為知名的(de)(de)一(yi)(yi)種協(xie)議(yi)，通過(guo)(guo)這(zhe)(zhe)個(ge)(ge)(ge)協(xie)議(yi)服務(wu)(wu)，能(neng)(neng)(neng)夠透(tou)明地(di)中(zhong)轉服務(wu)(wu)器(qi)和客戶(hu)端之(zhi)(zhi)間的(de)(de)數(shu)據。然而(er)(er)NAT的(de)(de)引入導致(zhi)在NAT后面的(de)(de)用(yong)(yong)戶(hu)無(wu)法對(dui)外(wai)提(ti)供SOCKS4/5服務(wu)(wu)。本文(wen)試圖使用(yong)(yong)穿(chuan)透(tou)NAT的(de)(de)P2P技術，使在NAT內(nei)的(de)(de)SOCKS4/5服務(wu)(wu)也能(neng)(neng)(neng)提(ti)供給(gei)外(wai)部(bu)機器(qi)使用(yong)(yong)，真正實現(xian)(xian)對(dui)于互聯網(wang)(wang)(wang)的(de)(de)任何一(yi)(yi)個(ge)(ge)(ge)用(yong)(yong)戶(hu)都(dou)能(neng)(neng)(neng)夠直接(jie)(jie)訪(fang)問。
1 穿(chuan)透(tou)NAT的協議
為(wei)了(le)解決引入NAT設備后網(wang)絡互聯出現的(de)問(wen)題，有大(da)量協議被(bei)發明和使用，比如MIDCOM[5]、TURN[6]等，但是這些(xie)協議大(da)都需要第(di)(di)三方介入，這會導(dao)致(zhi)一(yi)些(xie)問(wen)題。如：中(zhong)轉(zhuan)第(di)(di)三方的(de)帶寬(kuan)、處理能力(li)以及實時性。這隨著NAT后面節點(dian)的(de)增(zeng)多，數據量的(de)增(zeng)長(chang)以及對于實時性的(de)嚴格(ge)要求等，這些(xie)協議處理都存在問(wen)題。我們希(xi)望兩個(ge)機器(qi)能夠實現真正(zheng)溝通，而不是通過中(zhong)繼(ji)的(de)方式。UPNP和STUN這兩個(ge)協議能夠實現這種真正(zheng)直接(jie)的(de)溝通。
1.1 UPNP[7]
UPNP（Universal Plug and Play）是由UPnP Forum推廣的(de)(de)一(yi)套網(wang)絡(luo)(luo)協(xie)議(yi)。該協(xie)議(yi)的(de)(de)目(mu)標(biao)(biao)是使家(jia)庭網(wang)絡(luo)(luo)和公司網(wang)絡(luo)(luo)中的(de)(de)各種設(she)備(bei)能(neng)夠相互無(wu)縫連接，并(bing)(bing)簡(jian)化(hua)相關網(wang)絡(luo)(luo)的(de)(de)實現(xian)。UPnP通(tong)過(guo)(guo)定(ding)義(yi)和基于開放(fang)、遵(zun)循因(yin)特網(wang)通(tong)訊網(wang)協(xie)議(yi)標(biao)(biao)準(zhun)的(de)(de)UPnP設(she)備(bei)控制(zhi)協(xie)議(yi)來實現(xian)這一(yi)目(mu)標(biao)(biao)。任何(he)設(she)備(bei)都能(neng)自(zi)動(dong)加入一(yi)個網(wang)絡(luo)(luo)，獲取自(zi)己的(de)(de)IP地址，宣(xuan)布自(zi)己的(de)(de)名字，根據請求檢查自(zi)身功能(neng)并(bing)(bing)且檢測出其它設(she)備(bei)和它們的(de)(de)功能(neng)。支持UPnP的(de)(de)設(she)備(bei)允許UPnP數據包通(tong)過(guo)(guo)IGD協(xie)議(yi)在沒有(you)(you)用(yong)戶交互的(de)(de)情況下(xia)，無(wu)障礙的(de)(de)通(tong)過(guo)(guo)NAT。但是UPnP的(de)(de)缺點是：它要求所(suo)有(you)(you)網(wang)絡(luo)(luo)中的(de)(de)設(she)備(bei)都支持UPnP，即使單(dan)臺設(she)備(bei)不(bu)符合UPnP標(biao)(biao)準(zhun)的(de)(de)，我們就無(wu)法(fa)實現(xian)一(yi)種P2P網(wang)絡(luo)(luo)。
1.2 STUN [8][9]
STUN協(xie)(xie)議是(shi)一種(zhong)輕量級的(de)(de)(de)客戶(hu)端-服務器模式的(de)(de)(de)協(xie)(xie)議，它(ta)(ta)不(bu)需要任何管理員進行網(wang)(wang)(wang)絡配置(zhi)，就能(neng)發(fa)(fa)(fa)現(xian)它(ta)(ta)們和公網(wang)(wang)(wang)之間是(shi)否存在NAT，并確(que)定NAT的(de)(de)(de)類型。STUN協(xie)(xie)議目(mu)前(qian)僅(jin)僅(jin)支持使(shi)用UDP報(bao)文穿(chuan)透(tou)(tou)(tou)Cone NAT[10]。此(ci)協(xie)(xie)議利用Cone NAT傳輸 UDP的(de)(de)(de)原(yuan)理進行穿(chuan)透(tou)(tou)(tou)[11][12][13]：私網(wang)(wang)(wang)內(nei)某個(ge)(ge)機器通(tong)過(guo)Cone NAT發(fa)(fa)(fa)送UDP數據(ju)到(dao)(dao)外(wai)網(wang)(wang)(wang)某個(ge)(ge)機器，內(nei)部(bu)(bu)IP地(di)址(zhi)(zhi)(zhi)和端口的(de)(de)(de)UDP數據(ju)經過(guo)Cone NAT被(bei)映(ying)(ying)射到(dao)(dao)一個(ge)(ge)外(wai)部(bu)(bu)地(di)址(zhi)(zhi)(zhi)，在某個(ge)(ge)時(shi)間段內(nei)這(zhe)個(ge)(ge)內(nei)部(bu)(bu)IP地(di)址(zhi)(zhi)(zhi)和端口將被(bei)轉換(huan)為固定外(wai)部(bu)(bu)IP地(di)址(zhi)(zhi)(zhi)和端口（這(zhe)個(ge)(ge)過(guo)程將被(bei)Cone NAT記錄，并且存儲為一個(ge)(ge)Session）。此(ci)后，如果外(wai)部(bu)(bu)Session對(dui)應的(de)(de)(de)機器發(fa)(fa)(fa)送UDP數據(ju)到(dao)(dao)這(zhe)個(ge)(ge)Cone NAT，Cone NAT會把這(zhe)個(ge)(ge)數據(ju)包轉發(fa)(fa)(fa)到(dao)(dao)內(nei)部(bu)(bu)映(ying)(ying)射的(de)(de)(de)這(zhe)個(ge)(ge)地(di)址(zhi)(zhi)(zhi)上。目(mu)前(qian)IETF定義的(de)(de)(de)STUN協(xie)(xie)議目(mu)前(qian)能(neng)夠穿(chuan)透(tou)(tou)(tou)Cone NAT，但是(shi)不(bu)能(neng)穿(chuan)透(tou)(tou)(tou)Symmetric NAT。不(bu)過(guo)我(wo)們可以通(tong)過(guo)修(xiu)改STUN協(xie)(xie)議來實現(xian)穿(chuan)透(tou)(tou)(tou)Symmetric NAT的(de)(de)(de)目(mu)的(de)(de)(de)。[14][15][16]
2 SOCKS4/5協議
SOCKS協(xie)議(yi)(yi)(yi)是一種(zhong)應用(yong)(yong)(yong)層(ceng)(ceng)次的(de)(de)協(xie)議(yi)(yi)(yi)，它(ta)提供一種(zhong)通(tong)(tong)用(yong)(yong)(yong)方(fang)(fang)案，能(neng)為(wei)應用(yong)(yong)(yong)程序提供基于TCP和(he)(he)UDP數據(ju)報文的(de)(de)服務，但是它(ta)不能(neng)ICMP之類的(de)(de)底層(ceng)(ceng)通(tong)(tong)訊協(xie)議(yi)(yi)(yi)，SOCKS協(xie)議(yi)(yi)(yi)從概念上來講是介(jie)于應用(yong)(yong)(yong)層(ceng)(ceng)和(he)(he)傳輸層(ceng)(ceng)之間的(de)(de)“中介(jie)層(ceng)(ceng)（shim-layer）”，SOCKS V4協(xie)議(yi)(yi)(yi)為(wei)HTTP、FTP、TELNET、WAI和(he)(he)GOPHER等基于TCP協(xie)議(yi)(yi)(yi)的(de)(de)客戶/服務器程序提供了(le)方(fang)(fang)案。新的(de)(de)SOCKS V5協(xie)議(yi)(yi)(yi)在(zai)SOCKS V4協(xie)議(yi)(yi)(yi)基礎上作了(le)進一步擴(kuo)展，從而可以支持UDP協(xie)議(yi)(yi)(yi)，并對其(qi)框架(jia)規定作了(le)擴(kuo)展，以支持安全認證方(fang)(fang)案。同時它(ta)還采用(yong)(yong)(yong)地(di)址(zhi)解析方(fang)(fang)案以支持域(yu)名和(he)(he)IPV6地(di)址(zhi)。
SOCKS協(xie)議(yi)利用握手（negotiation），請求（Requests），應答（Replies）等過程完成對于(yu)上述協(xie)議(yi)的(de)轉發。一(yi)般而言(yan)SOCKS4/5服(fu)務器通常(chang)綁定在1080端口上。
3 NAT穿透SOCKS4/5協議(yi)實現(xian)
3.1 協議方案
如圖(tu)1，為了(le)實(shi)現雙方(fang)(fang)(fang)都(dou)在NAT后(hou)的(de)(de)機器(qi)的(de)(de)SOCKS4/5之(zhi)間(jian)的(de)(de)直(zhi)接(jie)(jie)(jie)通(tong)(tong)信，我們需要(yao)一(yi)個雙方(fang)(fang)(fang)都(dou)能(neng)訪問的(de)(de)中(zhong)間(jian)服(fu)務(wu)先把(ba)兩邊的(de)(de)機器(qi)關聯(lian)起來。在公網(wang)上我們需要(yao)架設一(yi)個雙方(fang)(fang)(fang)都(dou)能(neng)夠聯(lian)系的(de)(de)服(fu)務(wu)器(qi)，然后(hou)通(tong)(tong)過STUN協議(yi)幫助雙方(fang)(fang)(fang)完(wan)(wan)成(cheng)直(zhi)接(jie)(jie)(jie)通(tong)(tong)信。一(yi)旦(dan)直(zhi)接(jie)(jie)(jie)聯(lian)系完(wan)(wan)成(cheng)，我們就不再(zai)需要(yao)公網(wang)中(zhong)間(jian)服(fu)務(wu)了(le)，此后(hou)我們采用可靠的(de)(de)UDP傳輸協議(yi)完(wan)(wan)成(cheng)SOCKS4/5客戶(hu)端(duan)和(he)服(fu)務(wu)器(qi)的(de)(de)直(zhi)接(jie)(jie)(jie)數(shu)據(ju)傳輸。
此協議分為兩個(ge)部分，首先是(shi)通(tong)過STUN協議完成NAT后兩個(ge)機器(qi)(qi)(qi)的SOCKS4/5客戶端關聯器(qi)(qi)(qi)和SOCKS4/5服務器(qi)(qi)(qi)關聯器(qi)(qi)(qi)的直接(jie)通(tong)信(xin)，然(ran)后使(shi)用可靠的UDP協議完成SOCKS4/5客戶端服務器(qi)(qi)(qi)的數(shu)據通(tong)信(xin)。
3.2 建立直接(jie)通信(xin)
我們可以使用STUN協議來幫助雙方都(dou)在NAT后(hou)的(de)機(ji)器建立(li)直(zhi)接(jie)的(de)通信。STUN協議通過一(yi)(yi)種(zhong)叫做UDP hole punching的(de)機(ji)制來實現這(zhe)一(yi)(yi)目的(de)。一(yi)(yi)旦(dan)完成這(zhe)個(ge)操作，兩個(ge)NAT設備后(hou)的(de)機(ji)器就(jiu)能夠實現直(zhi)接(jie)的(de)網絡通信而不再需要STUN服務(wu)器的(de)介入了(le)。
如圖(tu)2顯(xian)示SOCKS4/5客戶端關聯(lian)器(qi)和SOCKS4/5服(fu)務(wu)端關聯(lian)器(qi)通(tong)過STUN協議(yi)幫(bang)助建立直接通(tong)信的過程。
（1）客戶(hu)(hu)端(duan)關聯器(qi)(qi)通過(guo)NAT A連(lian)接到(dao)服(fu)(fu)務(wu)器(qi)(qi)，服(fu)(fu)務(wu)端(duan)關聯器(qi)(qi)通過(guo)NAT B連(lian)接到(dao)服(fu)(fu)務(wu)器(qi)(qi)，服(fu)(fu)務(wu)器(qi)(qi)記(ji)錄客戶(hu)(hu)端(duan)關聯器(qi)(qi)和(he)服(fu)(fu)務(wu)端(duan)關聯器(qi)(qi)的外網地址和(he)端(duan)口(kou)。
（2）服(fu)務器(qi)向客戶端(duan)(duan)關聯(lian)(lian)器(qi)發(fa)送服(fu)務端(duan)(duan)管理器(qi)的(de)外網(wang)地址和(he)端(duan)(duan)口消(xiao)(xiao)息，服(fu)務器(qi)向服(fu)務端(duan)(duan)關聯(lian)(lian)器(qi)發(fa)送客戶端(duan)(duan)關聯(lian)(lian)器(qi)的(de)外網(wang)地址和(he)端(duan)(duan)口消(xiao)(xiao)息。
（3）客戶(hu)端(duan)關聯(lian)(lian)器(qi)(qi)向服(fu)務(wu)端(duan)關聯(lian)(lian)器(qi)(qi)的(de)(de)外網地(di)址(zhi)和(he)端(duan)口發送hole punching消息。雖然這(zhe)個(ge)(ge)數據(ju)包(bao)在NAT B的(de)(de)時候會被阻止(zhi)（非Full Cone NAT禁(jin)止(zhi)沒經過關聯(lian)(lian)的(de)(de)外網IP直接訪問內網），但是(shi)這(zhe)個(ge)(ge)UDP數據(ju)包(bao)在經過NAT A的(de)(de)時候，會在NAT A上建立一個(ge)(ge)Session，這(zhe)個(ge)(ge)Session記錄了本地(di)客戶(hu)端(duan)關聯(lian)(lian)器(qi)(qi)與(yu)服(fu)務(wu)端(duan)關聯(lian)(lian)器(qi)(qi)外網地(di)址(zhi)的(de)(de)關聯(lian)(lian)信息。
（4）服務端(duan)關聯(lian)器發送回應消息(xi)到客戶(hu)端(duan)關聯(lian)器，NAT A由于有步驟(zou)3由hole punching消息(xi)建立的Session，NAT A將(jiang)會把這(zhe)個(ge)消息(xi)轉發到客戶(hu)端(duan)關聯(lian)器，完成后雙(shuang)方建立直接(jie)的消息(xi)通信。
3.3 SOCKS4/5數據傳輸
由于STUN協(xie)議(yi)(yi)僅(jin)僅(jin)支持(chi)UDP的穿透，但是SOCKS4協(xie)議(yi)(yi)只支持(chi)TCP的連接，為了兼容(rong)SOCKS4/5協(xie)議(yi)(yi)，我(wo)們(men)使用轉發的機制來保證(zheng)我(wo)們(men)的程序能夠完美匹(pi)配SOCKS4/5這兩種協(xie)議(yi)(yi)。
如圖3所示：
（1）SOCKS客戶端關聯器(qi)綁定本機端口1080。本地(di)(di)SOCKS客戶端程序（如(ru)IE等程序）設置本地(di)(di)SOCKS為本地(di)(di)127.0.0.1080。SOCKS客戶端按需要訪(fang)問(wen)某個(ge)公網服務器(qi)或者(zhe)遠端對方的私網服務器(qi)。
（2）客戶(hu)端(duan)關聯器(qi)(qi)接(jie)收(shou)到(dao)(dao)SOCKS客戶(hu)端(duan)發送(song)(song)過來的(de)數據，不做任何(he)改(gai)變，通(tong)過可靠的(de)UDP（如(ru)UDT協(xie)議，此協(xie)議可以(yi)提供類似(si)TCP的(de)可靠數據傳輸）數據傳輸發送(song)(song)到(dao)(dao)已經(jing)建立的(de)直(zhi)接(jie)通(tong)信的(de)服務端(duan)關聯器(qi)(qi)。
（3）服(fu)務端關聯器接收到可靠的(de)(de)(de)UDP傳輸(shu)過來(lai)的(de)(de)(de)數(shu)據，然后不做任何改(gai)變的(de)(de)(de)將(jiang)這(zhe)個數(shu)據通過TCP轉發(fa)到SOCKS4/5的(de)(de)(de)真正服(fu)務器程序（127.0.0.1：1080）。
（4）SOCKS服(fu)務(wu)器連接(jie)實際需要(yao)訪(fang)問的公網或(huo)者私網服(fu)務(wu)器（如(ru)需要(yao)訪(fang)問的HTTP服(fu)務(wu)）。
4 實驗測試
4.1 實驗設備
系統硬件：三臺(tai)PC，配置(zhi)：CPU P6 3.40GHz 4GM 內(nei)存
NAT設(she)備：兩臺NetGear WPN824路由器。
操(cao)作系統軟(ruan)件：Windows7。
4.2 實驗效果
程序經過(guo)實際測試證明，支(zhi)持NAT穿(chuan)透的(de)(de)SOCKS協議(yi)完全可行。測試顯示瀏覽器瀏覽網站(zhan)與直接使用SOCKS協議(yi)連接的(de)(de)效率(lv)基本接近，但是由(you)于中轉(zhuan)過(guo)程的(de)(de)花費(fei)，瀏覽大型網站(zhan)可能相(xiang)對于直接SOCKS連接慢了5%，不過(guo)這個基本不會影響(xiang)用戶的(de)(de)感受。
5 結論
SOCKS協(xie)(xie)議(yi)(yi)(yi)是客(ke)戶端(duan)(duan)/服(fu)務器(qi)模式(shi)(shi)，這(zhe)(zhe)種模式(shi)(shi)由(you)于NAT的(de)(de)引入(ru)導致(zhi)如果服(fu)務在NAT后(hou)面將(jiang)會出現問(wen)題。本論文使(shi)(shi)用一(yi)種新的(de)(de)客(ke)戶端(duan)(duan)-服(fu)務端(duan)(duan)關(guan)聯器(qi)方(fang)(fang)法(fa)使(shi)(shi)得(de)SOCKS協(xie)(xie)議(yi)(yi)(yi)能夠(gou)支持(chi)NAT的(de)(de)穿透(tou)，這(zhe)(zhe)個使(shi)(shi)得(de)SOCKS協(xie)(xie)議(yi)(yi)(yi)能夠(gou)被大多(duo)數工作在NAT后(hou)的(de)(de)計算機使(shi)(shi)用。并且這(zhe)(zhe)種關(guan)聯器(qi)方(fang)(fang)法(fa)與上層的(de)(de)協(xie)(xie)議(yi)(yi)(yi)沒有(you)任(ren)何直(zhi)接(jie)關(guan)系(xi)，我們可以擴展(zhan)此種協(xie)(xie)議(yi)(yi)(yi)，使(shi)(shi)得(de)很多(duo)原來不支持(chi)NAT穿透(tou)的(de)(de)協(xie)(xie)議(yi)(yi)(yi)也(ye)能夠(gou)被支持(chi)，比如：SMTP、POP3、IMAP、SNMP等。同(tong)樣，這(zhe)(zhe)個方(fang)(fang)法(fa)也(ye)能支持(chi)我們定義新的(de)(de)協(xie)(xie)議(yi)(yi)(yi)，比如類(lei)似QQ一(yi)樣即時P2P通訊協(xie)(xie)議(yi)(yi)(yi)。
參考文獻：
[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]王勇，崔修(xiu)濤(tao)，呂(lv)釗，李子成.基(ji)于探(tan)測對Symmetric NAT與端口受(shou)限NAT的穿透方案[J].計算機應用，2006，4（26）.
[16]楊(yang)璐，沈(shen)悅，蔣蕾.一種TCP協議穿透Symmetric NAT方案[J].計(ji)算機(ji)工程與應用，2007，43（6）.
篇8
在大型企業(ye)(ye)(ye)自(zi)動化(hua)系(xi)統(tong)中，上(shang)(shang)層(ceng)(ceng)(ceng)企業(ye)(ye)(ye)管理層(ceng)(ceng)(ceng)和生產監控(kong)層(ceng)(ceng)(ceng)一般都采(cai)用以(yi)太(tai)網和PC機，而下層(ceng)(ceng)(ceng)車間現(xian)場則(ze)采(cai)用現(xian)場總(zong)線和單(dan)片機測控(kong)設備。上(shang)(shang)下兩層(ceng)(ceng)(ceng)的(de)溝通(tong)(tong)，通(tong)(tong)常(chang)采(cai)用工(gong)業(ye)(ye)(ye)控(kong)制機加以(yi)太(tai)網卡(ka)，再加上(shang)(shang)PC機插槽(cao)上(shang)(shang)的(de)接口(kou)卡(ka)或并行打印口(kou)的(de)EPP接口(kou)卡(ka)實現(xian)。這(zhe)種連接方式(shi)成(cheng)本(ben)高(gao)，開發周期長(chang)。針對(dui)這(zhe)種情(qing)況，筆者設計一種單(dan)獨的(de)CAN以(yi)太(tai)網網關互連系(xi)統(tong)，成(cheng)功地實現(xian)以(yi)太(tai)網與現(xian)有CAN總(zong)線網的(de)直接數據互聯。
1 系統結構
系統總體結構分為三(san)部分：現(xian)場測控(kong)網絡(luo)（CAN網絡(luo)）、嵌入(ru)式透明SX52網關、以太網信息(xi)管理終端（如監控(kong)平臺和網絡(luo)數據庫等(deng)），如圖(tu)1所示。
CAN總(zong)(zong)線(xian)是一個設(she)備互連總(zong)(zong)線(xian)型控制網絡(luo)。在CAN總(zong)(zong)線(xian)上(shang)可以掛接多達110個設(she)備節(jie)點(dian)，各設(she)備間可以自(zi)主相(xiang)互通信，實(shi)現(xian)復雜(za)網絡(luo)控制系(xi)統。但(dan)設(she)備信息(xi)層(ceng)無法(fa)直接到達信息(xi)管(guan)理層(ceng)，要想設(she)備信息(xi)進入(ru)信息(xi)管(guan)理層(ceng)需通過數(shu)據(ju)網關。嵌入(ru)式透(tou)明(ming)SX52網關就是為此而設(she)計的。
透(tou)(tou)明式網(wang)(wang)(wang)(wang)(wang)(wang)關(guan)在以太(tai)(tai)(tai)網(wang)(wang)(wang)(wang)(wang)(wang)應用層構建和(he)解析(xi)完(wan)整的(de)(de)(de)CAN協(xie)議(yi)數(shu)(shu)據(ju)(ju)包(bao)。CAN協(xie)議(yi)數(shu)(shu)據(ju)(ju)包(bao)作為(wei)(wei)TCP／IP網(wang)(wang)(wang)(wang)(wang)(wang)絡(luo)應用層的(de)(de)(de)數(shu)(shu)據(ju)(ju)進行傳輸，它(ta)對(dui)通信(xin)數(shu)(shu)據(ju)(ju)的(de)(de)(de)具體實際意義不做任(ren)何解釋(shi)。透(tou)(tou)明式網(wang)(wang)(wang)(wang)(wang)(wang)關(guan)由通信(xin)處(chu)理器、CAN總線控(kong)(kong)制(zhi)器和(he)以太(tai)(tai)(tai)網(wang)(wang)(wang)(wang)(wang)(wang)控(kong)(kong)制(zhi)器三部(bu)分組成(cheng)。其中SX52單片(pian)機(ji)為(wei)(wei)核心處(chu)理器，它(ta)實現了(le)CAN控(kong)(kong)制(zhi)網(wang)(wang)(wang)(wang)(wang)(wang)絡(luo)與以太(tai)(tai)(tai)網(wang)(wang)(wang)(wang)(wang)(wang)之間的(de)(de)(de)協(xie)議(yi)轉(zhuan)(zhuan)換(huan)。以太(tai)(tai)(tai)網(wang)(wang)(wang)(wang)(wang)(wang)信(xin)息管(guan)(guan)理層的(de)(de)(de)控(kong)(kong)制(zhi)指(zhi)(zhi)令發送(song)到嵌入式透(tou)(tou)明SX52網(wang)(wang)(wang)(wang)(wang)(wang)關(guan)，將(jiang)(jiang)TCP／IP協(xie)議(yi)包(bao)數(shu)(shu)據(ju)(ju)轉(zhuan)(zhuan)換(huan)為(wei)(wei)CAN協(xie)議(yi)形式發送(song)至CAN控(kong)(kong)制(zhi)網(wang)(wang)(wang)(wang)(wang)(wang)絡(luo)中的(de)(de)(de)指(zhi)(zhi)定設備(bei)節點，完(wan)成(cheng)信(xin)息管(guan)(guan)理層對(dui)現場設備(bei)層的(de)(de)(de)控(kong)(kong)制(zhi)。同樣地，當CAN網(wang)(wang)(wang)(wang)(wang)(wang)絡(luo)上(shang)(shang)的(de)(de)(de)設備(bei)數(shu)(shu)據(ju)(ju)（如定時(shi)采樣數(shu)(shu)據(ju)(ju)或報警信(xin)息）要傳輸到信(xin)息管(guan)(guan)理層時(shi)，可將(jiang)(jiang)數(shu)(shu)據(ju)(ju)發送(song)到嵌入式透(tou)(tou)明SX52網(wang)(wang)(wang)(wang)(wang)(wang)關(guan)，再通過(guo)網(wang)(wang)(wang)(wang)(wang)(wang)關(guan)協(xie)議(yi)轉(zhuan)(zhuan)換(huan)程序將(jiang)(jiang)CAN協(xie)議(yi)數(shu)(shu)據(ju)(ju)封裝成(cheng)TCP／IP協(xie)議(yi)的(de)(de)(de)以太(tai)(tai)(tai)網(wang)(wang)(wang)(wang)(wang)(wang)數(shu)(shu)據(ju)(ju)幀發送(song)至以太(tai)(tai)(tai)網(wang)(wang)(wang)(wang)(wang)(wang)上(shang)(shang)的(de)(de)(de)監控(kong)(kong)計算(suan)機(ji)。
以(yi)太網(wang)(wang)信(xin)息管(guan)理(li)終端是一個(ge)(ge)根據用戶的(de)具體要求而設(she)計的(de)用戶層(ceng)應(ying)用軟件。它可(ke)以(yi)是一個(ge)(ge)WIN32監控(kong)程(cheng)序或網(wang)(wang)絡數據庫（記錄CAN節(jie)點設(she)備(bei)數據）軟件等；甚(shen)至可(ke)能是CAN節(jie)點設(she)備(bei)的(de)服務(wu)器軟件，為設(she)備(bei)提(ti)供較復雜的(de)數據處理(li)工(gong)作。
2 硬件設計
系統硬件(jian)分(fen)(fen)為(wei)兩(liang)大部分(fen)(fen)：CAN總線網(wang)絡設(she)(she)備接口設(she)(she)計和嵌(qian)入式(shi)透明SX52網(wang)關(guan)設(she)(she)計。
2．1 CAN總線網(wang)絡設(she)備接口設(she)計
CAN總線(xian)網絡(luo)設備接(jie)口(kou)(kou)設計(ji)較網關設計(ji)簡單(dan)。它是在完成設備功能(neng)的(de)(de)基礎上加入一個CAN通信控(kong)制器(qi)接(jie)口(kou)(kou)芯(xin)片，實現(xian)與(yu)CAN總線(xian)網絡(luo)的(de)(de)連接(jie)。考慮到開發成本和(he)靈活性，筆者(zhe)在設計(ji)中選(xuan)用PHILIPHS公司的(de)(de)獨立(li)CAN通信控(kong)制器(qi)SJA1000芯(xin)片和(he)CAN總線(xian)收發器(qi)82C250芯(xin)片。其結構如圖2所示。
2．2 嵌入式透明SX52網關設計
嵌入式透明網(wang)(wang)關設計是整個系統設計的(de)核心(xin)。其(qi)結構(gou)如圖3所示。它(ta)由(you)CAN控(kong)制器協(xie)議轉換(huan)(huan)模塊和(he)以太(tai)網(wang)(wang)控(kong)制器協(xie)議轉換(huan)(huan)模塊兩(liang)部分組(zu)成。網(wang)(wang)關硬(ying)件中SX52微(wei)處理(li)器起核心(xin)作用。它(ta)是由(you)美國Ubicom公司研制的(de)高速(su)可配置通信控(kong)制器，其(qi)處理(li)速(su)度相當高。在外接(jie)100MHz時鐘時，指令(ling)執行速(su)度可達100 MIPS。它(ta)可實現TCP／IP協(xie)議棧中的(de)ARP、IP、UDP、TCP、HTTP、SMTP、ICMP等網(wang)(wang)絡協(xie)議。
CAN控(kong)制(zhi)器(qi)協(xie)議轉換模塊硬件電路原理(li)如(ru)圖3左框圖。它由三部分組成：微控(kong)制(zhi)器(qi)SX52、獨(du)立CAN通信控(kong)制(zhi)器(qi)SJA1000、CAN總(zong)線收發器(qi)82C250。其中SX52為唯一的(de)CPU核心(xin)，負責(ze)SJA1000的(de)初始化(hua)，通過讀寫(xie)SJA1000內部寄存(cun)器(qi)實現數據的(de)接收、發送(song)和(he)錯誤(wu)處(chu)理(li)等。PCA82C250則提供對總(zong)線的(de)差(cha)動發送(song)能力和(he)對CAN控(kong)制(zhi)器(qi)的(de)差(cha)動接收能力。
以(yi)太網(wang)控(kong)制(zhi)器協(xie)議(yi)轉換模(mo)塊主(zhu)要由微控(kong)制(zhi)器SX52、以(yi)太網(wang)通信控(kong)制(zhi)器RTL8019AS和隔離(li)濾波器FB2002組(zu)成。RTL8019AS是臺灣Realtek公(gong)司制(zhi)造(zao)的(de)(de)(de)一(yi)種高集成度的(de)(de)(de)全雙工10Mbps以(yi)太網(wang)控(kong)制(zhi)芯片(pian)，實現(xian)了基于Ethernet協(xie)議(yi)的(de)(de)(de)MAC層的(de)(de)(de)全部功(gong)(gong)能(neng)，內(nei)置16KB的(de)(de)(de)SRAM、雙DMA通道和FIFO完成數(shu)(shu)(shu)據(ju)包(bao)的(de)(de)(de)接收(shou)和發送功(gong)(gong)能(neng)。在網(wang)關(guan)設計(ji)中(zhong)，使用跳線(xian)模(mo)式（JP置為(wei)(wei)(wei)高）硬配(pei)(pei)置RTL8019AS為(wei)(wei)(wei)8位(wei)模(mo)式。使用RTL8019的(de)(de)(de)低(di)(di)5位(wei)地(di)(di)址(zhi)線(xian)A0～A4以(yi)及(ji)低(di)(di)8位(wei)數(shu)(shu)(shu)據(ju)線(xian)D0～D7。SX52的(de)(de)(de)B口(kou)的(de)(de)(de)B0～B4腳作(zuo)為(wei)(wei)(wei)地(di)(di)址(zhi)線(xian)連(lian)接RTL8019AS的(de)(de)(de)低(di)(di)5位(wei)地(di)(di)址(zhi)線(xian)，B5～B7作(zuo)為(wei)(wei)(wei)控(kong)制(zhi)線(xian)分(fen)別連(lian)接讀寫時序控(kong)制(zhi)腳IORB、IOWB、IOCHRDY；C口(kou)作(zuo)為(wei)(wei)(wei)數(shu)(shu)(shu)據(ju)線(xian)連(lian)接RTL8019AS的(de)(de)(de)低(di)(di)8位(wei)數(shu)(shu)(shu)據(ju)線(xian)；A口(kou)保(bao)留，用作(zuo)日后(hou)擴展。圖3中(zhong)AT24C64為(wei)(wei)(wei)8KB EEPROM，主(zhu)要用來保(bao)存嵌入式透明SX－52網(wang)關(guan)的(de)(de)(de)配(pei)(pei)置信息，如網(wang)關(guan)IP地(di)(di)址(zhi)、MAC地(di)(di)址(zhi)和SJA1000的(de)(de)(de)ID網(wang)絡標示符、網(wang)絡掩碼AMR和總線(xian)定時（BTR0、BTR1）等。這樣，可以(yi)靈(ling)活方便地(di)(di)修改網(wang)關(guan)參數(shu)(shu)(shu)，適應(ying)不同(tong)環境(jing)，同(tong)時也考慮(lv)到以(yi)后(hou)的(de)(de)(de)擴展。
RTL8019AS除與SX52連接外，還將其網絡(luo)收發器的4根引腳TPOUT＋、TPOUT－、TPIN＋、TPIN－通過外接的隔離(li)濾波器FB2002與以太網相(xiang)連。采用(yong)隔離(li)濾波器FB2002是為了提高網絡(luo)通信的抗干擾能力。
3 軟件設計
整個(ge)互聯系(xi)統的(de)軟件設計(ji)可以分(fen)為三部分(fen)：CAN總線(xian)設備接(jie)口通信(xin)程(cheng)(cheng)序(xu)、透明網(wang)關協議轉換(huan)程(cheng)(cheng)序(xu)和以太(tai)網(wang)層應用程(cheng)(cheng)序(xu)設計(ji)。其中，CAN總線(xian)設備接(jie)口通信(xin)程(cheng)(cheng)序(xu)和透明網(wang)關協議轉換(huan)程(cheng)(cheng)序(xu)的(de)CAN控制器(qi)協議模(mo)塊在結(jie)構(gou)上有較(jiao)大的(de)相似性(xing)，但有可能因采(cai)用微控制器(qi)不同而導致(zhi)實(shi)現(xian)的(de)程(cheng)(cheng)序(xu)語(yu)言相異。因而，在此不作論述，而主(zhu)要討論后(hou)兩個(ge)方面的(de)程(cheng)(cheng)序(xu)設計(ji)。
3．1 透明網關協(xie)議轉換程(cheng)序(xu)
透(tou)明(ming)網(wang)(wang)(wang)(wang)關(guan)協(xie)議(yi)(yi)轉換(huan)程序(xu)的整體設(she)計思路(lu)為：當以太(tai)網(wang)(wang)(wang)(wang)應用(yong)層(ceng)有(you)(you)數(shu)(shu)(shu)(shu)據(ju)(ju)(ju)(ju)(ju)要發送(song)到CAN節點時(shi)(shi)，首先，數(shu)(shu)(shu)(shu)據(ju)(ju)(ju)(ju)(ju)發送(song)到透(tou)明(ming)網(wang)(wang)(wang)(wang)關(guan)由(you)以太(tai)網(wang)(wang)(wang)(wang)控(kong)制(zhi)(zhi)器協(xie)議(yi)(yi)轉換(huan)模塊從傳輸層(ceng)數(shu)(shu)(shu)(shu)據(ju)(ju)(ju)(ju)(ju)報文中(zhong)解析出完(wan)整的CAN協(xie)議(yi)(yi)數(shu)(shu)(shu)(shu)據(ju)(ju)(ju)(ju)(ju)包，存放在數(shu)(shu)(shu)(shu)據(ju)(ju)(ju)(ju)(ju)緩(huan)沖(chong)區A?再(zai)通(tong)知(zhi)總調(diao)(diao)度(du)(du)模塊，由(you)它(ta)調(diao)(diao)用(yong)CAN控(kong)制(zhi)(zhi)器協(xie)議(yi)(yi)模塊將CAN協(xie)議(yi)(yi)數(shu)(shu)(shu)(shu)據(ju)(ju)(ju)(ju)(ju)包發送(song)到CAN總線上(shang)。反過(guo)來(lai)，當CAN設(she)備有(you)(you)數(shu)(shu)(shu)(shu)據(ju)(ju)(ju)(ju)(ju)要發送(song)到用(yong)戶層(ceng)時(shi)(shi)，首先，數(shu)(shu)(shu)(shu)據(ju)(ju)(ju)(ju)(ju)發送(song)到透(tou)明(ming)網(wang)(wang)(wang)(wang)關(guan)由(you)CAN控(kong)制(zhi)(zhi)器協(xie)議(yi)(yi)模塊將完(wan)整的CAN協(xie)議(yi)(yi)數(shu)(shu)(shu)(shu)據(ju)(ju)(ju)(ju)(ju)包存放在數(shu)(shu)(shu)(shu)據(ju)(ju)(ju)(ju)(ju)緩(huan)沖(chong)區B?再(zai)通(tong)知(zhi)總調(diao)(diao)度(du)(du)模塊，由(you)它(ta)調(diao)(diao)用(yong)以太(tai)網(wang)(wang)(wang)(wang)控(kong)制(zhi)(zhi)器協(xie)議(yi)(yi)轉換(huan)模塊將完(wan)整的CAN協(xie)議(yi)(yi)數(shu)(shu)(shu)(shu)據(ju)(ju)(ju)(ju)(ju)包作為應用(yong)層(ceng)數(shu)(shu)(shu)(shu)據(ju)(ju)(ju)(ju)(ju)封裝起來(lai)，再(zai)發送(song)到以太(tai)網(wang)(wang)(wang)(wang)的應用(yong)層(ceng)。其程序(xu)結構如圖4所示。
3．1．1 CAN控制器(qi)協議模塊
CAN控制器協(xie)議轉換模塊程(cheng)(cheng)序(xu)(xu)主要由SJA1000的寄存器讀程(cheng)(cheng)序(xu)(xu)CANRead（）、寫程(cheng)(cheng)序(xu)(xu)CANWrite（）、初(chu)始(shi)化程(cheng)(cheng)序(xu)(xu)CANInit（）、發送程(cheng)(cheng)序(xu)(xu)txdsub（）、接收程(cheng)(cheng)序(xu)(xu)rxdsub（）程(cheng)(cheng)序(xu)(xu)組成。之(zhi)所以要編寫單獨的SJA1000的寄存器讀、寫子(zi)程(cheng)(cheng)序(xu)(xu)，這是由SX52芯(xin)片只(zhi)有I／O端口決定的。
選用(yong)CAN2．0A協議構建CAN總(zong)(zong)線(xian)控(kong)(kong)制網絡，對SJA1000的(de)初(chu)始(shi)化(hua)主要完成(cheng)控(kong)(kong)制寄存器(qi)(qi)CR、驗(yan)收代碼(ma)寄存器(qi)(qi)ACR、驗(yan)收屏(ping)蔽寄存器(qi)(qi)AMR、總(zong)(zong)線(xian)定時(shi)(shi)寄存器(qi)(qi)BTR0，1和輸出控(kong)(kong)制寄存器(qi)(qi)OCR的(de)設置。初(chu)始(shi)化(hua)完成(cheng)后，由(you)總(zong)(zong)調度(du)模塊監控(kong)(kong)SJA1000控(kong)(kong)制器(qi)(qi)。當CAN總(zong)(zong)線(xian)上有(you)數(shu)據到達時(shi)(shi)，它調用(yong)接收子程序(xu)rxdsub（），把這一幀數(shu)據包存入(ru)數(shu)據緩沖(chong)區B中，然(ran)后釋放接收緩沖(chong)器(qi)(qi)。同樣，當有(you)按(an)CAN2．0A協議格式組合成(cheng)的(de)一幀數(shu)據報文(wen)在數(shu)據緩沖(chong)區A中要發送到CAN總(zong)(zong)線(xian)上去(qu)時(shi)(shi)，總(zong)(zong)調度(du)模塊將調CAN發送子程序(xu)txdsub（）發送。
3．1．2 以(yi)太網控制器協議轉換模塊(kuai)
以太(tai)網(wang)控制(zhi)器協(xie)議(yi)轉換模塊(kuai)主要負責從UDP數(shu)據(ju)(ju)包中解析出完整CAN協(xie)議(yi)報(bao)(bao)文(wen)，存(cun)入(ru)數(shu)據(ju)(ju)緩(huan)沖區A。同時，可能(neng)將數(shu)據(ju)(ju)緩(huan)沖區B中的完整CAN協(xie)議(yi)報(bao)(bao)文(wen)封裝成UDP數(shu)據(ju)(ju)報(bao)(bao)，然后將其(qi)發送到以太(tai)網(wang)上。
在通(tong)信傳(chuan)(chuan)輸(shu)層采(cai)用UDP協(xie)(xie)(xie)議(yi)(yi)是考(kao)慮到CAN協(xie)(xie)(xie)議(yi)(yi)數據(ju)報(bao)為短幀形式（每個(ge)數據(ju)幀最多為8字(zi)節）。如果(guo)采(cai)用TCP傳(chuan)(chuan)輸(shu)協(xie)(xie)(xie)議(yi)(yi)，要(yao)(yao)傳(chuan)(chuan)輸(shu)8字(zi)節CAN協(xie)(xie)(xie)議(yi)(yi)數據(ju)，要(yao)(yao)先(xian)通(tong)過3次握手(shou)建立連接(jie)(jie)，再傳(chuan)(chuan)輸(shu)數據(ju)，之后還要(yao)(yao)通(tong)過握手(shou)釋放連接(jie)(jie)。這(zhe)(zhe)樣傳(chuan)(chuan)輸(shu)效(xiao)(xiao)率(lv)對有(you)限(xian)的(de)(de)(de)網(wang)絡(luo)資(zi)源來(lai)說無(wu)疑是一種浪費。而(er)UDP是無(wu)連接(jie)(jie)的(de)(de)(de)傳(chuan)(chuan)輸(shu)，可以提高網(wang)絡(luo)傳(chuan)(chuan)輸(shu)效(xiao)(xiao)率(lv)，同時，也減輕(qing)網(wang)關的(de)(de)(de)處理(li)任(ren)務。當(dang)然(ran)，UDP傳(chuan)(chuan)輸(shu)協(xie)(xie)(xie)議(yi)(yi)是不(bu)可靠的(de)(de)(de)，對于控(kong)制網(wang)絡(luo)來(lai)說，是不(bu)允(yun)許的(de)(de)(de)。為了提高通(tong)信的(de)(de)(de)可靠性，采(cai)用了回傳(chuan)(chuan)校驗(yan)(yan)機制。通(tong)過實驗(yan)(yan)測試表明(ming)這(zhe)(zhe)種方式是行(xing)之有(you)效(xiao)(xiao)的(de)(de)(de)。
以(yi)太網(wang)控制(zhi)器(qi)協(xie)議(yi)(yi)轉換模塊主(zhu)要由以(yi)太網(wang)卡驅(qu)動、ARP、UDP協(xie)議(yi)(yi)的若干個API函數(shu)組成，如NICInit（）、NICDMAInit（）、NICInitTxFrame（）、NICSendTxFrame（）、NICReadAgain（）、ARPCheckIfIs（）、ARPSendResponse（）、ARPSendStPacket（）、ICMPProcPktIn（）、UDPAppInit（）、IPGenCheckSum（）、、UDPAppProcPktIn（）、UDPStartPktOut（）和(he)UDPEndPktOut（）等。所使用的變量有：remoteIP[3:0]、myIP[3:0]、UDPRxSrcPortMSB、UDPRxSrcPortLSB、UDPRxDataLenMSB、UDPRxDataLenLSB、UDPTxSrcPortMSB,UDPTxSrcPortLSB、UDPTxDestPortMSB、UDPTxDestPortLSB、DPTxDataLenMSB, UDPTxDataLenLSB等。
系統首次執行或復位時(shi)，以太(tai)(tai)網控制器協(xie)議轉換模塊(kuai)將(jiang)(jiang)首先調(diao)用(yong)(yong)NICInit()和UDPAppInit()等進(jin)行NIC、ARP、IP、UDP和應(ying)用(yong)(yong)程(cheng)序(xu)(xu)(xu)(xu)的(de)初(chu)始化。初(chu)始化完成后(hou)，即進(jin)入(ru)主循環。在主循環中(zhong)，SX52將(jiang)(jiang)反復檢測RTL8019AS是(shi)(shi)(shi)否接(jie)收(shou)(shou)以太(tai)(tai)網幀(zhen)。當有數(shu)(shu)(shu)(shu)(shu)據(ju)(ju)(ju)(ju)(ju)被接(jie)收(shou)(shou)時(shi)，SX52調(diao)用(yong)(yong)NICDMAInit()和NICReadAgain()讀(du)入(ru)以太(tai)(tai)網幀(zhen)首部?再(zai)調(diao)用(yong)(yong)ARPCheckIfIs()判斷(duan)接(jie)收(shou)(shou)幀(zhen)是(shi)(shi)(shi)否為(wei)ARP數(shu)(shu)(shu)(shu)(shu)據(ju)(ju)(ju)(ju)(ju)。若(ruo)是(shi)(shi)(shi)ARP，則(ze)轉入(ru)ARPSendResponse()和ARPSendStPacket()子程(cheng)序(xu)(xu)(xu)(xu)進(jin)行ARP處理并發(fa)(fa)(fa)送響應(ying)ARP數(shu)(shu)(shu)(shu)(shu)據(ju)(ju)(ju)(ju)(ju)報(bao)(bao)(bao)；若(ruo)不是(shi)(shi)(shi)ARP，則(ze)判斷(duan)是(shi)(shi)(shi)否為(wei)IP數(shu)(shu)(shu)(shu)(shu)據(ju)(ju)(ju)(ju)(ju)報(bao)(bao)(bao)。若(ruo)非(fei)IP數(shu)(shu)(shu)(shu)(shu)據(ju)(ju)(ju)(ju)(ju)報(bao)(bao)(bao)則(ze)清除該以太(tai)(tai)網幀(zhen)；當所(suo)接(jie)收(shou)(shou)幀(zhen)包含IP數(shu)(shu)(shu)(shu)(shu)據(ju)(ju)(ju)(ju)(ju)報(bao)(bao)(bao)時(shi)，則(ze)需進(jin)一步(bu)判斷(duan)是(shi)(shi)(shi)ICMP數(shu)(shu)(shu)(shu)(shu)據(ju)(ju)(ju)(ju)(ju)報(bao)(bao)(bao)還是(shi)(shi)(shi)UDP數(shu)(shu)(shu)(shu)(shu)據(ju)(ju)(ju)(ju)(ju)報(bao)(bao)(bao)文(wen)。若(ruo)是(shi)(shi)(shi)ICMP數(shu)(shu)(shu)(shu)(shu)據(ju)(ju)(ju)(ju)(ju)報(bao)(bao)(bao)則(ze)執行ICMPProcPktIn()子程(cheng)序(xu)(xu)(xu)(xu)處理ICMP數(shu)(shu)(shu)(shu)(shu)據(ju)(ju)(ju)(ju)(ju)報(bao)(bao)(bao)并重發(fa)(fa)(fa)IP數(shu)(shu)(shu)(shu)(shu)據(ju)(ju)(ju)(ju)(ju)報(bao)(bao)(bao)；若(ruo)數(shu)(shu)(shu)(shu)(shu)據(ju)(ju)(ju)(ju)(ju)為(wei)UDP數(shu)(shu)(shu)(shu)(shu)據(ju)(ju)(ju)(ju)(ju)報(bao)(bao)(bao)文(wen)，則(ze)調(diao)用(yong)(yong)UDPProcPktIn()子程(cheng)序(xu)(xu)(xu)(xu)。該程(cheng)序(xu)(xu)(xu)(xu)將(jiang)(jiang)讀(du)入(ru)UDP數(shu)(shu)(shu)(shu)(shu)據(ju)(ju)(ju)(ju)(ju)報(bao)(bao)(bao)文(wen)首部的(de)數(shu)(shu)(shu)(shu)(shu)據(ju)(ju)(ju)(ju)(ju)并進(jin)行相應(ying)處理，還原出(chu)完整的(de)CAN協(xie)議數(shu)(shu)(shu)(shu)(shu)據(ju)(ju)(ju)(ju)(ju)報(bao)(bao)(bao)文(wen)存入(ru)數(shu)(shu)(shu)(shu)(shu)據(ju)(ju)(ju)(ju)(ju)緩沖區(qu)B中(zhong)，再(zai)通(tong)知總(zong)(zong)調(diao)度(du)程(cheng)序(xu)(xu)(xu)(xu)，由總(zong)(zong)調(diao)度(du)程(cheng)序(xu)(xu)(xu)(xu)調(diao)用(yong)(yong)CAN總(zong)(zong)線控制子程(cheng)序(xu)(xu)(xu)(xu)將(jiang)(jiang)CAN協(xie)議數(shu)(shu)(shu)(shu)(shu)據(ju)(ju)(ju)(ju)(ju)報(bao)(bao)(bao)文(wen)發(fa)(fa)(fa)往CAN總(zong)(zong)線。
反過來(lai)，當總(zong)調度程(cheng)序通知以太(tai)(tai)網控制器協(xie)議(yi)轉換模塊將(jiang)數(shu)據緩(huan)沖(chong)區B中準備好的CAN協(xie)議(yi)數(shu)據發(fa)送到(dao)以太(tai)(tai)網上時，它將(jiang)調用NICInitTxFrame()、UDPStartPktOut()、IPGenCheckSum()、IPStartPktOut()、NICSendTxFrame()、UDPEndPktOut()等子函(han)數(shu)進(jin)行發(fa)送處理，從而實(shi)現CAN總(zong)線(xian)到(dao)以太(tai)(tai)網的數(shu)據傳輸。
3．2 以太網層應用程序設計(ji)
以太網上的通信(xin)協(xie)議(yi)一般采(cai)用(yong)TCP／IP協(xie)議(yi)。本文采(cai)用(yong)流行的SOCKET套接字編(bian)程(cheng)，傳輸(shu)層協(xie)議(yi)選擇UDP（用(yong)戶數據報協(xie)議(yi)），通過Visual C＋＋編(bian)寫用(yong)戶層程(cheng)序。
篇9
關于網絡工程實習自(zi)我鑒(jian)定(ding)
四個(ge)星期的實(shi)習(xi)在轉(zhuan)眼中已(yi)經過去，回想當初剛(gang)剛(gang)開始進入實(shi)習(xi)的時(shi)候，腦子里是充滿著疑(yi)惑與(yu)好奇(qi)。好奇(qi)這次(ci)名為網絡工程實(shi)習(xi)的過程中，我們要(yao)開展什(shen)么樣的學(xue)習(xi)。而今在不知不覺中實(shi)習(xi)已(yi)進入了尾聲。
在這(zhe)次實(shi)習(xi)中，我(wo)們從開始的(de)(de)(de)(de)時候只有淺顯的(de)(de)(de)(de)網絡理論知識(shi)，轉變(bian)為更了解各種(zhong)網絡器(qi)(qi)件，在虛擬機的(de)(de)(de)(de)安裝與配(pei)(pei)置(zhi)(zhi)(zhi)中，掌握(wo)了各種(zhong)服務器(qi)(qi)的(de)(de)(de)(de)安裝與配(pei)(pei)置(zhi)(zhi)(zhi)，在路(lu)由器(qi)(qi)的(de)(de)(de)(de)配(pei)(pei)置(zhi)(zhi)(zhi)中，掌握(wo)了路(lu)由器(qi)(qi)的(de)(de)(de)(de)基(ji)本配(pei)(pei)置(zhi)(zhi)(zhi)命令以及路(lu)由器(qi)(qi)的(de)(de)(de)(de)各個(ge)模(mo)(mo)(mo)式。我(wo)們還學習(xi)了Vlan的(de)(de)(de)(de)劃(hua)分、動態路(lu)由的(de)(de)(de)(de)配(pei)(pei)置(zhi)(zhi)(zhi)、交(jiao)換機的(de)(de)(de)(de)配(pei)(pei)置(zhi)(zhi)(zhi)、VPN的(de)(de)(de)(de)配(pei)(pei)置(zhi)(zhi)(zhi)等(deng)等(deng)。實(shi)驗(yan)(yan)中構建(jian)拓(tuo)撲圖，對(dui)(dui)各個(ge)實(shi)驗(yan)(yan)器(qi)(qi)件進(jin)(jin)行(xing)地址(zhi)規劃(hua)和基(ji)礎配(pei)(pei)置(zhi)(zhi)(zhi)這(zhe)是(shi)(shi)每個(ge)實(shi)驗(yan)(yan)都(dou)必(bi)須進(jin)(jin)行(xing)的(de)(de)(de)(de)。如果這(zhe)兩(liang)步做(zuo)不(bu)好(hao)，就無(wu)法(fa)連(lian)通(tong)各個(ge)器(qi)(qi)件，它們之間是(shi)(shi)無(wu)法(fa)進(jin)(jin)行(xing)通(tong)信的(de)(de)(de)(de)。無(wu)法(fa)進(jin)(jin)行(xing)通(tong)信，也就意(yi)味著后面的(de)(de)(de)(de)各種(zhong)配(pei)(pei)置(zhi)(zhi)(zhi)都(dou)無(wu)法(fa)再(zai)進(jin)(jin)行(xing)下去。所(suo)以構建(jian)網絡拓(tuo)撲和進(jin)(jin)行(xing)地址(zhi)規劃(hua)使網絡連(lian)通(tong)是(shi)(shi)進(jin)(jin)行(xing)實(shi)驗(yan)(yan)的(de)(de)(de)(de)基(ji)礎。在第(di)十(shi)(shi)四(si)個(ge)實(shi)驗(yan)(yan)之前的(de)(de)(de)(de)實(shi)驗(yan)(yan)，對(dui)(dui)路(lu)由器(qi)(qi)的(de)(de)(de)(de)配(pei)(pei)置(zhi)(zhi)(zhi)時應(ying)該在哪種(zhong)模(mo)(mo)(mo)式下進(jin)(jin)行(xing)，指導(dao)書里都(dou)是(shi)(shi)給出的(de)(de)(de)(de);然而，在第(di)十(shi)(shi)四(si)個(ge)實(shi)驗(yan)(yan)之后，路(lu)由器(qi)(qi)的(de)(de)(de)(de)模(mo)(mo)(mo)式就沒有給出了，這(zhe)是(shi)(shi)對(dui)(dui)我(wo)們的(de)(de)(de)(de)要求的(de)(de)(de)(de)一個(ge)提升，要求我(wo)們更熟(shu)悉(xi)對(dui)(dui)路(lu)由器(qi)(qi)的(de)(de)(de)(de)配(pei)(pei)置(zhi)(zhi)(zhi)模(mo)(mo)(mo)式以及配(pei)(pei)置(zhi)(zhi)(zhi)命令才(cai)能完成實(shi)驗(yan)(yan)。
在第(di)十(shi)三個實(shi)(shi)驗 無線網絡(luo)設(she)計及(ji)配置中(zhong)第(di)一次用到Serial接(jie)口(kou) ，這與之(zhi)前常用的(de)(de)(de)FastEthernet接(jie)口(kou)有區別，在實(shi)(shi)驗中(zhong)其(qi)中(zhong)一個路(lu)(lu)有設(she)置了(le)(le)clock rate，而另外一個沒(mei)有設(she)置，或(huo)設(she)置里不一樣的(de)(de)(de)參數(shu)，導致兩個路(lu)(lu)由器(qi)無法(fa)通信，后來在同(tong)學的(de)(de)(de)指(zhi)導下(xia)找出(chu)了(le)(le)問題所(suo)在，從而解(jie)(jie)決(jue)了(le)(le)問題。在DHCP中(zhong)繼實(shi)(shi)驗中(zhong)，由于不了(le)(le)解(jie)(jie)DHCP中(zhong)繼的(de)(de)(de)具體實(shi)(shi)現過程以(yi)及(ji)沒(mei)有弄明白地址池的(de)(de)(de)配置所(suo)以(yi)遇到了(le)(le)麻煩(fan)，連接(jie)好(hao)網絡(luo)并連通后無法(fa)自動獲(huo)取(qu)IP地址雖然在同(tong)學的(de)(de)(de)協助下(xia)完(wan)成(cheng)了(le)(le)實(shi)(shi)驗，但是始(shi)終沒(mei)有很清晰的(de)(de)(de)實(shi)(shi)驗思路(lu)(lu)。
實(shi)習(xi)中所涉及的(de)(de)內容都是比(bi)較接近實(shi)際(ji)的(de)(de)，很(hen)有實(shi)際(ji)意義，特別是VPN的(de)(de)設計及配置部分(fen)，對認識(shi)(shi)(shi)現在的(de)(de)網(wang)絡構建都是有重大(da)的(de)(de)指導意義的(de)(de)，它將我們之前學的(de)(de)理論(lun)知(zhi)(zhi)識(shi)(shi)(shi)與實(shi)際(ji)聯系(xi)起來。加(jia)強了我們對知(zhi)(zhi)識(shi)(shi)(shi)的(de)(de)運用的(de)(de)能(neng)力(li)。
在實(shi)(shi)驗(yan)中除了(le)(le)學會(hui)了(le)(le)安裝虛擬機(ji)以(yi)為，還掌握了(le)(le)思(si)科的仿真(zhen)軟件(jian)的實(shi)(shi)驗(yan)，雖(sui)然是(shi)用仿真(zhen)軟件(jian)，并沒有接觸(chu)到實(shi)(shi)物，但(dan)是(shi)軟件(jian)的高(gao)仿真(zhen)性(xing)讓我(wo)(wo)們對(dui)實(shi)(shi)驗(yan)充(chong)滿著樂趣。實(shi)(shi)習中對(dui)各種網絡協議的內(nei)容都需要我(wo)(wo)們去了(le)(le)解、而老師給(gei)出的指導(dao)書里面，有些知識并不是(shi)很(hen)詳細，這就培(pei)養了(le)(le)我(wo)(wo)們自己查看資料的能(neng)力(li)。
通過這次(ci)實習，使我(wo)(wo)對網絡知識的(de)興趣有了更(geng)大的(de)提升(sheng)，這對我(wo)(wo)以后的(de)學習中(zhong)也是至(zhi)關重要的(de)。
網絡工程實習自我鑒定閱(yue)讀
我實習(xi)的(de)單位(wei)是(shi)學院，這是(shi)一所(suo)由市教(jiao)委、(集團)公(gong)司(si)與德(de)國基金會合作(zuo)的(de)一所(suo)探索、實踐德(de)國“雙(shuang)元(yuan)制”職業教(jiao)育(yu)模式的(de)全日制中(zhong)等(deng)專業學校(xiao)。我在學校(xiao)里主要是(shi)負責校(xiao)園內網(wang)的(de)管理，其涉及到校(xiao)園網(wang)網(wang)站的(de)正常(chang)登陸和訪問，校(xiao)園內各系部主機是(shi)否正常(chang)互聯，有無被病(bing)毒(du)感染、傳播。使得(de)校(xiao)園網(wang)內的(de)計算機能夠正常(chang)運(yun)行，做(zuo)好校(xiao)園網(wang)的(de)管理和維(wei)護工作(zuo)。
從學(xue)生(sheng)到實習(xi)工程師，短(duan)短(duan)幾(ji)個月(yue)的(de)工作過(guo)程使我(wo)受益(yi)匪淺(qian)。 不僅是在(zai)專業知識(shi)方面，最主要(yao)是在(zai)為人(ren)(ren)處事方面。社會在(zai)加速度地發(fa)生(sheng)變化，對人(ren)(ren)才的(de)要(yao)求(qiu)也越(yue)來越(yue)高，要(yao)用發(fa)展的(de)眼光看問題，得不斷提(ti)高思想認識(shi)，完善(shan)自己。作為一名it從業者，所受的(de)社會壓力將比其(qi)他行業更加沉重，要(yao)學(xue)會創(chuang)新求(qiu)變，以(yi)適應社會的(de)需要(yao)。在(zai)單(dan)位里，小到計(ji)算(suan)機的(de)組裝維修，大到服(fu)務器(qi)的(de)維護與(yu)測試，都需要(yao)一個人(ren)(ren)獨立完成。可以(yi)說(shuo)，近3個月(yue)的(de)工作使我(wo)成長了(le)不少，從中(zhong)有不少感悟，下面就是我(wo)的(de)一點心得：
第(di)一是要(yao)(yao)真誠(cheng)：你可以偽裝(zhuang)你的(de)(de)面孔(kong)你的(de)(de)心(xin)，但絕不可以忽略(lve)真誠(cheng)的(de)(de)力量。 第(di)一天去(qu)網(wang)絡(luo)中心(xin)實習，心(xin)里不可避免的(de)(de)有些疑惑：不知道老師怎(zen)么(me)樣，應該去(qu)怎(zen)么(me)做(zuo)啊(a)，要(yao)(yao)去(qu)干些什(shen)么(me)呢(ni)等(deng)等(deng)吧!踏進辦公(gong)室(shi)，只見幾個陌(mo)生(sheng)的(de)(de)臉孔(kong)。我(wo)微(wei)笑著和他們(men)(men)(men)打招(zhao)呼。從那天起，我(wo)養成(cheng)了一個習慣(guan)，每(mei)天早上見到(dao)他們(men)(men)(men)都(dou)要(yao)(yao)微(wei)笑的(de)(de)說聲：“老師早”，那是我(wo)心(xin)底真誠(cheng)的(de)(de)問候。我(wo)總覺(jue)得，經常(chang)有一些細微(wei)的(de)(de)東西容易被(bei)我(wo)們(men)(men)(men)忽略(lve)，比(bi)如輕輕的(de)(de)一聲問候，但它(ta)卻表達了對老師同事對朋友的(de)(de)尊(zun)重關心(xin)，也讓他人感覺(jue)到(dao)被(bei)重視與被(bei)關心(xin)。僅(jin)僅(jin)幾天的(de)(de)時間(jian)，我(wo)就(jiu)和老師們(men)(men)(men)打成(cheng)一片，很好的(de)(de)跟他們(men)(men)(men)交流溝(gou)通學習，我(wo)想(xiang)，應該是我(wo)的(de)(de)真誠(cheng)，換得了老師的(de)(de)信任(ren)。他們(men)(men)(men)把我(wo)當朋友也愿意(yi)(yi)指(zhi)導我(wo)，愿意(yi)(yi)分配給(gei)我(wo)任(ren)務。
第二是溝(gou)通(tong)：要(yao)想(xiang)在短暫的實習(xi)時間內，盡(jin)可能(neng)多的學一(yi)些(xie)東西，這就(jiu)需要(yao)跟老師(shi)有很(hen)(hen)好(hao)的溝(gou)通(tong)，加深彼(bi)此(ci)的了(le)解 ，剛到網絡中心，老師(shi)并不了(le)解你(ni)的工(gong)(gong)作學習(xi)能(neng)力，不清楚你(ni)會做那些(xie)工(gong)(gong)作，不清楚你(ni)想(xiang)了(le)解的知(zhi)識(shi)，所(suo)以(yi)跟老師(shi)很(hen)(hen)好(hao)的溝(gou)通(tong)是很(hen)(hen)必要(yao)的。同(tong)時我(wo)覺得這也是我(wo)們將(jiang)來走上(shang)社會的一(yi)把不可缺(que)少的鑰(yao)匙。通(tong)過溝(gou)通(tong)了(le)解，老師(shi)我(wo)我(wo)有了(le)大體了(le)解，邊(bian)有針對性的教我(wo)一(yi)些(xie)知(zhi)識(shi)，我(wo)對網絡部線，電(dian)(dian)腦(nao)硬件安裝，網絡故障(zhang)排除，工(gong)(gong)作原理應用比(bi)叫感興趣，所(suo)以(yi)老師(shi)就(jiu)讓(rang)我(wo)獨(du)立(li)的完(wan)成校內大小(xiao)部門的網絡檢(jian)修與電(dian)(dian)腦(nao)故障(zhang)排除工(gong)(gong)作。
如秘書(shu)處的(de)辦公室內局域網的(de)組件，中心服務機(ji)房的(de)服務器監測(ce)等，直接或間接保證(zheng)了(le)校園(yuan)網的(de)正(zheng)常(chang)運行和使用(yong)，在(zai)(zai)這方面的(de)工作中，真(zhen)(zhen)正(zheng)學到了(le)計算機(ji)教科書(shu)上(shang)所沒有或者真(zhen)(zhen)正(zheng)用(yong)到了(le)課(ke)本上(shang)的(de)知識，鞏固了(le)舊知識，掌握(wo)了(le)新知識，甚(shen)至在(zai)(zai)實(shi)踐中****了(le)書(shu)本上(shang)舊有的(de)不合實(shi)際的(de)知識，這才真(zhen)(zhen)正(zheng)體現了(le)知識的(de)真(zhen)(zhen)正(zheng)價值(zhi)，學以(yi)致(zhi)用(yong)。
第三是(shi)激情(qing)與(yu)耐心： 激情(qing)與(yu)耐心，就(jiu)(jiu)像火與(yu)冰，看似兩種完(wan)全(quan)不(bu)同的(de)(de)(de)(de)(de)東(dong)西，卻能(neng)(neng)碰撞出最美(mei)麗的(de)(de)(de)(de)(de)火花。在(zai)(zai)中(zhong)心時(shi)(shi)(shi)，老(lao)師就(jiu)(jiu)跟我(wo)說(shuo)，想(xiang)做電(dian)腦(nao)網絡(luo)這一(yi)塊，激情(qing)與(yu)耐心必不(bu)可少，在(zai)(zai)產品更新(xin)方面，這一(yi)行業(ye)就(jiu)(jiu)像做新(xin)聞工作，補(bu)斷(duan)的(de)(de)(de)(de)(de)更新(xin)，這就(jiu)(jiu)需要你有激情(qing)，耐心的(de)(de)(de)(de)(de)去(qu)不(bu)斷(duan)的(de)(de)(de)(de)(de)學習(xi)提(ti)高(gao)自(zi)己的(de)(de)(de)(de)(de)專(zhuan)業(ye)水平。在(zai)(zai)一(yi)些具體(ti)的(de)(de)(de)(de)(de)工作當中(zhong)也(ye)是(shi)這樣的(de)(de)(de)(de)(de)：記得(de)剛來學校(xiao)實習(xi)的(de)(de)(de)(de)(de)時(shi)(shi)(shi)候老(lao)師安(an)排我(wo)去(qu)綜合部安(an)裝win98操作系(xi)(xi)統，我(wo)本想(xiang)對(dui)我(wo)來說(shuo)是(shi)非常簡單(dan)的(de)(de)(de)(de)(de)事(shi)，可沒想(xiang)到出現(xian)了很多問題(ti)(ti)，開始是(shi)硬件問題(ti)(ti)：光驅(qu)(qu)不(bu)能(neng)(neng)用使(shi)我(wo)在(zai)(zai)一(yi)開始安(an)裝系(xi)(xi)統時(shi)(shi)(shi)就(jiu)(jiu)出現(xian)了急躁的(de)(de)(de)(de)(de)情(qing)緒(xu)，然后(hou)順利解(jie)決(jue)后(hou)，98系(xi)(xi)統的(de)(de)(de)(de)(de)驅(qu)(qu)動問題(ti)(ti)又讓我(wo)大傷腦(nao)筋!
從(cong)一開(kai)始的(de)(de)u驅動慢慢的(de)(de)安裝(zhuang)，再通過硬(ying)件(jian)監測軟(ruan)件(jian)查看硬(ying)件(jian)型號(hao)， 到最后把系統(tong)安裝(zhuang)成(cheng)功(gong)，用(yong)了(le)(le)(le)(le)(le)整(zheng)整(zheng)兩(liang)天的(de)(de)時間，通過自(zi)己(ji)(ji)的(de)(de)捉(zhuo)摸，調試，自(zi)此(ci)，我算(suan)(suan)是真正(zheng)的(de)(de)搞明白的(de)(de)計(ji)算(suan)(suan)機的(de)(de)硬(ying)件(jian)安裝(zhuang)，維護(hu)和更新，接著我又進行了(le)(le)(le)(le)(le)各(ge)種(zhong)計(ji)算(suan)(suan)機操作(zuo)系統(tong)的(de)(de)反(fan)復(fu)安裝(zhuang)調試，一遍又一遍的(de)(de)調試安裝(zhuang)，自(zi)然有些(xie)煩，但我用(yong)我的(de)(de)熱情耐心克服這些(xie)困(kun)難，問老(lao)師(shi)，查資料，一個(ge)個(ge)問題(ti)迎刃而解，自(zi)己(ji)(ji)在(zai)這方面的(de)(de)知識(shi)(shi)得到了(le)(le)(le)(le)(le)充(chong)實。這些(xie)在(zai)平常的(de)(de)書(shu)本上僅(jin)僅(jin)是獲得感性的(de)(de)認(ren)識(shi)(shi)在(zai)這里真的(de)(de)實踐(jian)了(le)(le)(le)(le)(le)，才算(suan)(suan)是真正(zheng)的(de)(de)掌握了(le)(le)(le)(le)(le)，也讓我認(ren)識(shi)(shi)到了(le)(le)(le)(le)(le)自(zi)己(ji)(ji)的(de)(de)不足，告誡自(zi)己(ji)(ji)，不管做什么，切忌眼高手低，要善于鉆研。
還有(you)(you)我感(gan)觸(chu)比(bi)較深(shen)的就(jiu)是(shi)查看(kan)log日志記(ji)錄，因(yin)為服務(wu)器的維護(hu)是(shi)復雜又艱辛的，既要(yao)保障(zhang)物理安(an)全又要(yao)保證系統(tong)安(an)全，這就(jiu)需要(yao)通過查詢(xun)log日志記(ji)錄，每一(yi)分鐘的服務(wu)器狀況(kuang)都有(you)(you)log日志記(ji)錄，而且它一(yi)是(shi)數(shu)據量大、二是(shi)有(you)(you)大量無用信(xin)息(xi)，所以查看(kan)log使(shi)非(fei)常“痛(tong)苦”的事情。像這些工作我深(shen)深(shen)地感(gan)覺到沒有(you)(you)激情與(yu)耐心(xin)是(shi)做不好(hao)的。
網絡工(gong)程實習個人自我鑒定(ding)
一、實習的基本概況
時間：20xx年x月x日—20xx年x月x日
地點：E607
(一)理論指導
1、 IEEE802標準和以太(tai)網：
㈠ OSI模(mo)(mo)型(xing)(xing)和TCP/IP協(xie)議：OSI模(mo)(mo)型(xing)(xing)中包(bao)括(kuo)物理層(ceng)、數(shu)(shu)據(ju)鏈路(lu)層(ceng)、網(wang)絡(luo)層(ceng)、傳輸層(ceng)、會(hui)話(hua)層(ceng)、表示(shi)層(ceng)、應用層(ceng)。㈡ IEEE802參考(kao)模(mo)(mo)型(xing)(xing)：物理層(ceng)被分(fen)為(wei)(wei)(wei)上下兩(liang)個子(zi)層(ceng)：對電纜介質的(de)說明;介質訪(fang)問(wen)單元(MAU)。數(shu)(shu)據(ju)鏈路(lu)層(ceng)也被分(fen)為(wei)(wei)(wei)兩(liang)個子(zi)層(ceng)：媒體訪(fang)問(wen)控制子(zi)層(ceng)(MAC);邏輯(ji)鏈路(lu)控制子(zi)層(ceng)(LLC)。㈢ 以(yi)(yi)太(tai)網(wang)簡介：①以(yi)(yi)太(tai)網(wang)的(de)物理地址(zhi)(zhi)可分(fen)為(wei)(wei)(wei)三(san)類：單播地址(zhi)(zhi)、廣播地址(zhi)(zhi)和多播地址(zhi)(zhi)。② 以(yi)(yi)太(tai)網(wang)訪(fang)問(wen)模(mo)(mo)式(shi)：CSMA/CD③ 以(yi)(yi)太(tai)網(wang)的(de)MAC幀格(ge)式(shi)：一(yi)種(zhong)是DIX Ethernet V2標(biao)準，另一(yi)種(zhong)是IEEE的(de)802.3標(biao)準。兩(liang)種(zhong)幀格(ge)式(shi)可以(yi)(yi)在同(tong)一(yi)以(yi)(yi)太(tai)網(wang)絡(luo)共(gong)存。兩(liang)種(zhong)幀格(ge)式(shi)都具有7個域(yu)：前(qian)導碼、幀首(shou)定(ding)界符、目的(de)MAC地址(zhi)(zhi)、源MAC地址(zhi)(zhi)、協(xie)議類型(xing)(xing)或數(shu)(shu)據(ju)長度(du)、數(shu)(shu)據(ju)、幀校(xiao)驗序列(lie)。
2、地址解析協(xie)議(ARP)
㈠ 物理地址與邏輯地址 ㈡ ARP協議(yi)簡介 ㈢ ARP報文格式 ㈣ ARP封裝 ㈤ ARP的運行過程 ㈥ ARP高速緩(huan)存 ㈦ ARP ㈧ 協議(yi)棧(zhan)實(shi)現代碼解析 ㈨ 各模(mo)塊(kuai)推薦(jian)流(liu)程：(1) ARP請求發送流(liu)程(2)輸(shu)入(ru)ARP數(shu)據包處理流(liu)程
3、網絡協議(IP)
㈠ IP協議簡介
㈡ ①IP地址：地址空間(jian) 。
②IP地(di)(di)址(zhi)的(de)表(biao)(biao)示(shi)方(fang)法 ：IP地(di)(di)址(zhi)有三種(zhong)常用的(de)表(biao)(biao)示(shi)方(fang)法：二進制表(biao)(biao)示(shi)方(fang)法、點分十進制表(biao)(biao)示(shi)方(fang)法和十六進制表(biao)(biao)示(shi)方(fang)法。
③IP地(di)(di)址的(de)分(fen)類(lei)(lei)(lei)： IP地(di)(di)址分(fen)成(cheng)5類(lei)(lei)(lei)：A類(lei)(lei)(lei)，B類(lei)(lei)(lei)，C類(lei)(lei)(lei)，D類(lei)(lei)(lei)和E類(lei)(lei)(lei)。其中A類(lei)(lei)(lei)、B類(lei)(lei)(lei)和C類(lei)(lei)(lei)地(di)(di)址是基本的(de)Internet地(di)(di)址，是用戶使用的(de)地(di)(di)址，D類(lei)(lei)(lei)地(di)(di)址用于廣播，E類(lei)(lei)(lei)地(di)(di)址為保留地(di)(di)址。
④網絡號(hao)和主(zhu)機 ：在分類(lei)(lei)編址(zhi)(zhi)的(de)A類(lei)(lei)，B類(lei)(lei)和C類(lei)(lei)地址(zhi)(zhi)中，IP地址(zhi)(zhi)可劃分為(wei)網絡號(hao)(net-id)和主(zhu)機號(hao)(host-id)。這兩部分長度都是可變的(de)，取決于地址(zhi)(zhi)的(de)類(lei)(lei)型。
⑤地(di)(di)(di)(di)(di)址(zhi)(zhi)(zhi)(zhi)(zhi)(zhi)類(lei)(lei)和地(di)(di)(di)(di)(di)址(zhi)(zhi)(zhi)(zhi)(zhi)(zhi)塊(kuai)：A類(lei)(lei)地(di)(di)(di)(di)(di)址(zhi)(zhi)(zhi)(zhi)(zhi)(zhi)共(gong)分為(wei)128個地(di)(di)(di)(di)(di)址(zhi)(zhi)(zhi)(zhi)(zhi)(zhi)塊(kuai)，每(mei)(mei)個地(di)(di)(di)(di)(di)址(zhi)(zhi)(zhi)(zhi)(zhi)(zhi)塊(kuai)都(dou)包(bao)(bao)含(han)有16777216個地(di)(di)(di)(di)(di)址(zhi)(zhi)(zhi)(zhi)(zhi)(zhi)。這(zhe)表明(ming)要使用這(zhe)類(lei)(lei)地(di)(di)(di)(di)(di)址(zhi)(zhi)(zhi)(zhi)(zhi)(zhi)的(de)機構(gou)(gou)一定是(shi)一個非常龐(pang)大的(de)機構(gou)(gou)。B類(lei)(lei)地(di)(di)(di)(di)(di)址(zhi)(zhi)(zhi)(zhi)(zhi)(zhi)共(gong)劃分為(wei)16384個地(di)(di)(di)(di)(di)址(zhi)(zhi)(zhi)(zhi)(zhi)(zhi)塊(kuai)，每(mei)(mei)個地(di)(di)(di)(di)(di)址(zhi)(zhi)(zhi)(zhi)(zhi)(zhi)塊(kuai)都(dou)包(bao)(bao)含(han)有65536個地(di)(di)(di)(di)(di)址(zhi)(zhi)(zhi)(zhi)(zhi)(zhi)。 C類(lei)(lei)地(di)(di)(di)(di)(di)址(zhi)(zhi)(zhi)(zhi)(zhi)(zhi)共(gong)劃分為(wei)2097152個地(di)(di)(di)(di)(di)址(zhi)(zhi)(zhi)(zhi)(zhi)(zhi)塊(kuai)，每(mei)(mei)個地(di)(di)(di)(di)(di)址(zhi)(zhi)(zhi)(zhi)(zhi)(zhi)塊(kuai)都(dou)包(bao)(bao)含(han)有256個地(di)(di)(di)(di)(di)址(zhi)(zhi)(zhi)(zhi)(zhi)(zhi)。D類(lei)(lei)地(di)(di)(di)(di)(di)址(zhi)(zhi)(zhi)(zhi)(zhi)(zhi)只有一個地(di)(di)(di)(di)(di)址(zhi)(zhi)(zhi)(zhi)(zhi)(zhi)塊(kuai)。它用來(lai)進行多播(bo)。E類(lei)(lei)地(di)(di)(di)(di)(di)址(zhi)(zhi)(zhi)(zhi)(zhi)(zhi)只有一個地(di)(di)(di)(di)(di)址(zhi)(zhi)(zhi)(zhi)(zhi)(zhi)塊(kuai)。它是(shi)保留地(di)(di)(di)(di)(di)址(zhi)(zhi)(zhi)(zhi)(zhi)(zhi)。
㈢ 特(te)殊的IP地址：1) 網絡(luo)地址：主(zhu)機號為全“0”的IP地址不分配給任何主(zhu)機，而是作為網絡(luo)本身的標識。
2) 直接廣播地址：主機(ji)號(hao)為(wei)全“1”的IP地址不分(fen)配給任何主機(ji)，用作廣播地址。
3) 有(you)限廣(guang)播地(di)址：32位為全“1”的IP地(di)址(255.255.255.255)稱(cheng)為有(you)限廣(guang)播地(di)址。
4) 主機本身(shen)地(di)(di)址：32位全“0”的IP地(di)(di)址(0.0.0.0)稱為主機本身(shen)地(di)(di)址。
5) 回環地(di)址：127.0.0.1稱為(wei)回環地(di)址，常用于本機上軟件測試和本機上網絡(luo)應用程(cheng)序之間的通(tong)信地(di)址。
㈣子網劃分
㈤IP報文格式
㈥IP封裝
㈦IP數據報分片
㈧IP數據報(bao)校(xiao)驗和
4、用戶數據報協(xie)議(yi)(UDP)
UDP協議簡介(jie)：UDP(用(yong)(yong)(yong)(yong)戶數(shu)據報協議)，主要用(yong)(yong)(yong)(yong)來(lai)支持那些需要在(zai)計算機之間傳輸數(shu)據的(de)網(wang)絡(luo)應用(yong)(yong)(yong)(yong)。包括網(wang)絡(luo)視頻會議系統在(zai)內(nei)的(de)眾多的(de)客戶/服務器模式(shi)的(de)網(wang)絡(luo)應用(yong)(yong)(yong)(yong)都需要使用(yong)(yong)(yong)(yong)UDP協議。UDP報文(wen)(wen)格(ge)式(shi)：每個UDP報文(wen)(wen)稱為(wei)一個用(yong)(yong)(yong)(yong)戶數(shu)據報(User Datagram)，用(yong)(yong)(yong)(yong)戶數(shu)據報分為(wei)兩(liang)個部(bu)分：UDP首部(bu)和UDP數(shu)據。首部(bu)被分為(wei)四個16位的(de)字段(duan)，分別代表源端口號﹑目的(de)端口號﹑報文(wen)(wen)的(de)長度以及UDP校驗和。
UDP應用：1)UDP適用于這樣的(de)(de)進程(cheng)(cheng)，它(ta)需(xu)要簡單的(de)(de)請(qing)求——響應通信，而較少考(kao)慮流(liu)量控(kong)制(zhi)(zhi)和差(cha)(cha)錯控(kong)制(zhi)(zhi)。對于需(xu)要傳送(song)成(cheng)塊數據(ju)的(de)(de)進程(cheng)(cheng)，如FTP，則通常(chang)不使(shi)用UD;2)UDP適用于具有(you)內部流(liu)量控(kong)制(zhi)(zhi)和差(cha)(cha)錯控(kong)制(zhi)(zhi)機制(zhi)(zhi)的(de)(de)進程(cheng)(cheng);3)對多(duo)播和廣播來說，UDP是個比較合適的(de)(de)傳輸層協(xie)議;;4)UDP可用于管理(li)進程(cheng)(cheng)，如SNMP協(xie)議;5)UDP可用于某些(xie)路由(you)選擇更新協(xie)議。
5、傳輸控(kong)制協議(TCP)
TCP(傳(chuan)輸(shu)控(kong)制協(xie)議)協(xie)議是TCP/IP協(xie)議族中(zhong)的(de)面向連接的(de)、可靠的(de)傳(chuan)輸(shu)層協(xie)議。
6、域名服務(DNS)
DNS(域名服務)是一種能夠完(wan)成從域名到地址或從地址到域名的(de)映射系(xi)統(tong)。使(shi)用DNS，計(ji)算機用戶(hu)可以間接的(de)通過域名來完(wan)成通信。
7、超(chao)文(wen)本傳(chuan)輸協(xie)議(HTTP)
HTTP(超文本傳輸(shu)協議(yi))主要用于訪問萬維(wei)網上的數(shu)據。HTTP在(zai)熟知端口80上使用TCP服務。
8、遠程登錄與(yu)文(wen)件傳輸協議(TELNET與(yu)FTP )
FTP(文件(jian)傳輸協議)提供了一(yi)(yi)種通過(guo)TCP傳送文件(jian)的方法，可以將(jiang)一(yi)(yi)個文件(jian)從一(yi)(yi)個系統復制到另一(yi)(yi)個系統中。
(二)實習過(guo)程或步(bu)驟
1、領略真實的MAC幀：
將主(zhu)機A和B作為(wei)一組(zu)，主(zhu)機B啟動協(xie)議(yi)(yi)分析器，新(xin)建(jian)捕(bu)獲窗口進行(xing)數(shu)據捕(bu)獲并設置過濾(lv)條件(提(ti)取ICMP協(xie)議(yi)(yi));主(zhu)機A ping 主(zhu)機B，察看主(zhu)機B協(xie)議(yi)(yi)
分析(xi)器捕獲的(de)數(shu)據包(bao)，分析(xi)MAC幀格式(shi)(shi)。然后將主機B的(de)過濾器恢復為默認狀態。實驗(yan)結果為: MAC幀格式(shi)(shi)：
其(qi)中目的MAC地(di)址：00142A—503336 ;源MAC地(di)址：00142A—522C15;型或數據長(chang)度(du)：0800
2、ARP報文
將(jiang)主(zhu)機A、B、C、D、E、F作為一組進行實(shi)驗。
①主機(ji)B在命令(ling)(ling)行方式(shi)下輸入staticroute_config命令(ling)(ling)，開(kai)啟靜態路由服(fu)務(wu)。
②主機(ji)A、B、C、D、E、F在命令行下運行“arp -d”命令，清空ARP高(gao)速(su)緩存。
③機A、B、C、D、E、F重新啟動協(xie)議分析器，打開(kai)捕獲窗(chuang)口進行(xing)數據捕獲并設置過濾條(tiao)件(提取ARP、ICMP)。
④主機(ji)A ping 主機(ji)E(172.16.0.2)。
⑤主機A、B、C、D、E、F停止數據捕獲，察看(kan)協(xie)議分析器(qi)(qi)中采集到的(de)(de)(de)(de)ARP報文(wen)。通過實驗了解(jie)(jie)到：單一(yi)ARP請(qing)求(qiu)報文(wen)不(bu)能(neng)跨(kua)越(yue)子(zi)網(wang)進行地址解(jie)(jie)析，ARP報文(wen)的(de)(de)(de)(de)存(cun)活空間只限在(zai)子(zi)網(wang)內。因為(wei)ARP報文(wen)的(de)(de)(de)(de)請(qing)求(qiu)是(shi)在(zai)網(wang)關(guan)下(xia)的(de)(de)(de)(de)數據請(qing)求(qiu)，脫(tuo)離子(zi)網(wang)ARP報文(wen)也(ye)就自動失效，并且ARP請(qing)求(qiu)是(shi)以廣(guang)播的(de)(de)(de)(de)方式進行，而廣(guang)播報文(wen)不(bu)能(neng)跨(kua)越(yue)子(zi)網(wang)。ARP地址解(jie)(jie)析在(zai)跨(kua)越(yue)子(zi)網(wang)的(de)(de)(de)(de)通信中所起到的(de)(de)(de)(de)作(zuo)(zuo)用(yong)：作(zuo)(zuo)用(yong)是(shi)解(jie)(jie)析網(wang)關(guan)的(de)(de)(de)(de)MAC地址，ARP本身無法跨(kua)躍(yue)不(bu)同網(wang)段。當數據要發往(wang)外部網(wang)絡時，通常是(shi)首先(xian)使用(yong)ARP請(qing)求(qiu)網(wang)關(guan)路由(you)器(qi)(qi)的(de)(de)(de)(de)MAC地址，之后將數據發往(wang)網(wang)關(guan)路由(you)器(qi)(qi)，由(you)網(wang)關(guan)路由(you)器(qi)(qi)進行轉(zhuan)發。
3、編(bian)輯并發送(song)IP數據報(bao)：
將主機A、B、C、D、E、F作(zuo)為一組進行實驗。
①主(zhu)機(ji)B在命令(ling)行(xing)方式(shi)下輸入staticroute_config命令(ling)，開啟靜(jing)態路由服(fu)務。
②主機(ji)(ji)A啟(qi)動協議編(bian)輯器，編(bian)輯一(yi)個(ge)IP數(shu)(shu)據報，其(qi)中(zhong)：MAC層(ceng)：目(mu)的(de)MAC地(di)(di)址(zhi)(zhi)：主機(ji)(ji)B的(de)MAC地(di)(di)址(zhi)(zhi)(對應于172.16.1.1接口(kou)的(de)MAC) 源(yuan)MAC地(di)(di)址(zhi)(zhi)：主機(ji)(ji)A的(de)MAC地(di)(di)址(zhi)(zhi)。協議類型或數(shu)(shu)據長(chang)度：0800。IP層(ceng)：總(zong)長(chang)度：IP層(ceng)長(chang)度。生存時(shi)間：128。源(yuan)IP地(di)(di)址(zhi)(zhi)：主機(ji)(ji)A的(de)IP地(di)(di)址(zhi)(zhi)(172.16.1.2)。目(mu)的(de)IP地(di)(di)址(zhi)(zhi)：主機(ji)(ji)E的(de)IP地(di)(di)址(zhi)(zhi)(172.16.0.2)。校驗(yan)和：在(zai)其(qi)它(ta)所有(you)字(zi)段填(tian)(tian)充完畢(bi)后計(ji)算并填(tian)(tian)充。自定義字(zi)段：數(shu)(shu)據：填(tian)(tian)入大于1字(zi)節的(de)用(yong)戶數(shu)(shu)據。
③在主機B(兩(liang)塊(kuai)網卡分(fen)別(bie)打開兩(liang)個捕(bu)獲(huo)(huo)窗口)、E上(shang)啟動(dong)協議分(fen)析器，設置(zhi)過濾條(tiao)件(提取IP協議)，開始捕(bu)獲(huo)(huo)數據(ju)。
④主機A發送(song)第1步中(zhong)編輯好的報文。
⑤主(zhu)機B、E停止捕獲數據(ju)，在捕獲到(dao)的數據(ju)中查找主(zhu)機A所發送的數據(ju)報。
⑥將第1步中主機A所(suo)編(bian)輯(ji)的報文(wen)的“生存(cun)時間”設(she)置為1，重新計算校驗和。
⑦主機(ji)B、E重新開始捕獲數(shu)據。
⑧主機A發送第(di)5步中(zhong)編輯好(hao)的報文。
⑨主(zhu)(zhu)機B、E停止捕(bu)獲數(shu)(shu)據，在捕(bu)獲到的(de)(de)(de)數(shu)(shu)據中(zhong)查找(zhao)主(zhu)(zhu)機A所發(fa)送(song)的(de)(de)(de)數(shu)(shu)據報(bao)(bao)。觀察實(shi)驗過(guo)程得：在實(shi)驗過(guo)程中(zhong)主(zhu)(zhu)機A所編輯的(de)(de)(de)報(bao)(bao)文，經過(guo)主(zhu)(zhu)機B到達主(zhu)(zhu)機E后，報(bao)(bao)文數(shu)(shu)據發(fa)生變(bian)化(hua)，變(bian)化(hua)的(de)(de)(de)原因是：他們不在一個子(zi)網上。主(zhu)(zhu)機B能接受到A發(fa)送(song)的(de)(de)(de)報(bao)(bao)文，主(zhu)(zhu)機E不能，因為此(ci)(ci)報(bao)(bao)文的(de)(de)(de)生存時間太短，致使主(zhu)(zhu)機E無法捕(bu)獲此(ci)(ci)報(bao)(bao)文。
4、UDP單(dan)播(bo)通信(xin)
將(jiang)主機A、B、C、D、E、F作(zuo)為一組進行(xing)實驗。
①主機B、C、D、E、F上啟動(dong)“實驗平臺工具(ju)欄中的UDP工具(ju)”，作為服務器端，監聽端口設置(zhi)為2483，“創建”成功(gong)。
②主機(ji)C、E上啟(qi)動(dong)協(xie)議(yi)分(fen)析器開(kai)始捕獲數據，并設置(zhi)過(guo)濾條件(提取UDP協(xie)議(yi))。
③主機A上啟(qi)動“實驗平臺(tai)工具欄中的UDP工具”，作為客戶端(duan)，以(yi)主機C的IP為目的IP地址，以(yi)2483為端(duan)口，填寫數據并(bing)發(fa)送。
④察看主機B、C、D、E、F上的(de)“UDP工具”接收的(de)信(xin)息。
⑤察(cha)看主機C協議分析器上(shang)的UDP報(bao)文
⑥主(zhu)(zhu)(zhu)機(ji)A上(shang)(shang)使(shi)用協議編(bian)輯器向主(zhu)(zhu)(zhu)機(ji)E發(fa)送(song)UDP報(bao)文，其中： 目的(de)(de)MAC地(di)址：E的(de)(de)MAC地(di)址;目的(de)(de)IP地(di)址：主(zhu)(zhu)(zhu)機(ji)E的(de)(de)IP地(di)址;目的(de)(de)端(duan)口：2483;校驗(yan)和(he)：0發(fa)送(song)此(ci)報(bao)文 ⑦主(zhu)(zhu)(zhu)機(ji)B、C、D、E、F關閉(bi)服務端(duan)，主(zhu)(zhu)(zhu)機(ji)A關閉(bi)客戶端(duan)。從(cong)實驗(yan)中得出結論：UDP是(shi)(shi)一(yi)個(ge)(ge)(ge)無連(lian)(lian)接協議，傳輸數(shu)據(ju)之前源(yuan)端(duan)和(he)終端(duan)不(bu)建立連(lian)(lian)接，當它想傳送(song)時就簡單地(di)去抓取來自應用程(cheng)序的(de)(de)數(shu)據(ju)，并盡可能快地(di)把它扔到網(wang)絡上(shang)(shang)。在發(fa)送(song)端(duan)，UDP傳送(song)數(shu)據(ju)的(de)(de)速度(du)僅僅是(shi)(shi)受應用程(cheng)序生成數(shu)據(ju)的(de)(de)速度(du)、計(ji)算機(ji)的(de)(de)能力和(he)傳輸帶寬(kuan)的(de)(de)限制;在接收端(duan)，UDP把每(mei)個(ge)(ge)(ge)消(xiao)(xiao)息段放(fang)在隊(dui)列中，應用程(cheng)序每(mei)次從(cong)隊(dui)列中讀(du)一(yi)個(ge)(ge)(ge)消(xiao)(xiao)息段。
(2) 由于傳(chuan)輸數據(ju)不(bu)建立連接(jie)，因此也就不(bu)需(xu)要維護連接(jie)狀(zhuang)態(tai)，包括收發狀(zhuang)態(tai)等(deng)，因此一臺服務機可(ke)同(tong)時向多個客戶機傳(chuan)輸相同(tong)的(de)消息。
5、頁面訪問
①將主(zhu)機(ji)A和B作為一組
② 主機A清空IE緩存。
③主機B啟動協議(yi)(yi)分析器開始捕獲(huo)數據，并設置過(guo)濾條件(jian)(提(ti)取HTTP協議(yi)(yi))。
④主(zhu)機(ji)A啟動IE瀏覽器(qi)，在(zai)“地址”框(kuang)中(zhong)輸入服(fu)務(wu)器(qi)的ip/experiment，并(bing)連接(jie)，服(fu)務(wu)器(qi)IP默認為(wei)172.16.0.253。主(zhu)機(ji)B停止(zhi)捕獲數據(ju)(ju)，分析捕獲到的數據(ju)(ju)。分析實(shi)驗可知，實(shi)驗中(zhong)使用(yong)http的get方法(fa) (從(cong)服(fu)務(wu)器(qi)請求一個文檔(dang))。作用(yong)：請求獲取Request-URI所標識的資源。
6、使用TCP連接工具與服務器進行命令交互(hu)
將主(zhu)機(ji)A和B作為一組;1、主(zhu)機(ji)B啟動(dong)協(xie)(xie)議分析器開始捕獲數(shu)據(ju)并設置過濾條件(提取TCP協(xie)(xie)議)。2、主(zhu)機(ji)A啟動(dong)TCP工(gong)具連接FTP服務(wu)器。
(1)主機A啟動“實驗平臺工(gong)具(ju)欄中(zhong)的TCP工(gong)具(ju)”。①選(xuan)中(zhong)“客戶(hu)端(duan)”單選(xuan)框。②在“地址”文本框中(zhong)填入FTP服(fu)務器的IP地址。③在“端(duan)口(kou)”文本框中(zhong)填入主機FTP服(fu)務器進程的端(duan)口(kou)號21。④點擊“連接(jie)”按鈕，建立與(yu)FTP服(fu)務器的TCP連接(jie)。
(2)連(lian)接(jie)成功(將(jiang)該(gai)次連(lian)接(jie)記(ji)為(wei)w_cmd)，在接(jie)收窗口會顯示成功連(lian)接(jie)的信息。然后在發送(song)窗口發送(song)數據(ju)，觀(guan)察(cha)服務器回(hui)復的信息。由實驗總(zong)結出FTP服務器是使用什么方式創建數據(ju)連(lian)接(jie)的。
二、實習感受
(一)成績與收獲
經過為期幾周的(de)(de)(de)網絡工程(cheng)(cheng)實(shi)習我對IPV4協議中的(de)(de)(de)各個協議有了(le)更深入的(de)(de)(de)了(le)解。在(zai)實(shi)驗(yan)一中掌握(wo)(wo)了(le)什(shen)么是(shi)IEEE802標(biao)準和(he)(he)(he)以太(tai)網、太(tai)網的(de)(de)(de)報(bao)文格式(shi)(shi);掌握(wo)(wo)MAC地址(zhi)的(de)(de)(de)作用;MAC廣(guang)播地址(zhi)的(de)(de)(de)作用;LLC幀(zhen)報(bao)文格式(shi)(shi);協議編輯(ji)器和(he)(he)(he)協議分析器的(de)(de)(de)使(shi)用方(fang)法(fa)(fa);協議棧(zhan)發(fa)送和(he)(he)(he)接收以太(tai)網數(shu)據幀(zhen)的(de)(de)(de)過程(cheng)(cheng)。通過動(dong)手實(shi)驗(yan)捕獲數(shu)據包分析出MAC幀(zhen)格式(shi)(shi)。同(tong)時學(xue)會了(le)編寫(xie)LLC幀(zhen)，更加明白LLC幀(zhen)是(shi)由目的(de)(de)(de)MAC地址(zhi)、源MAC地址(zhi)、協議類型和(he)(he)(he)數(shu)據長度、用戶定義數(shu)據/數(shu)據字段等組成。在(zai)實(shi)驗(yan)三中熟練掌握(wo)(wo)了(le)IP校驗(yan)和(he)(he)(he)計算方(fang)法(fa)(fa)，可手動(dong)計算也可使(shi)用協議編輯(ji)器的(de)(de)(de)“自動(dong)計算”校驗(yan)和(he)(he)(he)。
同(tong)(tong)時還懂得受限廣(guang)播地(di)(di)(di)址(zhi)的(de)(de)作用(yong)：受限的(de)(de)廣(guang)播地(di)(di)(di)址(zhi)是255.255.255.255。該地(di)(di)(di)址(zhi)用(yong)于主機配(pei)置過(guo)程(cheng)中(zhong)IP數據(ju)報的(de)(de)目的(de)(de)地(di)(di)(di)址(zhi)，此時，主機可能還不知(zhi)道它(ta)所(suo)在(zai)網(wang)(wang)(wang)絡(luo)的(de)(de)網(wang)(wang)(wang)絡(luo)掩(yan)碼，甚(shen)至連它(ta)的(de)(de)IP地(di)(di)(di)址(zhi)也(ye)不知(zhi)道。在(zai)任何(he)情況下(xia)，路由(you)器都不轉發目的(de)(de)地(di)(di)(di)址(zhi)為受限的(de)(de)廣(guang)播地(di)(di)(di)址(zhi)的(de)(de)數據(ju)報，這樣的(de)(de)數據(ju)報僅出(chu)現在(zai)本地(di)(di)(di)網(wang)(wang)(wang)絡(luo)中(zhong)。最(zui)重要的(de)(de)是，在(zai)學(xue)(xue)(xue)習(xi)的(de)(de)過(guo)程(cheng)中(zhong)組(zu)內(nei)成員互相幫助，遇(yu)到(dao)困難大(da)家共同(tong)(tong)解決，真正認識(shi)到(dao)團(tuan)結(jie)協作精神的(de)(de)重要，同(tong)(tong)時我(wo)們積極利用(yong)網(wang)(wang)(wang)絡(luo)搜集大(da)量資(zi)料并(bing)從(cong)中(zhong)摘取與自(zi)己(ji)課題相關(guan)的(de)(de)內(nei)容，這樣在(zai)研究過(guo)程(cheng)中(zhong)又(you)增(zeng)加了不少課外知(zhi)識(shi)，對大(da)一(yi)學(xue)(xue)(xue)過(guo)的(de)(de)網(wang)(wang)(wang)絡(luo)原(yuan)理是個很好的(de)(de)復習(xi)和回顧。另外，通過(guo)實習(xi)我(wo)發現自(zi)己(ji)目前掌(zhang)握的(de)(de)東西還是少，在(zai)今(jin)后的(de)(de)學(xue)(xue)(xue)習(xi)中(zhong)要不斷(duan)學(xue)(xue)(xue)習(xi)不斷(duan)總(zong)結(jie)，必須(xu)拓寬自(zi)己(ji)的(de)(de)知(zhi)識(shi)面(mian)、開闊自(zi)己(ji)的(de)(de)視(shi)野。
(二)問題與不足
篇10
關(guan)鍵字 TCP/IP；教學(xue)平臺(tai)；數據包截獲；包過濾(lv)；協議分析
1 引言
TCP/IP協(xie)(xie)議(yi)(yi)族是計算(suan)機網絡(luo)軟件組(zu)成(cheng)的(de)核心部(bu)分(fen)，同時也(ye)是很抽象和難以(yi)掌握(wo)的(de)部(bu)分(fen)。目前(qian)，對(dui)于TCP/IP協(xie)(xie)議(yi)(yi)族的(de)研(yan)(yan)究(jiu)(jiu)，一(yi)般(ban)是基于協(xie)(xie)議(yi)(yi)應(ying)用(yong)本(ben)(ben)身(shen)(shen)的(de)研(yan)(yan)究(jiu)(jiu)，也(ye)就是研(yan)(yan)究(jiu)(jiu)如何(he)將指定的(de)協(xie)(xie)議(yi)(yi)嵌入產品，使該產品能夠支持上(shang)層產品應(ying)用(yong)該協(xie)(xie)議(yi)(yi)或自身(shen)(shen)產品對(dui)該協(xie)(xie)議(yi)(yi)的(de)應(ying)用(yong)。作(zuo)為(wei)高校(xiao)計算(suan)機網絡(luo)課程中(zhong)所介紹的(de)協(xie)(xie)議(yi)(yi)，對(dui)于很大一(yi)部(bu)分(fen)老師和同學來講，都還只(zhi)是停留在了解和使用(yong)這(zhe)個(ge)協(xie)(xie)議(yi)(yi)上(shang)，并(bing)沒有(you)深入到協(xie)(xie)議(yi)(yi)本(ben)(ben)身(shen)(shen)的(de)原理中(zhong)去(qu)。
本系統(tong)通過(guo)(guo)(guo)對(dui)TCP/IP協議(yi)族的(de)研究，將其中的(de)部分常用協議(yi)（如TCP、IP、UDP等(deng)）的(de)具體結(jie)構、工作(zuo)方式(shi)和(he)(he)工作(zuo)過(guo)(guo)(guo)程(cheng)，用人機(ji)交互方式(shi)和(he)(he)圖形(xing)化界(jie)面(mian)(mian)形(xing)象(xiang)生(sheng)(sheng)動展現(xian)在學(xue)(xue)(xue)生(sheng)(sheng)面(mian)(mian)前。教學(xue)(xue)(xue)中通過(guo)(guo)(guo)對(dui)本套系統(tong)的(de)利(li)用，可(ke)以達(da)到提高學(xue)(xue)(xue)習(xi)(xi)效率，改善學(xue)(xue)(xue)習(xi)(xi)效果，使(shi)學(xue)(xue)(xue)生(sheng)(sheng)對(dui)協議(yi)的(de)學(xue)(xue)(xue)習(xi)(xi)不僅達(da)到對(dui)使(shi)用方法(fa)的(de)了(le)解，同時(shi)達(da)到對(dui)協議(yi)結(jie)構以及工作(zuo)原理的(de)領悟，使(shi)學(xue)(xue)(xue)生(sheng)(sheng)對(dui)網絡課程(cheng)的(de)學(xue)(xue)(xue)習(xi)(xi)達(da)到一個新的(de)層次。
2 系統設計依據
2.1 設(she)計思路及設(she)計目的
本(ben)(ben)系統開發(fa)的(de)(de)(de)(de)目的(de)(de)(de)(de)是針(zhen)對(dui)(dui)大學(xue)本(ben)(ben)科學(xue)生(sheng)對(dui)(dui)《計算機網絡(luo)(luo)》課(ke)程(cheng)中(zhong)關于網絡(luo)(luo)傳(chuan)輸以及協(xie)(xie)議(yi)原(yuan)理部分的(de)(de)(de)(de)學(xue)習，使學(xue)生(sheng)可以自己定(ding)制傳(chuan)輸內(nei)容，并(bing)親(qin)眼看(kan)到所有內(nei)容傳(chuan)輸的(de)(de)(de)(de)過程(cheng)形式等(deng)，增強(qiang)對(dui)(dui)協(xie)(xie)議(yi)結構的(de)(de)(de)(de)記憶，并(bing)可以親(qin)自動手控(kong)制協(xie)(xie)議(yi)的(de)(de)(de)(de)狀(zhuang)態(tai)，達到對(dui)(dui)協(xie)(xie)議(yi)原(yuan)理及工作方式的(de)(de)(de)(de)深入了解。
2.2 系統設計中所(suo)用(yong)到(dao)的(de)原理
2.2.1 數據傳輸的原理
在基于(yu)TCP/IP的網絡中(zhong)，應用層的數(shu)據(ju)傳輸(shu)通常是基于(yu)TCP或者(zhe)UDP協(xie)議的，而(er)兩種協(xie)議最(zui)大(da)的區別在于(yu)是否面向連接。
在面(mian)向連(lian)(lian)接的(de)(de)TCP協議中(zhong)，傳輸(shu)數據首先要(yao)求(qiu)傳輸(shu)雙(shuang)方建立(li)一條(tiao)虛電路(lu)連(lian)(lian)接。通(tong)信雙(shuang)方通(tong)過(guo)自身的(de)(de)sockets（或稱為通(tong)訊端點） 建立(li)sockets的(de)(de)連(lian)(lian)接，從而達到傳輸(shu)的(de)(de)目的(de)(de)。
UDP是一種是無連(lian)接(jie)(jie)(jie)的(de)用(yong)(yong)戶(hu)數據報傳輸協議，與(yu)TCP操作不(bu)(bu)(bu)同，計算機(ji)間并不(bu)(bu)(bu)需要建(jian)立(li)一個(ge)明確、可(ke)靠的(de)鏈路(lu)，一個(ge)UDP應(ying)用(yong)(yong)可(ke)同時作為(wei)客戶(hu)方(fang)或服務器方(fang)。UDP向應(ying)用(yong)(yong)程序提供了一種發送封裝的(de)原始IP數據包(bao)的(de)方(fang)法。雖然UDP數據報只能提供不(bu)(bu)(bu)可(ke)靠的(de)交付，但在許多方(fang)面UDP可(ke)以(yi)簡(jian)化連(lian)接(jie)(jie)(jie)，這樣可(ke)以(yi)避免(mian)建(jian)立(li)和釋放(fang)連(lian)接(jie)(jie)(jie)的(de)麻煩。
2.2.2 網(wang)絡包截獲的原理
通常在(zai)同一(yi)個(ge)網(wang)段的(de)(de)所有(you)網(wang)絡(luo)接口都有(you)訪問在(zai)物理媒體上(shang)傳(chuan)輸的(de)(de)所有(you)數(shu)據的(de)(de)能(neng)力，而每個(ge)網(wang)絡(luo)接口都還應(ying)(ying)該有(you)一(yi)個(ge)硬件(jian)地址(zhi)(zhi)，該硬件(jian)地址(zhi)(zhi)不同于(yu)網(wang)絡(luo)中存(cun)在(zai)的(de)(de)其他(ta)網(wang)絡(luo)接口的(de)(de)硬件(jian)地址(zhi)(zhi)，同時，每個(ge)網(wang)絡(luo)至(zhi)少還要(yao)一(yi)個(ge)廣播地址(zhi)(zhi)（代表所有(you)的(de)(de)接口地址(zhi)(zhi)），在(zai)正(zheng)常情(qing)況下(xia)，一(yi)個(ge)合法的(de)(de)網(wang)絡(luo)接口應(ying)(ying)該只響應(ying)(ying)這樣的(de)(de)兩種數(shu)據幀：
（1）幀的目標(biao)區域具有和本地(di)網絡接口相(xiang)匹配(pei)的硬件地(di)址。
（2）幀(zhen)的(de)目(mu)標區(qu)域具有(you)"廣播地址(zhi)"。
在接受到(dao)上面兩種情況的數據(ju)包時，網卡通過CPU產生一(yi)個硬件(jian)中斷(duan)，該(gai)中斷(duan)能引起操作系統注意(yi)，然(ran)后(hou)將幀中所包含的數據(ju)傳送給系統進一(yi)步處理。
本(ben)(ben)(ben)系(xi)統中(zhong)對(dui)數(shu)(shu)據(ju)(ju)幀的(de)截獲就是(shi)(shi)利(li)用將本(ben)(ben)(ben)地網卡模式(shi)設成混雜（promiscuous）狀態的(de)機(ji)制，混雜模式(shi)就是(shi)(shi)接收所有經(jing)過(guo)網卡的(de)數(shu)(shu)據(ju)(ju)包，包括不是(shi)(shi)發給本(ben)(ben)(ben)機(ji)的(de)包。當網卡處于(yu)這種"混雜"方式(shi)時，使網卡對(dui)所有遭遇到的(de)每(mei)一個幀都產生一個硬(ying)件中(zhong)斷(duan)以便提醒操作系(xi)統處理(li)流經(jing)該物(wu)理(li)媒體上(shang)的(de)每(mei)一個報文包。
2.2.3 協議狀態跳(tiao)轉(zhuan)的原理(li)