udp协议十篇

udp协议篇1

关键词:UDP;RUDP;可靠性

中图分类号:TP393文献标识码:A文章编号:1009-3044(2010)16-4379-02

Reliable Improvement Agreement Based on UDP Agreement

YIN Ran-ran

(School of Computer & Information, Hefei University of Technology, Hefei 230009, China)

Abstract: This article will propose and realizes the embedded equipment's authentic data transmission and one kind of new many through the comparative analysis transmission level transport protocols UDP unreliability and the TCP low efficiency in the UDP agreement's foundation transmits the RUDP agreement wireless. The RUDP agreement software module provides based on the news reliable communication function, the correspondence is faces the connection, the first floor uses UDP to take the load bearing agreement.

Key words: UDP; RUDP; reliability

1 TCP协议和UDP协议

1.1 TCP协议

传输控制协议即TCP,尽管它和UDP都使用相同的网络层协议(IP),但它向应用层提供了与UDP完全不同的服务,它提供一种面向连接的、可靠的字节流服务。面向连接意味着两个使用TCP的应用在彼此交换数据之前必须先建立一个TCP连接,数据传输完成后,再经过4次握手终止双方的连接。在数据传输的过程中,TCP还通过对数据的确认、流量控制等手段提高通信的可靠性。

1.2 UDP协议

UDP(User Datagram Protocol),即用户数据报协议。在TCP/IP网络通信中, UDP协议是一种面向无连接的服务。它发送数据以独立的数据包形式,不保证各数据包的发送顺序,也不进行正确性检查,因此,可能出现数据的重发、丢失、失序等现象[2]。使用UDP协议的常见服务有DNS、QQ等。

UDP协议直接向接收方发送数据而不关心对方计算机的状态,因此,它是一种相对不可靠的通信协议。正因为UDP协议不考虑网络数据传输过程中的很多问题,所以能节省了大量的网络状态确认和数据确认的系统资源消耗,从而提高UDP协议的传输速度和网络的利用效率。可是,如果既能充分利用UDP协议的这些优势,又能保证UDP通信的可靠性,网络通信系统的性能将会得到更大程度地提高。

2 RUDP 协议的提出

2.1 嵌入式设备可靠通信面临的问题

面向连接方式的服务功能明显很强大,它能够发挥面向连接的传输所具备的特性,例如流量控制,差错处理以及顺序交付等等,但是面向无连接的服务更适合于某些情况,在网络层上使用IP协议就是一个面向无连接的服务而且这个面向无连接的服务显得更加健壮,因为Internet本身就是一个不稳定的环境,面向连接的服务反而不能很好的运行于其上。

如果使用TCP连接协议实现嵌入式设备之间的数据传输可能带来许多的问题,嵌入式设备之间建立TCP连接并发送数据后,或者接收端向正在请求连接的设备发出SYN+ACK应答报文后,都可能无法接收到终端的ACK报文,在这种情况下发送端一般会重试并等待一段时间后终止这个连接。大量重传数据会进一步加剧网络的拥塞情况,严重时可以使网络及服务器系统崩溃,同时也会对数据传输的实时性产生影响。同时目前嵌入式设备又存在多点分散、数据量小、实时性要求高等特点[3]。本文将在UDP协议的基础上提出并实现嵌入式设备的可靠数据传输。

2.2 嵌入式可靠传输模型的体系结构

RUDP协议软件模块底层采用UDP作为承载协议,提供基于消息的可靠通信功能。根据计算机网络层次体系的概念,RUDP协议的层次模型就是在原UDP/IP协议的传输层和应用层之间加入了RUDP层和标志层。RUDP协议的层次结构如表1所示。

RUDP层的功能是保证数据的可靠传送。由于嵌入式设备通过网络进行消息的收发是处于一个公共网络的环境之中,可能会有大量无用的数据向嵌入式设备进行发送,大量的数据解析会极大地增加嵌入式设备的负担。为了避免这个问题,我们增加了一个标志层,标志层可以让嵌入式设备迅速的判断所接收的数据包是否为有效数据包,如果标志层数据不可识别,则迅速将包丢弃。在可靠传输层进行可靠传输设计和实现,在这一层,我们增加一系列可靠传输机制以保证嵌入式设备之间数据的可靠传输。这样就形成了一个原UDP协议所在传输层和应用层之间加入了一层为保证可靠数据传送而实现的RUDP软件模块和标志层的六层体系结构。从而,在UDP协议的基础上实现一种基于消息的面向连接的,适合嵌入式设备的可靠数据传递机制。

2.3 嵌入式可靠传输模型的基本功能

嵌入式可靠传输模型RUDP主要功能有:

1) 基于消息的收发功能:RUDP的传输层利用基于消息的传输协议,所以不必考虑发送端可以接收多少数据,只需知道能否接收数据即可。

2) 校验和:RUDP的校验和算法采用UDP的校验功能保证数据包的正确和顺序到达。UDP校验和字段是对整个UDP报文头和UDP所带的数据的校验和。

3) 丢弃重复包和保存失序包的功能:每当收到数据包后,便对数据包进行确认。保存未确认的数据包,丢弃已经确认了的重复包。由于UDP传送过程中,收到的数据包的顺序可能会和发送的顺序有一定的区别,所以保存失序包能够有效的减少重发的次数,也就是能相应的减少网络的数据流量。

4) 超时重发功能:RUDP中借鉴TCP中的超时重发机制来保证数据包的可靠传递;同时TCP中的确认延迟功能也得到借鉴,这样可以显著降低网络的流量,提高嵌入式系统的通信效率。

5) 服务器和客户端保活功能:探测收发两端的连接是否正常时嵌入式可靠传输模型中必须要实现的一个功能。如果连接已经出错,若干数据包仍然发送,当超时定时器到时后就会进行数据的重发。如果没有判断收发两端的连接是否正常,则会导致数据无法正常而又高效的发送。

2.4 RUDP协议工作过程

RUDP协议的工作过程是:首先,建立连接。发送方和接收方通过三次握手的方式建立连接(三次握手过程如图1所示)。第三次握手时,发送方发给接收方的数据帧中除了包含对接收方的确认信息之外,还包含将要发送的数据帧总数。接收方收到确认帧后,开始与发送方建立连接。与此同时将根据收到的帧总数设置接收窗口大小并将所有帧序号放入缓存。双方连接建立好后保证了数据发送和接收的同步性。

