有关ICP(Internet Cache Protocol)协议的总结(二)之RFC2187

来源：互联网发布：投资书籍推荐知乎编辑：程序博客网时间：2024/06/15 12:10

为什么写完了三才来写二呢？因为《ICP.....二》是对RFC2187协议的翻译，这活对我来说有点难度。特别是我连6级都还没过的情况下。哎！

亲们，转载请注明出处哦！！！

ICP协议是个在缓存服务器间进行通信的轻量级的消息协议。ICP用于缓存服务器之间交换关于URL地址是否存在的提示。缓存服务器间通过ICP协议的请求和应答消息，交换有关对象的位置信息，以此来决定最适合的检索当前对象的位置。

这个文档介绍了ICP的软件实施细则。如果需要知道ICP协议的说明和消息格式，请参照RFC 2186规范。我们避免作出关于有关ICP协议应在特定的Web缓存配置中使用的判断。在一些情况中ICP协议是非常适合的，在另外一些情况中是不适合的。我们认识到，这个文档里所描述的某些做法是不理想的。其中一些存在历史原因。在以后的版本中某些方面都有所改进。该文件只能描述目前的一些实际应用，我们重点是记录而不是评价。然而，我们确实的知道存在安全问题或其他缺点。

本文档的其余部分如下。我们首先描述的Web缓存的结构，解释使用ICP动机，并演示如何配置缓存层次结构中的使用。我们再提供一个ICP查询响应事务的一步一步的描述。我们接着讨论了ICP与防火墙的关系，并简要讨论了组播ICP。最后我们将研究到目前为止该协议在开发和部署过程中有过的经验教训，与典型的安全考虑。

二、Web高速缓存结构

一个单一的缓存服务器将尽可能的减少由其管辖范围的客户端产生的流量。同样的，一组缓存服务器可以通过用大致的方法共享一个缓存，获取相同的便利。关于收获型项目的研究表明，以分层连接的web缓存机制是很重要的。在缓存的层次（或者网状）结构中，缓存会与他相邻的缓存建立对等关系。有两种关系：层次模型和分布式模型。层次模型中，各缓存之间是树状结构；分布式模型中，所有的缓存属于同一级。术语“邻”和“对等体”是用来指任何与本缓存只有一跳距离的父或同级缓存。图一描述了一个简单的层次结构。

图一、一个简单的web缓存结构。本地缓存可以通过同级缓存检索信息，并且可以通过父缓存节点检索命中和非命中消息，以及检索源服务器。

但是，究竟什么是“同级”和“上一级”？这个定义是在层级结构基础上的。当一个缓存服务器没有需要的对象时，他可以通过ICP询问相邻的缓存服务器是否有此对象。如果相邻的缓存有请求的对象（命中），当前缓存将向他请求该对象。如果任一相邻的缓存服务器都没有此对象（未命中），那么缓存必须向父缓存，或直原始服务器转发此请求。层次结构和分布式结构的基本区别是：一个“邻居命中”消息可以是来自于这两个模型；但是“邻居未命中”消息只能来源于层次结构。换句话说，在分布式的模型中，缓存只能要求检索的兄弟缓存已经有了的对象。而同样的在层级结构中缓存可以向父缓存询问，无论它是否缓存可要求检索的对象。层次模型的缓存的机制是，如果有必要或者因为父缓存一般存在于网络中转服务提供者一定范围或者路径上，一个缓存可以为需求方提供中转。

Squid 和Harvest系统，允许更复杂的结构（所谓的混合式模型，参照《web缓存技术总结》http://blog.csdn.net/simongyley/article/details/23353619）。例如，可以指定一个给定的邻居可用于只有一类特定的要求，如从一个特定的DNS域的URL。此外，他可以在某些请求下将一个邻居节点视为父节点，某些请求时将其视为同级节点。

这里描述的高速缓存层次结构模型为了防止顶级缓存成为瓶颈包含了许多优化功能。其中之一是，防止父节点被当成之前的描述再被利用一次。另一个优化是，缓存间只向邻居缓存转发可以被缓存的对象。一大类的web请求本身不能被缓存（在回复中添加了不可缓存标志），包括：需要认证的某些类型的请求，会话加密数据，高度个性化的回复消息，和某些类型的数据库查询。第一级别的缓存应该处理这些请求，而不是像父级缓存转发增加其负担。

三、ICP协议的附加价值

虽然可以不使用ICP维持高速缓存层次结构，但是ICP或类似机制的缺乏禁止了同级元通信关系的存在，比如：用来查询附近的关于一个特定文件的缓存机制。

