導語：如何才能寫好一篇udp協(xié)議，這就需要搜集整理更多的資料和文獻，歡迎閱讀由公務員之家整理的十篇范文，供你借鑒。

篇1

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

中圖分類號:TP312 文獻標識碼:A 文章編號:1009-3044(2010)13-3319-02

Use udp Protocol and Analysis

LIU Peng1, LIU Yan2

(puter Science and Information Engineering College, Guangxi Normal University, Guilin 541004, China; 2.Affiliated Hospital of Guilin Medical University,The Office of Teaching Management, Guilin 541001, China)

Abstract: UDP protocol is a compact, highly efficient protocol has been widely used. The method of how to design communication program with UDP protocol in windows operating system was introduced. Then test communication with the introduced program. The captured packets by Sniffer in communication experimental were analyzed in detail to verify the network model and the network communication program, summed up the advantages and disadvantages of UDP protocol.

Key words: UDP; communication; packet analysis; sniffer

UDP是User Datagram Protocol的簡稱,是TCP/IP體系結構中一種無連接的傳輸層協(xié)議,提供面向事務的簡單不可靠信息傳送服務。UDP 協(xié)議是 IP 協(xié)議與上層協(xié)議的接口,用端口號分別為運行在同一設備上的多個應用程序提供服務。它定義在IETF RFC 768中[1]。

UDP是分發(fā)信息的理想?yún)f(xié)議,適用于追求效率且不需要額外可靠機制的情形,如音、視頻流媒體分發(fā)、高層協(xié)議或應用程序提供錯誤和流控制功能時的快速數(shù)據(jù)分發(fā)。 UDP服務于很多知名應用,如網絡文件系統(tǒng)(NFS)、簡單網絡管理協(xié)議(SNMP)、域名系統(tǒng)(DNS)以及簡單文件傳輸系統(tǒng)(TFTP)、動態(tài)主機配置協(xié)議(DHCP)、路由信息協(xié)議(RIP)等。

1 UDP協(xié)議使用

在Windows下使用UDP不需要實現(xiàn)RFC 768中定義的UDP細節(jié),封閉的Windows操作系統(tǒng)為用戶實現(xiàn)了協(xié)議,以動態(tài)鏈接庫及API的形式提供給用戶程序調用。這種方式方便了程序設計,但也阻止了用戶對網絡協(xié)議的更深理解。為了更加深入研究UDP有必要對傳輸報文流進行分析;為了更好的分析,需要實現(xiàn)一個使用UDP的通信程序。

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

#include //基本輸入輸出庫

#include //網絡API函數(shù)庫

#pragma comment (lib,"WS2_32.lib")/*將WS2_32.lib加入鏈接,不用再為這個鏈接文件設置鏈接選項了*/

void main()

{ WORD wVersionRequested;

WSADATA wsaData;

int err;

wVersionRequested = MAKEWORD( 1, 1 );

err = WSAStartup( wVersionRequested, &wsaData );

if ( err != 0 ) {

return; /* 處理找不到 WinSock DLL.*/}

/* 確認 WinSock DLL 支持的版本 */

if ( LOBYTE( wsaData.wVersion ) != 1 ||HIBYTE( wsaData.wVersion ) != 1 ) {

WSACleanup( ); return;

}/* [3]以上代碼為MSDN提供的設計windows下網絡程序的標準方法*/

SOCKET sockSrv=socket(AF_INET,SOCK_DGRAM,0);/*AF_INET因特網地址族UDP, TCP, 等.SOCK_DGRAM 基于upd的套接字。*/

SOCKADDR_IN addrSrv;

addrSrv.sin_addr.S_un.S_addr=htonl(INADDR_ANY);/*htonl主機字節(jié)序變?yōu)榫W絡字節(jié)序*/

addrSrv.sin_family=AF_INET;

addrSrv.sin_port=htons(6666);

err=bind(sockSrv,(SOCKADDR *)&addrSrv,sizeof(SOCKADDR)); /*綁定主機從6666端口接受數(shù)據(jù)*/

if ( err != 0 ) {

return; /* 處理幫定異常*/

} SOCKADDR_IN addrClient;

int len=sizeof(sockaddr);

char recvBuff[200];//接收緩存

char sendBuff[200];//發(fā)送緩存

char tempBuff[200];//暫時緩存

while (1){

recvfrom(sockSrv,recvBuff,200,0,(SOCKADDR*)&addrClient,&len); //接收數(shù)據(jù)

if('E'==recvBuff[0])

{sendto(sockSrv,"E",strlen("E"),0,(SOCKADDR*)&addrClient,len); //發(fā)送數(shù)據(jù)

printf("Communications end\n");

break;

}sprintf(tempBuff,"Recieve From IP %s :%s ",inet_ntoa(addrClient.sin_addr),recvBuff); //格式化

printf("%s\n",tempBuff);

printf("Please input data send to IP %s :\n ",inet_ntoa(addrClient.sin_addr));

gets(sendBuff);

sendto(sockSrv,sendBuff,strlen(sendBuff)+1,0,(SOCKADDR*)&addrClient,len);

}closesocket(sockSrv);

WSACleanup();

}客戶端程序頭文件及socket初始化和服務器端一樣,不同的是socket函數(shù)的使用。

//頭文件和服務器端一樣

void main()

{…

//初始化和服務器端一樣

/* 以上代碼為MSDN提供的設計windows下網絡程序的標準方法,*/

SOCKET sockCleit=socket(AF_INET,SOCK_DGRAM,0);//SOCK_DGRAM 基于upd的套接字

SOCKADDR_IN addrSrv;

addrSrv.sin_addr.S_un.S_addr=inet_addr("192.168.1.103");/*設置目標地址,根據(jù)服務器端情況*/

addrSrv.sin_family=AF_INET;

addrSrv.sin_port=htons(6666);//與服務器端一致

char recvBuff[200];//接收緩存

char sendBuff[200];//發(fā)送緩存

char tempBuff[200];//暫時緩存

int len=sizeof(SOCKADDR);

while (1)

{printf("Please input data send to IP %s :\n",inet_ntoa(addrSrv.sin_addr));

gets(sendBuff);

sendto(sockCleit,sendBuff,strlen(sendBuff)+1,0,(SOCKADDR*)&addrSrv,len);//發(fā)送

recvfrom(sockCleit,recvBuff,200,0,(SOCKADDR*)&addrSrv,&len);//接收

if('E'==recvBuff[0])

{sendto(sockCleit,"q",strlen("q"),0,(SOCKADDR*)&addrSrv,len);

printf("Communications end\n");

break;

}sprintf(tempBuff,"Recieve From IP %s :%s ",inet_ntoa(addrSrv.sin_addr),recvBuff);

printf("%s\n",tempBuff);

}closesocket(sockCleit);

WSACleanup();

}

以上代碼可使用VC6.0、VS2005、 VS2008等軟件編譯器。服務器端的網絡地址為192.168.1.102。客戶端不限,只要和服務間路由可達即可,本例中使用192.168.1.100。如不想更改服務器端IP地址,只要按照程序注釋,根據(jù)實際情況更改客戶程序的addrSrv.sin_addr.S_un.S_addr變量即可。

2 報文捕獲與分析

圖1為客戶端IP192.168.1.100向服務器端IP192.168.1.103發(fā)出數(shù)據(jù)“test”后,由服務器端的sniffer捕獲的報文。

UDP報文為灰色開始的0c 96 1a 0a 00 0d 6d 3e 74 65 73 74 00共13字節(jié)。UDP前45開始到67為標準IP報文頭共20個字節(jié),報文開頭的00到08 00(IP報文頭前)14個字節(jié)為DLC(Data Link Control)報文頭。UDP報文中,0c 96源端口號,兩字節(jié),客戶端用于接收信息的端口號,不需要回復可用全零。1a 0a 目的端口號,兩字節(jié),服務器端的接收端口號。00 0d 數(shù)據(jù)包長度,兩字節(jié),本示例為13。6d 3e 校驗和,兩字節(jié)。74 65 73 74 00 數(shù)據(jù)包的內容,74 65 73 74 為“test”的ASCII編碼,00通過源程序可以發(fā)現(xiàn),為了接收端處理方便多發(fā)的一個空字節(jié)。

圖2為服務器端103接收到“test”后,向客戶端發(fā)送“received test”數(shù)據(jù),由服務器端的sniffer軟件捕獲的報文。

UDP報文為灰色開始1a 0a 0c96 00 16 b6 78 72 65 63 65 69 76 65 64 20 74 65 73 74 00共22字節(jié)。1a 0a源端口號,0b 96目的端口號,與前一報文正好相反。00 16 數(shù)據(jù)包長度22字節(jié)。B6 78 校驗和,72 65 63 65 69 76 65 64 20 74 65 73 74 00 是數(shù)據(jù)報的內容,同樣多發(fā)了一個空字節(jié)。

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

3 結束語

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

參考文獻:

[1] 謝希仁.計算機網絡[M].5版.北京:電子工業(yè)出版社,2007:108-184.

[2] Stanley B Lippman. JoséeLajoi C++Primer[M].潘愛民,張麗,譯.北京:電力出版社,2005.

篇2

關鍵詞：arm；linux；交叉編譯環(huán)境；udp協(xié)議；重發(fā)機制；重發(fā)次數(shù)

中圖分類號：tp393文獻標識碼：a文章編號：1009-3044(2011)13-3001-03

the application research of communicating based on arm-linux environment and udp-protocol

cui hao, shao ping-fan

(wuhan university of science and technology, wuhan 430000, china)

abstract: the sender and receiver are relatively independent when communicating under udp- protocol, the sender resending messages to receiver times instead of creating a connection. a resend-mechanism that the key-messages were send by upper computer in fixed times, was used in order to ensuring not to lost key-message. although the resend-mechanism can ensure that the key-message wouldn’t be lose anyway, but abundant of redundancy messages were send through the network device lead to inefficency, obviously more resend-times more inefficency. so, how to determine the resend-times become the crucial to improve the efficiency while ensuring the messages were send accurately. a method of determining the resend-times will be given as following.

key words: arm; linux; crossing compile evironment; udp-protocol; resend mechanism; resend times

udp協(xié)議以其高效性和應用的簡單，被廣泛運用于嵌入式網絡開發(fā)中。由于udp協(xié)議的應用簡單，在嵌入式設備開發(fā)過程中，網絡資源的利用率并不高。以下將介紹一個udp具體項目實驗過程，描述arm-linux環(huán)境的軟硬件環(huán)境構建過程，并對udp協(xié)議下一種重發(fā)模式中上位機的重發(fā)次數(shù)的確定提出一種可行的方法。

1 研究背景

隨著嵌入式技術的快速發(fā)展，嵌入式設備已經在許多領域取代了傳統(tǒng)的微型機設備。本文的選題主要來自于實習期間承接的一項改造項目：某院校特長生評分系統(tǒng)的改造。項目改造目的有：1) 保留原上位機。2) 改用手持式客戶端進行顯示及評分操作。3)保留原有網絡設備。針對要求，我們使用s3c2440作為硬件平臺，移植linux操作系統(tǒng)，并在arm-linux環(huán)境下研究了udp協(xié)議的通信過程，進行了上位機與嵌入式系統(tǒng)的udp協(xié)議通信實驗及分析，并給出一種重發(fā)機制中的發(fā)送次數(shù)求法。

2 硬件平臺介紹

s3c2440處理速度達到了400mhz，具有較高的性價比。為了提高開發(fā)效率，我們采用公司自行研制開發(fā)的et-s3c2440開發(fā)板。

2.1 et-s3c2440開發(fā)板簡介

et-s3c2440是公司自行開發(fā)的一款arm9架構的實驗開發(fā)板，其結構框圖如圖1。

核心板的主要器件有：32mb×2片sdram，64mb norflash，512mb nandflash。設計了啟動方式可選，通過開關選擇從nandflash或norflash啟動。

2.2 實驗相關電路說明

底板電路主要功能是輸入輸出以及網絡通訊功能。按鍵輸入部分采用掃描方式獲得輸入，用一個單向地址鎖存器和一個雙向地址鎖存器與地址總線相連，可以通過掃描地址來獲得按鍵輸入。lcd采用三星的3.5寸tft屏作為顯示輸出設備。網卡芯片選用的是與原設備匹配的10m 的cs8900a，關于cs8900a與s3c2440的硬件連接，有眾多資源可供參考，本文不再贅述。

3 系統(tǒng)軟件平臺的構建

硬件平臺搭建完畢后要將操作系統(tǒng)和應用程序在硬件平臺上運行起來。以下是對嵌入式linux操作系統(tǒng)移植的過程。

3.1 交叉編譯環(huán)境的構建

