UDP协议在GPRS私网和INTERNET公网的数据交换 |
UDP协议在GPRS私网和INTERNET公网的数据交换 |
2007-09-27 23:43:12, Thu
Post
#1
|
|
猫猫猫 Group: Power Cat Posts: 626 Joined: 2006-12-8 Member No.: 2 |
用一个简图简单解释一下这UDP协议数据交换的问题。
DTU(内网地址10.0.0.1)==(移动内网)====>NAT===(外网公网)===>服务器(公网地址:55.0.0.24) 其中NAT有两个地址,其一是内网地址(比如说是10.0.0.2),其二是外网地址(比如说是1.1.1.1) (移动内网)====>(10.0.0.2)NAT(1.1.1.1)====>(外网公网) 包交换过程如下: DTU发出的数据包是: src:10.0.0.1 dst:55.0.0.24 这个包发给NAT。 以下假设服务器侦听在UDP 2400端口。 其中NAT有两个地址,其一是内网地址(比如说是10.0.0.2),其二是外网地址(比如说是1.1.1.1) (移动内网)====>(10.0.0.2)NAT(1.1.1.1)====>(外网公网) 包交换过程如下: DTU发出的数据包是: src:10.0.0.1:1001 dst:55.0.0.24:2400 这个包发给NAT。 NAT对此包作了转换,进行源地址和端口的替换,发到公网,公网上传的这个包变成了 src:1.1.1.1:1111 dst:55.0.0.24:2400 通过公网到达了服务器55.0.0.24,所以,从服务器看,DTU的地址和端口就是1.1.1.1:1111. 当 服务器过了一段时间(比如说5分钟后)想要主动送数据给DTU时,服务器的UDP SOCKET连接回送的目标是1.1.1.1:1111,实际上是送给 NAT。但是问题此时出现了,NAT已经将这个UDP连接的对应关系给删除了(假设NAT存储UDP连接的超时时间是1分钟),此时NAT收到这个服务器 发来的数据包,将无从决定究竟将其转发给谁。这样导致刚才那台DTU根本收不到服务器端发来的数据!所以如果DTU的心跳包设定的时间太长,比这个NAT 网关的UDP连接超时长的话,服务器送来的数据也会发不到DTU。 |
|
|
2007-09-27 23:43:34, Thu
Post
#2
|
|
猫猫猫 Group: Power Cat Posts: 626 Joined: 2006-12-8 Member No.: 2 |
先简单的说一下TCP与UDP的区别:
1。基于连接与无连接; 2。对系统资源的要求(TCP较多,UDP少); 3。UDP程序结构较简单; 4。流模式与数据报模式 ; 5。TCP保证数据正确性,UDP可能丢包,TCP保证数据顺序,UDP不保证。 另外结合GPRS网络的情况具体的谈一下他们的区别: 1。TCP传输存在一定的延时,大概是1600ms(移动提供),UDP响应速度稍微快一些。 2。TCP包头结构: 源端口16位 目标端口 16位 序列号 32位 回应序号 32位 TCP头长度 4位 reserved 6位 控制代码6位 窗口大小16位 偏移量16位 校验和16位 选项 32位(可选) 这样我们得出了TCP包头的最小长度,为20字节。 UDP包头结构: 源端口16位 目的端口16位 长度 16位 校验和 16位 可见,UDP的包小很多。确实如此,因为UDP是非可靠连接。设计初衷就是尽可能快的将数据包发送出去,所以UDP协议显得非常精简。 3。GPRS网络端口资源,UDP十分紧缺,变化很快;而TCP采用可靠链路传输,不存在端口变化的问题。 在工业场合的应用,一般都需具备以下特点: 1。要求时时传输,但也有一些场合是定时传输,总的来说在整个传输过程中要求服务器中心端和GPRS终端设备能相互的、时时的传输数据。 TCP本身就是可靠链路传输,提供一个时时的双向的传输通道,能很好的满足工业现场传输的要求。但是GPRS网络对TCP链路也存在一个限制:此条链路在长时间(大概20分钟左右,视具体情况而定)没有数据流量,会自动降低此链路的优先级直至强制断开此链路。所以在实际使用中也会采用心跳包(一般是一个字节的数据)来维持此链路。 UDP由于自身特点,以及GPRS网络UDP端口资源的有限性,在一段时间没有数据流量后,端口容易改变,产生的影响就是从服务器中心端向GPRS终端发送数据,GPRS终端接收不到。具体的原因就是移动网关从中作了中转,需要隔一定时间给主机发UDP 包来维持这个IP和端口号,这样主机就能主动给GPRS发UDP包了并且我在测试中发现,这个间隔时间很短,我在1多分钟发一次UDP包才能够维持,但是再长可能移动网关那边就要丢失这个端口了,此时如果主机想主动发数据给GPRS,那肯定是不行的了,只有GPRS终端设备再发一个UDP包过去,移动重新给你分配一个中转IP和端口,才能够进行双向通讯。 2。要求数据的丢包率较小。有些工业场合,例如电力、水务抄表,环保监测等等,不容许传输过程中的数据丢失或者最大限度的要求数据的可靠性。 从这一点来看,很显然在无线数据传输过程中,TCP比UDP更能保证数据的完整性、可靠性,存在更小的丢包率。在实际测试中也是如此。以厦门桑荣科技有限公司提供的GPRS终端设备为例:TCP的在千分之9,UDP的在千分之17左右。 3。要求降低费用。目前有很大部分GPRS设备的应用都是取代前期无线数传电台,除了使用范围外,其考虑的主要问题就是费用。能降低费用当然都是大家最愿意接受的。和费用直接相关的就是流量了,流量低,费用就低了。 虽然TCP本身的包头要比UDP多,但是UDP在实际应用中往往需要维护双向通道,就必须要通过大量的心跳包数据来维护端口资源。总的比较起来,UDP 的实际流量要比TCP还要大。很多使用者在初期的时候并不了解UDP需要大量心跳包来维持端口资源这个问题,往往都认为UDP要比TCP更节省流量,实际上这里存在着一个误区。 4。在某些特定的应用场合,例如一些银行的时时交互系统,对响应速度要求很高,此时数据传输频率较快,不需要大量心跳包维持UDP端口资源,采用UDP就比较有利了。 5。在目前的1:N的传输模式中,既有多个GPRS终端设备往一个服务器中心传输数据,此时采用UDP会比TCP要好的多,因为UDP耗用更少的系统资源。但是在实际应用中却发现,很多用户还是采用TCP的传输方式,建立二级中心1:A(1:N),即每一个分中心对应N/A台设备,独立处理数据,再统一将数据传送到主中心。这样既能保证了传输过程中采用了TCP的传输协议,又能很好处理了中心服务器的多链路的系统耗用的问题。 总的来说,TCP/IP协议更能满足目前各行业对远程数据传输的要求,它提供更稳定更便利的传输通道,很好的满足了远程数据传输的要求。 |
|
|
Lo-Fi Version | Time is now: 2024-11-2 03:46 |