一个关注使用ICP协议的交互，会增加针对http传输的ICP协议应答/查询的延迟。然而，如果ICP请求能在相邻的缓存中定位需求的对象，那么ICP协议的延时将比通过邻居发来的更快交付的时间偏移更大。为了最小化ICP协议的延时，缓存（协议本身也是）被设计的将很快回复ICP请求。事实上，应用程序将对ICP请求做最小的处理，大部分ICP协议相关的延迟都可以归咎于网络传输时延。

同时ICP也用于证明邻居是可达的。如果ICP从邻居的回复无法到达，那么无论是网络路径拥塞（或向下），或缓存的应用程序将不会在ICP要求的邻居的机器上运行。在这些情况下，缓存服务器不能用这些邻居的缓存。此外，由于一个空闲的缓存服务器应答的速度比繁忙的快，其他的都是同等的。因此，ICP提供了某种形式的负载平衡。

四、ICP结构的配置范例

在层次结构中配置缓存，需要建立对等关系，目前涉及在两个对等端点的手动配置。第一个高速缓存必须表明，另一个缓存是上级或同级。其他高速缓存将有可能添加的第一个高速缓存到访问控制列表中。

下面我们展示一个假设情况下的一些示例配置线路。假设我们有两个高速缓存，一个由ISP操纵，和另一个由用户操作。首先我们描述用户如何将他的缓存与ISP的对等。第二，我们描述了ISP在何种情况下会允许用户访问其缓存。

4.1、‘proxy.customer.org’缓存的配置范例

在Squid系统中，配置一个层次结构的缓存系统的上下级缓存时，需要在配置文件中输入“cache_host”指令，格式如下：

cache_host hostname type http-port icp-port [options]

其中，type的值可以为“patent”、“sibling”或者“multicast”。对于我们的例子来说，我们可以配置成：

cache_host cache.isp.com parent 8080 3130

这样的配置会使子缓存服务器解决大部分父缓存服务器没能缓存的对象。（'cgi-bin”和非GET请求会被直接解决）。

使用中的父节点有可能对于一些特定服务器是不可取的，如在customer.org域中的服务器。为了直接处理这样的本地域，客户可以将下列配置加入到他的配置文件：

local_domain customer.org

也有可能是这样的情况，用户想要使用ISP缓存服务器仅仅是为了一个DNS域的特定子集。对于这种请求限制的需求，在高级别的缓存层次结构中更常见。尽管如此，我们仍然在此说明。限制ISP的DNS域名缓存的一个子集，客户会可以下面的配置语句增加到配置文件中：

cache_host_domain cache.isp.com com net org

4.2、‘cache.isp.com’缓存的配置范例

配置查询接受方的使用了访问列表的同伴关系，类似用于路由的节点。访问列表支持很大程度上的对等关系的定制。如果没有接入线路，缓存允许默认情况下的请求。

请注意，cache.isp.com缓存不需要显式地指定客户缓存作为同伴，也不是关系编码的ICP查询类型本身。访问控制项调节这个缓存和它的邻居之间的关系。在我们的示例中，ISP会使用：

acl src Customer proxy.customer.org
http_access allow Customer
icp_access allow Customer

这定义了一个条目名为“客户“的访问控制，它指定了源IP地址的客户缓存机。客户的缓存将允许向http和icp端口发送任何请求（包括缓存未命中）。这种配置意味着ISP缓存是客户端缓存的父节点。

如果ISP需要实施一个层级关系，它需要拒绝访问缓存未命中的消息。可以配置如下：

miss_access deny Customer

当然，ISP也要将这消息跟用户同步，这样用户也可以改变他层级关系中父节点和子节点的配置。不然，如果用户请求一个不再ISP缓存中的对象时，就会发生错误。

五、ICP协议的应用

以下各节描述了在Harvest（研究版本）和Squid缓存包中ICP的实现。主要依据版本号，也就是说版本1.4p12用于Harvest，版本1.1.10用户Squid。在ICP交互事件的基本顺序如下：

1.本地缓存收到一个从缓存客户端来的http请求

2.本地缓存发送ICP请求

3.客户端缓存接收到请求，并发送ICP回复

4.本地缓存收到ICP回复，然后决定下一个请求向谁发出

5.1、发送ICP请求

5.1.1、判断是否需要使用ICP

注意，每一个http请求都要求发送一个ICP请求。很明显，缓存命中将不再需要ICP，因为其要求立即被满足。如果源服务器在物理上非常接近缓存服务器，我们不想用到任何的邻居缓存。在Squid和Harvest系统中，管理员指定构成一个“本地”服务器的local_domain”和“local_ip配置选项的内容，缓存总是直接的跟本地服务器进行交互，从不向一个邻居缓存请求。

