重定向与负载均衡

为什么要重定向

现代网络中，重定向是普遍存在的：

• 可靠的执行HTTP事务
• 最小化时延
• 节约网络带宽 出于这些原因，Web内容通常分布在很多地方，以保证可用性。重定向是一种有助于找到“最佳”分布式内容的技术。

大多数重定向技术都包含了某种形式的负载均衡。

重定向到何地的

从客户端向目标发送HTTP请求，目标对其进行处理的角度来看，服务器、代理、缓存和网关对客户端来说都是服务器。很多重定向技术都可用于服务器、代理、缓存和网关。

Web服务器会根据每个IP来处理请求。将请求分摊到复制的服务器中去，就意味着应该把对某特定URL每条请求都发送得到最佳的Web服务器上去：最靠近客户端的、或负载最轻的或采用其他优化策略选择的服务器）。

代理希望根据每个协议来处理请求。在理想情况下，某个代理附近的所有HTTP流量都应该通过这个代理传输。

重定向协议概览

重定向的目标是尽快地将HTTP报文发送到可用的Web服务器上去。在穿过因特网的路径上，HTTP报文传输的方向会受到HTTP应用程序和报文经由路由设备的影响，参加以下示例：

• 配置创建HTTP报文的浏览器应用程序，使其将报文发送给代理服务器。
• DNS解析程序会选择用于报文寻址的IP地址。对不同物理低于的不同客户端来说，这个IP地址可能不同。
• 报文经过网络传输时，会被划分为一些带有地址的分组；交换机和路由器会检查分组中的TCP/IP地址，并据此来确定分组的发送数据。
• Web服务器可以通过HTTP重定向将请求反弹给不同的Web服务器。

通用的重定向方法

HTTP重定向

Web服务器可以将短的HTTP重定向报文发回给客户端，告诉它们去其他地方试试。

有些Web站点会将HTTP重定向作为一种简单的负载均衡形式来使用

返回HTTP重定向响应的服务器（重定向服务器），找到可用的负载最小的内容服务器，并将浏览器重定向到那台服务器上去。对广泛分布的Web站点来说，确定“最佳”的可用服务器会更复杂一些，不仅要考虑服务器的负载，还要考虑到浏览器和服务器之间的距离。

与其它重定向技术相比，HTTP重定向优点之一是重定向服务器知道客户端的IP地址，从而可以做出更合理的选择。

HTTP重定向可以在服务器间导引请求，但是它有以下几个缺点：

• 需要原始服务器进行大量处理来判断要重定向到哪台服务器上去。有时，发布重定向所需处理量几乎与提供页面本身所需处理量一样。
• 增加了用户时延，因为访问页面时要进行两次往返。
• 如果重定向服务器出现故障，站点就会瘫痪。

DNS重定向

• DNS轮转算法：最常见的重定向技术也是最简单的重定向技术。DNS对服务器的每次查询都会得到不同的服务器地址序列（尤其是首地址）。
• 负载均衡算法：有些DNS服务器会跟踪Web服务器的负载，将负载最轻的Web服务器放在列表的最前面
• 邻接路由算法：Web服务器集群在地理上分散时，DNS服务器会尝试着将用户导向最近的Web服务器
• 故障屏蔽算法：DNS服务器可以监视网络的状况，并将请求绕过出现服务终端或其它故障的地方

  任播寻址

  在任播寻址中，几个地理上分散的Web服务器拥有完全相同的IP地址，而且会通过骨干路由器的最短路径路由功能将客户端的请求发送给离它最近的服务器。 这仍然是一项实验性技术。

  IP MAC转发

  四层交换机

  IP 地址转发

  网络地址转换

  网元控制协议

• 网元： NE，Network Element，路由器和交换机等负责转发IP分组的设备
• 服务器元素： SE，Server Element，Web服务器和代理缓存等提供应用层请求的设备

NECP（Network Element Control Protocol，网元控制协议）允许网元与服务器元素进行交互。

NECP并未显式提供对负载均衡的支持；它只是为SE提供了一种发送负载均衡信息给NE的方式，这样NE就可以在它认为合适的情况下进行负载均衡了。

与WCCP一样，NECP也提供了几种转发分组的方式： MAC转发、GRE封装和NAT。

代理的重定向方法

Web浏览器客户端怎么才会知道要连接到某个代理上去呢？可以用3种方法来判断：

• 显式的浏览器配置
• 动态自动配置
• 透明拦截

代理可以顺次将客户端请求重定向到另一个代理上去。响应就会来自与客户端请求资源的地址不同的另外一个地址。还要讨论几种用于对等代理-缓存重定向的协议：ICP、CARP和HTCP。

缓存重定向的方法

