udp协议范文

导语：如何才能写好一篇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.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.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 协议状态跳转的原理

篇1

篇2

篇3

篇4

篇5

篇6

篇7

篇8

篇9

篇10

热门标签

精品范文