當前位置：首頁 > 文庫 > 文案

udp協議范文8篇

時間：2024-08-15 14:15:35 81

udp協議

udp協議篇1

關鍵詞：UDP協議；Socket；網絡通信

中圖分類號：TP393文獻標識碼：A文章編號：1009-3044(2008)34-1867-02

Socket Network Programs Based on UDP Protocol

ZHOU Li-juan

(College of Science, Hunan University of Technology, Zhuzhou 412008, China)

Abstract: Windows Socket is a network programming interface,and applications can correspond to eachother in different domains without worrying about the different protocols by using it.This paper introduces the mechanism and principle of Socket network programs based on UDP protocol,and proposes a method of network with Java socket.

key words: UDP protocol;socket; network communication

Socket適用于網絡環境中的進程間通信，它已成為當前許多操作系統的網絡API，也是網絡操作系統中必不可少的基礎功能。隨著Linux操作系統和Internet的不斷發展，Linux網絡環境下尤其是基于UDP的socket通信技術仍廣為注目。文章介紹了socket的編程原理，并通過一個Java編寫的客戶/服務器程序，描述了網絡中基于UDP的不同主機上的兩個進程之間的socket通信機制。

1 Socket通信機制

Socket（套接字）機制是一種API，是網絡應用程序的編程接口。Socket是通過標準文件描述符和其它程序通訊的一個方法。每一個套接字都用一個半相關描述：{協議，本地地址、本地端口}來表示；一個完整的套接字則用一個相關描述：{協議，本地地址、本地端口、遠程地址、遠程端口}，每一個套接字都有一個本地的由操作系統分配的唯一的套接字號。

根據傳輸數據類型的不同，Socket主要分為三類：1) 流式Socket（SOCK_STREAM），在這種方式下，兩個通訊的應用程序之間要先建立一種虛擬的連接，提供可靠的、面向連接的通信流，它使用TCP協議，從而保證了數據傳輸的正確性和順序的。2) 數據報Socket（SOCK_DGRAM），它使用數據報協議UDP，定義了一種無連接的服務，數據通過相互獨立的報文進行傳輸，是無序的，并且不保證可靠、無差錯。3) 原始Socket，原始套接字允許對底層協議如IP或ICMP直接訪問，它功能強大但使用較為不便，主要用于一些協議的開發。

2 UDP協議的工作原理

UDP協議是一個面向無連接的協議，其連接的建立不必像TCP那樣需要服務器端偵聽，也不需要有客戶機請求連接，屬于一種“強制”性的網絡連接。UDP提供一對一或一對多的、無連接的數據報服務。該服務對消息中傳輸的數據提供不可靠的、最大努力的傳送，這意味著它不保證數據的到達，也不保證所傳送的數據報的順序是否正確，UDP不重新傳輸丟失的數據。其主要工作是：將應用程序傳輸過來的數據分塊交給網絡層，確認接受到分組信息。

盡管UDP無法像TCP一樣提供可靠的數據傳輸，但UDP并不比TCP缺乏優越性。UDP在傳輸效率方面比TCP要高一些，而且許多應用程序并不需要保證嚴格的傳輸可靠性，比如視頻會議系統等，需要實時的交互，但并不要求音頻視頻的絕對正確。

使用UDP協議傳輸數據時，首先設置客戶計算機的Local Port(本地端口)屬性，而作為服務器的計算機只需要設置Remoter Host(遠程主機)屬性為客戶計算機的IP地址或域名即可，并將其Remote Port屬性設置為客戶計算機上的Local Port屬性。使用UDP端口號時，端口提供了用于發送消息的位置，每個端口由一個唯一的編號來標識。當應用程序向另一臺計算機發送數據時，UDP生成一個數據頭，包括源端口，這些端口提供送達信息所需要的地址。UDP協議還為數據和數據頭計算出求和檢驗的值，在目標計算機中，數據包被傳遞至UDP協議程序并送到目的地端口。

3 UDP套接字的通信過程

中提供了兩個類DatagramSocket和DatagramPacket用來支持數據報通信。DatagramSoc ket用來在程序之間建立傳送數據報的通信連接，是數據報通信中的Socket。在數據報實現C/S通信程序時，無論在客戶端還是服務器端，都要首先建立一個DatagramSocket對象，用來表示數據報通信的端點，應用程序通過Socket接收或發送數據報。

DatagramPacket則用來表示一個數據報，它是傳輸數據的載體，封裝了數據、數據長度、數據報地址等信息。

采用UDP套接字方式實現C/S的通信程序由客戶端和服務器端兩部分組成。服務器進程依次按以下步驟進行：1) 調用Socket()創建一個數據報套接字；2) 調用bind()把服務器地址綁定在該套接字上；3) 調用recvform()等待客戶進程發來的請求，服務器此時處于無限循環狀態；4) 服務進程接收到客戶進程所發來的數據報后，進行處理，調用sendto()將處理結果返回給客戶進程，返回狀態3)，繼續監聽；5)服務進程調用close()撤消套接字，終止服務。

客戶進程則按以下步驟進行：1) 調用Socket()創建一個數據流套接字；2) 調用sendto()向服務器進程發送數據報；3) 調用recvfrom()等待服務器進程返回該處理結果；4) 客戶進程調用close()撤消套接字。

4 數據報通信實例

程序由服務器端和客戶端兩部分組成，服務器端主機中有一個名為“udp_socket.txt”文件，文件中保存了一段英文。服務器端接收一個客戶端的請求，就從文件中讀取若干個英文字符發送給客戶端。當文件中所有內容發送給完畢，服務器端程序將退出。客戶端首先構造一個數據報發送給服務器端，然后等待接受服務器端響應，當接收到服務器端的數據報后，顯示數據并結束通信。

1) 服務器端程序

public class Server_Th

{ boolean m_q=true;

public void serverWork() throea IOException

{DatagramSocket ds=new DatagramSocket(2000)

//創建端口號為2000的數據報套接字

BufferedReader in=new BufferedReader(new FileReader (“udp_socket.txt”));

while(m_q)

{ byte buf[ ]=new byte[256];//創建緩沖區

DatagramPacket packet=new DatagramPacket (buf, buflength); //創建接收數據報對象

ds.receive(packet);//接收數據報

String dString=null;

if((dString=in.reaLine())==null)

{in.close();

m_q=false;

dString=”Good Morning!”;}

buf=dString.getBytes();//將數據存儲到buf中

inetAddress address=packet.getAddress();

//得到客戶端IP地址

int prot=packet.getPort();//得到客戶端的端口

packet=new DatagramPacket (buf,buf.length, address. port );

//構造要發送數據報

ds.send(packet);//發送數據報

}

ds.close();//關閉

}

public void main(String args[])

{ Server_Th server=new Server_Th();

try

{server.serverWork();}

Catch(IOException e){}

}}

2) 客戶端程序

public class Client_Th

{public void main(String args[ ]) throws IOException

{ DatagramSocket socket=new DatagramSocket( );

//創建套接字對象

byte buf[ ]=new byte[256];

InetAdress address=InetAddress.getByName(“20.14.30.9”);

//服務器IP地址

DatagramPacket packet=new DatagramPacket(buf,buf. Length,address,2000);//創建要發送的數據報對象

socket.send(packet);//接收數據報

packet=new DatagramPacket(buf,buf.length);

//創建要接收的數據報對象

socket.receive(packet);//接收數據報

String received=new String(packet.getData());

System.out.println(“The string form the server: ”+recerived);

//取得數據報中的數據并顯示

Socket.close();//關閉socket

}}

編寫程序時客戶端和服務器端的DatagramSocket必須用一個端口，因為客戶端向服務器端請求時，服務器需要知道從哪個端口監聽請求。當數據進行傳輸時，服務器從接收到的數據報中得到客戶端的接收數據的端口，然后將數據報發送到這個端口，客戶端則監聽這個端口而得到服務器端發送過來的數據報并顯示其內容。運行時要先運行服務器端程序，再運行客戶端程序。

5 小結

Socket在網絡編程方面發揮著很大的作用。UDP是可靠性無法得到保障的協議，但對于質量要求不是很高的網絡應用程序，UDP是一個很好的選擇。

參考文獻：

[1] 張桂珠.Java面向對象程序設計[M].北京:郵電出版社,2006.

[2] 周坤,傅德勝.基于Windows Socket的網絡數據傳輸及其安全[J].計算機工程與設計,2007,28(22):5381-5386.

[3] 趙文清.淺析用Socket的Java語言網絡通訊機制和程序設計[J].信息技術,2002(7):66-67.

udp協議篇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] 劉暢,彭楚武.linux下的udp協議編程[j].儀表技術,2006(1).

udp協議篇3

【關鍵詞】UDP協議；ARM；X86；通訊；解決方案

隨著人工智能的應用，ARM產品已經遍布到各個領域：工業控制、無線通訊領域、消費類電子產品、成像和安全產品，包括現在流行的數碼相機和打印機中絕大部分采用ARM技術，手機中的32位SIM智能卡也采用了ARM技術。除此以外，ARM微處理器及技術還應用到許多不同的領域，并會在將來取得更加廣泛的應用，因此，ARM與其它平臺之間通訊就顯得尤為重要。

1.UDP協議本質

