rfcrfc2508.txt

本程序为在linux下实现FTP传输文件的实现

组织：中国互动出版网（http://www.china-pub.com/）
RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：[e-mail]
译者： 李超（licc_li  [e-mail]）
译文发布时间：2001-5-23
版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须
保留本文档的翻译及版权信息。


Network Working Group                                          S. Casner
Request for Comments: 2508                                 Cisco Systems
Category: Standards Track                                    V. Jacobson
                                                           Cisco Systems
February 1999


低速串行链路下IP/UDP/RTP数据包头的压缩
（RFC 2508 Compressing IP/UDP/RTP Headers for Low-Speed Serial Links）

本备忘录的状态
  本文档讲述了一种Internet社区的Internet标准跟踪协议，它需要进一步进行讨论和建议以
得到改进。请参考最新版的“Internet正式协议标准” (STD1)来获得本协议的标准化程度
和状态。本备忘录的发布不受任何限制。
版权声明
   Copyright (C) The Internet Society (1999).  All Rights Reserved.
摘要
本文描述了一种对IP/UDP/RTP数据报头进行压缩的方法，它可以降低在低速串行链路上
的网络开销。多数情况下，三个头可压缩到2-4字节。
请赐教并将您的建议发送到工作组邮件列表[e-mail]或直接给作者。
本文中的关键字“必须”，“必须不”，“要求的”，“应该”，“不应该”，“会”，“不会”，
“建议”，“或许”，“可选的”在 RFC 2119 中解释。   
目录
本备忘录的状态	1
版权声明	1
摘要	1
1. 介绍	2
2. 设想和折中	2
2.1. 单工与全双工	3
2.2. 分片与分层	3
3.压缩算法	3
3.1.基本概念	3
3.2 RTP数据包头压缩	4
3.3协议	5
3.4. RTCP控制包压缩	12
3.5.非RTP UDP包压缩	13
4.与分片的交互	13
5.压缩协商	13
6.致谢	14
7.参考文献	14
8. 安全性考虑	14
9.作者地址	15
10.版权声明	15
1. 介绍
   随着实时传输协议(RTP)成为正式的RFC[1]发行，人们对于利用RTP实现不同的网络音视
频应用程序间互操作的兴趣也日益增长。然而，我们也注意到，当使用低速链路如14.4Kb/s
或28.8Kb/s拨号时，12字节的RTP头对于仅有20字节的负载而言开销实在太大。（为了减少
头占用的字节，一些已经在类似环境下存在的应用通常使用自定义的协议，而这样做的代价
就是削减了RTP相关的功能。）
   事实上，正如在TCP中已经取得巨大成功，也可通过压缩技术来令IP/UDP/RTP包头变小。
这时，压缩可以针对于RTP头（在端到端应用中），或者IP，UDP，RTP的组合头（在Link-by-Link
应用中）。将40字节的组合头一起进行压缩比仅压缩12字节的RTP头更具实际效果，因为两
种情况下的结果大小均为约2-4字节。同时，由于延迟和丢失率都很低，对Link-by-Link应
用进行压缩性能上也更好。因此我们在这里定义的方法就是针对Link-by-link应用下
IP/UDP/RTP头进行组合压缩。
   本文定义的压缩方案可应用于IPv4包、IPv6包或封装了多个IP头的包。为了能同时在IPv6
和IPv4下使用，这里定义的IP/UDP/RTP压缩符合[3]中规定的通用压缩框架。该框架把TCP
和非TCP定义为IP之上的两个传输类。本规范将IP/UDP/TCP从非TCP类中抽取出来创建为第三
类。
2. 设想和折中
   本压缩方案的目标是，在不发送UDP校验和的情况下，将大多数包的IP/UDP/RTP头压缩到
2个字节，在带校验和时则压缩到4个字节。这一方案的提出主要是受使用14.4kb/s和
28.8kb/s拨号调制解调器发送音视频时遇到的相关问题所引起。这些链路提供全双工通信，
所以协议利用了这点，尽管协议在用于单工链路时可能性能会有所下降。该方案在本地链路
上往返时间(RTT)很低，从而实现性能最高。
   为了降低低速链路下的延迟，除了在第四节中确定了分片和压缩中可能使用的一些交互