还有其他类别的请求，缓存（或者管理员）可能更愿意直接向源服务器请求，在Squid和Harvest系统中，这一类包括所有的非GET请求的方法。一个Squid缓存也可以配置为不使用URL去匹配”hierarchy_stoplist”。

为了让HTTP请求以产生一个ICP的交互，它必须：

o 不能缓存命中

o 不能是本地服务器

o 产生get请求

o 不匹配“hierarchy_stoplist”配置

我们称之为“层次化”的请求。非层次化的请求没有产生任何ICP的交互。为了避免处理那些可能降低缓存效率的请求，可以配置缓存不配置针对特定字符串的URL的参考层次（例如“cgi_bin’）。

5.1.2、确定去查询哪些节点

默认情况下，一个缓存将向所有节点发送一条ICP_OP_QUERY消息，除非以下的条件有任何一条满足：

o 限制防止为这种请求查询一个节点，基于配置指令的cache_host_domain’，它指定了一套DNS域（从URLs中），可以查询或者不能被查询节点。在Squid系统中，更灵活的指令（'cache_host_acl”）支持限制请求的其他部分（方法，端口号，源，等的限制）。

o 节点是分布式结构的，http请求中包含不能缓存（no-cache）头域。这是因为分布式模型中，需要缓存间透传请求，这是不被允许的。

o 节点被配置成永远不能发送ICP请求（比如：包含了“no-query”选项）

如果候选的只有一个可供查询的ICP节点，并且Squid配置指令的“single_parent_bypass”参数也被设置了，那么可以循环等待那个单节点的ICP回复响应，并且直接将http请求发送到节点缓存。

Squid的‘source_ping’配置选项，配置了一个Squid缓存服务器，在源服务器比任何的缓存更接近节点时，可以通过向源服务器发送含有ICP请求的”ping“指令。

5.1.3、计算的ICP应答的号

Squid和Harvest系统希望最大化从缓存中换取命中消息的概率。因此，缓存等待所有ICP回复被收到。通常情况下，我们期望得到的每个查询的ICP消息的回复，除了：

o 当节点被认为是已经被关闭了。如果一个缓存关闭了，Squid和Harvest系统仍然会继续向这个缓存发送ICP请求，但是不会期望它回复。当从这样的缓存收到了回复，那么他的状态将变为”在线“。

在Squid和Harvest系统演化的过程中，判断服务器是在线状态的方法也有一些改变。Squid和Harvest系统都认为当一个节点连续20次没有返回ICP请求的响应，那么它是不在线的。在Squid系统中同时也认为，如果一个TCP连接建立失败，那么这个缓存也是不在线的，当TCP连接成功，这台服务器又上线了。

o 当发送到一个多播地址。在这种情况下，我们可能会期望得到一个以上的回答，并没有办法明确确定有多少个。我们在下面的第7节将讨论组播问题。

5.1.4、设置超时事件

由于ICP采用UDP协议作为底层传输协议，ICP查询和回复可能有时被网络丢弃。如果不是所有的预期的回答都到达的话，缓存中会设置一个超时事件。默认情况下，Squid和Harvest系统采用二秒超时机制。如果超过超时时间但是对象检索尚未开始，一种源的选择机制将在第5.3.9描述。

5.2.接收ICP请求并且发送回复消息

当一条ICP_OP_QUERY消息收到时，缓存会解析它，并决定要发送什么响应消息。它会发送下列操作码之一，并且是按顺序匹配的：

5.2.1、ICP_OP_ERR

URL是从载荷中提取和解析出来的。如果解析失败，将返回一条ICP_OP_ERR信息。

5.2.2、ICP_OP_DENIED

访问控制会被检查。如果发现节点不能被允许做这样的回复，ICP_OP_DENIED消息将会被返回。Squid系统会对向每个节点发送的ICP_OP_DENIED消息进行计数。如果多于100个回复超过95%都被拒绝了，那就不再进行回复。这样可以防止错误的配置使得缓存不断来回发送不必要的ICP信息。

5.2.3、ICP_OP_HIT

如果缓存没有符合之前的任何一个操作码，这意味着请求被允许，我们必须确定这个请求是否会命中，于是我们要检查在本地缓存中是否存在此URL。如果存在，并且在未来的30秒内此条目是新鲜的，我们可以回复一个ICP_OP_HIT消息。采用局部刷新（或TTL）规则来确定新鲜或者陈旧状态。