linux 2.6.29.1版本的內核可以登錄到kernel.org下載。本文選擇的是arm-linux-gcc-4.3.2工具鏈(ftp://ftp.arm.linux.org.uk/pub/armlinux/toolchain)

在宿主機上進入linux系統(tǒng)，切換當前目錄到工具鏈所在目錄，新建一個arm目錄保存解壓后的文件(mkdir /user/local/arm)并將arm-linux-gcc-4.3.2解壓到這個目錄中(tar jxvf arm-linux-gcc-4.3.2 –c /user/local/arm)。然后將環(huán)境變量$path修改一下，讓$path中包含有arm-linux-gcc所在的目錄(編輯/etc/profile 添加語句”export path=/user/local/arm/4.3.2/bin:$path”)，然后reboot一下，這樣交叉編譯環(huán)境就構建好了。

3.2 bootloader的移植

vivi是一款相當成熟和相對簡單的常用bootloader，我們以vivi為移植原型，將s3c2440所有io端口寄存器定義添加到頭文件2440add.inc，刪除部分硬件平臺使用不到的代碼，最后將修改過的vivi制作成鏡像燒錄到flash中。[1]

3.3 linux內核移植

獲取linux-2.6.29.1源代碼并解壓后，首先修改內核源代碼所在目錄中的makefile，將系統(tǒng)架構修改為arm(arch ?=arm ),交叉編譯工具修改為arm-linux-gcc (cross_compile ?=arm-linux-)，修改輸入時鐘(arch/arm/mach-s3c2440/mach-smdk2440.c中的函數(shù)static void __init smdk2440_map_io中，修改s3c24xx_init_clocks(12000000)此處所用晶振為12m)。修改machine名稱(在arch/arm/mach-s3c2440/mach-smdk2440.c文件中的函數(shù)machine_start( ),修改為machine_start(s3c2440, “自定義機器名”)，修改nandflash分區(qū)信息(arch/arm/plat-s3c24xx/common-smdk.c結構體static struct mtd_partition smdk_default_nand_part[]中保存的是nandflah的分區(qū)信息，將其修改為當前使用的分區(qū)信息),然后修改nandflash的匹配時間(3c2410_platform_nand_smdk_nand_info smdk_nand_info ={})。

上述內核源代碼修改完成后，還需要對一些設備的驅動進行修改。本文使用的nec 3.5寸 320×240液晶屏，硬件平臺使用gpg4腳進行背光控制，需要修改lcd背光(/arch/arm/mach-s3c2440/mach-smdk2440.c中static void __init smdk2440_machine_init(void)，將函數(shù)中的gpio口配置為gpg4)。關于cs8900a網卡的驅動移植，相關資源很豐富，本文也不再贅述。

本實驗中nandflash采用的是yaffs2文件系統(tǒng)，所以打yaffs2文件系統(tǒng)補丁，壓縮包為cvs-root.tar.gz。

至此，linux的內核源代碼修改工作完成了，下面還需要利用makefile,進行內核配置。

在linux 2.6.29.1內核目錄下首先make s3c2410_defconfig使用2410的配置模板來配置2440；然后make menuconfig,這時我們可以在圖形化界面中，空格鍵可改變各個配置選項的被選中狀態(tài)，根據(jù)需要進行配置即可。配置完成后保存好配置，最后進行內核的編譯(make dep 建立文件間依賴 make clean 清除編譯殘留文件make zimage 生成內核壓縮鏡像文件)。

編譯過程完成后會在內核目錄arch/arm/boot/下生成zimage內核映像文件，將這個鏡像文件燒錄到flash中，調試檢驗，經上述修改后的內核工作運行正常。

3.4 根文件系統(tǒng)的制作

根文件系統(tǒng)是使用busybox-1.13.3來制作完成。下載busybox并解壓完成后，修改makefile中的架構為arm架構，編譯工具為arm-linux-gcc( arch ?=arm； cross_compile ?=arm-linux-),然后make menuconfig,通過圖形界面對busybox進行配置，然后對busybox進行編譯(make config_prefix=/opt/studyarm/rootfs install)，在目標目錄下會生成目錄bin、sbin、usr和文件linuxrc的內容。

基本目錄結構生成后，應該在目標目錄下建立一些未生成的必要的系統(tǒng)目錄如dev、etc、lib等，并通過chmod命令改變目錄權限為可寫。再將一些必要的動態(tài)鏈接庫和靜態(tài)庫拷貝到lib下，然后在dev目錄下創(chuàng)建設備節(jié)點，最后創(chuàng)建該嵌入式linux系統(tǒng)的初始化配置文件(包括設備列表文件、口令、網絡分組組名、hostname主機名、etc/inittab初始化表單、etc/profile環(huán)境變量配置文件、用于系統(tǒng)初始化的.bash腳本文件等)。[2]由于本實驗需對網絡編程，要求自動初始化cs8900a網卡芯片的ip地址、網關、子網掩碼等，所以在開機自啟動腳本中加入ifconfig語句，使得開機時自動配置網卡參數(shù)。

根文件系統(tǒng)構建完成后，使用yaffs2文件系統(tǒng)制作工具mkyaffs2image.tgz，通過命令mkyaffs2image rootfs rootfs.img生成根文件系統(tǒng)鏡像，然后將鏡像燒寫入flash中。

4 arm-linux環(huán)境下的udp協(xié)議通信實驗

經過上述硬件設計和操作系統(tǒng)移植過程，本文所使用到的實驗環(huán)境已經構建完畢，經反復調試修改，嵌入式linux操作系統(tǒng)在平臺下運行正常，于是進行udp協(xié)議通信實驗。

4.1 udp協(xié)議套接字編程基礎

udp是一個面向數(shù)據(jù)報和無連接的簡單傳輸層協(xié)議，它不像tcp那樣通過握手過程建立服務器與客戶端的連接才可以工作。在網絡通信質量較好的情況下，udp體現(xiàn)出高效率，這適合于傳送少量報文的應用。[3] linux系統(tǒng)是通過套接字結構來進行網絡編程的，應用程序通過對套接字的幾個函數(shù)調用，會返回一個用于通信的套接字描述符,而linux應用程序在進行任何形式的i/o操作時，程序實際上是在讀寫一個文件描述符。[4]因此linux下的套接字編程，可以看成是對普通文件描述符的操作，這些操作與被使用的硬件平臺無關，這是linux設備無關性的優(yōu)點。udp協(xié)議的通信模型如圖3所示。

在上述流程中，客戶端所收到的報文被存儲在緩沖區(qū)中，recvfrom()函數(shù)返回了報文存儲緩沖區(qū)的首地址，我們可以很方便地對這個首地址進行數(shù)組操作，從而實現(xiàn)對報文的解碼。

4.2 上位機報文結構及重發(fā)機制分析

根據(jù)項目要求，上位機軟件依然保留，我們使用協(xié)議嗅探工具對上位機發(fā)送的報文進行了嗅探，得到了上位機報文的結構如表1所示。

表1 上位機報文結構

上位機發(fā)出的每條報文由32個字節(jié)組成，第0位為版本信息。第1……12位為比賽信息和運動員教練信息，是報文的關鍵信息部分，13……22位為服務器端和客戶端的ip地址及端口號信息，23位是上位機對客戶端的操作指令代碼，24位是相關重發(fā)機制的代碼，30和31兩位是checksum，用來保證數(shù)據(jù)傳輸?shù)恼_。上位機采用的重發(fā)機制是一種上位機按照固定重發(fā)次數(shù)多次發(fā)送同一關鍵內容報文的機制，其第24位重發(fā)機制位被分為高4位和低4位兩部分，高四位的內容是當前發(fā)送的報文的索引號，每次發(fā)送一條新內容的報文時索引號自增1，索引號的取值范圍在0x00—0xff范圍內循環(huán)自增。低四位是重發(fā)編號，表示同一索引號的報文正在被第幾次重發(fā)，固定的重發(fā)次數(shù)由上位機初始化時設定。

4.3 嵌入式客戶端的實驗程序設計

針對報文結構，我們對接收端編寫實驗程序代碼，代碼的主要功能是從上位機接收報文，將計算出的checksum校驗和與收到的校驗和對比判斷報文是否正確，然后從正確報文中取出主要信息并按照報文中的上位機指令碼進行輸出。其結構流程圖如圖3所示。

實驗程序經編碼、調試后在交叉編譯環(huán)境中交叉編譯，生成arm-linux環(huán)境下可執(zhí)行文件，在目標板上執(zhí)行。經測試試驗程序能夠正確接收上位機發(fā)來的報文，對報文解碼，并能根據(jù)上位機命令對關鍵信息做輸出處理。

4.4 對上位機重發(fā)次數(shù)的研究

進行udp協(xié)議通信時，發(fā)送端和接收端的狀態(tài)是相對獨立的，發(fā)送端不與接收端建立連接，而是不停向接收端發(fā)送，為了確保不丟失報文，上位機采取了按固定次數(shù)重發(fā)相同內容報文的機制。然而這種機制雖然可以有效確保報文不丟失，但是大量冗余數(shù)據(jù)報被發(fā)送，網絡資源利用率不高。重發(fā)次數(shù)越多，冗余數(shù)據(jù)報越多，效率越低。要想有效保證數(shù)據(jù)報準確發(fā)送的同時又不產生過多冗余數(shù)據(jù)報，那么重復發(fā)送的次數(shù)的確定就成為問題的關鍵。以下給出一種確定上位機重發(fā)次數(shù)的方法。

假設當前網絡狀況下，每次報文發(fā)送被丟失的概率為p，系統(tǒng)允許接收端報文關鍵內容丟失概率為q,那么如何確定以上重發(fā)機制中的重發(fā)次數(shù)k呢？

特殊情況下若報文重發(fā)次數(shù)為2，分別在每條報文重發(fā)機制位注明一個索引號和一個重發(fā)編號，發(fā)送端發(fā)送報文的次序應形如 1.1 ,1.2 ,2.1 ,2.2 ,3.1 ,3.2……其中索引號相同的報文關鍵內容相同，重發(fā)編號不同代表同一關鍵內容報文的不同次發(fā)送。因此只有出現(xiàn)連續(xù)兩次丟失數(shù)據(jù)報的情況下，報文關鍵內容才可能丟失。出現(xiàn)連續(xù)兩次丟失的情況有2種，當x.1 , x.2丟失，此時索引號為x的報文關鍵信息將全部丟失。當x.2,(x+1). 1丟失，丟失報文的索引號不同，此時不會發(fā)生報文關鍵信息丟失，因此報文關鍵內容丟失的概率q=p2/2。

當報文重發(fā)次數(shù)為3,依然在每條報文的重發(fā)機制位注明索引號和重發(fā)號，發(fā)送報文的次序應為1.1 ,1.2 ,1.3 ,2.1 ,2.2 ,2.3 ,3.1 ,3.2……。只有出現(xiàn)連續(xù)3次丟失數(shù)據(jù)報的情況報文關鍵信息才可能丟失，列出連續(xù)3次丟失報文的情況有3種，當x.1 , x.2 , x.3丟失，此時索引號為x的報文信息全部丟失。當x.2 , x.3 ,(x+1).1或x.3 ,(x+1).1 ,(x+1).2丟失時不影響報文的準確傳遞。因此此時報文關鍵內容丟失的概率q=p3/3。

推廣至一般情況易得當報文重發(fā)次數(shù)為k時，報文關鍵內容丟失的概率q=pk/k，移項有kq=pk。于是我們得到求重發(fā)次數(shù)k的方法如下：

1) 根據(jù)網絡狀況獲得報文丟失概率p；

2) 根據(jù)客戶需求取得報文關鍵內容的允許丟失率范圍q；

3) 分別作出y=px和y=qx的圖像；

4) 求得兩圖像的交點的x坐標，并將x坐標值取整加一即為所求重發(fā)次數(shù)k。

本文實驗中，需求方允許報文關鍵信息丟失概率q=0.0001,我們分別對上位機發(fā)送端和下位機接收端收發(fā)的報文進行了統(tǒng)計，在某一固定時間段內，上位機共發(fā)送報文19665條，接收端接收報文18636條，傳輸過程中丟失的報文19665-18636=1029條，當前網絡環(huán)境下的報文丟失率為，即p=0.0523。據(jù)此數(shù)值分別作出y=0.0001x的曲線和y=0.0523 x的曲線，取得兩曲線交點x坐標為x≈2.78，最后將x=2.78取整加1得到k=3，即上位機對同一數(shù)據(jù)報的重發(fā)次數(shù)應該定為3次就可保證系統(tǒng)丟失報文的概率低于0.0001。

5 結論與展望

本文從硬件平臺搭建、linux移植以及udp協(xié)議編程幾個方面介紹了arm-linux環(huán)境下udp協(xié)議通信的具體實現(xiàn)，并分析了一種在實際嵌入式項目中常用的上位機數(shù)據(jù)報重發(fā)機制，最后對這種機制中的重發(fā)次數(shù)的確定方法給出了求解過程，為后續(xù)的具體項目實施提供了實踐依據(jù)，也希望為其他應用這種重發(fā)機制的嵌入式產品開發(fā)者們提供了借鑒。

參考文獻：

[1] 李偉.基于arm9的嵌入式linux手持平臺的設計與實現(xiàn)[d].武漢:武漢理工大學碩士學位論文,2009.

[2] 范艷開.基于arm的嵌入式linux操作系統(tǒng)移植[d].西安:西北工業(yè)大學,2005.

篇3

0引言

用戶數(shù)據(jù)報協(xié)議（User Datagram Protocol，UDP）是一種無連接的傳輸層協(xié)議，沒有連接建立和連接終止的握手過程，所以UDP協(xié)議通信效率高，冗余性強，對個別數(shù)據(jù)包丟失不敏感，廣泛應用于車輛檢測儀、氣象檢測儀和情報板等工程類項目中。在高速公路可變情報板系統(tǒng)中，UDP協(xié)議經常在應用層面利用后向差錯控制（Backward Error Control，BEC）技術實現(xiàn)對數(shù)據(jù)流的調節(jié)，以避免網絡的阻塞。接收端采用與發(fā)送端“一次握手”的方式來確保每一個獨立數(shù)據(jù)包的正確傳輸。如果接收數(shù)據(jù)包正確合法，接收端將回送確認信息（ACK）來傳輸下一個數(shù)據(jù)包；否則自動請求重發(fā)（Automatic Repeat reQuest，ARQ），這一機制稱之為空閑ARQ[1]。

 

空閑ARQ因技術簡單而容易實現(xiàn)。但是，半雙工的通信方式致使其傳輸效率和帶寬利用率很低，在往返時延（RoundTrip Time，RTT）較高的情況下尤為明顯。相比之下，連續(xù)ARQ克服了空閑ARQ停止等待的缺點，它允許發(fā)送端在收到ACK之前連續(xù)發(fā)送多個數(shù)據(jù)包，也允許接收端連續(xù)接收[2]。然而在可變情報板系統(tǒng)中，負責數(shù)據(jù)接收的工控機配置情況差強人意，與發(fā)送端相去較遠。一些終端自適應協(xié)議（如RBUDP+[3]、RAPID[4]、PAPID+[5]、GTP（Group Transport Protocol）[6]、PAUDP[7]和RTsunami[8]等）已經考慮到終端的性能問題，它們根據(jù)終端系統(tǒng)的接受能力實時調整發(fā)送速率，從而獲得更好的傳輸性能。這些協(xié)議在eScience等需要海量數(shù)據(jù)傳輸?shù)目蒲袘弥行Ч@著[9]，而對于工程中廣泛使用的小文件傳輸力不從心，因為在協(xié)議作出調整之前文件已經傳輸完畢，各種算法無用武之地。為了解決上述提到的諸多問題，本文探討了與終端性能相關的若干影響因子，并針對終端性能瓶頸提出一種基于UDP的自適應傳輸協(xié)議。該協(xié)議無須用戶干預，可根據(jù)系統(tǒng)當前狀態(tài)配置參數(shù)，針對不同大小的文件區(qū)分對待，采取多種措施保證數(shù)據(jù)可靠快速地傳輸。

 