外，本规范并未提出大型数据包的分片和占先策略。分片方案可能会单独定义并与本压缩方
案配合使用。
   应该注意到，实现的简单性是评价压缩方案的一个重要因素。通信服务器可能要用一个
处理器支持多达100个拨号调制解调器的数据压缩。因此，如下的考虑都是比较恰当的，即
在设计阶段为了实现简单而牺牲一些通用性，或者在设计上灵活通用但为了简单性可对设计
进行子集化。通过在压缩和解压器之间用更复杂的模型通信改变头字段还可以达成更好的压
缩效果，但其复杂性却是没必要的。下一节将讨论这里列出的一些折中方案。
2.1. 单工与全双工
   在没有其它限制的情况下，单工链路上的压缩方案应成为首选。但为防止错误发生，单
工链路上的操作需要用一个含有压缩状态信息的未压缩包头进行周期性的刷新。如果明显的
错误信号可以返回，则恢复延迟也可以实质性地缩短，无错误情况的开销也会降低。为了实
现这些性能的优化，本规范包括了一个可逆向发送的明显错误指示。
   在单工链路中，可以使用周期性刷新来取代。解压器一旦侦测到错误存在于某个特定的
流中，它可以简单地放弃该流中所有的包直到接收到一个未压缩的头为止，然后继续解压。
其致命弱点在于可能要在恢复解压前要放弃大量的包。周期性刷新的方法在[3]的3.3节中进
行描述，它应用于单工链路的IP/UDP/RTP压缩，或者应用于其它非TCP包流的高延迟链路。
2.2. 分片与分层
   在低速链路上发送大型数据包所需时间而导致的延迟对于单向音频应用不算什么大问
题，因为接收方可以适应延迟变动。但对于交互式的交谈，最小端到端延迟是非常关键的。
对大的，非实时数据包进行分片以允许小的实时包在分片间隙进行传送可以降低这种延迟。
   本规范只处理压缩，并且假定，如果包括分片，也将被处理为一个单独层。将分片和压
缩按这种方式进行集成并不可取，因为一旦如此，在没有必要或不可能进行分片的情况下，
连压缩都不能使用。类似地，应该避免预留协议的任何需求。除了要求链路层提供一些包类
型码，一个包长度指示和良好的错误检测外，该压缩方案可独立于任何其它机制而应用在本
地链路的两端。
   相反，单独对IP/UDP和RTP层进行压缩丢失了太多的压缩效率，这些效率可以通过将它们
一起对待而得到。由于相同的函数可以应用于所有层，实现跨越这些协议层边界的方案是恰
当的。
3.压缩算法
   本文定义的压缩算法主要利用了RFC 1144[2]描述的TCP/IP头压缩的设计。读者可以参考
该RFC获取更多的关于对包头进行压缩的基本动机和通用原理。
3.1.基本概念
   对TCP头压缩的研究发现，IP和TCP头有一半的字节在整个连接期间保持不变，这正是降
低数据率的两个要素中的首要因素。因此，在发送一次未压缩头之后，可以将这些字段从其
后的压缩头中除去。其余的压缩来自对变化字段进行区分编码以减少长度，以及在通常情况
下根据包长度计算变化而完全删除掉变化字段。这一长度由链路层协议指示。
   对于RTP头的压缩也可以采用一些相同的技术。不过最大的收获在于人们发现，尽管每个
