下面是小编精心为大家整理的udp协议通用4篇，在大家参照的同时，也可以分享一下给您最好的朋友。
关键词：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协议；磁场测量；数据采集；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 = IdT …imeoutDefault）：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的数据传输协议（UDP-basedDataTransferProtocol，简称UDT）是一种互联网数据传输协议。UDT的主要目的是支持高速广域网上的海量数据传输，而互联网上的标准数据传输协议TCP在高带宽长距离网络上性能很差。顾名思义，UDT建于UDP之上，并引入新的拥塞控制和数据可靠性控制机制。UDT是面向连接的双向的应用层协议。它同时支持可靠的数据流传输和部分可靠的数据报传输。由于UDT完全在UDP上实现，它也可以应用在除了高速数据传输之外的其它应用领域，例如点到点技术（P2P），防火墙穿透，多媒体数据传输等等。
（来源：文章屋网
关键词：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 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.