注意：在兄弟节点之间存在一个ICP_OP_HIT 回复的竞争机制，ICP_OP_HIT消息意味着，指定URL的http请求随后会缓存命中。我们假设在ICP_OP_HIT消息之后很快就会有一个http请求到来。但是会有一个极微小的可能，在http请求来之前，对象已经被从缓存中清理出去了。如果这种情况发生，并且应答节点已经配置了Squid的‘miss_access’配置项，那么用户将会收到一个非常混乱的访问被拒绝的消息。

5.2.3.1、 ICP_OP_HIT_OBJ

在回复ICP_OP_HIT消息之前，我们会检查是否可以发送一个ICP_OP_HIT_OBJ消息进行替代。在下列情况可以使用ICP_OP_HIT_OBJ：

o ICP_OP_QUERY消息中ICP_FLAG_HIT_OBJ标志位被设置。

o 整个对象（包括URL）可以在一条ICP消息中发送。ICP消息的最大长度是16k字节。但是一个应用可以为ICP_OP_HIT_OBJ回复消息设置小点的最大长度。

正常情况下，ICP会在请求接收到之后马上进行回复。但是ICP_OP_HIT_OBJ消息只有在对象数据已经准备好可以被拷贝到回复体里之后才能被发送。对于Squid和Harvest系统这意味着如果对象不在内存中，那么它首先应该从硬盘上被交换到内存中。因此，ICP_OP_HIT_OBJ回复消息会比ICP_OP_HIT消息有更高的延迟。

5.2.4、ICP_OP_MISS_NOFETCH

这种情况下一位置缓存非命中。ICP有两种未命中消息。如果缓存服务器不希望用户节点从它这请求对象，它会发送一个ICP_OP_MISS_NOFETCH消息。

5.2.5、ICP_OP_MISS

ICP_OP_MISS作为默认消息发送。如果应答缓存服务器是请求缓存服务器的父级，ICP_OP_MISS消息表示通过向应答缓存获取URL的邀请。

5.3. 接受ICP回复消息

一些ICP回复将被忽略；特别是，当下列情况发生时：

o 回复消息来自于一个未知的终端节点。

o 由URL指定的对象不存在。

o 对象已经被获取过了。

5.3.1、ICP_OP_DENIED

如果从一个终端节点发来的多于100个回复消息中超过95%都被（ICP_OP_DENIED）拒绝了。这表明，如此高的拒绝率很可能表明一个配置错误，可能是本地的也可能是终端节点的。那么，在缓存服务器运行的过程中，不会再向该终端节点发送请求。

5.3.2、 ICP_OP_HIT

应答终端节点可以立即开始检索对象。

5.3.3、 ICP_OP_HIT_OBJ

对象数据从ICP消息提取成功，并且检索已经完成。如果回复ICP_OP_HIT_OBJ时存在一些问题（比如，缺少数据），那么这个消息将会被当成ICP_OP_HIT对待。

5.3.4、 ICP_OP_SECHO

由于ICP_OP_SECHO消息在任何其他的ICP_OP_HIT消息之前到达，那么对象数据检索将在源服务器端进行。如果ICP_OP_HIT消息先到，那么ICP_OP_SECHO消息将被忽略，因为对象检索已经开始了。

5.3.5、 ICP_OP_DECHO

对于ICP_OP_DECHO消息的处理跟ICP_OP_MISS类似。非ICP类型的终端节点总被当做父节点；非ICP类型的终端节点在此是没有意义的。ICP_OP_DECHO消息的一个严重问题是，由于这个消息是从回复端的UDP端口发出的，这并不能表明回复端是在线的，只能表明之间存在网络连接。

5.3.6、ICP_OP_MISS

如果终端节点是分布式关系，那么ICP_OP_MISS回复将被忽略。不然，终端节点可能会记住，并且在将来没有收到命中消息时再次使用。

Squid和Harvest系统会记住第一个返回ICP_OP_MISS消息的父节点。在Squid系统中，父节点可以加权。那么实际上“第一个未命中的父节点”消息未必是第一个被收到。我们把这叫做FIRST_PARENT_MISS。记住分布式节点的未命中消息会被忽略，我们只关心父节点来的非命中消息。父节点的未命中RTT参数也可以被加权。因为有些时候最近的节点未必是我们想要采用的。

当然Squid最近的版本用了ICP_FLAG_SRC_RTT参数后可以记住通往到源节点的rtt数据最低的父节点。我们叫CLOSEST_PARENT_MISS。