UDP協議是英文User Datagram Protocol的縮寫，即用戶數據報協議，主要用來支持那些需要在計算機之間傳輸數據的網絡應用。包括網絡視頻會議系統在內的眾多客戶/服務器模式的網絡應用都需要使用UDP協議。UDP協議從問世至今已經被使用了很多年，雖然其最初的光彩已經被一些類似協議所掩蓋，但即使是在今天，UDP仍然不失為一項非常實用和可行的網絡傳輸層協議。

UDP協議使用端口號為不同的應用保留其各自的數據傳輸通道。UDP和TCP協議正是采用這一機制實現對同一時刻內多項應用同時發送和接收數據的支持。數據發送一方（可以是客戶端或服務器端）將UDP數據報通過源端口發送出去，而數據接收一方則通過目標端口接收數據。有的網絡應用只能使用預先為其預留或注冊的靜態端口；而另外一些網絡應用則可以使用未被注冊的動態端口。因為UDP報頭使用兩個字節存放端口號，所以端口號的有效范圍是從0到65535。一般來說，大于49151的端口號都代表動態端口。

數據報的長度是指包括報頭和數據部分在內的總的字節數。因為報頭的長度是固定的，所以該域主要被用來計算可變長度的數據部分（又稱為數據負載）。數據報的最大長度根據工作環境的不同而各異。從理論上說，包含報頭在內的數據報的最大長度為65535字節。不過，一些實際應用往往會限制數據報的大小，有時會降低到8192字節。

UDP協議使用報頭中的校驗值來保證數據的安全。校驗值首先在數據發送方通過特殊的算法計算得出，在傳遞到接收方之后，還需要再重新計算。

如果某個數據報在傳輸過程中被第三方篡改或者由于線路噪音等原因受到損壞，發送和接收方的校驗計算值將不會相符，由此UDP協議可以檢測是否出錯。其實在UDP協議中校驗功能是可選的，如果將其關閉可以使系統的性能有所提升。這與TCP協議是不同的，后者要求必須具有校驗值。

2.實現案例

實現案例如下：在觸摸屏進行畫圖，使其在液晶屏上顯示，同時通過網絡傳輸數據，使其在計算機屏幕上顯示，并由計算機控制清除液晶屏上的圖形。

步驟如下：

（1）新建工程

void InitNetWork（）//初始化網絡

{

U32 ipaddr32，ipmaskaddr32，ipgateaddr32；

U8 *Mac；

ipaddr32=Get_ipaddr（）； //獲取IP地址

ipmaskaddr32=Get_maskaddr（）；//獲取子網掩碼

ipgateaddr32=Get_gwaddr（）； //獲取網關

Mac=Get_mac（）； //獲取網卡地址

NetPortChoose（0）； //選擇網口，必須在配置網絡以前進行

initOSNet（ipaddr32， ipmaskaddr32， ipgateaddr32，Mac）；//配置網絡

OSTimeDly（1000）；//任務掛起1秒

printk（"init Ethernet and UDP is ok！＼n"）；

}

（3）定義計算機端套接字，全局變量

（4）編寫Main_Task任務及消息循環

主要負責響應觸摸屏消息，在屏幕上畫圖，然后將數據傳輸到計算機上。

對觸摸屏消息的處理和鍵盤消息類似，其消息類型pMsg->Message為OSM_TOUCH_SCREEN，消息參數pMsg->LParam中包含了觸摸屏的動作信息，定義如下：

#define TCHSCR_ACTION_NULL 0

#define TCHSCR_ACTION_CLICK 1 //觸摸屏單擊

#define TCHSCR_ACTION_DBCLICK 2 //觸摸屏雙擊

#define TCHSCR_ACTION_DOWN 3 //觸摸屏按下

#define TCHSCR_ACTION_UP 4 //觸摸屏抬起

#define TCHSCR_ACTION_MOVE 5 //觸摸屏移動

消息參數pMsg->WParam中則包含了觸摸點的坐標信息，低16位是X坐標值，高16位是Y坐標值。這里當觸摸屏產生“按下”動作后采用MoveTo（）函數設置繪圖起始點坐標，當產生“移動”動作后采用LineTo（）函數繪制線段。

3.解決方案

3.1 建立Socket

為了建立建立Socket，程序可以調用Socket函數，該函數返回一個類似于文件描述符的句柄。socket函數原型為：

int socket（int domain， int type，int protocol）；

domain指明所使用的協議族，通常為PF_INET，表示互聯網協議族（TCP/IP協議族）；type參數指定socket的類型：SOCK_STREAM或SOCK_DGRAM，Socket接口還定義了原始Socket（SOCK_RAW），允許程序使用低層協議；protocol通常賦值”0”。Socket（）調用返回一個整型socket描述符，你可以在后面的調用使用它。

Socket描述符是一個指向內部數據結構的指針，它指向描述符表入口。調用Socket函數時，socket執行體將建立一個Socket，實際上”建立一個Socket”意味著為一個Socket數據結構分配存儲空間。Socket執行體為你管理描述符表。

兩個網絡程序之間的一個網絡連接包括五種信息：通信協議、本地協議地址、本地主機端口、遠端主機地址和遠端協議端口。Socket數據結構中包含這五種信息。

3.2 配置Socket

通過socket調用返回一個socket描述符后，在使用socket進行網絡傳輸以前，必須配置該socket。面向連接的socket客戶端通過調用Connect函數在socket數據結構中保存本地和遠端信息。無連接socket的客戶端和服務端以及面向連接socket的服務端通過調用bind函數來配置本地信息。

Bind函數將socket與本機上的一個端口相關聯，隨后你就可以在該端口監聽服務請求。Bind函數原型為：

int bind（int sockfd，struct sockaddr *my_addr，int addrlen）；

Sockfd是調用socket函數返回的socket描述符，my_addr是一個指向包含有本機IP地址及端口號等信息的sockaddr類型的指針；addrlen常被設置為

3.3 建立連接

面向連接的客戶程序使用Connect函數來配置socket并與遠端服務器建立一個TCP連接，其函數原型為：

int connect（int sockfd，struct sockaddr *serv_addr，int addrlen）；

Sockfd是socket函數返回的socket描述符；serv_addr是包含遠端主機IP地址和端口號的指針；addrlen是遠端地址結構的長度。Connect函數在出現錯誤時返回-1，并且設置errno為相應的錯誤碼。進行客戶端程序設計無須調用bind（），因為這種情況下只需知道目的機器的IP地址，而客戶通過哪個端口與服務器建立連接并不需要關心，socket執行體為你的程序自動選擇一個未被占用的端口，并通知你的程序數據什么時候到達端口。

Connect函數啟動和遠端主機的直接連接。只有面向連接的客戶程序使用socket時才需要將此socket與遠端主機相連。無連接協議從不建立直接連接。面向連接的服務器也從不啟動一個連接，它只是被動的在協議端口監聽客戶的請求。

Listen函數使socket處于被動的監聽模式，并為該socket建立一個輸入數據隊列，將到達的服務請求保存在此隊列中，直到程序處理它們。

int listen（int sockfd，int backlog）；

首先，當accept函數監視的socket收到連接請求時，socket執行體將建立一個新的socket，執行體將這個新socket和請求連接進程的地址聯系起來，收到服務請求的初始socket仍可以繼續在以前的socket上監聽，同時可以在新的socket描述符上進行數據傳輸操作。

3.4 傳輸數據

Send（）和recv（）這兩個函數用于面向連接的socket上進行數據傳輸。

Sockfd是你用來傳輸數據的socket描述符；msg是一個指向要發送數據的指針；Len是以字節為單位數據的長度；flags一般情況下設置為0（關于該參數的用法可參照man手冊）。

Send（）函數返回實際上發送出的字節數，可能會少于你希望發送的數據。在程序中應該將send（）的返回值與欲發送的字節數進行比較。當send（）返回值與len不匹配時，應該對這種情況進行處理。

3.5 傳輸結束

當所有的數據操作結束以后，你可以調用close（）函數來釋放該socket，從而停止在該socket上的任何數據操作。

udp協議篇4

關鍵詞網絡通信；UDP二次封裝；共享內存；進程間通信

中圖分類號TN92 文獻標識碼A 文章編號 1674-6708（2011）55-0181-02

1研究背景

磁浮仿真系統大致可以為分3個層次，底層是仿真子系統的仿真管理計算機，中間層是仿真支撐服務器，上層是工作站仿真計算機。所有環境仿真設備通過以太網與底層子系統的仿真管理計算機相連，仿真管理計算機對其仿真子系統進行統一管理，它將子系統仿真設備的工況信息實時向上推送。仿真支撐服務器與所有底層子系統管理計算機和上層工作站均有通信需求，是報文收發的中轉站，它將、工作站及其執行結果的信息記入數據庫備查，或用于數據分析。上層工作站用于集成管理底層的子系統，它注入故障下達測試命令到底層子系統管理計算機并等待應答。此外，底層子系統管理計算機之間也互相傳遞信息。這些計算機中仿真系統在處理接收和發送數據上的工作大多是相同的，如果能夠簡化它們在數據通信上的工作，將對系統的設計和效率有很大的提高作用。網絡通信方案的設計，即可將系統中各模塊處理網絡通信的部分抽取出來，封裝成一個相對獨立的模塊。

2影響因素分析

磁浮仿真系統中底層管理計算機上運行的仿真軟件是不同編程語言實現的，各自重新構建通信接口有困難,底層、中層、上層不同計算機之間的通信要求也各異。通過對磁浮仿真系統中多個模塊的通信要求分析，可以得到模塊間的數據通信具有以下特點：

