rfc2508.txt

很多RFC的中文文档

多个压缩包到达，解压器应该为每个收到的压缩包重新传输CONTEXT_STATE包，但应该限制
重传输率以避免反向通道的溢出。
   当链路中出现错误时，链路层通常将放弃损坏的包，但可以提供一个错误指示。在相同
环境的另一个包传输前可能会消耗一些时间，然后该包将被解压器发现乱序而抛弃，造成至
少两个包丢失。链路提供显示地错误指示是为了快速恢复，解压器可以有选择地发送一个咨
询CONTEXT_STATE包为最近的一个或多个活动环境（没必要为所有环境）列出最近有效的顺
序号和generation号。对于给定的环境，如果压缩器还没有发送更高顺序号的压缩包，并且
generation号和当前号一致，则不需要任何校正动作。否则压缩器就得选择标志环境为无效
以便下一个包以FULL_HEADER或COMPRESSED_NON_TCP模式(如果generation号不一致则需要
FULL_HEADER)发送。不过可以注意到，如果链路层RTT时间比包间隙很大，这时已经有多个
不同环境的包沿链路发送了，这使得在压缩器收到CONTEXT_STATE包时顺序号可能已经增大。
其结果就是有些环境被没必要地变为无效，导致额外地消耗了带宽。
   下图所示为CONTEXT_STATE包的格式。第一个字节是类型码，允许CONTEXT_STATE包类型
被[3]中定义的通用压缩框架中的多个压缩方案共享。包其余部分的内容取决于具体的压缩
方案。在本文的IP/UDP/RTP压缩方案中，其余部分组织为一个块的列表，可以为多个环境指
示状态，前面为一个字节表示的块数目。
   IP/UDP/RTP压缩方案中使用了两个类型码值。1表示采用8位会话环境:
             0   1   2   3   4   5   6   7
           +---+---+---+---+---+---+---+---+
           | 1 = IP/UDP/RTP 如CID为8位	   |
           +---+---+---+---+---+---+---+---+
           |         	会话计数           |
           +---+---+---+---+---+---+---+---+
           +---+---+---+---+---+---+---+---+
           |       		会话环境ID  	   |
           +---+---+---+---+---+---+---+---+
           | I | 0 | 0 | 0 |    顺序号	   |
           +---+---+---+---+---+---+---+---+
           | 0 | 0 |       generation      |
           +---+---+---+---+---+---+---+---+
                          ...
           +---+---+---+---+---+---+---+---+
           |       		会话环境 ID        |
           +---+---+---+---+---+---+---+---+
           | I | 0 | 0 | 0 |    顺序号	   |
           +---+---+---+---+---+---+---+---+
           | 0 | 0 |       generation      |
           +---+---+---+---+---+---+---+---+
   	2表示使用16位的会话环境ID。
会话环境ID按照网络字节顺序发送（最高位优先）：
             0   1   2   3   4   5   6   7
           +---+---+---+---+---+---+---+---+
           | 2 = IP/UDP/RTP 如CID为16位	   |
           +---+---+---+---+---+---+---+---+
           |         会话数目	           |
           +---+---+---+---+---+---+---+---+
           +---+---+---+---+---+---+---+---+
           |                               |
           +       会话环境ID              +
           |                               |
           +---+---+---+---+---+---+---+---+
           | I | 0 | 0 | 0 |    顺序号     |
           +---+---+---+---+---+---+---+---+
           | 0 | 0 |       generation      |
           +---+---+---+---+---+---+---+---+
                          ...
           +---+---+---+---+---+---+---+---+
           |                               |
           +       会话环境ID              +
           |                               |
           +---+---+---+---+---+---+---+---+
           | I | 0 | 0 | 0 |    顺序号     |
           +---+---+---+---+---+---+---+---+
           | 0 | 0 |       generation      |
           +---+---+---+---+---+---+---+---+
   在标志为无效，要发送COMPRESSED_NON_TCP包或FULL_HEADER的环境中，"I"位应设置为1。
