RFC2757-Long Thin Networks-chifire自译本(7)

 

 

 

-          允许延迟敏感的低速通信使用小包。

 

-          降低头的负载（通常的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	Yes                (For IPv4, TCP and Mobile IP, PPP)
SNOOP plus SACK	In limited use	IN           WD (for SACK)	Yes
Fast retransmit/fast recovery	RFC 2581 (PS)	WD	Yes (should be  there already)
Transaction/TCP	RFC 1644      (Experimental)	WD     (simultaneously  needed on Server)	No
Estimating Slow Start Threshold(ssthresh)	NA	WS	No
Delayed Duplicate Acknowledgements	Not stable	WR            IN (for notifications)	When stable
Class-based Queuing on End Systems	NA	WD	When stable
Explicit Congestion	RFC 2481 (EXP)	WD	Yes
Notification		NI
TCP Control Block Interdependence	RFC 2140  (Informational)	WD	Yes(Track research)

 

 

       上面表中所述的各种优化，只有SNOOP加SACK和延迟重复确认（Delayed duplicate acknowledgement）是当前建议在无线网络下使用的。其它的还处于讨论阶段甚至有些不是给无线应用使用的。更多的可用性将吸引研究团体的注意及分析。

 

       在上述机制中，只有头压缩（Header Compression，IP及TCP上用的）和“SNOOP加SACK”在有IPSec的场合下停止使用。

 

Montenegro, et al.           Informational                     [Page 34]

 

6 结论（Conclusion）

 

       在回顾了远程窄带网的不可预知及问题重重的特性之后，我们知道优化其传输是一项令人生畏的任务。我们也将现存相关的研究做了些介绍。基于本文观点，我们也建议建立远程窄带网（LTNs）的实现机制。

 

7 感谢（Acknowledgements）

 

       作者万分感谢IETF tcpsat和tcpimpl工作组。下列成员也提供了有价值的意见：

Mark Allman (NASA)，Vern Paxson (ACIRI)，Raphi Rom (Technion/Sun)，

Charlie Perkins (Nokia)，Peter Stark (Phone.com)。

 

8 安全考虑（Security Considerations）

 

       本文讨论和建议的机制是早期公布的。在原始讨论中有关安全方面的讨论也在此列出，其中几种已经在本文中讨论过了，另外，将与我们建议机制相关的有价值的议题列一下，以供参考：

 

   -  更大的初始化窗尺寸（Larger Initial TCP Window Size）

 

      未知安全议题（No known security issues ）[RFC2414, RFC2581]。

 

   -  头压缩（Header Compression）

 

可能会受某些拒绝服务攻击（denial of service attacks）。但是任何有能力施展攻击的攻击者需要具有比他控制能力更强的攻击[IPHC, IPHC-RTP]。

     

 

   -  拥塞控制，快中继/快恢复（Congestion Control, Fast Retransmit/Fast Recovery）

 

攻击者可能会迫使TCP连接挂起，或者，更做些更严重、更有攻击性的行为。后者可能导致某些网络的拥塞崩溃（congestion collapse）[RFC2581]。

 

   -  显式拥塞通知（Explicit Congestion Notification）

             

       　看来并没有提高网络的抵抗攻击能力。相反，它可能因产生应答迟缓的流标识和与TCP不兼容的拥塞控制[ECN]而降低网络的这方面能力。

     

 

 

 

Montenegro, et al.           Informational                     [Page 35]