篇4

【關鍵詞】可靠UDP;確認重傳;滑動窗口

引言

由于傳統(tǒng)的數(shù)據(jù)傳輸協(xié)議所針對的業(yè)務不同，在數(shù)據(jù)傳輸?shù)乃俣群涂煽啃灾g不能達到很好的平衡。車險理賠系統(tǒng)中采用的是移動理賠的思想，手持終端機通過移動通信網絡和后臺中心系統(tǒng)進行數(shù)據(jù)交互。目前國內的通信事業(yè)并不是很發(fā)達，信號覆蓋率并不全面，移動通信網絡的帶寬和傳輸質量會受到地域的影響，為確保理賠現(xiàn)場與后臺系統(tǒng)間數(shù)據(jù)的及時可靠傳輸，需要基于移動通信的網絡環(huán)境設計高效可靠的數(shù)據(jù)傳輸功能。本章在UDP傳輸協(xié)議基礎上，通過應用層封裝和可靠性設計的方法，采用數(shù)據(jù)包的確認重傳、流量控制等機制，設計并實現(xiàn)基于UDP協(xié)議的可靠數(shù)據(jù)傳輸功能。

1.TCP與UDP的對比

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

（1）TCP和UDP是傳輸層的兩個協(xié)議，它們最大的區(qū)別是是否面向連接。TCP，在客戶端和服務器端進行通信之前，首先要交換傳輸層控制信息，為雙方的通信做好準備。UDP是一個非連接的協(xié)議，傳輸數(shù)據(jù)之前雙方不建立連接，當傳送數(shù)據(jù)時，簡單的抓取來自應用程序的數(shù)據(jù)，并盡可能快的把數(shù)據(jù)傳送到網絡上。

（2）UDP協(xié)議的數(shù)據(jù)傳輸不需要維護收發(fā)狀態(tài)和連接狀態(tài)等，與TCP相比，網絡有效利用率得到很大的提高。

（3）TCP協(xié)議提供數(shù)據(jù)確認重傳、擁塞控制等可靠性保證，UDP協(xié)議不提供可靠性保證，也不提供流量控制。

TCP協(xié)議由于需要確認的狀態(tài)和對數(shù)據(jù)包的操作過多，數(shù)據(jù)傳輸?shù)乃俣炔桓咔揖W絡延遲較大，所以雖然協(xié)議可靠但并不適合面向移動通信的數(shù)據(jù)傳輸;而UDP協(xié)議由于不用建立連接，沒有超時重發(fā)等可靠機制，網絡延遲小且數(shù)據(jù)傳輸速度很快。本文設計的理賠系統(tǒng)面向移動通信網絡實現(xiàn)理賠現(xiàn)場與后臺系統(tǒng)間的數(shù)據(jù)傳輸，網絡環(huán)境不如光纖接入網絡穩(wěn)定可靠，對數(shù)據(jù)的高效可靠傳輸有著很高的要求。因此，本章選用UDP協(xié)議，并在其基礎上，設計了連接確認、數(shù)據(jù)確認等可靠機制，滿足了系統(tǒng)對于高效可靠傳輸功能的需求。

2.基于UDP改進的可靠傳輸協(xié)議設計

2.1 可靠UDP傳輸協(xié)議的層次結構

本文設計的基于UDP改進的傳輸協(xié)議的層次結構如圖1所示：

從圖1中可以看出，本文在原來的TCP/IP模型的傳輸層和應用層之間添加了一層為保證數(shù)據(jù)可靠傳輸?shù)母倪M協(xié)議層。新組成的五層網絡體系結構中，實際用來傳輸數(shù)據(jù)的仍然是傳輸層的UDP協(xié)議，新添加的協(xié)議是在UDP傳輸層的基礎上，通過應用層對通信雙方進行連接確認、流量控制等功能，提供一種可靠的數(shù)據(jù)傳輸機制。改進協(xié)議主要提供的功能有：

（1）面向消息包機制的數(shù)據(jù)接收和發(fā)送功能。改進協(xié)議的數(shù)據(jù)傳輸層仍然使用UDP傳輸協(xié)議，本身又添加了可靠機制，因此可以提供基于消息包的可靠的數(shù)據(jù)傳輸功能。

（2）數(shù)據(jù)重傳功能。發(fā)送方收到接收方發(fā)來的重發(fā)請求，將需要重發(fā)的數(shù)據(jù)包發(fā)出。

（3）丟棄重復包功能。接收方對收到的重復消息包，進行簡單的丟棄。

（4）流量控制功能。

圖1 協(xié)議層次結構圖

2.2 可靠UDP傳輸協(xié)議報文結構

可靠UDP傳輸協(xié)議的報文結構如圖2所示，從圖中可以看出，可靠UDP傳輸協(xié)議的報文結構就是在UDP報文的數(shù)據(jù)填充部分添加一些自定義字段與UDP包頭一起構成可靠UDP傳輸協(xié)議的包頭，而剩余部分用來填充真實數(shù)據(jù)。其填充的字段分別為：

MessageType（消息類型）用于識別數(shù)據(jù)包類型，包括數(shù)據(jù)傳輸請求消息、數(shù)據(jù)包發(fā)送消息、數(shù)據(jù)包確認消息等，占用兩個字節(jié)空間。

Length（數(shù)據(jù)包總長度）用于標識數(shù)據(jù)包類型以及數(shù)據(jù)（Data）總長度，本文設計的可靠傳輸協(xié)議約定數(shù)據(jù)包長度最大不超過1436個字節(jié)，所以Length占用兩個字節(jié)空間即可。

MessageNumber （消息傳輸序號）用于標識當前發(fā)送的數(shù)據(jù)包在整個消息中的位置，占用四個字節(jié)空間。

圖2 改進協(xié)議報文結構

2.3 可靠傳輸內部機制

2.3.1 三次握手機制

TCP協(xié)議建立連接需要一個3次握手的過程[2]，連接成功后，對連接進行維護直到該連接被銷毀。因此，仿照TCP連接的建立過程，我們在連接開始的時候，模擬TCP協(xié)議的三次握手過程，通過改進的可靠UDP協(xié)議也進行了一個類似的過程。如圖3所示，該過程分為三個步驟：

第一次握手：建立連接時，網點A發(fā)送一個傳輸請求給網點B，并進入等待網點B的確認狀態(tài)中。

第二次握手：網點B收到請求后，對該請求進行確認，發(fā)送一個請求應答的報文給網點A。

第三次握手：網點A收到網點B的請求應答后，向網點B發(fā)送確認（傳輸應答），此確認包發(fā)送完畢后，網點A和網點B都進入完成狀態(tài)，三次握手成功建立。

圖3 簡單的3次握手

2.3.2 數(shù)據(jù)包確認機制

由于若是僅僅使用基于時間的選擇性確認機制時，當傳輸大數(shù)據(jù)時，可能會由于帶寬問題，發(fā)送方A向接收方B發(fā)送大量數(shù)據(jù)包，而在預定時間間隔超時之前，發(fā)送方A由于待證實的隊列得不到證實而無法繼續(xù)發(fā)送（此時待證實的隊列已滿），只有等到接收方B定時器超時后，向A發(fā)送ACK包，證實發(fā)送隊列的消息，A才能繼續(xù)發(fā)送，大大降低了數(shù)據(jù)傳輸效率。所以本文采用基于時間的選擇性確認和基于數(shù)據(jù)包數(shù)目的累積確認相結合的確認機制，其算法如下：

if（數(shù)據(jù)包時間確認計時器到時）

{

接收方給發(fā)送方發(fā)送ACK包 AND

數(shù)據(jù)包時間確認定時器歸零 AND

數(shù)據(jù)包接收計數(shù)器歸零;

}

else if （數(shù)據(jù)包接收計數(shù)器達到預定值）

{

接收方給發(fā)送方發(fā)送ACK包 AND

數(shù)據(jù)包時間確認定時器歸零 AND

數(shù)據(jù)包接收計數(shù)器歸零;

}

在這種確認機制下，當移動網絡中帶寬不足，發(fā)送速率較小時，主要是基于時間的選擇性確認機制起到作用。

2.3.3 流量控制機制

協(xié)議中采取滑動窗口的機制來實現(xiàn)數(shù)據(jù)傳輸中的流量控制的功能。滑動窗口的機制在文獻[3][4]中都有提及。協(xié)議中的數(shù)據(jù)報文中用于標記數(shù)據(jù)傳遞的序號用2.2中設計的MessageNumber表示，采用無符號整數(shù)，取值為0～232-1，對應圖中的大圓所代表的循環(huán);發(fā)送方和接收方的緩沖區(qū)大小設置相同，分別對應圖中的兩個小循環(huán)。

利用滑動窗口實現(xiàn)流量控制的方法是：當接收方收到一條消息之后就將滑動窗口中的接收窗口大小減1。只有在確定上層應用將接收到的消息處理完成后才還原對接收窗口的大小的操作;接收方發(fā)現(xiàn)發(fā)送窗口的大小增加后，表明可以接收更多的數(shù)據(jù)，會向發(fā)送方發(fā)送相應的請求，發(fā)送方根據(jù)請求調整發(fā)送窗口的大小。通過這樣就能夠有效的控制發(fā)送方發(fā)送數(shù)據(jù)的速度，達到流量控制的效果，防止網絡擁塞的情況發(fā)送。

3.總結

本文以對比的方式介紹了TCP和UDP傳輸協(xié)議，并指出了各自的優(yōu)缺點：TCP協(xié)議是面向連接的基于流模式的傳輸協(xié)議，高可靠但效率較低;UDP協(xié)議是面向無連接的基于數(shù)據(jù)報的傳輸協(xié)議，高效但不可靠。最后，在UDP協(xié)議的基礎上，通過增加簡單的三次握手，確認重傳機制，滑動窗口機制，設計出了一種基于UDP的可靠傳輸協(xié)議，使其在可靠性和傳輸效率之間達到一個良好的統(tǒng)一與折衷。

參考文獻

[1]Douglas er，林瑤，張娟，王海等.用TCP/IP進行網際互聯(lián)――原理、協(xié)議與結構（第五版）[M].北京：電子工業(yè)出版社，2009.

篇5

C是與RCM2200配套使用的軟件開發(fā)語言，它擁有豐富的庫函數(shù)以便程序員編程時調用，結果表明，運用該語言能實現(xiàn)基于RCM2200以太網與異步串口之間的成功通信。

關鍵詞 嵌入式系統(tǒng)；RCM2200；UDP報文；串口通信

1 引言

目前，嵌入式技術已經廣泛滲入并應用到各領域，涉及到多種傳統(tǒng)及現(xiàn)代技術，形成了前所未有的多學科、多領域的交叉與融合。由Z-World公司推出的RCM2200[1]是一款低成本的嵌入式微控制器核心模塊，它采用Dynamic C?[2]這一專門為Z-World產品創(chuàng)建的集成的C 編譯器、編輯器、鏈接器、裝載器和調試器，便于實現(xiàn)快速開發(fā)應用，加快產品投放到市場。

UDP協(xié)議[3][4]是比較著名的傳輸層協(xié)議之一，它與TCP協(xié)議一樣是基于IP協(xié)議的，但與TCP不同的是它不需要協(xié)議層提供質量保證，因此，在需要實時數(shù)據(jù)傳輸?shù)那闆r下應用比較廣泛。并且，因為不提供質量保證，服務器沒有必要一直處于等待狀態(tài)，從而大大減輕了服務器的負擔。在某些情況下，還可以根據(jù)需要給UDP報文加上一些質量保證控制，有很大的靈活度。

在不遠的將來，將設備與網絡相連將成為一種趨勢。在諸如GPS串口數(shù)據(jù)網絡收發(fā)以及某些語音傳輸、實時監(jiān)控等多種場合，實現(xiàn)以太網與異步串口數(shù)據(jù)之間的通信是非常必要的。本文介紹了一種基于RCM2200嵌入式微控制器核心模塊利用UDP報文實現(xiàn)網絡與串口互通的方法，可以迅速實現(xiàn)將串口與網絡相連接。

2 系統(tǒng)原理及功能

RCM2200采用Rabbit半導體公司推出的高性能8位器件－Rabbit2000型微處理器；帶RJ-45插口的內置10Base-T端口簡化了網絡連接，便于開發(fā)帶以太網接口的監(jiān)控、通訊設備；配備有4個串行口，方便擴展聯(lián)接；擁有26根并行的I/O引線以及16根可設置的I/O引線，無須擴展即可完成一般的I/O任務；擁有256K Flash，128K SRAM， 用于代碼存儲和數(shù)據(jù)存儲；時間、日期、看門狗、定時器等一應俱全；且其采用雙列直插式引腳，尺寸僅為59 x 41 x 22 mm。這種結構促進了嵌

入式系統(tǒng)的快速開發(fā)，并可實現(xiàn)集成的以太網連接。

RCM2200系統(tǒng)的基本框架結構如圖1所示。

圖1 RCM2200系統(tǒng)結構

RCM2200采用Dynamic C?語言進行軟件開發(fā)，與標準C語言相比，Dynamic C的改進和差異在于使得在功能強大的嵌入式系統(tǒng)上進行實時

編程變得非常容易。 語言的擴展包括多任務和優(yōu)

先多任務的構造，當供電失敗時，能夠保護寫入變量， 能夠寫入到中斷程序中去。標準C函數(shù)庫，特定板的外圍驅動，芯片外圍設備，以及其他的性能以源代碼的形式包含在Dynamic C中。完全支持匯編語言，在對時間要求較高的應用中，匯編代碼可以方便的與C代碼混用。

在該開發(fā)系統(tǒng)中將RCM2200的以太網接口與當?shù)鼐钟蚓W相連，選擇一個串口與計算機的串口相連。由以太網發(fā)送UDP報文給RCM2200微控制器核心模塊經過處理后通過串口發(fā)送給計算機，由計算機串口發(fā)送數(shù)據(jù)給RCM2200微控制器核心模塊經過處理后通過其上的網絡口發(fā)送UDP報文給以太網，從而實現(xiàn)基于RCM2200以太網和串口之間的通信。