5.3.7、ICP_OP_MISS_NOFETCH

这个回答基本上会被忽略。缓存不能发送一条ICP_OP_MISS_NOFETCH消息到终端节点。

5.3.8、ICP_OP_ERR

完全被忽略。

5.3.9、所有终端节点都未命中

当收到ICP_OP_HIT和ICP_OP_SECHO消息时，对对象的请求将马上发送。如果收到了ICP_OP_HIT_OBJ消息，那么就不需要发送请求了。对于其他的操作码，我们将采用等待回复数量达到一定的数量。当我们获取了所有期望的回复，或者当超时时间到达，那么就需要发起请求了。

由于从所有的终端节点都受到了未命中消息，我们就必须选择一个父节点或者源服务器。

o 如果节点使用icp_flag_src_rtt特征，我们将向与源节点之间的rtt值最低的父节点发送请求。如果本地缓存也测量到源服务器RTT的值，并且比任何一个父节点都要近，那么将直接向源节点进行请求。

o 如果有个有效地FIRST_PARENT_MISS父节点，将向此节点进行请求。

o 如果ICP查询/应答交换没有产生任何适当的父节点，那么将直接向源服务器进行请求（除非防火墙禁止这项操作）。

5.4、ICP选项

下列选项曾被加在Squid系统中为了支持一些新的功能。实现了跟Harvest系统的向后兼容。

5.4.1、ICP_FLAG_HIT_OBJ

这个标志位默认是关闭的，除非在符合下面三个标准的情况下会在ICP_OP_QUERY消息中进行设置：

o 缓存的配置文件中，有“udp_hit_obj on”配置。

o 终端节点必须使用ICPV2。

o http的请求不能包含“Pragma: no-cache”头域。

5.4.2、ICP_FLAG_SRC_RTT

这个标志位默认是关闭的，除非在符合下面两个标准的情况下会在ICP_OP_QUERY消息中进行设置：

o 缓存的配置文件中，有“query_icmp on”配置。

o 终端节点必须使用ICPV2。

六、防火墙

操作一个在防火墙后面或者在私有网络里的缓存服务器会带来一些有趣的问题。最难得部分是指出缓存是否应该链接源服务器。 Squid和Harvest系统提供一个“inside_firewall"的配置指令可以列出防火墙近端的DNS域。其他的一切都被认为是在防火墙的远端。Squid系统也有一个“firewall_ip”指令使的内部主机可以由IP地址指定。

在一个简单的配置中，一个在防火墙后面的Squid缓存只能有一个父级缓存（是建立在防火墙本身上的）。在这种情况下，Squid缓存必须使用那个父级缓存为防火墙后面的所有服务器服务。所以就没必要使用ICP协议了。

在更复杂的配置环境中，可能会有一些终端缓存在防火墙后面。在这里，ICP可以被用来检测终端节点的缓存命中。偶尔，当ICP在使用的时候，有可能没有收到任何回复。如果缓存服务器没有在防火墙后面，请求可能直接被发送到源服务器。但是在这种情况下，缓存必须选择一个父缓存，不管是随机选择还是有配置选取。比如，在Squid系统之前，在没有其它可用的缓存服务器时，父缓存被指定为默认的选择。

七、广播

为了更有效地分配，有些时候缓存服务器可能会把一个ICP请求发送到一个多播地址，一个邻居缓存可能会加入到这个多播组里来接收这些请求。

目前的做法是，缓存只发送ICP回复到单播地址，有几个原因：

o 多播ICP的回复不能减少发送的数据包数量

o 可以防止其他组的成员接受不需要的回复。

o 回复应该遵循由单播路由给出的在接收端和发送端之间的(单播)路径,因为随后的http请求都将单播路由。

信任是缓存间的关系的一个重要方面。一个缓存不应该主动信任任何一个回复广播ICP请求的缓存。缓存应该忽略并非配置中认为是邻居的缓存来的消息。不然，可以很容易的通过运行一个非法的缓存并将它加入一个组接着为所有的请求返回ICP_OP_HIT消息并提供虚假内容，来污染一个缓存网络。

当把消息发送到广播组时，缓存服务器管理员必须非常小心的使用达到所有组成员的最小广播TTL参数。加入一个广播组不需要特殊的权限，也没有办法阻止任何人加入“你”的组。使用相同的多播地址两组缓存可能重叠，这将导致缓存服务器惠存从未知的邻居接收到ICP回答。未知的邻居不应该用来检索对象的数据，但缓存将不断收到并且总是忽视其发来的ICP回复消息。

