关于上Internet网和TCP/IP协议的实用技术

2006-05-07 15:50:05来源: 电子产品世界

    越来越多的嵌入式应用增加了Internet网络功能,但是,嵌入式应用的编程人员对于上网和TCP/IP协议比较生疏,由于需要了解的技术内容量很多,因此很难短时间从中找出有用的关键部分,本文打算对新手给以实用性的指导。

    TCP/IP包括一系列协议

    首先,应理解我们所说的TCP/IP是统指一系列的协议,其中包括TCP(传输控制协议)、UDP(用户数据报协议)、IP(Internet协议)还有一些更低层的连接层协议,如Ethernet(以太网协议)等。

    用TCP协议传输的所谓数据实际指的是数据流中的段,而用UDP协议传输的所谓数据指的是数据包。IP则是TCP、UDP(传输层协议)之下的网络层协议。IP所提供的是非可靠的、无连接能力的、向指定主机地址的包传送的协议。IP包也叫数据报。数据报可能出现丢失、重复或次序紊乱等现象,所以,它是非可靠的协议。但是,IP 协议的最大好处是,IP数据报独立于低层的网络技术,所以它是一种通用的数据传送方法。

    TCP和UDP都属于IP上层的传输层协议。二者都使用端口号作为送往主机的解码地址。端口号由各个具体应用所确定,同时使用多个端口号能完成“一机多网”的操作。每个UDP数据包和TCP数据段中都含源端口号和目的端口号。为接收远端的输入而等待着执行接入操作的主机是所谓的服务器,发起接入请求的主机就是所谓的客户机。

    服务器为最常服务的应用如FTP(文件传输协议)、Email和HTTP,分配了知名的端口号并对其进行持续地监听。作为传输源的客户机通常选择随机的端口号,并向已分配了知名端口号的服务器发出接入请求。客户应用所取的端口号应大于1024,因1024以下的端口号是为知名应用而预留的。

    UDP为维护数据包的整体性应尽最大可能地选用校验和。UDP数据包的可靠性是与IP相当的;所以,远端主机收到的数据包未能保证其正确的顺序。但是由于TCP所传数据流应用了顺序号和应答措施,可以发现数据的丢失、段的失序和对传输错误的排除,所以TCP协议提供的是数据流的可靠传输。

    相对于UDP,TCP所获得的可靠性是以其复杂性为代价的。TCP面向接入,而UDP是无连接能力的。这意味着,UDP客户机向指定的远端主机发送数据包时,并未事先确知对方是做好了接收数据的准备的。因此就会发生某一客户机发给一个主机,而此主机事先并未把此客户机列入其目标端口号而加以监听。这种情况,只要远端主机运行的是TCP/IP堆栈,并能够将输入的UDP数据报送到ICMP层进行处理的话,此主机将返回一个ICMP(Internet控制信息协议)错误。也就是说,如果远端主机不能接收发去的UDP数据的话,客户机还可以获得一定的提示的;但是,这种提示是有限的,因为客户机并不确知数据的结果。

    然而也正是由于,UDP没有保证可靠性的机制,没有其他的关卡机制,UDP才得以实现全速地发送(即充分发挥物理通信设备的速度)。如果使用低速的处理器,因UDP的开销很小,会导致其传输率比高出TCP很多;但对于高速处理器,二者的差别不会很大。又,UDP没有点对点接入的要求,所以可以实现“一对多点”,“多对多点”的广播和多点播发信息。作为使用UDP实行信息广播的例子,就是在DHCP协议(动态主机控制协议)中,当系统引导的时候,发出广播信息,通知所有DHCP服务器向系统提交网络配置信息。

    TCP原理

    TCP是面向接入的。在将数据发向远方主机之前,必须先建立TCP接入。这意味着只有在两端都实现了TCP接入后,才可以进行点-点之间的数据交换。建立TCP的点-点连接,包括“三重握手”的操作:

    1、 客户机向服务器发出同步段(SYN),请求接入。

    2、 服务器向客户机发出同步-应答段(SYN--ACK)。一方面作为对客户请求接入的响应,一方面要求客户端也进行接入。

    3、 客户机向服务器再发出应答段(ACK)。作为对服务器所发请求接入的响应。

    同样,包含数据的每一个TCP段也都应该取得对端返回的应答段(ACK),作为握手信号来保证数据被可靠地接收。应答段本身不再需要应答,避免应答陷入无穷的嵌套。客户机请求对端接入时,要随机地选送一个初始序号。在第二步中建立TCP接入时,服务器也要选送一个自己的初始序号,并用这个号作为对客户机送来序号的应答号返送给客户机。这样,每一个TCP段中都包含一个序号,并以这个序号作为数据流的定位器,而返给客户机的应答号则表达所发来的数据已经妥收。

    消除传输中的错误,仰赖持续跟踪已发出数据段的应答是否返回。在设定的时间段内,如果未收到该段的应答则应重发。如果还是未收到应答,则适当增加间隔时间再次重发。在总的极限时间段内一直不能等到应答返回,则本次接入失效不能再用,并应将出错情况及时通知应用程序。每次成功的接入,只要本端和对端没有执行过关闭操作,就一直是接通的。要想知道对端是否还处于接入状态,唯一的方法就是发数据进行探测。关闭TCP接入共有4步:

    1、 客户机向服务器发出关闭段(FIN)。此时,客户机不能再向远方服务器发送数据,但是仍可接收数据。

    2、 服务器向客户机发出关闭--应答段。此时,服务器还可以向客户机发送数据,即接入处于“半关闭”状态。

    3、 服务器向客户机发出关闭段(FIN),关闭本侧的接入。仍可接收数据。一方面作为客户请求接入的响应,一方面要求客户端也须接入。此时,服务器不能再发送数据。

    4、 客户机为响应服务器的关闭,向服务器发出关闭--应答段。

    至此,接入已从两端拆除完毕。客户机不可紧接着再次请求恢复刚刚关闭的接入。需要有一个叫做2MSL间歇时间,避免前后两次接入产生牵连。对于娱乐网,这个间歇时间约取2分钟,因为即使在接入关闭之后,客户系统仍有大量的资源可供使用,间歇2分钟后从新接入对客户不造成影响。然而,对于嵌入式系统,2分钟的间歇时间无异于万古千年,再说,接入关闭之后可用于填补间歇时间的可用资源又极为有限。所以,嵌入式TCP/IP的2MSL时间应该尽可能地减下来。

    TCP通过数据窗的滑动来调整数据的传送率。只要使用TCP,就不可能在所建立的点-点接入上实现数据的阵发式全速传送,原因在于数据流中被插入了有些随机性的应答环节,它改变着传送率。每一个TCP段中,服务器都将其当前可用于接收的数据容量(即TCP数据窗,不计应答)通知对方,作为对端掌握发送的极限。这样做的好处是,发送端是在明了接收端当前确实处理能力的基础上向网络派送数据,对于网络的交通有效性也是有积极意义的。

    现在看一下数据流与TCP数据窗的关系和窗是如何滑动的,见图1。图中按数据发送时的序号标注数据流,图中可以看到窗的大小和当前窗的位置,窗外左侧的1、2、3是已经可靠发送完毕的段,窗外右侧的10、11是尚未发送的段;只有窗内才是当前获得发送资格和正等待着应答的各段,设4号段等到了应答,因发送圆满而退出窗口,相应地当前窗向右滑动一段使10号成为有资格发送的段。如果各段的应答都十分顺利的话,有可能窗内的各段都处于等待应答状态。所以,窗口的大小和完成应答的快慢影响着数据传送的速度。接收端可以酌情暂时关闭窗口,只要通知出去的接收数据容量为0字节即可。这时,发送端必须停止发送,而代之以对对侧窗口的探测,探其窗口的重新开放。t1.gif (5862 字节)

    因为TCP发送的是数据流,所以无法区分10个128字节的段与一个10*1288字节的段。为此,需要在TCP之上附加一个协议,以便将数据流断开,使之成为可识别的数据部分。譬如标记出开始、终止和数据类型等等。常用的FTP、Telnet、和Email(SMTP)都是在TCP之上附加了自己的协议头的。

    究竟是UPD还是TCP?

    至此可以明白,相对于UDP,TCP的可靠性是以许多复杂措施及由此而增加的开销为代价换来的。嵌入式的设计者应牢牢记住:UDP本身无连接能力和不可靠,但对传输率却无阻碍;而TCP提供可靠的数据流,但处理的开销较大,使传输率有所降低。

    关于UDP的不可靠这一点,也不可简单化以致有所误解,真正使用UDP时,经常是要在应用层增加提高UDP可靠性的代码,譬如给数据添加顺序的标记,使在应用层上能发现数据的丢失和乱序,从而加以更正。嵌入式的设计者会面临许多具体的特殊要求,如代码不能长、或传输率是关键、或可靠性最重要等等,需要很好地加以分析和折衷。

    有时选用UDP或TCP的效果有明显的不同。对于楼宇散布各处的温度和湿度传感器的每秒一次地集中监控来说,选用UDP或TCP都关系不大。对于独立的、又不太重要的传感器监控,选用UDP也就够了。而进入数据库的传感器监控结果,因其可靠性要求,则需用TCP。由于微处理器的能力有限,不采用UDP就难以上网的,势必只能迁就于UDP;如会议电视和IP音响。实时播放的电视和音响传输率是关键,也得选用UDP,因为若选用TCP会因可靠性要求而重新传数据,因此可能错过了应播出的时间反而引起混乱;再有,对于这种发与收应严格保持同步、宁缺勿烂的应用还应在UDP上面的应用层增加数据顺序性的约束。对于数据监控系统,因传输可靠性的要求很高,照例应采用TCP。Web和Email也照例采用的是TCP。

    嵌入式应用可以从标准的网络协议获益很多,用最少的资源实现最广泛的远方监控,仅仅是一个方面。限于本文的目标,仅仅只能简要地涉及与Internet有关的TCO/IP协议。

 

编辑: 引用地址:http://www.eeworld.com.cn/designarticles/network/200605/2947.html
本网站转载的所有的文章、图片、音频视频文件等资料的版权归版权所有人所有,本站采用的非本站原创文章及图片等内容无法一一联系确认版权者。如果本网所选内容的文章作者及编辑认为其作品不宜公开自由传播,或不应无偿使用,请及时通过电子邮件或电话通知我们,以迅速采取适当措施,避免给双方造成不必要的经济损失。
论坛活动 E手掌握
微信扫一扫加关注
论坛活动 E手掌握
芯片资讯 锐利解读
微信扫一扫加关注
芯片资讯 锐利解读
推荐阅读
全部

小广播

About Us 关于我们 客户服务 联系方式 器件索引 网站地图 最新更新 手机版

站点相关: 安防电子 医疗电子 工业控制

北京市海淀区知春路23号集成电路设计园量子银座1305 电话:(010)82350740 邮编:100191

电子工程世界版权所有 京ICP证060456号 京ICP备10001474号 电信业务审批[2006]字第258号函 京公海网安备110108001534 Copyright © 2005-2016 EEWORLD.com.cn, Inc. All rights reserved