接着,发送方开始发送数据帧,接收方收到数据帧并进行处理。能够正确接收到的帧序号将会从序号缓存中删除。发送方发送完数据帧后发送“发送完”标志给接收方。接收方收到此标志后,开始扫描帧序号缓存。如果数据帧全部接收到,接收方向发送方发送一“接收完”标志,发送方收到后断开连接。如果序号缓存中有序号则说明有帧丢失,这时接收方将向发送方发出一个带有丢失帧序号的确认帧。发送方收到此确认帧后将重新发送丢失帧。如此重复,直到接收方完全正确接收到数据帧。其工作过程如图2所示。

3 总结

通过分析比较传输层协议TCP和UDP,能够看到它们各自的特点,并分析出它们各自的优势和缺点。结合嵌入式设备数据传输的特点同时针对UDP在可靠性方面的不足进行了改进,简单介绍了RUDP协议的原理和工作过程。通过分析可以看出采用RUDP的效率在嵌入式设备数据传输中要优于UDP协议,这样就可以实现一种更适合于嵌入式设备的可靠数据传递机制。

参考文献:

[1] Wright G R,Stevens W R. TCP/ IP 详解卷2:实现[M].陆雪莹,蒋慧,译.北京:机械工业出版社,1999.

udp协议篇2

关键词：ARM；Linux；交叉编译环境；UDP协议；重发机制；重发次数

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版本的内核可以登录到下载。本文选择的是arm-linux-gcc-4.3.2工具链()

在宿主机上进入Linux系统，切换当前目录到工具链所在目录，新建一个arm目录保存解压后的文件(mkdir /user/local/arm)并将arm-linux-gcc-4.3.2解压到这个目录中(tar jxvf arm-linux-gcc-4.3.2 –C /user/local/arm)。然后将环境变量-linux-gcc所在的目录(编辑/etc/profile 添加语句”export PATH=/user/local/arm/4.3.2/bin:)，然后reboot一下，这样交叉编译环境就构建好了。

3.2 BOOTLOADER的移植

vivi是一款相当成熟和相对简单的常用bootloader，我们以vivi为移植原型，将S3C2440所有IO端口寄存器定义添加到头文件2440add.inc，删除部分硬件平台使用不到的代码，最后将修改过的vivi制作成镜像烧录到flash中。[1]

udp协议篇3

关键词：UDP协议；磁场测量；数据采集；Delphi

在分布式测量系统中，大多数采用以太网进行数据传输。以太网的传输协议有TCP和UDP等。TCP是面向连接的，可靠性较高，但效率较低；UDP则是一种传输速率高，但不保证数据可靠性的协议，因此比较适合应用在实时性要求高、数据传输量大的测量系统中。

1 UDP协议简述

UDP协议的母体和TCP协议一样，也是IP协议。每个UDP报文称为一个用户数据报，分UDP报头和UDP数据区两部分。报头由四个16位长的字段组成，分别说明该报文的源端口、目的端口、报文长度以及校验和。UDP报文格式如图1所示。

图1 UDP报文格式

源端口字段和目的端口字段包含了16位的UDP协议端口号。长度字段记录该数据报的长度，以8位为组计算，包括报头和用户数据区。校验和字段是可选择的，如该字段值为0，表明不进行校验。UDP协议的报头只包含几个域，比TCP包头简单，它的网络开销一般要小于TCP协议。同时，由于UDP协议在传送数据过程中没有建立连接，也不进行检查，因此在优良的网络环境中，其工作效率较TCP协议要高。但UDP协议不提供报文到达确认、排序以及流量控制等功能，因此，报文可能会丢失、重复以及乱序等，其可靠性问题只能由使用UDP的该应用程序来解决。

2 利用Delphi编写UDP协议的网络应用程序

2.1 INDY介绍

INDY的全名是Internet Direct，是一套开放源代码的Internet控件集，它支持大部分Internet协议，包括TCP、UDP、HTTP、POP3等，支持BASE64、MD2、MD4、MD5等编解码，提供相应的客户端和服务器控件。INDY是完全基于SOCKET阻塞工作模式的开发库，支持Delphi、C++ Builder等开发平台。

2.2 INDY UDP相关控件

INDY（10.1）提供了UDP相关的服务器和客户端控件TIdUDPServer、TIdUDPClient，它们封装了UDP协议的实现。

（1）TIdUDPServer控件的主要属性及方法

主要属性：

Active，启动或停止UDP；

Bindings：TIdSocketHandles，服务器所分配的套接字句柄（Socket handles）；

BufferSize：Integer，最大数据包大小；

DefaultPort：integer，用于监听新连接的端口号；

IPVersion，UDP支持的IP协议版本；

ThreadedEvent：boolean，指定是否采用独立线程进行UDP读操作。

主要方法：

Send（AHost： string， const APort： Integer， const AData： string），向指定IP地址（AHost）和端口（APort）的端点发送字符串；

SendBuffer（AHost： string， const APort： Integer， const ABuffer： TIdBytes），向指定IP地址（AHost）和端口（APort）的端点发送字节数组；

ReceiveString（const AMSec： Integer = IdTimeoutDefault）： string，接收字符串；

ReceiveBuffer（var ABuffer： TIdBytes， const AMSec： Integer = IdTimeoutDefault）： Integer，接收字节数组。

（2）TIdUDPClient控件的主要属性及方法

主要属性：

Host：String，远端计算机IP地址；

Port：Word，远端计算机端口号；

BoundIP：String，本机IP地址；

BoundPort：Word，本机端口号；

BoundPortMax：Integer，本机最大端口数；

BoundPortMin：Integer，本机最小端口数；

BufferSize：Integer，最大数据包大小；

IPVersion：TIdIPVersion，UDP支持的IP协议版本；

ReceiveTimeOut：Integer，等待读取socket时间；

Active：Boolen，启动或停止UDP。

主要方法：

Send（AData：String），发送字符串；

SendBuffer（const ABuffer： TIdBytes），发送字节数组；

