udp協議范文

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

篇1

關鍵詞:用戶數據報協議;通信;報文分析;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體系結構中一種無連接的傳輸層協議,提供面向事務的簡單不可靠信息傳送服務。UDP 協議是 IP 協議與上層協議的接口,用端口號分別為運行在同一設備上的多個應用程序提供服務。它定義在IETF RFC 768中[1]。

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

1 UDP協議使用

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

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

#include //基本輸入輸出庫

#include //網絡API函數庫

#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主機字節序變為網絡字節序*/

addrSrv.sin_family=AF_INET;

addrSrv.sin_port=htons(6666);

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

if ( err != 0 ) {

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

} 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); //格式化

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函數的使用。

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

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");/*設置目標地址,根據服務器端情況*/

addrSrv.sin_family=AF_INET;

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

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

char sendBuff[200];//發送緩存

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);//發送

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地址,只要按照程序注釋,根據實際情況更改客戶程序的addrSrv.sin_addr.S_un.S_addr變量即可。

2 報文捕獲與分析

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

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

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

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

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

3 結束語

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

參考文獻:

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

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

篇2

關鍵詞：arm；linux；交叉編譯環境；udp協議；重發機制；重發次數

中圖分類號：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協議以其高效性和應用的簡單，被廣泛運用于嵌入式網絡開發中。由于udp協議的應用簡單，在嵌入式設備開發過程中，網絡資源的利用率并不高。以下將介紹一個udp具體項目實驗過程，描述arm-linux環境的軟硬件環境構建過程，并對udp協議下一種重發模式中上位機的重發次數的確定提出一種可行的方法。

1 研究背景

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

2 硬件平臺介紹

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

2.1 et-s3c2440開發板簡介

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

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

2.2 實驗相關電路說明

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

3 系統軟件平臺的構建

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

3.1 交叉編譯環境的構建

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

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

3.2 bootloader的移植

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

3.3 linux內核移植

獲取linux-2.6.29.1源代碼并解壓后，首先修改內核源代碼所在目錄中的makefile，將系統架構修改為arm(arch ?=arm ),交叉編譯工具修改為arm-linux-gcc (cross_compile ?=arm-linux-)，修改輸入時鐘(arch/arm/mach-s3c2440/mach-smdk2440.c中的函數static void __init smdk2440_map_io中，修改s3c24xx_init_clocks(12000000)此處所用晶振為12m)。修改machine名稱(在arch/arm/mach-s3c2440/mach-smdk2440.c文件中的函數machine_start( ),修改為machine_start(s3c2440, “自定義機器名”)，修改nandflash分區信息(arch/arm/plat-s3c24xx/common-smdk.c結構體static struct mtd_partition smdk_default_nand_part[]中保存的是nandflah的分區信息，將其修改為當前使用的分區信息),然后修改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)，將函數中的gpio口配置為gpg4)。關于cs8900a網卡的驅動移植，相關資源很豐富，本文也不再贅述。

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

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

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

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

3.4 根文件系統的制作

根文件系統是使用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的內容。

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

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

4 arm-linux環境下的udp協議通信實驗

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

4.1 udp協議套接字編程基礎

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

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

4.2 上位機報文結構及重發機制分析

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

表1 上位機報文結構

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

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

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

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

4.4 對上位機重發次數的研究

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

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

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

當報文重發次數為3,依然在每條報文的重發機制位注明索引號和重發號，發送報文的次序應為1.1 ,1.2 ,1.3 ,2.1 ,2.2 ,2.3 ,3.1 ,3.2……。只有出現連續3次丟失數據報的情況報文關鍵信息才可能丟失，列出連續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。

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

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

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

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

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

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

5 結論與展望

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

參考文獻：

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

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

篇3

0引言

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

 

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

 

篇4

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

引言

由于傳統的數據傳輸協議所針對的業務不同，在數據傳輸的速度和可靠性之間不能達到很好的平衡。車險理賠系統中采用的是移動理賠的思想，手持終端機通過移動通信網絡和后臺中心系統進行數據交互。目前國內的通信事業并不是很發達，信號覆蓋率并不全面，移動通信網絡的帶寬和傳輸質量會受到地域的影響，為確保理賠現場與后臺系統間數據的及時可靠傳輸，需要基于移動通信的網絡環境設計高效可靠的數據傳輸功能。本章在UDP傳輸協議基礎上，通過應用層封裝和可靠性設計的方法，采用數據包的確認重傳、流量控制等機制，設計并實現基于UDP協議的可靠數據傳輸功能。