1）多點對多點傳輸數據。如果采用面向連接的方式進行通信，則需要每個模塊都各自維護到其它模塊的多個連接，處理起來很不方便，并且不利于擴充模塊。因此適合無連接的通信；

2）模塊間的數據通信具有突發性，通信數據量不規則、不連續。比較適合采用報文轉發方式傳輸；

3）通信目的計算機的IP地址可能改變，需要可配置；

4）模塊的數量可能擴充，也就是說，在同一臺計算機上運行的不同模塊的通信節點可能有多個，需要可配置；

5）模塊間傳輸數據必須保證通信的可靠性和數據的正確性；

6）某些通信要求實時性，通信異常導致陳舊數據必須清除。

3方案設計

根據第2節的影響因素分析，了解到通信方案需要解決四個問題，即通信接口問題、實時性可靠性均衡問題、IP端口可配置問題。首先，解決通信接口問題，需要將系統的數據通信工作獨立出來，與原本系統的其他應用隔離開。因此，引入這樣兩個概念――通信層進程和應用層進程。通信層進程負責為應用層提供通信服務和其他輔助服務，如通信日志記錄、通信狀態監控等；應用層進程即原本系統各模塊運行的應用進程，兩者間數據通信靠本機進程間通信維系。基于確保實時性和大數據量的通信要求，本機進程間通信選取的方法是共享內存，然后分別為通信層和應用層提供讀寫共享內存的接口，即使用DLL（動態鏈接庫）的方式分別加載到通信層程序和應用層程序中。其次，解決實時性可靠性均衡問題，從多點通信和實時性的考慮出發，決定了選取無連接且傳輸更高效的UDP協議。然而，UDP協議不能保證可靠性，于是想到了對UDP協議進行二次封裝，形成一種兼顧通信的可靠性與實時性的新協議――RUDP協議。最后，采用通信層進程讀取.ini配置文件的配置信息的方法來解決IP端口可配置問題。

3.1 本機進程間通信

本機應用層與通信層之間的進程間通信需要借助共享內存技術、動態鏈接庫技術來實現。

共享內存技術是通過內存映射文件的方式來實現的。內存映射文件是文件內容到進程虛擬地址空間的復制。文件的內容的拷貝稱為文件映像，而操作系統用來維持該拷貝的內部結構稱為文件映射對象。另一個進程通過使用第一個進程的文件映射對象建立映像，可以在它自己的虛擬地址空間建立完全一樣的文件映像，這樣就達到了進程間共享數據的目的。

設計方案將共享內存分為兩種。一種發送報文時使用，應用層進程向此共享內存內寫入報文，通信層進程分配線程采用輪循或接收消息通知的方式讀取共享內存中的待發送報文，并通過套接字將其發送到目的計算機的通信層進程。這種共享內存可稱之為發送結點共享內存。另一種與此相反，接收報文時使用，通信層進程接收到報文后，根據報文首部判斷與之對應的目的應用層，并將報文寫入對應的共享內存，應用層進程再讀出并解封裝報文。根據報文發送目的地址與源地址，可為每個源地址與目的地址分配對應的共享內存。每一塊共享內存，有一個或幾個寫入線程，一個讀出線程與其相對應。

動態鏈接庫（DLL）技術用來提供讀、寫、清空共享內存的接口。在DLL完成相應共享內存的初始化工作后，發送接收雙方進程通過調用該DLL中相應的寫入讀取共享內存的函數訪問共享內存，從而實現雙方的通信。雙方進程啟動后，用內存映射文件的方式把一塊命名共享內存映射到DLL附加的各個進程地址空間。

共享內存的實現方式設計如圖1所示。

3.2 UDP協議二次封裝

RUDP就是在原TCP/IP協議的傳輸層的UDP協議和應用層之間加入了一層為保證可靠數據傳送而實現的RUDP軟件模塊而形成的一個五層體系結構，即在原有TCP/IP模型的應用層和傳輸層之間加入一個定制的通信層（RUDP層），這樣就可以利用UDP協議實現一種基于消息的面向連接的可靠數據傳遞機制。

為了保證數據傳輸的可靠性，可以借鑒TCP的三次握手原理，對UDP進行二次封裝，形成了RUDP傳輸機制。報文發送方對傳輸的可靠性和實時性要求通過應用層與通信層的接口DLL，以出口函數的參數形式傳遞，然后再將這些信息封裝到原報文首部。通信層中解封裝報文首部，并根據這些信息靈活地選擇通信方式用以提高傳輸效率和保證可靠。

3.3配置文件

.ini配置文件用來靈活配置系統中某臺計算機需要通信的節點個數、通信目的地址、對端接收端口和本機綁定端口。.ini的讀寫通過調用api函數GetPrivateProfileInt()；GetPrivateProfileString()和WritePrivateProfileString()來實現。

4測試驗證

根據通信方案的設計，我們已經編碼實現了一套通信中間件，包含單獨的通信層程序、配套動態鏈接庫通信接口及.ini配置文件，并在100Mbps傳輸速率的局域網中進行了一對一、多對一、多對多的測試驗證，得到測試結果如下表：

5結論

文中論述的通信方案確保了整個仿真系統可以高頻度大數據量地進行通信，實現了上層工作站、中層服務器與下層管理計算機之間的數據交互要求。在保證數據傳輸可靠性的的前提下，盡可能的滿足了數據傳輸的實時性。通信層完全獨立于需要通信的應用層，通信接口良好，可以做到靈活配置，極大地方便了應用層的調用，為今后整個仿真系統的擴展，通信需求的增加提供了良好保證。完善后的通信方案不僅適用于本仿真系統，還可以應用于類似需求的局域網多點通信中。

參考文獻

[1]施煒，李崢，秦穎編著.Windows Sockets 規范及應用-Windows網絡編程接口.

[2]周偉明.多核計算與程序設計.華中科技大學出版社，2009.

[3]汪翔，袁輝編著.Visual C++實踐與提高.網絡編程篇.中國鐵道出版社，2001.

[4]郎銳，孫方編著.Visual C++網絡通信程序開發基礎及實例解析.2版.北京：機械工業出版社，2006.

[5]電腦編程技巧與維護雜志社編著.Visual C++編程技巧典型案例解析網絡與通信及計算機安全與維護篇.北京：中國電力出版社，2005.

[6]劉化君編著.網絡編程與計算技術.北京：機械工業出版社，2009.

[7]梁庚，白焰.Windows下進程間通信方式探討.微型電腦應用，2006，22(12).

[8]馬魁濤，蔡穎，郭寶峰.Win32進程間信息共享的實現方法研究.

udp協議篇5

關鍵詞：IPSec；NAT；IKE；VPN；UDP封裝

中圖分類號：TP393文獻標識碼：A文章編號：1009-3044(2008)33-1360-03

Research on Coordination Between IPSec and NAT

ZHANG Ai-ke

(Departmet of Information Engineering, Liuzhou Vocational&Technical College,Liuzhou 545006,China)

Abstract: Network Address Translation (NAT) and IP security protocol (IPSec) are outstanding technologies that are widely used in network. At present, because IPSec and NAT are incompatible, the technologies can not co-exist in network at the same time. This paper engages in the research upon the coordination between IPSec and NAT. points out the application scope of NAT-T so as to guide the optimum IPSec VPN implementation.

Key words: IPSec;NAT;IKE;VPN;UDP encapsulation

1 引言

IPSec與NAT是用來解決IPv4中網絡安全與IP地址短缺問題的兩項技術。IPSec是Internet工程任務組（IETF）制定的一系列安全標準[1]，已被確定為IPv6的必需組成部分，是下一代網絡的安全標準，它可以較好地解決目前Internet上面臨的安全威脅，有效地保證數據的安全傳輸。隨著Internet的不斷發展，采用IPSec技術實現利用互聯網建立VPN網絡，越來越被眾多大中型企業所青睞，IPSec已逐漸成為構建VPN的主流技術。網絡地址轉換（NAT）技術[2] 在內部網絡中使用內部私有IP地址，通過NAT將每個從內部網絡發出的數據包的私有地址翻譯成合法的公用IP地址在Internet上使用，支持多臺主機共享全局IP地址，常見于接入設備和防火墻中，能很好地解決IPv4網絡地址枯竭的問題，同時具有屏蔽內部網絡的作用。

然而，在實際應用中，IPSec技術和NAT技術存在嚴重的不兼容性，當IPSec數據流穿越NAT設備時，兩者無法協同工作，已被廣泛使用的NAT設備制約著基于IPSec技術的VPN的發展。因此，IPSec和NAT兼容性方面的問題已成為當前網絡安全領域的研究熱點，尋求基于IPSec技術的VPN和現有的NAT設備和平共處，實現NAT透明穿越的解決方案已成為迫在眉睫的任務。

2 問題描述

由于IPSec對數據包進行保護，對數據包的改動會導致驗證或解密過程的失敗。IPSec與NAT的兼容性沖突是多方面的，其中主要是由于IPSec數據包在穿越NAT時無法進行正確轉換造成的。IPSec與NAT的不兼容性問題主要有以下幾個方面[3]：

1) IPSec AH和NAT：AH利用消息摘要算法對整個IP數據包產生一個散列值，該散列值的作用范圍是整個IP包，包括源IP地址和目的IP地址，接收方利用該散列值認證收到的IP數據包。如果在發送過程中原始IP包的任何字段發生變化，都將會導致接收方的認證失敗，接收方將丟棄該包。但NAT會對外出包的源地址和進入包的目的地址進行修改，AH認為IP包被非法修改，從而導致認證失效。ESP的完整性檢查不包括IP頭（傳輸模式），或者檢查的是不為NAT所修改的內嵌IP協議頭（隧道模式），因此在ESP中不存在這樣的問題。