3 UDP協(xié)議的實現(xiàn)

UDP協(xié)議是比較著名的傳輸層協(xié)議之一，它使用IP作為網絡層協(xié)議，為應用程序發(fā)送和接收數(shù)據(jù)報。但是，它提供無連接服務，是不可靠傳輸。因此，UDP報文主要用于需要實時數(shù)據(jù)傳輸?shù)那闆r，一次傳輸少量的數(shù)據(jù)。在某些對實時性要求很高的場合，利用UDP報文進行數(shù)據(jù)傳輸是非常必要的，但往往要采用一些可靠性方案，以防止有漏傳、誤傳的現(xiàn)象發(fā)生。

3.1 客戶機/服務器程序設計模式

客戶機/服務器的程序設計模式在網絡程序設計中被大量的應用。這種設計模式將整個系統(tǒng)分為兩大部分——服務器部分和客戶機部分。客戶機向服務器提出請求，服務器對請求作相應的處理將結果返回給客戶機。

根據(jù)不同的實際情況，客戶機/服務器的通信存在對稱和非對稱兩種方式。在對稱的方式下，通信的每一方都可能扮演主從角色；在非對稱的方式下，一方不可改變的認為是主機，而另一方則是從機。無論是對稱的或是非對稱的，當服務被提供時必然存在客戶進程和服務進程。基于UDP協(xié)議的通信既可采用對稱方式也可采用非對稱方式。

3.2 數(shù)據(jù)報套接字

套接字（socket）是通信的基石，是支持TCP/IP協(xié)議的網絡通信的基本操作單元。它是網絡通信過程中端點的抽象表示，包含進行網絡通信必須的五種信息：連接使用的協(xié)議，本地主機的IP地址，本地進程的協(xié)議端口，遠地主機的IP地址，遠地進程的協(xié)議端口。

UDP協(xié)議支持數(shù)據(jù)報套接字。這種套接字可以采用客戶/服務器模式，以全雙工方式工作，接收發(fā)送可以同時進行，但并不保證數(shù)據(jù)傳輸?shù)目煽啃浴⒂行蛐院蜔o重復性，需要由程序員負責管理數(shù)據(jù)報的排序和可靠性。

3.3 使用Dynamic C實現(xiàn)UDP報文的傳輸

Dynamic C提供了許多支持TCP/IP協(xié)議的庫函數(shù)。其中，DCRTCP.LIB是最主要的函數(shù)庫。

下面將簡要介紹UDP協(xié)議下的基本通信流程。

3.3.1 調用本地初始化函數(shù)

void sock_init(void)

該函數(shù)將使用默認配置初始化本地信息包驅動器以及DCRTCP.LIB函數(shù)庫。該函數(shù)必須在其他網絡庫函數(shù)被使用前進行調用。

3.3.2 打開數(shù)據(jù)報套接字

int udp_open( *s， lport， remote_IP， port， *data_handler ())

其中的參數(shù)解釋如下：

s : 指向UDP套接字的指針；

lport : 本地協(xié)議端口；

remote_IP : 可接受的遠地主機IP地址，如果該項為-1，則支持廣播通信；

port : 可接受的遠地進程協(xié)議端口，如果該項為-1，則為廣播數(shù)據(jù)報；

data_handler() : 如果接收到數(shù)據(jù)則調用該函數(shù)；

該函數(shù)的返回值，如果成功返回非零，否則返回零值。

3.3.3 接收遠地主機發(fā)送的數(shù)據(jù)報

int udp_recv( *s， *buf_recv， recv_len)

當套接字初始化后用該函數(shù)掃描接收緩沖區(qū)，，察看是否有數(shù)據(jù)報到達。其中，

buf_recv : 指向用于存放已到達數(shù)據(jù)報的數(shù)組的指針；

recv_len : 存放數(shù)據(jù)報的數(shù)組的大小。

如果接收到數(shù)據(jù)報則返回數(shù)據(jù)報的長度；否則返回-1。

3.3.4 發(fā)送數(shù)據(jù)報給遠地主機

int udp_send( *s， *buf_send， send_len )

調用該函數(shù)發(fā)送數(shù)據(jù)報給遠地主機。如果成功返回該數(shù)據(jù)報的長度，否則返回-1。

buf_send : 指向待發(fā)送數(shù)據(jù)報的指針；

send_len : 待發(fā)送數(shù)據(jù)報的長度。

3.3.5 網絡信息處理函

int tcp_tick( *s )

該函數(shù)將察看網絡連接狀態(tài)，檢查數(shù)據(jù)報的到達情況，處理新到數(shù)據(jù)報并重傳丟失的數(shù)據(jù)報。若出現(xiàn)網絡連接被復位及套接字已關閉的情況或參量s為NULL，則返回值為零；否則返回非零值。

3.3.6 關閉套接字

void sock_close( *s )

當數(shù)據(jù)傳送工作完成或傳送過程中發(fā)生錯誤時，可調用該函數(shù)關閉套接字

4

串口通信的實現(xiàn)

4.1 RS232電平與TTL電平的轉換

PC機的串行接口是符合EIA RS-232C規(guī)范的外部總線標準接口，而RCM2200配備有四個串行接口，都是采用TTL電平，因此兩者之間必須進行電平轉換。以RCM2200的串行口C（位于核心模塊的J4插槽上）為例，電平轉換如圖2所示。

圖2 RS232與TTL電平轉換圖

4.2 使用Dynamic C實現(xiàn)串口數(shù)據(jù)的傳輸

Dynamic C提供了一些與計算機串行口進行通信的函數(shù)可供用戶程序調用，下面簡要介紹其中的一部分。

4.2.1 打開串行接口

int serXopen( bard )

bard : 長整型，每秒鐘傳送的比特數(shù)。

該函數(shù)用于打開RCM2200的串行接口，由于RCM2200核心模塊擁有四個串行口，故X可根據(jù)需要取為A\B\C\D其中一個。在調用該函數(shù)之前，還必須先定義串行口的輸入輸出緩沖區(qū)大小，通常情況下設定為2n-1，否則就采用默認值31，但在編譯時會給出警告。該函數(shù)的返回值：成功則為1，否則為0。

4.2.2 讀取PC機串行口數(shù)據(jù)

int serXgetc()

/* X = A|B|C|D */

程序可以調用該函數(shù)查詢串行口是否有字符來到，如果有，返回該字符值；否則，返回值-1。

4.2.3 發(fā)送數(shù)據(jù)到PC機串行口

int serXputs( *s )

int serXwrite( s， length ) /* X = A|B|C|D */

這兩個函數(shù)均可用于發(fā)送字符串給計算機的串行口，返回成功發(fā)送的字符數(shù)。

s : 待發(fā)送字符串的首地址；

length : 待發(fā)送字符串的長度。

4.2.4 關閉串行口

void serXclose()

/* X = A|B|C|D */

該函數(shù)用于關閉已經打開的串行口。

5

實現(xiàn)以太網與串口之間的通信

5.1

定義網絡以及串口初始化數(shù)據(jù)

在程序的開頭，必須使用#define定義一些初

始化數(shù)據(jù)，比如：RCM2200所使用的本地IP地址以及端口，與之通信的遠地IP地址以及端口以及串口輸入輸出緩沖區(qū)的大小等等。

5.2 主程序

在主程序中調用PC機串口發(fā)送字符串給RCM2200經過處理后再由RCM2200發(fā)送UDP報文給以太網以及RCM2200接收以太網發(fā)送來的UDP報文后再送給計算機的串行口兩個子程序。

main()

{

sock_init(); //初始化網絡庫函數(shù)

: //打開串行口及網絡套接字

for(;;;)

{

tcp_tick(NULL);//察看套接字狀態(tài)

init_comm();//網絡發(fā)報文串口接收

comm_init();//串口發(fā)數(shù)據(jù)網絡接收

}

}

5.3網絡發(fā)報文串口接收

子程序init_comm() 使用庫函數(shù)udp_recv查詢RCM2200以太網接口是否有UDP報文來到，如果沒有則返回主程序，否則將UDP報文存放到buf_init數(shù)組中，然后調用serCputs(buf_init)通過RCM2200的串行口C發(fā)送到計算機的串行口。值得一提的是，當RCM2200接收到了一次報文之后，它將自動關閉接收報文的套接字，因此，如果還想接受下一次發(fā)送的報文，必須再次調用函數(shù)udp_open打開該套接字。

5.4串口發(fā)字符串網絡接收

子程序 comm_init()調用函數(shù)serCgetc()用于查詢計算機的串行口是否有數(shù)據(jù)到來，如果沒有則返回主程序，否則將接收到的字符存儲到buf_comm數(shù)組中，直到檢測到結束符到來，將字符串以UDP報文的形式通過函數(shù)udp_send發(fā)送給以太網。如果發(fā)送成功，則返回主程序等待下一次數(shù)據(jù)的到來，否則關閉該套接字后重新打開再返回主程序等待。

5.5程序調試結果

在該程序的調試過程中，利用Visual C++語言編寫了一個接收和發(fā)送UDP報文的程序用于以太網的計算機上，另外還使用了從網上下載的串口調試幫助軟件，結果表明，該程序能實現(xiàn)基于RCM2200以太網與異步串口之間的成功通信。

結論

RCM2200是為了促進嵌入式系統(tǒng)的快速開發(fā)和實現(xiàn)集成的以太網連接而設計的。集成的以太網口允許用戶通過使用經濟的網絡軟件進行瞬間的本地連接或全球范圍的連接。另外，RCM2200還提供了四個串行口用于和其他設備的串行口進行數(shù)據(jù)交換。

RCM2200使用Dynamic C軟件開發(fā)環(huán)境，支持C語言、匯編語言，擁有豐富的庫函數(shù)可供用戶調用，并具有單步編譯、斷點設置、單步執(zhí)行、代碼分解、監(jiān)視表達式等優(yōu)秀性能。

使用Dynamic C接收和發(fā)送UDP報文時，由于網絡對該報文的傳輸不提供質量保證，在每完成一次操作后，必須及時檢查套接字的狀態(tài)，避免發(fā)生誤傳、漏傳以及套接字關閉等現(xiàn)象。在發(fā)送和接收串口數(shù)據(jù)時，要注意使RCM2200的串口數(shù)據(jù)傳輸波特率與PC機保持一致，這樣，才能保證正確傳輸。

參考文獻

【1】Z-World， Inc. RabbitCore RCM2200 User’s Manual 2001年

【2】Z-World， Inc. Dynamic C premier User’s Manual

1999年

篇6

【關鍵詞】 無線網絡 多媒體 通信 傳輸技術

引言：隨著社會的發(fā)展，人們生活水平日漸提升，其安全防護意識也有所增強，在先進技術支持下，無線網絡應急多媒體通信的應用愈加廣泛，不僅保證了人們的安全，還提高了其生活質量。但實際應用中，對應急多媒體通信有著較高的要求，如：實時性、可靠性與連續(xù)性等，而無線網絡應急多媒體通信未能滿足上述要求，因此，本文探討了其傳輸協(xié)議與通信終端系統(tǒng)，旨在進一步提高其整體性能。

一、應急多媒體通信的無線網絡特點

其一，低寬帶，通常情況下，其寬帶僅為1-2個數(shù)量級；其二，時變性，對于應急通信終端來說，其主要用于移動情況，此時的應用環(huán)境會影響無線網絡的寬帶變化，特別是移動處于高速狀態(tài)下，可能發(fā)生突變；其三，非對稱性，無線網絡的上行與下行寬帶各異；其四，影響較大，在實際數(shù)據(jù)傳輸中信道干擾較為嚴重，同時誤碼率較高，通常情況下，與有線傳輸相比，會高出幾個數(shù)量級。在實際研究與設計過程中，結合上述特點，要求應急多媒體通信傳輸技術應符合以下要求：第一點，在保證清晰度的前提下，占用較小的寬帶資源；第二點，寬帶大小變化過程中應具備較強的自適應性；第三點，多媒體數(shù)據(jù)傳輸時應保證較小的延時；第四點，數(shù)據(jù)傳輸應具備較高的可靠性與穩(wěn)定性。

二、 應急多媒體通信流媒體協(xié)議的選用

目前，傳輸協(xié)議較多，其中使用頻率較高的有用戶數(shù)據(jù)報協(xié)議（UDP）與傳輸控制協(xié)議（TCP）。

1、UDP協(xié)議。此協(xié)議屬于無連接協(xié)議，其在網絡中主要用于處理數(shù)據(jù)包，它的優(yōu)點為簡單的分組格式、較小的頭部開銷、較快的處理速度，因此，UDP作為應用層時，所提供的傳輸服務則會缺少可靠性。在選用UDP協(xié)議時，應考慮UDP的特性，通常情況下，其可用于大信息量的音頻、視頻與普通數(shù)據(jù)的實時傳送[1]。UDP協(xié)議的快速與簡單等優(yōu)點較為顯著，滿足了大多數(shù)流媒體的應用需求，但由于此協(xié)議缺少可靠性與可控性，導致其極易出現(xiàn)各種問題。

2、TCP協(xié)議。此協(xié)議的設計主要是為了服務有線網絡，當前，其作為傳輸層協(xié)議的使用頻率較高。由于有線網絡擁塞問題較為嚴重，進而極易出現(xiàn)報文丟失，同時其出錯率也相對較低，而使用TCP協(xié)議后，經發(fā)送方、接收方與網絡的協(xié)調合作，進而保證了有線網絡數(shù)據(jù)傳輸?shù)男Чτ跓o線網絡而言，如果其使用TCP協(xié)議，為了保證多媒體數(shù)據(jù)的高效傳輸，需要較大的緩沖區(qū)，同時也需要充足的寬帶，但在實際應用中不具備上述條件，隨之出現(xiàn)了諸多問題，如：較高的丟包率、較差的網絡狀況等。