SendBuffer（AHost： string， const APort： Integer， const ABuffer： TIdBytes），向指定IP地址（AHost）和端口（APort）的端点发送字节数组；

ReceiveString（const AMSec： Integer = IdTimeoutDefault）：string，接收字符串；

ReceiveBuffer（var ABuffer： TIdBytes，const AMSec：Integer = IdTimeoutDefault）：integer，接收字节数组；

Connected： Boolean，读取UDP连接状态。

2.3 系统程序功能介绍

磁场数据采集系统的主要功能是实时接收测磁仪上传的三分量磁场测量数据，通过图、表形式进行显示，并保存成格式为‘TXT’或‘Excel’类型的数据文件。

在该程序中采用的主要控件有：UDP相关控件IdUDPClient、图形显示控件TeeChart、数据显示控件Memo及文件保存和状态显示控件等。图2是磁场数据采集程序的用户界面。

根据约定采用的上下位机IP地址和端口号（上位机（PC机）的IP为：192.168.0. 99，Port为8080；下位机（测磁仪）的IP为：192.168.0.123，Port为2020），设置IdUDPClient1的相关属性：

Host：=192.168.0.123；

Port：=2020；

BoundIP：=192.168.0. 99；

BoundPort：=8080

图2 磁场数据采集系统程序界面

计算机与测磁仪的通讯过程如下：仪器端等待上位机指令，收到数据传送“开始”指令，将测量数据打包发至上位机，直至收到“停止”指令。上位机在设置好相关IP地址及Port属性后，向仪器端发送“开始”指令，并等待接收数据。收到数据后，对其进行实时处理，更新测量结果的数据和图形显示。

2.4 程序清单 （略）

3 结束语

由于UDP具有TCP无可比拟的速度优势，因此特别适合应用在实时性要求较高且需大量数据传输的场合。在Delphi环境中，采用开源INDY控件实现基于UDP协议的通信，系统开发、调试将更加容易、迅速。

udp协议篇4

关键词：arm；linux；交叉编译环境；udp协议；重发机制；重发次数

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版本的内核可以登录到下载。本文选择的是arm-linux-gcc-4.3.2工具链()

在宿主机上进入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脚本文件等)。由于本实验需对网络编程，要求自动初始化cs8900a网卡芯片的ip地址、网关、子网掩码等，所以在开机自启动脚本中加入ifconfig语句，使得开机时自动配置网卡参数。

根文件系统构建完成后，使用yaffs2文件系统制作工具mkyaffs2image.tgz，通过命令mkyaffs2image rootfs rootfs.img生成根文件系统镜像，然后将镜像烧写入flash中。

4 arm-linux环境下的udp协议通信实验

经过上述硬件设计和操作系统移植过程，本文所使用到的实验环境已经构建完毕，经反复调试修改，嵌入式linux操作系统在平台下运行正常，于是进行udp协议通信实验。

4.1 udp协议套接字编程基础

udp是一个面向数据报和无连接的简单传输层协议，它不像tcp那样通过握手过程建立服务器与客户端的连接才可以工作。在网络通信质量较好的情况下，udp体现出高效率，这适合于传送少量报文的应用。 linux系统是通过套接字结构来进行网络编程的，应用程序通过对套接字的几个函数调用，会返回一个用于通信的套接字描述符,而linux应用程序在进行任何形式的i/o操作时，程序实际上是在读写一个文件描述符。因此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.

范艳开.基于arm的嵌入式linux操作系统移植[d].西安:西北工业大学,2005.

udp协议篇5

关键词：IPSec NAT IKE UDP封装

随着网络技术飞速发展，IPSec已经成为搭建虚拟专用网（VPN）的核心技术。1998年底IETF规划并制定的IPSec。它不仅为IP协议层以上的高层协议和应用提供优质的安全保护，也可兼容IPv4及IPv6，并具有很好的扩展性和可利用性。

NAT，是一种将私有（保留）地址转化为合法IP地址的转换技术，它不仅完美地解决了IP地址不足的问题，而且还能够有效地避免来自网络外部的攻击，隐藏并保护网络内部的计算机。

目前，NAT设备的应用越来越广泛，但它的使用对基于IP的VPN的发展造成了极大的阻碍和影响，其原因在于IPSec协议负责VPN 中的保护传输数据的安全性的工作。在数据传输过程中，IPSec必将对IP包进行修改，因此不能被NAT通过而被丢弃。如何能让二者在VPN网络下协调工作，成为了实现NAT穿透的重要课题。

一、IPSec与NAT的不兼容性分析

根据对两协议的分析，会发现NAT和IPSec具有一定的不兼容。其主要表现有三：一、NAT影响ESP（封装安全载荷协议）；二、NAT影响AH（网络认证协议）；三、NAT影响IKE（密钥管理协议）。而根据对其特征分析后得出结论，IPSec对NAT的支持只有在地址转换情况下和隧道模式才能完成数据NAT穿越，这样既对NAT的工作造成了一定限制，又降低了IPSec的安全性能，可行性差。

为了能使IPSec在VPN中得到充分利用，在现有条件下，IPSec和NAT兼容性解决方案就应满足可部署性、远程访问、防火墙兼容性、可扩展性、后向兼容性、安全性等特性。

二、利用UDP封装法实现NAT的透明穿透

为实现NAT 透明穿透可以采取封装UDP的方法，这样既不需对NAT网关和路由作任何修改又简单易用，但缺点也很明显，添加UDP 报文头，将加大带宽开销，鉴于传输带宽持续扩大，这开销可忽略不计。此方法原理和实现如下：

1、封装格式。为了实现端口的正确转换，保证端口值对NAT可见，我们采取封装UDP的方法，在IP包头和AH/ESP的之间添加一个UDP头，完成封装。由于端口应用重复，为简化配置和避免端口安全隐患，需要采取措施来区分端口500的数据包是IKE消息还是UDP封装的ESP。我们将在IKE 报头添加Non-ESP标记。 在确定存在一个中间NAT之后，支持IPSec NAT-T 的对话方开始使用新的IKE报头。

2、IKE协商过程。通过采取IKE协商来确定IPSec通信实体双方是否采用封装UDP的方法。通过IKE协商在其中增添新的NAT-OA和NAT-D有效载荷和及UDP通道类型。

