Network Working Group J. Border
Request for Comments: 3135 Hughes Network Systems
Category: Informational M. Kojo
University of Helsinki
J. Griner
NASA Glenn Research Center
G. Montenegro
Sun Microsystems, Inc.
Z. Shelby
University of Oulu
June 2001
Network Working Group J. Border
Request for Comments: 3135 Hughes Network Systems
Category: Informational M. Kojo
University of Helsinki
J. Griner
NASA Glenn Research Center
G. Montenegro
Sun Microsystems, Inc.
Z. Shelby
University of Oulu
June 2001
Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations
旨在缓解链路相关降级的性能增强代理
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
Abstract
摘要
This document is a survey of Performance Enhancing Proxies (PEPs) often employed to improve degraded TCP performance caused by characteristics of specific link environments, for example, in satellite, wireless WAN, and wireless LAN environments. Different types of Performance Enhancing Proxies are described as well as the mechanisms used to improve performance. Emphasis is put on proxies operating with TCP. In addition, motivations for their development and use are described along with some of the consequences of using them, especially in the context of the Internet.
本文档是对性能增强代理（PEP）的概述，这些代理通常用于改善特定链路环境（例如卫星、无线WAN和无线LAN环境）的特性导致的TCP性能下降。描述了不同类型的性能增强代理以及用于提高性能的机制。重点放在使用TCP操作的代理上。此外，还描述了开发和使用它们的动机以及使用它们的一些后果，特别是在互联网环境中。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Types of Performance Enhancing Proxies . . . . . . . . . . . . 4
2.1 Layering . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1 Transport Layer PEPs . . . . . . . . . . . . . . . . . . . . 5
2.1.2 Application Layer PEPs . . . . . . . . . . . . . . . . . . . 5
2.2 Distribution . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Implementation Symmetry . . . . . . . . . . . . . . . . . . . 6
2.4 Split Connections . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Types of Performance Enhancing Proxies . . . . . . . . . . . . 4
2.1 Layering . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1 Transport Layer PEPs . . . . . . . . . . . . . . . . . . . . 5
2.1.2 Application Layer PEPs . . . . . . . . . . . . . . . . . . . 5
2.2 Distribution . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Implementation Symmetry . . . . . . . . . . . . . . . . . . . 6
2.4 Split Connections . . . . . . . . . . . . . . . . . . . . . . 7
2.5 Transparency . . . . . . . . . . . . . . . . . . . . . . . . . 8
3. PEP Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1 TCP ACK Handling . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.1 TCP ACK Spacing . . . . . . . . . . . . . . . . . . . . . . 9
3.1.2 Local TCP Acknowledgements . . . . . . . . . . . . . . . . . 9
3.1.3 Local TCP Retransmissions . . . . . . . . . . . . . . . . . 9
3.1.4 TCP ACK Filtering and Reconstruction . . . . . . . . . . . . 10
3.2 Tunneling . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3 Compression . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.4 Handling Periods of Link Disconnection with TCP . . . . . . . 11
3.5 Priority-based Multiplexing . . . . . . . . . . . . . . . . . 12
3.6 Protocol Booster Mechanisms . . . . . . . . . . . . . . . . . 13
4. Implications of Using PEPs . . . . . . . . . . . . . . . . . . 14
4.1 The End-to-end Argument . . . . . . . . . . . . . . . . . . . 14
4.1.1 Security . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.1.1.1 Security Implications . . . . . . . . . . . . . . . . . . 15
4.1.1.2 Security Implication Mitigations . . . . . . . . . . . . . 16
4.1.1.3 Security Research Related to PEPs . . . . . . . . . . . . 16
4.1.2 Fate Sharing . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1.3 End-to-end Reliability . . . . . . . . . . . . . . . . . . . 17
4.1.4 End-to-end Failure Diagnostics . . . . . . . . . . . . . . . 19
4.2 Asymmetric Routing . . . . . . . . . . . . . . . . . . . . . . 19
4.3 Mobile Hosts . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.4 Scalability . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.5 Other Implications of Using PEPs . . . . . . . . . . . . . . . 21
5. PEP Environment Examples . . . . . . . . . . . . . . . . . . . 21
5.1 VSAT Environments . . . . . . . . . . . . . . . . . . . . . . 21
5.1.1 VSAT Network Characteristics . . . . . . . . . . . . . . . . 22
5.1.2 VSAT Network PEP Implementations . . . . . . . . . . . . . . 23
5.1.3 VSAT Network PEP Motivation . . . . . . . . . . . . . . . . 24
5.2 W-WAN Environments . . . . . . . . . . . . . . . . . . . . . . 25
5.2.1 W-WAN Network Characteristics . . . . . . . . . . . . . . . 25
5.2.2 W-WAN PEP Implementations . . . . . . . . . . . . . . . . . 26
5.2.2.1 Mowgli System . . . . . . . . . . . . . . . . . . . . . . 26
5.2.2.2 Wireless Application Protocol (WAP) . . . . . . . . . . . 28
5.2.3 W-WAN PEP Motivation . . . . . . . . . . . . . . . . . . . . 29
5.3 W-LAN Environments . . . . . . . . . . . . . . . . . . . . . . 30
5.3.1 W-LAN Network Characteristics . . . . . . . . . . . . . . . 30
5.3.2 W-LAN PEP Implementations: Snoop . . . . . . . . . . . . . . 31
5.3.3 W-LAN PEP Motivation . . . . . . . . . . . . . . . . . . . . 33
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 34
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 34
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 39
Appendix A - PEP Terminology Summary . . . . . . . . . . . . . . . 41
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 45
2.5 Transparency . . . . . . . . . . . . . . . . . . . . . . . . . 8
3. PEP Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1 TCP ACK Handling . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.1 TCP ACK Spacing . . . . . . . . . . . . . . . . . . . . . . 9
3.1.2 Local TCP Acknowledgements . . . . . . . . . . . . . . . . . 9
3.1.3 Local TCP Retransmissions . . . . . . . . . . . . . . . . . 9
3.1.4 TCP ACK Filtering and Reconstruction . . . . . . . . . . . . 10
3.2 Tunneling . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3 Compression . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.4 Handling Periods of Link Disconnection with TCP . . . . . . . 11
3.5 Priority-based Multiplexing . . . . . . . . . . . . . . . . . 12
3.6 Protocol Booster Mechanisms . . . . . . . . . . . . . . . . . 13
4. Implications of Using PEPs . . . . . . . . . . . . . . . . . . 14
4.1 The End-to-end Argument . . . . . . . . . . . . . . . . . . . 14
4.1.1 Security . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.1.1.1 Security Implications . . . . . . . . . . . . . . . . . . 15
4.1.1.2 Security Implication Mitigations . . . . . . . . . . . . . 16
4.1.1.3 Security Research Related to PEPs . . . . . . . . . . . . 16
4.1.2 Fate Sharing . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1.3 End-to-end Reliability . . . . . . . . . . . . . . . . . . . 17
4.1.4 End-to-end Failure Diagnostics . . . . . . . . . . . . . . . 19
4.2 Asymmetric Routing . . . . . . . . . . . . . . . . . . . . . . 19
4.3 Mobile Hosts . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.4 Scalability . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.5 Other Implications of Using PEPs . . . . . . . . . . . . . . . 21
5. PEP Environment Examples . . . . . . . . . . . . . . . . . . . 21
5.1 VSAT Environments . . . . . . . . . . . . . . . . . . . . . . 21
5.1.1 VSAT Network Characteristics . . . . . . . . . . . . . . . . 22
5.1.2 VSAT Network PEP Implementations . . . . . . . . . . . . . . 23
5.1.3 VSAT Network PEP Motivation . . . . . . . . . . . . . . . . 24
5.2 W-WAN Environments . . . . . . . . . . . . . . . . . . . . . . 25
5.2.1 W-WAN Network Characteristics . . . . . . . . . . . . . . . 25
5.2.2 W-WAN PEP Implementations . . . . . . . . . . . . . . . . . 26
5.2.2.1 Mowgli System . . . . . . . . . . . . . . . . . . . . . . 26
5.2.2.2 Wireless Application Protocol (WAP) . . . . . . . . . . . 28
5.2.3 W-WAN PEP Motivation . . . . . . . . . . . . . . . . . . . . 29
5.3 W-LAN Environments . . . . . . . . . . . . . . . . . . . . . . 30
5.3.1 W-LAN Network Characteristics . . . . . . . . . . . . . . . 30
5.3.2 W-LAN PEP Implementations: Snoop . . . . . . . . . . . . . . 31
5.3.3 W-LAN PEP Motivation . . . . . . . . . . . . . . . . . . . . 33
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 34
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 34
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 39
Appendix A - PEP Terminology Summary . . . . . . . . . . . . . . . 41
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 45
The Transmission Control Protocol [RFC0793] (TCP) is used as the transport layer protocol by many Internet and intranet applications. However, in certain environments, TCP and other higher layer protocol performance is limited by the link characteristics of the environment.
传输控制协议[RFC0793]（TCP）被许多Internet和intranet应用程序用作传输层协议。然而，在某些环境中，TCP和其他高层协议的性能受到环境链路特性的限制。
This document is a survey of Performance Enhancing Proxy (PEP) performance migitigation techniques. A PEP is used to improve the performance of the Internet protocols on network paths where native performance suffers due to characteristics of a link or subnetwork on the path. This document is informational and does not make recommendations about using PEPs or not using them. Distinct standards track recommendations for the performance mitigation of TCP over links with high error rates, links with low bandwidth, and so on, have been developed or are in development by the Performance Implications of Link Characteristics WG (PILC) [PILCWEB].
本文档是对性能增强代理（PEP）性能迁移技术的概述。PEP用于提高网络路径上Internet协议的性能，因为路径上的链路或子网络的特性会影响本机性能。本文件仅供参考，不建议使用或不使用PEP。链路特性WG（PILC）[PILCWEB]的性能影响已经制定或正在制定针对高错误率链路、低带宽链路等TCP性能缓解的不同标准跟踪建议。
Link design choices may have a significant influence on the performance and efficiency of the Internet. However, not all link characteristics, for example, high latency, can be compensated for by choices in the link layer design. And, the cost of compensating for some link characteristics may be prohibitive for some technologies. The techniques surveyed here are applied to existing link technologies. When new link technologies are designed, they should be designed so that these techniques are not required, if at all possible.
链接设计的选择可能会对互联网的性能和效率产生重大影响。然而，并非所有链路特性（例如，高延迟）都可以通过链路层设计中的选择来补偿。而且，对于某些技术，补偿某些链路特性的成本可能会过高。这里调查的技术适用于现有的链路技术。在设计新的链路技术时，如果可能的话，它们的设计应确保不需要这些技术。
This document does not advocate the use of PEPs in any general case. On the contrary, we believe that the end-to-end principle in designing Internet protocols should be retained as the prevailing approach and PEPs should be used only in specific environments and circumstances where end-to-end mechanisms providing similar performance enhancements are not available. In any environment where one might consider employing a PEP for improved performance, an end user (or, in some cases, the responsible network administrator) should be aware of the PEP and the choice of employing PEP functionality should be under the control of the end user, especially if employing the PEP would interfere with end-to-end usage of IP layer security mechanisms or otherwise have undesirable implications in some circumstances. This would allow the user to choose end-to-end IP at all times but, of course, without the performance enhancements that employing the PEP may yield.
本文件不提倡在任何一般情况下使用政治公众人物。相反，我们认为，设计互联网协议时的端到端原则应保留为主流方法，PEP应仅在无法提供类似性能增强的端到端机制的特定环境和情况下使用。在任何可能考虑采用PEP来提高性能的环境中，终端用户（或者，在某些情况下，负责网络管理员）应该知道PEP，并且采用PEP功能的选择应该在最终用户的控制下，特别是如果使用PEP会干扰IP层安全机制的端到端使用，或者在某些情况下会产生不良影响。这将允许用户在任何时候选择端到端IP，当然，没有使用PEP可能产生的性能增强。
This survey does not make recommendations, for or against, with respect to using PEPs. Standards track recommendations have been or are being developed within the IETF for individual link
本调查未就使用政治公众人物提出赞成或反对的建议。IETF中已经或正在针对单个链路制定标准跟踪建议
characteristics, e.g., links with high error rates, links with low bandwidth, links with asymmetric bandwidth, etc., by the Performance Implications of Link Characteristics WG (PILC) [PILCWEB].
链路特性WG（PILC）[PILCWEB]的性能影响的特性，例如，具有高错误率的链路、具有低带宽的链路、具有不对称带宽的链路等。
The remainder of this document is organized as follows. Section 2 provides an overview of different kinds of PEP implementations.
本文件的其余部分组织如下。第2节概述了不同类型的政治公众人物实施。
Section 3 discusses some of the mechanisms which PEPs may employ in order to improve performance. Section 4 discusses some of the implications with respect to using PEPs, especially in the context of the global Internet. Finally, Section 5 discusses some example environments where PEPs are used: satellite very small aperture terminal (VSAT) environments, mobile wireless WAN (W-WAN) environments and wireless LAN (W-LAN) environments. A summary of PEP terminology is included in an appendix (Appendix A).
第3节讨论了政治公众人物为提高绩效可能采用的一些机制。第4节讨论了与使用政治公众人物相关的一些影响，特别是在全球互联网环境下。最后，第5节讨论了使用PEP的一些示例环境：卫星甚小孔径终端（VSAT）环境、移动无线广域网（W-WAN）环境和无线局域网（W-LAN）环境。政治公众人物术语摘要见附录（附录A）。
There are many types of Performance Enhancing Proxies. Different types of PEPs are used in different environments to overcome different link characteristics which affect protocol performance. Note that enhancing performance is not necessarily limited in scope to throughput. Other performance related aspects, like usability of a link, may also be addressed. For example, [M-TCP] addresses the issue of keeping TCP connections alive during periods of disconnection in wireless networks.
有许多类型的性能增强代理。在不同的环境中使用不同类型的PEP，以克服影响协议性能的不同链路特性。请注意，提高性能并不一定局限于吞吐量。其他与性能相关的方面，如链接的可用性，也可以解决。例如，[M-TCP]解决了在无线网络断开连接期间保持TCP连接活动的问题。
The following sections describe some of the key characteristics which differentiate different types of PEPs.
以下各节描述了区分不同类型政治公众人物的一些关键特征。
In principle, a PEP implementation may function at any protocol layer but typically it functions at one or two layers only. In this document we focus on PEP implementations that function at the transport layer or at the application layer as such PEPs are most commonly used to enhance performance over links with problematic characteristics. A PEP implementation may also operate below the network layer, that is, at the link layer, but this document pays only little attention to such PEPs as link layer mechanisms can be and typically are implemented transparently to network and higher layers, requiring no modifications to protocol operation above the link layer. It should also be noted that some PEP implementations operate across several protocol layers by exploiting the protocol information and possibly modifying the protocol operation at more than one layer. For such a PEP it may be difficult to define at which layer(s) it exactly operates on.
原则上，PEP实现可以在任何协议层上运行，但通常仅在一个或两个层上运行。在本文档中，我们重点介绍在传输层或应用层运行的PEP实现，因为PEP最常用于增强具有问题特征的链路的性能。PEP实现也可以在网络层下操作，即在链路层，但是本文档仅很少关注此类PEP，因为链路层机制可以并且通常对网络层和更高层透明地实现，不需要修改链路层上的协议操作。还应注意，一些PEP实现通过利用协议信息并可能在多个协议层上修改协议操作跨多个协议层运行。对于这样的PEP，可能很难定义其在哪一层上准确操作。
Transport layer PEPs operate at the transport level. They may be aware of the type of application being carried by the transport layer but, at most, only use this information to influence their behavior with respect to the transport protocol; they do not modify the application protocol in any way, but let the application protocol operate end-to-end. Most transport layer PEP implementations interact with TCP. Such an implementation is called a TCP Performance Enhancing Proxy (TCP PEP). For example, in an environment where ACKs may bunch together causing undesirable data segment bursts, a TCP PEP may be used to simply modify the ACK spacing in order to improve performance. On the other hand, in an environment with a large bandwidth*delay product, a TCP PEP may be used to alter the behavior of the TCP connection by generating local acknowledgments to TCP data segments in order to improve the connection's throughput.
传输层PEP在传输层运行。他们可能知道传输层承载的应用程序的类型，但最多只使用此信息来影响他们关于传输协议的行为；它们不以任何方式修改应用程序协议，而是让应用程序协议端到端地运行。大多数传输层PEP实现都与TCP交互。这种实现称为TCP性能增强代理（TCP PEP）。例如，在ACK可能聚集在一起导致不希望的数据段突发的环境中，可以使用TCP PEP来简单地修改ACK间隔以提高性能。另一方面，在具有大带宽*延迟乘积的环境中，TCP PEP可用于通过生成对TCP数据段的本地确认来改变TCP连接的行为，以提高连接的吞吐量。
The term TCP spoofing is sometimes used synonymously for TCP PEP functionality. However, the term TCP spoofing more accurately describes the characteristic of intercepting a TCP connection in the middle and terminating the connection as if the interceptor is the intended destination. While this is a characteristic of many TCP PEP implementations, it is not a characteristic of all TCP PEP implementations.
术语TCP欺骗有时与TCP PEP功能同义。然而，术语TCP欺骗更准确地描述了截取TCP连接在中间的特性，并终止连接，就好像拦截器是预期的目的地一样。虽然这是许多TCP PEP实现的特征，但并非所有TCP PEP实现的特征。
Application layer PEPs operate above the transport layer. Today, different kinds of application layer proxies are widely used in the Internet. Such proxies include Web caches and relay Mail Transfer Agents (MTA) and they typically try to improve performance or service availability and reliability in general and in a way which is applicable in any environment but they do not necessarily include any optimizations that are specific to certain link characteristics.
应用层PEP在传输层之上运行。如今，各种各样的应用层代理在互联网上得到了广泛的应用。这类代理包括Web缓存和中继邮件传输代理（MTA），它们通常试图以适用于任何环境的方式提高性能或服务可用性和可靠性，但不一定包括特定于某些链路特性的任何优化。
Application layer PEPs, on the other hand, can be implemented to improve application protocol as well as transport layer performance with respect to a particular application being used with a particular type of link. An application layer PEP may have the same functionality as the corresponding regular proxy for the same application (e.g., relay MTA or Web caching proxy) but extended with link-specific optimizations of the application protocol operation.
另一方面，可以实现应用层pep，以针对与特定类型的链路一起使用的特定应用改进应用协议以及传输层性能。应用层PEP可能与同一应用程序的相应常规代理（例如中继MTA或Web缓存代理）具有相同的功能，但通过特定于链路的应用程序协议操作优化进行扩展。
Some application protocols employ extraneous round trips, overly verbose headers and/or inefficient header encoding which may have a significant impact on performance, in particular, with long delay and slow links. This unnecessary overhead can be reduced, in general or
一些应用程序协议使用无关的往返、过于冗长的报头和/或低效的报头编码，这可能会对性能产生重大影响，特别是在长延迟和慢链路的情况下。这种不必要的开销通常可以减少，也可以减少
for a particular type of link, by using an application layer PEP in an intermediate node. Some examples of application layer PEPs which have been shown to improve performance on slow wireless WAN links are described in [LHKR96] and [CTC+97].
对于特定类型的链路，在中间节点中使用应用层PEP。[LHKR96]和[CTC+97]中描述了应用层PEP的一些示例，这些示例已被证明可以提高低速无线WAN链路的性能。
A PEP implementation may be integrated, i.e., it comprises a single PEP component implemented within a single node, or distributed, i.e., it comprises two or more PEP components, typically implemented in multiple nodes. An integrated PEP implementation represents a single point at which performance enhancement is applied. For example, a single PEP component might be implemented to provide impedance matching at the point where wired and wireless links meet.
PEP实现可以是集成的，即它包括在单个节点内实现的单个PEP组件，也可以是分布式的，即它包括两个或多个PEP组件，通常在多个节点中实现。集成的PEP实现代表了应用性能增强的单一点。例如，可以实现单个PEP组件，以在有线和无线链路交汇处提供阻抗匹配。
A distributed PEP implementation is generally used to surround a particular link for which performance enhancement is desired. For example, a PEP implementation for a satellite connection may be distributed between two PEPs located at each end of the satellite link.
分布式PEP实现通常用于围绕需要性能增强的特定链路。例如，卫星连接的PEP实现可以分布在位于卫星链路每一端的两个PEP之间。
A PEP implementation may be symmetric or asymmetric. Symmetric PEPs use identical behavior in both directions, i.e., the actions taken by the PEP occur independent from which interface a packet is received. Asymmetric PEPs operate differently in each direction. The direction can be defined in terms of the link (e.g., from a central site to a remote site) or in terms of protocol traffic (e.g., the direction of TCP data flow, often called the TCP data channel, or the direction of TCP ACK flow, often called the TCP ACK channel). An asymmetric PEP implementation is generally used at a point where the characteristics of the links on each side of the PEP differ or with asymmetric protocol traffic. For example, an asymmetric PEP might be placed at the intersection of wired and wireless networks or an asymmetric application layer PEP might be used for the request-reply type of HTTP traffic. A PEP implementation may also be both symmetric and asymmetric at the same time with regard to different mechanisms it employs. (PEP mechanisms are described in Section 3.)
PEP实现可以是对称的，也可以是非对称的。对称PEP在两个方向上使用相同的行为，即PEP采取的动作独立于接收数据包的接口。不对称政治公众人物在每个方向上的运作方式不同。可以根据链路（例如，从中心站点到远程站点）或协议流量（例如，TCP数据流的方向，通常称为TCP数据通道，或TCP ACK流的方向，通常称为TCP ACK通道）来定义方向。非对称PEP实现通常用于PEP每侧链路的特性不同或具有非对称协议流量的点。例如，非对称PEP可以放置在有线和无线网络的交叉点，或者非对称应用层PEP可以用于HTTP通信的请求-应答类型。就PEP采用的不同机制而言，PEP实现也可能同时是对称和非对称的。（第3节介绍了政治公众人物机制。）
Whether a PEP implementation is symmetric or asymmetric is independent of whether the PEP implementation is integrated or distributed. In other words, a distributed PEP implementation might operate symmetrically at each end of a link (i.e., the two PEPs function identically). On the other hand, a distributed PEP implementation might operate asymmetrically, with a different PEP implementation at each end of the link. Again, this usually is used with asymmetric links. For example, for a link with an asymmetric
PEP实现是对称的还是不对称的，与PEP实现是集成的还是分布式的无关。换句话说，分布式PEP实现可能在链路的每一端对称运行（即，两个PEP功能相同）。另一方面，分布式PEP实现可能会不对称运行，在链路的每一端都有不同的PEP实现。同样，这通常用于不对称链接。例如，对于具有非对称
amount of bandwidth available in each direction, the PEP on the end of the link forwarding traffic in the direction with a large amount of bandwidth might focus on locally acknowledging TCP traffic in order to use the available bandwidth. At the same time, the PEP on the end of the link forwarding traffic in the direction with very little bandwidth might focus on reducing the amount of TCP acknowledgement traffic being forwarded across the link (to keep the link from congesting).
在每个方向上的可用带宽量，链路端上的PEP在具有大量带宽的方向上转发流量，可能会专注于本地确认TCP流量，以便使用可用带宽。同时，链路端上的PEP在带宽非常小的方向上转发流量，其重点可能是减少通过链路转发的TCP确认流量（以防止链路拥塞）。
A split connection TCP implementation terminates the TCP connection received from an end system and establishes a corresponding TCP connection to the other end system. In a distributed PEP implementation, this is typically done to allow the use of a third connection between two PEPs optimized for the link. This might be a TCP connection optimized for the link or it might be another protocol, for example, a proprietary protocol running on top of UDP. Also, the distributed implementation might use a separate connection between the proxies for each TCP connection or it might multiplex the data from multiple TCP connections across a single connection between the PEPs.
拆分连接TCP实现终止从终端系统接收的TCP连接，并建立到另一个终端系统的相应TCP连接。在分布式PEP实现中，这通常是为了允许在两个PEP之间使用针对链路优化的第三个连接。这可能是为链接优化的TCP连接，也可能是另一个协议，例如，运行在UDP之上的专有协议。此外，分布式实现可能会在每个TCP连接的代理之间使用单独的连接，或者可能会在PEP之间的单个连接上多路传输来自多个TCP连接的数据。
In an integrated PEP split connection TCP implementation, the PEP again terminates the connection from one end system and originates a separate connection to the other end system. [I-TCP] documents an example of a single PEP split connection implementation.
在集成的PEP拆分连接TCP实现中，PEP再次终止来自一端系统的连接，并发起到另一端系统的单独连接。[I-TCP]记录了单个PEP拆分连接实现的示例。
Many integrated PEPs use a split connection implementation in order to address a mismatch in TCP capabilities between two end systems. For example, the TCP window scaling option [RFC1323] can be used to extend the maximum amount of TCP data which can be "in flight" (i.e., sent and awaiting acknowledgement). This is useful for filling a link which has a high bandwidth*delay product. If one end system is capable of using scaled TCP windows but the other is not, the end system which is not capable can set up its connection with a PEP on its side of the high bandwidth*delay link. The split connection PEP then sets up a TCP connection with window scaling over the link to the other end system.
许多集成的PEP使用分离连接实现，以解决两个终端系统之间TCP功能不匹配的问题。例如，TCP窗口缩放选项[RFC1323]可用于扩展“飞行中”（即，发送并等待确认）的最大TCP数据量。这对于填充具有高带宽*延迟乘积的链路非常有用。如果一个终端系统能够使用按比例缩放的TCP窗口，而另一个不能，则无法使用的终端系统可以在其高带宽*延迟链路一侧建立与PEP的连接。然后，分离连接PEP通过连接到另一个终端系统的链路，通过窗口缩放来建立TCP连接。
Split connection TCP implementations can effectively leverage TCP performance enhancements optimal for a particular link but which cannot necessarily be employed safely over the global Internet.
拆分连接TCP实现可以有效地利用TCP性能增强，这对于特定链路来说是最佳的，但不一定能够在全球互联网上安全地使用。
Note that using split connection PEPs does not necessarily exclude simultaneous use of IP for end-to-end connectivity. If a split connection is managed per application or per connection and is under the control of the end user, the user can decide whether a particular
请注意，使用拆分连接PEP并不一定排除同时使用IP进行端到端连接。如果拆分连接是针对每个应用程序或每个连接进行管理的，并且在最终用户的控制下，则用户可以决定是否使用特定的
TCP connection or application makes use of the split connection PEP or whether it operates end-to-end. When a PEP is employed on a last hop link, the end user control is relatively easy to implement.
TCP连接或应用程序使用剥离连接PEP，或者无论其是否端到端运行。当在最后一跳链路上使用PEP时，最终用户控制相对容易实现。
In effect, application layer proxies for TCP-based applications are split connection TCP implementations with end systems using PEPs as a service related to a particular application. Therefore, all transport (TCP) layer enhancements that are available with split connection TCP implementations can also be employed with application layer PEPs in conjunction with application layer enhancements.
实际上，基于TCP的应用程序的应用层代理是使用PEP作为与特定应用程序相关的服务的终端系统的拆分连接TCP实现。因此，拆分连接TCP实现中可用的所有传输（TCP）层增强功能也可以与应用层PEP结合使用，并与应用层增强功能结合使用。
Another key characteristic of a PEP is its degree of transparency. PEPs may operate totally transparently to the end systems, transport endpoints, and/or applications involved (in a connection), requiring no modifications to the end systems, transport endpoints, or applications.
政治公众人物的另一个关键特征是其透明度。PEP可以对终端系统、传输端点和/或所涉及的应用程序（在连接中）完全透明地运行，无需修改终端系统、传输端点或应用程序。
On the other hand, a PEP implementation may require modifications to both ends in order to be used. In between, a PEP implementation may require modifications to only one of the ends involved. Either of these kind of PEP implementations is non-transparent, at least to the layer requiring modification.
另一方面，PEP实现可能需要对两端进行修改才能使用。在这两者之间，政治公众人物的实施可能只需要修改其中一个目的。这两种PEP实现都是不透明的，至少对需要修改的层是如此。
It is sometimes useful to think of the degree of transparency of a PEP implementation at four levels, transparency with respect to the end systems (network-layer transparent PEP), transparency with respect to the transport endpoints (transport-layer transparent PEP), transparency with respect to the applications (application-layer transparent PEP) and transparency with respect to the users. For example, a user who subscribes to a satellite Internet access service may be aware that the satellite terminal is providing a performance enhancing service even though the TCP/IP stack and the applications in the user's PC are not aware of the PEP which implements it.
有时，在四个级别上考虑PEP实现的透明度是有用的，即终端系统的透明度（网络层透明PEP）、传输端点的透明度（传输层透明PEP）、应用程序的透明度（应用程序层透明PEP）以及对用户的透明度。例如，订阅卫星因特网接入服务的用户可能知道卫星终端正在提供性能增强服务，即使TCP/IP堆栈和用户PC中的应用程序不知道实现该服务的PEP。
Note that the issue of transparency is not the same as the issue of maintaining end-to-end semantics. For example, a PEP implementation which simply uses a TCP ACK spacing mechanism maintains the end-to-end semantics of the TCP connection while a split connection TCP PEP implementation may not. Yet, both can be implemented transparently to the transport endpoints at both ends. The implications of not maintaining the end-to-end semantics, in particular the end-to-end semantics of TCP connections, are discussed in Section 4.
请注意，透明度的问题与维护端到端语义的问题不同。例如，简单使用TCP ACK间隔机制的PEP实现保持TCP连接的端到端语义，而拆分连接TCP PEP实现可能不这样做。然而，这两种方法都可以对两端的传输端点透明地实现。第4节讨论了不维护端到端语义，特别是TCP连接的端到端语义的含义。
An obvious key characteristic of a PEP implementation is the mechanism(s) it uses to improve performance. Some examples of PEP mechanisms are described in the following subsections. A PEP implementation might implement more than one of these mechanisms.
PEP实现的一个明显的关键特征是它用于提高性能的机制。以下小节介绍了PEP机制的一些示例。PEP实现可以实现这些机制中的多个。
Many TCP PEP implementations are based on TCP ACK manipulation. The handling of TCP acknowledgments can differ significantly between different TCP PEP implementations. The following subsections describe various TCP ACK handling mechanisms. Many implementations combine some of these mechanisms and possibly employ some additional mechanisms as well.
许多TCP PEP实现都基于TCP ACK操作。TCP确认的处理在不同的TCP PEP实现之间可能会有很大的不同。以下小节描述了各种TCP ACK处理机制。许多实现结合了这些机制中的一些，还可能采用一些附加机制。
In environments where ACKs tend to bunch together, ACK spacing is used to smooth out the flow of TCP acknowledgments traversing a link. This improves performance by eliminating bursts of TCP data segments that the TCP sender would send due to back-to-back arriving TCP acknowledgments [BPK97].
在应答倾向于聚集在一起的环境中，应答间隔用于平滑通过链路的TCP应答流。这通过消除TCP发送方由于背对背到达TCP确认而发送的TCP数据段突发来提高性能[BPK97]。
In some PEP implementations, TCP data segments received by the PEP are locally acknowledged by the PEP. This is very useful over network paths with a large bandwidth*delay product as it speeds up TCP slow start and allows the sending TCP to quickly open up its congestion window. Local (negative) acknowledgments are often also employed to trigger local (and faster) error recovery on links with significant error rates. (See Section 3.1.3.)
在一些PEP实现中，PEP接收的TCP数据段由PEP本地确认。这在具有大带宽*延迟乘积的网络路径上非常有用，因为它加快了TCP慢速启动，并允许发送TCP快速打开其拥塞窗口。本地（否定）确认通常也用于在错误率较高的链路上触发本地（更快）错误恢复。（见第3.1.3节。）
Local acknowledgments are automatically employed with split connection TCP implementations. When local acknowledgments are used, the burden falls upon the TCP PEP to recover any data which is dropped after the PEP acknowledges it.
本地确认自动用于拆分连接TCP实现。当使用本地确认时，TCP PEP有责任恢复PEP确认后丢弃的任何数据。
A TCP PEP may locally retransmit data segments lost on the path between the TCP PEP and the receiving end system, thus aiming at faster recovery from lost data. In order to achieve this the TCP PEP may use acknowledgments arriving from the end system that receives the TCP data segments, along with appropriate timeouts, to determine
TCP PEP可以本地重新传输在TCP PEP和接收端系统之间的路径上丢失的数据段，从而旨在更快地从丢失的数据中恢复。为了实现这一点，TCP PEP可以使用接收TCP数据段的终端系统发出的确认以及适当的超时来确定
when to locally retransmit lost data. TCP PEPs sending local acknowledgments to the sending end system are required to employ local retransmissions towards the receiving end system.
何时本地重新传输丢失的数据。向发送端系统发送本地确认的TCP PEP需要向接收端系统进行本地重传。
Some PEP implementations perform local retransmissions even though they do not use local acknowledgments to alter TCP connection performance. Basic Snoop [SNOOP] is a well know example of such a PEP implementation. Snoop caches TCP data segments it receives and forwards and then monitors the end-to-end acknowledgments coming from the receiving TCP end system for duplicate acknowledgments (DUPACKs). When DUPACKs are received, Snoop locally retransmits the lost TCP data segments from its cache, suppressing the DUPACKs flowing to the sending TCP end system until acknowledgments for new data are received. The Snoop system also implements an option to employ local negative acknowledgments to trigger local TCP retransmissions. This can be achieved, for example, by applying TCP selective acknowledgments locally on the error-prone link. (See Section 5.3 for details.)
一些PEP实现执行本地重传，即使它们不使用本地确认来改变TCP连接性能。基本Snoop[Snoop]是一个众所周知的PEP实现示例。Snoop缓存它接收和转发的TCP数据段，然后监视来自接收TCP端系统的端到端确认，以获取重复确认（DUPACKs）。当接收到DUPACK时，Snoop会从其缓存本地重新传输丢失的TCP数据段，从而抑制流向发送TCP端系统的DUPACK，直到接收到新数据的确认。Snoop系统还实现了一个使用本地否定确认来触发本地TCP重传的选项。例如，可以通过在容易出错的链路上本地应用TCP选择性确认来实现这一点。（详见第5.3节。）
On paths with highly asymmetric bandwidth the TCP ACKs flowing in the low-speed direction may get congested if the asymmetry ratio is high enough. The ACK filtering and reconstruction mechanism addresses this by filtering the ACKs on one side of the link and reconstructing the deleted ACKs on the other side of the link. The mechanism and the issue of dealing with TCP ACK congestion with highly asymmetric links are discussed in detail in [RFC2760] and in [BPK97].
在带宽高度不对称的路径上，如果不对称率足够高，则低速方向上流动的TCP ACK可能会拥塞。ACK过滤和重构机制通过过滤链路一侧的ACK并重构链路另一侧的已删除ACK来解决此问题。[RFC2760]和[BPK97]详细讨论了利用高度不对称链路处理TCP ACK拥塞的机制和问题。
A Performance Enhancing Proxy may encapsulate messages to carry the messages across a particular link or to force messages to traverse a particular path. A PEP at the other end of the encapsulation tunnel removes the tunnel wrappers before final delivery to the receiving end system. A tunnel might be used by a distributed split connection TCP implementation as the means for carrying the connection between the distributed PEPs. A tunnel might also be used to support forcing TCP connections which use asymmetric routing to go through the end points of a distributed PEP implementation.
性能增强代理可以封装消息，以跨特定链接传送消息或强制消息遍历特定路径。封装通道另一端的PEP在最终交付至接收端系统之前移除通道包装。分布式拆分连接TCP实现可以使用隧道作为在分布式PEP之间传输连接的手段。隧道也可用于支持强制使用非对称路由的TCP连接通过分布式PEP实现的端点。
Many PEP implementations include support for one or more forms of compression. In some PEP implementations, compression may even be the only mechanism used for performance improvement. Compression reduces the number of bytes which need to be sent across a link. This is useful in general and can be very important for bandwidth
许多PEP实现包括对一种或多种压缩形式的支持。在某些PEP实现中，压缩甚至可能是用于提高性能的唯一机制。压缩减少了需要通过链路发送的字节数。这在一般情况下是有用的，并且对带宽非常重要
limited links. Benefits of using compression include improved link efficiency and higher effective link utilization, reduced latency and improved interactive response time, decreased overhead and reduced packet loss rate over lossy links.
链接有限。使用压缩的好处包括提高链路效率和更高的有效链路利用率、减少延迟和改进交互响应时间、减少开销和降低有损链路上的数据包丢失率。
Where appropriate, link layer compression is used. TCP and IP header compression are also frequently used with PEP implementations. [RFC1144] describes a widely deployed method for compressing TCP headers. Other header compression algorithms are described in [RFC2507], [RFC2508] and [RFC2509].
在适当的情况下，使用链接层压缩。TCP和IP报头压缩也经常用于PEP实现。[RFC1144]描述了一种广泛部署的压缩TCP头的方法。[RFC2507]、[RFC2508]和[RFC2509]中描述了其他报头压缩算法。
Payload compression is also desirable and is increasing in importance with today's increased emphasis on Internet security. Network (IP) layer (and above) security mechanisms convert IP payloads into random bit streams which defeat applicable link layer compression mechanisms by removing or hiding redundant "information." Therefore, compression of the payload needs to be applied before security mechanisms are applied. [RFC2393] defines a framework where common compression algorithms can be applied to arbitrary IP segment payloads. However, [RFC2393] compression is not always applicable. Many types of IP payloads (e.g., images, audio, video and "zipped" files being transferred) are already compressed. And, when security mechanisms such as TLS [RFC2246] are applied above the network (IP) layer, the data is already encrypted (and possibly also compressed), again removing or hiding any redundancy in the payload. The resulting additional transport or network layer compression will compact only headers, which are small, and possibly already covered by separate compression algorithms of their own.
有效载荷压缩也是可取的，随着当今对互联网安全的日益重视，它的重要性也越来越高。网络（IP）层（及以上）安全机制将IP有效负载转换为随机比特流，通过删除或隐藏冗余“信息”来破坏适用的链路层压缩机制。因此，在应用安全机制之前，需要应用有效负载压缩。[RFC2393]定义了一个框架，通用压缩算法可应用于任意IP段有效负载。然而，[RFC2393]压缩并不总是适用的。许多类型的IP有效负载（例如，正在传输的图像、音频、视频和“压缩”文件）已经被压缩。并且，当诸如TLS[RFC2246]之类的安全机制应用于网络（IP）层之上时，数据已经被加密（并且可能也被压缩），再次移除或隐藏有效载荷中的任何冗余。由此产生的额外传输层或网络层压缩将仅压缩较小的报头，并且可能已经由各自的压缩算法覆盖。
With application layer PEPs one can employ application-specific compression. Typically an application-specific (or content-specific) compression mechanism is much more efficient than any generic compression mechanism. For example, a distributed Web PEP implementation may implement more efficient binary encoding of HTTP headers, or a PEP can employ lossy compression that reduces the image quality of online-images on Web pages according to end user instructions, thus reducing the number of bytes transferred over a slow link and consequently the response time perceived by the user [LHKR96].
使用应用层PEP，可以使用特定于应用程序的压缩。通常，特定于应用程序（或特定于内容）的压缩机制比任何通用压缩机制都要高效得多。例如，分布式Web PEP实现可以实现更高效的HTTP报头二进制编码，或者PEP可以采用有损压缩，根据最终用户指令降低网页上在线图像的图像质量，从而减少通过慢速链路传输的字节数，从而减少用户感知的响应时间[LHKR96]。
Periods of link disconnection or link outages are very common with some wireless links. During these periods, a TCP sender does not receive the expected acknowledgments. Upon expiration of the retransmit timer, this causes TCP to close its congestion window with all of the related drawbacks. A TCP PEP may monitor the traffic coming from the TCP sender towards the TCP receiver behind the
链路断开或链路中断的周期在某些无线链路中非常常见。在这些期间，TCP发送方不会收到预期的确认。当重传计时器过期时，这会导致TCP关闭其拥塞窗口，并具有所有相关的缺点。TCP PEP可以监控从TCP发送方到TCP接收方的流量
disconnected link. The TCP PEP retains the last ACK, so that it can shut down the TCP sender's window by sending the last ACK with a window set to zero. Thus, the TCP sender will go into persist mode.
断开连接。TCP PEP保留最后一个ACK，因此它可以通过发送窗口设置为零的最后一个ACK来关闭TCP发送方的窗口。因此，TCP发送方将进入持久模式。
To make this work in both directions with an integrated TCP PEP implementation, the TCP receiver behind the disconnected link must be aware of the current state of the connection and, in the event of a disconnection, it must be capable of freezing all timers. [M-TCP] implements such operation. Another possibility is that the disconnected link is surrounded by a distributed PEP pair.
为了通过集成的TCP PEP实现在两个方向上都能工作，断开连接后的TCP接收器必须知道连接的当前状态，并且在断开连接的情况下，必须能够冻结所有计时器。[M-TCP]实现了这样的操作。另一种可能性是断开的链路被分布式PEP对包围。
In split connection TCP implementations, a period of link disconnection can easily be hidden from the end host on the other side of the PEP thus precluding the TCP connection from breaking even if the period of link disconnection lasts a very long time; if the TCP PEP cannot forward data due to link disconnection, it stops receiving data. Normal TCP flow control then prevents the TCP sender from sending more than the TCP advertised window allowed by the PEP. Consequently, the PEP and its counterpart behind the disconnected link can employ a modified TCP version which retains the state and all unacknowledged data segments across the period of disconnection and then performs local recovery as the link is reconnected. The period of link disconnection may or may not be hidden from the application and user, depending upon what application the user is using the TCP connection for.
在分离连接TCP实现中，链路断开的周期可以很容易地对PEP另一侧的终端主机隐藏，从而防止TCP连接中断，即使链路断开的周期持续很长时间；如果TCP PEP由于链路断开而无法转发数据，它将停止接收数据。然后，正常的TCP流控制会阻止TCP发送方发送超过PEP允许的TCP播发窗口的数据。因此，PEP及其断开链路后的对应方可以采用修改的TCP版本，该版本在断开期间保留状态和所有未确认的数据段，然后在链路重新连接时执行本地恢复。链路断开的时间段可能对应用程序和用户隐藏，也可能不对应用程序和用户隐藏，这取决于用户使用TCP连接的应用程序。
Implementing priority-based multiplexing of data over a slow and expensive link may significantly improve the performance and usability of the link for selected applications or connections.
在缓慢且昂贵的链路上实现基于优先级的数据多路复用可以显著提高所选应用程序或连接的性能和可用性。
A user behind a slow link would experience the link more feasible to use in case of simultaneous data transfers, if urgent data transfers (e.g., interactive connections) could have shorter response time (better performance) than less urgent background transfers. If the interactive connections transmit enough data to keep the slow link fully utilized, it might be necessary to fully suspend the background transfers for awhile to ensure timely delivery for the interactive connections.
如果紧急数据传输（例如，交互式连接）的响应时间比不太紧急的后台传输短（性能更好），则慢速链接后面的用户将体验到在同时数据传输的情况下更适合使用的链接。如果交互式连接传输足够的数据以保持慢速链接的充分利用，则可能需要完全暂停后台传输一段时间，以确保交互式连接的及时交付。
In flight TCP segments of an end-to-end TCP connection (with low priority) cannot be delayed for a long time. Otherwise, the TCP timer at the sending end would expire, resulting in suboptimal performance. However, this kind of operation can be controlled in conjunction with a split connection TCP PEP by assigning different priorities for different connections (or applications). A split connection PEP implementation allows the PEP in an intermediate node
端到端TCP连接（低优先级）的飞行中TCP段不能延迟很长时间。否则，发送端的TCP计时器将过期，导致性能不佳。但是，这种操作可以通过为不同的连接（或应用程序）分配不同的优先级，与分割连接TCP PEP一起进行控制。拆分连接PEP实现允许PEP位于中间节点中
to delay the data delivery of a lower-priority TCP flow for an unlimited period of time by simply rescheduling the order in which it forwards data of different flows to the destination host behind the slow link. This does not have a negative impact on the delayed TCP flow as normal TCP flow control takes care of suspending the flow between the TCP sender and the PEP, when the PEP is not forwarding data for the flow, and resumes it once the PEP decides to continue forwarding data for the flow. This can further be assisted, if the protocol stacks on both sides of the slow link implement priority based scheduling of connections.
通过简单地重新安排将不同流的数据转发到慢链路后面的目标主机的顺序，将低优先级TCP流的数据传递延迟无限时间。这不会对延迟的TCP流产生负面影响，因为当PEP不转发流的数据时，正常的TCP流控制会暂停TCP发送方和PEP之间的流，并在PEP决定继续转发流的数据时恢复。如果慢速链路两侧的协议栈实现基于优先级的连接调度，则这可以进一步得到帮助。
With such a PEP implementation, along with user-controlled priorities, the user can assign higher priority for selected interactive connection(s) and have much shorter response time for the selected connection(s), even if there are simultaneous low priority bulk data transfers which in regular end-to-end operation would otherwise eat the available bandwidth of the slow link almost completely. These low priority bulk data transfers would then proceed nicely during the idle periods of interactive connections, allowing the user to keep the slow and expensive link (e.g., wireless WAN) fully utilized.
通过这样的PEP实现，以及用户控制的优先级，用户可以为所选交互连接分配更高的优先级，并且对于所选连接具有更短的响应时间，即使存在同步的低优先级批量数据传输，在常规的端到端操作中，这些数据传输也会几乎完全占用慢速链路的可用带宽。然后，这些低优先级的批量数据传输将在交互连接的空闲期间顺利进行，使用户能够充分利用缓慢而昂贵的链路（例如，无线WAN）。
Other priority-based mechanisms may be applied on shared wireless links with more than two terminals. With shared wireless mediums becoming a weak link in Internet QoS architectures, many may turn to PEPs to provide extra priority levels across a shared wireless medium [SHEL00]. These PEPs are distributed on all nodes of the shared wireless medium. For example, in an 802.11 WLAN this PEP is implemented in the access point (base station) and each mobile host. One PEP then uses distributed queuing techniques to coordinate traffic classes of all nodes. This is also sometimes called subnet bandwidth management. See [BBKT97] for an example of queuing techniques which can be used to achieve this. This technique can be implemented either above or below the IP layer. Priority treatment can typically be specified either by the user or by marking the (IPv4) ToS or (IPv6) Traffic Class IP header field.
其他基于优先级的机制可应用于具有两个以上终端的共享无线链路上。随着共享无线介质成为Internet QoS体系结构中的薄弱环节，许多人可能会求助于PEP来跨共享无线介质提供额外的优先级[SHEL00]。这些PEP分布在共享无线媒体的所有节点上。例如，在802.11 WLAN中，该PEP在接入点（基站）和每个移动主机中实现。一个PEP然后使用分布式排队技术来协调所有节点的流量类别。这有时也称为子网带宽管理。参见[BBKT97]了解可用于实现此目的的排队技术示例。这种技术可以在IP层之上或之下实现。优先级处理通常可以由用户指定，也可以通过标记（IPv4）ToS或（IPv6）流量类IP头字段来指定。
Work in [FMSBMR98] shows a range of other possible PEP mechanisms called protocol boosters. Some of these mechanisms are specific to UDP flows. For example, a PEP may apply asymmetrical methods such as extra UDP error detection. Since the 16 bit UDP checksum is optional, it is typically not computed. However, for links with errors, the checksum could be beneficial. This checksum can be added to outgoing UDP packets by a PEP.
[FMSBMR98]中的工作显示了一系列其他可能的PEP机制，称为协议助推器。其中一些机制特定于UDP流。例如，PEP可以应用非对称方法，例如额外的UDP错误检测。由于16位UDP校验和是可选的，因此通常不进行计算。然而，对于有错误的链接，校验和可能是有益的。PEP可以将该校验和添加到传出UDP数据包中。
Symmetrical mechanisms have also been developed. A Forward Erasure Correction (FZC) mechanism can be used with real-time and multicast traffic. The encoding PEP adds a parity packet over a block of packets. Upon reception, the parity is removed and missing data is regenerated. A jitter control mechanism can be implemented at the expense of extra latency. A sending PEP can add a timestamp to outgoing packets. The receiving PEP then delays packets in order to reproduce the correct interval.
对称机构也已开发出来。前向擦除校正（FZC）机制可用于实时和多播流量。编码PEP在数据包块上添加奇偶校验数据包。接收时，奇偶校验被删除，丢失的数据被重新生成。可以以额外延迟为代价来实现抖动控制机制。发送PEP可以向发送的数据包添加时间戳。然后，接收PEP延迟数据包以再现正确的间隔。
The following sections describe some of the implications of using Performance Enhancing Proxies.
以下部分描述了使用性能增强代理的一些含义。
As indicated in [RFC1958], the end-to-end argument [SRC84] is one of the architectural principles of the Internet. The basic argument is that, as a first principle, certain required end-to-end functions can only be correctly performed by the end systems themselves. Most of the potential negative implications associated with using PEPs are related to the possibility of breaking the end-to-end semantics of connections. This is one of the main reasons why PEPs are not recommended for general use.
如[RFC1958]所述，端到端参数[SRC84]是互联网的架构原则之一。基本论点是，作为第一条原则，某些必需的端到端功能只能由端系统本身正确执行。与使用PEP相关的大多数潜在负面影响都与破坏连接的端到端语义的可能性有关。这是不建议将PEP用于一般用途的主要原因之一。
As indicated in Section 2.5, not all PEP implementations break the end-to-end semantics of connections. Correctly designed PEPs do not attempt to replace any application level end-to-end function, but only attempt to add performance optimizations to a subpath of the end-to-end path between the application endpoints. Doing this can be consistent with the end-to-end argument. However, a user or network administrator adding a PEP to his network configuration should be aware of the potential end-to-end implications related to the mechanisms being used by the particular PEP implementation.
如第2.5节所述，并非所有PEP实现都会破坏连接的端到端语义。正确设计的PEP不会尝试替换任何应用程序级端到端功能，而只会尝试向应用程序端点之间的端到端路径的子路径添加性能优化。这样做可以与端到端参数保持一致。但是，将PEP添加到其网络配置中的用户或网络管理员应了解与特定PEP实现所使用的机制相关的潜在端到端影响。
In most cases, security applied above the transport layer can be used with PEPs, especially transport layer PEPs. However, today, only a limited number of applications include support for the use of transport (or higher) layer security. Network (IP) layer security (IPsec) [RFC2401], on the other hand, can generally be used by any application, transparently to the application.
在大多数情况下，应用于传输层之上的安全性可用于PEP，尤其是传输层PEP。然而，目前只有少数应用程序支持使用传输（或更高）层安全性。另一方面，网络（IP）层安全性（IPsec）[RFC2401]通常可以被任何应用程序透明地使用。
The most detrimental negative implication of breaking the end-to-end semantics of a connection is that it disables end-to-end use of IPsec. In general, a user or network administrator must choose between using PEPs and using IPsec. If IPsec is employed end-to-end, PEPs that are implemented on intermediate nodes in the network cannot examine the transport or application headers of IP packets because encryption of IP packets via IPsec's ESP header (in either transport or tunnel mode) renders the TCP header and payload unintelligible to the PEPs. Without being able to examine the transport or application headers, a PEP may not function optimally or at all.
破坏连接的端到端语义的最有害的负面影响是它禁用了IPsec的端到端使用。通常，用户或网络管理员必须在使用PEPs和使用IPsec之间进行选择。如果采用端到端IPsec，则在网络中间节点上实现的PEP无法检查IP数据包的传输或应用程序报头，因为通过IPsec的ESP报头（在传输或隧道模式下）对IP数据包进行加密会使PEP无法理解TCP报头和有效负载。如果不能检查传输或应用程序头，PEP可能无法最佳运行或根本无法正常运行。
If a PEP implementation is non-transparent to the users and the users trust the PEP in the middle, IPsec can be used separately between each end system and PEP. However, in most cases this is an undesirable or unacceptable alternative as the end systems cannot trust PEPs in general. In addition, this is not as secure as end-to-end security. (For example, the traffic is exposed in the PEP when it is decrypted to be processed.) And, it can lead to potentially misleading security level assumptions by the end systems. If the two end systems negotiate different levels of security with the PEP, the end system which negotiated the stronger level of security may not be aware that a lower level of security is being provided for part of the connection. The PEP could be implemented to prevent this from happening by being smart enough to force the same level of security to each end system but this increases the complexity of the PEP implementation (and still is not as secure as end-to-end security).
如果PEP实现对用户是非透明的，并且用户在中间信任PEP，则可以在每个端系统和PEP之间单独使用IPSec。然而，在大多数情况下，这是一种不受欢迎或不可接受的替代方案，因为终端系统通常不能信任PEP。此外，这不如端到端安全性那么安全。（例如，当对流量进行解密以进行处理时，该流量在PEP中公开。）并且，它可能导致终端系统对安全级别的假设产生潜在误导。如果两个终端系统与PEP协商不同的安全级别，则协商较高安全级别的终端系统可能不知道为部分连接提供了较低的安全级别。可以通过足够聪明的方式来实现PEP，以防止这种情况发生，从而强制每个终端系统具有相同的安全级别，但这增加了PEP实现的复杂性（并且仍然不如端到端安全性那么安全）。
With a transparent PEP implementation, it is difficult for the end systems to trust the PEP because they may not be aware of its existence. Even if the user is aware of the PEP, setting up acceptable security associations with the PEP while maintaining the PEP's transparent nature is problematic (if not impossible).
对于透明的政治公众人物实施，终端系统很难信任政治公众人物，因为他们可能不知道政治公众人物的存在。即使用户知道PEP，在保持PEP的透明性的同时与PEP建立可接受的安全关联也是有问题的（如果不是不可能的话）。
Note that even when a PEP implementation does not break the end-to-end semantics of a connection, the PEP implementation may not be able to function in the presence of IPsec. For example, it is difficult to do ACK spacing if the PEP cannot reliably determine which IP packets contain ACKs of interest. In any case, the authors are currently not aware of any PEP implementations, transparent or non-transparent, which provide support for end-to-end IPsec, except in a case where the PEPs are implemented on the end hosts.
请注意，即使PEP实现没有破坏连接的端到端语义，PEP实现也可能无法在存在IPsec的情况下运行。例如，如果PEP不能可靠地确定哪些IP数据包包含感兴趣的ACK，则很难确定ACK间隔。在任何情况下，作者目前都不知道有任何PEP实现（透明或非透明）提供对端到端IPsec的支持，但PEP在终端主机上实现的情况除外。
There are some steps which can be taken to allow the use of IPsec and PEPs to coexist. If an end user can select the use of IPsec for some traffic and not for other traffic, PEP processing can be applied to the traffic sent without IPsec. Of course, the user must then do without security for this traffic or provide security for the traffic via other means (for example, by using transport layer security). However, even when this is possible, significant complexity may need to be added to the configuration of the end system.
可以采取一些步骤来允许IPsec和PEP的使用共存。如果最终用户可以选择对某些流量而不是其他流量使用IPsec，则可以对不使用IPsec发送的流量应用PEP处理。当然，用户必须在没有安全性的情况下处理此流量，或者通过其他方式（例如，通过使用传输层安全性）为流量提供安全性。然而，即使这是可能的，也可能需要向终端系统的配置中添加显著的复杂性。
Another alternative is to implement IPsec between the two PEPs of a distributed PEP implementation. This at least protects the traffic between the two PEPs. (The issue of trusting the PEPs does not change.) In the case where the PEP implementation is not transparent to the user, (assuming that the user trusts the PEPs,) the user can configure his end system to use the PEPs as the end points of an IPsec tunnel. And, an IPsec tunnel could even potentially be used between the end system and a PEP to protect traffic on this part of the path. But, all of this adds complexity. And, it still does not eliminate the risk of the traffic being exposed in the PEP itself as the traffic is received from one IPsec tunnel, processed and then forwarded (even if forwarded through another IPsec tunnel).
另一种选择是在分布式PEP实现的两个PEP之间实现IPsec。这至少可以保护两个PEP之间的通信量。（信任PEP的问题没有改变。）在PEP实施对用户不透明的情况下（假设用户信任PEP），用户可以将其终端系统配置为使用PEP作为IPsec隧道的端点。而且，在终端系统和PEP之间甚至可能使用IPsec隧道来保护这部分路径上的流量。但是，所有这些都增加了复杂性。而且，当从一个IPsec隧道接收、处理然后转发（即使通过另一个IPsec隧道转发）流量时，它仍然不能消除在PEP本身中暴露流量的风险。
There is research underway investigating the possibility of changing the implementation of IPsec to be more friendly to the use of PEPs. One approach being actively looked at is the use of multi-layer IP security. [Zhang00] describes a method which allows TCP headers to be encrypted as one layer (with the PEPs in the path of the TCP connections included in the security associations used to encrypt the TCP headers) while the TCP payload is encrypted end-to-end as a separate layer. This still involves trusting the PEP, but to a much lesser extent. However, a drawback to this approach is that it adds a significant amount of complexity to the IP security implementation. Given the existing complexity of IPsec, this drawback is a serious impediment to the standardization of the multi-layer IP security idea and it is very unlikely that this approach will be adopted as a standard any time soon. Therefore, relying on this type of approach will likely involve the use of non-standard protocols (and the associated risk of doing so).
目前正在进行研究，调查是否有可能改变IPsec的实现，使其对PEP的使用更加友好。正在积极研究的一种方法是使用多层IP安全。[Zhang00]描述了一种方法，该方法允许将TCP报头作为一个层进行加密（在用于加密TCP报头的安全关联中包括TCP连接路径中的PEP），同时将TCP有效负载作为一个单独的层进行端到端加密。这仍然包括信任政治公众人物，但程度要小得多。然而，这种方法的一个缺点是它给IP安全实现增加了大量的复杂性。鉴于IPsec的现有复杂性，这一缺陷严重阻碍了多层IP安全思想的标准化，而且这种方法不太可能在短期内被采用为标准。因此，依赖这种方法可能会涉及使用非标准协议（以及这样做的相关风险）。
Another important aspect of the end-to-end argument is fate sharing. If a failure occurs in the network, the ability of the connection to survive the failure depends upon how much state is being maintained
端到端争论的另一个重要方面是命运共享。如果网络中发生故障，连接在故障中生存的能力取决于所保持的状态
on behalf of the connection in the network and whether the state is self-healing. If no connection specific state resides in the network or such state is self-healing as in case of regular end-to-end operation, then a failure in the network will break the connection only if there is no alternate path through the network between the end systems. And, if there is no path, both end systems can detect this. However, if the connection depends upon some state being stored in the network (e.g., in a PEP), then a failure in the network (e.g., the node containing a PEP crashes) causes this state to be lost, forcing the connection to terminate even if an alternate path through the network exists.
代表网络中的连接和状态是否为自愈。如果网络中没有特定于连接的状态，或者这种状态与常规端到端操作一样是自愈状态，则只有在端系统之间没有通过网络的备用路径时，网络中的故障才会中断连接。如果没有路径，两个终端系统都可以检测到这一点。然而，如果连接取决于网络中存储的某些状态（例如，在PEP中），则网络中的故障（例如，包含PEP的节点崩溃）会导致该状态丢失，即使存在通过网络的备用路径，连接也会终止。
The importance of this aspect of the end-to-end argument with respect to PEPs is dependent upon both the PEP implementation and upon the types of applications being used. Sometimes coincidentally but more often by design, PEPs are used in environments where there is no alternate path between the end systems and, therefore, a failure of the intermediate node containing a PEP would result in the termination of the connection in any case. And, even when this is not the case, the risk of losing the connection in the case of regular end-to-end operation may exist as the connection could break for some other reason, for example, a long enough link outage of a last-hop wireless link to the end host. Therefore, users may choose to accept the risk of a PEP crashing in order to take advantage of the performance gains offered by the PEP implementation. The important thing is that accepting the risk should be under the control of the user (i.e., the user should always have the option to choose end-to-end operation) and, if the user chooses to use the PEP, the user should be aware of the implications that a PEP failure has with respect to the applications being used.
关于PEP，端到端参数的这一方面的重要性取决于PEP实现和所使用的应用程序类型。有时巧合，但更多的情况是设计上，PEP用于终端系统之间没有备用路径的环境中，因此，包含PEP的中间节点的故障在任何情况下都会导致连接终止。而且，即使情况并非如此，在常规端到端操作的情况下，也可能存在丢失连接的风险，因为连接可能由于某些其他原因而中断，例如，到终端主机的最后一跳无线链路中断足够长的时间。因此，用户可以选择接受政治公众人物崩溃的风险，以利用政治公众人物实施带来的性能提升。重要的是，接受风险应由用户控制（即，用户应始终可以选择端到端操作），如果用户选择使用PEP，则用户应了解PEP故障对所用应用程序的影响。
Another aspect of the end-to-end argument is that of acknowledging the receipt of data end-to-end in order to achieve reliable end-to-end delivery of data. An application aiming at reliable end-to-end delivery must implement an end-to-end check and recovery at the application level. According to the end-to-end argument, this is the only possibility to correctly implement reliable end-to-end operation. Otherwise the application violates the end-to-end argument. This also means that a correctly designed application can never fully rely on the transport layer (e.g., TCP) or any other communication subsystem to provide reliable end-to-end delivery.
端到端论证的另一个方面是确认端到端数据的接收，以实现可靠的端到端数据交付。旨在实现可靠端到端交付的应用程序必须在应用程序级别实现端到端检查和恢复。根据端到端的论点，这是正确实现可靠的端到端操作的唯一可能性。否则，应用程序将违反端到端参数。这也意味着，正确设计的应用程序永远不能完全依赖传输层（如TCP）或任何其他通信子系统来提供可靠的端到端交付。
First, a TCP connection may break down for some reason and result in lost data that must be recovered at the application level. Second, the checksum provided by TCP may be considered inadequate, resulting in undetected (by TCP) data corruption [Pax99] and requiring an
首先，TCP连接可能由于某种原因而中断，导致必须在应用程序级别恢复的数据丢失。其次，TCP提供的校验和可能被认为不充分，导致（TCP）未检测到的数据损坏[Pax99]，并需要
application level check for data corruption. Third, a TCP acknowledgement only indicates that data was delivered to the TCP implementation on the other end system. It does not guarantee that the data was delivered to the application layer on the other end system. Therefore, a well designed application must use an application layer acknowledgement to ensure end-to-end delivery of application layer data. Note that this does not diminish the value of a reliable transport protocol (i.e., TCP) as such a protocol allows efficient implementation of several essential functions (e.g., congestion control) for an application.
应用程序级检查数据损坏。第三，TCP确认仅表示数据已传递到另一端系统上的TCP实现。它不能保证数据被传送到另一端系统的应用层。因此，设计良好的应用程序必须使用应用程序层确认来确保应用程序层数据的端到端交付。注意，这不会降低可靠传输协议（即TCP）的价值，因为这样的协议允许有效地实现应用程序的几个基本功能（例如拥塞控制）。
If a PEP implementation acknowledges application data prematurely (before the PEP receives an application ACK from the other endpoint), end-to-end reliability cannot be guaranteed. Typically, application layer PEPs do not acknowledge data prematurely, i.e., the PEP does not send an application ACK to the sender until it receives an application ACK from the receiver. And, transport layer PEP implementations, including TCP PEPs, generally do not interfere with end-to-end application layer acknowledgments as they let applications operate end-to-end. However, the user and/or network administrator employing the PEP must understand how it operates in order to understand the risks related to end-to-end reliability.
如果PEP实现过早地确认应用程序数据（在PEP从另一个端点接收到应用程序确认之前），则无法保证端到端的可靠性。通常，应用层PEP不会过早地确认数据，即，PEP在从接收方接收到应用ACK之前不会向发送方发送应用ACK。而且，传输层PEP实现（包括TCP PEP）通常不会干扰端到端应用层确认，因为它们允许应用程序端到端运行。但是，使用PEP的用户和/或网络管理员必须了解其运行方式，以便了解与端到端可靠性相关的风险。
Some Internet applications do not necessarily operate end-to-end in their regular operation, thus abandoning any end-to-end reliability guarantee. For example, Internet email delivery often operates via relay Mail Transfer Agents, that is, relay Simple Mail Transfer Protocol (SMTP) servers. An originating MTA (SMTP server) sends the mail message to a relay MTA that receives the mail message, stores it in non-volatile storage (e.g., on disk) and then sends an application level acknowledgement. The relay MTA then takes "full responsibility" for delivering the mail message to the destination SMTP server (maybe via another relay MTA); it tries to forward the message for a relatively long time (typically around 5 days). This scheme does not give a 100% guarantee of email delivery, but reliability is considered "good enough".
一些Internet应用程序在正常运行时不一定要端到端运行，因此放弃了任何端到端的可靠性保证。例如，Internet电子邮件传递通常通过中继邮件传输代理进行操作，即中继简单邮件传输协议（SMTP）服务器。原始MTA（SMTP服务器）将邮件发送到中继MTA，中继MTA接收邮件，将邮件存储在非易失性存储器（例如，磁盘）中，然后发送应用程序级确认。中继MTA然后承担将邮件消息传递到目标SMTP服务器的“全部责任”（可能通过另一个中继MTA）；它尝试将消息转发一段相对较长的时间（通常大约5天）。该方案不能保证100%的电子邮件发送，但可靠性被认为“足够好”。
An application layer PEP for this kind of an application may acknowledge application data (e.g., mail message) without essentially decreasing reliability, as long as the PEP operates according to the same procedure as the regular proxy (e.g., relay MTA). Again, as indicated above, the user and/or network administrator employing such a PEP needs to understand how it operates in order to understand the reliability risks associated with doing so.
这种应用程序的应用层PEP可以确认应用程序数据（例如，邮件消息），而不会从本质上降低可靠性，只要PEP按照与常规代理（例如，中继MTA）相同的程序操作即可。同样，如上所述，采用此类PEP的用户和/或网络管理员需要了解其操作方式，以便了解与此相关的可靠性风险。
Another aspect of the end-to-end argument is the ability to support end-to-end failure diagnostics when problems are encountered. If a network problem occurs which breaks a connection, the end points of the connection will detect the failure via timeouts. However, the existence of a PEP in between the two end points could delay (sometimes significantly) the detection of the failure by one or both of the end points. (Of course, some PEPs are intentionally designed to hide these types of failures as described in Section 3.4.) The implications of delayed detection of a failed connection depend on the applications being used. Possibilities range from no impact at all (or just minor annoyance to the end user) all the way up to impacting mission critical business functions by delaying switchovers to alternate communications paths.
端到端参数的另一个方面是在遇到问题时支持端到端故障诊断的能力。如果出现中断连接的网络问题，连接的端点将通过超时检测故障。然而，在两个端点之间存在PEP可能延迟（有时显著延迟）一个或两个端点对故障的检测。（当然，一些PEP被有意设计为隐藏这些类型的故障，如第3.4节所述。）延迟检测故障连接的影响取决于所使用的应用程序。可能性从根本没有影响（或对最终用户来说只是小麻烦）一直到通过延迟切换到备用通信路径而影响任务关键型业务功能。
In addition, tools used to debug connection failures may be affected by the use of a PEP. For example, PING (described in [RFC792] and [RFC2151]) is often used to test for connectivity. But, because PING is based on ICMP instead of TCP (i.e., it is implemented using ICMP Echo and Reply commands at the network layer), it is possible that the configuration of the network might route PING traffic around the PEP. Thus, PING could indicate that an end-to-end path exists between two hosts when it does not actually exist for TCP traffic. Even when the PING traffic does go through the PEP, the diagnostics indications provided by the PING traffic are altered. For example, if the PING traffic goes transparently through the PEP, PING does not provide any indication that the PEP exists and since the PING traffic is not being subjected to the same processing as TCP traffic, it may not necessarily provide an accurate indication of the network delay being experienced by TCP traffic. On the other hand, if the PEP terminates the PING and responds to it on behalf of the end host, then the PING provides information only on the connectivity to the PEP. Traceroute (also described in [RFC2151]) is similarly affected by the presence of the PEP.
此外，用于调试连接故障的工具可能会受到PEP使用的影响。例如，PING（在[RFC792]和[RFC2151]中描述）通常用于测试连接性。但是，由于PING基于ICMP而不是TCP（即，它是在网络层使用ICMP Echo和Reply命令实现的），因此网络配置可能会在PEP周围路由PING流量。因此，PING可能表示两台主机之间存在一条端到端路径，而TCP流量实际上并不存在该路径。即使PING流量通过PEP，PING流量提供的诊断指示也会改变。例如，如果PING通信量透明地通过PEP，那么PING不提供PEP存在的任何指示，并且由于PING通信量没有受到与TCP通信量相同的处理，因此它可能不一定提供TCP通信量所经历的网络延迟的准确指示。另一方面，如果PEP终止PING并代表终端主机响应，则PING仅提供与PEP连接的信息。示踪路由（也在[RFC2151]中描述）同样受到PEP存在的影响。
Deploying a PEP implementation usually requires that traffic to and from the end hosts is routed through the intermediate node(s) where PEPs reside. With some networks, this cannot be accomplished, or it might require that the intermediate node is located several hops away from the target link edge which in turn is impractical in many cases and may result in non-optimal routing.
部署PEP实现通常需要通过PEP驻留的中间节点路由往返于终端主机的流量。对于某些网络，这是无法实现的，或者可能需要中间节点距离目标链路边缘几跳，这在许多情况下是不切实际的，并且可能导致非最优路由。
Note that this restriction does not apply to all PEP implementations. For example, a PEP which is simply doing ACK spacing only needs to see one direction of the traffic flow (the direction in which the ACKs are flowing). ACK spacing can be done without seeing the actual flow of data.
请注意，此限制不适用于所有PEP实施。例如，简单地执行ACK间隔的PEP只需要看到业务流的一个方向（ACK的流动方向）。确认间隔可以在看不到实际数据流的情况下完成。
In environments where a PEP implementation is used to serve mobile hosts, additional problems may be encountered because PEP related state information may need to be transferred to a new PEP node during a handoff.
在使用PEP实现服务于移动主机的环境中，可能会遇到其他问题，因为在切换期间可能需要将PEP相关的状态信息传输到新的PEP节点。
When a mobile host moves, it is subject to handovers. If the intermediate node and home for the serving PEP changes due to handover, any state information that the PEP maintains and is required for continuous operation must be transferred to the new intermediate node to ensure continued operation of the connection. This requires extra work and overhead and may not be possible to perform fast enough, especially if the host moves frequently over cell boundaries of a wireless network. If the mobile host moves to another IP network, routing to and from the mobile host may need to be changed to traverse a new PEP node.
当移动主机移动时，会进行切换。如果服务PEP的中间节点和主节点由于切换而发生变化，则PEP维护的以及连续运行所需的任何状态信息都必须传输到新的中间节点，以确保连接的持续运行。这需要额外的工作和开销，并且可能无法足够快地执行，特别是当主机频繁地在无线网络的小区边界上移动时。如果移动主机移动到另一个IP网络，则可能需要更改进出移动主机的路由以遍历新的PEP节点。
Today, mobility implications with respect to using PEPs are more significant to W-LAN networks than to W-WAN networks. Currently, a W-WAN base station typically does not provide the mobile host with the connection point to the wireline Internet. (A W-WAN base station may not even have an IP stack.) Instead, the W-WAN network takes care of mobility with the connection point to the wireline Internet remaining unchanged while the mobile host moves. Thus, PEP state handover is not currently required in most W-WAN networks when the host moves. However, this is generally not true in W-LAN networks and, even in the case of W-WAN networks, the user and/or network administrator using a PEP needs to be cognizant of how the W-WAN base stations and the PEP work in case W-WAN PEP state handoff becomes necessary in the future.
今天，与使用PEP有关的移动性影响对于W-LAN网络比W-WAN网络更为重要。目前，W-WAN基站通常不向移动主机提供到有线因特网的连接点。（W-WAN基站甚至可能没有IP堆栈。）相反，W-WAN网络负责移动性，在移动主机移动时，到有线因特网的连接点保持不变。因此，当主机移动时，大多数W-WAN网络中目前不需要PEP状态切换。然而，这在W-LAN网络中通常是不正确的，并且即使在W-WAN网络的情况下，使用PEP的用户和/或网络管理员也需要知道在将来需要W-WAN PEP状态切换的情况下W-WAN基站和PEP如何工作。
Because a PEP typically processes packet information above the IP layer, a PEP requires more processing power per packet than a router. Therefore, PEPs will always be (at least) one step behind routers in terms of the total throughput they can support. (Processing above the IP layer is also more difficult to implement in hardware.) In addition, since most PEP implementations require per connection state, PEP memory requirements are generally significantly higher
由于PEP通常在IP层上处理数据包信息，因此PEP对每个数据包的处理能力要求高于路由器。因此，就其所能支持的总吞吐量而言，PEP将始终（至少）落后于路由器一步。（IP层以上的处理也更难在硬件中实现。）此外，由于大多数PEP实现需要每个连接状态，因此PEP内存要求通常要高得多
than with a router. Therefore, a PEP implementation may have a limit on the number of connections which it can support whereas a router has no such limitation.
而不是用路由器。因此，PEP实现可能对其可支持的连接数量有限制，而路由器没有此类限制。
Increased processing power and memory requirements introduce scalability issues with respect to the use of PEPs. Placement of a PEP on a high speed link or a link which supports a large number of connections may require network topology changes beyond just inserting the PEP into the path of the traffic. For example, if a PEP can only handle half of the traffic on a link, multiple PEPs may need to be used in parallel, adding complexity to the network configuration to divide the traffic between the PEPs.
随着处理能力和内存需求的增加，PEP的使用会带来可伸缩性问题。将PEP放置在高速链路或支持大量连接的链路上可能需要改变网络拓扑，而不仅仅是将PEP插入流量路径。例如，如果一个PEP只能处理一条链路上一半的流量，则可能需要并行使用多个PEP，从而增加了网络配置的复杂性，以在PEP之间分配流量。
This document describes some significant implications with respect to using Performance Enhancing Proxies. However, the list of implications provided in this document is not necessarily exhaustive. Some examples of other potential implications related to using PEPs include the use of PEPs in multi-homing environments and the use of PEPs with respect to Quality of Service (QoS) transparency. For example, there may be potential interaction with the priority-based multiplexing mechanism described in Section 3.5 and the use of differentiated services [RFC2475]. Therefore, users and network administrators who wish to deploy a PEP should look not only at the implications described in this document but also at the overall impact (positive and negative) that the PEP will have on their applications and network infrastructure, both initially and in the future when new applications are added and/or changes in the network infrastructure are required.
本文档描述了有关使用性能增强代理的一些重要含义。然而，本文件中提供的影响清单并不一定详尽无遗。与使用PEP相关的其他潜在影响的一些示例包括在多主环境中使用PEP以及在服务质量（QoS）透明度方面使用PEP。例如，可能存在与第3.5节中描述的基于优先级的多路复用机制以及区分服务的使用[RFC2475]的潜在交互。因此，希望部署PEP的用户和网络管理员不仅应考虑本文档中所述的影响，还应考虑PEP对其应用程序和网络基础设施的总体影响（正面和负面），最初和将来都需要添加新的应用程序和/或更改网络基础设施。
The following sections describe examples of environments where PEP is currently used to improve performance. The examples are provided to illustrate the use of the various PEP types and PEP mechanisms described earlier in the document and to help illustrate the motivation for their development and use.
以下各节介绍了当前使用PEP提高性能的环境示例。提供这些示例是为了说明文件前面描述的各种政治公众人物类型和政治公众人物机制的使用，并帮助说明其开发和使用的动机。
Today, VSAT networks are implemented with geosynchronous satellites. VSAT data networks are typically implemented using a star topology. A large hub earth station is located at the center of the star with VSATs used at the remote sites of the network. Data is sent from the hub to the remote sites via an outroute. Data is sent from the remote sites to the hub via one or more inroutes. VSATs represent an environment with highly asymmetric links, with an outroute typically
今天，VSAT网络由地球同步卫星实施。VSAT数据网络通常采用星形拓扑结构。一个大型集线器地球站位于星体中心，VSAT用于网络的远程站点。数据通过出站路由从集线器发送到远程站点。数据通过一条或多条InRoute从远程站点发送到集线器。VSAT代表了一个具有高度不对称链路的环境，通常具有一个出站路由
much larger than an inroute. (Multiple inroutes can be used with each outroute but any particular VSAT only has access to a single inroute at a time, making the link asymmetric.)
比在路上的要大得多。（每条出站路由可以使用多条入站路由，但任何特定VSAT一次只能访问一条入站路由，从而使链路不对称。）
VSAT networks are generally used to implement private networks (i.e., intranets) for enterprises (e.g., corporations) with geographically dispersed sites. VSAT networks are rarely, if ever, used to implement Internet connectivity except at the edge of the Internet (i.e., as the last hop). Connection to the Internet for the VSAT network is usually implemented at the VSAT network hub site using appropriate firewall and (when necessary) NAT [RFC2663] devices.
VSAT网络通常用于为地理位置分散的企业（如公司）实施专用网络（即内部网）。VSAT网络很少（如果有的话）用于实现互联网连接，除非是在互联网边缘（即作为最后一跳）。VSAT网络的互联网连接通常在VSAT网络集线器站点使用适当的防火墙和（必要时）NAT[RFC2663]设备实现。
With respect to TCP performance, VSAT networks exhibit the following subset of the satellite characteristics documented in [RFC2488]:
关于TCP性能，VSAT网络表现出[RFC2488]中记录的卫星特性的以下子集：
Long feedback loops
长反馈回路
Propagation delay from a sender to a receiver in a geosynchronous satellite network can range from 240 to 280 milliseconds, depending on where the sending and receiving sites are in the satellite footprint. This makes the round trip time just due to propagation delay at least 480 milliseconds. Queueing delay and delay due to shared channel access methods can sometimes increase the total delay up to on the order of a few seconds.
在地球同步卫星网络中，从发送方到接收方的传播延迟可以在240到280毫秒之间，这取决于发送和接收站点在卫星覆盖区中的位置。这使得仅由于传播延迟而产生的往返时间至少为480毫秒。排队延迟和共享通道访问方法导致的延迟有时会将总延迟增加到几秒钟左右。
Large bandwidth*delay products
大带宽*延迟产品
VSAT networks can support capacity ranging from a few kilobits per second up to multiple megabits per second. When combined with the relatively long round trip time, TCP needs to keep a large number of packets "in flight" in order to fully utilize the satellite link.
VSAT网络可以支持从每秒几千比特到每秒几兆比特的容量。当与相对较长的往返时间相结合时，TCP需要保持大量数据包“飞行”，以便充分利用卫星链路。
Asymmetric capacity
不对称容量
As indicated above, the outroute of a VSAT network is usually significantly larger than an inroute. Even though multiple inroutes can be used within a network, a given VSAT can only access one inroute at a time. Therefore, the incoming (outroute) and outgoing (inroute) capacity for a VSAT is often very asymmetric. As outroute capacity has increased in recent years, ratios of 400 to 1 or greater are becoming more and more common. With a TCP maximum segment size of 1460 bytes and delayed acknowledgments [RFC1122] in use, the ratio of IP packet bytes for data to IP packet bytes for ACKs is only (3000 to 40) 75 to 1.
如上所述，VSAT网络的出路由通常比入路由大得多。即使在一个网络中可以使用多条inroute，给定的VSAT一次只能访问一条inroute。因此，VSAT的入站（出站）和出站（入站）容量通常是非常不对称的。近年来，随着外线容量的增加，400:1或更高的比率变得越来越普遍。在TCP最大段大小为1460字节且使用延迟确认[RFC1122]的情况下，数据的IP数据包字节与确认的IP数据包字节的比率仅为（3000比40）75比1。
Thus, inroute capacity for carrying ACKs can have a significant impact on TCP performance. (The issue of asymmetric link impact on TCP performance is described in more detail in [BPK97].)
因此，承载ACK的路由内容量会对TCP性能产生重大影响。（非对称链路对TCP性能的影响问题在[BPK97]中有更详细的描述。）
With respect to the other satellite characteristics listed in [RFC2488], VSAT networks typically do not suffer from intermittent connectivity or variable round trip times. Also, VSAT networks generally include a significant amount of error correction coding. This makes the bit error rate very low during clear sky conditions, approaching the bit error rate of a typical terrestrial network. In severe weather, the bit error rate may increase significantly but such conditions are rare (when looked at from an overall network availability point of view) and VSAT networks are generally engineered to work during these conditions but not to optimize performance during these conditions.
关于[RFC2488]中列出的其他卫星特性，VSAT网络通常不会受到间歇性连接或可变往返时间的影响。此外，VSAT网络通常包括大量纠错编码。这使得在晴空条件下的误码率非常低，接近典型地面网络的误码率。在恶劣天气下，误码率可能会显著增加，但这种情况很少见（从整体网络可用性的角度来看），VSAT网络通常设计为在这些情况下工作，但不会在这些情况下优化性能。
Performance Enhancing Proxies implemented for VSAT networks generally focus on improving throughput (for applications such as FTP and HTTP web page retrievals). To a lesser degree, PEP implementations also work to improve interactive response time for small transactions.
为VSAT网络实施的性能增强代理通常侧重于提高吞吐量（用于FTP和HTTP网页检索等应用程序）。在较小程度上，PEP实现还可以提高小型事务的交互响应时间。
There is not a dominant PEP implementation used with VSAT networks. Each VSAT network vendor tends to implement their own version of PEP functionality, integrated with the other features of their VSAT product. [HNS] and [SPACENET] describe VSAT products with integrated PEP capabilities. There are also third party PEP implementations designed to be used with VSAT networks. These products run on nodes external to the VSAT network at the hub and remote sites. NettGain [FLASH] and Venturi [FOURELLE] are examples of such products. VSAT network PEP implementations generally share the following characteristics:
VSAT网络没有主要的PEP实现。每个VSAT网络供应商都倾向于实现自己版本的PEP功能，并与VSAT产品的其他功能集成。[HNS]和[SPACENET]描述了具有集成PEP功能的VSAT产品。还有设计用于VSAT网络的第三方PEP实现。这些产品在集线器和远程站点的VSAT网络外部节点上运行。NettGain[FLASH]和Venturi[FOURELLE]就是此类产品的例子。VSAT网络PEP实施通常具有以下特点：
- They focus on improving TCP performance;
- 他们专注于提高TCP性能；
- They use an asymmetric distributed implementation;
- 他们使用非对称的分布式实现；
- They use a split connection approach with local acknowledgments and local retransmissions;
- 他们使用一种带有本地确认和本地重传的分离连接方法；
- They support some form of compression to reduce the amount of bandwidth required (with emphasis on saving inroute bandwidth).
- 它们支持某种形式的压缩以减少所需的带宽（重点是节省路由带宽）。
The key differentiators between VSAT network PEP implementations are:
VSAT网络PEP实施之间的主要区别在于：
- The maximum throughput they attempt to support (mainly a function of the amount of buffer space they use);
- 它们试图支持的最大吞吐量（主要是它们使用的缓冲区空间量的函数）；
- The protocol used over the satellite link. Some implementations use a modified version of TCP while others use a proprietary protocol running on top of UDP;
- 通过卫星链路使用的协议。一些实现使用TCP的修改版本，而另一些使用运行在UDP之上的专有协议；
- The type of compression used. Third party VSAT network PEP implementations generally focus on application (e.g., HTTP) specific compression algorithms while PEP implementations integrated into the VSAT network generally focus on link specific compression.
- 使用的压缩类型。第三方VSAT网络PEP实施通常侧重于特定于应用程序（如HTTP）的压缩算法，而集成到VSAT网络中的PEP实施通常侧重于特定于链路的压缩。
PEP implementations integrated into a VSAT product are generally transparent to the end systems. Third party PEP implementations used with VSAT networks usually require configuration changes in the remote site end systems to route TCP packets to the remote site proxies but do not require changes to the hub site end systems. In some cases, the PEP implementation is actually integrated transparently into the end system node itself, using a "bump in the stack" approach. In all cases, the use of a PEP is non-transparent to the user, i.e., the user is aware when a PEP implementation is being used to boost performance.
集成到VSAT产品中的PEP实现通常对终端系统是透明的。与VSAT网络一起使用的第三方PEP实施通常需要更改远程站点端系统的配置，以将TCP数据包路由到远程站点代理，但不需要更改集线器站点端系统。在某些情况下，PEP实现实际上使用“堆栈中的凹凸”方法透明地集成到终端系统节点本身中。在所有情况下，PEP的使用对用户来说都是不透明的，即用户知道何时使用PEP实现来提高性能。
VSAT networks, since the early stages of their deployment, have supported the use of local termination of a protocol (e.g., SDLC and X.25) on each side of the satellite link to hide the satellite link from the applications using the protocol. Therefore, when LAN capabilities were added to VSAT networks, VSAT customers expected and, in fact, demanded, the use of similar techniques for improving the performance of IP based traffic, in particular TCP traffic.
VSAT网络自其部署的早期阶段起，就支持在卫星链路的每一侧使用协议（例如SDLC和X.25）的本地终止，以对使用该协议的应用程序隐藏卫星链路。因此，当局域网能力被添加到VSAT网络时，VSAT客户期望并且实际上要求使用类似的技术来改进基于IP的流量，特别是TCP流量的性能。
As indicated in Section 5.1, VSAT networks are primarily used to implement intranets with Internet connectivity limited to and closely controlled at the hub site of the VSAT network. Therefore, VSAT customers are not as affected (or at least perceive that they are not as affected) by the Internet related implications of using PEPs as are other technologies. Instead, what is more important to VSAT customers is the optimization of the network. And, VSAT customers, in general, prefer that the optimization of the network be done by the network itself rather than by implementing changes (such as enabling the TCP scaled window option) to their own equipment. VSAT customers prefer to optimize their end system configuration for local communications related to their local mission critical functions and let the VSAT network hide the presence of the satellite link as much as possible. VSAT network vendors have also been able to use PEP functionality to provide value added "services" to their customers such as extending the useful of life of older equipment which includes older, "non-modern" TCP stacks.
如第5.1节所述，VSAT网络主要用于实现内部网，其互联网连接仅限于VSAT网络的中心站点，并在中心站点受到严格控制。因此，VSAT客户不像其他技术那样受到使用PEP的互联网相关影响的影响（或至少认为他们没有受到影响）。相反，对VSAT客户来说，更重要的是优化网络。而且，VSAT客户通常更喜欢由网络本身进行网络优化，而不是对自己的设备实施更改（例如启用TCP缩放窗口选项）。VSAT客户倾向于优化其终端系统配置，以实现与其本地关键任务功能相关的本地通信，并让VSAT网络尽可能隐藏卫星链路的存在。VSAT网络供应商还能够使用PEP功能向其客户提供增值“服务”，例如延长旧设备的使用寿命，包括旧的“非现代”TCP堆栈。
Of course, as the line between intranets and the Internet continues to fade, the implications of using PEPs start to become more significant for VSAT networks. For example, twelve years ago security was not a major concern because the equipment cost related to being able to intercept VSAT traffic was relatively high. Now, as technology has advanced, the cost is much less prohibitive. Therefore, because the use of PEP functionality in VSAT networks prevents the use of IPsec, customers must rely on the use of higher layer security mechanisms such as TLS or on proprietary security mechanisms implemented in the VSAT networks themselves (since currently many applications are incapable of making (or simply don't make) use of the standardized higher layer security mechanisms). This, in turn, affects the cost of the VSAT network as well as affects the ability of the customers to make use of Internet based capabilities.
当然，随着内部网和互联网之间的界限不断淡化，使用PEP对VSAT网络的影响开始变得更加重要。例如，12年前，安全不是主要问题，因为能够拦截VSAT通信的设备成本相对较高。现在，随着技术的进步，成本也不再那么昂贵了。因此，由于在VSAT网络中使用PEP功能会阻止IPsec的使用，客户必须依赖于使用更高层的安全机制，如TLS或VSAT网络本身实现的专有安全机制（因为目前许多应用程序无法实现（或根本不实现）使用标准化的高层安全机制）。这反过来会影响VSAT网络的成本，也会影响客户利用基于互联网的功能的能力。
In mobile wireless WAN (W-WAN) environments the wireless link is typically used as the last-hop link to the end user. W-WANs include such networks as GSM [GSM], GPRS [GPRS],[BW97], CDPD [CDPD], IS-95 [CDMA], RichoNet, and PHS. Many of these networks, but not all, have been designed to provide mobile telephone voice service in the first place but include data services as well or they evolve from a mobile telephone network.
在移动无线广域网（W-WAN）环境中，无线链路通常用作到最终用户的最后一跳链路。W-WAN包括GSM[GSM]、GPRS[GPRS]、[BW97]、CDPD[CDPD]、IS-95[CDMA]、RichoNet和PHS等网络。这些网络中的许多（但不是全部）最初设计用于提供移动电话语音服务，但也包括数据服务，或者它们是从移动电话网络演变而来的。
W-WAN links typically exhibit some combination of the following link characteristics:
W-WAN链路通常表现出以下链路特性的某些组合：
- low bandwidth (with some links the available bandwidth might be as low as a few hundred bits/sec)
- 低带宽（对于某些链路，可用带宽可能低至几百位/秒）
- high latency (minimum round-trip delay close to one second is not exceptional)
- 高延迟（接近1秒的最小往返延迟并不例外）
- high BER resulting in frame or packet losses, or long variable delays due to local link-layer error recovery
- 高误码率导致帧或数据包丢失，或由于本地链路层错误恢复导致长时间可变延迟
- some W-WAN links have a lot of internal buffer space which tend to accumulate data, thus resulting in increased round-trip delay due to long (and variable) queuing delays
- 一些W-WAN链路具有大量内部缓冲空间，这些缓冲空间往往会累积数据，因此由于长（和可变）排队延迟，导致往返延迟增加
- on some W-WAN links the users may share common channels for their data packet delivery which, in turn, may cause unexpected delays to the packet delivery of a user due to simultaneous use of the same channel resources by the other users
- 在一些W-WAN链路上，用户可以共享用于其数据分组传送的公共信道，这反过来可能由于其他用户同时使用相同信道资源而导致用户分组传送的意外延迟
- unexpected link disconnections (or intermittent link outages) may occur frequently and the period of disconnection may last a very long time
- 意外链路断开（或间歇性链路中断）可能会频繁发生，断开时间可能会持续很长时间
- (re)setting the link-connection up may take a long time (several tens of seconds or even minutes)
- （重新）设置链路连接可能需要很长时间（几十秒甚至几分钟）
- the W-WAN network typically takes care of terminal mobility: the connection point to the Internet is retained while the user moves with the mobile host
- W-WAN网络通常负责终端移动性：当用户与移动主机一起移动时，保留到Internet的连接点
- the use of most W-WAN links is expensive. Many of the service providers apply time-based charging.
- 大多数W-WAN链路的使用成本很高。许多服务提供商采用基于时间的收费。
Performance Enhancing Proxies implemented for W-WAN environments generally focus on improving the interactive response time but at the same time aim at improving throughput, mainly by reducing the transfer volume over the inherently slow link in various ways. To achieve this, typically enhancements are applied at almost all protocol layers.
为W-WAN环境实施的性能增强代理通常侧重于提高交互响应时间，但同时旨在提高吞吐量，主要是通过以各种方式减少固有慢速链路上的传输量。为了实现这一点，通常会在几乎所有协议层上应用增强功能。
The Mowgli system [KRA94] is one of the early approaches to address the challenges induced by the problematic characteristics of low bandwidth W-WAN links.
Mowgli系统[KRA94]是解决低带宽W-WAN链路的问题特性所带来的挑战的早期方法之一。
The indirect approach used in Mowgli is not limited to a single layer as in many other split connection approaches, but it involves all protocol layers. The basic architecture is based on split TCP (UDP is also supported) together with full support for application layer proxies with a distributed PEP approach. An application layer proxy pair may be added between a client and server, the agent (local proxy) on a mobile host and the proxy on an intermediate node that provides the mobile host with the connection to the wireline Internet. Such a pair may be either explicit or fully transparent to the applications, but it is, at all times, under end-user control thus allowing the user to select the traffic that traverses through the PEP implementation and choose end-to-end IP for other traffic.
Mowgli中使用的间接方法不象许多其他分离连接方法那样局限于单层，而是涉及所有协议层。基本体系结构基于拆分TCP（也支持UDP），并通过分布式PEP方法完全支持应用层代理。可以在客户端和服务器、移动主机上的代理（本地代理）和为移动主机提供有线互联网连接的中间节点上的代理之间添加应用层代理对。这样的一对可以是明确的或对应用程序完全透明的，但它始终处于最终用户控制之下，因此允许用户选择通过PEP实现的流量，并为其他流量选择端到端IP。
In order to allow running legacy applications unmodified and without recompilation, the socket layer implementation on the mobile host is slightly modified to connect the applications, which are configured to traverse through the PEP, to a local agent while retaining the original TCP/IP socket semantics. Two types of application layer agent-proxy pairs can be configured for mobile host application use.
为了允许运行未经修改且无需重新编译的遗留应用程序，移动主机上的套接字层实现略微修改，以将配置为通过PEP遍历的应用程序连接到本地代理，同时保留原始TCP/IP套接字语义。可以为移动主机应用程序配置两种类型的应用程序层代理代理对。
A generic pair can be used with any application and it simply provides split transport service with some optional generic enhancements like compression. An application-specific pair can be retailed for any application or a group of applications that are able to take leverage on the same kind of enhancements. A good example of enhancements achieved with an application-specific proxy pair is the Mowgli WWW system that improves significantly the user perceived response time of Web browsing mainly by reducing the transfer volume and the number of round trips over the wireless link [LAKLR95], [LHKR96].
通用对可以用于任何应用程序，它只提供带有一些可选通用增强功能（如压缩）的拆分传输服务。特定于应用程序的一对可以针对任何应用程序或一组能够利用同类增强功能的应用程序进行零售。使用特定于应用程序的代理对实现的一个很好的增强示例是Mowgli WWW系统，该系统主要通过减少无线链路上的传输量和往返次数[LAKLR95]，[LHKR96]，显著提高了用户感知的Web浏览响应时间。
Mowgli provides also an option to replace the TCP/IP core protocols on the last-hop link with a custom protocol that is tuned for low-bandwidth W-WAN links [KRLKA97]. This protocol was designed to provide the same transport service with similar semantics as regular TCP and UDP provide, but use a different protocol implementation that can freely apply any appropriate protocol mechanisms without being constrained by the current TCP/IP packet format or protocol operation. As this protocol is required to operate over a single logical link only, it could partially combine the protocol control information and protocol operation of the link, network, and transport layers. In addition, the protocol can operate on top of various link services, for example on top of different raw link services, on top of PPP, on top of IP, or even on top of a single TCP connection using it as a link service and implementing "TCP multiplexing" over it. In all other cases, except when the protocol is configured to operate on top of raw (wireless) link service, IP may co-exist with the custom protocol allowing simultaneous end-to-end IP delivery for the traffic not traversing through the PEP implementation.
Mowgli还提供了一个选项，可将最后一跳链路上的TCP/IP核心协议替换为针对低带宽W-WAN链路调整的自定义协议[KRLKA97]。该协议旨在提供与常规TCP和UDP提供的语义相似的传输服务，但使用不同的协议实现，可以自由应用任何适当的协议机制，而不受当前TCP/IP数据包格式或协议操作的限制。由于该协议只需在单个逻辑链路上运行，因此它可以部分地结合链路、网络和传输层的协议控制信息和协议操作。此外，该协议可以在各种链路服务之上操作，例如在不同的原始链路服务之上、在PPP之上、在IP之上、甚至在单个TCP连接之上操作，将其用作链路服务并在其上实现“TCP多路复用”。在所有其他情况下，除了协议被配置为在原始（无线）链路服务之上运行时，IP可以与定制协议共存，从而允许对不通过PEP实现的流量同时进行端到端IP交付。
Furthermore, the custom protocol can be run in different operation modes which turn on or off certain protocol functions depending on the underlying link service. For example, if the underlying link service provides reliable data delivery, the checksum and the window-based error recovery can be turned off, thus reducing the protocol overhead; only a very simple recovery mechanism is needed to allow recovery from an unexpected link disconnection. Therefore, the protocol design was able to use extremely efficient header encoding (only 1-3 bytes per packet in a typical case), reduce the number of round trips significantly, and various features that are useful with low-bandwidth W-WAN links were easy to add. Such features include suspending the protocol operation over the periods of link disconnection or link outage together with fast start once the link becomes operational again, priority-based multiplexing of user data over the W-WAN link thus offering link capacity to interactive
此外，自定义协议可以在不同的操作模式下运行，这些操作模式根据基础链路服务打开或关闭某些协议功能。例如，如果底层链路服务提供可靠的数据传递，则可以关闭校验和和和基于窗口的错误恢复，从而减少协议开销；只需要一个非常简单的恢复机制就可以从意外的链路断开中恢复。因此，协议设计能够使用极其高效的报头编码（在典型情况下，每个数据包仅1-3字节），显著减少往返次数，并且易于添加对低带宽W-WAN链路有用的各种功能。这些特征包括在链路断开或链路中断期间暂停协议操作，以及在链路再次开始运行时快速启动，通过W-WAN链路对用户数据进行基于优先级的多路复用，从而为交互用户提供链路容量
applications in a timely manner even in presence of bandwidth-intensive background transfers, and link-level flow control to prevent data from accumulating into the W-WAN link internal buffers.
即使在存在带宽密集型后台传输的情况下，也能及时应用程序，并进行链路级流量控制，以防止数据累积到W-WAN链路内部缓冲区。
If desired, regular TCP/IP transport, possibly with corresponding protocol modifications in TCP (and UDP) that would tune it more suitable for W-WAN links, can be employed on the last-hop link.
如果需要，可以在最后一跳链路上使用常规TCP/IP传输，可能在TCP（和UDP）中进行相应的协议修改，以使其更适合W-WAN链路。
The Mowgli system was designed to support mobile hosts that are attached to the Internet over constrained links, but did not address the specific challenges with low-end mobile devices. Many mobile wireless devices are power, memory, and processing constrained, and the communication links to these devices have lower bandwidth and less stable connections. These limitations led designers to develop the Wireless Application Protocol (WAP) that specifies an application framework and network protocols intended to work across differing narrowband wireless network technologies bringing Internet content and advanced data services to low-end digital cellular phones and other mobile wireless terminals, such as pagers and PDAs.
Mowgli系统旨在支持通过受限链接连接到互联网的移动主机，但没有解决低端移动设备的具体挑战。许多移动无线设备受到电源、内存和处理的限制，与这些设备的通信链路的带宽较低，连接稳定性较差。这些限制促使设计师开发了无线应用协议（WAP），该协议指定了一个应用框架和网络协议，旨在跨不同的窄带无线网络技术工作，将互联网内容和先进的数据服务带到低端数字蜂窝电话和其他移动无线终端，例如寻呼机和PDA。
The WAP model consists of a WAP client (mobile terminal), a WAP proxy, and an origin server. It requires a WAP proxy between the WAP client and the server on the Internet. WAP uses a layered, scalable architecture [WAPARCH], specifying the following five protocol layers to be used between the terminal and the proxy: Application Layer (WAE) [WAPWAE], Session Layer (WSP) [WAPWSP], Transaction Layer (WTP) [WAPWTP], Security Layer (WTLS) [WAPWTLS], and Transport Layer (WDP) [WAPWDP]. Standard Internet protocols are used between the proxy and the origin server. If the origin server includes WAP proxy functionality, it is called a WAP Server.
WAP模型由WAP客户端（移动终端）、WAP代理和源服务器组成。它需要在WAP客户端和Internet上的服务器之间使用WAP代理。WAP使用分层、可扩展的体系结构[WAPARCH]，指定终端和代理之间要使用的以下五个协议层：应用层（WAE）[WAPWAE]、会话层（WSP）[WAPWSP]、事务层（WTP）[WAPWTP]、安全层（WTLS）[WAPWTLS]和传输层（WDP）[WAPWDP]。代理服务器和源服务器之间使用标准Internet协议。如果源服务器包含WAP代理功能，则称为WAP服务器。
In a typical scenario, a WAP client sends an encoded WAP request to a WAP proxy. The WAP proxy translates the WAP request into a WWW (HTTP) request, performing the required protocol conversions, and submits this request to a standard web server on the Internet. After the web server responds to the WAP proxy, the response is encoded into a more compact binary format to decrease the size of the data over the air. This encoded response is forwarded to the WAP client [WAPPROXY].
在典型场景中，WAP客户端向WAP代理发送编码的WAP请求。WAP代理将WAP请求转换为WWW（HTTP）请求，执行所需的协议转换，并将此请求提交到Internet上的标准web服务器。在web服务器响应WAP代理之后，响应被编码为更紧凑的二进制格式，以减少空中数据的大小。此编码响应被转发到WAP客户端[WAPPROXY]。
WAP operates over a variety of bearer datagram services. When communicating over these bearer services, the WAP transport layer (WDP) is always used between the WAP client and WAP proxy and it provides port addressed datagram service to the higher WAP layers. If the bearer service supports IP (e.g., GSM-CSD, GSM-GPRS, IS-136, CDPD), UDP is used as the datagram protocol. However, if the bearer
WAP通过各种承载数据报服务进行操作。当通过这些承载服务进行通信时，WAP传输层（WDP）总是在WAP客户端和WAP代理之间使用，它向更高的WAP层提供端口寻址数据报服务。如果承载服务支持IP（例如，GSM-CSD、GSM-GPRS、IS-136、CDPD），则使用UDP作为数据报协议。但是，如果持票人
service does not support IP (e.g., GSM-SMS, GSM-USSD, GSM Cell Broadcast, CDMS-SMS, TETRA-SDS), WDP implements the required datagram protocol as an adaptation layer between the bearer network and the protocol stack.
服务不支持IP（例如，GSM-SMS、GSM-USSD、GSM小区广播、CDMS-SMS、TETRA-SDS），WDP将所需的数据报协议作为承载网络和协议栈之间的适配层实施。
The use of the other layers depends on the port number. WAP has registered a set of well-known ports with IANA. The port number selected by the application for communication between a WAP client and proxy defines the other layers to be used at each end. The security layer, WTLS, provides privacy, data integrity and authentication. Its functionality is similar to TLS 1.0 [RFC2246] extended with datagram support, optimized handshake and dynamic key refreshing. If the origin server includes WAP proxy functionality, it might be used to facilitate the end-to-end security solutions, otherwise it provides security between the mobile terminal and the proxy.
其他层的使用取决于端口号。WAP已经向IANA注册了一组著名的端口。应用程序为WAP客户端和代理之间的通信选择的端口号定义了在每一端使用的其他层。安全层WTLS提供隐私、数据完整性和身份验证。其功能类似于TLS 1.0[RFC2246]，通过数据报支持、优化握手和动态密钥刷新进行扩展。如果源服务器包含WAP代理功能，则它可能用于促进端到端安全解决方案，否则它将提供移动终端和代理之间的安全性。
The transaction layer, WTP, is message based without connection establishment and tear down. It supports three types of transaction classes: an unconfirmed request (unidirectional), a reliable (confirmed) request (unidirectional), and a reliable (confirmed) request-reply transaction. Data is carried in the first packet and 3-way handshake is eliminated to reduce latencies. In addition acknowledgments, retransmission, and flow control are provided. It allows more than one outstanding transaction at a time. It handles the bearer dependence of a transfer, e.g., selects timeout values and packet sizes according to the bearer. Unfortunately, WTP uses fixed retransmission timers and does not include congestion control, which is a potential problem area as the use of WAP increases [RFC3002].
事务层WTP是基于消息的，不需要建立连接和断开连接。它支持三种类型的事务类：未确认请求（单向）、可靠（确认）请求（单向）和可靠（确认）请求-应答事务。数据在第一个数据包中传输，消除了三次握手以减少延迟。此外，还提供确认、重传和流控制。它一次允许多个未完成的事务。它处理传输的承载依赖性，例如，根据承载选择超时值和数据包大小。不幸的是，WTP使用固定的重传计时器，不包括拥塞控制，这是随着WAP使用的增加而出现的一个潜在问题[RFC3002]。
The session layer, WSP, supports binary encoded HTTP 1.1 with some extensions such as long living session with suspend/resume facility and state handling, header caching, and push facility. On top of the architecture is the application environment (WAE).
会话层WSP支持二进制编码的HTTP 1.1和一些扩展，例如具有挂起/恢复功能和状态处理、头缓存和推送功能的长期会话。体系结构之上是应用程序环境（WAE）。
As indicated in Section 5.2.1, W-WAN networks typically offer very low bandwidth connections with high latency and relatively frequent periods of link disconnection and they usually are expensive to use. Therefore, the transfer volume and extra round-trips, such as those associated with TCP connection setup and teardown, must be reduced and the slow W-WAN link should be efficiently shielded from excess traffic and global (wired) Internet congestion to make Internet access usable and economical. Furthermore, interactive traffic must be transmitted in a timely manner even if there are other simultaneous bandwidth intensive (background) transfers and during the periods with connectivity the link must be kept fully utilized
如第5.2.1节所述，W-WAN网络通常提供非常低的带宽连接，具有高延迟和相对频繁的链路断开周期，并且通常使用成本较高。因此，必须减少传输量和额外的往返行程，例如与TCP连接设置和拆卸相关的往返行程，并且应有效地屏蔽慢速W-WAN链路，以避免过度流量和全球（有线）互联网拥塞，从而使互联网接入可用且经济。此外，即使存在其他同时的带宽密集型（后台）传输，也必须及时传输交互流量，并且在连接期间，必须充分利用链路
due to expensive use. In addition, the (long) periods of link disconnection must not abort active (bulk data) transfers, if an end-user so desires.
由于使用费用昂贵。此外，如果最终用户需要，链路断开的（长）时间不得中止活动（批量数据）传输。
As (all) applications cannot be made mobility/W-WAN aware in short time frame or maybe ever, support for mobile W-WAN use should be implemented in a way which allows most applications, at least those running on fixed Internet hosts, to continue their operation unmodified.
由于（所有）应用程序无法在短时间内或可能永远能够感知移动/W-WAN，因此对移动W-WAN使用的支持应以允许大多数应用程序（至少是在固定互联网主机上运行的应用程序）不经修改地继续其操作的方式实现。
Wireless LANs (W-LAN) are typically organized in a cellular topology where an access point with a W-LAN transceiver controls a single cell. A cell is defined in terms of the coverage area of the base station. The access points are directly connected to the wired network. The access point in each of the cells is responsible for forwarding packets to and from the hosts located in the cell. Often the hosts with W-LAN transceivers are mobile. When such a mobile host moves from one cell to another cell, the responsibility for forwarding packets between the wired network and the mobile host must be transferred to the access point of the new cell. This is known as a handoff. Many W-LAN systems also support an operation mode enabling ad-hoc networking. In this mode access points are not necessarily needed, but hosts with W-LAN transceiver can communicate directly with the other hosts within the transceiver's transmission range.
无线局域网（W-LAN）通常以蜂窝式拓扑结构组织，其中带有W-LAN收发器的接入点控制单个小区。小区是根据基站的覆盖范围来定义的。接入点直接连接到有线网络。每个小区中的接入点负责向位于小区中的主机转发数据包和从位于小区中的主机转发数据包。通常，带有W-LAN收发器的主机是移动的。当这样的移动主机从一个小区移动到另一个小区时，在有线网络和移动主机之间转发分组的责任必须转移到新小区的接入点。这称为切换。许多W-LAN系统还支持一种支持自组织网络的操作模式。在这种模式下，不一定需要接入点，但是带有W-LAN收发器的主机可以直接与收发器传输范围内的其他主机通信。
Current wireless LANs typically provide link bandwidth from 1 Mbps to 11 Mbps. In the future, wide deployment of higher bandwidths up to 54 Mbps or even higher can be expected. The round-trip delay with wireless LANs is on the order of a few milliseconds or tens of milliseconds. Examples of W-LANs include IEEE 802.11, HomeRF, and Hiperlan. Wireless personal area networks (WPAN) such as Bluethooth can use the same PEP techniques.
当前的无线局域网通常提供从1Mbps到11Mbps的链路带宽。在未来，预计将广泛部署高达54 Mbps甚至更高的更高带宽。无线局域网的往返延迟大约为几毫秒或几十毫秒。W-LAN的示例包括IEEE 802.11、HomeRF和Hiperlan。诸如Bluethooth之类的无线个人区域网络（WPAN）可以使用相同的PEP技术。
Wireless LANs are error-prone due to bit errors, collisions and link outages. In addition, consecutive packet losses may also occur during handoffs. Most W-LAN MAC protocols perform low level retransmissions. This feature shields upper layers from most losses. However, unavoidable losses, retransmission latency and link outages still affect upper layers. TCP performance over W-LANs or a network path involving a W-LAN link is likely to suffer from these effects.
由于位错误、冲突和链路中断，无线局域网容易出错。此外，在切换期间也可能发生连续的分组丢失。大多数W-LAN MAC协议执行低级重传。此功能可保护上层免受大部分损失。然而，不可避免的损失、重传延迟和链路中断仍然会影响上层。通过W-LAN或涉及W-LAN链路的网络路径的TCP性能可能会受到这些影响。
As TCP wrongly interprets these packet losses to be network congestion, the TCP sender reduces its congestion window and is often forced to timeout in order to recover from the consecutive losses. The result is often unacceptably poor end-to-end performance.
由于TCP错误地将这些数据包丢失解释为网络拥塞，TCP发送方会缩短其拥塞窗口，并经常被迫超时以从连续丢失中恢复。结果往往是端到端性能差得令人无法接受。
Berkeley's Snoop protocol [SNOOP] is a TCP-specific approach in which a TCP-aware module, a Snoop agent, is deployed at the W-LAN base station that acts as the last-hop router to the mobile host. Snoop aims at retaining the TCP end-to-end semantics. The Snoop agent monitors every packet that passes through the base station in either direction and maintains soft state for each TCP connection. The Snoop agent is an asymmetric PEP implementation as it operates differently on TCP data and ACK channels as well as on the uplink (from the mobile host) and downlink (to the mobile host) TCP segments.
Berkeley的Snoop协议[Snoop]是一种特定于TCP的方法，其中在W-LAN基站部署一个感知TCP的模块，即Snoop代理，作为移动主机的最后一跳路由器。Snoop旨在保留TCP端到端语义。Snoop代理监视在任一方向通过基站的每个数据包，并为每个TCP连接保持软状态。Snoop代理是一种非对称的PEP实现，因为它在TCP数据和ACK信道以及上行链路（从移动主机）和下行链路（到移动主机）TCP段上的操作不同。
For a data transfer to a mobile host, the Snoop agent caches unacknowledged TCP data segments which it forwards to the TCP receiver and monitors the corresponding ACKs. It does two things:
对于到移动主机的数据传输，Snoop代理缓存未确认的TCP数据段，并将其转发到TCP接收器，并监视相应的确认。它做两件事：
1. Retransmits any lost data segments locally by using local timers and TCP duplicate ACKs to identify packet loss, instead of waiting for the TCP sender to do so end-to-end.
1. 通过使用本地计时器和TCP复制确认来识别数据包丢失，而不是等待TCP发送方端到端地重新传输任何丢失的数据段。
2. Suppresses the duplicate ACKs on their way from the mobile host back to the sender, thus avoiding fast retransmit and congestion avoidance at the latter.
2. 在从移动主机返回发送方的过程中抑制重复的ACK，从而避免后者的快速重传和拥塞避免。
Suppressing the duplicate ACKs is required to avoid unnecessary fast retransmits by the TCP sender as the Snoop agent retransmits a packet locally. Consider a system that employs the Snoop agent and a TCP sender S that sends packets to receiver R via a base station BS. Assume that S sends packets A, B, C, D, E (in that order) which are forwarded by BS to the wireless receiver R. Assume the first transmission of packet B is lost due to errors on the wireless link. In this case, R receives packets A, C, D, E and B (in that order). Receipt of packets C, D and E trigger duplicate ACKs. When S receives three duplicate ACKs, it triggers fast retransmit (which results in a retransmission, as well as reduction of the congestion window). The Snoop agent also retransmits B locally, when it receives three duplicate ACKs. The fast retransmit at S occurs despite the local retransmit on the wireless link, degrading throughput. Snoop deals with this problem by dropping TCP duplicate ACKs appropriately at BS.
当Snoop代理在本地重新传输数据包时，需要抑制重复的ACK以避免TCP发送方不必要的快速重新传输。考虑使用Snoop代理和TCP发送器S的系统，该发送器通过基站BS将数据包发送到接收机R。假设S发送分组A、B、C、D、E（按该顺序），这些分组由BS转发到无线接收器R。假设分组B的第一次传输由于无线链路上的错误而丢失。在这种情况下，R接收分组A、C、D、E和B（按该顺序）。收到数据包C、D和E将触发重复确认。当S收到三个重复的ACK时，它会触发快速重传（这会导致重传，并减少拥塞窗口）。当Snoop代理接收到三个重复的ack时，它也在本地重新传输B。尽管在无线链路上进行了本地重传，但在S处仍会发生快速重传，从而降低吞吐量。Snoop通过在BS上适当地丢弃TCP重复ack来处理这个问题。
For a data transfer from a mobile host, the Snoop agent detects the packet losses on the wireless link by monitoring the data segments it forwards. It then employs either Negative Acknowledgements (NAK) locally or Explicit Loss Notifications (ELN) to inform the mobile sender that the packet loss was not related to congestion, thus allowing the sender to retransmit without triggering normal congestion control procedures. To implement this, changes at the mobile host are required.
对于来自移动主机的数据传输，Snoop代理通过监视其转发的数据段来检测无线链路上的数据包丢失。然后，它在本地使用否定确认（NAK）或显式丢失通知（ELN）来通知移动发送方分组丢失与拥塞无关，从而允许发送方在不触发正常拥塞控制过程的情况下重新传输。要实现这一点，需要在移动主机上进行更改。
When a Snoop agent uses NAKs to inform the TCP sender of the packet losses on the wireless link, one possibility to implement them is using the Selective Acknowledgment (SACK) option of TCP [RFC2018]. This requires enabling SACK processing at the mobile host. The Snoop agent sends a TCP SACK, when it detects a hole in the transmission sequence from the mobile host or when it has not received any new packets from the mobile host for a certain time period. This approach relies on the advisory nature of the SACKs: the mobile sender is advised to retransmit the missing segments indicated by SACK, but it must not assume successful end-to-end delivery of the segments acknowledged with SACK as these segments might get lost later in the path to the receiver. Instead, the sender must wait for a cumulative ACK to arrive.
当Snoop代理使用NAK通知TCP发送方无线链路上的数据包丢失时，实现它们的一种可能性是使用TCP[RFC2018]的选择性确认（SACK）选项。这需要在移动主机上启用SACK处理。当Snoop代理检测到来自移动主机的传输序列中存在漏洞或在特定时间段内未从移动主机接收任何新数据包时，它会发送TCP SACK。这种方法依赖于SACK的建议性质：建议移动发送方重新传输SACK指示的缺失段，但不能假设SACK确认的段成功端到端传递，因为这些段可能稍后在通往接收方的路径中丢失。相反，发送方必须等待累计ACK到达。
When the ELN mechanism is used to inform the mobile sender of the packet losses, Snoop uses one of the 'unreserved' bits in the TCP header for ELN [SNOOPELN]. The Snoop agent keeps track of the holes that correspond to segments lost over the wireless link. When a (duplicate) ACK corresponding to a hole in the sequence space arrives from the TCP receiver, the Snoop agent sets the ELN bit on the ACK to indicate that the loss is unrelated to congestion and then forwards the ACK to the TCP sender. When the sender receives a certain number of (duplicate) ACKs with ELN (a configurable variable at the mobile host, e.g., two), it retransmit the missing segment without performing any congestion control measures.
当ELN机制用于通知移动发送方数据包丢失时，Snoop使用TCP报头中的一个“未保留”位作为ELN[SNOOPELN]。Snoop代理跟踪与无线链路上丢失的段相对应的孔。当与序列空间中的孔对应的（重复）ACK从TCP接收器到达时，Snoop代理在ACK上设置ELN位以指示丢失与拥塞无关，然后将ACK转发给TCP发送方。当发送方通过ELN（移动主机上的一个可配置变量，例如两个）接收到一定数量的（重复的）ACK时，它将重新传输丢失的段，而不执行任何拥塞控制措施。
The ELN mechanism using one of the six bits reserved for future use in the TCP header is dangerous as it exercises checks that might not be correctly implemented in TCP stacks, and may expose bugs.
ELN机制使用TCP报头中为将来使用而保留的六位之一是危险的，因为它执行的检查可能无法在TCP堆栈中正确实现，并且可能会暴露错误。
A scheme such as Snoop is needed only if the possibility of a fast retransmit due to wireless errors is non-negligible. In particular, if the wireless link uses link-layer recovery for lost data, then this scheme is not beneficial. Also, if the TCP window tends to stay smaller than four segments, for example, due to congestion related losses on the wired network, the probability that the Snoop agent will have an opportunity to locally retransmit a lost packet is small. This is because at least three duplicate ACKs are needed to trigger the local retransmission, but due to small window the Snoop
只有在由于无线错误导致快速重传的可能性不可忽略时，才需要Snoop等方案。特别地，如果无线链路使用链路层恢复来恢复丢失的数据，则该方案是不利的。此外，如果TCP窗口倾向于保持小于四个段，例如，由于有线网络上与拥塞相关的丢失，则Snoop代理将有机会本地重新传输丢失的分组的概率很小。这是因为至少需要三个重复的ack来触发本地重传，但由于Snoop的窗口很小
agent may not be able to forward three new packets after the lost packet and thus induce the required three duplicate ACKs. Conversely, when the TCP window is large enough, Snoop can provide significant performance improvement (compared with standard TCP).
代理可能无法在丢失的数据包之后转发三个新数据包，从而导致所需的三个重复ack。相反，当TCP窗口足够大时，Snoop可以提供显著的性能改进（与标准TCP相比）。
In order to alleviate the problem with small TCP windows, Snoop proposes a solution in which a TCP sender is allowed to transmit a new data segment for each duplicate ACK it receives as long as the number of duplicate ACKs is less than the threshold for TCP fast retransmission (three duplicate ACKs). If the new segment reaches the receiver, it will generate another duplicate ACK which, in turn, allows the sender to transmit yet another data segment. This continues until enough duplicate ACKs have accumulated to trigger TCP fast retransmission. This proposal is the same as the "Limited Transfer" proposal [RFC3042] that has recently been forwarded to the standards track. However, to be able to benefit from this solution, it needs to be deployed on TCP senders and therefore it is not ready for use in a short time frame.
为了缓解小TCP窗口的问题，Snoop提出了一种解决方案，其中允许TCP发送方为其接收到的每个重复ACK发送一个新的数据段，只要重复ACK的数量小于TCP快速重传的阈值（三个重复ACK）。如果新的数据段到达接收器，它将生成另一个重复的ACK，从而允许发送方传输另一个数据段。这将一直持续，直到累积足够多的重复ACK以触发TCP快速重传。该提案与最近转发至标准轨道的“有限转让”提案[RFC3042]相同。然而，为了能够从这个解决方案中获益，它需要部署在TCP发送方上，因此它在短时间内还没有准备好使用。
Snoop requires the intermediate node (base station) to examine and operate on the traffic between the mobile host and the other end host on the wired Internet. Hence, Snoop does not work if the IP traffic is encrypted. Possible solutions involve:
Snoop要求中间节点（基站）检查并操作有线互联网上移动主机和另一终端主机之间的流量。因此，如果对IP通信进行加密，则Snoop不起作用。可能的解决办法包括：
- making the Snoop agent a party to the security association between the client and the server;
- 使Snoop代理成为客户端和服务器之间的安全关联的一方；
- IPsec tunneling mode, terminated at the Snooping base station.
- IPsec隧道模式，在侦听基站终止。
However, these techniques require that users trust base stations.
然而，这些技术要求用户信任基站。
Snoop also requires that both the data and the corresponding ACKs traverse the same base station. Furthermore, the Snoop agent may duplicate efforts by the link layer as it retransmits the TCP data segments "at the transport layer" across the wireless link. (Snoop has been described by its designers as a TCP-aware link layer. This is the right approach: the link and network layers can be much more aware of each other than strict layering suggests.)
Snoop还要求数据和相应的ACK都穿过同一基站。此外，当Snoop代理在无线链路上“在传输层”重新传输TCP数据段时，它可以复制链路层的工作。（Snoop的设计者将其描述为一个TCP感知的链路层。这是正确的方法：链路层和网络层可以比严格的分层更加相互感知。）
Wireless LANs suffer from an error prone wireless channel. Errors can typically be considered bursty and channel conditions may change rapidly from mobility and environmental changes. Packets are dropped from bit errors or during handovers. Periods of link outage can also be experienced. Although the typical MAC performs retransmissions, dropped packets, outages and retransmission latency still can have serious performance implications for IP performance, especially TCP.
无线局域网存在易出错的无线信道。错误通常被认为是突发性的，并且信道条件可能因移动性和环境变化而迅速变化。数据包因位错误或在切换过程中丢失。也可能经历链路中断的时期。尽管典型的MAC执行重传，丢包、中断和重传延迟仍然会对IP性能，特别是TCP性能产生严重影响。
PEPs can be used to alleviate problems caused by packet losses, protect TCP from link outages, and to add priority multiplexing. Techniques such as Snoop are integrally implemented in access points, while priority and compression schemes are distributed across the W-LAN.
PEP可用于缓解数据包丢失引起的问题，保护TCP不受链路中断的影响，并添加优先级多路复用。Snoop等技术集成在接入点中，而优先级和压缩方案分布在W-LAN中。
The use of Performance Enhancing Proxies introduces several issues which impact security. First, (as described in detail in Section 4.1.1,) using PEPs and using IPsec is generally mutually exclusive. Unless the PEP is also both capable and trusted to be the endpoint of an IPsec tunnel (and the use of an IPsec tunnel is deemed good enough security for the applicable threat model), a user or network administrator must choose between improved performance and network layer security. In some cases, transport (or higher) layer security can be used in conjunction with a PEP to mitigate the impact of not having network layer security. But, support by applications for the use of transport (or higher) layer security is far from ubiquitous.
使用性能增强代理会带来一些影响安全性的问题。首先，（如第4.1.1节所述，）使用PEP和使用IPsec通常是互斥的。除非PEP也能够并且被信任为IPsec隧道的端点（并且IPsec隧道的使用对于适用的威胁模型来说已经足够安全），否则用户或网络管理员必须在改进的性能和网络层安全性之间进行选择。在某些情况下，传输（或更高）层安全性可与PEP结合使用，以减轻没有网络层安全性的影响。但是，应用程序对使用传输（或更高）层安全性的支持远不是无处不在的。
Additionally, the PEP itself needs to be protected from attack. First, even when IPsec tunnels are used with the PEP, the PEP represents a point in the network where traffic is exposed. And, the placement of a PEP in the network makes it an ideal platform from which to launch a denial of service or man in the middle attack. (Also, taking the PEP out of action is a potential denial of service attack itself.) Therefore, the PEP must be protected (e.g., by a firewall) or must protect itself from improper access by an attacker just like any other device which resides in a network.
此外，PEP本身需要受到保护，以防受到攻击。首先，即使IPsec隧道与PEP一起使用，PEP也表示网络中流量暴露的点。而且，PEP在网络中的放置使得它成为启动拒绝服务或中间人攻击的理想平台。（此外，使PEP停止工作本身就是一种潜在的拒绝服务攻击。）因此，PEP必须受到保护（例如，通过防火墙），或者必须像驻留在网络中的任何其他设备一样，保护自己免受攻击者的不当访问。
This document is an informational overview document and, as such, does not introduce new nor modify existing name or number spaces managed by IANA.
本文档是一份信息性概述文档，因此不会引入或修改IANA管理的现有名称或数字空间。
This document grew out of the Internet-Draft "TCP Performance Enhancing Proxy Terminology", RFC 2757 "Long Thin Networks", and work done in the IETF TCPSAT working group. The authors are indebted to the active members of the PILC working group. In particular, Joe Touch and Mark Allman gave us invaluable feedback on various aspects of the document and Magdolna Gerendai provided us with essential help on the WAP example.
本文件源于互联网草案“TCP性能增强代理术语”、RFC 2757“长瘦网络”，以及IETF TCPSAT工作组所做的工作。作者感谢PILC工作组的积极成员。特别是，Joe Touch和Mark Allman就文档的各个方面向我们提供了宝贵的反馈，Magdolna Gerendai为我们提供了WAP示例方面的重要帮助。
[BBKT97] P. Bhagwat, P. Bhattacharya, A. Krishma, S.K. Tripathi,
"Using channel state dependent packet scheduling to
improve TCP throughput over wireless LANs," ACM Wireless
Networks, March 1997, pp. 91 - 102. Available at:
http://www.acm.org/pubs
/articles/journals/wireless/1997-3-1/p91-bhagwat/p91-
bhagwat.pdf
[BBKT97] P. Bhagwat, P. Bhattacharya, A. Krishma, S.K. Tripathi,
"Using channel state dependent packet scheduling to
improve TCP throughput over wireless LANs," ACM Wireless
Networks, March 1997, pp. 91 - 102. Available at:
http://www.acm.org/pubs
/articles/journals/wireless/1997-3-1/p91-bhagwat/p91-
bhagwat.pdf
[BPK97] H. Balakrishnan, V.N. Padmanabhan, R.H. Katz, "The Effects of Asymmetry on TCP Performance," Proc. ACM/IEEE Mobicom, Budapest, Hungary, September 1997.
[BPK97]H.Balakrishnan，V.N.Padmanabhan，R.H.Katz，“不对称对TCP性能的影响”，Proc。ACM/IEEE Mobicom，匈牙利布达佩斯，1997年9月。
[BW97] G. Brasche, B. Walke, "Concepts, Services, and Protocols of the New GSM Phase 2+ general Packet Radio Service," IEEE Communications Magazine, Vol. 35, No. 8, August 1997.
[BW97]G.Brasche，B.Walke，“新GSM第2阶段+通用分组无线电服务的概念、服务和协议”，《IEEE通信杂志》，第35卷，第8期，1997年8月。
[CDMA] Electronic Industry Alliance (EIA)/Telecommunications Industry Association (TIA), IS-95: Mobile Station-Base Station Compatibility Standard for Dual-Mode Wideband Spread Spectrum Cellular System, 1993.
[CDMA]电子工业联盟（EIA）/电信工业协会（TIA），IS-95：双模宽带扩频蜂窝系统的移动站基站兼容性标准，1993年。
[CDPD] Wireless Data Forum, CDPD System Specification, Release 1.1, 1995.
[CDPD]无线数据论坛，CDPD系统规范，1.11995版。
[CTC+97] H. Chang, C. Tait, N. Cohen, M. Shapiro, S. Mastrianni, R. Floyd, B. Housel, D. Lindquist, "Web Browsing in a Wireless Environment: Disconnected and Asynchronous Operation in ARTour Web Express," Proc. MobiCom'97, Budapest, Hungary, September 1997.
[CTC+97]H.Chang，C.Tait，N.Cohen，M.Shapiro，S.Mastrianni，R.Floyd，B.House，D.Lindquist，“无线环境中的网页浏览：ARTour Web Express中的断开连接和异步操作”，Proc。MobiCom'97，匈牙利布达佩斯，1997年9月。
[FMSBMR98] D.C. Feldmeier, A.J. McAuley, J.M. Smith, D.S. Bakin, W.S. Marcus, T.M. Raleigh, "Protocol Boosters," IEEE Journal on Selected Areas of Communication, Vol. 16, No. 3, April 1998.
[FMSBMR98]D.C.Feldmeier，A.J.McAuley，J.M.Smith，D.S.Bakin，W.S.Marcus，T.M.Raleigh，“协议助推器”，IEEE选定通信领域杂志，第16卷，第3期，1998年4月。
[FLASH] Flash Networks Ltd., performance boosting products technology vendor based in Holmdel, New Jersey. Website at http://www.flashnetworks.com.
[FLASH]FLASH Networks Ltd.，性能提升产品技术供应商，总部位于新泽西州霍姆德尔。网址：http://www.flashnetworks.com.
[FOURELLE] Fourelle Systems, performance boosting products technology vendor based in Santa Clara, California. Website at http://www.fourelle.com.
[FOURELLE]FOURELLE Systems，性能提升产品技术供应商，总部位于加利福尼亚州圣克拉拉。网址：http://www.fourelle.com.
[GPRS] ETSI, "General Packet Radio Service (GPRS): Service Description, Stage 2," GSM03.60, v.6.1.1, August 1998.
[GPRS]ETSI，“通用分组无线业务（GPRS）：业务描述，第2阶段”，GSM03.60，v.6.1.11998年8月。
[GSM] M. Rahnema, "Overview of the GSM system and protocol architecture," IEEE Communications Magazine, Vol. 31, No. 4, pp. 92-100, April 1993.
[GSM]M.Rahnema，“GSM系统和协议架构概述”，《IEEE通信杂志》，第31卷，第4期，第92-100页，1993年4月。
[HNS] Hughes Network Systems, Inc., VSAT technology vendor based in Germantown, Maryland. Website at http://www.hns.com.
[HNS]休斯网络系统公司，VSAT技术供应商，位于马里兰州日尔曼敦。网址：http://www.hns.com.
[I-TCP] A. Bakre, B.R. Badrinath, "I-TCP: Indirect TCP for Mobile Hosts," Proc. 15th International Conference on Distributed Computing Systems (ICDCS), May 1995.
[I-TCP]A.Bakre，B.R.Badrinath，“I-TCP：移动主机的间接TCP”，Proc。第15届分布式计算系统国际会议，1995年5月。
[KRA94] M. Kojo, K. Raatikainen, T. Alanko, "Connecting Mobile Workstations to the Internet over a Digital Cellular Telephone Network," Proc. Workshop on Mobile and Wireless Information Systems (MOBIDATA), Rutgers University, NJ, November 1994. Revised version published in Mobile Computing, pp. 253-270, Kluwer, 1996.
[KRA94]M.Kojo，K.Raatikainen，T.Alanko，“通过数字蜂窝电话网络将移动工作站连接到互联网”，Proc。移动和无线信息系统讲习班，罗格斯大学，新泽西州，1994年11月。修订版发布于移动计算，第253-270页，Kluwer，1996年。
[KRLKA97] M. Kojo, K. Raatikainen, M. Liljeberg, J. Kiiskinen, T. Alanko, "An Efficient Transport Service for Slow Wireless Telephone Links," IEEE Journal on Selected Areas of Communication, Vol. 15, No. 7, September 1997.
[KRLKA97]M.Kojo，K.Raatikainen，M.Liljeberg，J.Kiiskinen，T.Alanko，“慢速无线电话链路的高效传输服务”，IEEE选定通信领域杂志，第15卷，第7期，1997年9月。
[LAKLR95] M. Liljeberg, T. Alanko, M. Kojo, H. Laamanen, K. Raatikainen, "Optimizing World-Wide Web for Weakly-Connected Mobile Workstations: An Indirect Approach," Proc. of the 2nd Int. Workshop on Services in Distributed and Networked Environments, Whistler, Canada, pp. 132- 139, June 1995.
[LAKLR95]M.Liljeberg，T.Alanko，M.Kojo，H.Laamanen，K.Raatikainen，“为弱连接移动工作站优化万维网：一种间接方法”，Proc。第二届分布式和网络环境服务国际研讨会，加拿大惠斯勒，第132-139页，1995年6月。
[LHKR96] M. Liljeberg, H. Helin, M. Kojo, K. Raatikainen, "Mowgli WWW Software: Improved Usability of WWW in Mobile WAN Environments," Proc. IEEE Global Internet 1996 Conference, London, UK, November 1996.
[LHKR96]M.Liljeberg，H.Helin，M.Kojo，K.Raatikainen，“Mowgli WWW软件：在移动WAN环境中改进WWW的可用性”，Proc。IEEE全球互联网1996年会议，伦敦，英国，1996年11月。
[M-TCP] K. Brown, S. Singh, "M-TCP: TCP for Mobile Cellular Networks," ACM Computer Communications Review Volume 27(5), 1997. Available at ftp://ftp.ece.orst.edu/pub/singh/papers/mtcp.ps.gz.
[M-TCP]K.Brown，S.Singh，“M-TCP:TCP用于移动蜂窝网络”，ACM计算机通信评论卷27（5），1997年。可在ftp://ftp.ece.orst.edu/pub/singh/papers/mtcp.ps.gz.
[Pax99] V. Paxson, "End-to-End Internet Packet Dynamics," IEEE/ACM Transactions on Networking, Vol. 7, No. 3, 1999, pp. 277-292.
[Pax99]V.Paxson，“端到端互联网数据包动力学”，IEEE/ACM网络交易，第7卷，第3期，1999年，第277-292页。
[PILCWEB] http://pilc.grc.nasa.gov.
[PILCWEB]http://pilc.grc.nasa.gov.
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFC0792]Postel，J.，“互联网控制消息协议”，STD 5，RFC 792，1981年9月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC1122] Braden, R., "Requirements for Internet Hosts -- Communications Layers", STD 3, RFC 1122, October 1989.
[RFC1122]Braden，R.，“互联网主机的要求——通信层”，标准3，RFC 1122，1989年10月。
[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月。
[RFC1958] Carpenter, B., "Architectural Principles of the Internet", RFC 1958, June 1996.
[RFC1958]Carpenter，B.，“互联网的建筑原理”，RFC19581996年6月。
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996.
[RFC2018]Mathis，M.，Mahdavi，J.，Floyd，S.和A.Romanow，“TCP选择性确认选项”，RFC 2018，1996年10月。
[RFC2151] Kessler, G. and S. Shepard, "A Primer On Internet and TCP/IP Tools and Utilities", FYI 30, RFC 2151, June 1997.
[RFC2151]Kessler，G.和S.Shepard，“互联网和TCP/IP工具及实用程序入门”，FYI 30，RFC 2151，1997年6月。
[RFC2246] Dierk, T. and E. Allen, "TLS Protocol Version 1," RFC 2246, January 1999.
[RFC2246]Dierk，T.和E.Allen，“TLS协议版本1”，RFC2246，1999年1月。
[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月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[RFC2475]Blake，S.，Black，D.，Carlson，M.，Davies，E.，Wang，Z.和W.Weiss，“差异化服务架构”，RFC 24751998年12月。
[RFC2488] Allman, M., Glover, D. and L. Sanchez, "Enhancing TCP Over Satellite Channels using Standard Mechanisms", BCP 28, RFC 2488, January 1999.
[RFC2488]Allman，M.，Glover，D.和L.Sanchez，“使用标准机制增强卫星信道上的TCP”，BCP 28，RFC 2488，1999年1月。
[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]Casner，S.和V.Jacobson，“压缩低速串行链路的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月。
[RFC2663] Srisuresh, P. and Y. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[RFC2663]Srisuresh，P.和Y.Holdrege，“IP网络地址转换器（NAT）术语和注意事项”，RFC 2663，1999年8月。
[RFC2760] Allman, M., Dawkins, S., Glover, D., Griner, J., Henderson, T., Heidemann, J., Kruse, H., Ostermann, S., Scott, K., Semke, J., Touch, J. and D. Tran, "Ongoing TCP Research Related to Satellites", RFC 2760, February 2000.
[RFC2760]奥尔曼，M.，道金斯，S.，格洛弗，D.，格林纳，J.，亨德森，T.，海德曼，J.，克鲁斯，H.，奥斯特曼，S.，斯科特，K.，塞姆克，J.，Touch，J.和D.Tran，“正在进行的与卫星相关的TCP研究”，RFC 27602000年2月。
[RFC3002] Mitzel, D., "Overview of 2000 IAB Wireless Internetworking Workshop", RFC 3002, December 2000.
[RFC3002]Mitzel，D.，“2000年IAB无线互联车间概述”，RFC 30022000年12月。
[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月。
[SHEL00] Z. Shelby, T. Saarinen, P. Mahonen, D. Melpignano, A. Marshall, L. Munoz, "Wireless IPv6 Networks - WINE," IST Mobile Summit, Ireland, October 2000.
[SHEL00]Z.Shelby，T.Saarinen，P.Mahonen，D.Melpingnano，A.Marshall，L.Munoz，“无线IPv6网络-葡萄酒”，IST移动峰会，爱尔兰，2000年10月。
[SNOOP] H. Balakrishnan, S. Seshan, E. Amir, R. Katz, "Improving TCP/IP Performance over Wireless Networks," Proc. 1st ACM Conference on Mobile Communications and Networking (Mobicom), Berkeley, California, November 1995.
[SNOOP]H.Balakrishnan，S.Seshan，E.Amir，R.Katz，“改善无线网络上的TCP/IP性能”，Proc。第一届ACM移动通信和网络会议（Mobicom），加利福尼亚州伯克利，1995年11月。
[SNOOPELN] H. Balakrishnan, R. Katz, "Explicit Loss Notification and Wireless Web Performance," Proc. IEEE Globecom 1998, Internet Mini-Conference, Sydney, Australia, November 1998.
[SNOOPELN]H.Balakrishnan，R.Katz，“显式丢失通知和无线网络性能”，Proc。IEEE Globecom 1998，因特网小型会议，澳大利亚悉尼，1998年11月。
[SPACENET] Spacenet, VSAT technology vendor based in Mclean, Virginia. Website at http://www.spacenet.com.
[SPACENET]SPACENET，VSAT技术供应商，位于弗吉尼亚州麦克莱恩。网址：http://www.spacenet.com.
[SRC84] J.H. Saltzer, D.P. Reed, D.D. Clark, "End-To-End Arguments in System Design," ACM TOCS, Vol. 2, No. 4, pp. 277-288, November 1984.
[SRC84]J.H.Saltzer，D.P.Reed，D.D.Clark，“系统设计中的端到端参数”，ACM TOCS，第2卷，第4期，第277-288页，1984年11月。
[WAPARCH] Wireless Application Protocol Architecture Specification, April 1998, http://www.wapforum.org.
[WAPARCH]无线应用协议体系结构规范，1998年4月，http://www.wapforum.org.
[WAPPROXY] Wireless Application Protocol Push Proxy Gateway Service Specification, August 1999, http://www.wapforum.org.
[WAPPROXY]无线应用协议推送代理网关服务规范，1999年8月，http://www.wapforum.org.
[WAPWAE] Wireless Application Protocol Wireless Application Environment Overview, March 2000, http://www.wapforum.org.
[WAPWAE]无线应用协议无线应用环境概述，2000年3月，http://www.wapforum.org.
[WAPWDP] Wireless Application Protocol Wireless Datagram Protocol Specification, February 2000, http://www.wapforum.org.
[WAPWDP]无线应用协议无线数据报协议规范，2000年2月，http://www.wapforum.org.
[WAPWSP] Wireless Application Protocol Wireless Session Protocol Specification, May 2000, http://www.wapforum.org.
[WAPWSP]无线应用协议无线会话协议规范，2000年5月，http://www.wapforum.org.
[WAPWTLS] Wireless Application Protocol Wireless Transport Layer Security Specification, February 2000, http://www.wapforum.org.
[WAPWTLS]无线应用协议无线传输层安全规范，2000年2月，http://www.wapforum.org.
[WAPWTP] Wireless Application Protocol Wireless Transaction Protocol Specification, February 2000, http://www.wapforum.org.
[WAPWTP]无线应用协议无线事务协议规范，2000年2月，http://www.wapforum.org.
[Zhang00] Y. Zhang, B. Singh, "A Multi-Layer IPsec Protocol," Proc. proceedings of 9th USENIX Security Symposium, Denver, Colorado, August 2000. Available at http://www.wins.hrl.com/people/ygz/papers/usenix00.html.
[Zhang00]Y.Zhang，B.Singh，“多层IPsec协议”，Proc。第九届USENIX安全研讨会论文集，科罗拉多州丹佛，2000年8月。可在http://www.wins.hrl.com/people/ygz/papers/usenix00.html.
Questions about this document may be directed to:
有关本文件的问题，请联系：
John Border Hughes Network Systems 11717 Exploration Lane Germantown, Maryland 20876
约翰·博德·休斯网络系统公司，马里兰州日尔曼镇探索巷11717号，邮编：20876
Phone: +1-301-548-6819
Fax: +1-301-548-1196
EMail: border@hns.com
Phone: +1-301-548-6819
Fax: +1-301-548-1196
EMail: border@hns.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
Jim Griner NASA Glenn Research Center MS: 54-5 21000 Brookpark Orad Cleveland, Ohio 44135-3191
吉姆·格林纳美国宇航局格伦研究中心MS:54-5 21000俄亥俄州布鲁克公园奥拉德克利夫兰44135-3191
Phone: +1-216-433-5787
Fax: +1-216-433-8705
EMail: jgriner@grc.nasa.gov
Phone: +1-216-433-5787
Fax: +1-216-433-8705
EMail: jgriner@grc.nasa.gov
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
Zach Shelby University of Oulu Center for Wireless Communications PO Box 4500 FIN-90014 Finland
扎克谢尔比奥卢大学无线通信中心PO箱4500芬兰-90014
Phone: +358-40-779-6297
EMail: zach.shelby@ee.oulu.fi
Phone: +358-40-779-6297
EMail: zach.shelby@ee.oulu.fi
Appendix A - PEP Terminology Summary
附录A-政治公众人物术语摘要
This appendix provides a summary of terminology frequently used during discussion of Performance Enhancing Proxies. (In some cases, these terms have different meanings from their non-PEP related usage.)
本附录总结了在讨论性能增强代理时经常使用的术语。（在某些情况下，这些术语的含义与其非政治公众人物相关用法不同。）
ACK filtering
ACK滤波
Removing acknowledgments to prevent congestion of a low speed link, usually used with paths which include a highly asymmetric link. Sometimes also called ACK reduction. See Section 3.1.4.
删除确认以防止低速链路拥塞，通常用于包含高度不对称链路的路径。有时也称为ACK减少。见第3.1.4节。
ACK spacing
应答间隔
Delayed forwarding of acknowledgments in order to space them appropriately, for example, to help minimize the burstiness of TCP data. See Section 3.1.1.
延迟转发确认，以便适当地隔开它们，例如，帮助最小化TCP数据的突发性。见第3.1.1节。
application layer PEP
应用层PEP
A Performance Enhancing Proxy operating above the transport layer. May be aimed at improving application or transport protocol performance (or both). Described in detail in Section 2.1.2.
在传输层之上运行的性能增强代理。可能旨在提高应用程序或传输协议性能（或两者兼而有之）。详细说明见第2.1.2节。
asymmetric link
不对称链路
A link which has different rates for the forward channel (used for data segments) and the back (or return) channel (used for ACKs).
前向信道（用于数据段）和后向（或返回）信道（用于ACK）速率不同的链路。
available bandwidth
可用带宽
The total capacity of a link available to carry information at any given time. May be lower than the raw bandwidth due to competing traffic.
在任何给定时间可用于传输信息的链路的总容量。由于竞争流量，可能低于原始带宽。
bandwidth utilization
带宽利用率
The actual amount of information delivered over a link in a given period, usually expressed as a percent of the raw bandwidth of the link.
在给定时间段内通过链路传输的实际信息量，通常表示为链路原始带宽的百分比。
gateway
网关
Has several meanings with respect to PEPs, depending on context:
根据上下文，对政治公众人物有多种含义：
- An access point to a particular link;
- 特定链路的接入点；
- A device capable of initiating and terminating connections on
- 一种能够在网络上启动和终止连接的设备
behalf of a user or end system (e.g., a firewall or proxy).
代表用户或终端系统（如防火墙或代理）。
Not necessarily, but could be, a router.
不一定，但可能是路由器。
in flight (data)
飞行中（数据）
Data sent but not yet acknowledged. More precisely, data sent for which the sender has not yet received the acknowledgement.
已发送但尚未确认的数据。更准确地说，发送人尚未收到确认的数据。
link layer PEP
链路层PEP
A Performance Enhancing Proxy operating below the network layer.
在网络层下运行的性能增强代理。
local acknowledgement
本地确认
The generation of acknowledgments by an entity in the path between two end systems in order to allow the sending system to transmit more data without waiting for end-to-end acknowledgments. Described (in the context of TCP) in Section 3.1.2.
由实体在两个终端系统之间的路径上生成确认，以允许发送系统在不等待端到端确认的情况下传输更多数据。在第3.1.2节中描述（在TCP上下文中）。
performance enhancing proxy
性能增强代理
An entity in the network acting on behalf of an end system or user (with or without the knowledge of the end system or user) in order to enhance protocol performance. Section 2 describes various types of performance enhancing proxies. Section 3 describes the mechanisms performance enhancing proxies use to improve performance.
网络中代表终端系统或用户（不管终端系统或用户是否知情）以提高协议性能的实体。第2节描述了各种类型的性能增强代理。第3节描述了用于提高性能的性能增强代理的机制。
raw bandwidth
原始带宽
The total capacity of an unloaded link available to carry information.
可用于承载信息的未加载链路的总容量。
Snoop
窥探
A TCP-aware link layer developed for wireless packet radio and cellular networks. It works by caching segments at a wireless base station. If the base station sees duplicate acknowledgments for a segment that it has cached, it retransmits the missing segment while suppressing the duplicate acknowledgement stream being forwarded back to the sender until the wireless receiver starts to acknowledge new data. Described in detail in Section 5.3.2 and [SNOOP].
为无线分组无线电和蜂窝网络开发的TCP感知链路层。它的工作原理是在无线基站缓存数据段。如果基站看到其缓存的段的重复确认，它将重新传输丢失的段，同时抑制转发回发送方的重复确认流，直到无线接收机开始确认新数据。详细说明见第5.3.2节和[SNOOP]。
split connection
分裂连接
A connection that has been terminated before reaching the intended destination end system in order to initiate another connection towards the end system. This allows the use of different connection characteristics for different parts of the path of the originally intended connection. See Section 2.4.
在到达预定目的地终端系统之前已终止的连接，以便启动另一个通向终端系统的连接。这允许对原始预期连接路径的不同部分使用不同的连接特性。见第2.4节。
TCP PEP
TCP政治公众人物
A Performance Enhancing Proxy operating at the transport layer with TCP. Aimed at improving TCP performance.
使用TCP在传输层操作的性能增强代理。旨在提高TCP性能。
TCP splitting
TCP拆分
Using one or more split TCP connections to improve TCP performance.
使用一个或多个拆分TCP连接来提高TCP性能。
TCP spoofing
TCP欺骗
Sometimes used as a synonym for TCP PEP. More accurately, TCP spoofing refers to using transparent (to the TCP stacks in the end systems) mechanisms to improve TCP performance. See Section 2.1.1.
有时用作TCP PEP的同义词。更准确地说，TCP欺骗是指使用透明（对终端系统中的TCP堆栈）机制来提高TCP性能。见第2.1.1节。
transparent
透明的
In the context of a PEP, transparent refers to not requiring changes to be made to the end systems, transport endpoints and/or applications involved in a connection. See Section 2.5 for a more detailed explanation.
在PEP的上下文中，透明是指不需要对连接中涉及的终端系统、传输端点和/或应用程序进行更改。有关更详细的说明，请参见第2.5节。
transport layer PEP
传输层PEP
A Performance Enhancing Proxy operating at the transport layer. Described in detail in Section 2.1.1.
在传输层运行的性能增强代理。详细说明见第2.1.1节。
tunneling
隧道
In the context of PEPs, tunneling refers to the process of wrapping a packet for transmission over a particular link between two PEPs. See Section 3.2.
在PEP的上下文中，隧道是指包装数据包以便在两个PEP之间的特定链路上传输的过程。见第3.2节。
WAP
WAP
The Wireless Application Protocol specifies an application framework and network protocols intended to work across differing narrow-band wireless network technologies. See Section 5.2.2.2.
无线应用协议指定了应用框架和网络协议，旨在跨不同的窄带无线网络技术工作。见第5.2.2.2节。
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编辑功能的资金目前由互联网协会提供。