如果I为0，则环境处于咨询状态。I位设为0表示、在链路错误指示后要发送环境咨询状态。
由于CONTEXT_STATE包本身也可能丢失，所以允许对一个或多个块重传输。但希望只有在接
收到另一个包时才触发重传输，如果链路几乎空闲时，可用一个相对较长的计时器来触发重
传输(如定为1秒)。如果给定环境的块被重传输，它可能与用来刷新环境的FULL_HEADER或
COMPRESSED_NON_TCP错过。这时压缩器可以忽略错误指示。
   在需要传输UDP校验和的情况下，解压器可以尝试使用[3]的10.1节描述的"twice"算法。
在该算法中，假设delta值与丢失包和随后接收的一个包相同则delta要多次应用。校验和匹
配表示成功。对于这里定义的方案，顺序号的区别说明了delta必须要应用的次数。注意，
一个不正确的正指示可能会带来一些小风险。即便这里"twice"算法应用成功，也建议发送
一个FULL_HEADER或COMPRESSED_NON_TCP包。
   有些错误可能无法检测出来，比如一排丢失了16个包且链路层没有提供错误指示。在这
种情况下解压器将产生无效的包。如果UDP校验和正在传输，接收方可能会检测到无效包并
且丢弃他们，但是接收方无法通知解压器。因此，建议解压器周期性地验证UDP校验和，如
每16个包验证一次。如果发现错误，它应将环境置为无效并且用一个CONTEXT_STATE包来通
知压缩器。
3.4. RTCP控制包压缩
   按照RTP协议规定，数据通过偶数端口发送，而RTCP包通过下一个奇数号端口进行发送，
因此可以为RTP和RTCP包分别制定压缩方案。对于RTCP，压缩同时针对包头和数据本身，即
不同包类型的内容。SR和RR RTCP包中的数字内容不好压缩，但SDES包中的文本信息可以压
缩到一个屏蔽位表示每个存在并已压缩的项(用于对SDES NOTE项进行计时并允许端系统为
计算间隔而测量平均RTCP包大小)。
   然而由于一些原因（尽管压缩应该应用于IP和UDP头），在本压缩方案中并不对RTCP头和
数据进行压缩。RTP协议规范建议应该按比例决定RTCP包间隙，以便所有会话中参与者占用
的RTCP总带宽不超过5%的会话总带宽，所以压缩RTCP并没有太多的好处。压缩SDES项会造成
每个环境ID要存储的共享状态明显增加。并且，当通过一个RTP混合器发送多个源的SDES信
息时，为了允许压缩就必须为每个SSRC标识符维护一个单独的RTCP会话环境。在一个超过255
个参与者的会话中，即使只有一个参与者发送数据也会造成环境缓存中大量的垃圾数据。假
设RTCP包作为COMPRESSED_UDP形式发送，即使不对其进行压缩，多数情况下它所占压缩链路
的比重也不超过5%。鉴于非压缩RTCP包消耗的带宽不超过会话总带宽的5%，对于一个长度为
90字节的典型RTCP包，只要RTP数据包负载长度至少为108字节，则RTCP所占用的压缩带宽比
率也会不超过5%。如果RTP负载长度比较小，该比率会有所提高，但对于负载大小为37字节
的RTP包而言，该比例仍不会超过7%。如果RTP负载数据包很大，则压缩RTCP所占的比例小于
非压缩RTCP（如对1000字节的包该比例为4%）。
3.5.非RTP UDP包压缩
   如前所述，COMPRESSED_UDP包可用来压缩未携带RTP信息的UDP包。UDP之头后的任何数据
都不太可能象在RTP头中相应字段一样有恒定不变的值。特别地，SSRC字段就很可能发生改
变。因此为了避免当SSRC字段改变时用光环境槽，很有必要明了这些非RTP的UDP包流（由于
该字段是用来标识特定RTP环境的一部分）。每一个这样的流都可以拥有一个环境，但编码
器只在环境中设置一个标志来表示SSRC字段的变化可被忽略，且将发送COMPRESSED_UDP包而
非COMPRESSED_RTP包。
4.与分片的交互
   为了减少延迟，在连接RTP头时使用分片的方法对大的非实时包进行分割，以便允许小的
