- 允许延迟敏感的低速通信使用小包。
- 降低头的负载（通常的TCP段尺寸是512）。移动IP通道中IPv4/TCP的头负载可以从11.7%降到不足1%。
- 降低有损耗连接的丢包率（因为采用了更小的压缩包进行交互）。
Van Jacobson (VJ)头压缩[RFC1144]中所描述的TCP头压缩是被建议的标准方式，已经得到了广泛的应用。它使用TCP超时（timeout）来检测压缩方与解压缩方间的同步丢包（loss）。[IPHC]包含了一个显式请求，用以处理无压缩头传输时，允许不必等待TCP超时（或进入拥塞避免程序）就进行重新同步。
建议：实现[IPHC]，特别是因为它与IP-in-IP [RFC2003]和移动IP的最小化封装（Minimal Encapsulation [RFC2004]），而且它与损耗连接的TCP头压缩及记录包的连接也有关系。支持端对端协议（PPP）的设备应当实现[IPHC-PPP]。VJ头压缩可以有选择地实现，因为它是广泛应用的建议标准。然而，它只应在可靠的LTN网络操作中应用，因为即使是一个位的错误都可能导致整个TCP窗口被关闭，而且还会引发代价昂贵的慢启动恢复。
4.12 有效负载压缩（Payload Compression）
压缩IP的有效荷载也是个好办法。“IP有效荷载压缩协议”（IP Payload Compression Protocol －IPComp，[IPPCP]）中定义了常用压缩算法用于任意IP段负载的框架。IP负载压缩是位置比较适合的优化方式，在IP级安全体系中，它是必要的，因为安全体系将IP负载转换成随机的位流（bitstream），使通常应用的链路层压缩机制由于无法获得足够的信息，从而无法对其进行处理。
然而，许多IP负载其实已经被压缩过了（如图像、音频、视频及被上传的ZIP文件等），或者已经在IP层就加过密了（如SSL/TLS等）。这些负载将不能再次压缩，从而限制了本优化所能带来的益处。
HTTP/1.1已经支持消息体（message body）的压缩了。例如，使用zlib压缩相对应的指示为：“Content-Encoding：deflate”和“Accept-Encoding：deflate” [HTTP- PERF]。
Montenegro, et al. Informational [Page 31]
HTTP-NG看来可以支持HTTP级的资源压缩，可以为通常一些可被压缩的MIME型文件（如text/html）提供相应的支持，这就降低了对IPComp的需求。但如果IPComp比HTTP-NG配置的更快的话，用IPComp压缩HTML和MIME头将是有益的。
通常，应用级压缩会做得比IPComp要好些，因为它们有机会使用针对指定被压缩数据的压缩字典。
建议：IPComp可以有选择地被实现。从现在开始关注HTTP-NG的标准化及应用。建议使用zlib实现HTTP/1.1的压缩。
4.13 TCP控制块的内部依赖性（TCP Control Block Interdependence [Touch97]）
TCP维护着每个连接的信息，如连接状态、当前往返周期、拥塞控制或最大段尺寸。TCP能在两个连接的连接之间共享信息，或者当与一主机保持旧连接的情况下，与该主机的新建连接能够提高性能。该原理可以很容易地被扩展到LAN系统，而不仅仅是一个给定系统。[Touch97]描述了两种情形下的缓冲更新（cache update）。
W-WAN设备的用户会经常向同一个或同一组服务器请求连接。例如，为了阅读邮件或初始化与其它服务器的连接，这些设备可能被配置成总使用相同的email服务器或WWW代理服务器。该建议的好处在于它减轻了应用程序优化传输层的负担。为了提高TCP连接的性能，该机制只需要在无线设备处做些变更。
一般而论，该方案能在不增加实现代价的情况下提高连接装备的活力（dynamism）。
建议：尽管HTTP/1.1的持久稳固连接可能也能起到相同效果，本机制仍是建议采用的。 其它的应用（甚至是HTTP/1.0）会觉得它有用。请继续加以关注，尤其是在“拥塞管理器，Congestion Manager[CM]”方面做的工作，该管理器将会将协议间和应用间共享信息的概念推广开来，使之更适合网络的状况。
Montenegro, et al. Informational [Page 32]
5 推荐优化摘要（Summary of Recommended Optimizations）
下面的表格是我们在前面描述的各种值得关注的建议摘要。
第一列，“建议的稳定性”（Stability of the Proposal）讨论机制的成熟性。某些建议在IETF内部被跟踪。IETF建议要么是Internet草稿（Internet Drafts，I-D），要么是请求注释（Request for Comments，RFC），以前的是预备版本。有几种类型的RFC：草稿标准（Draft Standards，DS）是标准的跟踪文件，含有比建议标准（Proposed Standard，PS）更多的信息，该文件仍会被修订。情报性或实验性的RFC不能算是标准。其它建议由于太小或不为人所知，及没有机会在实际应用已经被隔绝。
“基于….实现”（Implemented at），提示了哪些建议在实现过程中，必须修改TCP会话。传统的服务器不可以被修改，所以该列表明是否要两个节点处都要实现，或者只实现一处，即移动设备和中间介质节点。用到了如下符号：WS（无线发送方，wireless sender，即移动设备的TCP发送操作必须被修改）；WR（无线接收方，wireless receiver，即移动设备TCP接收方必须被修改）；WD（无线设备，wireless device，即在移动设备处的修改没有指明TCP发送方或接收方）；IN（中间介质节点，intermediate node）以及NI（网络构造，infrastructure）。这些实体的概念在正文的1.1节（网络结构）中已经描述。NA简单表示“不可应用”（not applicable）。
“建议”（Recommendation）栏写着我们的建议态度。某些机制已被认可采用；某些机制还需要论证及研究；某些是不建议采用的。
|
建议名称（Name） |
建议的稳定性 （Stability of the Proposal） |
基于…实现 （Implemented at） |
建议否 （Recommendation） |
|
Increased Initial Window |
RFC 2581 (PS) |
WS |
Yes (initial_window=2) |
|
Disable delayed ACKs during slow start |
NA |
WR |
When stable |
|
Byte countinginstead of ACK counting |
NA |
WS |
NO |
Montenegro, et al. Informational [Page 33]
（续上页）
|
建议名称（Name） |
建议的稳定性 （Stability of the Proposal） |
基于…实现 （Implemented at） |
建议否 （Recommendation） |
|
TCP Header Compression for PPP |
RFC 1144 (PS) |
WD IN |
Yes (see 4.11) |
|
IP Payload Compression (IPComp) |
RFC 2393 (PS) |
WD (simultaneously needed on Server) |
Yes |
|
Header Compression |
RFC 2507 (PS), RFC 2509 (PS) |
WD IN |
最新评论共有 0 位网友发表了评论
查看所有评论
发表评论
热点关注
|