2) 校驗和與NAT：TCP和UDP在計算校驗和時使用了偽頭部，因而校驗和與IP源和目的地址有依賴關系。因此，當NAT設備改變IP地址后需要重新計算并修改TCP/UDP校驗和。當應用了ESP傳輸模式的IP包經過NAT設備時，由于TCP/UDP校驗和處于加密負載之中，該值在在修改了外層IP包頭后無法被NAT進行更新，這樣，雖然IPSec不會丟棄這個包，但是當它被送往上層協議處理，在進行校驗和校驗時會出錯，這個包還是會被丟棄。ESP隧道模式可以和靜態或動態NAT相兼容，因為TCP/UDP校驗和只與內層“原始”IP包頭有關，對于外層IP包頭的的修改并不對其造成影響。然而，在NAPT存在的情況下，AH和ESP都無法通過NAPT，NAPT需要TCP/UDP端口來匹配出入信包，上層端口信息對于NAT網關是不可知的，所以NAT網關無法完成多個私網地址映射到一個公網地址的變換。

3) IKE地址標識符和NAT：在IKE協商中，通信雙方使用IP地址作為身份標識符，而NAT設備對IP地址的修改會引起IP頭中的地址和標識符不符，IKE會將這樣的包丟掉。

4) IKE固定的目標端口和NAPT：IKE協商時的UDP通信端口號一般固定是500，而當NAPT后面的多方主機向同一響應者發起IKE SA時，NAPT需要通過不同的端口號區分不同的連接，因此，響應者必須能夠接受非500UDP端口的IKE流量。

5) 重疊的SPD項和NAT：在IKE協商的第二階段中，NAT后的多個主機和相同響應者協商SPD時會出現重疊，這樣，響應者可能在錯誤的IPSec SA下發送數據包。

6) IPSec SPI選擇符和NAT：IPSec ESP流量受加密保護，對NAT是透明的，NAT必須使用IP頭和IPSec頭來多路分解到來的IPSec信包，目的IP地址、安全協議（AH/ESP）、和SPI共同惟一標識一個安全聯盟來達到這個目的。由于SA是單向的，外出和進入包的SPI選取是獨立的，因此，僅通過監測外出的流量，NAT無法決定哪個進入的SPI和哪個目標主機相對應。

7) 內嵌IP地址和NAT：當內嵌IP地址時，由于載荷受到完整性保護，IPSec包中的任何IP地址不能被NAT轉換。內嵌IP地址的協議包括FTP、IRC、SNMP、LPAP、H.232、SIP和許多游戲協議。

除上述外，有些NAT的具體實現也存在不利于IPSec穿越的特點，例如：某些NAT供應商的NAPT不能處理非UDP/TCP報文，拒絕通過ESP、AH報文；有些幫助解決兼容性問題的方法會引起新的不兼容性，如對端口500的特殊處理、對ISAKMP有效載荷進行解析及ISAKMP頭部檢查等。

3 協同工作的方法

IPSec和NAT的兼容性方案的目的是擴大IPSec的適用范圍。根據前面分析的IPSec與NAT之間存在的兼容性問題，以及評估一個解決方案的可配置性、可擴展性、多模式支持能力、與防火墻的兼容性、遠程通信能力、互操作性和安全性等原則[4]，下面來探討一些方法來解決IPSec和NAT協同工作的問題。

3.1 RSIP方法

RSIP是指在不同地址域通信的主機自己能處理跨越不同地址域的地址變換問題。它的工作機制[5]是：當RSIP客戶機要聯系互聯網上主機的時候，它查詢RSIP服務器以便獲得一個端口號和公網IP地址。接著客戶機通過隧道將包發往RSIP服務器，RSIP服務器將隧道頭剝掉，然后將包發向互聯網。對于到達的包，RSIP服務器基于端口號查找客戶機IP地址，加入隧道頭，然后將它們發往RSIP客戶機。

RSIP網關是跨越在多個編址域的多宿主設備，允許主機直接參與到多個編址域中，并不對地址進行翻譯，這樣盡管主機需要知道RSIP網關，但是卻沒有破壞Internet端到端的通信，應用RSIP不需要修改源到目的地的IP載荷流，也就避免了對AH、ESP等協議的損傷。

RSIP技術的完全實現需要用新的RSIP網關代替現有的NAT路由設備，同時涉及對客戶機的修改、服務器的重新部署等問題，因此實施費用相對較大，部署時間較長，降低了該方案的可行性。

3.2 “6to4”方法

這種方法的基本原理[6]是：各個局部網絡運行在IPv6上，在IPv6網絡邊界安裝NAT，NAT給主機提供IPv6地址前綴，這個地址前綴是NAT設備的IPv4 IP地址，當IPv6的數據報到達NAT時，NAT提取IPv6的地址前綴作為IPv6數據報的IPv4隧道地址，NAT把IPv6數據包封裝在IPv4數據包中發送出去；在響應方，相應的NAT作IPv4隧道的解封，解封后的數據包在局部網絡中用IPv6協議進行路由。在各個VPN保護的子網中是基于IPv6協議通信的。

這種方法很好地考慮了將來整個網絡升級到IPv6的情況，同時它需要的支持也很少。

但這種方式要求對NAT進行修改，現在NAT的分布已非常廣泛，而且很多NAT設備部署在公司、機構無法控制的地方，例如：ISP部署NAT在它的接入服務器上。因此，實施這種方式的費用較高，短期內難以實現。

3.3 專用NAT方法

其基本思想是：在VPN網關接收到數據包時作一次該網關專用的NAT，將通信鏈路中作了NAT的數據包根據策略配置恢復沒有NAT時的IP地址或端口，當數據包通過網關到達目的地時，與通信鏈路中沒有NAT時的數據包一樣。通過這種方式來解決IPSec與NAT兼容性問題的關鍵是：在雙方初始通信時確定NAT的存在，把經過NAT的數據包和系統策略配置中的連接相聯系起來，為通信雙方的后續通信建立地址、策略綁定，維持這個連接的狀態，后續的通信根據連接狀態作NAT。

這種處理方式將內部網絡的拓撲結構暴露給了通信對方的網關，通信鏈路中的竊聽者也能得到這部分信息，并且每個客戶端都必須安裝有這個解決方案的實現。專用NAT沒有正式文檔描述，在已有的幾個產品中可以見到，如e-Border Solution provided by Permeo Technologies，Inc。目前沒有提供也沒有實現這種方案的系統之間的兼容性。

3.4 UDP封裝方法

UDP封裝法[7]是IETF提出的一種用于IPSec穿越NAT的解決方案，基本思想是：由發送主機在發送前將IPSec數據包封裝在UDP中，到達接收方后再去掉外面的IP頭以及UDP封裝，從而使其中的IPSec數據包不受影響。ESP協議在傳輸模式和隧道模式下UDP封裝格式分別如圖1、圖2所示。

圖1 ESP傳輸模式UDP封裝數據格式變化圖

圖2 ESP隧道模式UDP封裝數據格式變化圖

UDP封裝法的實現需要對IKE協商進行改進來配合。

1) IKE協商第一階段

在這一階段中需要完成兩種探測：探測對方是否支持NAT穿越（NAT-T）；探測在通信路徑中是否存在NAT設備。在IKE第一階段的前兩條交換消息中，發送“廠商ID載荷”，如果對方支持NAT，那么它就能識別此載荷，因為它詳細描述了對NAT穿越的支持。然后在主模式的第三個和第四個交換消息或者野蠻模式的第二個和第三個交換消息中，增加載荷NAT-D（NAT-Discovery），載荷的值是源或者目的地址和端口號的HASH值，計算如下：

HASH=HASH（CK-I│CK-R│IP│Port）

其中CK-I，CK-R分別是發送方和接收方的Cookie值。當對方收到NAT-D載荷后，計算地址和端口的HASH值，如果與收到的相同，則表示它們之間沒有NAT，否則表明鏈路中有NAT設備對它做了改變。如果發送者不能確定自己的IP地址，它可以在報文中包含多個本地IP地址的HASH值，僅當所有的HASH值均不匹配時，才表明有NA設備存在。

一些NAT設備不改變源端口500，即使NAT后面有多個客戶機。這些NAT設備通過Cookie值而不是端口來完成與后面多個客戶機的映射，這樣，IKE很難發現NAT設備的兼容性能力。最好的方法是發現存在NAT設備后，把IKE傳輸從端口500上移走。一般在NAT設備被探測到后，發起者必須立刻將UDP的源端口和目的端口都設置為4500。這樣會出現一個問題：IKE協商數據包（UDP數據包）和協商完成后的UDP封裝ESP數據包使用相同的端口4500進行發送，為了區分出這兩種數據包，在IKE數據包的UDP頭和IKE頭之間添加四字節的Non-ESP標志，與UDP封裝的ESP包中的SPI域對齊，且值為全零。封裝后的IKE包和ESP包的格式[8]如圖3所示。

圖3UDP封裝后IKE包和ESP包的區別

2) IKE協商第二階段