1.TCP與UDP的對比

TCP和UDP都屬于傳輸層協議，負責承擔數據傳輸的任務[1]。兩者之間的主要區別有：

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

（2）UDP協議的數據傳輸不需要維護收發狀態和連接狀態等，與TCP相比，網絡有效利用率得到很大的提高。

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

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

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

2.1 可靠UDP傳輸協議的層次結構

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

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

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

（2）數據重傳功能。發送方收到接收方發來的重發請求，將需要重發的數據包發出。

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

（4）流量控制功能。

圖1 協議層次結構圖

2.2 可靠UDP傳輸協議報文結構

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

MessageType（消息類型）用于識別數據包類型，包括數據傳輸請求消息、數據包發送消息、數據包確認消息等，占用兩個字節空間。

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

MessageNumber （消息傳輸序號）用于標識當前發送的數據包在整個消息中的位置，占用四個字節空間。

圖2 改進協議報文結構

2.3 可靠傳輸內部機制

2.3.1 三次握手機制

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

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

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

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

圖3 簡單的3次握手

2.3.2 數據包確認機制

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

if（數據包時間確認計時器到時）

{

接收方給發送方發送ACK包 AND

數據包時間確認定時器歸零 AND

數據包接收計數器歸零;

}

else if （數據包接收計數器達到預定值）

{

接收方給發送方發送ACK包 AND

數據包時間確認定時器歸零 AND

數據包接收計數器歸零;

}

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

2.3.3 流量控制機制

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

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

3.總結

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

參考文獻

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

篇5

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

關鍵詞 嵌入式系統；RCM2200；UDP報文；串口通信

1 引言

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

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

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

2 系統原理及功能

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

入式系統的快速開發，并可實現集成的以太網連接。

RCM2200系統的基本框架結構如圖1所示。

圖1 RCM2200系統結構

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

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

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

在該開發系統中將RCM2200的以太網接口與當地局域網相連，選擇一個串口與計算機的串口相連。由以太網發送UDP報文給RCM2200微控制器核心模塊經過處理后通過串口發送給計算機，由計算機串口發送數據給RCM2200微控制器核心模塊經過處理后通過其上的網絡口發送UDP報文給以太網，從而實現基于RCM2200以太網和串口之間的通信。

3 UDP協議的實現

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

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

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

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

3.2 數據報套接字

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

UDP協議支持數據報套接字。這種套接字可以采用客戶/服務器模式，以全雙工方式工作，接收發送可以同時進行，但并不保證數據傳輸的可靠性、有序性和無重復性，需要由程序員負責管理數據報的排序和可靠性。

3.3 使用Dynamic C實現UDP報文的傳輸

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

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

3.3.1 調用本地初始化函數

void sock_init(void)

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

3.3.2 打開數據報套接字

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

其中的參數解釋如下：

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

lport : 本地協議端口；

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

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

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

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

3.3.3 接收遠地主機發送的數據報

int udp_recv( *s， *buf_recv， recv_len)

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

buf_recv : 指向用于存放已到達數據報的數組的指針；

recv_len : 存放數據報的數組的大小。

如果接收到數據報則返回數據報的長度；否則返回-1。

3.3.4 發送數據報給遠地主機

int udp_send( *s， *buf_send， send_len )

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

buf_send : 指向待發送數據報的指針；

send_len : 待發送數據報的長度。

3.3.5 網絡信息處理函

int tcp_tick( *s )

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

3.3.6 關閉套接字

void sock_close( *s )

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

4

串口通信的實現

4.1 RS232電平與TTL電平的轉換

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

圖2 RS232與TTL電平轉換圖

4.2 使用Dynamic C實現串口數據的傳輸

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

4.2.1 打開串行接口

int serXopen( bard )

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

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

4.2.2 讀取PC機串行口數據

int serXgetc()

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

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

4.2.3 發送數據到PC機串行口

int serXputs( *s )

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

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

s : 待發送字符串的首地址；

length : 待發送字符串的長度。

4.2.4 關閉串行口