1）新的NAT-OA有效载荷：其包括IPSec对话方的原始地址。接收方将UDP封装的ESP传输模式时每个对话方在快速模式协商期间发送的 NAT-OA有效载荷存储在用于 SA 的参数中。

2）新的NAT-D有效载荷：新的有效载荷整合一个地址和端口号将其作为散列值，并在主模式协商期间，即IKE协商第一阶段第三、四条消息中，IPSec 对话方中包括一个用于目标地址和端口，另一个用于源地址和端口的两个NAT-D有效载荷。接收方通过NAT-D有效载荷来确定NAT之后是否存在一个的地址端口号被NAT 转换过，然后运用转换后的地址和端口号来判别有无在NAT之后对话方位。

3）用于UDP封装的ESP传输模式和隧道模式的新的封装模式。在快速模式协商期间，为了通知IPSec 对话方应该对 ESP使用 UDP 封装，将采取这两种新的封装模式。

3、地址通告和Keepalive包。由于封装UDP IPSec分组只能解决NAPT 设备不支持AH 和ESP 通信等问题，因此还需要辅助方法来解决如UDP端口映射、TCP校验和错误的保持等问题。为保证校验和正确无误，就必须要实现地址通告，这就需要通信双方将原始IP地址和端口发送给对方。它的实现通过IKE第二阶段的前两条消息中的NAT-OA有效载荷，其中包含 IPSec 对话方的原始地址，因此接收方接收后就可以通过它检验解密之后的上层校验和。

消息发起者在初始主模式和快速模式 IKE 协商期间在NAT中创建了一个 UDP端口映射。 但是，超时后NAT 中的UDP映射一般没有使用就会自动删除。如果响应者随后向发起者发送IKE消息却没有提供UDP端口映射，那么NAT将丢弃其消息。只有利用定期发送Keepalive包，同步刷新后续IKE协商和UDP封装的ESP的UDP端口映射，才能解决此问题，正常保证通信。

三、结束语

随着目前IPSec应用越来越广泛，其已成为VPN的核心协议之一，而由于IPv6取代IPv4仍需时日，因此NAT设备仍将是限制IPSec推广的最大障碍，而UDP封装将是当前解决兼容性问题的最优选择之一，但也并不完善，仍需进一步探讨研究。

参考文献：

[1]Aboba B, William Dixon. IPSec-NAT compatibility requirements[Z]. Internet draft, draft-ietf-IPsec-nat-reqts txt, 2001

udp协议篇6

MSN最新安全版中关村在线免费下载页面:

.cn/detail/11/109664.shtml

QQ和MSN应该是我们最常用的IM软件,但是相信不少人都注意到,两个软件在传输文件的时候,MSN要比QQ慢很多,当然也不是绝对的每次传输MSN都慢,然而这绝对是大多数情况。这到底是为什么呢?让我们来一看究竟。

就本质上而言,QQ是一个基于TCP/UDP协议的通讯软件,而MSN是基于TCP协议的通讯软件,但对博大精深的网络通讯协议的理解和应用,QQ和MSN却有着彼此不同的理念。

那么QQ是如何通讯的呢?在TCP/IP协议中,唯一标识一个应用进程的是socket,它通过网络层的IP地址和传输层的端口号来实现,对于同一个IP地址的内部网络,通过不同的端口号来标识不同的QQ进程;当你登录QQ服务器的时候,服务器会保留你的保留IP地址和端口号信息,并在你的好友的QQ进程中进行列表显示,然后两个进程就可以通信了。

通常,发送文件的计算机首先要通过消息服务器将其IP地址发送给接收计算机,当接收计算机同意接收的确认消息反馈到消息服务器后,消息服务器将据此设置好文件传输对话。随即,发送计算机与接收计算机就会在确定好的端口范围内,建立起TCP或UDP连接开始文件的检索与传输。

在默认状态下,QQ优先采用了UDP(User Data Protocol,用户数据报协议)协议传送数据,而对可靠性要求高的数据通讯系统往往使用TCP协议传输数据。与TCP协议不同,UDP协议并不提供数据传送的验证机制――在整个文件传输过程中如果出现数据报的丢失,协议本身并不能作出任何的检测或提示。因此,通常人们把UDP协议称为不可靠的传输协议。

UDP协议适用于无需应答、要求时效的软件使用,这样的设计正好与QQ追求的目标相符,所以QQ优先使用了此协议进行一切功能应用。但是,由于UDP协议具有不可靠性,常会因种种原因导致消息或数据的发送失败(很多时候会发现发送文件给对方接收时,对方根本收不到要求接收文件的消息。或是发送聊天消息时,对方根本没有收到过消息)。显然,UDP协议由于排除了信息可靠传递机制,将安全和排序等功能移交给上层应用来完成,极大降低了执行时间,使速度得到了保证。QQ在数据传输上更注重实际性能,为了获得更好的使用效果,往往可以牺牲一定的可靠性。因此,使用QQ来传输数据,在很多时候就成了一个“不错”的选择。

一般内网传输首选QQ,速度最快。QQ的文件传输是直接个人对个人,采用P2P的传输方式,具有不需中转的优势,而且服务器都在国内,传输性能要高于外国IM软件。

看过了QQ,我们再来看看MSN的传输原理。MSN全称MSN Messenger,是微软公司推出的即时通讯软件。MSN Messenger凭借自身的优秀性能和简易操作,已跻身为目前世界上使用最为广泛的IM软件(即时通讯软件),在国内也有着众多的用户,是唯一一款可以和QQ抗衡的IM软件。如今MSN除了互联网通信外还广泛用于局域网,如学校、公司、政府机构等内部人员交流。

就MSN所用的TCP协议来说,它已经包含了数据传递验证机制。而网络传输协议中的验证机制往往是接收方收到发送方信息后自动回复一个确认信息,因此有时候在网络出现延迟或线端拥塞时,即使MSN显示连接正常也会出现“无法将XXXX信息发送给所有接收者”。

udp协议篇7

关键词：屏幕广播；UDP协议；数据传输

中图分类号：TP393文献标识码：A文章编号：1009-3044(2011)31-7765-02