如果在第一階段發現有NAT設備存在，IKE的第二階段協商SA時就作相應的變化：添加兩種新的模式：UDP封裝隧道模式和UDP封裝傳輸模式；增加NAT-OA以發送發起者的原始IP地址，以修正因NAT變換后的TCP/UDP校驗和；位于NAT后面的IPSec發起方定期發送保持激活報文（keep alive），用以保持所建立的NAT映射不變。

該方案不需要對IKE或IPSec協議本身做任何的改動，只需要對IKE的實現做一些小的改進，該方法只依賴于NAT對UDP的支持，所以可以與絕大多數的NAT設備一起協同工作，具有簡單且易于實現的優點，在總體上對NAT穿越問題有了較好的解決。但是，該方案的缺點也很明顯：不支持AH協議，增加了載荷長度，延長了IKE協商SA的時間，無法實現NAT后多主機發起通信，泄漏了內網地址信息等。盡管如此，IETF提出的UDP封裝法及在它基礎上進行的各種改進，仍然是目前解決IPSec與NAT兼容性問題的主流技術。

3.5 TCP封裝方法

使用UDP協議的好處在于傳輸數據比較快，UDP協議在傳輸小數據量時確實比TCP協議有更好的效率。但是，當需要傳輸的數據量比較大（如使用數字證書進行身份認證和密鑰協商）時，UDP協議數據容易失序和丟失；在一個噪音比較大，數據失真比較多，容易受干擾的網絡環境（如無線網絡）中，往往造成數據的大量失真。出現這些情況時，需要上層協議對UDP數據包進行重新排序或重傳等操作，由此造成的效率損失往往比較大，在此我們可以考慮使用TCP協議進行密鑰協商。TCP協議能夠很好地處理數據報的失序和丟失問題，在大數據量傳輸時也有很好的表現。TCP協議在建立過程和拆除過程中的數據交換所造成的效率損失并不比UDP協議處理時的損失大。

在實際的應用環境中，使用UDP封裝會遇到以下的復雜情況：UDP數據屬于上層數據，如果長度比較大，IP層會對此數據進行分片，先由IPSec協議對此分片數據進行封裝，再由UDP協議進行二次封裝以穿越NAT；到達目的地后拆除UDP的二次封裝，需要再由IP層對分片數據進行重組。假如其中UDP二次封裝的一個數據報丟失，那么整個UDP數據報都需要重新發送而不是只發送丟失的數據分片。這將造成整個通信效率明顯下降。在此我們可以考慮使用TCP協議對IPSec數據包進行二次封裝。TCP協議不會造成數據的失序和丟失，TCP協議會自動重新發送丟失的數據報而不是全部業務數據重新發送。此時使用TCP不會造成明顯的效率降低，而是更好地提供了數據的傳輸服務。

以上分析的雖然是復雜的情形，但VPN通信是面向廣域網的安全傳輸需求，它相比局域網環境中的通信要復雜得多，在實際應用中各種情況都可能出現，所以用TCP代替UDP對IPSec數據包進行封裝以穿越NAT設備的考慮是具有現實意義的。

4 結束語

基于IPSec的VPN技術和NAT技術都是充滿前途和廣泛被使用的網絡技術，解決IPSec和NAT的協同工作問題，對于部署VPN具有重要的意義。該文在詳細分析了影響IPSec和NAT無法兼容的原因后，提出了實現NAT穿越幾種方法，其中詳細介紹了比較適用于目前網絡環境的UDP封裝法，并提出了用TCP封裝IPSec數據包的設想，下一步的研究工作就是在此基礎上進一步深入加以完善。

參考文獻：

[1] Naganand Doraswamy.IPSec新一代因特網安全標準[M].北京:機械工業出版社,1998.

[2] RFC-1631-1994.The IP Network Address Translator (NAT) [S].

[3] 譚興烈,張世雄.IPSec和NAT協同工作技術研究[J].計算機工程與應用,2003(12):I64-165.

[4] 李孝展,潘金貴.IPSec與NAT兼容性問題及其解決方案剖析[J].計算機應用與軟件,2007,24(2):161-163.

[5] RFC-3103-2001.M.Borella, D.Grabelsky ,J Lo,K.Taniguchi. Ream Specific IP:Protocol Specification( RSIP)[S].

[6] RFC-3056-2001.B.Carpente and K.Moore.Connection of IPv6 Domains via IPv4 Clouds[S].

[7] RFC-3984-2005. A. Huttunen, W. Dixon, V. Volpe. UDPEncapsulation of IPsec Packets[S].

udp協議篇6

關鍵詞： TCP/IP；TCP協議； UDP協議；Winsock；遠程監測

中圖分類號：TP393 文獻標識碼：A 文章編號：1009-3044（2013）04-0731-06

Design of TCP and UDP Communication Test Software

TU Jin-long

（Nanjing Communications Institute of Technology， Nanjing 211188， China）

Abstract： TCP and UDP are two protocols of TCP/IP transmission layer protocol. They use IP routing function to send packets to destinations， thus provide network services for applications and application layer protocols. TCP and UDP both have their advantages and disadvantages， the mai n difference between them lies in the connection state. Applications choose accord to the actual usage. Winsock can be used to write client and server applications without the need of knowing details of the TCP/IP. By setting Winsock attributes and call its control methods， connection to remote computers and two-way data exchange can be easily achieved.

Key words： TCP/IP； TCP protocol； UDP protocol； Winsock； remote monitoring

根據國家有關標準，各地應加強對客運車輛燃料消耗量檢測和監督管理，加快淘汰、更新高耗能的老舊營運車輛。但迄今為止，我國客運行業的能耗統計一直采用手工填寫統計報表的方式，不僅投入的人力物力大、數據誤差大，而且不能實時了解能耗情況。為此，需要研發一種客車能耗遠程監測系統，以便實時快速地采集客車運營過程中的有關信息，實現全自動的客車能耗數據分析、處理、評估，從而改變現行的由人工按月或年度填寫報表的統計方式，提高工作效率及數據的準確性，為管理部門對高能耗高污染車輛實施強制淘汰或報廢提供數據支持。

隨著計算機技術及網絡技術的不斷發展，人們的生活和工作越來越離不開網絡，尤其是網絡遠程控制技術已經廣泛地應用于網絡自動化管理、實時監控等方面。針對移動運行的客車，要實時獲取有關數據，就需要憑借無線網絡將采集到的數據傳到監控中心。在眾多的網絡通信中，以TCP/IP協議最為流行，為了測試遠程無線通信在具有防火墻的系統中的有效性，針對應用的特殊性，以及為了順利進行軟硬件的配接，需要先編寫一個測試通信鏈路的TCP和UDP通信測試軟件。

TCP和UDP是TCP/IP體系結構中的兩個傳輸層協議，它們使用IP路由功能把數據包發送到目的地，從而為應用程序及應用層協議提供網絡服務。TCP提供的是面向連接的可靠的端到端傳送服務，它可以在低層不可靠的情況下（如出現分組傳輸的丟失、亂序等）提供可靠的傳輸機制。而UDP提供的是無連接的、不可靠的傳輸服務，在數據傳輸之前，不需要建立連接，而且收方收到UDP數據報文之后，也不需要給出任何應答信息。顯然，UDP減少了很多的為保證可靠傳輸而附加的額外開銷，因而它的效率高[1]。因此，TCP與UDP各有其優缺點，要根據實際應用進行選擇。

1 TCP和UDP測試軟件的設計

使用TCP和UDP通信的方法有多種，在VB開發平臺上使用Winsock控件來設計軟件可以說是最方便的。Winsock即Windows Sockets規范的簡稱，是目前最流行的網絡通信應用程序接口之一。Socket通常也稱作“套接字”，用于描述IP地址和端口，是一個通信鏈的句柄。應用程序通常通過“套接字”向網絡發出請求或者應答網絡請求。

Winsock控件對用戶是不可見的，但它提供了訪問TCP/IP網絡的捷徑，使用它可以通過UDP協議或TCP協議方便地連接到遠程的機器并進行數據交換。用Winsock控件編寫客戶和服務器應用程序，不需要了解TCP/IP或調用底層Winsock API的具體細節。通過設置Winsock控件的屬性和調用該控件的方法，可以很容易地連接到遠程計算機并進行雙向的數據交換。

使用WinSock控件時，首先要確定的是使用TCP還是UDP協議，它們之間主要的區別在于連接狀態。

1.1 TCP測試軟件設計

TCP協議是面向連接的協議，在數據傳輸前就建立好了點到點的連接。TCP網絡程序工作原理如圖1所示[2]。

圖1 TCP網絡程序工作原理

基于 TCP/IP 協議網絡通信主要模式就是客戶機/服務器模式（Client/Server 模式，簡稱 C/S），即客戶端提出請求，服務器在監聽時接收到請求后就提供請求服務。遠程控制是基于 C/S 模式來實現的，所以程序分為服務器和客戶端程序。客戶端和服務器端連接成功后，通過信息交換取得相應的服務。因此，在進行編程時，服務器端程序應設置Winsock控件的LocalPort屬性和調用 Listen 方法來監聽，客戶機端程序則要設置 Winsock 控件的 RemoteHost 和 RemotePort 屬性、調用 Connect 方法請求連接[3]。一旦建立了連接，兩臺計算機之間就可以發送和接受數據了。要發送數據，調用SendData方法。當接受數據時，產生DataArrival事件。在DataArrival事件中調用GetData方法來接收數據。

