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

    越来越多的嵌入式应用增加了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字节即可。这时，发送端必须停止发送，而代之以对对侧窗口的探测，探其窗口的重新开放。

    因为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协议。