屏幕广播技术在实验教学领域，特别在计算机实验教学上起到非常好的作用。一般看来屏幕广播技术的核心技术主要集中在屏幕的截取以及传输上。要做到实时性强，屏幕色彩以及刷新速度与教师机一样是非常不容易的。

就目前所了解的解决方案中一般就截取画面而言，如果采用截取整个屏幕然后广播传输是不可取的，因为这样会增加网络传输的负担，传输的数据量大，实时性也不好。而另外的一种方案就是将屏幕分为若干区域通过判断屏幕中画面的不同区域的图像改变而将改变的部分通过网络传输。但这样做也会造成网络传输频繁，画面有时候会产生残留现象。若采用无连接的、占用网络带宽资源较少的UDP协议可以解决这个问题。

1 UDP协议

UDP是User Datagram Protocol的简称，中文名是用户数据包协议，是OSI参考模型中一种无连接的传输层协议，提供面向事务的简单不可靠信息传送服务。它是IETF RFC 768是UDP的正式规范。

UDP协议的特点：

1) UDP是一个无连接协议，传输数据之前，源端和终端不建立连接。

2) 由于传输数据不建立连接，因此也就不需要维护连接状态，包括收发状态等，因此一台服务机可同时向多个客户机传输相同的消息。

3) UDP信息包的标题很短，只有8个字节，相对于TCP的20个字节信息包的额外开销很小。

4) 吞吐量不受拥挤控制算法的调节，只受应用软件生成数据的速率、传输带宽、源端和终端主机性能的限制。

5) UDP使用尽最大努力交付，即不保证可靠交付，因此主机不需要维持复杂的链接状态表。

虽然在局域网不稳定的环境下，UDP协议数据包丢包率会偏大。但是由于UDP协议所具有的特性――不属于连接型协议，因此具有占用网络小，处理速度快的优点，所以通常多媒体文件，特别是音频、视频和普通数据在传送时较多的使用UDP。因为它们即使偶尔丢失一两个数据包，也不会对接收结果产生太大影响。比如常用的QQ，在传输文字数据、语音数据的时候就是采用UDP协议。

正是由于UDP协议有些这种无连接方式、不可靠的特性，这就使得在一个小型百兆快速以太网中，由于网络环境比较满意，所以我们就能使用此协议进行屏幕广播。再加上每台计算机使用UDP协议的时候占用网络带宽较小，即使局域网中接入较多的计算机（一般计算机实验室的机器数在100台左右）也不会由于网络带宽占用太大而造成屏幕广播的延时。

2 屏幕广播技术

屏幕广播技术实际上是以C/S的方式，通过计算机局域网得以实现的。服务器程序一般安装在主控制计算机上，通常安装在每间实验室的教师机；客户端一般安装在受控制计算机上，通常安装在实验室的学生机上。主控制计算机通过截屏将屏幕里的数据广播至受控制计算机。若采用TCP协议，则会造成数据延时过高。正由于UDP协议不需要建立连接和释放，所以在广播数据中具有效率高、速度快、延时低等有点，故屏幕广播技术适合采用UDP协议进行数据的广播。

实现远程屏幕广播包括以下5个主要步骤：

1) 主控制端和客户端利用UDP协议，主控制端绑定IP广播地址；

2) 主控制端抓取屏幕的数据；

3) 压缩屏幕图像的数据；

4) 由控制端通过局域网向客户端广播发送图像数据；

5) 客户端接收主控制端发送的数据并进行显示屏幕图像。

屏幕广播技术是利用Windows的多线程技术和UDP协议来共同实现的。当教师机上启动屏幕广播之后，系统会创建一个新的线程用来进行当前的屏幕广播，当屏幕广播终止之后自动将这个线程关闭，使得操作系统的资源能够得到重新利用。该线程是在系统的后台执行，由系统的主线程控制。为了提高传输速率，同时降级网络资源的占用，首先要对教师机的屏幕进行分割抓屏，也就是说要将教师机的屏幕按照3×3平均分割成9个较小的网格区域，每个网格区域对应于一个传输线程，接着通过CRC校验即循环冗余校验码（Cyclic Redundancy Check）比对算法找出哪些屏幕区域发生了变化，将发生变化区域的位图数据进行JPG格式的数据压缩，然后使用UDP协议将发生改变的屏幕区域通过对应传输线程传输到客户端的学生机上。学生机在接受到数据之后再将其进行重组，并且同时判断其区域位置，最后将图像显示在学生机的屏幕上。由于只是传输了屏幕发生改变的区域数据，再加上采用具有无连接型、占用网络带宽资源少的UDP协议进行传输数据，在一个局域网内，屏幕广播效果得到了很大的提升。

上述屏幕广播的过程周而复始，这样就能把教师机上屏幕数据不断的发送到学生机。使得教师在教师机上的全部操作都能实时的传输到学生机的屏幕上。这样的话，教师能够边讲解教学内容、边进行实际操作演示给学生看，不仅提高了课堂教学效果，而且提高了学生的学习效率。

说明：

循环冗余校验码（CRC）是一种根据网络数据封包或电脑档案等数据产生简短固定位数校验码的一种散列函数，主要用来检测或校验数据传输或者保存后可能出现的错误。生成的数字在传输或者储存之前计算出来并且附加到数据后面，然后接收方进行检验确定数据是否发生变化。一般来说，循环冗余校验的值都是32位的整数。由于本函数易于用二进制的电脑硬件使用、容易进行数学分析并且尤其善于检测传输通道干扰引起的错误，因此获得广泛应用。它的的基本原理是：在K位信息码后再拼接R位的校验码，整个编码长度为N位，因此，这种编码又叫（N，K）码。对于一个给定的（N，K）码，可以证明存在一个最高次幂为N-K=R的多项式G(x)。根据G(x)可以生成K位信息的校验码，而G(x)叫做这个CRC码的生成多项式。 校验码的具体生成过程为：假设发送信息用信息多项式C(X)表示，将C(x)左移R位，则可表示成C(x)*2的R次方，这样C(x)的右边就会空出R位，这就是校验码的位置。通过C(x)*2的R次方除以生成多项式G(x)得到的余数就是校验码。将作为控制端的教师机的屏幕划分成3*3的9个网络区域，对这9个网格区域分别进行屏幕数据的抓取。然后进行CRC校验比对。数组Prior CRC：array[0..8] of int64；和New CRC:array:[0..8] of int64;分别用于存储上一次和本次不同抓屏的网格图像数据的校验值，如果New CRC[tag]=Prior CRC[tag]，则说明该网格内的屏幕显示没有发生变化，则该数据就不需要进行传输。若New CRC[tag]Prior CRC[tag]，则说明该网格内的屏幕显示已经发生变化，则该数据就需要通过UDP广播协议在局域网内进行数据的传输，将数据发送到客户端，再由客户端将网格数据还原显示到指定的屏幕网格区域，这就完成了一次屏幕广播。

