Network Working Group S. Dawkins
Request for Comments: 3150 G. Montenegro
BCP: 48 M . Kojo
Category: Best Current Practice V. Magret
July 2001
Network Working Group S. Dawkins
Request for Comments: 3150 G. Montenegro
BCP: 48 M . Kojo
Category: Best Current Practice V. Magret
July 2001
End-to-end Performance Implications of Slow Links
慢速链接对端到端性能的影响
Status of this Memo
本备忘录的状况
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
本文件规定了互联网社区的最佳现行做法，并要求进行讨论和提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
Abstract
摘要
This document makes performance-related recommendations for users of network paths that traverse "very low bit-rate" links.
本文档为穿越“极低比特率”链路的网络路径的用户提供与性能相关的建议。
"Very low bit-rate" implies "slower than we would like". This recommendation may be useful in any network where hosts can saturate available bandwidth, but the design space for this recommendation explicitly includes connections that traverse 56 Kb/second modem links or 4.8 Kb/second wireless access links - both of which are widely deployed.
“极低比特率”意味着“比我们想要的慢”。本建议可能适用于主机可能会使可用带宽饱和的任何网络，但本建议的设计空间明确包括穿越56 Kb/秒调制解调器链路或4.8 Kb/秒无线接入链路的连接，这两种链路都已广泛部署。
This document discusses general-purpose mechanisms. Where application-specific mechanisms can outperform the relevant general-purpose mechanism, we point this out and explain why.
本文件讨论通用机制。如果特定于应用程序的机制可以优于相关的通用机制，我们将指出这一点并解释原因。
This document has some recommendations in common with RFC 2689, "Providing integrated services over low-bitrate links", especially in areas like header compression. This document focuses more on traditional data applications for which "best-effort delivery" is appropriate.
本文档有一些与RFC 2689相同的建议，“在低比特率链路上提供集成服务”，特别是在诸如报头压缩等领域。本文档更侧重于“尽力而为”适用的传统数据应用程序。
Table of Contents
目录
1.0 Introduction ................................................. 2
2.0 Description of Optimizations ................................. 3
2.1 Header Compression Alternatives ...................... 3
2.2 Payload Compression Alternatives ..................... 5
2.3 Choosing MTU sizes ................................... 5
2.4 Interactions with TCP Congestion Control [RFC2581] ... 6
2.5 TCP Buffer Auto-tuning ............................... 9
2.6 Small Window Effects ................................. 10
3.0 Summary of Recommended Optimizations ......................... 10
4.0 Topics For Further Work ...................................... 12
5.0 Security Considerations ...................................... 12
6.0 IANA Considerations .......................................... 13
7.0 Acknowledgements ............................................. 13
8.0 References ................................................... 13
Authors' Addresses ............................................... 16
Full Copyright Statement ......................................... 17
1.0 Introduction ................................................. 2
2.0 Description of Optimizations ................................. 3
2.1 Header Compression Alternatives ...................... 3
2.2 Payload Compression Alternatives ..................... 5
2.3 Choosing MTU sizes ................................... 5
2.4 Interactions with TCP Congestion Control [RFC2581] ... 6
2.5 TCP Buffer Auto-tuning ............................... 9
2.6 Small Window Effects ................................. 10
3.0 Summary of Recommended Optimizations ......................... 10
4.0 Topics For Further Work ...................................... 12
5.0 Security Considerations ...................................... 12
6.0 IANA Considerations .......................................... 13
7.0 Acknowledgements ............................................. 13
8.0 References ................................................... 13
Authors' Addresses ............................................... 16
Full Copyright Statement ......................................... 17
The Internet protocol stack was designed to operate in a wide range of link speeds, and has met this design goal with only a limited number of enhancements (for example, the use of TCP window scaling as described in "TCP Extensions for High Performance" [RFC1323] for very-high-bandwidth connections).
Internet协议栈被设计为在广泛的链路速度范围内运行，并且仅通过有限数量的增强（例如，使用“高性能TCP扩展”[RFC1323]中描述的TCP窗口扩展来实现非常高的带宽连接）就达到了这一设计目标。
Pre-World Wide Web application protocols tended to be either interactive applications sending very little data (e.g., Telnet) or bulk transfer applications that did not require interactive response (e.g., File Transfer Protocol, Network News). The World Wide Web has given us traffic that is both interactive and often "bulky", including images, sound, and video.
前万维网应用程序协议往往是发送很少数据的交互式应用程序（如Telnet）或不需要交互式响应的批量传输应用程序（如文件传输协议、网络新闻）。万维网为我们提供了互动且通常“庞大”的流量，包括图像、声音和视频。
The World Wide Web has also popularized the Internet, so that there is significant interest in accessing the Internet over link speeds that are much "slower" than typical office network speeds. In fact, a significant proportion of the current Internet users is connected to the Internet over a relatively slow last-hop link. In future, the number of such users is likely to increase rapidly as various mobile devices are foreseen to to be attached to the Internet over slow wireless links.
万维网还普及了互联网，因此人们对通过比典型办公网络速度“慢”得多的链接速度访问互联网产生了极大的兴趣。事实上，当前互联网用户中有很大一部分是通过相对较慢的最后一跳链接连接到互联网的。未来，由于预计各种移动设备将通过慢速无线链路连接到互联网，此类用户的数量可能会迅速增加。
In order to provide the best interactive response for these "bulky" transfers, implementors may wish to minimize the number of bits actually transmitted over these "slow" connections. There are two
为了为这些“庞大”传输提供最佳交互响应，实现者可能希望最小化通过这些“缓慢”连接实际传输的比特数。有两个
areas that can be considered - compressing the bits that make up the overhead associated with the connection, and compressing the bits that make up the payload being transported over the connection.
可以考虑的领域-压缩构成与连接相关联的开销的位，以及压缩构成通过连接传输的有效负载的位。
In addition, implementors may wish to consider TCP receive window settings and queuing mechanisms as techniques to improve performance over low-speed links. While these techniques do not involve protocol changes, they are included in this document for completeness.
此外，实现者可能希望考虑TCP接收窗口设置和排队机制作为改善低速链路性能的技术。虽然这些技术不涉及协议变更，但为了完整性，它们包含在本文档中。
This section describes optimizations which have been suggested for use in situations where hosts can saturate their links. The next section summarizes recommendations about the use of these optimizations.
本节介绍了建议在主机可能使其链路饱和的情况下使用的优化。下一节总结了关于使用这些优化的建议。
Mechanisms for TCP and IP header compression defined in [RFC1144, RFC2507, RFC2508, RFC2509, RFC3095] provide the following benefits:
[RFC1144、RFC2507、RFC2508、RFC2509、RFC3095]中定义的TCP和IP报头压缩机制具有以下优点：
- Improve interactive response time
- 提高交互式响应时间
- Decrease header overhead (for a typical dialup MTU of 296 bytes, the overhead of TCP/IP headers can decrease from about 13 percent with typical 40-byte headers to 1-1.5 percent with with 3-5 byte compressed headers, for most packets). This enables use of small packets for delay-sensitive low data-rate traffic and good line efficiency for bulk data even with small segment sizes (for reasons to use a small MTU on slow links, see section 2.3)
- 减少报头开销（对于296字节的典型拨号MTU，对于大多数数据包，TCP/IP报头的开销可以从典型的40字节报头的约13%减少到3-5字节压缩报头的1-1.5%）。这使得能够使用小数据包来实现对延迟敏感的低数据速率通信，并且即使在具有小数据段大小的情况下，也能够为批量数据提供良好的线路效率（关于在慢速链路上使用小MTU的原因，请参见第2.3节）
- Many slow links today are wireless and tend to be significantly lossy. Header compression reduces packet loss rate over lossy links (simply because shorter transmission times expose packets to fewer events that cause loss).
- 如今，许多慢速链路都是无线的，往往会有明显的损耗。报头压缩降低了有损链路上的数据包丢失率（这仅仅是因为较短的传输时间使数据包暴露在较少的导致丢失的事件中）。
[RFC1144] header compression is a Proposed Standard for TCP Header compression that is widely deployed. Unfortunately it is vulnerable on lossy links, because even a single bit error results in loss of synchronization between the compressor and decompressor. It uses TCP timeouts to detect a loss of such synchronization, but these errors result in loss of data (up to a full TCP window), delay of a full RTO, and unnecessary slow-start.
[RFC1144]报头压缩是广泛部署的TCP报头压缩拟议标准。不幸的是，它在有损链路上易受攻击，因为即使是一个位错误也会导致压缩器和解压缩器之间的同步丢失。它使用TCP超时来检测此类同步的丢失，但这些错误会导致数据丢失（最多可达完整的TCP窗口）、完整RTO延迟以及不必要的缓慢启动。
A more recent header compression proposal [RFC2507] includes an explicit request for retransmission of an uncompressed packet to allow resynchronization without waiting for a TCP timeout (and executing congestion avoidance procedures). This works much better on links with lossy characteristics.
最近的报头压缩方案[RFC2507]包括明确请求重新传输未压缩数据包，以允许在不等待TCP超时的情况下重新同步（并执行拥塞避免过程）。这在具有有损特性的链接上效果更好。
The above scheme ceases to perform well under conditions as extreme as those of many cellular links (error conditions of 1e-3 or 1e-2 and round trip times over 100 ms.). For these cases, the 'Robust Header Compression' working group has developed ROHC [RFC3095]. Extensions of ROHC to support compression of TCP headers are also under development.
上述方案在与许多蜂窝链路一样极端的条件下（错误条件为1e-3或1e-2，往返时间超过100毫秒）不再表现良好。对于这些情况，“鲁棒头部压缩”工作组已开发了ROHC[RFC3095]。支持TCP头压缩的ROHC扩展也在开发中。
[RFC1323] defines a "TCP Timestamp" option, used to prevent "wrapping" of the TCP sequence number space on high-speed links, and to improve TCP RTT estimates by providing unambiguous TCP roundtrip timings. Use of TCP timestamps prevents header compression, because the timestamps are sent as TCP options. This means that each timestamped header has TCP options that differ from the previous header, and headers with changed TCP options are always sent uncompressed. In addition, timestamps do not seem to have much of an impact on RTO estimation [AlPa99].
[RFC1323]定义了一个“TCP时间戳”选项，用于防止在高速链路上“包装”TCP序列号空间，并通过提供明确的TCP往返计时来改进TCP RTT估计。使用TCP时间戳可以防止报头压缩，因为时间戳是作为TCP选项发送的。这意味着每个带时间戳的头都有不同于前一个头的TCP选项，并且具有更改的TCP选项的头总是以未压缩的方式发送。此外，时间戳似乎对RTO估计没有太大影响[AlPa99]。
Nevertheless, the ROHC working group is developing schemes to compress TCP headers, including options such as timestamps and selective acknowledgements.
然而，ROHC工作组正在开发压缩TCP报头的方案，包括时间戳和选择性确认等选项。
Recommendation: Implement [RFC2507], in particular as it relates to IPv4 tunnels and Minimal Encapsulation for Mobile IP, as well as TCP header compression for lossy links and links that reorder packets. PPP capable devices should implement "IP Header Compression over PPP" [RFC2509]. Robust Header Compression [RFC3095] is recommended for extremely slow links with very high error rates (see above), but implementors should judge if its complexity is justified (perhaps by the cost of the radio frequency resources).
建议：实施[RFC2507]，特别是因为它涉及IPv4隧道和移动IP的最小封装，以及有损链路和重新排序数据包的链路的TCP报头压缩。支持PPP的设备应实现“PPP上的IP报头压缩”[RFC2509]。对于错误率极高的极慢链路（见上文），建议使用健壮的报头压缩[RFC3095]，但实施者应判断其复杂性是否合理（可能是由于射频资源的成本）。
[RFC1144] header compression should only be enabled when operating over reliable "slow" links.
[RFC1144]只有在通过可靠的“慢速”链路运行时，才应启用报头压缩。
Use of TCP Timestamps [RFC1323] is not recommended with these connections, because it complicates header compression. Even though the Robust Header Compression (ROHC) working group is developing specifications to remedy this, those mechanisms are not yet fully developed nor deployed, and may not be generally justifiable. Furthermore, connections traversing "slow" links do not require protection against TCP sequence-number wrapping.
不建议在这些连接中使用TCP时间戳[RFC1323]，因为它会使报头压缩复杂化。尽管鲁棒头压缩（ROHC）工作组正在制定规范来解决这一问题，但这些机制尚未完全开发或部署，而且通常也不合理。此外，通过“慢速”链接的连接不需要保护以防止TCP序列号缠绕。
Compression of IP payloads is also desirable on "slow" network links. "IP Payload Compression Protocol (IPComp)" [RFC2393] defines a framework where common compression algorithms can be applied to arbitrary IP segment payloads.
IP有效负载的压缩在“慢速”网络链路上也是可取的。“IP有效负载压缩协议（IPComp）”[RFC2393]定义了一个框架，其中通用压缩算法可应用于任意IP段有效负载。
IP payload compression is something of a niche optimization. It is necessary because IP-level security converts IP payloads to random bitstreams, defeating commonly-deployed link-layer compression mechanisms which are faced with payloads that have no redundant "information" that can be more compactly represented.
IP有效负载压缩是一种小生境优化。这是必要的，因为IP级别的安全性将IP有效负载转换为随机比特流，从而击败了通常部署的链路层压缩机制，这些机制面临的有效负载没有可以更紧凑地表示的冗余“信息”。
However, many IP payloads are already compressed (images, audio, video, "zipped" files being transferred), or are already encrypted above the IP layer (e.g., SSL [SSL]/TLS [RFC2246]). These payloads will not "compress" further, limiting the benefit of this optimization.
然而，许多IP有效负载已经被压缩（正在传输的图像、音频、视频、“压缩”文件），或者已经在IP层上被加密（例如，SSL[SSL]/TLS[RFC2246]）。这些有效载荷不会进一步“压缩”，从而限制了这种优化的好处。
For uncompressed HTTP payload types, HTTP/1.1 [RFC2616] also includes Content-Encoding and Accept-Encoding headers, supporting a variety of compression algorithms for common compressible MIME types like text/plain. This leaves only the HTTP headers themselves uncompressed.
对于未压缩的HTTP有效负载类型，HTTP/1.1[RFC2616]还包括内容编码和接受编码头，支持针对常见可压缩MIME类型（如text/plain）的各种压缩算法。这只剩下HTTP头本身未压缩。
In general, application-level compression can often outperform IPComp, because of the opportunity to use compression dictionaries based on knowledge of the specific data being compressed.
一般来说，应用程序级压缩通常优于IPComp，因为有机会使用基于压缩的特定数据知识的压缩字典。
Extensive use of application-level compression techniques will reduce the need for IPComp, especially for WWW users.
广泛使用应用程序级压缩技术将减少对IPComp的需求，特别是对于WWW用户。
Recommendation: IPComp may optionally be implemented.
建议：可选择实施IPComp。
There are several points to keep in mind when choosing an MTU for low-speed links.
在为低速链路选择MTU时，有几点需要记住。
First, if a full-length MTU occupies a link for longer than the delayed ACK timeout (typically 200 milliseconds, but may be up to 500 milliseconds), this timeout will cause an ACK to be generated for every segment, rather than every second segment, as occurs with most implementations of the TCP delayed ACK algorithm.
首先，如果全长MTU占用链路的时间超过延迟ACK超时（通常为200毫秒，但可能高达500毫秒），此超时将导致为每个段生成ACK，而不是像TCP延迟ACK算法的大多数实现那样，为每一秒段生成ACK。
Second, "relatively large" MTUs, which take human-perceptible amounts of time to be transmitted into the network, create human-perceptible delays in other flows using the same link. [RFC1144] considers 100-200 millisecond delays as human-perceptible. The convention of choosing 296-byte MTUs (with header compression enabled) for dialup access is a compromise that limits the maximum link occupancy delay with full-length MTUs close to 200 milliseconds on 9.6 Kb/second links.
第二，“相对较大”的MTU将人类可感知的时间量传输到网络中，在使用相同链路的其他流中产生人类可感知的延迟。[RFC1144]认为100-200毫秒的延迟是人类可以感知的。选择296字节MTU（启用报头压缩）进行拨号访问的约定是一种折衷方案，在9.6 Kb/s链路上，全长MTU的最大链路占用延迟限制为接近200毫秒。
Third, on last-hop links using a larger link MTU size, and therefore larger MSS, would allow a TCP sender to increase its congestion window faster in bytes than when using a smaller MTU size (and a smaller MSS). However, with a smaller MTU size, and a smaller MSS size, the congestion window, when measured in segments, increases more quickly than it would with a larger MSS size. Connections using smaller MSS sizes are more likely to be able to send enough segments to generate three duplicate acknowledgements, triggering fast retransmit/fast recovery when packet losses are encountered. Hence, a smaller MTU size is useful for slow links with lossy characteristics.
第三，在最后一跳链路上，使用更大的链路MTU大小，因此更大的MSS，将允许TCP发送方比使用更小的MTU大小（和更小的MSS）时更快地增加其拥塞窗口（以字节为单位）。然而，当MTU尺寸较小，MSS尺寸较小时，在分段测量时，拥塞窗口比MSS尺寸较大时增加得更快。使用较小MSS大小的连接更有可能发送足够的段以生成三个重复确认，从而在遇到数据包丢失时触发快速重传/快速恢复。因此，较小的MTU尺寸对于具有损耗特性的慢链路是有用的。
Fourth, using a smaller MTU size also decreases the queuing delay of a TCP flow (and thereby RTT) compared to use of larger MTU size with the same number of packets in a queue. This means that a TCP flow using a smaller segment size and traversing a slow link is able to inflate the congestion window (in number of segments) to a larger value while experiencing the same queuing delay.
第四，与在队列中使用相同数量的数据包的较大MTU大小相比，使用较小MTU大小还可以减少TCP流的排队延迟（从而减少RTT）。这意味着，使用较小段大小并通过慢速链路的TCP流能够在经历相同排队延迟的同时将拥塞窗口（以段数计）膨胀到较大的值。
Finally, some networks charge for traffic on a per-packet basis, not on a per-kilobyte basis. In these cases, connections using a larger MTU may be charged less than connections transferring the same number of bytes using a smaller MTU.
最后，一些网络按每个数据包收费，而不是按每千字节收费。在这些情况下，使用较大MTU的连接的费用可能低于使用较小MTU传输相同字节数的连接的费用。
Recommendation: If it is possible to do so, MTUs should be chosen that do not monopolize network interfaces for human-perceptible amounts of time, and implementors should not chose MTUs that will occupy a network interface for significantly more than 100-200 milliseconds.
建议：如果有可能，应选择不会在人类可感知的时间内独占网络接口的MTU，并且实施者不应选择占用网络接口明显超过100-200毫秒的MTU。
In many cases, TCP connections that traverse slow links have the slow link as an "access" link, with higher-speed links in use for most of the connection path. One common configuration might be a laptop computer using dialup access to a terminal server (a last-hop router), with an HTTP server on a high-speed LAN "behind" the terminal server.
在许多情况下，穿越慢速链路的TCP连接将慢速链路作为“访问”链路，而高速链路用于大多数连接路径。一种常见的配置可能是使用拨号访问终端服务器（最后一跳路由器）的笔记本电脑，在终端服务器“后面”的高速LAN上有一个HTTP服务器。
In this case, the HTTP server may be able to place packets on its directly-attached high-speed LAN at a higher rate than the last-hop router can forward them on the low-speed link. When the last-hop router falls behind, it will be unable to buffer the traffic intended for the low-speed link, and will become a point of congestion and begin to drop the excess packets. In particular, several packets may be dropped in a single transmission window when initial slow start overshoots the last-hop router buffer.
在这种情况下，HTTP服务器可能能够在其直接连接的高速LAN上以高于最后一跳路由器在低速链路上转发数据包的速率放置数据包。当最后一跳路由器落后时，它将无法缓冲用于低速链路的通信量，并将成为拥塞点并开始丢弃多余的数据包。特别地，当初始慢启动超过最后一跳路由器缓冲器时，可以在单个传输窗口中丢弃多个分组。
Although packet loss is occurring, it isn't detected at the TCP sender until one RTT time after the router buffer space is exhausted and the first packet is dropped. This late congestion signal allows the congestion window to increase up to double the size it was at the time the first packet was dropped at the router.
虽然正在发生数据包丢失，但在路由器缓冲区空间耗尽并丢弃第一个数据包后的一次RTT时间内，TCP发送方不会检测到数据包丢失。这个延迟拥塞信号允许拥塞窗口增加到路由器丢弃第一个数据包时的两倍。
If the link MTU is large enough to take more than the delayed ACK timeout interval to transmit a packet, an ACK is sent for every segment and the congestion window is doubled in a single RTT. If a smaller link MTU is in use and delayed ACKs can be utilized, the congestion window increases by a factor of 1.5 in one RTT. In both cases the sender continues transmitting packets well beyond the congestion point of the last-hop router, resulting in multiple packet losses in a single window.
如果链路MTU足够大，以至于传输数据包所需的时间超过延迟的ACK超时时间间隔，则为每个段发送ACK，并且在单个RTT中拥塞窗口加倍。如果使用较小的链路MTU并且可以利用延迟的ACK，则在一个RTT中拥塞窗口将增加1.5倍。在这两种情况下，发送方继续传输数据包，远远超过最后一跳路由器的拥塞点，从而在单个窗口中造成多个数据包丢失。
The self-clocking nature of TCP's slow start and congestion avoidance algorithms prevent this buffer overrun from continuing. In addition, these algorithms allow senders to "probe" for available bandwidth - cycling through an increasing rate of transmission until loss occurs, followed by a dramatic (50-percent) drop in transmission rate. This happens when a host directly connected to a low-speed link offers an advertised window that is unrealistically large for the low-speed link. During the congestion avoidance phase the peer host continues to probe for available bandwidth, trying to fill the advertised window, until packet loss occurs.
TCP的慢启动和拥塞避免算法的自时钟特性阻止了这种缓冲区溢出的继续。此外，这些算法允许发送方“探测”可用带宽——通过不断增加的传输速率循环，直到发生丢失，然后传输速率急剧下降（50%）。当直接连接到低速链路的主机提供的播发窗口对于低速链路来说太大时，就会发生这种情况。在拥塞避免阶段，对等主机继续探测可用带宽，试图填充公布的窗口，直到发生数据包丢失。
The same problems may also exist when a sending host is directly connected to a slow link as most slow links have some local buffer in the link interface. This link interface buffer is subject to overflow exactly in the same way as the last-hop router buffer.
当发送主机直接连接到慢速链路时，也可能存在相同的问题，因为大多数慢速链路的链路接口中都有一些本地缓冲区。此链路接口缓冲区与最后一跳路由器缓冲区的溢出方式完全相同。
When a last-hop router with a small number of buffers per outbound link is used, the first buffer overflow occurs earlier than it would if the router had a larger number of buffers. Subsequently with a smaller number of buffers the periodic packet losses occur more frequently during congestion avoidance, when the sender probes for available bandwidth.
当使用每个出站链路具有少量缓冲区的最后一跳路由器时，第一个缓冲区溢出发生的时间比路由器具有大量缓冲区的时间更早。随后，当发送方探测可用带宽时，在避免拥塞期间，使用较少数量的缓冲区，周期性数据包丢失发生得更频繁。
The most important responsibility of router buffers is to absorb bursts. Too few buffers (for example, only three buffers per outbound link as described in [RFC2416]) means that routers will overflow their buffer pools very easily and are unlikely to absorb even a very small burst. When a larger number of router buffers are allocated per outbound link, the buffer space does not overflow as quickly but the buffers are still likely to become full due to TCP's default behavior. A larger number of router buffers leads to longer queuing delays and a longer RTT.
路由器缓冲区最重要的职责是吸收突发。缓冲区太少（例如，如[RFC2416]中所述，每个出站链路只有三个缓冲区）意味着路由器将很容易溢出缓冲池，甚至不可能吸收非常小的突发。当为每个出站链路分配更多的路由器缓冲区时，缓冲区空间不会很快溢出，但由于TCP的默认行为，缓冲区仍有可能变满。较大数量的路由器缓冲区会导致更长的排队延迟和更长的RTT。
If router queues become full before congestion is signaled or remain full for long periods of time, this is likely to result in "lock-out", where a single connection or a few connections occupy the router queue space, preventing other connections from using the link [RFC2309], especially when a tail drop queue management discipline is being used.
如果路由器队列在拥塞发出信号之前变满或长时间保持满，则可能导致“锁定”，即单个连接或几个连接占用路由器队列空间，从而阻止其他连接使用链路[RFC2309]，特别是在使用尾部丢弃队列管理规程时。
Therefore, it is essential to have a large enough number of buffers in routers to be able to absorb data bursts, but keep the queues normally small. In order to achieve this it has been recommended in [RFC2309] that an active queue management mechanism, like Random Early Detection (RED) [RED93], should be implemented in all Internet routers, including the last-hop routers in front of a slow link. It should also be noted that RED requires a sufficiently large number of router buffers to work properly. In addition, the appropriate parameters of RED on a last-hop router connected to a slow link will likely deviate from the defaults recommended.
因此，路由器中必须有足够多的缓冲区，以便能够吸收数据突发，但保持队列通常较小。为了实现这一点，[RFC2309]中建议在所有互联网路由器（包括慢链路前面的最后一跳路由器）中实施主动队列管理机制，如随机早期检测（RED）[RED93]。还应注意，RED需要足够多的路由器缓冲区才能正常工作。此外，连接到慢速链路的最后一跳路由器上适当的RED参数可能会偏离推荐的默认值。
Active queue management mechanism do not eliminate packet drops but, instead, drop packets at earlier stage to solve the full-queue problem for flows that are responsive to packet drops as congestion signal. Hosts that are directly connected to low-speed links may limit the receive windows they advertise in order to lower or eliminate the number of packet drops in a last-hop router. When doing so one should, however, take care that the advertised window is large enough to allow full utilization of the last-hop link capacity and to allow triggering fast retransmit, when a packet loss is encountered. This recommendation takes two forms:
主动队列管理机制不消除丢包，而是在早期丢包，以解决作为拥塞信号响应丢包的流的完全队列问题。直接连接到低速链路的主机可能会限制它们播发的接收窗口，以减少或消除最后一跳路由器中的丢包次数。然而，在这样做时，应注意广告窗口足够大，以允许充分利用最后一跳链路容量，并允许在遇到分组丢失时触发快速重传。这项建议有两种形式：
- Modern operating systems use relatively large default TCP receive buffers compared to what is required to fully utilize the link capacity of low-speed links. Users should be able to choose the default receive window size in use - typically a system-wide parameter. (This "choice" may be as simple as "dial-up access/LAN access" on a dialog box - this would accommodate many environments without requiring hand-tuning by experienced network engineers.)
- 与充分利用低速链路的链路容量相比，现代操作系统使用相对较大的默认TCP接收缓冲区。用户应该能够选择使用中的默认接收窗口大小-通常是系统范围的参数。（此“选择”可能与对话框上的“拨号访问/LAN访问”一样简单-这将适应许多环境，而无需经验丰富的网络工程师手动调整。）
- Application developers should not attempt to manually manage network bandwidth using socket buffer sizes. Only in very rare circumstances will an application actually know both the bandwidth and delay of a path and be able to choose a suitably low (or high) value for the socket buffer size to obtain good network performance.
- 应用程序开发人员不应尝试使用套接字缓冲区大小手动管理网络带宽。只有在极少数情况下，应用程序才能真正了解路径的带宽和延迟，并能够为套接字缓冲区大小选择适当的低（或高）值，以获得良好的网络性能。
This recommendation is not a general solution for any network path that might involve a slow link. Instead, this recommendation is applicable in environments where the host "knows" it is always connected to other hosts via "slow links". For hosts that may connect to other host over a variety of links (e.g., dial-up laptop computers with LAN-connected docking stations), buffer auto-tuning for the receive buffer is a more reasonable recommendation, and is discussed below.
对于可能涉及慢速链路的任何网络路径，本建议不是通用解决方案。相反，此建议适用于主机“知道”它始终通过“慢速链接”连接到其他主机的环境。对于可能通过各种链路连接到其他主机的主机（例如，带有LAN连接扩展底座的拨号膝上型计算机），接收缓冲区的缓冲区自动调整是一个更合理的建议，如下所述。
[SMM98] recognizes a tension between the desire to allocate "large" TCP buffers, so that network paths are fully utilized, and a desire to limit the amount of memory dedicated to TCP buffers, in order to efficiently support large numbers of connections to hosts over network paths that may vary by six orders of magnitude.
[SMM98]认识到分配“大”TCP缓冲区以充分利用网络路径的愿望与限制专用于TCP缓冲区的内存量的愿望之间的紧张关系，以便通过可能变化六个数量级的网络路径有效支持与主机的大量连接。
The technique proposed is to dynamically allocate TCP buffers, based on the current congestion window, rather than attempting to preallocate TCP buffers without any knowledge of the network path.
提出的技术是基于当前拥塞窗口动态分配TCP缓冲区，而不是在不知道网络路径的情况下尝试预先分配TCP缓冲区。
This proposal results in receive buffers that are appropriate for the window sizes in use, and send buffers large enough to contain two windows of segments, so that SACK and fast recovery can recover losses without forcing the connection to use lengthy retransmission timeouts.
此方案产生的接收缓冲区适用于使用的窗口大小，发送缓冲区足够大，可以包含两个段窗口，因此SACK和fast recovery可以恢复丢失，而不会强制连接使用长时间的重新传输超时。
While most of the motivation for this proposal is given from a server's perspective, hosts that connect using multiple interfaces with markedly-different link speeds may also find this kind of technique useful. This is true in particular with slow links, which are likely to dominate the end-to-end RTT. If the host is connected only via a single slow link interface at a time, it is fairly easy to (dynamically) adjust the receive window (and thus the advertised window) to a value appropriate for the slow last-hop link with known bandwidth and delay characteristics.
虽然此建议的大部分动机都是从服务器的角度给出的，但是使用多个具有明显不同链路速度的接口进行连接的主机也可能会发现这种技术很有用。这一点尤其适用于低速链路，这可能会主导端到端RTT。如果主机一次仅通过一个慢速链路接口连接，则很容易（动态地）将接收窗口（以及广告窗口）调整为适合具有已知带宽和延迟特性的慢速最后一跳链路的值。
Recommendation: If a host is sometimes connected via a slow link but the host is also connected using other interfaces with markedly-different link speeds, it may use receive buffer auto-tuning to adjust the advertised window to an appropriate value.
建议：如果主机有时通过慢速链路连接，但主机也使用具有明显不同链路速度的其他接口连接，则可能会使用接收缓冲区自动调整将播发窗口调整为适当的值。
If a TCP connection stabilizes with a congestion window of only a few segments (as could be expected on a "slow" link), the sender isn't sending enough segments to generate three duplicate acknowledgements, triggering fast retransmit and fast recovery. This means that a retransmission timeout is required to repair the loss - dropping the TCP connection to a congestion window with only one segment.
如果TCP连接在拥塞窗口只有几个段的情况下稳定（在“慢速”链路上可能会出现这种情况），则发送方发送的段数不足以生成三个重复确认，从而触发快速重传和快速恢复。这意味着需要重新传输超时来修复丢失-将TCP连接丢弃到只有一个段的拥塞窗口。
[TCPB98] and [TCPF98] observe that (in studies of network trace datasets) it is relatively common for TCP retransmission timeouts to occur even when some duplicate acknowledgements are being sent. The challenge is to use these duplicate acknowledgements to trigger fast retransmit/fast recovery without injecting traffic into the network unnecessarily - and especially not injecting traffic in ways that will result in instability.
[TCPB98]和[TCPF98]观察到（在网络跟踪数据集的研究中），即使发送了一些重复的确认，TCP重传超时也相对常见。挑战在于使用这些重复确认来触发快速重传/快速恢复，而不向网络注入不必要的流量，尤其是不以会导致不稳定的方式注入流量。
The "Limited Transmit" algorithm [RFC3042] suggests sending a new segment when the first and second duplicate acknowledgements are received, so that the receiver is more likely to be able to continue to generate duplicate acknowledgements until the TCP retransmit threshold is reached, triggering fast retransmit and fast recovery. When the congestion window is small, this is very useful in assisting fast retransmit and fast recovery to recover from a packet loss without using a retransmission timeout. We note that a maximum of two additional new segments will be sent before the receiver sends either a new acknowledgement advancing the window or two additional duplicate acknowledgements, triggering fast retransmit/fast recovery, and that these new segments will be acknowledgement-clocked, not back-to-back.
“有限传输”算法[RFC3042]建议在接收到第一个和第二个重复确认时发送一个新段，以便接收器更有可能继续生成重复确认，直到达到TCP重传阈值，从而触发快速重传和快速恢复。当拥塞窗口很小时，这对于帮助快速重传和快速恢复从数据包丢失中恢复而不使用重传超时非常有用。我们注意到，在接收器发送新确认提前窗口或两个额外重复确认（触发快速重传/快速恢复）之前，最多将发送两个额外的新段，并且这些新段将被确认计时，而不是背对背。
Recommendation: Limited Transmit should be implemented in all hosts.
建议：应在所有主机中实施有限传输。
This section summarizes our recommendations regarding the previous standards-track mechanisms, for end nodes that are connected via a slow link.
本节总结了我们关于先前标准跟踪机制的建议，适用于通过慢速链路连接的终端节点。
Header compression should be implemented. [RFC1144] header compression can be enabled over robust network links. [RFC2507] should be used over network connections that are expected to experience loss due to corruption as well as loss due to congestion. For extremely lossy and slow links, implementors should evaluate ROHC [RFC3095] as a potential solution. [RFC1323] TCP timestamps must be turned off because (1) their protection against TCP sequence number wrapping is unjustified for slow links, and (2) they complicate TCP header compression.
应该实现报头压缩。[RFC1144]可以通过强健的网络链路启用报头压缩。[RFC2507]应在网络连接上使用，这些网络连接预计会因损坏而丢失，也会因拥塞而丢失。对于极有损耗和慢速链接，实施者应评估ROHC[RFC3095]作为一种潜在的解决方案。[RFC1323]必须关闭TCP时间戳，因为（1）它们对TCP序列号包装的保护对于慢速链路是不合理的，（2）它们使TCP报头压缩复杂化。
IP Payload Compression [RFC2393] should be implemented, although compression at higher layers of the protocol stack (for example [RFC 2616]) may make this mechanism less useful.
应该实现IP有效负载压缩[RFC2393]，尽管在协议栈的更高层（例如[RFC 2616]）进行压缩可能会降低该机制的实用性。
For HTTP/1.1 environments, [RFC2616] payload compression should be implemented and should be used for payloads that are not already compressed.
对于HTTP/1.1环境，应实现[RFC2616]有效负载压缩，并应将其用于尚未压缩的有效负载。
Implementors should choose MTUs that don't monopolize network interfaces for more than 100-200 milliseconds, in order to limit the impact of a single connection on all other connections sharing the network interface.
实现者应该选择不垄断网络接口超过100-200毫秒的MTU，以限制单个连接对共享网络接口的所有其他连接的影响。
Use of active queue management is recommended on last-hop routers that provide Internet access to host behind a slow link. In addition, number of router buffers per slow link should be large enough to absorb concurrent data bursts from more than a single flow. To absorb concurrent data bursts from two or three TCP senders with a typical data burst of three back-to-back segments per sender, at least six (6) or nine (9) buffers are needed. Effective use of active queue management is likely to require even larger number of buffers.
建议在最后一跳路由器上使用主动队列管理，该路由器为慢速链路后面的主机提供Internet访问。此外，每个慢速链路的路由器缓冲区数量应足够大，以吸收来自多个流的并发数据突发。为了吸收来自两个或三个TCP发送方的并发数据突发，每个发送方具有三个背靠背段的典型数据突发，至少需要六（6）个或九（9）个缓冲区。有效使用主动队列管理可能需要更多的缓冲区。
Implementors should consider the possibility that a host will be directly connected to a low-speed link when choosing default TCP receive window sizes.
实现者应该考虑当选择默认TCP接收窗口大小时，主机将直接连接到低速链路的可能性。
Application developers should not attempt to manually manage network bandwidth using socket buffer sizes as only in very rare circumstances an application will be able to choose a suitable value for the socket buffer size to obtain good network performance.
应用程序开发人员不应尝试使用套接字缓冲区大小手动管理网络带宽，因为只有在极少数情况下，应用程序才能为套接字缓冲区大小选择合适的值，以获得良好的网络性能。
Limited Transmit [RFC3042] should be implemented in all end hosts as it assists in triggering fast retransmit when congestion window is small.
有限传输[RFC3042]应在所有终端主机中实现，因为它有助于在拥塞窗口较小时触发快速重传。
All of the mechanisms described above are stable standards-track RFCs (at Proposed Standard status, as of this writing).
上面描述的所有机制都是稳定的标准跟踪RFC（在撰写本文时处于建议的标准状态）。
In addition, implementors may wish to consider TCP buffer auto-tuning, especially when the host system is likely to be used with a wide variety of access link speeds. This is not a standards-track TCP mechanism but, as it is an operating system implementation issue, it does not need to be standardized.
此外，实现者可能希望考虑TCP缓冲器自动调谐，特别是当主机系统很可能被用于各种各样的访问链路速度时。这不是一个标准的跟踪TCP机制，但由于它是一个操作系统实现问题，因此不需要标准化。
Of the above mechanisms, only Header Compression (for IP and TCP) may cease to work in the presence of end-to-end IPSEC. However, [RFC3095] does allow compressing the ESP header.
在上述机制中，只有报头压缩（对于IP和TCP）在端到端IPSEC存在时可能停止工作。但是，[RFC3095]不允许压缩ESP标头。
In addition to the standards-track mechanisms discussed above, there are still opportunities to improve performance over low-speed links.
除了上面讨论的标准跟踪机制外，还存在改善低速链路性能的机会。
"Sending fewer bits" is an obvious response to slow link speeds. The now-defunct HTTP-NG proposal [HTTP-NG] replaced the text-based HTTP header representation with a binary representation for compactness. However, HTTP-NG is not moving forward and HTTP/1.1 is not being enhanced to include a more compact HTTP header representation. Instead, the Wireless Application Protocol (WAP) Forum has opted for the XML-based Wireless Session Protocol [WSP], which includes a compact header encoding mechanism.
“发送更少的比特”是对低速链路的明显反应。现已失效的HTTP-NG提案[HTTP-NG]将基于文本的HTTP头表示替换为二进制表示，以实现紧凑性。然而，HTTP-NG并没有向前发展，HTTP/1.1也没有得到增强以包含更紧凑的HTTP头表示。取而代之的是，无线应用协议（WAP）论坛选择了基于XML的无线会话协议[WSP]，它包括一个紧凑的报头编码机制。
It would be nice to agree on a more compact header representation that will be used by all WWW communities, not only the wireless WAN community. Indeed, general XML content encodings have been proposed [Millau], although they are not yet widely adopted.
如果能就所有WWW社区（而不仅仅是无线WAN社区）都将使用的更紧凑的报头表示达成一致，那就太好了。事实上，已经提出了通用的XML内容编码[Millau]，尽管它们尚未被广泛采用。
We note that TCP options which change from segment to segment effectively disable header compression schemes deployed today, because there's no way to indicate that some fields in the header are unchanged from the previous segment, while other fields are not. The Robust Header Compression working group is developing such schemes for TCP options such as timestamps and selective acknowledgements. Hopefully, documents subsequent to [RFC3095] will define such specifications.
我们注意到，在不同段之间更改的TCP选项有效地禁用了今天部署的报头压缩方案，因为无法表明报头中的某些字段与前一段没有变化，而其他字段则没有变化。健壮的报头压缩工作组正在为TCP选项（如时间戳和选择性确认）开发此类方案。希望[RFC3095]之后的文件将定义此类规范。
Another effort worth following is that of 'Delta Encoding'. Here, clients that request a slightly modified version of some previously cached resource would receive a succinct description of the differences, rather than the entire resource [HTTP-DELTA].
另一项值得关注的工作是“增量编码”。在这里，请求对某些先前缓存的资源进行轻微修改的客户端将收到对差异的简洁描述，而不是整个资源[HTTP-DELTA]。
All recommendations included in this document are stable standards-track RFCs (at Proposed Standard status, as of this writing) or otherwise do not suggest any changes to any protocol. With the exception of Van Jacobson compression [RFC1144] and [RFC2507, RFC2508, RFC2509], all other mechanisms are applicable to TCP connections protected by end-to-end IPSec. This includes ROHC [RFC3095], albeit partially, because even though it can compress the outermost ESP header to some extent, encryption still renders any payload data uncompressible (including any subsequent protocol headers).
本文件中包含的所有建议均为稳定的标准跟踪RFC（在撰写本文时处于拟定标准状态），或不建议对任何协议进行任何更改。除了Van Jacobson压缩[RFC1144]和[RFC2507、RFC2508、RFC2509]之外，所有其他机制都适用于受端到端IPSec保护的TCP连接。这包括ROHC[RFC3095]，尽管只是部分原因，因为即使它可以在某种程度上压缩最外层的ESP报头，加密仍然会使任何有效负载数据不可压缩（包括任何后续协议报头）。
This document is a pointer to other, existing IETF standards. There are no new IANA considerations.
本文件是指向其他现有IETF标准的指针。没有新的IANA考虑因素。
This recommendation has grown out of "Long Thin Networks" [RFC2757], which in turn benefited from work done in the IETF TCPSAT working group.
本建议源于“长瘦网络”[RFC2757]，这反过来又得益于IETF TCPSAT工作组所做的工作。
[AlPa99] Mark Allman and Vern Paxson, "On Estimating End-to-End Network Path Properties", in ACM SIGCOMM 99 Proceedings, 1999.
[AlPa99]Mark Allman和Vern Paxson，“关于估算端到端网络路径属性”，ACM SIGCOMM 99会议记录，1999年。
[HTTP-DELTA] J. Mogul, et al., "Delta encoding in HTTP", Work in Progress.
[HTTP-DELTA]J.Mogul等人，“HTTP中的DELTA编码”，正在进行中。
[HTTP-NG] Mike Spreitzer, Bill Janssen, "HTTP 'Next Generation'",
9th International WWW Conference, May, 2000. Also
available as: http://www.www9.org/w9cdrom/60/60.html
[HTTP-NG] Mike Spreitzer, Bill Janssen, "HTTP 'Next Generation'",
9th International WWW Conference, May, 2000. Also
available as: http://www.www9.org/w9cdrom/60/60.html
[Millau] Marc Girardot, Neel Sundaresan, "Millau: an encoding
format for efficient representation and exchange of XML
over the Web", 9th International WWW Conference, May,
2000. Also available as:
http://www.www9.org/w9cdrom/154/154.html
[Millau] Marc Girardot, Neel Sundaresan, "Millau: an encoding
format for efficient representation and exchange of XML
over the Web", 9th International WWW Conference, May,
2000. Also available as:
http://www.www9.org/w9cdrom/154/154.html
[PAX97] Paxson, V., "End-to-End Internet Packet Dynamics", 1997,
in SIGCOMM 97 Proceedings, available as:
http://www.acm.org/sigcomm/ccr/archive/ccr-toc/ccr-toc-
97.html
[PAX97] Paxson, V., "End-to-End Internet Packet Dynamics", 1997,
in SIGCOMM 97 Proceedings, available as:
http://www.acm.org/sigcomm/ccr/archive/ccr-toc/ccr-toc-
97.html
[RED93] Floyd, S., and Jacobson, V., Random Early Detection gateways for Congestion Avoidance, IEEE/ACM Transactions on Networking, V.1 N.4, August 1993, pp. 397-413. Also available from http://ftp.ee.lbl.gov/floyd/red.html.
[RED93]Floyd，S.和Jacobson，V.，《避免拥塞的随机早期检测网关》，IEEE/ACM网络交易，第1卷第4期，1993年8月，第397-413页。也可从http://ftp.ee.lbl.gov/floyd/red.html.
[RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial Links", RFC 1144, February 1990.
[RFC1144]Jacobson，V.，“压缩低速串行链路的TCP/IP头”，RFC1144，1990年2月。
[RFC1323] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[RFC1323]Jacobson，V.，Braden，R.和D.Borman，“高性能TCP扩展”，RFC 1323，1992年5月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol: Version 1.0", RFC 2246, January 1999.
[RFC2246]Dierks，T.和C.Allen，“TLS协议：1.0版”，RFC2246，1999年1月。
[RFC2309] Braden, R., Clark, D., Crowcroft, J., Davie, B., Deering, S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, J. and L. Zhang, "Recommendations on Queue Management and Congestion Avoidance in the Internet", RFC 2309, April 1998.
[RFC2309]Braden，R.，Clark，D.，Crowcroft，J.，Davie，B.，Deering，S.，Estrin，D.，Floyd，S.，Jacobson，V.，Minshall，G.，Partridge，C.，Peterson，L.，Ramakrishnan，K.，Shenker，S.，Wroclawski，J.和L.Zhang，“关于互联网中队列管理和拥塞避免的建议”，RFC 2309，1998年4月。
[RFC2393] Shacham, A., Monsour, R., Pereira, R. and M. Thomas, "IP Payload Compression Protocol (IPComp)", RFC 2393, December 1998.
[RFC2393]Shacham，A.，Monsour，R.，Pereira，R.和M.Thomas，“IP有效载荷压缩协议（IPComp）”，RFC 23931998年12月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[RFC2416] Shepard, T. and C. Partridge, "When TCP Starts Up With Four Packets Into Only Three Buffers", RFC 2416, September 1998.
[RFC2416]Shepard，T.和C.Partridge，“当TCP启动时，只有四个数据包进入三个缓冲区”，RFC 2416，1998年9月。
[RFC2507] Degermark, M., Nordgren, B. and S. Pink, "IP Header Compression", RFC 2507, February 1999.
[RFC2507]Degermark，M.，Nordgren，B.和S.Pink，“IP头压缩”，RFC 2507，1999年2月。
[RFC2508] Casner, S. and V. Jacobson. "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999.
[RFC2508]卡斯纳，S.和V.雅各布森。“压缩低速串行链路的IP/UDP/RTP报头”，RFC 2508，1999年2月。
[RFC2509] Engan, M., Casner, S. and C. Bormann, "IP Header Compression over PPP", RFC 2509, February 1999.
[RFC2509]Engan，M.，Casner，S.和C.Bormann，“PPP上的IP报头压缩”，RFC 2509，1999年2月。
[RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581]Allman，M.，Paxson，V.和W.Stevens，“TCP拥塞控制”，RFC 25811999年4月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
[RFC2757] Montenegro, G., Dawkins, S., Kojo, M., Magret, V., and N. Vaidya, "Long Thin Networks", RFC 2757, January 2000.
[RFC2757]黑山，G.，道金斯，S.，科乔，M.，马格里特，V.，和N.瓦迪亚，“长瘦网络”，RFC 2757，2000年1月。
[RFC3042] Allman, M., Balakrishnan, H. and S. Floyd, "Enhancing TCP's Loss Recovery Using Limited Transmit", RFC 3042, January 2001.
[RFC3042]Allman，M.，Balakrishnan，H.和S.Floyd，“使用有限传输增强TCP的丢失恢复”，RFC 3042，2001年1月。
[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T. and H. Zheng, "RObust Header Compression (ROHC): Framework and four Profiles: RTP, UDP ESP and uncompressed", RFC 3095, July 2001.
[RFC3095]Bormann，C.，Burmeister，C.，Degermark，M.，Fukushima，H.，Hannu，H.，Jonsson，L-E.，Hakenberg，R.，Koren，T.，Le，K.，Liu，Z.，Martenson，A.，Miyazaki，A.，Svanbro，K.，Wiebke，T.，Yoshimura，T.和H.Zheng，“鲁棒头压缩（ROHC）：框架和四个配置文件：RTP，UDP ESP和未压缩”，RFC 3095，2001年7月。
[SMM98] Jeffrey Semke, Matthew Mathis, and Jamshid Mahdavi, "Automatic TCP Buffer Tuning", in ACM SIGCOMM 98 Proceedings 1998. Available from http://www.acm.org/sigcomm/sigcomm98/tp/abs_26.html.
[SMM98]Jeffrey Semke、Matthew Mathis和Jamshid Mahdavi，“自动TCP缓冲区调整”，1998年ACM SIGCOMM 98会议录。可从http://www.acm.org/sigcomm/sigcomm98/tp/abs_26.html.
[SSL] Alan O. Freier, Philip Karlton, Paul C. Kocher, The SSL
Protocol: Version 3.0, March 1996. (Expired Internet-
Draft, available from
http://home.netscape.com/eng/ssl3/ssl-toc.html)
[SSL] Alan O. Freier, Philip Karlton, Paul C. Kocher, The SSL
Protocol: Version 3.0, March 1996. (Expired Internet-
Draft, available from
http://home.netscape.com/eng/ssl3/ssl-toc.html)
[TCPB98] Hari Balakrishnan, Venkata N. Padmanabhan, Srinivasan
Seshan, Mark Stemm, Randy H. Katz, "TCP Behavior of a
Busy Internet Server: Analysis and Improvements", IEEE
Infocom, March 1998. Available from:
http://www.cs.berkeley.edu/~hari/papers/infocom98.ps.gz
[TCPB98] Hari Balakrishnan, Venkata N. Padmanabhan, Srinivasan
Seshan, Mark Stemm, Randy H. Katz, "TCP Behavior of a
Busy Internet Server: Analysis and Improvements", IEEE
Infocom, March 1998. Available from:
http://www.cs.berkeley.edu/~hari/papers/infocom98.ps.gz
[TCPF98] Dong Lin and H.T. Kung, "TCP Fast Recovery Strategies:
Analysis and Improvements", IEEE Infocom, March 1998.
Available from:
http://www.eecs.harvard.edu/networking/papers/ infocom-
tcp-final-198.pdf
[TCPF98] Dong Lin and H.T. Kung, "TCP Fast Recovery Strategies:
Analysis and Improvements", IEEE Infocom, March 1998.
Available from:
http://www.eecs.harvard.edu/networking/papers/ infocom-
tcp-final-198.pdf
[WSP] Wireless Application Protocol Forum, "WAP Wireless Session Protocol Specification", approved 4 May, 2000, available from http://www1.wapforum.org/tech/documents/WAP-203-WSP-20000504-a.pdf. (informative reference).
[WSP]无线应用协议论坛，“WAP无线会话协议规范”，2000年5月4日批准，可从http://www1.wapforum.org/tech/documents/WAP-203-WSP-20000504-a.pdf. （参考资料）。
Authors' Addresses
作者地址
Questions about this document may be directed to:
有关本文件的问题，请联系：
Spencer Dawkins Fujitsu Network Communications 2801 Telecom Parkway Richardson, Texas 75082
德克萨斯州理查森电信大道2801号斯宾塞·道金斯富士通网络通信公司75082
Phone: +1-972-479-3782
EMail: spencer.dawkins@fnc.fujitsu.com
Phone: +1-972-479-3782
EMail: spencer.dawkins@fnc.fujitsu.com
Gabriel Montenegro Sun Microsystems Laboratories, Europe 29, chemin du Vieux Chene 38240 Meylan, FRANCE
加布里埃尔黑山太阳微系统实验室，欧洲29号，chemin du Vieux Chene 38240 Meylan，法国
Phone: +33 476 18 80 45
EMail: gab@sun.com
Phone: +33 476 18 80 45
EMail: gab@sun.com
Markku Kojo Department of Computer Science University of Helsinki P.O. Box 26 (Teollisuuskatu 23) FIN-00014 HELSINKI Finland
马尔库科乔赫尔辛基大学计算机科学系P.O盒26（TeulLuuukkutu 23）FIF-000 014赫尔辛基芬兰
Phone: +358-9-1914-4179
Fax: +358-9-1914-4441
EMail: kojo@cs.helsinki.fi
Phone: +358-9-1914-4179
Fax: +358-9-1914-4441
EMail: kojo@cs.helsinki.fi
Vincent Magret Alcatel Internetworking, Inc. 26801 W. Agoura road Calabasas, CA, 91301
Vincent Magret Alcatel Internetworking，Inc.加利福尼亚州卡拉巴斯市阿古拉路西26801号，邮编：91301
Phone: +1 818 878 4485
EMail: vincent.magret@alcatel.com
Phone: +1 818 878 4485
EMail: vincent.magret@alcatel.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。