3、混合協(xié)議。現(xiàn)階段，流媒體傳輸協(xié)議中最為流行的為RTSP/RTP/RTCP/UDP協(xié)議，實時傳輸中應使用RTP與RTCP兩個端口，前者借助UDP協(xié)議，以此保證了實時視音頻數(shù)據(jù)的快速傳輸，后者借助TRCP協(xié)議，從而實現(xiàn)了對傳輸信息的有效控制，通過二者，最終實現(xiàn)了高效傳輸[2]。UDP具有良好的實時性，但其不具備擁塞控制機制，導致UDP協(xié)議易丟失數(shù)據(jù)，進而擦混熟速率也將受到較大的影響；TCP擁有擁塞控制機制、重傳機制與流量控制機制，其實施需要借助大量的反饋信息，而此時的信息會占用一定的寬帶。在此情況下，本文結合二者的優(yōu)缺點，設計了TCP/UDP混合協(xié)議，通過二者優(yōu)點的充分發(fā)揮，兼顧了傳輸效率與可靠性，以此保證了無線網絡視音頻的高質量傳輸。

三、ARM/DSP雙核嵌入式系統(tǒng)

在無線網絡中傳輸視音頻時，利用TCP/UDP混合協(xié)議，保證了傳輸?shù)乃俣扰c質量，但為了保證整個音視頻通信的效果，仍需要注重其終端，在強有力終端支持下，進一步增加多媒體數(shù)據(jù)傳輸?shù)乃俣龋M一步提高其通信的質量。目前，國內外學者在研究多媒體時，主要關注的內容為嵌入式終端系統(tǒng)計算能力的提高。本文提出了ARM/DSP雙核移動多媒體嵌入式系統(tǒng)，其中ARM端的主控芯片為S3C2440A芯片，DSP端的主控芯片為BlackFin533芯片，它可支持WinCE與Linux系統(tǒng)，充分發(fā)揮了ARM的控制性能與DSP的視頻數(shù)據(jù)處理能力。ARM/DSP雙核嵌入式系統(tǒng)主要是由ARM、DSP及其相連接的SPI接口三部分構成的，ARM作為操作系統(tǒng)，主要提供的功能有圖形界面、應用程序與網絡通信功能；DSP需要提供SPI通信協(xié)議，從而實現(xiàn)了相應的操作[3]。

總結：綜上所述，本文分析了無線網絡應急多媒體通信傳輸技術，重點分析了其傳輸協(xié)議及終端系統(tǒng)，相信，通過TCP/UDP混合協(xié)議及ARM/DSP雙核嵌入式系統(tǒng)的應用，無線網絡應急多媒體通信的質量將不斷提高。

參 考 文 獻

[1]何君燕，劉凱. 井下無線多媒體傳感器網絡圖像傳輸技術研究[J]. 軟件，2012，01：112-115.

篇7

關鍵詞：SOCKS；NAT；P2P；STUN；穿透

中圖分類號：TP393.03

IP網絡地址是整個互聯(lián)網的基礎，目前大多數(shù)網絡設備使用的都是IPv4地址。IPv4地址提出的時候沒有想到互聯(lián)網發(fā)展如此之快：根據(jù)2012年的思科報告，全球有23億互聯(lián)網用戶，到2017年，全球將會有約36億互聯(lián)網用戶。到2017年，將會有超過190億全球網絡聯(lián)接（固定/移動個人設備、M2M聯(lián)接等）。現(xiàn)在IPv4的地址已經不夠這些設備使用了，為了解決這個問題，IETF提供了NAT[1][2]方案，這個方案使用NAT將網絡分為外網和私網，每個私網都可以重用，這個方案大大緩解了IPv4地址匱乏的問題。但是這個方案導致了一個問題，對于想對外提供服務的NAT私網內的用戶而言，這個功能會受到限制，最主要的原因是NAT外的用戶不能直接訪問到NAT內私網中的計算機數(shù)據(jù)。這種情況導致了互聯(lián)網上P2P互相訪問的困難。不過目前還有很多應用需要這種服務器式的被動訪問，比如SOCKS4/5[3][4]協(xié)議，這個是最為知名的一種協(xié)議，通過這個協(xié)議服務，能夠透明地中轉服務器和客戶端之間的數(shù)據(jù)。然而NAT的引入導致在NAT后面的用戶無法對外提供SOCKS4/5服務。本文試圖使用穿透NAT的P2P技術，使在NAT內的SOCKS4/5服務也能提供給外部機器使用，真正實現(xiàn)對于互聯(lián)網的任何一個用戶都能夠直接訪問。

1 穿透NAT的協(xié)議

為了解決引入NAT設備后網絡互聯(lián)出現(xiàn)的問題，有大量協(xié)議被發(fā)明和使用，比如MIDCOM[5]、TURN[6]等，但是這些協(xié)議大都需要第三方介入，這會導致一些問題。如：中轉第三方的帶寬、處理能力以及實時性。這隨著NAT后面節(jié)點的增多，數(shù)據(jù)量的增長以及對于實時性的嚴格要求等，這些協(xié)議處理都存在問題。我們希望兩個機器能夠實現(xiàn)真正溝通，而不是通過中繼的方式。UPNP和STUN這兩個協(xié)議能夠實現(xiàn)這種真正直接的溝通。

1.1 UPNP[7]

UPNP（Universal Plug and Play）是由UPnP Forum推廣的一套網絡協(xié)議。該協(xié)議的目標是使家庭網絡和公司網絡中的各種設備能夠相互無縫連接，并簡化相關網絡的實現(xiàn)。UPnP通過定義和基于開放、遵循因特網通訊網協(xié)議標準的UPnP設備控制協(xié)議來實現(xiàn)這一目標。任何設備都能自動加入一個網絡，獲取自己的IP地址，宣布自己的名字，根據(jù)請求檢查自身功能并且檢測出其它設備和它們的功能。支持UPnP的設備允許UPnP數(shù)據(jù)包通過IGD協(xié)議在沒有用戶交互的情況下，無障礙的通過NAT。但是UPnP的缺點是：它要求所有網絡中的設備都支持UPnP，即使單臺設備不符合UPnP標準的，我們就無法實現(xiàn)一種P2P網絡。

1.2 STUN [8][9]

STUN協(xié)議是一種輕量級的客戶端-服務器模式的協(xié)議，它不需要任何管理員進行網絡配置，就能發(fā)現(xiàn)它們和公網之間是否存在NAT，并確定NAT的類型。STUN協(xié)議目前僅僅支持使用UDP報文穿透Cone NAT[10]。此協(xié)議利用Cone NAT傳輸 UDP的原理進行穿透[11][12][13]：私網內某個機器通過Cone NAT發(fā)送UDP數(shù)據(jù)到外網某個機器，內部IP地址和端口的UDP數(shù)據(jù)經過Cone NAT被映射到一個外部地址，在某個時間段內這個內部IP地址和端口將被轉換為固定外部IP地址和端口（這個過程將被Cone NAT記錄，并且存儲為一個Session）。此后，如果外部Session對應的機器發(fā)送UDP數(shù)據(jù)到這個Cone NAT，Cone NAT會把這個數(shù)據(jù)包轉發(fā)到內部映射的這個地址上。目前IETF定義的STUN協(xié)議目前能夠穿透Cone NAT，但是不能穿透Symmetric NAT。不過我們可以通過修改STUN協(xié)議來實現(xiàn)穿透Symmetric NAT的目的。[14][15][16]

2 SOCKS4/5協(xié)議

SOCKS協(xié)議是一種應用層次的協(xié)議，它提供一種通用方案，能為應用程序提供基于TCP和UDP數(shù)據(jù)報文的服務，但是它不能ICMP之類的底層通訊協(xié)議，SOCKS協(xié)議從概念上來講是介于應用層和傳輸層之間的“中介層（shim-layer）”，SOCKS V4協(xié)議為HTTP、FTP、TELNET、WAI和GOPHER等基于TCP協(xié)議的客戶/服務器程序提供了方案。新的SOCKS V5協(xié)議在SOCKS V4協(xié)議基礎上作了進一步擴展，從而可以支持UDP協(xié)議，并對其框架規(guī)定作了擴展，以支持安全認證方案。同時它還采用地址解析方案以支持域名和IPV6地址。

SOCKS協(xié)議利用握手（negotiation），請求（Requests），應答（Replies）等過程完成對于上述協(xié)議的轉發(fā)。一般而言SOCKS4/5服務器通常綁定在1080端口上。

3 NAT穿透SOCKS4/5協(xié)議實現(xiàn)

3.1 協(xié)議方案

如圖1，為了實現(xiàn)雙方都在NAT后的機器的SOCKS4/5之間的直接通信，我們需要一個雙方都能訪問的中間服務先把兩邊的機器關聯(lián)起來。在公網上我們需要架設一個雙方都能夠聯(lián)系的服務器，然后通過STUN協(xié)議幫助雙方完成直接通信。一旦直接聯(lián)系完成，我們就不再需要公網中間服務了，此后我們采用可靠的UDP傳輸協(xié)議完成SOCKS4/5客戶端和服務器的直接數(shù)據(jù)傳輸。

此協(xié)議分為兩個部分，首先是通過STUN協(xié)議完成NAT后兩個機器的SOCKS4/5客戶端關聯(lián)器和SOCKS4/5服務器關聯(lián)器的直接通信，然后使用可靠的UDP協(xié)議完成SOCKS4/5客戶端服務器的數(shù)據(jù)通信。

3.2 建立直接通信

我們可以使用STUN協(xié)議來幫助雙方都在NAT后的機器建立直接的通信。STUN協(xié)議通過一種叫做UDP hole punching的機制來實現(xiàn)這一目的。一旦完成這個操作，兩個NAT設備后的機器就能夠實現(xiàn)直接的網絡通信而不再需要STUN服務器的介入了。

如圖2顯示SOCKS4/5客戶端關聯(lián)器和SOCKS4/5服務端關聯(lián)器通過STUN協(xié)議幫助建立直接通信的過程。

（1）客戶端關聯(lián)器通過NAT A連接到服務器，服務端關聯(lián)器通過NAT B連接到服務器，服務器記錄客戶端關聯(lián)器和服務端關聯(lián)器的外網地址和端口。

（2）服務器向客戶端關聯(lián)器發(fā)送服務端管理器的外網地址和端口消息，服務器向服務端關聯(lián)器發(fā)送客戶端關聯(lián)器的外網地址和端口消息。

（3）客戶端關聯(lián)器向服務端關聯(lián)器的外網地址和端口發(fā)送hole punching消息。雖然這個數(shù)據(jù)包在NAT B的時候會被阻止（非Full Cone NAT禁止沒經過關聯(lián)的外網IP直接訪問內網），但是這個UDP數(shù)據(jù)包在經過NAT A的時候，會在NAT A上建立一個Session，這個Session記錄了本地客戶端關聯(lián)器與服務端關聯(lián)器外網地址的關聯(lián)信息。

（4）服務端關聯(lián)器發(fā)送回應消息到客戶端關聯(lián)器，NAT A由于有步驟3由hole punching消息建立的Session，NAT A將會把這個消息轉發(fā)到客戶端關聯(lián)器，完成后雙方建立直接的消息通信。

3.3 SOCKS4/5數(shù)據(jù)傳輸

由于STUN協(xié)議僅僅支持UDP的穿透，但是SOCKS4協(xié)議只支持TCP的連接，為了兼容SOCKS4/5協(xié)議，我們使用轉發(fā)的機制來保證我們的程序能夠完美匹配SOCKS4/5這兩種協(xié)議。

如圖3所示：

（1）SOCKS客戶端關聯(lián)器綁定本機端口1080。本地SOCKS客戶端程序（如IE等程序）設置本地SOCKS為本地127.0.0.1080。SOCKS客戶端按需要訪問某個公網服務器或者遠端對方的私網服務器。

（2）客戶端關聯(lián)器接收到SOCKS客戶端發(fā)送過來的數(shù)據(jù)，不做任何改變，通過可靠的UDP（如UDT協(xié)議，此協(xié)議可以提供類似TCP的可靠數(shù)據(jù)傳輸）數(shù)據(jù)傳輸發(fā)送到已經建立的直接通信的服務端關聯(lián)器。

（3）服務端關聯(lián)器接收到可靠的UDP傳輸過來的數(shù)據(jù)，然后不做任何改變的將這個數(shù)據(jù)通過TCP轉發(fā)到SOCKS4/5的真正服務器程序（127.0.0.1：1080）。

（4）SOCKS服務器連接實際需要訪問的公網或者私網服務器（如需要訪問的HTTP服務）。

4 實驗測試

4.1 實驗設備

系統(tǒng)硬件：三臺PC，配置：CPU P6 3.40GHz 4GM 內存

NAT設備：兩臺NetGear WPN824路由器。

操作系統(tǒng)軟件：Windows7。

4.2 實驗效果

程序經過實際測試證明，支持NAT穿透的SOCKS協(xié)議完全可行。測試顯示瀏覽器瀏覽網站與直接使用SOCKS協(xié)議連接的效率基本接近，但是由于中轉過程的花費，瀏覽大型網站可能相對于直接SOCKS連接慢了5%，不過這個基本不會影響用戶的感受。

5 結論

SOCKS協(xié)議是客戶端/服務器模式，這種模式由于NAT的引入導致如果服務在NAT后面將會出現(xiàn)問題。本論文使用一種新的客戶端-服務端關聯(lián)器方法使得SOCKS協(xié)議能夠支持NAT的穿透，這個使得SOCKS協(xié)議能夠被大多數(shù)工作在NAT后的計算機使用。并且這種關聯(lián)器方法與上層的協(xié)議沒有任何直接關系，我們可以擴展此種協(xié)議，使得很多原來不支持NAT穿透的協(xié)議也能夠被支持，比如：SMTP、POP3、IMAP、SNMP等。同樣，這個方法也能支持我們定義新的協(xié)議，比如類似QQ一樣即時P2P通訊協(xié)議。

參考文獻：

[1]P Srisuresh， M Holdrege. IP network address translator （NAT）terminology and considerations.RFC 2663.August 1999.

[2]G Tsirtsis and P Srisuresh. Network address translation-protocol translation （NAT-PT）.RFC 2766.February 2000.

[3]Ying-Da Lee， SOCKS： A protocol for TCP proxy across firewalls， http：///txt/socks4.protocol.

[4]M. Leech ， M. Ganis， Y. Lee， R. Kuris， D. Koblas， L. Jones. SOCKS Protocol Version 5. RFC 1928.