实时包能利用分割间隙进行发送。由于这样的交错发送会改变解压器的接收到的包顺序，导
致错误出现，我们在此均假定这些大数据包对于压缩器到解压器的通道是旁路的。头压缩对
大数据包而言并不重要，因为其开销所占比重较小。
   如果有些来自RTP会话环境的包被选中参加分片(主要取决于大小)，而另一些不参加分
片，则可能造成乱序的现象出现。这将导致压缩效率的下降，因为在顺序空间中这些被分割
的大包会被当作是丢失。但是，由于RTP顺序号将在接收方被正确重建且允许应用程序进行
重排序，所以暂时的乱序也不会造成过于严重的问题。就象链路层自己能检测到的链路错误
一样，分片机制使用顺序信息检测到的链路错误可以通过一个CONTEXT_STATE消息指示给压
缩器。
   环境ID字节位于COMPRESSED_RTP头的最前面，如果这样可行并经过协商，可以把该字节
分派给分片层。由于压缩器可以强制分配环境ID，其值可设置为和分片层中的环境标识符一
致。
5.压缩协商
   在特定链路上使用IP/UDP/RTP压缩属于链路层协议的功能。所以要为具体协议单独定义
协商方式，如为PPP[4]。下面是可能要协商的项：
?	环境ID的大小。
?	环境中包头栈的最大值。
?	一个对delta值解码的环境相关表。
6.致谢
   很多朋友都为本压缩方案的设计和相关问题的解决付出了努力。1996年3月，Scott 
Petrack在落山矶的AVT工作组发起了关于RTP头压缩的讨论。Carsten Bormann开发了低速链
路上带传输控制的压缩体系结构，同时对于本文描述的方案也作出了一些特别贡献。David 
Oran独立开发了一个基于本文类似思想的Note，并建议使用PPP多链路协议进行分片。Mikael 
Degermark在把本方案同IPv6压缩框架进行集成方面作出了贡献。
7.参考文献
   [1] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP:
       A Transport Protocol for real-time applications", RFC 1889,
       January 1996.
   [2] Jacobson, V., "TCP/IP Compression for Low-Speed Serial Links",
       RFC 1144, February 1990.
   [3] Degermark, M., Nordgren, B. and S. Pink, "Header Compression for
       IPv6", RFC 2507, February 1999.
   [4] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC
       1661, July 1994.
   [5] Hoffman, D., Fernando, G., Goyal, V. and M. Civanlar, "RTP
       Payload Format for MPEG1/MPEG2 Video", RFC 2250, January 1998.
8.安全性考虑
   由于加密会消除本压缩方案所试图实现的冗余性，所以为了在低带宽链路上完成操作我们考
虑可能要放弃加密。不过对于那些需要压缩数据而不是包头的情况，RTP已经规定了另一种可选
的加密方法，它只压缩RTP负载而将包头保持明文。这样压缩依然可以使用。
   一个有问题的或是恶意的压缩器可能使解压器重组的包同原始包不一致却有有效的IP, IDP，
RTP头，甚至有效的UDP校验和。这样的破坏可通过端到端认证和完整性机制（它不会受到压缩的
影响）检测出来。认证头中的恒定部分可通过[3]所描述的方法进行压缩。
   本协议在发送CONTEXT_STATE控制包时没有执行任何认证。有权访问压缩器和解压器之间链路
的攻击者可以通过插入错误的包使压缩效率下降，甚至导致链路拥塞。不过他们还可以通过许多
其他方式来破坏通信。如果使用的压缩技术会造成接收端计算负荷不均衡，系统就有潜在拒绝服
务式攻击的威胁。攻击者可通过插入病态报文造成解压缩复杂性增加，导致接收端过载和处理其
它流的效率降低。然而，本压缩方案并未显示出有任何明显的波动性。
对本协议的安全性回顾并没有发现任何多余的安全性考虑。
9.作者地址
   Stephen L. Casner
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA 95134-1706
   United States
   EMail: [e-mail]
   Van Jacobson
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA 95134-1706
   United States
   EMail: [e-mail]
10.版权声明
   Copyright (C) The Internet Society (1999).  All Rights Reserved.
   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.
   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.
   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
RFC2508  Compressing IP/UDP/RTP Headers for Low-Speed Serial Links     低速串行链
路下IP/UDP/RTP数据包头的压缩


1
RFC文档中文翻译计划