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

udp協(xié)議范文8篇

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

udp協(xié)議

udp協(xié)議篇1

關鍵詞：UDP協(xié)議；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適用于網絡環(huán)境中的進程間通信，它已成為當前許多操作系統(tǒng)的網絡API，也是網絡操作系統(tǒng)中必不可少的基礎功能。隨著Linux操作系統(tǒng)和Internet的不斷發(fā)展，Linux網絡環(huán)境下尤其是基于UDP的socket通信技術仍廣為注目。文章介紹了socket的編程原理，并通過一個Java編寫的客戶/服務器程序，描述了網絡中基于UDP的不同主機上的兩個進程之間的socket通信機制。

1 Socket通信機制

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

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

2 UDP協(xié)議的工作原理

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

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

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

3 UDP套接字的通信過程

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

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

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

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

4 數(shù)據(jù)報通信實例

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

1) 服務器端程序

public class Server_Th

{ boolean m_q=true;

public void serverWork() throea IOException

{DatagramSocket ds=new DatagramSocket(2000)

//創(chuàng)建端口號為2000的數(shù)據(jù)報套接字

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

while(m_q)

{ byte buf[ ]=new byte[256];//創(chuàng)建緩沖區(qū)

DatagramPacket packet=new DatagramPacket (buf, buflength); //創(chuàng)建接收數(shù)據(jù)報對象

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

String dString=null;

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

{in.close();

m_q=false;

dString=”Good Morning!”;}

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

inetAddress address=packet.getAddress();

//得到客戶端IP地址

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

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

//構造要發(fā)送數(shù)據(jù)報

ds.send(packet);//發(fā)送數(shù)據(jù)報

}

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( );

//創(chuàng)建套接字對象

byte buf[ ]=new byte[256];

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

//服務器IP地址

DatagramPacket packet=new DatagramPacket(buf,buf. Length,address,2000);//創(chuàng)建要發(fā)送的數(shù)據(jù)報對象

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

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

//創(chuàng)建要接收的數(shù)據(jù)報對象

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

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

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

//取得數(shù)據(jù)報中的數(shù)據(jù)并顯示

Socket.close();//關閉socket

}}

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

5 小結

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

參考文獻：

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

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

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

udp協(xié)議篇2

關鍵詞：arm；linux；交叉編譯環(huán)境；udp協(xié)議；重發(fā)機制；重發(fā)次數(shù)

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

1 研究背景

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

2 硬件平臺介紹

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

2.1 et-s3c2440開發(fā)板簡介

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

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

2.2 實驗相關電路說明

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

3 系統(tǒng)軟件平臺的構建

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

3.1 交叉編譯環(huán)境的構建

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

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

3.2 bootloader的移植

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

3.3 linux內核移植

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

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

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

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

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

3.4 根文件系統(tǒng)的制作

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

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

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

4 arm-linux環(huán)境下的udp協(xié)議通信實驗

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

4.1 udp協(xié)議套接字編程基礎

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

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

4.2 上位機報文結構及重發(fā)機制分析

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

表1 上位機報文結構

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

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

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

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

4.4 對上位機重發(fā)次數(shù)的研究

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

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

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

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

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

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

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

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

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

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

5 結論與展望

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

參考文獻：

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

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

[3] 劉暢,彭楚武.linux下的udp協(xié)議編程[j].儀表技術,2006(1).

udp協(xié)議篇3

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

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

1.UDP協(xié)議本質

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

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

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

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

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

2.實現(xiàn)案例

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

步驟如下：

（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任務及消息循環(huán)

主要負責響應觸摸屏消息，在屏幕上畫圖，然后將數(shù)據(jù)傳輸?shù)接嬎銠C上。

對觸摸屏消息的處理和鍵盤消息類似，其消息類型pMsg->Message為OSM_TOUCH_SCREEN，消息參數(shù)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 //觸摸屏移動

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

3.解決方案

3.1 建立Socket

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

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

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

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

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

3.2 配置Socket

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

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

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

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

3.3 建立連接

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

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

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

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

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

int listen（int sockfd，int backlog）；

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

3.4 傳輸數(shù)據(jù)

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

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

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

3.5 傳輸結束

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

udp協(xié)議篇4

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

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

1研究背景

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

2影響因素分析

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

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

2）模塊間的數(shù)據(jù)通信具有突發(fā)性，通信數(shù)據(jù)量不規(guī)則、不連續(xù)。比較適合采用報文轉發(fā)方式傳輸；

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

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

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

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

3方案設計

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

3.1 本機進程間通信

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

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

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

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

共享內存的實現(xiàn)方式設計如圖1所示。

3.2 UDP協(xié)議二次封裝

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

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

3.3配置文件

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

4測試驗證

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

5結論

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

參考文獻

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

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

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

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

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

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

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

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

udp協(xié)議篇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上面臨的安全威脅，有效地保證數(shù)據(jù)的安全傳輸。隨著Internet的不斷發(fā)展，采用IPSec技術實現(xiàn)利用互聯(lián)網建立VPN網絡，越來越被眾多大中型企業(yè)所青睞，IPSec已逐漸成為構建VPN的主流技術。網絡地址轉換（NAT）技術[2] 在內部網絡中使用內部私有IP地址，通過NAT將每個從內部網絡發(fā)出的數(shù)據(jù)包的私有地址翻譯成合法的公用IP地址在Internet上使用，支持多臺主機共享全局IP地址，常見于接入設備和防火墻中，能很好地解決IPv4網絡地址枯竭的問題，同時具有屏蔽內部網絡的作用。

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

2 問題描述

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

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

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

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

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

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

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

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

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

3 協(xié)同工作的方法

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

3.1 RSIP方法

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

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

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

3.2 “6to4”方法

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

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

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