在VB6開發平臺上可以方便地使用Winsock控件來設計網絡通信軟件，為了測試的方便，將客戶端和服務器端的軟件設計在同一軟件中，通過標簽來選擇是客戶端還是服務器端，或是UDP測試，也可以在同一臺電腦中運行軟件完成測試。在設計階段，添加好必要的窗體和按鈕、文本框并設置所需的名稱、屬性后，在窗體中放置Winsock控件，在屬性窗口里的協議，選擇sckTCPProtocol，也可以在代碼里配置協議，例如：

Winsock1.Protocol=sckTCPProtocol

1.1.1服務器端程序

為了能接受多個連接請求，需要創建新的控件實例，調用新的實例中的接受方法。下面是創建一個服務器端程序的主要內容：

1）設置端口并偵聽（監聽）。雙擊“開始偵聽”按鈕，在代碼中加入要設置的LocalPort，并開始監聽，代碼如下：

Private Sub cmdListen_Click（）

If TCP_Server（0）.State sckClosed Then TCP_Server（0）.Close

TCP_Server（0）.LocalPort = txtLocalPort（2）.Text

TCP_Server（0）.Listen

End Sub

2）監聽連接請求。監聽方法在控件中被調用，每個連接請求到來時，代碼會測試看它的索引（Index）是否為0（監聽控件的值），根據其值是否為0執行不同的操作。代碼如下：

Private Sub TCP_Server_ConnectionRequest（Index As Integer， ByVal requestID As Long）

Dim i As Long

If Index = 0 Then '主Winsock——Winsock（0）發生消息

i = 1

If maxConnext > 0 Then

While i

i = i + 1

DoEvents

Wend

End If

If i

TCP_Server（i）.LocalPort = txtLocalPort（2）.Text

TCP_Server（i）.Accept requestID

nowconnext（i） = True 'Winsock（i）被占用

Else

If maxConnext > 50 Then

MsgBox "已經達到最大用戶數！"， vbExclamation + vbOKOnly， "提示"

Exit Sub

End If

maxConnext = maxConnext + 1

Load TCP_Server（maxConnext）

TCP_Server（maxConnext）.LocalPort = txtLocalPort（2）.Text

TCP_Server（maxConnext）.Accept requestID

ReDim Preserve nowconnext（maxConnext + 1）

nowconnext（maxConnext） = True

ReDim Preserve saveServerData（maxConnext + 1）

ReDim Preserve saveServerIndex（maxConnext + 1）

i = maxConnext

End If

End Sub

3）服務器端發送數據。若選中發送回車符，則在代碼中增加發送回車符，若選中發送換行符，則在代碼中增加發送換行符。若是廣播，則逐個發送，否則需要選擇發送目標。主要代碼如下：

Private Sub cmdSend3_Click（）

Dim i As Integer

Dim sendresult As Long

Dim sendsrc（） As Byte

Dim sendsrclen As Long

Dim sendmess（1 To 1024） As Byte

Dim outByte（） As Byte

If Me.ckHex（2）.Value = 1 Then '十六進制發送

sendsrclen = Len（txtSend（2）.Text） / 2 - 1

ReDim sendsrc（0 To sendsrclen）

For i = 0 To sendsrclen

sendsrc（i） = Val（"&H" & Mid（txtSend（0）.Text， i * 2 + 1， 2））

Else

outByte = StrConv（txtSend（2）.Text， vbFromUnicode）

sendsrc = outByte

sendsrclen = UBound（outByte）

End If

If chkGB.Value = 1 Then

For i = 1 To maxConnext

If TCP_Server（i）.State = sckConnected Then

TCP_Server（i）.SendData sendsrc

End If

DoEvents

Else

Dim findSerVer As Boolean

For i = 1 To maxConnext

If saveServerIndex（i） = Val（Combo1.Text） Then

findSerVer = True

Exit For

End If

If i > 0 And findSerVer = True Then

If TCP_Server（i）.State = sckConnected Then

TCP_Server（i）.SendData sendsrc

End If

Else

MsgBox "請選擇發送目標！"，， "提示："

End If

End Sub

4）服務器端接收數據，數據到達后，先調用TCP_Server控件的getdata方法，將接收的數據以vbstring數據類型，存放在strdata變量之中，然后再加到txtReceive（2）控件之中。主要代碼如下：

Private Sub TCP_Server_dataarrival（Index As Integer， ByVal bytestotal As Long）

Dim strdata As String

TCP_Server（Index）.GetData strdata， vbString

txtReceive（2）.Text = txtReceive（2）.Text & Index & "：" & TCP_Server（Index）.RemoteHostIP & "：" & TCP_Server（Index）.RemotePort & "：" & strdata & vbCr

End Sub

以上是創建一個服務器端程序的主要內容，為了方便使用，還可適當增加一些輔助的功能，運行后的服務器端界面如圖2所示。

圖2 TCP協議服務器端測試軟件運行界面

1.1.2 客戶端程序

1）設置遠程主機端口并連接。雙擊“建立連接”按鈕，在代碼中指定遠程主機的ip地址，并調用TCP_Client控件的connect方法，來初始化與主機的連接請求，代碼如下：

Private Sub cmdConnect_Click（）

On Error GoTo connectErr

If Tcp_Client.State sckClosed Then Tcp_Client.Close

Tcp_Client.RemoteHost = txtRemoteHost（1）.Text

Tcp_Client.RemotePort = txtRemotePort（1）.Text

Tcp_Client.Connect

TimerConnect.Enabled = True

Exit Sub

connectErr：

StatusBar1.Panels.Item（2）.Text = "未能成功連接。" & Err.Number

End Sub

2）客戶端發送數據。若選中發送回車符，則在代碼中增加發送回車符，若選中發送換行符，則在代碼中增加發送換行符。主要代碼如下：

Private Sub cmdSend2_Click（）

Dim i As Integer

Dim sendresult As Long

Dim sendsrc（） As Byte

Dim sendsrclen As Long

Dim sendmess（1 To 1024） As Byte

Dim outByte（） As Byte

On Error Resume Next

If Me.ckHex（1）.Value = 1 Then '十六進制發送

sendsrclen = Len（txtSend（1）.Text） / 2 - 1

ReDim sendsrc（0 To sendsrclen）

For i = 0 To sendsrclen

sendsrc（i） = Val（"&H" & Mid（txtSend（0）.Text， i * 2 + 1， 2））

Else

outByte = StrConv（txtSend（1）.Text， vbFromUnicode）

sendsrc = outByte

sendsrclen = UBound（outByte）

End If

If chk13（1）.Value = 1 Then

sendsrclen = sendsrclen + 1

ReDim Preserve sendsrc（0 To sendsrclen）

sendsrc（sendsrclen） = 13

End If

If chk10（1）.Value = 1 Then

sendsrclen = sendsrclen + 1

ReDim Preserve sendsrc（0 To sendsrclen）

sendsrc（sendsrclen） = 10

End If

If Tcp_Client.State = sckConnected Then

Tcp_Client.SendData sendsrc

Else

MsgBox "請先建立連接！"，， "提示："

End If

End Sub

3）客戶端接收數據，先調用TCP_Client控件的getdata方法，將接收的數據以vbstring數據類型存放strdata變量之中，然后將strdata變量的內容，加到txtReceive（1）控件之中。主要代碼如下：

Private Sub TCP_Client_dataarrival（ByVal bytestotal As Long）

Dim strdata As String

Tcp_Client.GetData strdata， vbString

txtReceive（1）.Text = txtReceive（1）.Text & strdata

End Sub

本部分是創建一個客戶端程序的主要內容，運行后的界面如圖3所示。

1.2 UDP測試軟件

UDP是無連接的協議。與TCP操作不同，計算機并不建立一個連接。并且，UDP應用程序可以是用在客戶端，也可以用在服務器端。使用UDP協議，在兩個Winsock控制間進行數據的發送，在連接的兩端必須完成以下三步：

1）設置RemoteHost屬性；

2）設置RemotePort屬性；

3）申請Bind方法。

通過使用方法Bind，則可將該Winsock捆綁到一個本地端口，以便該Winsock使用該端口來進行類似TCP的“監聽”功能，并防止其它應用使用該端口。

使用UDP協議傳送數據，首先設置客戶計算機的LocalPort屬性。而作為服務器的計算機僅需要設置RemoteHost屬性為客戶計算機的IP地址或域名，并將其RemotePort屬性設置成客戶計算機上的LocalPort屬性。主要代碼如下：

WinsockUDP.RemoteHost = txtRemoteHost（0）.Text

WinsockUDP.RemotePort = txtRemotePort（0）.Text

WinsockUDP.LocalPort = txtLocalPort（0）.Text

WinsockUDP.Bind txtLocalPort（0）

然后就可通過SendData方法來開始信息發送，客戶計算機則可在其DataArrial事件中使用方法GetData來獲取發送的信息，發送和接收數據的代碼與TCP通信的代碼類似。UDP測試程序運行后的界面如圖4所示。

圖4 UDP協議測試軟件運行界面

2 結束語

TCP和UDP是TCP/IP體系結構中的兩個傳輸層協議，它們使用IP路由功能把數據包發送到目的地，從而為應用程序及應用層

協議提供網絡服務。TCP提供的是面向連接的可靠的端到端傳送服務，而UDP提供的是無連接的傳輸服務，在數據傳輸之前，不需要建立連接，因而它的效率高。TCP與UDP各有其優缺點，它們之間主要的區別在于連接狀態，應用時要根據實際應用進行選擇。