WCCP可以使路由器将Web流量重定向到代理缓存中去。WCCP负责路由器和缓存服务器之间的通信，这样路由器就可以对缓存进行验证（确保它们已启动且正在运行），在缓存之间进行负载均衡，并将特定类型的流量发送给特定的缓存了。

WCCP重定向是如何工作的

• 启动包含了一些支持WCCP的路由器和缓存的网络，这些路由器和缓存之间可以相互通信。
• 一组路由器及其目标缓存构成一个WCCP服务组。服务组的配置说明了要将何种流量发往何处、流量是如何发送的以及如何在服务组的缓存之间进行负载均衡。
• 如果服务组配置为重定向HTTP流量，服务组中的路由器就会将HTTP请求发送给服务组中缓存。
• HTTP请求抵达服务组中的路由器时，路由器会（根据对请求IP地址的散列，或者“掩码/值”的配对策略）选择服务组中的某个缓存为请求提供服务。
• 路由器向缓存发送请求分组，可以用缓存的IP地址来封装分组，也可以通过IP MAC转发来实现。
• 如果缓存无法为请求提供服务，就将分组返回给路由器进行普通的转发。
• 服务组中成员会互相交换心跳报文，不断验证对方的可用性。

因特网缓存协议

ICP是一个对象发现协议，允许缓存在其兄弟缓存中查找命中内容。 如果某个缓存中没有HTTP报文请求的内容，它可以查明内容是否在附近的兄弟缓存中，如果在，就从那里获取内容，以避免查询原始服务器而带来的更多开销。

可以把ICP当作一个缓存集群协议。

HTTP请求报文的最终目的地可以通过一系列的ICP查询确定，从这个角度来说，ICP就是一个重定向协议。

ICP会同时询问附近的多个缓存，看看它们的缓存中是否有特定的URL。附近的缓存中如果有那个URL的话，就会返回一个简短的HIT报文，如果没有就返回MISS报文。

ICP报文是一个以网络字节序表示的32位封装结构。为了提高效率，可以由UDP承载其报文。

• Opcode： 操作码，ICP_OP_QUERY，ICP_OP_HIT，ICP_OP_MISS
• 版本： 8位
• 报文长度： 以字节为单位的ICP报文总长，16位。
• 请求编号： 记录多个同时发起的请求和响应
• 选项：
• 可选数据：
• 发送端主机地址： 承载了报文发送端的32位IP地址，实际中未使用
• 净负荷： 内容取决于报文的类型。

缓存阵列路由协议

代理服务器通过拦截来自单个用户的请求，提供所请求的Web对象的缓存副本，极大地降低了发往因特网地流量。但随着用户数地增加，大量流量可能会使代理服务器自身超载。

使用多个代理服务器将负载分散到一组服务器上

CARP用来管理一组代理服务器，使这组代理服务器对用户来说就像一个逻辑缓存一样。

CARP是ICP的一个替代品。

CARP和ICP的区别

ICP协议连接起来的每个代理服务器都是将内容进行了冗余镜像的独立缓存服务器，这就说明在不同的代理服务器之间复制Web对象条目是可行的。

CARP协议连接起来的一组服务器会被当作一个大型的服务器，其中每个组件服务器都只包含全部缓存文档中的一部分。 通过对某个Web对象的URL应用散列函数，CARP就可以将此对象映射到特定的代理服务器上去。 每个Web对象都有一个唯一的存储地址，可以通过单次查找确定对象的位置，而无需去查询集合中配置的每个代理服务器。

超文本缓存协议（HTCP）

ICP允许代理缓存向兄弟缓存查询文件是否存在。但是设计ICP时，考虑的是HTTP/0.9协议，因此，向兄弟缓存查询资源是否存在时，只允许发送URL。 HTCP允许兄弟缓存之间通过URL和所有的请求及响应首部来相互查询文档是否存在，以降低错误命中的可能。

HTCP允许兄弟缓存监视或请求在对方的缓存中添加或者删除所选中的文档，并修改对方已缓存文档的缓存策略。

HTCP认证

HTCP报文的认证部分时可选的。认证组件部分如下：

• 认证部分长度： 报文认证部分字节数，16位，包含了长度字段自身的长度。
• 签名时间： 32位，格林尼治标准时间，从1970年1月1日开始的秒数
• 签名过期时间： 32位
• 密钥名称： 用来表示共享密钥名称的字符串。密钥字段包含两个部分：用来说明后面哪个字符串长度的16为字节数，后面跟着的时未经解释的字节流
• 签名： HMAC-MD5摘要。签名也包括两个部分：16为字节数说明长度和字节流。

  设置缓存策略

  SET报文允许缓存请求对已缓存文档的缓存策略进行修改。

HTCP允许通过查询报文将请求和响应首部发送给兄弟缓存，这样可以降低缓存查询中的错误命中率。

通过进一步允许在兄弟缓存间交换策略信息，HTCP还可以提高兄弟缓存之间的合作能力。