3.3 專用NAT方法

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

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

3.4 UDP封裝方法

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

圖1 ESP傳輸模式UDP封裝數(shù)據(jù)格式變化圖

圖2 ESP隧道模式UDP封裝數(shù)據(jù)格式變化圖

UDP封裝法的實現(xiàn)需要對IKE協(xié)商進行改進來配合。

1) IKE協(xié)商第一階段

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

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

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

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

圖3UDP封裝后IKE包和ESP包的區(qū)別

2) IKE協(xié)商第二階段

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

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

3.5 TCP封裝方法

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

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

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

4 結束語

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

參考文獻：

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

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

[3] 譚興烈,張世雄.IPSec和NAT協(xié)同工作技術研究[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協(xié)議篇6

關鍵詞： TCP/IP；TCP協(xié)議； UDP協(xié)議；Winsock；遠程監(jiān)測

中圖分類號：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

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

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

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

1 TCP和UDP測試軟件的設計

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

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

使用WinSock控件時，首先要確定的是使用TCP還是UDP協(xié)議，它們之間主要的區(qū)別在于連接狀態(tài)。

1.1 TCP測試軟件設計

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

圖1 TCP網絡程序工作原理

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

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

Winsock1.Protocol=sckTCPProtocol

1.1.1服務器端程序

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

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

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）監(jiān)聽連接請求。監(jiān)聽方法在控件中被調用，每個連接請求到來時，代碼會測試看它的索引（Index）是否為0（監(jiān)聽控件的值），根據(jù)其值是否為0執(zhí)行不同的操作。代碼如下：

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

Dim i As Long

If Index = 0 Then '主Winsock——Winsock（0）發(fā)生消息

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 "已經達到最大用戶數(shù)！"， 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）服務器端發(fā)送數(shù)據(jù)。若選中發(fā)送回車符，則在代碼中增加發(fā)送回車符，若選中發(fā)送換行符，則在代碼中增加發(fā)送換行符。若是廣播，則逐個發(fā)送，否則需要選擇發(fā)送目標。主要代碼如下：

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 '十六進制發(fā)送

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 "請選擇發(fā)送目標！"，， "提示："

End If

End Sub

4）服務器端接收數(shù)據(jù)，數(shù)據(jù)到達后，先調用TCP_Server控件的getdata方法，將接收的數(shù)據(jù)以vbstring數(shù)據(jù)類型，存放在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

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

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

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）客戶端發(fā)送數(shù)據(jù)。若選中發(fā)送回車符，則在代碼中增加發(fā)送回車符，若選中發(fā)送換行符，則在代碼中增加發(fā)送換行符。主要代碼如下：

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 '十六進制發(fā)送

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）客戶端接收數(shù)據(jù)，先調用TCP_Client控件的getdata方法，將接收的數(shù)據(jù)以vbstring數(shù)據(jù)類型存放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

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

1.2 UDP測試軟件

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

1）設置RemoteHost屬性；

2）設置RemotePort屬性；

3）申請Bind方法。

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

使用UDP協(xié)議傳送數(shù)據(jù)，首先設置客戶計算機的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方法來開始信息發(fā)送，客戶計算機則可在其DataArrial事件中使用方法GetData來獲取發(fā)送的信息，發(fā)送和接收數(shù)據(jù)的代碼與TCP通信的代碼類似。UDP測試程序運行后的界面如圖4所示。

圖4 UDP協(xié)議測試軟件運行界面

2 結束語

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

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

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

參考文獻：

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

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

udp協(xié)議篇7

關鍵詞：車輛監(jiān)控系統(tǒng)； 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 引言

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

1 系統(tǒng)結構

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

2 系統(tǒng)關鍵技術

2.1 GPRS通信技術及UDP數(shù)據(jù)傳輸協(xié)議

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

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

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

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

2.2 基于C＃發(fā)送、接收UDP數(shù)據(jù)包使用的主要方法

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

（2）接受終端UDP數(shù)據(jù)。接收UDP數(shù)據(jù)包使用的是UdpClient中的“Receive”方法。此方法的調用語法如下： public byte ［］ Receive ( ref IPEndPoint remoteEP )；參數(shù)remoteEP 是一個IPEndPoint類的實例，它表示網絡中發(fā)送此數(shù)據(jù)包的節(jié)點。下面就是通過偵聽本地端口號“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參數(shù)是引用類型，receive到新的UDP后，receivePoint對象的address和port屬性值就是發(fā)送源的IP地址和端口。這個IP和端口未必是真的終端的IP和端口。因為終端上的應用程序綁定本地一個端口(比如是9002)，通過這個端口發(fā)送請求給路由器，路由器由此記錄下終端的內網IP和端口(9002),然后路由器分配自己的一個空閑端口(比如是7000)，通過這個端口(7000)發(fā)送請求給監(jiān)控中心。而對于監(jiān)控中心，它沒有任何關于終端的信息，它要做的只是回信息到路由器的外網IP的7000這個端口。路由器收到發(fā)送到其7000端口的數(shù)據(jù)后會再轉發(fā)給終端。

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

string IP =receivePoint.Address.ToString();

int Port = receivePoint.Port;

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

IPEndPoint host = new IPEndPoint (IP,Port)；

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

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

2.3 數(shù)據(jù)封裝和轉存

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

3 結語

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

參考文獻

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

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

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

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

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

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

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

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

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

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

udp協(xié)議篇8

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

0 引言

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

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

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

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

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

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

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

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

3 網絡時延測量方法

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

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

4 結論

本文鏈接：http://www.lbgj202.com/v-141-3373.htmludp協(xié)議范文8篇

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

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

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

商務調查報告11-22

清明節(jié)發(fā)朋友圈的詩句08-23