使用TCP和UDP通信的方法有多種，在VB開發平臺上使用Winsock控件來設計軟件可以說是最方便的。用Winsock控件編寫客戶和服務器應用程序，不需要了解TCP/IP的具體細節。通過設置Winsock控件的屬性和調用該控件的方法，可以很容易地連接到遠程計算機并進行雙向的數據交換。

參考文獻：

[1] 天津電氣傳動設計研究所.電氣傳動自動化技術手冊[M].北京：機械工業出版社，2011.

[2] 茹志鵑.基于TCP協議的Socket數據通信[J].科技信息，2012 （13）：69，93

udp協議篇7

關鍵詞：車輛監控系統； GPS； GPRS； UDP

中圖分類號：TN919-34 文獻標識碼：A 文章編號：1004-373X(2011)24-0107-03

Vehicle Monitoring System Based on GPRS Technology

WU Xiao-bin1, DU Dong-gao2

(1. Computer College, Nanjing Institute of Technology, Nanjing 210000, China;

2. College of Information Engineering, Jiaozuo University, Jiaozuo 454003, China)

Abstract： In order to implement the positioning tracking for dangerous goods, passenger, cargo transport vehicles and other special project vehicles, the GPS positioning system and GPRS communication technology are adopted for the achievement of real-time vehicle monitoring system. The data communication between the vehicle terminal and the control center is achieved by taking GPRS communication technology as a carrier of information transmission to display real-time traffic information by GPS positioning and WEBGIS technologies. The system has the advantages of high-speed communication, strong communication format scalability, high communication reliability and strong client controlling capacity to vehicles. The vehicle front-end status and location are displayed by Web page. It is easy for the clients to use the system.

Keywords： vehicle monitoring system; GPS; GPRS; UDP

收稿日期：2011-07-23

基金項目：南京工程學院青年基金資助項目（QKJB2009023）

0 引言

隨著我國經濟的發展,車輛日益增多,交通運輸的經營管理,貨運、客運的安全管理等,已成為公安、交通系統中的一個重要問題。車輛監控系統以全球定位系統（Global Position System,GPS）和GPRS（General Packet Radio Service）通信技術基礎，它可以將車載單元上接受到的實時定位數據通過無線網絡傳送至監控中心服務器上，監控中心計算機再利用地理信息系統的地圖顯示功能，以及信號指令的發送功能，實現對動態車輛的跟蹤與調度控制，從而建立起的一種大范圍、全方位發揮作用的、實時、準確、高效的綜合車輛調度和管理系統。系統基于Internet網絡，將監控中心、遠程監控終端、數據服務器、無線移動通信網、GPS 車載終端有機地結合在一起，以Internet服務器為核心實現分布式監控。

1 系統結構

基于GPRS的車輛監控信息系統由4個主要部分構成,即監控服務中心、車載終端、監控終端及無線通信網絡構成；監控服務中心是系統的核心部分，它連接車載終端和客戶端。監控服務中心由Web服務器，通信服務器，數據庫服務器構成。通信服務器接受車載終端的數據，并將數據轉發給Web服務器和數據庫服務器。該系統結構圖如圖1所示。

2 系統關鍵技術

2.1 GPRS通信技術及UDP數據傳輸協議

在車輛和監控中心之間需要通信設備來發送或接收信息。通信手段的選擇是監控系統的難點和技術關鍵。合理的通信方式的選擇可以為監控系統的指揮調度、報警處理提供一個穩定、快速的平臺。

車輛監控系統使用GPRS網絡作為傳輸載體。GPRS是一種采用分組交換和傳輸技術的高效率數據傳輸方式。它克服了電路交換速率低、資源利用率差等缺點，最大限度地利用了現有的GSM網絡資源，提高了傳輸速率。相對于短消息方式來說，GPRS服務既提高了質量又降低了使用費用。移動車載終端與監控調度中心之間的通信突發性較強，而每次數據量較小，使用GPRS網絡作為其傳輸載體是目前比較理想的解決方案，GPRS通信主要分為TCP和UDP協議。

TCP和UDP協議同在傳輸層，由于本系統每次傳輸的數據量小而且突發性強，所以采用UDP協議傳輸數據。UDP協議的主要作用是將網絡數據流壓縮成數據報的形式。一個典型的數據報就是一個二進制數據的傳輸單位。UDP協議為不可靠的傳輸協議，不提供數據傳送的保障機制。如果在從發送方到接收方的傳遞過程中出現數據報的丟失，協議本身并不能做出任何檢測或提示。因此，必須在應用層的協議中添加保障信息傳輸可靠性的確認機制。監控中心向終端下傳數據時，要求終端返回接收正確或錯誤的確認信息，監控中心收到正確的確認信息后數據下傳進程才完畢。否則，監控中心將在規定的時間內重發，直到收到正確的確認信息或發送次數標志溢出才終止。

GPRS網絡UDP端口資源十分緊缺，變化很快；UDP由于自身特點，以及GPRS網絡UDP端口資源的有限性，在一段時間沒有數據流量后，端口容易改變，產生的影響就是從服務器中心端向GPRS終端發送數據，GPRS終端接收不到。原因是移動網關從中做了中轉，需要隔一定時間給主機發UDP包來維持該IP和端口號,這樣主機就能主動給GPRS發UDP包，筆者在測試中發現,這個間隔時間很短,約1 min發一次UDP包才能夠維持,再長時間移動網關那邊就要丟失這個端口了,逾期主機想主動發數據給終端,將無法送達。只有GPRS終端設備重新發一個UDP包過去,移動再分配一個中轉IP和端口,才能夠進行雙向通信。為保證端口有效性和數據實時性，終端設備每5 s發送一條包含定位和狀態的數據給服務器。

2.2 基于C＃發送、接收UDP數據包使用的主要方法

(1) UDP數據類。用Visual C＃實現UDP協議，最為常用，也是最為關鍵的類就是UdpClient，UdpClient位于命名空間.Sockets中，Visual C＃發送、接收UDP數據包都是通過UdpClient類的。UdpClient類主要有以下幾個方法，見表1。

（2）接受終端UDP數據。接收UDP數據包使用的是UdpClient中的“Receive”方法。此方法的調用語法如下： public byte ［］ Receive ( ref IPEndPoint remoteEP )；參數remoteEP 是一個IPEndPoint類的實例，它表示網絡中發送此數據包的節點。下面就是通過偵聽本地端口號“8080”來獲取信息代碼：

UdpClient server = new UdpClient (8080);

IPEndPoint receivePoint = new IPEndPoint (IPAddress.Any,0);

byte［］ recData = server.Receive ( ref receivePoint );

recData就是接受到的UDP報文，其中UDP包頭結構如下：源端口16位，目的端口16位，長度 16位，校驗和 16位；上文中闡述了GPRS的UDP端口非常緊缺，隨時會變化，在每次接受到UDP報文后，必須記錄源端口、IP地址。receivePoint參數是引用類型，receive到新的UDP后，receivePoint對象的address和port屬性值就是發送源的IP地址和端口。這個IP和端口未必是真的終端的IP和端口。因為終端上的應用程序綁定本地一個端口(比如是9002)，通過這個端口發送請求給路由器，路由器由此記錄下終端的內網IP和端口(9002),然后路由器分配自己的一個空閑端口(比如是7000)，通過這個端口(7000)發送請求給監控中心。而對于監控中心，它沒有任何關于終端的信息，它要做的只是回信息到路由器的外網IP的7000這個端口。路由器收到發送到其7000端口的數據后會再轉發給終端。

（3）發送UDP數據報。發送UDP數據報使用” Send”方法。“Send”方法的調用語法如下：public int Send ( byte［］ dgram,int bytes,IPEndPoint endPoint )；參數說明：dgram 要發送的 UDP 數據文報（以字節數組表示）。bytes 數據文報中的字節數。 endPoint 一個 IPEndPoint，它表示要將數據文報發送到的主機和端口。返回值是已發送的字節數。下面使用UDPClient發送UDP數據包的具體的調用例子：

string IP =receivePoint.Address.ToString();

int Port = receivePoint.Port;

//receivePoint在上文中描述過，為Receive接受UDP時的引用；

IPEndPoint host = new IPEndPoint (IP,Port)；

UdpClient.Send ( "發送的字節","發送的字節長度",host )；

該代碼實現了對某終端發送UDP報文后的回復。如果需要主動向終端發送報文則需要從數據庫中提取該終端最近一次的IP和端口號，調用該方法發送內容。

2.3 數據封裝和轉存

監控中心與客戶端的數據通信包含2種：一種是上行數據，一種是下行數據。上行數據包含終端匯報車輛的狀態信息，車輛實時信息，車輛語音信息，視頻信息等。下行信息包含對終端的回應，車輛的實時控制等信息。數據種類大約一百多種，可分為20多種格式。針對每種格式定義一個結構進行數據接受和轉存到數據庫，進行數據顯示和分析。終端返回數據一般是結構類型，為保證數據轉換準確和便捷，C#也使用同樣的結構對數據進行接受。上文中UDP報文接受到的正文是byte類型，該byte內容有報文頭和報文類型、校驗部分和正文構成。根據報文類型找到對應的C#結構體structType。利用Marshal.SizeOf(structType);獲取結構體大小，并進行分配空間：IntPtr structPtr = Marshal.AllocHGlobal(size); 然后將byte數組拷到分配好的內存空間： Marshal.Copy(recData,0,structPtr,size); 將內存空間轉換為目標結構體object obj = Marshal.PtrToStructure(structPtr,structType)。為提高系統的實時響應速度，這些數據分為2種處理方式，如非緊急數據直接保存到數據庫，而如果是緊急數據，比如車輛報警數據，車輛控制數據則直接通過Socket連接發送到Web服務器，由Web服務器推送到瀏覽器監控端。