[5]P Srisuresh， J Kuthan， J Rosenberg， A Molitor，A Rayhan. Middlebox communication architecture and framework.RFC 3303.August 2002.

[6]J. Rosenberg， C. Huitema， and R. Mahy. Traversal using relay NAT （TURN）. Draft-rosenberg-midcom-turn-03， October 2003.

[7]UpnP Forum. Internet gateway device （IGD） standardized device control protocol. November 2001.

[8]J. Rosenberg， J. Weinberger， C. Huitema， R. Mahy.STUNSimple traversal of user datagram protocol（UDP）through network address translators （NATs）.RFC 3489，2003.

[9]J Rosenberg， R Mahy， P Matthews， D Wing. Session traversal utilities for NAT （STUN）. RFC 5389. 2008.

[10]C Jennings. NAT classification results using STUN. RFC 5389. October 2008.

[11]T. Hain. Architectural implications of NAT. RFC 2993. November 2000.

[12]D Senie. Network address translator （NAT）-friendly application design guidelines. RFC 3235. January 2002.

[13]Saikat Guha， Paul Francis. Simple traversal of UDP through NATs and TCP too （STUNT）. http：//nutss.gforge.cis.cornell.edu/stunt.php.

[14]Yuan Wei，Daisuke，et al. A new method for symmetric NAT traversal in UDP and TCP，APAN Network Research Workshop.11-18，August 2008.

[15]王勇，崔修濤，呂釗，李子成.基于探測對Symmetric NAT與端口受限NAT的穿透方案[J].計算機應用，2006，4（26）.

[16]楊璐，沈悅，蔣蕾.一種TCP協(xié)議穿透Symmetric NAT方案[J].計算機工程與應用，2007，43（6）.

篇8

在大型企業(yè)自動化系統(tǒng)中，上層企業(yè)管理層和生產監(jiān)控層一般都采用以太網和PC機，而下層車間現(xiàn)場則采用現(xiàn)場總線和單片機測控設備。上下兩層的溝通，通常采用工業(yè)控制機加以太網卡，再加上PC機插槽上的接口卡或并行打印口的EPP接口卡實現(xiàn)。這種連接方式成本高，開發(fā)周期長。針對這種情況，筆者設計一種單獨的CAN以太網網關互連系統(tǒng)，成功地實現(xiàn)以太網與現(xiàn)有CAN總線網的直接數(shù)據(jù)互聯(lián)。

1 系統(tǒng)結構

系統(tǒng)總體結構分為三部分：現(xiàn)場測控網絡（CAN網絡）、嵌入式透明SX52網關、以太網信息管理終端（如監(jiān)控平臺和網絡數(shù)據(jù)庫等），如圖1所示。

    CAN總線是一個設備互連總線型控制網絡。在CAN總線上可以掛接多達110個設備節(jié)點，各設備間可以自主相互通信，實現(xiàn)復雜網絡控制系統(tǒng)。但設備信息層無法直接到達信息管理層，要想設備信息進入信息管理層需通過數(shù)據(jù)網關。嵌入式透明SX52網關就是為此而設計的。

透明式網關在以太網應用層構建和解析完整的CAN協(xié)議數(shù)據(jù)包。CAN協(xié)議數(shù)據(jù)包作為TCP／IP網絡應用層的數(shù)據(jù)進行傳輸，它對通信數(shù)據(jù)的具體實際意義不做任何解釋。透明式網關由通信處理器、CAN總線控制器和以太網控制器三部分組成。其中SX52單片機為核心處理器，它實現(xiàn)了CAN控制網絡與以太網之間的協(xié)議轉換。以太網信息管理層的控制指令發(fā)送到嵌入式透明SX52網關，將TCP／IP協(xié)議包數(shù)據(jù)轉換為CAN協(xié)議形式發(fā)送至CAN控制網絡中的指定設備節(jié)點，完成信息管理層對現(xiàn)場設備層的控制。同樣地，當CAN網絡上的設備數(shù)據(jù)（如定時采樣數(shù)據(jù)或報警信息）要傳輸?shù)叫畔⒐芾韺訒r，可將數(shù)據(jù)發(fā)送到嵌入式透明SX52網關，再通過網關協(xié)議轉換程序將CAN協(xié)議數(shù)據(jù)封裝成TCP／IP協(xié)議的以太網數(shù)據(jù)幀發(fā)送至以太網上的監(jiān)控計算機。

以太網信息管理終端是一個根據(jù)用戶的具體要求而設計的用戶層應用軟件。它可以是一個WIN32監(jiān)控程序或網絡數(shù)據(jù)庫（記錄CAN節(jié)點設備數(shù)據(jù)）軟件等；甚至可能是CAN節(jié)點設備的服務器軟件，為設備提供較復雜的數(shù)據(jù)處理工作。

2 硬件設計

系統(tǒng)硬件分為兩大部分：CAN總線網絡設備接口設計和嵌入式透明SX52網關設計。

2．1 CAN總線網絡設備接口設計

CAN總線網絡設備接口設計較網關設計簡單。它是在完成設備功能的基礎上加入一個CAN通信控制器接口芯片，實現(xiàn)與CAN總線網絡的連接。考慮到開發(fā)成本和靈活性，筆者在設計中選用PHILIPHS公司的獨立CAN通信控制器SJA1000芯片和CAN總線收發(fā)器82C250芯片。其結構如圖2所示。

2．2 嵌入式透明SX52網關設計

嵌入式透明網關設計是整個系統(tǒng)設計的核心。其結構如圖3所示。它由CAN控制器協(xié)議轉換模塊和以太網控制器協(xié)議轉換模塊兩部分組成。網關硬件中SX52微處理器起核心作用。它是由美國Ubicom公司研制的高速可配置通信控制器，其處理速度相當高。在外接100MHz時鐘時，指令執(zhí)行速度可達100 MIPS。它可實現(xiàn)TCP／IP協(xié)議棧中的ARP、IP、UDP、TCP、HTTP、SMTP、ICMP等網絡協(xié)議。

CAN控制器協(xié)議轉換模塊硬件電路原理如圖3左框圖。它由三部分組成：微控制器SX52、獨立CAN通信控制器SJA1000、CAN總線收發(fā)器82C250。其中SX52為唯一的CPU核心，負責SJA1000的初始化，通過讀寫SJA1000內部寄存器實現(xiàn)數(shù)據(jù)的接收、發(fā)送和錯誤處理等。PCA82C250則提供對總線的差動發(fā)送能力和對CAN控制器的差動接收能力。

    以太網控制器協(xié)議轉換模塊主要由微控制器SX52、以太網通信控制器RTL8019AS和隔離濾波器FB2002組成。RTL8019AS是臺灣Realtek公司制造的一種高集成度的全雙工10Mbps以太網控制芯片，實現(xiàn)了基于Ethernet協(xié)議的MAC層的全部功能，內置16KB的SRAM、雙DMA通道和FIFO完成數(shù)據(jù)包的接收和發(fā)送功能。在網關設計中，使用跳線模式（JP置為高）硬配置RTL8019AS為8位模式。使用RTL8019的低5位地址線A0～A4以及低8位數(shù)據(jù)線D0～D7。SX52的B口的B0～B4腳作為地址線連接RTL8019AS的低5位地址線，B5～B7作為控制線分別連接讀寫時序控制腳IORB、IOWB、IOCHRDY；C口作為數(shù)據(jù)線連接RTL8019AS的低8位數(shù)據(jù)線；A口保留，用作日后擴展。圖3中AT24C64為8KB EEPROM，主要用來保存嵌入式透明SX－52網關的配置信息，如網關IP地址、MAC地址和SJA1000的ID網絡標示符、網絡掩碼AMR和總線定時（BTR0、BTR1）等。這樣，可以靈活方便地修改網關參數(shù)，適應不同環(huán)境，同時也考慮到以后的擴展。

RTL8019AS除與SX52連接外，還將其網絡收發(fā)器的4根引腳TPOUT＋、TPOUT－、TPIN＋、TPIN－通過外接的隔離濾波器FB2002與以太網相連。采用隔離濾波器FB2002是為了提高網絡通信的抗干擾能力。

3 軟件設計

整個互聯(lián)系統(tǒng)的軟件設計可以分為三部分：CAN總線設備接口通信程序、透明網關協(xié)議轉換程序和以太網層應用程序設計。其中，CAN總線設備接口通信程序和透明網關協(xié)議轉換程序的CAN控制器協(xié)議模塊在結構上有較大的相似性，但有可能因采用微控制器不同而導致實現(xiàn)的程序語言相異。因而，在此不作論述，而主要討論后兩個方面的程序設計。

3．1 透明網關協(xié)議轉換程序

透明網關協(xié)議轉換程序的整體設計思路為：當以太網應用層有數(shù)據(jù)要發(fā)送到CAN節(jié)點時，首先，數(shù)據(jù)發(fā)送到透明網關由以太網控制器協(xié)議轉換模塊從傳輸層數(shù)據(jù)報文中解析出完整的CAN協(xié)議數(shù)據(jù)包，存放在數(shù)據(jù)緩沖區(qū)A?再通知總調度模塊，由它調用CAN控制器協(xié)議模塊將CAN協(xié)議數(shù)據(jù)包發(fā)送到CAN總線上。反過來，當CAN設備有數(shù)據(jù)要發(fā)送到用戶層時，首先，數(shù)據(jù)發(fā)送到透明網關由CAN控制器協(xié)議模塊將完整的CAN協(xié)議數(shù)據(jù)包存放在數(shù)據(jù)緩沖區(qū)B?再通知總調度模塊，由它調用以太網控制器協(xié)議轉換模塊將完整的CAN協(xié)議數(shù)據(jù)包作為應用層數(shù)據(jù)封裝起來，再發(fā)送到以太網的應用層。其程序結構如圖4所示。

3．1．1 CAN控制器協(xié)議模塊

CAN控制器協(xié)議轉換模塊程序主要由SJA1000的寄存器讀程序CANRead（）、寫程序CANWrite（）、初始化程序CANInit（）、發(fā)送程序txdsub（）、接收程序rxdsub（）程序組成。之所以要編寫單獨的SJA1000的寄存器讀、寫子程序，這是由SX52芯片只有I／O端口決定的。

選用CAN2．0A協(xié)議構建CAN總線控制網絡，對SJA1000的初始化主要完成控制寄存器CR、驗收代碼寄存器ACR、驗收屏蔽寄存器AMR、總線定時寄存器BTR0，1和輸出控制寄存器OCR的設置。初始化完成后，由總調度模塊監(jiān)控SJA1000控制器。當CAN總線上有數(shù)據(jù)到達時，它調用接收子程序rxdsub（），把這一幀數(shù)據(jù)包存入數(shù)據(jù)緩沖區(qū)B中，然后釋放接收緩沖器。同樣，當有按CAN2．0A協(xié)議格式組合成的一幀數(shù)據(jù)報文在數(shù)據(jù)緩沖區(qū)A中要發(fā)送到CAN總線上去時，總調度模塊將調CAN發(fā)送子程序txdsub（）發(fā)送。

3．1．2 以太網控制器協(xié)議轉換模塊

以太網控制器協(xié)議轉換模塊主要負責從UDP數(shù)據(jù)包中解析出完整CAN協(xié)議報文，存入數(shù)據(jù)緩沖區(qū)A。同時，可能將數(shù)據(jù)緩沖區(qū)B中的完整CAN協(xié)議報文封裝成UDP數(shù)據(jù)報，然后將其發(fā)送到以太網上。

    在通信傳輸層采用UDP協(xié)議是考慮到CAN協(xié)議數(shù)據(jù)報為短幀形式（每個數(shù)據(jù)幀最多為8字節(jié)）。如果采用TCP傳輸協(xié)議，要傳輸8字節(jié)CAN協(xié)議數(shù)據(jù)，要先通過3次握手建立連接，再傳輸數(shù)據(jù)，之后還要通過握手釋放連接。這樣傳輸效率對有限的網絡資源來說無疑是一種浪費。而UDP是無連接的傳輸，可以提高網絡傳輸效率，同時，也減輕網關的處理任務。當然，UDP傳輸協(xié)議是不可靠的，對于控制網絡來說，是不允許的。為了提高通信的可靠性，采用了回傳校驗機制。通過實驗測試表明這種方式是行之有效的。

以太網控制器協(xié)議轉換模塊主要由以太網卡驅動、ARP、UDP協(xié)議的若干個API函數(shù)組成，如NICInit（）、NICDMAInit（）、NICInitTxFrame（）、NICSendTxFrame（）、NICReadAgain（）、ARPCheckIfIs（）、ARPSendResponse（）、ARPSendStPacket（）、ICMPProcPktIn（）、UDPAppInit（）、IPGenCheckSum（）、、UDPAppProcPktIn（）、UDPStartPktOut（）和UDPEndPktOut（）等。所使用的變量有：remoteIP[3:0]、myIP[3:0]、UDPRxSrcPortMSB、UDPRxSrcPortLSB、UDPRxDataLenMSB、UDPRxDataLenLSB、UDPTxSrcPortMSB,UDPTxSrcPortLSB、UDPTxDestPortMSB、UDPTxDestPortLSB、DPTxDataLenMSB, UDPTxDataLenLSB等。

系統(tǒng)首次執(zhí)行或復位時，以太網控制器協(xié)議轉換模塊將首先調用NICInit()和UDPAppInit()等進行NIC、ARP、IP、UDP和應用程序的初始化。初始化完成后，即進入主循環(huán)。在主循環(huán)中，SX52將反復檢測RTL8019AS是否接收以太網幀。當有數(shù)據(jù)被接收時，SX52調用NICDMAInit()和NICReadAgain()讀入以太網幀首部?再調用ARPCheckIfIs()判斷接收幀是否為ARP數(shù)據(jù)。若是ARP，則轉入ARPSendResponse()和ARPSendStPacket()子程序進行ARP處理并發(fā)送響應ARP數(shù)據(jù)報；若不是ARP，則判斷是否為IP數(shù)據(jù)報。若非IP數(shù)據(jù)報則清除該以太網幀；當所接收幀包含IP數(shù)據(jù)報時，則需進一步判斷是ICMP數(shù)據(jù)報還是UDP數(shù)據(jù)報文。若是ICMP數(shù)據(jù)報則執(zhí)行ICMPProcPktIn()子程序處理ICMP數(shù)據(jù)報并重發(fā)IP數(shù)據(jù)報；若數(shù)據(jù)為UDP數(shù)據(jù)報文，則調用UDPProcPktIn()子程序。該程序將讀入UDP數(shù)據(jù)報文首部的數(shù)據(jù)并進行相應處理，還原出完整的CAN協(xié)議數(shù)據(jù)報文存入數(shù)據(jù)緩沖區(qū)B中，再通知總調度程序，由總調度程序調用CAN總線控制子程序將CAN協(xié)議數(shù)據(jù)報文發(fā)往CAN總線。