包中总有几个字节要发生变化，但包与包之间的区别却是恒定的，因此二次差分为0。在会
话期间，通过维护压缩与解压器共享的未压缩头与一次差分序列，所需通信的便只有二次差
分为0的指示了。在这种情况下，如果不考虑任何信息丢失，则解压器在收到一个压缩包后
可以通过将一次差分结果加到保存的未压缩头来重建原始包头。象TCP/IP头压缩为多个同时
的TCP连接维护一个共享状态一样，IP/UDP/RTP压缩也应该为多个会话环境维护状态。一个
会话环境是由IP源地址和目的地址，UDP源端口和目的端口，以及RTP的SSRC字段定义。解压
器在实现时可以对这些字段使用哈希函数来检索存储的会话环境列表。压缩包携带一个称为
会话环境标识符或者CID的小整数来指示该包应该解释到哪个环境中。解压方可以使用CID
直接在存储的环境列表中来进行检索。
   由于RTP压缩是无损压缩，它可应用于任何可从中受益的UDP通信。当然最可能的例子就
是RTP包，不过也可以使用试探法来判断一个包是否为RTP包，因为即便试探法给出的答案是
错的也不会造成什么损害。这样做需要对所有的UDP包或者至少对偶数端口号的包(见3.4节)
执行压缩算法。
   为了避免将来无谓地重试，大多数压缩器在实现时都要维护包流的一个“拒绝缓存”来
记录那些多次作为RTP包尝试而压缩失败的包。压缩失败往往意味着潜在的RTP包头中一些在
多数时间应保持恒定字段却发生了变化，如负载类型字段。即便其它类似的字段都保持不变，
为了避免耗尽所有的可用会话环境，一个SSRC字段不断改变的包流也应放入拒绝缓存。拒绝
缓存可通过源IP地址和目的IP地址以及UDP端口对进行索引，而SSRC字段因为可能发生变化
不能用来作为索引。当RTP压缩失败，IP和UDP头仍然可以被压缩。分片后不是初始片的IP
包和长度不够容纳一个完整UDP头的包都不能作为FULL_HEADER发送。另外，没有容纳至少12
字节UDP数据的包也不能用于创建RTP环境。如果这样的包作为FULL_HEADER包发送，它后面
可以跟随COMPRESSED_UDP包但不能跟随COMPRESSED_RTP包。
3.2 RTP数据包头压缩
   在IPv4包头中只有总长度，包ID和校验和字段会发生改变。因为在链路层已经提供了长
度，这里总长度是冗余的，同时由于本压缩方案必须依靠链路层实现良好的错误检测（如PPP
的CRC[4]），头校验和也可以省略掉。于是只剩下了包ID，而在假定没有IP分片的情况下它
也无参加通信。不过为了保持无损压缩，包ID的变化也将被传输。对每个包而言，包ID通常
每次加1或者一个很小的整数值。（有些系统中包ID的增量为交换的字节数，这对压缩效率
有一些轻微的影响。）而IPv6包头既没有包ID字段，也没有头校验和字段，只有负载长度字
段会发生变化。
   由于在IP层和链路层均有相应字段，UDP头中的长度字段也是冗余的。如果选择不产生UDP
校验和则UDP的校验和字段为常数0。否则必须对校验和进行交互通信以保证无损压缩。一个
重要原则就是为需要的应用程序维护端到端的错误检测。
   在RTP头中，作为特定环境标识的一部分，给定的环境的SSRC标识符是恒定不变的。对大
多数包而言，只有顺序号和时间戳是因包而异的。如果没有包丢失或者乱序，顺序号应按步
进值1逐包改变。对音频包，时间戳应按采样周期增加。对于视频，时间戳在每帧的第一个
包是发生改变，而在后面该帧的其它包中保持不变。如果每个视频帧只占据一个包，且视频
帧按照恒定的速率产生，则帧与帧之间时间戳的变化也是恒定的。
注意到每当这种情况出现，顺序号和时间戳字段的二次差分均为0，所以下一个包头的相应
字段值可通过前一个未压缩包头的该字段加上存在会话环境一次差分值得到。当二次差分不
为0时，变化量通常也要远小于字段中所有位的数目，所以可通过对新的一次差分进行编码
并传输该编码来达到压缩的目的，不用传输绝对值。
   一个音频会话峰(talkspurt)中M位将在第一个包中设置，而一个视频帧中M位在最后一个