为了防止重叠缓存网格的发生，缓存间因此应该限制采用适当TTLS范围的ICP查询；类似mtrace的应用[ 6 ]可以确定合适的组播TTLS。

如第5.1.3所提到的，我们需要估计一个icp_op_query消息的预计回复数。对于单播，我们期望每一个查询都可以收到一个回复，如果终端节点在线。然而在广播情况下，我们期待可以有更多的回复，但是我们没有手段来确定到底有多少个回复。Squid定期（每15分钟）向广播组的节点发送测试的 ICP_OP_QUERY消息。作为一个实际的ICP查询过程，超时事件被设置，我们会记录回复数直到超时。我们发现，回复计数范围抖动很大。因此，计算出来的期望回复数一般是变化的平均值，向下舍入到最接近的整数。

八、经验学习

8.1、ICP和HTTP协议的不同点

ICP和http有着明显地不同。HTTP支持丰富和复杂的功能集。相反，ICP的设计是简单的，小的，有效的。HTTP请求和应答头包含ASCII文本形式的回车换行符分隔线，而ICP使用一个固定大小的头和二进制表示的数字。两者唯一相同点是URL。

请注意，ICP消息根本不包含http的请求方法。之前的实现方法都假设只有get方法是可以被缓存的，并且不需要定位在临缓存中的非-get请求。因此，ICP的当前版本不适应非GET请求，虽然该协议的下一版本将可能包括一个请求的方法。

HTTP定义了对缓存非常重要但是在ICP协议中无法表达的特征。这些参数是HTTP1.1中的：no-cache, If-Modified-Since, 和所有的Cache-Control特征。

一个icp_op_hit_obj消息可能传递一个不遵守所有请求标头的约束对象。我们之所以反对使用icp_op_hit_obj功能，就是因为这些在http和ICP中的差异。

8.2、层次模型、分布式模型，命中和未命中

请注意，ICP消息没有特殊字段来表明查询缓存的意图。这意味着，在ICP的查询和回复消息中没有明确说明这两台缓存服务器的关系是层次的还是分布的。一个分布式的缓存只能回复命中或者未命中，不能回复“你可以从我这检索”或者“你不能从我这检索”消息。请求端缓存为了防止从分布式模型中的邻居缓存解决未命中消息，必须在本地配置时应用“命中”或者“非命中”回复。这个约束是非常尴尬的，因为这方面的关系可以仅在发出请求的缓存服务器端配置，并且可以间接地通过配置查询缓存的访问控制中实现，就像第4.2节所描述的一样。

8.3、有关ICP协议的不同规则

对于ICP在缓存网格中的作用，有两种不同的理解。一种理解是，ICP规则只是用来定位对象的位置，具体而言，就是提示指定的对象是否存在于一个邻居缓存中。有一个隐喻表明缓存命中是非常可取的，ICP可以是用来最大限度地获得缓存命中的几率。如果ICP消息是由于拥塞而丢失，这并没有重大的损失；请求将无论如何都会被满足。

ICP正在被越来越多的用来充当一个复杂的角色：传输缓存使用机制。比如：许多机构（如大学）会在其网络的边界安装缓存服务器。这样的机构可能会乐意在遵循以下条款的情况下与其他组织、附近的缓存服务器建立分布式的模型关系：

o 该机构的所有用户或者客户都可以请求任何对象（缓存的或者没有缓存的）。

o 所有人都可以请求已经缓存在缓存服务器中的对象。

o 所有人都可以请求存在于改机构缓存服务器之后的服务器上的对象。

o 所有其他的请求被拒绝；具体地说就是，该组织将不会提供不属于其域的客户端或者服务器的请求。

8.4、ICPv2协议的设计缺陷

我们认识到ICP的原始设计的某些缺陷，并将他们进行了记录，期待未来的版本可以避免犯同样的错误。

o 在负载中的NULL结尾的URL地址需要通过解析消息一个字节一个字节一步一步的确认（即在一个icp_op_hit_obj消息中的对象数据的开始字段）。

o IPv4特定的两个域（发送方主机地址和请求的主机地址）。在实际使用中，这两个域基本都是采用0填充。如果在ICP消息中有IP地址的规则，那么就有必要设定一个地址簇来描述每一个地址，并且客户端有能力辨别他们是否需要通过IPv6来接收回复消息。

o 对于选项有些限制：不能超过32个选项，并且每个选项的数据长度不能超过32bit。这应该更像一个带有在选项数据之后有选项描述的TCP。