反過來，當總調度程序通知以太網控制器協(xié)議轉換模塊將數(shù)據(jù)緩沖區(qū)B中準備好的CAN協(xié)議數(shù)據(jù)發(fā)送到以太網上時，它將調用NICInitTxFrame()、UDPStartPktOut()、IPGenCheckSum()、IPStartPktOut()、NICSendTxFrame()、UDPEndPktOut()等子函數(shù)進行發(fā)送處理，從而實現(xiàn)CAN總線到以太網的數(shù)據(jù)傳輸。

3．2 以太網層應用程序設計

以太網上的通信協(xié)議一般采用TCP／IP協(xié)議。本文采用流行的SOCKET套接字編程，傳輸層協(xié)議選擇UDP（用戶數(shù)據(jù)報協(xié)議），通過Visual C＋＋編寫用戶層程序。

篇9

關于網絡工程實習自我鑒定

四個星期的實習在轉眼中已經過去，回想當初剛剛開始進入實習的時候，腦子里是充滿著疑惑與好奇。好奇這次名為網絡工程實習的過程中，我們要開展什么樣的學習。而今在不知不覺中實習已進入了尾聲。

在這次實習中，我們從開始的時候只有淺顯的網絡理論知識，轉變?yōu)楦私飧鞣N網絡器件，在虛擬機的安裝與配置中，掌握了各種服務器的安裝與配置，在路由器的配置中，掌握了路由器的基本配置命令以及路由器的各個模式。我們還學習了Vlan的劃分、動態(tài)路由的配置、交換機的配置、VPN的配置等等。實驗中構建拓撲圖，對各個實驗器件進行地址規(guī)劃和基礎配置這是每個實驗都必須進行的。如果這兩步做不好，就無法連通各個器件，它們之間是無法進行通信的。無法進行通信，也就意味著后面的各種配置都無法再進行下去。所以構建網絡拓撲和進行地址規(guī)劃使網絡連通是進行實驗的基礎。在第十四個實驗之前的實驗，對路由器的配置時應該在哪種模式下進行，指導書里都是給出的;然而，在第十四個實驗之后，路由器的模式就沒有給出了，這是對我們的要求的一個提升，要求我們更熟悉對路由器的配置模式以及配置命令才能完成實驗。

在第十三個實驗 無線網絡設計及配置中第一次用到Serial接口 ，這與之前常用的FastEthernet接口有區(qū)別，在實驗中其中一個路有設置了clock rate，而另外一個沒有設置，或設置里不一樣的參數(shù)，導致兩個路由器無法通信，后來在同學的指導下找出了問題所在，從而解決了問題。在DHCP中繼實驗中，由于不了解DHCP中繼的具體實現(xiàn)過程以及沒有弄明白地址池的配置所以遇到了麻煩，連接好網絡并連通后無法自動獲取IP地址雖然在同學的協(xié)助下完成了實驗，但是始終沒有很清晰的實驗思路。

實習中所涉及的內容都是比較接近實際的，很有實際意義，特別是VPN的設計及配置部分，對認識現(xiàn)在的網絡構建都是有重大的指導意義的，它將我們之前學的理論知識與實際聯(lián)系起來。加強了我們對知識的運用的能力。

在實驗中除了學會了安裝虛擬機以為，還掌握了思科的仿真軟件的實驗，雖然是用仿真軟件，并沒有接觸到實物，但是軟件的高仿真性讓我們對實驗充滿著樂趣。實習中對各種網絡協(xié)議的內容都需要我們去了解、而老師給出的指導書里面，有些知識并不是很詳細，這就培養(yǎng)了我們自己查看資料的能力。

通過這次實習，使我對網絡知識的興趣有了更大的提升，這對我以后的學習中也是至關重要的。

網絡工程實習自我鑒定閱讀

我實習的單位是學院，這是一所由市教委、(集團)公司與德國基金會合作的一所探索、實踐德國“雙元制”職業(yè)教育模式的全日制中等專業(yè)學校。我在學校里主要是負責校園內網的管理，其涉及到校園網網站的正常登陸和訪問，校園內各系部主機是否正常互聯(lián)，有無被病毒感染、傳播。使得校園網內的計算機能夠正常運行，做好校園網的管理和維護工作。

從學生到實習工程師，短短幾個月的工作過程使我受益匪淺。 不僅是在專業(yè)知識方面，最主要是在為人處事方面。社會在加速度地發(fā)生變化，對人才的要求也越來越高，要用發(fā)展的眼光看問題，得不斷提高思想認識，完善自己。作為一名it從業(yè)者，所受的社會壓力將比其他行業(yè)更加沉重，要學會創(chuàng)新求變，以適應社會的需要。在單位里，小到計算機的組裝維修，大到服務器的維護與測試，都需要一個人獨立完成。可以說，近3個月的工作使我成長了不少，從中有不少感悟，下面就是我的一點心得：

第一是要真誠：你可以偽裝你的面孔你的心，但絕不可以忽略真誠的力量。 第一天去網絡中心實習，心里不可避免的有些疑惑：不知道老師怎么樣，應該去怎么做啊，要去干些什么呢等等吧!踏進辦公室，只見幾個陌生的臉孔。我微笑著和他們打招呼。從那天起，我養(yǎng)成了一個習慣，每天早上見到他們都要微笑的說聲：“老師早”，那是我心底真誠的問候。我總覺得，經常有一些細微的東西容易被我們忽略，比如輕輕的一聲問候，但它卻表達了對老師同事對朋友的尊重關心，也讓他人感覺到被重視與被關心。僅僅幾天的時間，我就和老師們打成一片，很好的跟他們交流溝通學習，我想，應該是我的真誠，換得了老師的信任。他們把我當朋友也愿意指導我，愿意分配給我任務。

第二是溝通：要想在短暫的實習時間內，盡可能多的學一些東西，這就需要跟老師有很好的溝通，加深彼此的了解 ，剛到網絡中心，老師并不了解你的工作學習能力，不清楚你會做那些工作，不清楚你想了解的知識，所以跟老師很好的溝通是很必要的。同時我覺得這也是我們將來走上社會的一把不可缺少的鑰匙。通過溝通了解，老師我我有了大體了解，邊有針對性的教我一些知識，我對網絡部線，電腦硬件安裝，網絡故障排除，工作原理應用比叫感興趣，所以老師就讓我獨立的完成校內大小部門的網絡檢修與電腦故障排除工作。

如秘書處的辦公室內局域網的組件，中心服務機房的服務器監(jiān)測等，直接或間接保證了校園網的正常運行和使用，在這方面的工作中，真正學到了計算機教科書上所沒有或者真正用到了課本上的知識，鞏固了舊知識，掌握了新知識，甚至在實踐中****了書本上舊有的不合實際的知識，這才真正體現(xiàn)了知識的真正價值，學以致用。

第三是激情與耐心： 激情與耐心，就像火與冰，看似兩種完全不同的東西，卻能碰撞出最美麗的火花。在中心時，老師就跟我說，想做電腦網絡這一塊，激情與耐心必不可少，在產品更新方面，這一行業(yè)就像做新聞工作，補斷的更新，這就需要你有激情，耐心的去不斷的學習提高自己的專業(yè)水平。在一些具體的工作當中也是這樣的：記得剛來學校實習的時候老師安排我去綜合部安裝win98操作系統(tǒng)，我本想對我來說是非常簡單的事，可沒想到出現(xiàn)了很多問題，開始是硬件問題：光驅不能用使我在一開始安裝系統(tǒng)時就出現(xiàn)了急躁的情緒，然后順利解決后，98系統(tǒng)的驅動問題又讓我大傷腦筋!

從一開始的u驅動慢慢的安裝，再通過硬件監(jiān)測軟件查看硬件型號， 到最后把系統(tǒng)安裝成功，用了整整兩天的時間，通過自己的捉摸，調試，自此，我算是真正的搞明白的計算機的硬件安裝，維護和更新，接著我又進行了各種計算機操作系統(tǒng)的反復安裝調試，一遍又一遍的調試安裝，自然有些煩，但我用我的熱情耐心克服這些困難，問老師，查資料，一個個問題迎刃而解，自己在這方面的知識得到了充實。這些在平常的書本上僅僅是獲得感性的認識在這里真的實踐了，才算是真正的掌握了，也讓我認識到了自己的不足，告誡自己，不管做什么，切忌眼高手低，要善于鉆研。

還有我感觸比較深的就是查看log日志記錄，因為服務器的維護是復雜又艱辛的，既要保障物理安全又要保證系統(tǒng)安全，這就需要通過查詢log日志記錄，每一分鐘的服務器狀況都有l(wèi)og日志記錄，而且它一是數(shù)據(jù)量大、二是有大量無用信息，所以查看log使非常“痛苦”的事情。像這些工作我深深地感覺到沒有激情與耐心是做不好的。

網絡工程實習個人自我鑒定

一、實習的基本概況

時間：20xx年x月x日—20xx年x月x日

地點：E607

(一)理論指導

1、 IEEE802標準和以太網：

㈠ OSI模型和TCP/IP協(xié)議：OSI模型中包括物理層、數(shù)據(jù)鏈路層、網絡層、傳輸層、會話層、表示層、應用層。㈡ IEEE802參考模型：物理層被分為上下兩個子層：對電纜介質的說明;介質訪問單元(MAU)。數(shù)據(jù)鏈路層也被分為兩個子層：媒體訪問控制子層(MAC);邏輯鏈路控制子層(LLC)。㈢ 以太網簡介：①以太網的物理地址可分為三類：單播地址、廣播地址和多播地址。② 以太網訪問模式：CSMA/CD③ 以太網的MAC幀格式：一種是DIX Ethernet V2標準，另一種是IEEE的802.3標準。兩種幀格式可以在同一以太網絡共存。兩種幀格式都具有7個域：前導碼、幀首定界符、目的MAC地址、源MAC地址、協(xié)議類型或數(shù)據(jù)長度、數(shù)據(jù)、幀校驗序列。

2、地址解析協(xié)議(ARP)

㈠ 物理地址與邏輯地址 ㈡ ARP協(xié)議簡介 ㈢ ARP報文格式 ㈣ ARP封裝 ㈤ ARP的運行過程 ㈥ ARP高速緩存 ㈦ ARP ㈧ 協(xié)議棧實現(xiàn)代碼解析 ㈨ 各模塊推薦流程：(1) ARP請求發(fā)送流程(2)輸入ARP數(shù)據(jù)包處理流程

3、網絡協(xié)議(IP)

㈠ IP協(xié)議簡介

㈡ ①IP地址：地址空間 。

②IP地址的表示方法 ：IP地址有三種常用的表示方法：二進制表示方法、點分十進制表示方法和十六進制表示方法。

③IP地址的分類： IP地址分成5類：A類，B類，C類，D類和E類。其中A類、B類和C類地址是基本的Internet地址，是用戶使用的地址，D類地址用于廣播，E類地址為保留地址。

④網絡號和主機 ：在分類編址的A類，B類和C類地址中，IP地址可劃分為網絡號(net-id)和主機號(host-id)。這兩部分長度都是可變的，取決于地址的類型。

⑤地址類和地址塊：A類地址共分為128個地址塊，每個地址塊都包含有16777216個地址。這表明要使用這類地址的機構一定是一個非常龐大的機構。B類地址共劃分為16384個地址塊，每個地址塊都包含有65536個地址。 C類地址共劃分為2097152個地址塊，每個地址塊都包含有256個地址。D類地址只有一個地址塊。它用來進行多播。E類地址只有一個地址塊。它是保留地址。

㈢ 特殊的IP地址：1) 網絡地址：主機號為全“0”的IP地址不分配給任何主機，而是作為網絡本身的標識。

2) 直接廣播地址：主機號為全“1”的IP地址不分配給任何主機，用作廣播地址。

3) 有限廣播地址：32位為全“1”的IP地址(255.255.255.255)稱為有限廣播地址。

4) 主機本身地址：32位全“0”的IP地址(0.0.0.0)稱為主機本身地址。

5) 回環(huán)地址：127.0.0.1稱為回環(huán)地址，常用于本機上軟件測試和本機上網絡應用程序之間的通信地址。

㈣子網劃分

㈤IP報文格式

㈥IP封裝

㈦IP數(shù)據(jù)報分片

㈧IP數(shù)據(jù)報校驗和

4、用戶數(shù)據(jù)報協(xié)議(UDP)

UDP協(xié)議簡介：UDP(用戶數(shù)據(jù)報協(xié)議)，主要用來支持那些需要在計算機之間傳輸數(shù)據(jù)的網絡應用。包括網絡視頻會議系統(tǒng)在內的眾多的客戶/服務器模式的網絡應用都需要使用UDP協(xié)議。UDP報文格式：每個UDP報文稱為一個用戶數(shù)據(jù)報(User Datagram)，用戶數(shù)據(jù)報分為兩個部分：UDP首部和UDP數(shù)據(jù)。首部被分為四個16位的字段，分別代表源端口號﹑目的端口號﹑報文的長度以及UDP校驗和。

UDP應用：1)UDP適用于這樣的進程，它需要簡單的請求——響應通信，而較少考慮流量控制和差錯控制。對于需要傳送成塊數(shù)據(jù)的進程，如FTP，則通常不使用UD;2)UDP適用于具有內部流量控制和差錯控制機制的進程;3)對多播和廣播來說，UDP是個比較合適的傳輸層協(xié)議;;4)UDP可用于管理進程，如SNMP協(xié)議;5)UDP可用于某些路由選擇更新協(xié)議。

5、傳輸控制協(xié)議(TCP)

