Network Working Group A. Barbir
Request for Comments: 3568 Nortel Networks
Category: Informational B. Cain
Storigen Systems
R. Nair
Consultant
O. Spatscheck
AT&T
July 2003
Network Working Group A. Barbir
Request for Comments: 3568 Nortel Networks
Category: Informational B. Cain
Storigen Systems
R. Nair
Consultant
O. Spatscheck
AT&T
July 2003
Known Content Network (CN) Request-Routing Mechanisms
已知内容网络（CN）请求路由机制
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 (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
This document presents a summary of Request-Routing techniques that are used to direct client requests to surrogates based on various policies and a possible set of metrics. The document covers techniques that were commonly used in the industry on or before December 2000. In this memo, the term Request-Routing represents techniques that is commonly called content routing or content redirection. In principle, Request-Routing techniques can be classified under: DNS Request-Routing, Transport-layer Request-Routing, and Application-layer Request-Routing.
本文档概述了用于根据各种策略和一组可能的度量将客户端请求定向到代理的请求路由技术。该文件涵盖了2000年12月或之前行业中常用的技术。在本备忘录中，术语请求路由表示通常称为内容路由或内容重定向的技术。原则上，请求路由技术可以分为：DNS请求路由、传输层请求路由和应用层请求路由。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. DNS based Request-Routing Mechanisms . . . . . . . . . . . . 3
2.1. Single Reply . . . . . . . . . . . . . . . . . . . . . 3
2.2. Multiple Replies . . . . . . . . . . . . . . . . . . . 3
2.3. Multi-Level Resolution . . . . . . . . . . . . . . . . 4
2.3.1. NS Redirection . . . . . . . . . . . . . . . . 4
2.3.2. CNAME Redirection. . . . . . . . . . . . . . . 5
2.4. Anycast. . . . . . . . . . . . . . . . . . . . . . . . 5
2.5. Object Encoding. . . . . . . . . . . . . . . . . . . . 6
2.6. DNS Request-Routing Limitations. . . . . . . . . . . . 6
3. Transport-Layer Request-Routing . . . . . . . . . . . . . . 7
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. DNS based Request-Routing Mechanisms . . . . . . . . . . . . 3
2.1. Single Reply . . . . . . . . . . . . . . . . . . . . . 3
2.2. Multiple Replies . . . . . . . . . . . . . . . . . . . 3
2.3. Multi-Level Resolution . . . . . . . . . . . . . . . . 4
2.3.1. NS Redirection . . . . . . . . . . . . . . . . 4
2.3.2. CNAME Redirection. . . . . . . . . . . . . . . 5
2.4. Anycast. . . . . . . . . . . . . . . . . . . . . . . . 5
2.5. Object Encoding. . . . . . . . . . . . . . . . . . . . 6
2.6. DNS Request-Routing Limitations. . . . . . . . . . . . 6
3. Transport-Layer Request-Routing . . . . . . . . . . . . . . 7
4. Application-Layer Request-Routing . . . . . . . . . . . . . 8
4.1. Header Inspection. . . . . . . . . . . . . . . . . . . 8
4.1.1. URL-Based Request-Routing. . . . . . . . . . . 8
4.1.2. Header-Based Request-Routing . . . . . . . . . 9
4.1.3. Site-Specific Identifiers. . . . . . . . . . .10
4.2. Content Modification . . . . . . . . . . . . . . . . .10
4.2.1. A-priori URL Rewriting . . . . . . . . . . . .11
4.2.2. On-Demand URL Rewriting. . . . . . . . . . . .11
4.2.3. Content Modification Limitations . . . . . . .11
5. Combination of Multiple Mechanisms . . . . . . . . . . . . .11
6. Security Considerations . . . . . . . . . . . . . . . . . .12
7. Additional Authors and Acknowledgements . . . . . . . . . .12
A. Measurements . . . . . . . . . . . . . . . . . . . . . . . .13
A.1. Proximity Measurements . . . . . . . . . . . . . . . .13
A.1.1. Active Probing . . . . . . . . . . . . . . . .13
A.1.2. Metric Types . . . . . . . . . . . . . . . . .14
A.1.3. Surrogate Feedback . . . . . . . . . . . . . .14
8. Normative References . . . . . . . . . . . . . . . . . . . .15
9. Informative References . . . . . . . . . . . . . . . . . . .15
10. Intellectual Property and Copyright Statements . . . . . . .17
11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . .18
12. Full Copyright Statement . . . . . . . . . . . . . . . . . .19
4. Application-Layer Request-Routing . . . . . . . . . . . . . 8
4.1. Header Inspection. . . . . . . . . . . . . . . . . . . 8
4.1.1. URL-Based Request-Routing. . . . . . . . . . . 8
4.1.2. Header-Based Request-Routing . . . . . . . . . 9
4.1.3. Site-Specific Identifiers. . . . . . . . . . .10
4.2. Content Modification . . . . . . . . . . . . . . . . .10
4.2.1. A-priori URL Rewriting . . . . . . . . . . . .11
4.2.2. On-Demand URL Rewriting. . . . . . . . . . . .11
4.2.3. Content Modification Limitations . . . . . . .11
5. Combination of Multiple Mechanisms . . . . . . . . . . . . .11
6. Security Considerations . . . . . . . . . . . . . . . . . .12
7. Additional Authors and Acknowledgements . . . . . . . . . .12
A. Measurements . . . . . . . . . . . . . . . . . . . . . . . .13
A.1. Proximity Measurements . . . . . . . . . . . . . . . .13
A.1.1. Active Probing . . . . . . . . . . . . . . . .13
A.1.2. Metric Types . . . . . . . . . . . . . . . . .14
A.1.3. Surrogate Feedback . . . . . . . . . . . . . .14
8. Normative References . . . . . . . . . . . . . . . . . . . .15
9. Informative References . . . . . . . . . . . . . . . . . . .15
10. Intellectual Property and Copyright Statements . . . . . . .17
11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . .18
12. Full Copyright Statement . . . . . . . . . . . . . . . . . .19
This document provides a summary of known request routing techniques that are used by the industry before December 2000. Request routing techniques are generally used to direct client requests to surrogates based on various policies and a possible set of metrics. The task of directing clients' requests to surrogates is also called Request-Routing, Content Routing or Content Redirection.
本文档总结了行业在2000年12月之前使用的已知请求路由技术。请求路由技术通常用于根据各种策略和一组可能的度量将客户端请求定向到代理。将客户端的请求定向到代理的任务也称为请求路由、内容路由或内容重定向。
Request-Routing techniques are commonly used in Content Networks (also known as Content Delivery Networks) [8]. Content Networks include network infrastructure that exists in layers 4 through 7. Content Networks deal with the routing and forwarding of requests and responses for content. Content Networks rely on layer 7 protocols such as HTTP [4] for transport.
请求路由技术通常用于内容网络（也称为内容交付网络）[8]。内容网络包括存在于第4层到第7层中的网络基础设施。内容网络处理内容请求和响应的路由和转发。内容网络依靠HTTP[4]等第7层协议进行传输。
Request-Routing techniques are generally used to direct client requests for objects to a surrogate or a set of surrogates that could best serve that content. Request-Routing mechanisms could be used to direct client requests to surrogates that are within a Content Network (CN) [8].
请求路由技术通常用于将客户端对对象的请求定向到一个代理项或一组代理项，以最好地服务于该内容。请求路由机制可用于将客户端请求定向到内容网络（CN）内的代理服务器[8]。
Request-Routing techniques are used as a vehicle to extend the reach and scale of Content Delivery Networks. There exist multiple Request-Routing mechanisms. At a high-level, these may be classified under: DNS Request-Routing, transport-layer Request-Routing, and application-layer Request-Routing.
请求路由技术被用作扩展内容交付网络覆盖范围和规模的工具。存在多种请求路由机制。在较高的层次上，这些可分类为：DNS请求路由、传输层请求路由和应用层请求路由。
A request routing system uses a set of metrics in an attempt to direct users to surrogate that can best serve the request. For example, the choice of the surrogate could be based on network proximity, bandwidth availability, surrogate load and availability of content. Appendix A provides a summary of metrics and measurement techniques that could be used in the selection of the best surrogate.
请求路由系统使用一组度量，试图将用户引导到能够最好地服务于请求的代理。例如，代理的选择可以基于网络邻近性、带宽可用性、代理负载和内容可用性。附录A提供了可用于选择最佳替代物的指标和测量技术的总结。
The memo is organized as follows: Section 2 provides a summary of known DNS based Request-Routing techniques. Section 3 discusses transport-layer Request-Routing methods. In section 4 application layer Request-Routing mechanisms are explored. Section 5 provides insight on combining the various methods that were discussed in the earlier sections in order to optimize the performance of the Request-Routing System. Appendix A provides a summary of possible metrics and measurements techniques that could be used by the Request-Routing system to choose a given surrogate.
备忘录组织如下：第2节总结了已知的基于DNS的请求路由技术。第3节讨论传输层请求路由方法。第4节探讨了应用层请求路由机制。第5节介绍了如何结合前面几节中讨论的各种方法来优化请求路由系统的性能。附录A提供了请求路由系统可用于选择给定代理的可能度量和测量技术的摘要。
DNS based Request-Routing techniques are common due to the ubiquity of the DNS system [10][12][13]. In DNS based Request-Routing techniques, a specialized DNS server is inserted in the DNS resolution process. The server is capable of returning a different set of A, NS or CNAME records based on user defined policies, metrics, or a combination of both. In [11] RFC 2782 (DNS SRV) provides guidance on the use of DNS for load balancing. The RFC describes some of the limitations and suggests appropriate useage of DNS based techniques. The next sections provides a summary of some of the used techniques.
由于DNS系统的普遍性，基于DNS的请求路由技术很常见[10][12][13]。在基于DNS的请求路由技术中，在DNS解析过程中插入专门的DNS服务器。服务器能够根据用户定义的策略、度量或两者的组合返回一组不同的a、NS或CNAME记录。在[11]中，RFC 2782（DNS SRV）提供了使用DNS进行负载平衡的指南。RFC描述了一些限制，并建议适当使用基于DNS的技术。下一节将总结一些使用的技术。
In this approach, the DNS server is authoritative for the entire DNS domain or a sub domain. The DNS server returns the IP address of the best surrogate in an A record to the requesting DNS server. The IP address of the surrogate could also be a virtual IP(VIP) address of the best set of surrogates for requesting DNS server.
在这种方法中，DNS服务器对整个DNS域或子域具有权威性。DNS服务器将A记录中最佳代理的IP地址返回给请求DNS服务器。代理服务器的IP地址也可以是用于请求DNS服务器的最佳代理服务器集的虚拟IP（VIP）地址。
In this approach, the Request-Routing DNS server returns multiple replies such as several A records for various surrogates. Common implementations of client site DNS server's cycles through the multiple replies in a Round-Robin fashion. The order in which the records are returned can be used to direct multiple clients using a single client site DNS server.
在这种方法中，请求路由DNS服务器返回多个回复，例如各种代理的多个A记录。客户端站点DNS服务器的循环以循环方式通过多个回复的常见实现。返回记录的顺序可用于使用单个客户端站点DNS服务器指导多个客户端。
In this approach multiple Request-Routing DNS servers can be involved in a single DNS resolution. The rationale of utilizing multiple Request-Routing DNS servers in a single DNS resolution is to allow one to distribute more complex decisions from a single server to multiple, more specialized, Request-Routing DNS servers. The most common mechanisms used to insert multiple Request-Routing DNS servers in a single DNS resolution is the use of NS and CNAME records. An example would be the case where a higher level DNS server operates within a territory, directing the DNS lookup to a more specific DNS server within that territory to provide a more accurate resolution.
在这种方法中，单个DNS解析可以涉及多个请求路由DNS服务器。在单个DNS解析中使用多个请求路由DNS服务器的基本原理是允许一个服务器将更复杂的决策分发到多个更专业的请求路由DNS服务器。用于在单个DNS解析中插入多个请求路由DNS服务器的最常见机制是使用NS和CNAME记录。例如，更高级别的DNS服务器在某个区域内运行，将DNS查找定向到该区域内更特定的DNS服务器，以提供更准确的解析。
A DNS server can use NS records to redirect the authority of the next level domain to another Request-Routing DNS server. The, technique allows multiple DNS server to be involved in the name resolution process. For example, a client site DNS server resolving a.b.example.com [10] would eventually request a resolution of a.b.example.com from the name server authoritative for example.com. The name server authoritative for this domain might be a Request-Routing NS server. In this case the Request-Routing DNS server can either return a set of A records or can redirect the resolution of the request a.b.example.com to the DNS server that is authoritative for example.com using NS records.
DNS服务器可以使用NS记录将下一级域的权限重定向到另一个请求路由DNS服务器。该技术允许多个DNS服务器参与名称解析过程。例如，解析a.b.example.com[10]的客户端站点DNS服务器最终将从权威的名称服务器example.com请求解析a.b.example.com。此域的授权名称服务器可能是请求路由NS服务器。在这种情况下，请求路由DNS服务器可以返回一组a记录，或者可以使用NS记录将请求a.b.example.com的解析重定向到具有权威性的DNS服务器，例如a.b.example.com。
One drawback of using NS records is that the number of Request-Routing DNS servers are limited by the number of parts in the DNS name. This problem results from DNS policy that causes a client site DNS server to abandon a request if no additional parts of the DNS name are resolved in an exchange with an authoritative DNS server.
使用NS记录的一个缺点是，请求路由DNS服务器的数量受到DNS名称中的部分数量的限制。此问题源于DNS策略，该策略导致客户端站点DNS服务器在与权威DNS服务器的交换中未解决DNS名称的其他部分时放弃请求。
A second drawback is that the last DNS server can determine the TTL of the entire resolution process. Basically, the last DNS server can return in the authoritative section of its response its own NS record. The client will use this cached NS record for further request resolutions until it expires.
第二个缺点是最后一个DNS服务器可以确定整个解析过程的TTL。基本上，最后一个DNS服务器可以在其响应的权威部分返回其自己的NS记录。客户端将使用此缓存的NS记录进行进一步的请求解析，直到过期。
Another drawback is that some implementations of bind voluntarily cause timeouts to simplify their implementation in cases in which a NS level redirect points to a name server for which no valid A record is returned or cached. This is especially a problem if the domain of the name server does not match the domain currently resolved, since in this case the A records, which might be passed in the DNS response, are discarded for security reasons. Another drawback is the added delay in resolving the request due to the use of multiple DNS servers.
另一个缺点是，在NS级重定向指向没有返回或缓存有效记录的名称服务器的情况下，bind的一些实现会自动导致超时，以简化它们的实现。如果名称服务器的域与当前解决的域不匹配，这尤其是一个问题，因为在这种情况下，出于安全原因，可能会丢弃DNS响应中传递的a记录。另一个缺点是由于使用多个DNS服务器而增加了解析请求的延迟。
In this scenario, the Request-Routing DNS server returns a CNAME record to direct resolution to an entirely new domain. In principle, the new domain might employ a new set of Request-Routing DNS servers.
在这种情况下，请求路由DNS服务器返回一个CNAME记录，以将解析定向到一个全新的域。原则上，新域可能会使用一组新的请求路由DNS服务器。
One disadvantage of this approach is the additional overhead of resolving the new domain name. The main advantage of this approach is that the number of Request-Routing DNS servers is independent of the format of the domain name.
这种方法的一个缺点是解析新域名的额外开销。这种方法的主要优点是请求路由DNS服务器的数量与域名的格式无关。
Anycast [5] is an inter-network service that is applicable to networking situations where a host, application, or user wishes to locate a host which supports a particular service but, if several servers utilizes the service, it does not particularly care which server is used. In an anycast service, a host transmits a datagram to an anycast address and the inter-network is responsible for providing best effort delivery of the datagram to at least one, and preferably only one, of the servers that accept datagrams for the anycast address.
Anycast[5]是一种网络间服务，适用于主机、应用程序或用户希望定位支持特定服务的主机的联网情况，但如果多台服务器使用该服务，则不特别关心使用哪台服务器。在选播服务中，主机将数据报发送到选播地址，并且网络间负责向接受选播地址数据报的服务器中的至少一个（最好仅一个）提供数据报的最大努力交付。
The motivation for anycast is that it considerably simplifies the task of finding an appropriate server. For example, users, instead of consulting a list of servers and choosing the closest one, could simply type the name of the server and be connected to the nearest one. By using anycast, DNS resolvers would no longer have to be configured with the IP addresses of their servers, but rather could send a query to a well-known DNS anycast address.
anycast的动机是它大大简化了查找适当服务器的任务。例如，用户不必查询服务器列表并选择最近的服务器，只需键入服务器名称并连接到最近的服务器即可。通过使用选播，DNS解析程序将不再需要配置其服务器的IP地址，而是可以向已知的DNS选播地址发送查询。
Furthermore, to combine measurement and redirection, the Request-Routing DNS server can advertise an anycast address as its IP address. The same address is used by multiple physical DNS servers. In this scenario, the Request-Routing DNS server that is the closest to the client site DNS server in terms of OSPF and BGP routing will receive the packet containing the DNS resolution request. The server can use this information to make a Request-Routing decision.
此外，为了结合测量和重定向，请求路由DNS服务器可以公布选播地址作为其IP地址。多个物理DNS服务器使用相同的地址。在此场景中，在OSPF和BGP路由方面最接近客户端站点DNS服务器的请求路由DNS服务器将接收包含DNS解析请求的数据包。服务器可以使用此信息做出请求路由决策。
Drawbacks of this approach are listed below:
这种方法的缺点如下所示：
o The DNS server may not be the closest server in terms of routing to the client.
o 就到客户端的路由而言，DNS服务器可能不是最近的服务器。
o Typically, routing protocols are not load sensitive. Hence, the closest server may not be the one with the least network latency.
o 通常，路由协议对负载不敏感。因此，最近的服务器可能不是网络延迟最少的服务器。
o The server load is not considered during the Request-Routing process.
o 在请求路由过程中不考虑服务器负载。
Since only DNS names are visible during the DNS Request-Routing, some solutions encode the object type, object hash, or similar information into the DNS name. This might vary from a simple division of objects based on object type (such as images.a.b.example.com and streaming.a.b.example.com) to a sophisticated schema in which the domain name contains a unique identifier (such as a hash) of the object. The obvious advantage is that object information is available at resolution time. The disadvantage is that the client site DNS server has to perform multiple resolutions to retrieve a single Web page, which might increase rather than decrease the overall latency.
由于在DNS请求路由期间只有DNS名称可见，因此一些解决方案将对象类型、对象哈希或类似信息编码到DNS名称中。这可能不同于基于对象类型（如images.a.b.example.com和streaming.a.b.example.com）的简单对象划分，也可能不同于复杂的模式，其中域名包含对象的唯一标识符（如散列）。明显的优点是，在解析时可以获得对象信息。缺点是客户端站点DNS服务器必须执行多个解析才能检索单个网页，这可能会增加而不是减少总体延迟。
This section lists some of the limitations of DNS based Request-Routing techniques.
本节列出了基于DNS的请求路由技术的一些限制。
o DNS only allows resolution at the domain level. However, an ideal request resolution system should service requests per object level.
o DNS仅允许在域级别进行解析。然而，理想的请求解析系统应该为每个对象级别的请求提供服务。
o In DNS based Request-Routing systems servers may be required to return DNS entries with a short time-to-live (TTL) values. This may be needed in order to be able to react quickly in the face of outages. This in return may increase the volume of requests to DNS servers.
o 在基于DNS的请求路由系统中，服务器可能需要返回具有短生存时间（TTL）值的DNS条目。这可能是必要的，以便能够在面临停机时快速作出反应。这反过来可能会增加对DNS服务器的请求量。
o Some DNS implementations do not always adhere to DNS standards. For example, many DNS implementations do not honor the DNS TTL field.
o 某些DNS实现并不总是遵循DNS标准。例如，许多DNS实现不支持DNS TTL字段。
o DNS Request-Routing is based only on knowledge of the client DNS server, as client addresses are not relayed within DNS requests. This limits the ability of the Request-Routing system to determine a client's proximity to the surrogate.
o DNS请求路由仅基于客户端DNS服务器的知识，因为客户端地址不会在DNS请求中中继。这限制了请求路由系统确定客户端与代理的接近程度的能力。
o DNS servers can request and allow recursive resolution of DNS names. For recursive resolution of requests, the Request-Routing DNS server will not be exposed to the IP address of the client's site DNS server. In this case, the Request-Routing DNS server will be exposed to the address of the DNS server that is recursively requesting the information on behalf of the client's site DNS server. For example, imgs.example.com might be resolved by a CN, but the request for the resolution might come from dns1.example.com as a result of the recursion.
o DNS服务器可以请求并允许递归解析DNS名称。对于请求的递归解析，请求路由DNS服务器将不会暴露于客户端站点DNS服务器的IP地址。在这种情况下，请求路由DNS服务器将暴露于代表客户端的站点DNS服务器递归请求信息的DNS服务器的地址。例如，imgs.example.com可能由CN解析，但由于递归，解析请求可能来自dns1.example.com。
o Users that share a single client site DNS server will be redirected to the same set of IP addresses during the TTL interval. This might lead to overloading of the surrogate during a flash crowd.
o 共享单个客户端站点DNS服务器的用户将在TTL间隔期间重定向到同一组IP地址。这可能会导致在flash群组中代理项过载。
o Some implementations of bind can cause DNS timeouts to occur while handling exceptional situations. For example, timeouts can occur for NS redirections to unknown domains.
o bind的某些实现在处理异常情况时会导致DNS超时。例如，NS重定向到未知域时可能会发生超时。
DNS based request routing techniques can suffer from serious limitations. For example, the use of such techniques can overburden third party DNS servers, which should not be allowed [19]. In [11] RFC 2782 provides warnings on the use of DNS for load balancing. Readers are encouraged to read the RFC for better understanding of the limitations.
基于DNS的请求路由技术可能受到严重限制。例如，使用此类技术可能会使第三方DNS服务器负担过重，这是不允许的[19]。在[11]中，RFC 2782提供了关于使用DNS进行负载平衡的警告。鼓励读者阅读RFC，以便更好地理解其局限性。
At the transport-layer finer levels of granularity can be achieved by the close inspection of client's requests. In this approach, the Request-Routing system inspects the information available in the first packet of the client's request to make surrogate selection decisions. The inspection of the client's requests provides data about the client's IP address, port information, and layer 4 protocol. The acquired data could be used in combination with user-defined policies and other metrics to determine the selection of a surrogate that is better suited to serve the request. The techniques [20][18][15] are used to hand off the session to a more appropriate surrogate are beyond the scope of this document.
在传输层，可以通过仔细检查客户机的请求来实现更精细的粒度级别。在这种方法中，请求路由系统检查客户端请求的第一个数据包中的可用信息，以做出代理选择决策。对客户端请求的检查提供了有关客户端IP地址、端口信息和第4层协议的数据。所获取的数据可以与用户定义的策略和其他度量结合使用，以确定选择更适合服务于请求的代理。[20][18][15]用于将会话移交给更合适的代理的技巧超出了本文档的范围。
In general, the forward-flow traffic (client to newly selected surrogate) will flow through the surrogate originally chosen by DNS. The reverse-flow (surrogate to client) traffic, which normally transfers much more data than the forward flow, would typically take the direct path.
通常，前向流流量（客户端到新选择的代理）将流经DNS最初选择的代理。反向流（代理到客户端）流量通常比正向流传输更多的数据，通常采用直接路径。
The overhead associated with transport-layer Request-Routing [21][19] is better suited for long-lived sessions such as FTP [1] and RTSP [3]. However, it also could be used to direct clients away from overloaded surrogates.
与传输层请求路由[21][19]相关的开销更适合于FTP[1]和RTSP[3]等长寿命会话。然而，它也可以用来引导客户端远离过载的代理。
In general, transport-layer Request-Routing can be combined with DNS based techniques. As stated earlier, DNS based methods resolve clients requests based on domains or sub domains with exposure to the client's DNS server IP address. Hence, the DNS based methods could be used as a first step in deciding on an appropriate surrogate with more accurate refinement made by the transport-layer Request-Routing system.
通常，传输层请求路由可以与基于DNS的技术相结合。如前所述，基于DNS的方法基于暴露于客户端DNS服务器IP地址的域或子域来解析客户端请求。因此，基于DNS的方法可作为确定适当代理的第一步，并由传输层请求路由系统进行更精确的细化。
Application-layer Request-Routing systems perform deeper examination of client's packets beyond the transport layer header. Deeper examination of client's packets provides fine-grained Request-Routing control down to the level of individual objects. The process could be performed in real time at the time of the object request. The exposure to the client's IP address combined with the fine-grained knowledge of the requested objects enable application-layer Request-Routing systems to provide better control over the selection of the best surrogate.
应用层请求路由系统对传输层报头之外的客户端数据包执行更深入的检查。对客户端数据包的深入检查提供了细粒度的请求路由控制，可以控制到单个对象的级别。该过程可以在对象请求时实时执行。暴露于客户机的IP地址，再加上对所请求对象的细粒度了解，使应用层请求路由系统能够更好地控制最佳代理的选择。
Some application level protocols such as HTTP [4], RTSP [3], and SSL [2] provide hints in the initial portion of the session about how the client request must be directed. These hints may come from the URL of the content or other parts of the MIME request header such as Cookies.
一些应用程序级协议，如HTTP[4]、RTSP[3]和SSL[2]在会话的初始部分提供有关必须如何引导客户端请求的提示。这些提示可能来自内容的URL或MIME请求头的其他部分，如Cookies。
Application level protocols such as HTTP and RTSP describe the requested content by its URL [6]. In many cases, this information is sufficient to disambiguate the content and suitably direct the request. In most cases, it may be sufficient to make Request-Routing decision just by examining the prefix or suffix of the URL.
HTTP和RTSP等应用程序级协议通过其URL描述请求的内容[6]。在许多情况下，这些信息足以消除内容的歧义并适当地引导请求。在大多数情况下，仅通过检查URL的前缀或后缀就可以做出请求路由决定。
In this approach, the client's request is first resolved to a virtual surrogate. Consequently, the surrogate returns an application-specific code such as the 302 (in the case of HTTP [4] or RTSP [3]) to redirect the client to the actual delivery node.
在这种方法中，客户机的请求首先解析为虚拟代理。因此，代理返回特定于应用程序的代码，例如302（在HTTP[4]或RTSP[3]的情况下），以将客户端重定向到实际的交付节点。
This technique is relatively simple to implement. However, the main drawback of this method is the additional latency involved in sending the redirect message back to the client.
这项技术实现起来相对简单。但是，此方法的主要缺点是将重定向消息发送回客户端时会增加延迟。
In this technique, an In-Path element is present in the network in the forwarding path of the client's request. The In-Path element provides transparent interception of the transport connection. The In-Path element examines the client's content requests and performs Request-Routing decisions.
在这种技术中，在网络中客户端请求的转发路径中存在一个In-Path元素。In-Path元素提供对传输连接的透明拦截。In-Path元素检查客户端的内容请求并执行请求路由决策。
The In-Path element then splices the client connection to a connection with the appropriate delivery node and passes along the content request. In general, the return path would go through the In-Path element. However, it is possible to arrange for a direct return by passing the address translation information to the surrogate or delivery node through some proprietary means.
In-Path元素然后将客户端连接拼接到具有适当传递节点的连接，并传递内容请求。通常，返回路径将通过In-path元素。但是，可以通过某些专有方式将地址转换信息传递给代理节点或交付节点，从而安排直接返回。
The primary disadvantage with this method is the performance implications of URL-parsing in the path of the network traffic. However, it is generally the case that the return traffic is much larger than the forward traffic.
此方法的主要缺点是网络流量路径中URL解析的性能影响。然而，通常情况下，返回流量远大于转发流量。
The technique allows for the possibility of partitioning the traffic among a set of delivery nodes by content objects identified by URLs. This allows object-specific control of server loading. For example, requests for non-cacheable object types may be directed away from a cache.
该技术允许通过URL标识的内容对象在一组传递节点之间划分流量。这允许特定于对象的服务器加载控制。例如，对不可缓存对象类型的请求可能会被定向到远离缓存的位置。
This technique involves the task of using HTTP [4] such as Cookie, Language, and User-Agent, in order to select a surrogate. In [20] some examples of using this technique are provided.
此技术涉及使用HTTP[4]的任务，如Cookie、语言和用户代理，以便选择代理。[20]中提供了使用该技术的一些示例。
Cookies can be used to identify a customer or session by a web site. Cookie based Request-Routing provides content service differentiation based on the client. This approach works provided that the cookies belong to the client. In addition, it is possible to direct a connection from a multi-session transaction to the same server to achieve session-level persistence.
Cookie可用于通过网站识别客户或会话。基于Cookie的请求路由提供了基于客户端的内容服务差异。只要cookie属于客户端，这种方法就可以工作。此外，还可以将连接从多会话事务定向到同一服务器，以实现会话级持久性。
The language header can be used to direct traffic to a language-specific delivery node. The user-agent header helps identify the type of client device. For example, a voice-browser, PDA, or cell phone can indicate the type of delivery node that has content specialized to handle the content request.
语言标头可用于将通信量定向到特定于语言的传递节点。用户代理标头有助于识别客户端设备的类型。例如，语音浏览器、PDA或手机可以指示具有专门用于处理内容请求的内容的交付节点的类型。
Site-specific identifiers help authenticate and identify a session from a specific user. This information may be used to direct a content request.
特定于站点的标识符有助于对特定用户的会话进行身份验证和标识。此信息可用于指导内容请求。
An example of a site-specific identifier is the SSL Session Identifier. This identifier is generated by a web server and used by the web client in succeeding sessions to identify itself and avoid an entire security authentication exchange. In order to inspect the session identifier, an In-Path element would observe the responses of the web server and determine the session identifier which is then used to associate the session to a specific server. The remaining sessions are directed based on the stored session identifier.
站点特定标识符的一个示例是SSL会话标识符。此标识符由web服务器生成，并由web客户端在后续会话中使用，以标识自身并避免整个安全身份验证交换。为了检查会话标识符，In-Path元素将观察web服务器的响应并确定会话标识符，然后使用该标识符将会话与特定服务器关联。其余会话根据存储的会话标识符进行定向。
This technique enables a content provider to take direct control over Request-Routing decisions without the need for specific witching devices or directory services in the path between the client and the origin server. Basically, a content provider can directly communicate to the client the best surrogate that can serve the request. Decisions about the best surrogate can be made on a per-object basis or it can depend on a set of metrics. The overall goal is to improve scalability and the performance for delivering the modified content, including all embedded objects.
此技术使内容提供商能够直接控制请求路由决策，而无需在客户端和源服务器之间的路径中使用特定的交换设备或目录服务。基本上，内容提供商可以直接向客户机传达能够服务于请求的最佳代理。关于最佳代理的决策可以基于每个对象，也可以取决于一组度量。总体目标是提高可伸缩性和性能，以交付修改后的内容，包括所有嵌入式对象。
In general, the method takes advantage of content objects that consist of basic structure that includes references to additional, embedded objects. For example, most web pages, consist of an HTML document that contains plain text together with some embedded objects, such as GIF or JPEG images. The embedded objects are referenced using embedded HTML directives. In general, embedded HTML directives direct the client to retrieve the embedded objects from the origin server. A content provider can now modify references to embedded objects such that they could be fetched from the best surrogate. This technique is also known as URL rewriting.
通常，该方法利用由基本结构组成的内容对象，这些基本结构包括对其他嵌入对象的引用。例如，大多数网页由包含纯文本的HTML文档和一些嵌入对象（如GIF或JPEG图像）组成。使用嵌入的HTML指令引用嵌入的对象。通常，嵌入式HTML指令指示客户端从源服务器检索嵌入式对象。内容提供者现在可以修改对嵌入对象的引用，以便可以从最佳代理中获取它们。这种技术也称为URL重写。
Content modification techniques must not violate the architectural concepts of the Internet [9]. Special considerations must be made to ensure that the task of modifying the content is performed in a manner that is consistent with RFC 3238 [9] that specifies the architectural considerations for intermediaries that perform operations or modifications on content.
内容修改技术不得违反互联网的体系结构概念[9]。必须特别注意确保修改内容的任务以与RFC 3238[9]一致的方式执行，RFC 3238[9]规定了对内容执行操作或修改的中介机构的体系结构注意事项。
The basic types of URL rewriting are discussed in the following subsections.
URL重写的基本类型将在以下小节中讨论。
In this scheme, a content provider rewrites the embedded URLs before the content is positioned on the origin server. In this case, URL rewriting can be done either manually or by using software tools that parse the content and replace embedded URLs.
在此方案中，内容提供者在将内容定位到源服务器上之前重写嵌入的URL。在这种情况下，URL重写可以手动完成，也可以使用软件工具解析内容并替换嵌入的URL。
A-priori URL rewriting alone does not allow consideration of client specifics for Request-Routing. However, it can be used in combination with DNS Request-Routing to direct related DNS queries into the domain name space of the service provider. Dynamic Request-Routing based on client specifics are then done using the DNS approach.
单独的先验URL重写不允许考虑请求路由的客户端细节。但是，它可以与DNS请求路由结合使用，将相关DNS查询定向到服务提供商的域名空间。然后使用DNS方法完成基于客户端特定信息的动态请求路由。
On-Demand or dynamic URL rewriting, modifies the content when the client request reaches the origin server. At this time, the identity of the client is known and can be considered when rewriting the embedded URLs. In particular, an automated process can determine, on-demand, which surrogate would serve the requesting client best. The embedded URLs can then be rewritten to direct the client to retrieve the objects from the best surrogate rather than from the origin server.
按需或动态URL重写，在客户端请求到达源服务器时修改内容。此时，客户机的身份是已知的，在重写嵌入的URL时可以考虑该身份。特别是，一个自动化的过程可以根据需要确定哪个代理将最好地服务于请求的客户机。然后可以重写嵌入的URL，以指示客户端从最佳代理检索对象，而不是从源服务器检索对象。
Content modification as a Request-Routing mechanism suffers from many limitation [23]. For example:
内容修改作为一种请求路由机制受到许多限制[23]。例如：
o The first request from a client to a specific site must be served from the origin server.
o 从客户端到特定站点的第一个请求必须由源服务器提供。
o Content that has been modified to include references to nearby surrogates rather than to the origin server should be marked as non-cacheable. Alternatively, such pages can be marked to be cacheable only for a relatively short period of time. Rewritten URLs on cached pages can cause problems, because they can get outdated and point to surrogates that are no longer available or no longer good choices.
o 已修改为包含对附近代理的引用而不是对源服务器的引用的内容应标记为不可缓存。或者，可以将此类页面标记为仅在相对较短的时间段内可缓存。缓存页面上重写的URL可能会导致问题，因为它们可能会过时，并指向不再可用或不再是好选择的代理。
There are environments in which a combination of different mechanisms can be beneficial and advantageous over using one of the proposed mechanisms alone. The following example illustrates how the mechanisms can be used in combination.
在某些环境中，不同机制的组合比单独使用其中一种机制更有利。下面的示例说明了如何组合使用这些机制。
A basic problem of DNS Request-Routing is the resolution granularity that allows resolution on a per-domain level only. A per-object redirection cannot easily be achieved. However, content modification can be used together with DNS Request-Routing to overcome this problem. With content modification, references to different objects on the same origin server can be rewritten to point into different domain name spaces. Using DNS Request-Routing, requests for those objects can now dynamically be directed to different surrogates.
DNS请求路由的一个基本问题是解析粒度，它只允许在每个域级别进行解析。每个对象的重定向不容易实现。但是，内容修改可以与DNS请求路由一起使用以克服此问题。通过内容修改，可以重写对同一源服务器上不同对象的引用，以指向不同的域名空间。使用DNS请求路由，这些对象的请求现在可以动态地定向到不同的代理。
The main objective of this document is to provide a summary of current Request-Routing techniques. Such techniques are currently implemented in the Internet. However, security must be addressed by any entity that implements any technique that redirects client's requests. In [9] RFC 3238 addresses the main requirements for entities that intend to modify requests for content in the Internet.
本文档的主要目的是总结当前的请求路由技术。这些技术目前在互联网上实施。然而，任何实现重定向客户端请求的技术的实体都必须解决安全问题。在[9]中，RFC 3238解决了打算修改互联网内容请求的实体的主要要求。
Some active probing techniques will set off intrusion detection systems and firewalls. Therefore, it is recommended that implementers be aware of routing protocol security [25].
一些主动探测技术将触发入侵检测系统和防火墙。因此，建议实施者了解路由协议的安全性[25]。
It is important to note the impact of TLS [2] on request routing in CNs. Specifically, when TLS is used the full URL is not visible to the content network unless it terminates the TLS session. The current document focuses on HTTP techniques. TLS based techniques that require the termination of TLS sessions on Content Peering Gateways [8] are beyond the of scope of this document.
必须注意TLS[2]对CNs中请求路由的影响。具体来说，当使用TLS时，完整URL对内容网络不可见，除非它终止TLS会话。当前文档重点介绍HTTP技术。需要在内容对等网关上终止TLS会话的基于TLS的技术[8]超出了本文档的范围。
The details of security techniques are also beyond the scope of this document.
安全技术的细节也超出了本文档的范围。
The following people have contributed to the task of authoring this document: Fred Douglis (IBM Research), Mark Green, Markus Hofmann (Lucent), Doug Potter.
以下人员参与了编写本文档的工作：弗雷德·道格利斯（IBM研究）、马克·格林、马克斯·霍夫曼（朗讯）、道格·波特。
The authors acknowledge the contributions and comments of Ian Cooper, Nalin Mistry (Nortel), Wayne Ding (Nortel) and Eric Dean (CrystalBall).
作者感谢Ian Cooper、Nalin Mistry（北电）、Wayne Ding（北电）和Eric Dean（CrystalBall）的贡献和评论。
Request-Routing systems can use a variety of metrics in order to determine the best surrogate that can serve a client's request. In general, these metrics are based on network measurements and feedback from surrogates. It is possible to combine multiple metrics using both proximity and surrogate feedback for best surrogate selection. The following sections describe several well known metrics as well as the major techniques for obtaining them.
请求路由系统可以使用各种度量来确定能够服务于客户端请求的最佳代理。一般来说，这些指标基于网络测量和代理的反馈。可以使用接近度和代理反馈组合多个度量，以实现最佳代理选择。以下各节描述了几个众所周知的指标以及获取这些指标的主要技术。
Proximity measurements can be used by the Request-Routing system to direct users to the "closest" surrogate. In this document proximity means round-trip time. In a DNS Request-Routing system, the measurements are made to the client's local DNS server. However, when the IP address of the client is accessible more accurate proximity measurements can be obtained [24].
请求路由系统可以使用接近度测量将用户引导到“最近的”代理。在本文件中，邻近性指往返时间。在DNS请求路由系统中，对客户端的本地DNS服务器进行测量。然而，当客户端的IP地址可访问时，可以获得更准确的接近度测量[24]。
Proximity measurements can be exchanged between surrogates and the requesting entity. In many cases, proximity measurements are "one-way" in that they measure either the forward or reverse path of packets from the surrogate to the requesting entity. This is important as many paths in the Internet are asymmetric [24].
可以在代理和请求实体之间交换接近度测量值。在许多情况下，邻近性测量是“单向”的，因为它们测量数据包从代理到请求实体的正向或反向路径。这一点很重要，因为互联网中的许多路径都是不对称的[24]。
In order to obtain a set of proximity measurements, a network may employ active probing techniques.
为了获得一组邻近测量，网络可以采用主动探测技术。
Active probing is when past or possible requesting entities are probed using one or more techniques to determine one or more metrics from each surrogate or set of surrogates. An example of a probing technique is an ICMP ECHO Request that is periodically sent from each surrogate or set of surrogates to a potential requesting entity.
主动探测是指使用一种或多种技术探测过去或可能的请求实体，以确定每个代理项或代理集的一个或多个度量。探测技术的一个示例是ICMP回显请求，该请求定期从每个代理或代理集发送到潜在的请求实体。
In any active probing approach, a list of potential requesting entities need to be obtained. This list can be generated dynamically. Here, as requests arrive, the requesting entity addresses can be cached for later probing. Another potential solution is to use an algorithm to divide address space into blocks and to probe random addresses within those blocks. Limitations of active probing techniques include:
在任何主动探测方法中，都需要获得潜在请求实体的列表。此列表可以动态生成。在这里，当请求到达时，可以缓存请求的实体地址，以便以后进行探测。另一个可能的解决方案是使用算法将地址空间划分为块，并探测这些块中的随机地址。主动探测技术的局限性包括：
o Measurements can only be taken periodically.
o 只能定期进行测量。
o Firewalls and NATs disallow probes.
o 防火墙和NAT不允许探测。
o Probes often cause security alarms to be triggered on intrusion detection systems.
o 探测器通常会在入侵检测系统上触发安全警报。
The following sections list some of the metrics, which can be used for proximity calculations.
以下部分列出了可用于邻近性计算的一些度量。
o Latency: Network latency measurements metrics are used to determine the surrogate (or set of surrogates) that has the least delay to the requesting entity. These measurements can be obtained using active probing techniques.
o 延迟：网络延迟测量指标用于确定对请求实体具有最小延迟的代理项（或代理项集）。可以使用主动探测技术获得这些测量值。
o Hop Counts: Router hops from the surrogate to the requesting entity can be used as a proximity measurement.
o 跃点计数：从代理到请求实体的路由器跃点可以用作接近度测量。
o BGP Information: BGP AS PATH and MED attributes can be used to determine the "BGP distance" to a given prefix/length pair. In order to use BGP information for proximity measurements, it must be obtained at each surrogate site/location.
o BGP信息：BGP AS PATH和MED属性可用于确定到给定前缀/长度对的“BGP距离”。为了使用BGP信息进行近程测量，必须在每个代理站点/位置获取BGP信息。
It is important to note that the value of BGP AS PATH information can be meaningless as a good selection metric [24].
需要注意的是，作为路径信息的BGP值作为一个好的选择度量可能毫无意义[24]。
In order to select a "least-loaded" delivery node. Feedback can be delivered from each surrogate or can be aggregated by site or by location.
以选择“负载最少”的交付节点。反馈可以从每个代理传递，也可以按站点或位置聚合。
Feedback information may be obtained by periodically probing a surrogate by issuing an HTTP request and observing the behavior. The problems with probing for surrogate information are:
通过发出HTTP请求并观察行为，定期探测代理，可以获得反馈信息。探测代理信息的问题有：
o It is difficult to obtain "real-time" information.
o 很难获得“实时”信息。
o Non-real-time information may be inaccurate.
o 非实时信息可能不准确。
Consequently, feedback information can be obtained by agents that reside on surrogates that can communicate a variety of metrics about their nodes.
因此，驻留在代理上的代理可以获得反馈信息，代理可以传递有关其节点的各种度量。
[1] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.
[1] Postel，J.和J.Reynolds，“文件传输协议”，标准9，RFC 959，1985年10月。
[2] Dierks, T. and C. Allen, "The TLS Protocol Version 1", RFC 2246, January 1999.
[2] Dierks，T.和C.Allen，“TLS协议版本1”，RFC 2246，1999年1月。
[3] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming Protocol", RFC 2326, April 1998.
[3] Schulzrinne，H.，Rao，A.和R.Lanphier，“实时流协议”，RFC2326，1998年4月。
[4] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[4] 菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC2616，1999年6月。
[5] Partridge, C., Mendez, T. and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993.
[5] 帕特里奇，C.，门德斯，T.和W.米利肯，“主持任意广播服务”，RFC15461993年11月。
[6] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.
[6] Berners Lee，T.，Masinter，L.和M.McCahill，“统一资源定位器（URL）”，RFC 17381994年12月。
[7] Schulzrinne, H., Casner, S., Federick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
[7] Schulzrinne，H.，Casner，S.，Federick，R.和V.Jacobson，“RTP：实时应用的传输协议”，RFC 1889，1996年1月。
[8] Day, M., Cain, B., Tomlinson, G. and P. Rzewski, "A Model for Content Internetworking (CDI)", RFC 3466, February 2003.
[8] Day，M.，Cain，B.，Tomlinson，G.和P.Rzewski，“内容互联网（CDI）模型”，RFC 3466，2003年2月。
[9] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002.
[9] Floyd，S.和L.Daigle，“开放可插拔边缘服务的IAB架构和政策考虑”，RFC 3238，2002年1月。
[10] Eastlake, D. and A, Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999.
[10] Eastlake，D.和A，Panitz，“保留顶级DNS名称”，BCP 32，RFC 26061999年6月。
[11] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2002.
[11] Gulbrandsen，A.，Vixie，P.和L.Esibov，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2782，2002年2月。
[12] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[12] Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[13] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1035, November 1987.
[13] Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 10351987年11月。
[14] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
[14] Elz，R.和R.Bush，“DNS规范的澄清”，RFC 21811997年7月。
[15] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I. and X. Xiao, "Overview and Principles of Internet Traffic Engineering", RFC 3272, May 2002.
[15] Awduche，D.，Chiu，A.，Elwalid，A.，Widjaja，I.和X.Xiao，“互联网流量工程概述和原则”，RFC 3272，2002年5月。
[16] Crawley, E., Nair, R., Rajagopalan, B. and H. Sandick, "A Framework for QoS-based Routing in the Internet", RFC 2386, August 1998.
[16] Crawley，E.，Nair，R.，Rajagopalan，B.和H.Sandick，“互联网中基于QoS的路由框架”，RFC 2386，1998年8月。
[17] Huston, G., "Commentary on Inter-Domain Routing in the Internet", RFC 3221, December 2001.
[17] Huston，G.“因特网域间路由评论”，RFC 3221，2001年12月。
[18] M. Welsh et al., "SEDA: An Architecture for Well-Conditioned, Scalable Internet Services", Proceedings of the Eighteenth Symposium on Operating Systems Principles (SOSP-18) 2001, October 2001.
[18] M.Welsh等人，“SEDA：条件良好、可扩展互联网服务的体系结构”，第十八届操作系统原理研讨会论文集（SOSP-18），2001年10月。
[19] A. Shaikh, "On the effectiveness of DNS-based Server Selection", INFOCOM 2001, August 2001.
[19] A.Shaikh，“基于DNS的服务器选择的有效性”，INFOCOM 2001年，2001年8月。
[20] C. Yang et al., "An effective mechanism for supporting content-based routing in scalable Web server clusters", Proc. International Workshops on Parallel Processing 1999, September 1999.
[20] C.Yang等人，“在可扩展Web服务器集群中支持基于内容路由的有效机制”，Proc。1999年并行处理国际讲习班，1999年9月。
[21] R. Liston et al., "Using a Proxy to Measure Client-Side Web Performance", Proceedings of the Sixth International Web Content Caching and Distribution Workshop (WCW'01) 2001, August 2001.
[21] R.Liston等人，“使用代理测量客户端Web性能”，2001年第六届国际Web内容缓存和分发研讨会（WCW'01）论文集，2001年8月。
[22] W. Jiang et al., "Modeling of packet loss and delay and their effect on real-time multimedia service quality", Proceedings of NOSSDAV 2000, June 2000.
[22] 蒋文华等，“数据包丢失和延迟的建模及其对实时多媒体服务质量的影响”，《NOSSDAV 2000年学报》，2000年6月。
[23] K. Johnson et al., "The measured performance of content distribution networks", Proceedings of the Fifth International Web Caching Workshop and Content Delivery Workshop 2000, May 2000.
[23] K.Johnson等人，“内容分发网络的测量性能”，2000年第五届国际网络缓存研讨会和内容交付研讨会论文集，2000年5月。
[24] V. Paxson, "End-to-end Internet packet dynamics", IEEE/ACM Transactions 1999, June 1999.
[24] V.Paxson，“端到端互联网数据包动态”，IEEE/ACM交易1999年，1999年6月。
[25] F. Wang et al., "Secure routing protocols: Theory and Practice", Technical report, North Carolina State University 1997, May 1997.
[25] F.Wang等人，“安全路由协议：理论与实践”，技术报告，北卡罗来纳州立大学，1997年，1997年5月。
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何努力来确定任何此类权利。有关IETF在标准跟踪和标准相关文件中权利的程序信息，请参见BCP-11。可从IETF秘书处获得可供发布的权利声明副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涉及实施本标准所需技术的专有权利。请将信息发送给IETF执行董事。
Abbie Barbir Nortel Networks 3500 Carling Avenue Nepean, Ontario K2H 8E9 Canada
加拿大安大略省内皮恩卡林大道3500号北电网络有限公司K2H 8E9
Phone: +1 613 763 5229
EMail: abbieb@nortelnetworks.com
Phone: +1 613 763 5229
EMail: abbieb@nortelnetworks.com
Brad Cain Storigen Systems 650 Suffolk Street Lowell, MA 01854 USA
美国马萨诸塞州洛厄尔萨福克街650号Brad Cain Storigen Systems 01854
Phone: +1 978-323-4454
EMail: bcain@storigen.com
Phone: +1 978-323-4454
EMail: bcain@storigen.com
Raj Nair 6 Burroughs Rd Lexington, MA 02420 USA
美国马萨诸塞州列克星敦巴勒斯路6号拉杰奈尔02420
EMail: nair_raj@yahoo.com
EMail: nair_raj@yahoo.com
Oliver Spatscheck AT&T 180 Park Ave, Bldg 103 Florham Park, NJ 07932 USA
美国新泽西州弗洛勒姆公园103号楼公园大道180号奥利弗·斯帕切克电话电报公司07932
EMail: spatsch@research.att.com
EMail: spatsch@research.att.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
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 assignees.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
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编辑功能的资金目前由互联网协会提供。