3 結語

本文主要分析了監控系統的GPRS通信技術，詳細介紹了基于GPRS的UDP數據通信流程和方法，實現了C#環境下接受，發送UDP數據報文，協議的定制，數據轉存等關鍵技術。本文解決的問題是監控系統的核心內容，但并不是全部，一個完整的系統還應包括終端硬件設計以及后臺監控軟件、GIS地圖顯示等許多方面。今后，應通過進一步的研究，解決系統其他相關技術。

參考文獻

［1］ LAGRANGE X.GSM網絡與GPRS ［M］.北京:電子工業出版社,2002.

［2］鐘章隊.GPRS通用分組無線業務［M］.北京:人民郵電出版社，2002.

［3］李德仁.論空間信息與移動通信的集成應用［J］.武漢大學學報,2002,27(1):15-17.

［4］楊東凱.北京公交GPS車輛監控系統研究 [J ].電子技術應用,2000(11):59-61.

［5］ ELLIOTT D K.GPS原理與應用［M］.北京:電子工業出版社,2002.

［6］翟戰強.基于GPRS/GPS/GIS 的車輛導航與監控系統 [J ].測繪通報,2004(5):9-11.

［7］何小衛,王愛華,馬躍.基于GPRS的GPS車載終端通信技術研究［J］.計算機應用,2008,28 (11):2952-2954.

［8］王緩緩,李虎,張友純.基于GPS的車輛管理系統的難點及解決方案［J］.計算機應用,2003,23(12):292-294.

［9］明日科技有限公司.Visual C#開發技術大全［M］.北京:人民郵電出版社,2007.

［10］石超，孫保華，魏云飛，等.GPS接收機低噪聲放大器設計［J］.電子科技,2010(3)：56-58.

udp協議篇8

【關鍵詞】網絡測量；時延；測量技術

0 引言

隨著Internet的發展，其規模迅速擴大、網絡業務不斷出現、網絡拓撲結構日益復雜。但具有開放、分布式、不協作、異構等特點的因特網有效管理和控制變得更難。人們致力于在各種情況下尋找和建立連接，主要關注分組向那里發送，而較少關注發送分組的時間。分組到達的時間時延大大影響了因特網的服務質量。要提高網絡服務質量，就要找出存在問題。當前的網絡性能測量評價指標包括：時延、流量、丟包率、吞吐量（帶寬）等。其中網絡時延是最重要、最常用的性能指標。

1 網絡時延的基本概念和時延測量原理

時延是指一個報文或分組從一個網絡的一段傳送到另一端所需的時間。時延由發送時延、傳播時延和處理時延組成。發送時延是節點在發送數據時使數據塊從節點進入傳媒所需要時間，也就是數據塊的第一個比特開始發送算起，到最后一個比特發送完畢所需時間，也稱為傳輸時延。處理時延是指數據在交換節點為存儲轉發而進行必要的處理所花費時間。

2 時延測量中的關鍵技術和影響因素

時延測量首先要消除測量中出現的隨機性。網絡分組的時延是一個隨時間變化的隨機變量，由固定時延和可變時延兩部分構成。固定時延是基本上不變的，它由傳輸時延和傳播時延構成。傳輸時延由分組大小和鏈路的容量決定，一個分組的大小一旦固定，通過的鏈路容量便是固定的，其傳輸時延也是固定的。傳播時延由固定的物理傳輸介質確定并且是固定的。分組時延中的可變時延是由很多因素造成的。它可以分成中間路由器處理時延和排隊等待時延兩部分。對于任何一個分組，中間路由器總要對其進行路由查表以確定其轉發端口，這個時間可以看成是處理時間。同時，中間路由器繁忙可能導致分組排隊等待處理，也需要一段等待時間。處理和等待時間是不固定的，由路由器的具體性能以及鏈路的擁塞狀況而定，是一個隨機變量。所以如果鏈路不出現擁塞，一個分組的最小時延便與該分組的大小成線性關系。分組的時延具有突發性和偶然性，為了能夠使測量結果盡可能地反映網絡的真實情況，可以采用低通濾波的方法來消除隨機性。

其次，對網絡時延的測量，必須保證網絡入口點和出口點時鐘同步。如果時鐘不同步，則時延測量會有很大誤差。網絡中路徑往往是非對稱的，或者即使路由是對稱的但往返具有不同的性能特征。單向時延測量要求嚴格的時鐘同步。GPS時間同步技術是當前比較成熟的并在國際上廣泛使用的時間同步技術。單向時延測量一般要求、成本比較高。在實際的測量中，測量精度不是主要問題。網絡時延通常在數十到數百毫秒范圍內，測量存在幾毫秒的誤差完全可以接受。因此測量方案都采用往返時延，可以避開時鐘同步問題。

網絡時延總是隨著網絡的運行狀況而不斷變化。通過分析，可將影響網絡時延測量的因素歸為兩類：1）網絡本身的性能，即完全獨立于網絡測量方法、僅與網絡本身特性相關的部分；2）測量報文的特定性能，與網絡具體的測量方式密切相關.

目前，基于端到端的網絡時延測量方法，能達到快速準確的目的。這種方法，不是單個設備的時延測量，而是某一段甚至某一跳之間鏈路的時延測量。端到端往返時延的計算時間都在同一臺計算機上，不存在時間同步問題，無需在測量的兩端都安裝測量軟件，只需要固定一個測量點，另一個測量點可以任意選擇，使測量范圍擴充到整個因特網。端到端傳輸優點是鏈路建立后，發送端知道接收設備一定能收到，而且經過中間交換設備時不需要進行存儲轉發，因此時延較小。端到端傳輸缺點是直到接收端收到數據為止，發送端設備一直要參與傳輸。如果網絡時延很長，那么對發送端設備造成很大浪費。端到端傳輸的另一個缺點是如果接收設備關機或故障，那么端到端傳輸不可能實現。在端到端網絡時延測量中，要降低這種缺點帶來的影響，就要選擇合理的測量時段、數據包字長和測量樣本等。

3 網絡時延測量方法

根據網絡時延測量其承載數據包的協議不同，網絡時延測量方法可分為：基于ICMP協議的網絡時延測量。Ping是基于ICMP請求應答報文開發的應用軟件，用來診斷網絡故障，也是用來測量往返時延最常用的工具。Ping工具通過向網絡定地址發送ICMP echo報文，并監聽回應報文，根據回應報文的探測結果，來評估主機路徑的可靠性、往返時延大小等。將報文封裝在ICMP報文中是目前網絡測量工具最常用的方式，但是ICMP報文也是用來進行DOS攻擊的主要方式，因此在許多ICMP協議都被過濾了，可能會完全被阻塞。路由器可以限制ICMP回復的速率來避免被消耗過多的網絡帶寬和路由資源。這意味利用ICMP協議測量時延的結果是不可靠的。基于UDP協議的網絡時延測量。當對方主機或者中間節點過濾掉ICMP報文后，可以使用UDP報文來實現網絡的往返時延測量。UDP報文的實現和ICMP報文較相似，都是無連接的。不同的是UDP協議需要指定一個端口，在實際使用時，可以任選一個端口，當接收方該端口對應的服務不存在時，會立即返回一個“端口不可到達”的IC-MP報文。因此，在使用UDP報文進行測量時，要注意發送方發送一個UDP報文，接收方反饋的不一定是UDP報文，也有可能是ICMP報文，這兩種返回的報文都可以用來計算網絡的時延。此外，UDP協議在實現時要注意其最大報文長度與ICMP報文不同，通常應小于500 Byte。但是將報文封裝在UDP報文中也有疑問。UDP沒有TCP協議所固有的擁塞控制算法，在UDP報文使用達到高峰時，為了減少對TCP流的影響，UDP報文的速率可能會受到限制。

基于TCP協議的網絡時延測量。針對防火墻設置，雖比較復雜，但可適用于測量某些前兩種方法不能工作的特定環境。除了選取合適的承載報文，TCP協議測量網絡時延的難點包括TCP協議發送機制本身。TCP協議為提高傳輸效率，往往不是即時發送報文，而要收集足夠的數據后才發送，可能會產生發送方記錄的發送時間遠遠早于時間發送時間，而使得測量的結果大于實際值的現象。為避免此現象的發生，要求在主動測量時，不但要求發送方在承載的TCP報文中加入PSH標志，此時將立即發送此數據報文而無需等待，同時也要求接收方在反饋該報文時，也必須帶PSH標志。同理，在被動測量時，要注意承載的報文必須是帶有PSH標志的報文，并且對應的反饋報文也必須同樣帶有PSH報文。也可以利用其它協議實現網絡時延的測量。方法基本和UDP或TCP類似，關鍵根據所在網絡設置的具體情況，靈活選擇承載報文，即能在發送方立即發送，而接收方收到后又能立即反饋的報文。

4 結論

本文鏈接：http://www.svtrjb.com/v-141-3373.htmludp協議范文8篇

聲明：本網頁內容由互聯網博主自發貢獻，不代表本站觀點，本站不承擔任何法律責任。天上不會到餡餅，請大家謹防詐騙！若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。

上一篇：ui設計課程總結范文8篇

下一篇：ui設計論文范文8篇

祝福祖國的話09-27