o 虽然URL字符串目前作为缓存服务器的主键在使用，但是它不能更充分地为这个目的服务。现在一些HTTP响应根据不同的用户请求中的的User-Agent和其他头域进行标定。缓存服务器的主键必须包括所有在客户端请求中的非可传递头域。所有非逐跳请求头应在ICP查询消息中发送。

o ICPv2为查询和回复消息采用不同的操作码值。ICP协议需要为应答双方使用相同的操作码值，并且通过“请求/响应”标志来确定双方。

o ICPv2没有鉴权方法。

九、安全注意事项

安全对于基于UDP的ICP协议来说是一个问题。下面我们要讨论针对各种漏洞的攻击和其影响。

我们的第一道防线是检查ICP消息的源IP地址，比如由recvfrom（2）给出的。如果访问控制规则允许查询地址查询词缓存，那么ICP查询消息应该被处理。然而，只能接受来自已知的邻居的ICP回复消息；缓存必须忽略从未知地址的回复消息。

因为相信IP地址分组的有效性，ICP容易受到IP地址欺骗。在这个文档中，我们解决了一些IP地址欺骗的后果。通常，只有路由器能检测到IP地址欺骗，主机做不到。然而。IP认证头[ 7,8 ]可以提供对整个含有ICP协议的IP包的密码认证，从而消除IP地址欺骗的风险。

9.1、插入虚假的ICP查询

只要请求的地址被访问的缓存服务器授权，那么处理一条ICP_OP_QUERY消息是没有已知的风险的。

9.2、插入虚假的ICP回复

这里我们关心的是在任何真实的回复消息之前到达的第三方生成的ICP回复消息。第三方可能会伪造一条似乎来自合法邻居的ICP的回答。有三个漏洞：

o 伪装成从一个正在使用的邻居缓存过来的消息。

如果一个第三方可以在一个真实的回复到达之前发送一个icp_op_miss_nofetch回复，这个（伪造）邻居将不会被使用。

一个第三方可以采用 ICP_OP_DENIED消息攻击缓存服务器直到达到5.3.1部分描述的阈值，从而使邻居关系是暂时终止。

o 迫使某个邻居被使用。

如果一个第三方可以在真正的回复消息到达之前发送一个ICP_OP_HIT响应，那么这个（伪造）邻居将会被使用。这可能违反了分布式关系的条款；icp_op_hit回答意味着随后的HTTP请求也将是命中的。

同样的，如果可以产生伪造的icp_op_secho消息，缓存将直接从源服务器检索请求。

o 缓存中毒

因为ICP_OP_HIT_OBJ消息包含了实际的对象数据，所以他对信息安全问题非常敏感。再结合IP地址欺骗，此情况可能导致“无效的缓存对象”错误。

9.3、窃听

组播ICP查询为别人对ICP的消息的“窥探”提供了一个非常简单的方法。如果启用多播，缓存服务器的管理员应使用例如mtrace这样的工具去配置应用去使用所需的最小的组播TTL。请注意，IP封装安全载荷[7,9]的机制可以被用来防止对ICP消息的窃听。

在ICP链路上的窃听可以向第三方提供已经缓存了的用户浏览的地址列表。因为在Squid和Harvest系统中，主机地址是由0填充的，URL不能映射到单个主机系统。

默认情况下，Squid和Harvest系统不会发送含有‘cgi-bin’或‘?’的ICP消息。有些时候这些URL会包含敏感信息作为参数的参数。缓存服务器的管理者必须意识到，改变ICP查询这些URL的配置可能会导致向外界公开敏感信息，尤其是当使用组播的时候。

9.4、阻塞ICP消息

故意堵塞（或丢弃）ICP查询或应答消息将表现为链路故障或拥塞，并将防止使用一个会导致超时的邻节点（见第5.1.4）。如果所有的消息被阻塞，缓存服务器将假设临节点已经不在服务了，并将其从选择算法中踢除。然而，如果，例如，所有对其他节点的查询受阻，那么缓存服务器会重新认为此邻节点会仍然活着，但之后所有对其的请求都会产生ICP超时。

9.5、延时ICO消息

邻居选择算法通常会等待接收到所有ICP未命中应答。查询或者应答被延时，那么他们会比通常情况下到来的晚，这会导致随后的HTTP请求也被延迟。当然，如果消息被延迟导致超时后他们才到达，该行为跟上面的“阻塞”相同。

9.6、拒绝服务

拒绝服务攻击，表现在ICP的消息端口会被充斥着一个连续的流的虚假的消息，这种攻击主要针对三个漏洞：

o 应用程序可以记录每一个假的ICP消息最终填满磁盘分区。