3 屏幕广播技术在实际实验教学中的应用

计算机实验室管理平台是海南大学三亚学院计算机应用基础实验中心的省级科研项目，里面的特色之一就是屏幕广播技术。该平台已经在实验中心使用2年多了，反映效果良好。尤其平台内所嵌套的屏幕广播技术，得到了学院领导的一致肯定和实验教师的一致好评。

屏幕广播技术有效的解决了在局域网内进行广播大量网络数据的时候，占用大量网络带宽和系统资源这一棘手的问题。在计算机上机实验教学中，教师通过计算机管理平台中的屏幕广播模块，教师可以选择对特定机房还是对特定班级进行屏幕广播，边讲解、边实际操作给学生看。当屏幕广播结束之后，学生能够立刻进行实践操作。随着学院的不断壮大完善，班级不断的扩大，实验室也要根据实际需要进行扩大。若每间计算机实验室扩展较大，传统的用投影仪教学的方式已经无法适应大型计算机实验室实验教学的需求，且投影仪维护费用较高，尤其是投影仪的灯泡寿命仅仅3000小时左右，这就造成实验中心维护费用较高。通过采用屏幕广播技术，可以在提高实验教学效果的同时，大大的降低实验教学的运行成本。在计算机实验室中具有广泛的用途。

参考文献：

[1] 臧辉如.高校计算机实验室综合管理的研究[C].海南省高校实验室论文集,2009.

[2] 刘佳,冯震,单娟.基于Winsock通信的远程屏幕抓取技术研究[J].石家庄铁路职业技术学院学报,2008(12).

[3] 陈绍钧.屏幕广播技术在演示教学系统中的应用[J].实验室科学,2008(8).

udp协议篇8

引言

Internet现已成为社会重要的信息流通渠道。如果嵌入式系统能够连接到Internet上面，则可以方便、低廉地将信息传送到几乎世界上的任何一个地方。可以预言，嵌入式设备与Internet的结合代表着嵌入式系统和网络技术的真正未来。随着IPv6的应用，设备都可能获得一个全球唯一的IP地址，通过IP地址和互联网相连成为一个网络设备。但是传统的TCP/IP协议在实现实时性方面做得不够好，它把大量的精力花在保证数据传送的可靠性以及数据流量的控制上。而在实时性要求比较高的嵌入式领域中，传统的TCP/IP不能满足其实时要求。另外，传统TCP/IP的实现过于复杂，需占用大量系统资源，而嵌入式应用的系统资源往往都很有限。因此，需要把传统TCP/IP在不违背协议标准的前提下加以改进实现，使其实现性得到提高，占用的存储空间尽可能少，以满足嵌入式应用的要求。

在大型企业自动化系统中，上层企业管理层和生产监控层一般采用的都是以太网和PC机，而在下层车间现场都是采用现场总线和单片机测控设备。上下两层的沟通，通常采用工业控制机加以太网卡，再加上PC机插槽上的接口卡和并行打印口EPP接口卡来实现。这种连接方式成本高，开发周期长。针对这些情况，本文提出了一种单独的嵌入式CAN-以太网网关互连系统的设计方案，成功地实现以太网和现有的CAN总线网的直接数据传输。

1 异构网络互联系统结构设计

CAN总线是一个设备互连总线型控制网络。在CAN总线上可以挂接多达110个设备节点，各设备间可以自主相互通信，实现复杂网络控制系统。但设备信息层无法直接到达信息管理层，要想设备信息进入信息管理层就要通过一种数据网关。

这里设计了一个SX52网关，用于CAN总线与以太网的互连。图1所示的系统总体结构分为三部分：现场测控网络（CAN网络）、嵌入式透明SX52网关和以太网信息管理终端（如监控平台和网络数据库等）。以太网信息管理终端与CAN总线上的CAN节点通过Ethernet、SX52网关、CAN总线相互通信，其中SX52网关起核心异构网络的互连作用。

协议转换是异构网络互连的技术关键和难点。协议转换一般遥相呼应采用分层转换的方法，自低向上逐层进行。目前互连大都是在网络层或网络层展开的，因而必须对互连层以下各层协议逐层向上转换。这种转换方法的依据是协议分层的基本原理，即低层支持高层，高层调用低层，低层断开连接后，高层连接也随之断开，但高层断开连接却不会影响低层。从网络的分层结构上来看我们设计的互连系统具有如图2所示的分层结构。以太网上运行TCP/IP协议，它具有应用层、传输层、网络层以太网数据链路层和物理层；CAN总线具有应用层、数据链路层和物理层，其中应用层由用户自己定义，数据链路层和物理层由CAN协议所定义；SX52数据网关具有物理层、数据链路层和应用层，其应用层也就是Ethernet与CAN的信息数据交换层，SX52微控制器在此层相互解释并转发这两种不同协议的数据。

在本设计中，SX52网关被设计成了一个透明数据网关。也就是在以太网应用层构建和解析完整的CAN协议数据包。CAN协议数据包作为TCP/IP网络的应用层的数据进行传输。对通信数据的具体实际意义不做任何解释。

透明式网关由通信处理器、CAN总线控制器和以太网控制器三个部分组成。其中SX52单片机为核心处理器，实现CAN控制网络与以太网之间的协议转换。以太网信息管理 层的控制指令发送到嵌入式透明SX52网关，经过它将TCP/IP协议包数据转换为CAN协议形式发送至CAN控制网络中的指定设备节点，完成信息管理层对现场设备层的控制。同样地，当CAN网络上的设备数据（如定时采样数据或报警信息）要传输到信息管理层时，可将数据发送到嵌入式透明SX52网关，再通过网关协议转换程序将CAN协议数据封装成TCP/IP协议的以太网数据帧发送至以太网上的监控计算机。