void serXclose()

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

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

5

實現以太網與串口之間的通信

5.1

定義網絡以及串口初始化數據

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

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

5.2 主程序

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

main()

{

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

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

for(;;;)

{

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

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

comm_init();//串口發數據網絡接收

}

}

5.3網絡發報文串口接收

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

5.4串口發字符串網絡接收

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

5.5程序調試結果

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

結論

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

RCM2200使用Dynamic C軟件開發環境，支持C語言、匯編語言，擁有豐富的庫函數可供用戶調用，并具有單步編譯、斷點設置、單步執行、代碼分解、監視表達式等優秀性能。

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

參考文獻

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

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

1999年

篇6

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

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

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

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

二、 應急多媒體通信流媒體協議的選用

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

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

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

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

三、ARM/DSP雙核嵌入式系統

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

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

參 考 文 獻

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

篇7

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

中圖分類號：TP393.03

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

1 穿透NAT的協議

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

1.1 UPNP[7]

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

1.2 STUN [8][9]

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

2 SOCKS4/5協議

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

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

3 NAT穿透SOCKS4/5協議實現

3.1 協議方案

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

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

3.2 建立直接通信

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

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

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

（2）服務器向客戶端關聯器發送服務端管理器的外網地址和端口消息，服務器向服務端關聯器發送客戶端關聯器的外網地址和端口消息。

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

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

3.3 SOCKS4/5數據傳輸

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

如圖3所示：

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

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

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

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

4 實驗測試

4.1 實驗設備

系統硬件：三臺PC，配置：CPU P6 3.40GHz 4GM 內存

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

操作系統軟件：Windows7。

4.2 實驗效果

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

5 結論

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

參考文獻：

[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協議穿透Symmetric NAT方案[J].計算機工程與應用，2007，43（6）.

篇8

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

1 系統結構

系統總體結構分為三部分：現場測控網絡（CAN網絡）、嵌入式透明SX52網關、以太網信息管理終端（如監控平臺和網絡數據庫等），如圖1所示。

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

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

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

2 硬件設計

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

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

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

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

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

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

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

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

3 軟件設計

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

3．1 透明網關協議轉換程序

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

3．1．1 CAN控制器協議模塊

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

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

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

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

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

以太網控制器協議轉換模塊主要由以太網卡驅動、ARP、UDP協議的若干個API函數組成，如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等。

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

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

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

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

篇9

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

一、實習的基本概況

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

地點：E607

(一)理論指導

1、 IEEE802標準和以太網：

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

2、地址解析協議(ARP)

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

3、網絡協議(IP)

㈠ IP協議簡介

㈡ ①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) 回環地址：127.0.0.1稱為回環地址，常用于本機上軟件測試和本機上網絡應用程序之間的通信地址。

㈣子網劃分

㈤IP報文格式

㈥IP封裝

㈦IP數據報分片

㈧IP數據報校驗和

4、用戶數據報協議(UDP)

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

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

5、傳輸控制協議(TCP)

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

6、域名服務(DNS)

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

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

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

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

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

(二)實習過程或步驟

1、領略真實的MAC幀：

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

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

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

2、ARP報文

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

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

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

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

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

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

3、編輯并發送IP數據報：

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

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

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

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

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

⑤主機B、E停止捕獲數據，在捕獲到的數據中查找主機A所發送的數據報。

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

⑦主機B、E重新開始捕獲數據。

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

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

4、UDP單播通信

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

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

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

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

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

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

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

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

5、頁面訪問

①將主機A和B作為一組

② 主機A清空IE緩存。

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

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

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

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

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

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

二、實習感受

(一)成績與收獲

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

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

(二)問題與不足

篇10

關鍵字 TCP/IP；教學平臺；數據包截獲；包過濾；協議分析

1 引言

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

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

2 系統設計依據

2.1 設計思路及設計目的

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

2.2 系統設計中所用到的原理

2.2.1 數據傳輸的原理

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

在面向連接的TCP協議中，傳輸數據首先要求傳輸雙方建立一條虛電路連接。通信雙方通過自身的sockets（或稱為通訊端點） 建立sockets的連接，從而達到傳輸的目的。

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

2.2.2 網絡包截獲的原理

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

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

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

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

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

2.2.3 協議狀態跳轉的原理