Toad的博客

简介

随着功能日益强大的计算机进入人们家庭，扩展这些计算机的功能使之与Internet连接成为日益迫切的要求。不幸的是，这个扩展在链路层帧（link level framing）、地址分配(address assignment)、路由选择、认证以及性能等方面暴露出很多很复杂的问题。在写本文档时所有这些领域的工作还在进行。本文档描述一种方法，这种方法已经被用来提高低速（300-900bps）串行链路上的TCP/IP的性能。

这里推荐的压缩方法与Thinwire-II协议（参考文献[5]）描述的思想是相似的。但是本协议压缩的效率更高(压缩后TCP/IP头部为3个字节，而Thinwire-II为13个字节)，并且实现起来既高效又简单(Unix 实现需要250行C代码，在20MHz MC68020中压缩或者解压一个数据包平均需要90µs(_170指令集)。

该压缩专门针对TCP/IP数据包（注1），作者研究了UDP/IP数据包的压缩但发现这种情况极少出现，并且没有足够的datagram-to-datagram一致性来进行很好的压缩（例如，名字服务器查询）或者高层协议头部淹没了UDP/IP头部的开销（例如，Sun’s RPC/NFS）。作者还研究了分开压缩数据报的IP和TCP部分，但因为压缩后头部平均大小比原来增加50%，并且压缩和解压缩的代码加倍，因而被否决了。

 问题

人们可能期望通过串行IP链路从家中访问从“终端”击键（type）类型连接(如telnet, rlogin, xterm)到批量数据传输（例如ftp, smtp, nntp）的Internet服务。头部压缩的动机就是出于对良好的交互响应的需要求。也就是说协议的链路效率（line efficiency）为数据报中header占header+data的百分比。如果高效的批量数据传输是我们的目标，,通过把数据报的尺寸扩大到足够大总是可以使链路效率接近100%。

对人的因素（Human-factor）的研究（参考文献[15]）结果表明交互操作在低层反馈(feed-back)（字符回显,character echo）花费超过100-200ms时被认为是“差的”。协议头部从以下几方面与这个极端交互：

（1）如果链路速度太慢，也许不可能把头部和数据都放在一个200ms的窗口中：每敲击一个键产生一个字符就要导致发送一个41字节的TCP/IP数据包和接收一个41字节的反馈(echo)。链路速度至少达到 4000 bps 以便在200ms内能够处理这82 个字节的数据包。

点击下载：[PDF]RFC1144_低速串行链路上的TCPIP头部压缩_中文版