2 SX52中TCP/IP协议栈的设计

按照层次结构思想，对计算机网络模块化的研究结果是，形成了一组从上到下单向依赖关系的协议栈（protocol stack），也叫协议族。在标准的TCP/IP协议族中有很多协议。这里SX52中TCP/IP协议栈层次结构如图3所示。

2.1 SX52 ARP协议的设计与实现

地址解析协议ARP（Address Resolution Protocol）可以实现逻辑地址到物理地址的动态映射。它提供了一种使以太网络节点可以传输一个IP数据包到目的地址的映射机制。

在SX52中，ARP协议是通过一个“IP地址对应以太网地址”的单登记实现的。当远程主机需要知道它的物理地址时，远程主机会向它发送ARP请求。这时它就会响应这个远程主机的请求，告诉对方自己的物理地址。当然，当应用层需要传输IP数据包时，SX52 ARP协议也可以请求远程目的物理地址。

要传输的Internet数据包在以太网控制器的发送缓冲区中被构建，它使用最近接收到的数据包的目的以太网地址作为发送数据包的目的地址。当然，这可能不是正确的以太网地址，因此，在实际发送数据包之前，ARP协议将检查发送数据包中的IP地址是否存在于ARP核中。如果发送数据中包中的IP地址在这个核中，在以太网发送缓冲区中的数据包将使用ARP核中的以太网地址更新；如果不在，ARP协议将发送一个ARP请求包，然后等待一个应答。一旦这个ARP应答接收到，这个ARP核将使用刚接收到的目标以太网地址更新，接着，等待发送的数据包也将使用这个以太网地址更新，然后被发送出去。如果发送的ARP请求包没有应答，导致ARP定时器超时，这时等待发送的数据包将被废弃，正常的协议栈继续运行。使用的变量有：ARP核中的IP地址{hostlIP3,hostlIP2,hostlIP1,host1IP0};ARP核中的以太网物理地址{host1Eth0,host1Eth1,host1Eth2,host1Eth3,host1Eth4,host1Eth5};ARP协议的定时器{arpTimerMS

B,arpTimerLSB}等。使用涉及的函数有：ARPInit(),ARPCheckCache(),ARPSendResponse(),ARPUpdateEthAddr(),ARPCheckIfIs(),ARPCompare4(),ARPSendStPacket(),ARPSendCommon(),ARPSendRequest()。2.2 SX52 IP协议的设计与实现

IP是TCP/IP协议族中最为核心的协议。所有的TCP、UDP、ICMP及IGMP数据都以IP数据报格式传输。IP提供不可靠、无连接的数据报传送服务。本设计中的IP协议是针对特殊的应用环境下的合理简化。CAN总线的控制网络是一种短帧（每个数据帧为8字节）的实时网络，所以，IP数据包无须分片（MF=DF=0），同时，设置IP为服务类型为一般类型，其头长为20字节，寿命TTL设置为64。使用的变量有：目的IP地址{remoteIP3,remoteIP2,remoteIP1,remoteIP0};源IP地址{myIP3,myIP2,myIP1,myIP0};IP校验和{ipCheckSumMSB,ipCheckSumLSB};IP数据包长度{ipLengthMSB,}ipLengthLSB};上层使用的协议ipProtocol,IP标识{ipIdentMSB,ipIdentLSB}。使用涉及的函数有：TCPIPInit(),CheckIPDatagram(),CheckIPDestAddr(),IPStartPktOut()等。

2．3 SX52 ICMP协议的设计与实现

为了让互联网中的路由器报告或提供有关意外情况的信息，在TCP/IP协议系列中加入了一个专门用于发送差错报文的协议——互联网控制报文协议ICMP（Internet Control Message Protocol）。ICMP是IP的一部分在每个IP实现中都必须用到它。像其它所有的通信业务一样，ICMP报文是放在一个IP数据报的数据部分中传送的。ICMP报文的最终目的不是应用程序或目的机器上的用户，而是该机上处理它的Internet协议软件模块。也就是说：Internet控制报文协议允许路由器向其它路由器或主机发送差错或控制报文；ICMP在两台主机的Internet协议软件之间提供通信。

每个ICMP报文都以相同的3个字节开始：1个8位整数的报文类型（TYPE）字段用来识别报文，1个8位代码（CODE）字段提供有关报文类型的进一步信息，1个16位校验和字段。此外，ICMP报文还总是包括产生问题的数据报首部及其开头的64位数据。

ICMP使用IP来传送每一个差错报文。当路由器有一个ICMP报文要传递时，它会创建一个IP数据报并将ICMP报文封装其中，也就是说，ICMP报文被置于IP数据报的数据区中，然后这一数据报像通常一样被转发。即整个数据报被封装进帧中进行传递。

每一个ICMP报文的产生总是对应于一个数据报。路由器将一个ICMP报文将回给产生数据报的主机。在这里，只实现了ICMP的回应请求/应答服务，主要用于PING程序测试通信链路的畅通性，即只处理接收的报文类型为0x08的ICMP帧，发送的ICMP报文类型为0x00。它没有自己专有的变量，涉及的函数也只有ICMPGenCheckSum（）和ICMPProcPktIn()。

2.4 SX52 UDP协议的设计与实现

UDP是一个简单的面向数据报的运输层协议：进程的每个输出操作都正好产生一个UDP数据报，并组装成一份待发送的IP数据报。UDP不提供可靠性，它把应用程序传给IP层的数据发送出去，但是并不保证它们能到达目的地。由于缺乏可靠性，我们似乎觉得要避免使用UDP，而使用一种可靠的协议，如TCP。但分析发现，UDP在我们的互连设计中有很多的优点：其一，UDP协议传输效率高，无须TCP通信前的连接开销；第二，UDP协议简单，无须复杂的状态机传输机制，可以很好地避免SX52网关死机复位后由于状态不一致而无法正常通信，且上层协议又很难发现的危险。因此，可以使用UDP来实现通信（避免TCP连接的开销），而让许多需要的特征（如动态超和重传、拥塞避免、查错等）放置在应用层设计和实现。使用的变量有：