o 网络套接字接收队列可能被填满虚假消息，使合法消息被丢弃。

o 主机可能会浪费部分CPU去循环的接收虚假消息。

9.7、改变ICP领域

在此，我们假设第三方可以改变多个ICP应答消息域。

操作码：

如上面描述的一样，可以通过插入虚假消息来更改操作码字段。把“命中”状态改为“非命中”状态可能会阻止节点被使用。把“非命中”状态“改为“命中”状态，会导致原本不应该使用的节点被使用。

版本号：

如果新的版本号可以被识别和支持，那么改变ICP版本号字段可能带来不可预知的后果。接收端的应用应该忽略版本号字段不对的ICP消息。写这篇文档的同时，版本2和版本3同时在使用。这两个版本在相同的参数域的使用方法会有稍微的不同。

消息长度：

带有不正确消息长度的ICP消息应该被接收端的应用当做是错误消息而忽略。

请求号：

请求号经常被用来作为缓存服务器主键的一部分。Harvest系统不使用请求数。Squid用URL与连接请求号来定义一个缓存服务器的主键。改变请求号将会导致查询缓存主键的操作失败。这是相当于阻塞了所有的ICP应答。

虽然没有要求缓存服务器需要使用URL和请求号来定位使用了优秀的ICP查询的HTTP请求（但是Squid和Harvest系统这样做了）。请求号在请求和应答消息中必须保持一致。然而，如果查询的缓存服务器使用请求号来定位等待中的请求，那么应答的缓存服务器有可能增加回复请求号，这将导致两个缓存比实际上更接近对方的假象。

选项：

可选项参数改变的风险并不大。任何一个选项如果在请求中有被设置，那么在应答中也应该被设置。即使一点轻微的改变也会很明确的被查询缓存服务器检测到，这样的消息应该被忽略。一点轻微的改变是被允许的，同时也不会带来负面的影响。

选项的数据：

ICP_FLAG_SRC_RTT是唯一的使用选项数据的选项。修改了RTT的值，可以影响到邻节点选择算法，可能会导致强制使用一个邻节点或者阻止使用一个本来应该使用的邻节点。

URL：

URL和请求号用来生成缓存服务器的主键。改变URL会导致对缓存服务器主键查询的失败，还有就是相应ICP的应答消息完全被忽略了。这跟阻塞ICP的回复效果是一样的。

9.8、摘要

o ICP_OP_HIT_OBJ对于安全问题非常敏感，因为其包含了对象的数据。由于这些原因，在使用的过程中就要多加小心。

o 在这两种情况下，伪造、变更、插入或阻塞ICP消息将导致HTTP请求失败：

- 如果缓存服务器在防火墙后面并且不能直接跟源服务器连接。

- 如果一个虚假的icp_op_hit应答使得HTTP请求被转发到一个分布式节点上，并且这个请求在此节点上是未命中的，同时这个分布式节点也拒绝继续向源缓存去转发此请求。

o 伪造、变更、插入或阻止ICP消息容易引起HTTP请求消息被转发（或不转发）到特定的邻节点。如果邻居缓存也受到了损害，这将导致缓存网络被污染，并且提供虚假的对象内容。

o阻塞或延迟ICP消息可以导致HTTP请求被更大的延迟，但仍然是会被处理的。

十、参考

        [1] Fielding, R., et. al, "Hypertext Transfer Protocol -- HTTP/1.1",RFC 2068, UC Irvine, January 1997.
        [2] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, CERN, Xerox PARC, University of Minnesota,December 1994.
        [3] Bowman M., Danzig P., Hardy D., Manber U., Schwartz M., and Wessels D., "The Harvest Information Discovery and Access System",Internet Research Task Force - Resource Discovery,http://harvest.transarc.com/.
        [4] Wessels D., Claffy K., "ICP and the Squid Web Cache", National Laboratory for Applied Network Research,http://www.nlanr.net/˜wessels/Papers/icp-squid.ps.gz.
        [5] Wessels D., "The Squid Internet Object Cache", National Laboratory for Applied Network Research, http://squid.nlanr.net/Squid/
        [6] mtrace, Xerox PARC, ftp://ftp.parc.xerox.com/pub/netresearch/ ipmulti/.
        [7] Atkinson, R., "Security Architecture for the Internet Protocol",RFC 1825, NRL, August 1995.
        [8] Atkinson, R., "IP Authentication Header", RFC 1826, NRL, August 1995.
        [9] Atkinson, R., "IP Encapsulating Security Payload (ESP)", RFC 1827, NRL, August 1995.

0 0