包中设置。如果它作为一个常量字段则每次变化都要发送整个RTP头，如此会造成压缩效率
明显下降。因此，压缩头中的一位将明确地携带M位。如果包通过RTP混合器流动，特别是音
频数据，则CSRC列表和CC记数将发生改变。但CSRC列表将在会话峰期间保持不变，所以它只
需在发生变化时才发送。
3.3协议
   压缩协议必须维护一个状态牢靠的压缩器和解压器的共享信息集合。对每个IP/UDP/RTP
包流都有一个单独的通过源地址IP，目的地址IP，UDP端口对和RTP SSRC字段组合定义的会
话环境。要维护的会话环境数目可通过双方协商而定。每个环境通过一个8位或者16位的标
识符来标识，具体范围要根据协商的环境数量决定，所以最大值为65536。未压缩和压缩的
包都必须携带环境ID和一个4位的用来检测包通信中丢失的顺序号。每个环境都有自己的顺
序号空间，所以单个包的丢失只会影响到一个环境。
   每个环境共享的信息包括如下项目
?	完整的IP, UDP和RTP头，对最后一个由压缩器发送或者解压器重建的包，可能还
包括CSRC表。
?	IPv4 ID字段的一次差分结果，当收到环境中的一个未压缩IP头时初始化为1，每
次收到一个压缩包中的delta IPv4 ID字段时更新。
?	RTP时间戳字段的一次差分结果，当收到环境中的一个未压缩IP头时初始化为0，
每次收到一个压缩包中的delta RTP时间戳字段时更新。
?	最后一个4位顺序号，用来检测双方通信时的包丢失情况。
?	IPv6（见[3]）UDP包的非差分编码当前产生号。对于IPv4，如果没有使用下面定
义的COMPRESSED_NON_TCP包类型，则产生号可设置为0。
?	一个经过双方协商，可选的环境相关的delta编码表(见3.3.4节)。
   为了在不同的压缩和解压器形式下进行通信，本协议依靠链路层为除IPv4和IPv6外的四
种新的包格式提供指示：
      FULL_HEADER – 传送未压缩IP头和任何用来在解压方为特定环境建立未压缩头状态
的后续头和数据。FULL_HEADER包也携带了8或16位的会话环境标识符和4位的顺序号用来建
立双方的同步。格式见3.3.1节。
      COMPRESSED_UDP – 传送压缩到6字节或更少字节(如禁用UDP校验和则通常为2字节)
的IP和UDP头，后面是任何未压缩形式的后续头(可能为RTP)和数据。当RTP头的常量字段有
所不同时才使用包类型。RTP包头包括一个会变化的SSRC字段值，所以可能重定义会话环境。
其格式在3.3.3节定义。
      COMPRESSED_RTP – 表示RTP头和IP及UDP头一起压缩。该头的大小可以是2个字节，或
者当需要传送变化时更多一些。当二次差分值(至少在通常的常量字段)为0时使用包类型。
它包括delta编码，它是为了能在未压缩RTP头发送后并当改变发生时对于那些变化字段建立
一次差分队列。其格式在3.3.2中定义。
      CONTEXT_STATE – 一种由解压器发送给压缩器的特殊包，用来传输已经或者可能已经
失去同步的环境ID。该包仅通过点到点链路发送，所以它不需要IP头。其格式在3.3.5中定
义。
   当本压缩方案作为通用头压缩框架[3]的一部分用于IPv6时，还可使用另一种包类型：
      COMPRESSED_NON_TCP –无须进行差分编码传输[3]定义的压缩IP/UDP包。如果用于
IPv4，为了能携带IPv4 ID字段，它比前面所讲的COMPRESSED_UDP要多用1到2个字节。而IPv6
没有ID字段，这种非差分压缩在包丢失时更有弹性。
   在PPP协议[4]中为这些包格式分配代码应由IANA决定。
3.3.1.  FULL_HEADER (未压缩) 包格式
   此处定义的FULL_HEADER和[3]中所给出的定义是一致的。在那里有关于各种方案的
完整设计细节。它在IPv4中通常就是一个IP头，后面接着是一个UDP头和UDP负载（可能为一