单片机系统中TCP通信问题分析 - 8位机嵌入式TCP通信速度的研究

　　2 单片机系统中TCP通信问题分析

　　TCP协议是TCP／IP协议簇的核心，也是最复杂的协议。但由于其独特的自动检错和重发机制，实现了数据的可靠通信，但也正是由于其复杂性，在8 位机上实现TCP协议通信耗时就比较多，传输速率低下。TCP协议的数据通信过程，以客户机为例进行分析。图2是典型的采集系统TCP数据通信的时间序列图。在建立连接后，由客户机向服务器发送数据。假设此时客户机的启始序列号为100，每次固定发送100字的样数据。服务器负责接受该数据，但不下发任何送数据，只确认所接收的数据，其启始序列号为50。对于单片机系统，由于其处理速度和内存资源的局限，通常的处理流程如图3。

　　由于服务器（一般为装有windows系统的微机或工业计算机）并不是收到数据就直接发送确认，而是继续等待接受序列中的其他数据。这就会经常触发服务器的接受延时的确认算法，这将导致剩下的数据不能在200 ms内发送。对于高速交互的采样系统而言，这将产生明显的时延。Host Requirements RFC申明TCP必须实现Nagle算法，但必须为用户提供一种方法来关闭该算法在某个连接上的执行。该算法要求TCP连接上最多只能有一个未被确认的未完成的小分组，在该分组的确认到达之前不能发送其他的小分组。实际使用Sniffer监听软件也得到同样的结果，在接收到下位机的数据包后，上位机延时 200 ms后，发送确认包，其传输速度为10 packet／s，实际网络利用率不足1％。由图3可见，只要提高服务器确认发送的速度，就可以提高通信的速度。对于本系统采用33M的主频（C051F 单片机）发送一个分组（1 024 B）和接受一个确认分组（60 B）总用时为3～3.5 ms，关闭Nagle算法后，使用Sniffer监听分析数据包，系统上位机在收到数据包后，立即发送确认包，期间只有0.3 ms左右的网络延时，系统速率提高到设定的20 ms发送一次采样数据，即100 packet／s，系统利用率提高为为原来的10倍。

　　然而对于有些应用场合，每次采样的数据量并不大（小于100 B），采用关闭Nagle 算法来提高传输率是不理想的，因为这样增加了网络上传输的分组的数量，同时增大了客户机（下位机）处理这些多出来的分组的时间消耗，降低了系统利用率，增大了传输出错率，大幅度的减少了持续传输时间。实验中，当采用高频单片机（100M主频），将数据通信速率提高到1 000 packet／s，发现传输错误的数据包达到5％，同时传输持续时间由原来的大于48 h不间断，减少为不足2 h，系统利用率也只有不到2％，同时已无法继续提高传输速度（由硬件条件限制）。为解决这个问题，同过分析具体TCP通信的各环节对时间的消耗过程，寻求在已有的硬件基础上，通过软件来解决问题。

　　首先是数据分组打包。这里的耗时与要打包的数据量和主频有关。为了便于计算，以下都用最简单的MCS-8051单片机为例进行分析。对于发送100 B的数据，外界晶振为12M的51单片机，其一个机器周期为1μs。典型的打包代码（包括TCP包和IP包）的执行总周期约为2 200个机器周期（具体大小与编写软件所使用的语言和编译器有关），用时为2.2 ms。

　　其次是数据备份。TCP协议需要超时重发，因而备份已发出而未收到确认的数据分组是必要的。这里的耗时与数据量和主频以及数据本备份的存储器类型有关。对于100 B数据和40 B的头部（包括TCP包的20 B头部和IP包的20 B头部），总共140 B的数据备份，采用外部存储器，典型代码的执行周期为1 130个机器周期，用时为1.13 ms。

　　再次是发送数据分组。这里的耗时也与数据量和主频有关。典型发送分组代码的执行总周期为2 200个机器周期，耗时为2.2 ms。

　　最后确认分组。这里要做的工作有：检测接口芯片，判断分组类型，拆分IP包，拆分TCP包，典型代码的执行周期为4 130个机器周期，用时4.13 ms。

　　总共用时9.66 ms，其中接受确认分组耗时最多，占总用时的42.8％。