TCP(傳輸控制協(xié)議)協(xié)議是TCP/IP協(xié)議族中的面向連接的、可靠的傳輸層協(xié)議。

6、域名服務(DNS)

DNS(域名服務)是一種能夠完成從域名到地址或從地址到域名的映射系統(tǒng)。使用DNS，計算機用戶可以間接的通過域名來完成通信。

7、超文本傳輸協(xié)議(HTTP)

HTTP(超文本傳輸協(xié)議)主要用于訪問萬維網上的數(shù)據(jù)。HTTP在熟知端口80上使用TCP服務。

8、遠程登錄與文件傳輸協(xié)議(TELNET與FTP )

FTP(文件傳輸協(xié)議)提供了一種通過TCP傳送文件的方法，可以將一個文件從一個系統(tǒng)復制到另一個系統(tǒng)中。

(二)實習過程或步驟

1、領略真實的MAC幀：

將主機A和B作為一組，主機B啟動協(xié)議分析器，新建捕獲窗口進行數(shù)據(jù)捕獲并設置過濾條件(提取ICMP協(xié)議);主機A ping 主機B，察看主機B協(xié)議

分析器捕獲的數(shù)據(jù)包，分析MAC幀格式。然后將主機B的過濾器恢復為默認狀態(tài)。實驗結果為: MAC幀格式：

其中目的MAC地址：00142A—503336 ;源MAC地址：00142A—522C15;型或數(shù)據(jù)長度：0800

2、ARP報文

將主機A、B、C、D、E、F作為一組進行實驗。

①主機B在命令行方式下輸入staticroute_config命令，開啟靜態(tài)路由服務。

②主機A、B、C、D、E、F在命令行下運行“arp -d”命令，清空ARP高速緩存。

③機A、B、C、D、E、F重新啟動協(xié)議分析器，打開捕獲窗口進行數(shù)據(jù)捕獲并設置過濾條件(提取ARP、ICMP)。

④主機A ping 主機E(172.16.0.2)。

⑤主機A、B、C、D、E、F停止數(shù)據(jù)捕獲，察看協(xié)議分析器中采集到的ARP報文。通過實驗了解到：單一ARP請求報文不能跨越子網進行地址解析，ARP報文的存活空間只限在子網內。因為ARP報文的請求是在網關下的數(shù)據(jù)請求，脫離子網ARP報文也就自動失效，并且ARP請求是以廣播的方式進行，而廣播報文不能跨越子網。ARP地址解析在跨越子網的通信中所起到的作用：作用是解析網關的MAC地址，ARP本身無法跨躍不同網段。當數(shù)據(jù)要發(fā)往外部網絡時，通常是首先使用ARP請求網關路由器的MAC地址，之后將數(shù)據(jù)發(fā)往網關路由器，由網關路由器進行轉發(fā)。

3、編輯并發(fā)送IP數(shù)據(jù)報：

將主機A、B、C、D、E、F作為一組進行實驗。

①主機B在命令行方式下輸入staticroute_config命令，開啟靜態(tài)路由服務。

②主機A啟動協(xié)議編輯器，編輯一個IP數(shù)據(jù)報，其中：MAC層：目的MAC地址：主機B的MAC地址(對應于172.16.1.1接口的MAC) 源MAC地址：主機A的MAC地址。協(xié)議類型或數(shù)據(jù)長度：0800。IP層：總長度：IP層長度。生存時間：128。源IP地址：主機A的IP地址(172.16.1.2)。目的IP地址：主機E的IP地址(172.16.0.2)。校驗和：在其它所有字段填充完畢后計算并填充。自定義字段：數(shù)據(jù)：填入大于1字節(jié)的用戶數(shù)據(jù)。

③在主機B(兩塊網卡分別打開兩個捕獲窗口)、E上啟動協(xié)議分析器，設置過濾條件(提取IP協(xié)議)，開始捕獲數(shù)據(jù)。

④主機A發(fā)送第1步中編輯好的報文。

⑤主機B、E停止捕獲數(shù)據(jù)，在捕獲到的數(shù)據(jù)中查找主機A所發(fā)送的數(shù)據(jù)報。

⑥將第1步中主機A所編輯的報文的“生存時間”設置為1，重新計算校驗和。

⑦主機B、E重新開始捕獲數(shù)據(jù)。

⑧主機A發(fā)送第5步中編輯好的報文。

⑨主機B、E停止捕獲數(shù)據(jù)，在捕獲到的數(shù)據(jù)中查找主機A所發(fā)送的數(shù)據(jù)報。觀察實驗過程得：在實驗過程中主機A所編輯的報文，經過主機B到達主機E后，報文數(shù)據(jù)發(fā)生變化，變化的原因是：他們不在一個子網上。主機B能接受到A發(fā)送的報文，主機E不能，因為此報文的生存時間太短，致使主機E無法捕獲此報文。

4、UDP單播通信

將主機A、B、C、D、E、F作為一組進行實驗。

①主機B、C、D、E、F上啟動“實驗平臺工具欄中的UDP工具”，作為服務器端，監(jiān)聽端口設置為2483，“創(chuàng)建”成功。

②主機C、E上啟動協(xié)議分析器開始捕獲數(shù)據(jù)，并設置過濾條件(提取UDP協(xié)議)。

③主機A上啟動“實驗平臺工具欄中的UDP工具”，作為客戶端，以主機C的IP為目的IP地址，以2483為端口，填寫數(shù)據(jù)并發(fā)送。

④察看主機B、C、D、E、F上的“UDP工具”接收的信息。

⑤察看主機C協(xié)議分析器上的UDP報文

⑥主機A上使用協(xié)議編輯器向主機E發(fā)送UDP報文，其中： 目的MAC地址：E的MAC地址;目的IP地址：主機E的IP地址;目的端口：2483;校驗和：0發(fā)送此報文 ⑦主機B、C、D、E、F關閉服務端，主機A關閉客戶端。從實驗中得出結論：UDP是一個無連接協(xié)議，傳輸數(shù)據(jù)之前源端和終端不建立連接，當它想傳送時就簡單地去抓取來自應用程序的數(shù)據(jù)，并盡可能快地把它扔到網絡上。在發(fā)送端，UDP傳送數(shù)據(jù)的速度僅僅是受應用程序生成數(shù)據(jù)的速度、計算機的能力和傳輸帶寬的限制;在接收端，UDP把每個消息段放在隊列中，應用程序每次從隊列中讀一個消息段。

(2) 由于傳輸數(shù)據(jù)不建立連接，因此也就不需要維護連接狀態(tài)，包括收發(fā)狀態(tài)等，因此一臺服務機可同時向多個客戶機傳輸相同的消息。

5、頁面訪問

①將主機A和B作為一組

② 主機A清空IE緩存。

③主機B啟動協(xié)議分析器開始捕獲數(shù)據(jù)，并設置過濾條件(提取HTTP協(xié)議)。

④主機A啟動IE瀏覽器，在“地址”框中輸入服務器的ip/experiment，并連接，服務器IP默認為172.16.0.253。主機B停止捕獲數(shù)據(jù)，分析捕獲到的數(shù)據(jù)。分析實驗可知，實驗中使用http的get方法 (從服務器請求一個文檔)。作用：請求獲取Request-URI所標識的資源。

6、使用TCP連接工具與服務器進行命令交互

將主機A和B作為一組;1、主機B啟動協(xié)議分析器開始捕獲數(shù)據(jù)并設置過濾條件(提取TCP協(xié)議)。2、主機A啟動TCP工具連接FTP服務器。

(1)主機A啟動“實驗平臺工具欄中的TCP工具”。①選中“客戶端”單選框。②在“地址”文本框中填入FTP服務器的IP地址。③在“端口”文本框中填入主機FTP服務器進程的端口號21。④點擊“連接”按鈕，建立與FTP服務器的TCP連接。

(2)連接成功(將該次連接記為w_cmd)，在接收窗口會顯示成功連接的信息。然后在發(fā)送窗口發(fā)送數(shù)據(jù)，觀察服務器回復的信息。由實驗總結出FTP服務器是使用什么方式創(chuàng)建數(shù)據(jù)連接的。

二、實習感受

(一)成績與收獲

經過為期幾周的網絡工程實習我對IPV4協(xié)議中的各個協(xié)議有了更深入的了解。在實驗一中掌握了什么是IEEE802標準和以太網、太網的報文格式;掌握MAC地址的作用;MAC廣播地址的作用;LLC幀報文格式;協(xié)議編輯器和協(xié)議分析器的使用方法;協(xié)議棧發(fā)送和接收以太網數(shù)據(jù)幀的過程。通過動手實驗捕獲數(shù)據(jù)包分析出MAC幀格式。同時學會了編寫LLC幀，更加明白LLC幀是由目的MAC地址、源MAC地址、協(xié)議類型和數(shù)據(jù)長度、用戶定義數(shù)據(jù)/數(shù)據(jù)字段等組成。在實驗三中熟練掌握了IP校驗和計算方法，可手動計算也可使用協(xié)議編輯器的“自動計算”校驗和。

同時還懂得受限廣播地址的作用：受限的廣播地址是255.255.255.255。該地址用于主機配置過程中IP數(shù)據(jù)報的目的地址，此時，主機可能還不知道它所在網絡的網絡掩碼，甚至連它的IP地址也不知道。在任何情況下，路由器都不轉發(fā)目的地址為受限的廣播地址的數(shù)據(jù)報，這樣的數(shù)據(jù)報僅出現(xiàn)在本地網絡中。最重要的是，在學習的過程中組內成員互相幫助，遇到困難大家共同解決，真正認識到團結協(xié)作精神的重要，同時我們積極利用網絡搜集大量資料并從中摘取與自己課題相關的內容，這樣在研究過程中又增加了不少課外知識，對大一學過的網絡原理是個很好的復習和回顧。另外，通過實習我發(fā)現(xiàn)自己目前掌握的東西還是少，在今后的學習中要不斷學習不斷總結，必須拓寬自己的知識面、開闊自己的視野。

(二)問題與不足

篇10

關鍵字 TCP/IP；教學平臺；數(shù)據(jù)包截獲；包過濾；協(xié)議分析

1 引言

TCP/IP協(xié)議族是計算機網絡軟件組成的核心部分，同時也是很抽象和難以掌握的部分。目前，對于TCP/IP協(xié)議族的研究，一般是基于協(xié)議應用本身的研究，也就是研究如何將指定的協(xié)議嵌入產品，使該產品能夠支持上層產品應用該協(xié)議或自身產品對該協(xié)議的應用。作為高校計算機網絡課程中所介紹的協(xié)議，對于很大一部分老師和同學來講，都還只是停留在了解和使用這個協(xié)議上，并沒有深入到協(xié)議本身的原理中去。

本系統(tǒng)通過對TCP/IP協(xié)議族的研究，將其中的部分常用協(xié)議（如TCP、IP、UDP等）的具體結構、工作方式和工作過程，用人機交互方式和圖形化界面形象生動展現(xiàn)在學生面前。教學中通過對本套系統(tǒng)的利用，可以達到提高學習效率，改善學習效果，使學生對協(xié)議的學習不僅達到對使用方法的了解，同時達到對協(xié)議結構以及工作原理的領悟，使學生對網絡課程的學習達到一個新的層次。

2 系統(tǒng)設計依據(jù)

2.1 設計思路及設計目的

本系統(tǒng)開發(fā)的目的是針對大學本科學生對《計算機網絡》課程中關于網絡傳輸以及協(xié)議原理部分的學習，使學生可以自己定制傳輸內容，并親眼看到所有內容傳輸?shù)倪^程形式等，增強對協(xié)議結構的記憶，并可以親自動手控制協(xié)議的狀態(tài)，達到對協(xié)議原理及工作方式的深入了解。

2.2 系統(tǒng)設計中所用到的原理

2.2.1 數(shù)據(jù)傳輸?shù)脑?/p>

在基于TCP/IP的網絡中，應用層的數(shù)據(jù)傳輸通常是基于TCP或者UDP協(xié)議的，而兩種協(xié)議最大的區(qū)別在于是否面向連接。

在面向連接的TCP協(xié)議中，傳輸數(shù)據(jù)首先要求傳輸雙方建立一條虛電路連接。通信雙方通過自身的sockets（或稱為通訊端點） 建立sockets的連接，從而達到傳輸?shù)哪康摹?/p>

UDP是一種是無連接的用戶數(shù)據(jù)報傳輸協(xié)議，與TCP操作不同，計算機間并不需要建立一個明確、可靠的鏈路，一個UDP應用可同時作為客戶方或服務器方。UDP向應用程序提供了一種發(fā)送封裝的原始IP數(shù)據(jù)包的方法。雖然UDP數(shù)據(jù)報只能提供不可靠的交付，但在許多方面UDP可以簡化連接，這樣可以避免建立和釋放連接的麻煩。

2.2.2 網絡包截獲的原理

通常在同一個網段的所有網絡接口都有訪問在物理媒體上傳輸?shù)乃袛?shù)據(jù)的能力，而每個網絡接口都還應該有一個硬件地址，該硬件地址不同于網絡中存在的其他網絡接口的硬件地址，同時，每個網絡至少還要一個廣播地址（代表所有的接口地址），在正常情況下，一個合法的網絡接口應該只響應這樣的兩種數(shù)據(jù)幀：

（1）幀的目標區(qū)域具有和本地網絡接口相匹配的硬件地址。

（2）幀的目標區(qū)域具有"廣播地址"。

在接受到上面兩種情況的數(shù)據(jù)包時，網卡通過CPU產生一個硬件中斷，該中斷能引起操作系統(tǒng)注意，然后將幀中所包含的數(shù)據(jù)傳送給系統(tǒng)進一步處理。

本系統(tǒng)中對數(shù)據(jù)幀的截獲就是利用將本地網卡模式設成混雜（promiscuous）狀態(tài)的機制，混雜模式就是接收所有經過網卡的數(shù)據(jù)包，包括不是發(fā)給本機的包。當網卡處于這種"混雜"方式時，使網卡對所有遭遇到的每一個幀都產生一個硬件中斷以便提醒操作系統(tǒng)處理流經該物理媒體上的每一個報文包。

2.2.3 協(xié)議狀態(tài)跳轉的原理