UDP接收数据报的源端口{udpRxSrcPortMSB,udpRxSrcPortLSB};

UDP接收数据报的目的端口{udpRxDestPortMSB,udpRxDestPortLSB};

UDP接收数据报的长度{udpRxDataLenMSB,udpRxDataLenLSB};

UDP发送数据报的源端口{udpTxSrcPortMSB,udpTxSrcPortLSB};

UDP发送数据报的目的端口{udpTxDestPortMSB,udpTxDestPortLSB};

UDP发送数据报的长度{udpTxDataLenMSB,udpTxDataLenLSB}。

设计的相关函数有：UDPAppInit(),DPGenCheckSum(),UDPStartPktOut(),UDPProcPktIn(),UDPEndPktOut(),UDPAppProcPktIn(),UDPAppProcPktOut()等。

2.5 SX52 TCP协议的设计与实现

传输控制协议TCP（Transmission Control Protocol）是传输层的重要协议。它提供一个完全可靠的（没有数据重复或丢失）、面向连接的、全双工的流传输服务。本设计中，对复杂的TCP协议做了合理的简化：①因为CAN网络传输速度较快，数据量小且10Mbps的以太网传输一般不会发生阻塞，以太网上的主机也会有足够的能力及时处理通信数据，所以可以固定超时与重传的时间为5s。②RTL8019AS上有两个1500字节的接收缓冲区，且CAN网络为控制网，信息量小，所以可以固定接收窗口为1400字节。③因为我们采用一般的TCP服务就可以满足应用，所以可以忽略紧急指针和选项及填充字段的值。通过上述三点简化，实际上大大简化了TCP协议的实现。因为TCP的超时与重传时间的确定和窗口大小的控制有着较复杂的算法和实现机制。

它的实现变量有：tcpState,{tcpTmpSeq4,tcpTmpSeq3,tcpTmpSeq2,tcpTmpSeq1},{tcpTmpAck4,tcpTmpAck3,tcpTmpAck2,tcpTmpAck1},{tcpUnAckMSB,tcpUnAckLSB},tcpRxFlags,{tcpCheckSumMSB,tcpCheckSumLSB},{tcpLengthMSB,tcpLengthLSB},{tcpTmpMSB,TcpTmpLSB},{tcbLocalPortMSB,tcbLocalPortLSB},{tcbRemotePortMSB,tcbRemotePortLSB},{tcbSndUna4,tcbSndUna3,tcbSndUna2,tcbSndUnal},{tcbRcvNxt4,tcbRcvNxt3,tcbRcvNxt2,tcbRcvNxt1},tcbOffset,tcbFlags,{tcbSendWinMSB,tcbSendWinLSB},{tcpTimerMSB,tcpTimerLSB}等。

相关函数有：TCPIPInit(),TCPRxHeader(),TCPProcPktIn(),TCPTransmit(),TCPReTransmit(),TCPAppPassiveOpen(),TCPAppActiveOpen(),CPA

ppClose(),TCPAddRcvNxt(),TCPIncRcvNxt(),TCPIncSndUna(),TCPCopySeqToNxt(),TCPAckUpdate(),TCPUpdateSeq(),TCPChkSeq(),TCPRestorePrev(),TCPCmpNxtSeq(),TCPSendEmptyPkt(),TCPSendReset(),TCPSendSyn(),TCPSendISN(),TCPSendSynAck()TCPSendAck(),TCPSendFin(),TCPCheckSuminit(),CPCheckSumAcc(),TCPCheckSumAddHdr(),CPTxByte(),TCPStartPktOut(),TCPAppInit(),TCPAppTxBytes(),TCPAppTxData(),TCPAppTxDone(),TCPAppRxBytes(),TCPAppRxData(),等。2.6 TCP和IP传输层协议的选择

把TCP/IP协议应用到控制网络中如何选择传输层协议类型很关键。如果要与现有的应用程序通信，必须使用与其相同的协议类型。在实际应用时，从可靠性来说，TCP提供了可靠的数据连接，UDP和直接访问IP的一些协议是不可靠的，数据报可能会丢失、损坏或重复；从性能上讲，UDP的性能最快，可靠性、流量控制重组包和连接维护等附加开销降低了TCP的性能。对于速度比较慢的系统来说，如温度、湿度传感器，选择TCP或UDP都无所谓，对于不太重要的传感器选用UDP就可以了；对于可靠性要求较高的传感器，应该选用TCP协议；对于实时性要求高的网络设备，如网络会议系统、IP音响、实时播放的电视等设备，数据传输率较高，应该选用UDP协议；有些有严格要求的同步系统应采用UDP；数据监控系统传输的可靠性要求较高，应采用TCP；Web和Email也应采用了TCP。总之，要根据实际情况来确定选用何种协议。

udp协议篇9

【关键词】 无线网络 多媒体 通信 传输技术

引言：随着社会的发展，人们生活水平日渐提升，其安全防护意识也有所增强，在先进技术支持下，无线网络应急多媒体通信的应用愈加广泛，不仅保证了人们的安全，还提高了其生活质量。但实际应用中，对应急多媒体通信有着较高的要求，如：实时性、可靠性与连续性等，而无线网络应急多媒体通信未能满足上述要求，因此，本文探讨了其传输协议与通信终端系统，旨在进一步提高其整体性能。

一、应急多媒体通信的无线网络特点

其一，低宽带，通常情况下，其宽带仅为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.

udp协议篇10

基于UDP的数据传输协议（UDP-basedDataTransferProtocol，简称UDT）是一种互联网数据传输协议。UDT的主要目的是支持高速广域网上的海量数据传输，而互联网上的标准数据传输协议TCP在高带宽长距离网络上性能很差。顾名思义，UDT建于UDP之上，并引入新的拥塞控制和数据可靠性控制机制。UDT是面向连接的双向的应用层协议。它同时支持可靠的数据流传输和部分可靠的数据报传输。由于UDT完全在UDP上实现，它也可以应用在除了高速数据传输之外的其它应用领域，例如点到点技术（P2P），防火墙穿透，多媒体数据传输等等。

（来源：文章屋网 https://www.wzu.com）