基于应用层协议重定向的GSLB《CDN技术详解》

应用层重定向主要利用了HTTP、MMS、RTSP等协议本身的重定向机制来实现，由于各种应用层协议的重定向机制基本相同，因此以HTTP协议为例，介绍相关的知识。

1. HTTP重定向基本原理

在HTTP协议中，有三类重定向状态码：301 redirect、302 redirect与meta fresh。
1）301 redirect代表永久性转移（Permaneutly Moved）
2）302 redirect代表暂时性转移（Temporarily Moved）
3）meta fresh代表在特定时间后重定向到新的网页。

HTTP状态代码是在服务器返回数据的第一行实现的，比如你访问www.g.cn这个网址．Google的服务器返回的数据第一行是：HTTP/1.1 301 Moved Permanently，页面自动眺转到http://www.google.cn，表示g.cn这个URL被永久重定向到http://www.google.cn。

三类重定向的作用都是将用户的资源请求转向到另外一个URL，而这一节所说的HTTP重定向，是用于CDN均衡调度的，显然应该选择302 redirect。因为负载均衡系统需要实现的是将用户立刻且暂时性地重定向到另一台服务设备上去。

比如浏览器请求www.tanxingcai.com这个域名，服务器返回应答消息如下：

HTTP/1.1 302 Found
Date: Wed, 17 Mar 2010 08:11:11 GMT
Server: Apache/2.2.15 (Unix) mod_ssl/2.2.15 0penSSL/0.9.7a DAV/2
PHP/5.2.9
X-Powered-By, PHP/5.2.9
Location : http://bj.tanxingcai.com
Content-Length: 0

浏览器得到这个应答后，会再次发起请求，只不过请求的域名替换成http://bj.tanxingcai.com。有时候，域名替代也直接使用IP地址。

利用HTTP重定向的GSLB工作过程大致是：

1. 用户在浏览器地址栏里输入一个域名，如HTTP://www.tanxingcai.com；
2. 本地DNS服务器返回的解析结果是GSLB的IP地址；
3. 用户端浏览器会向GSLB发起HTTP请求，GSLB向浏览器返回响应请求的HTTP数据包；
   这个HTTP数据包的头信息（Header）中会包含一条“302 found”信息，告诉用户向某个IP地址的服务器请求内容。在这个过程中，GSLB还会做一个动作，就是修改原来的URL，把它改写成另一个URL’，这个URL’中的域名就是用户要去进行内容请求的服务设备的主机名。用户向这个服务器请求内容得到应答后，才是真正开始浏览网页内容的过程。

与智能DNS方式相似，GSLB在做HTTP重定向时，也就是在为用户选择最佳服务器时，也会综合考虑很多条件，比如服务器的负载情况、用户与各个服务器之间的链路质量、用户请求的内容所在位置等。区别在于，相比较于DNS方式，基于HTTP重定向方式的GSLB系统能够看到用户的IP地址，以及用户请求的具体内容，所以能够进行更精细的定位，这是HTTP重定向方式的最大优点。

当然HTTP重定向也有其不足：
1)这种方法只适用于HTTP应用，不适用于任何其他应用。比如微软的MMS协议、RTSP协议，就不能使用这种方式进行重定向。
2)其次，由于HTTP重定向过程需要额外解析域名URL’，还需要与URL’建立TCP连接并且发送HTTP请求，使得响应时间加长。
3)第三，不同于DNS方式，没有任何用户请求能被外部系统终结，所有请求都必须进入 GSLB系统，这将成为性能和可靠性的瓶颈。

2. 基于HTTP重定向的GSLB工作流程

1. 用户首先向网站的本地DNS请求域名(www.CDNbook.com)解析。

2. 由于网站已经预先进行了域名CNAME指向服务CDN的GSLB域名和IP，所以本地DNS会向用户返回GSLB设备的IP地址。（注意，是一个具体的IP地址，这样DNS解析过程就终结了。当然，如果GSLB系统本身是有负载均衡的，那么返回的这个IP地址就是经过GSLB系统自身负载均衡后的某台具体设备的IP地址。）

3. 用户向这台GSLB设备发起HTTP GET请求，请求该网站某个网页的内容。应该注意的是，在用户浏览一个完整的网页时，事实上是发起了多个HTTP请求，针对某个独立的对象，比如一张图片、一段视频、一段文字，都会存在这样一个独立的HTTP请求。

4. GSLB设备将综合分析用户IP、内容分布、设备负载、链路状况等实时信息，为用户选择一个合适的服务单元。之所以称为“单元”而不是“设备”，是因为很多实际的CDN系统的GSLB只鱼贵负载均衡的第一步，将用户访问请求调度到一个合适的服务区，或者一个集群，再由区域均衡或本地均衡设备做下一步负载均衡工作。GSLB设备向用户返回HTTP 302重定向应答，告知
   用户下一次请求应该发送的目的IP地址。如步骤(3)所述，这个IP地址可以是一台具体服务设备的IP地址，也可以是一个区域均衡设备的IP地址，或者一个集群的L4交换机的IP地址。

   如果GSLB在自己的静态路径表中没有查到用户IP所在网段的信息，可以通过两种方式完成路由策略。方式一，GSLB将用户请求通过轮询的方式定向到其他节点。方式二，GSLB会以同样方式去查动态最近路径表，如仍没有记录，GSLB会通知各POP点的SLB一同去测各POP点离用户的距离及时延，并报告核心节点确定最优站点，该IP地址所在的网段会被添加至动态最近路径
   表，供今后用户直接与最优的分配层节点的SLB设备建立连接。某些情况，也可采用轮询方式选择SLB设备。

5. 用户根据得到的IP地址向CDN节点发出媒体访问请求。

6. 如果这个IP地址的节点设备仍然是一个负载均衡设备，则通过负载均衡选择一台合适的服务设备，将其IP地址返回给用户。

7. 用户根据得到的IP地址向CDN服务设备发出媒体访问请求。

3. HTTP重定向方式的局限性体现在以下三个方面。

第一，GSLB性能压力大。GSLB作为所有用户请求进人CDN系统的第一跳，所有用户请求无一例外地都会到达这里，随着用户请求数量级的增加，GSLB的压力也随之增大。同时GSLB作为全网的核心部件很容易受到攻击，有较大的安全隐患。

第二，协议扩展性较差。这一条从实现原理上也能理解，GSLB是通过分析和改写服务器与客户端之间的应用协议交互信息实现重定向功能的，可能还要叠加一些权限判断、防盗链之类的定制功能。也就是说，应用屡负载均衡需要对应用有一定的了解。所以对于新增加的应用协议，需要进行开发升级。而对那些不支持重定向的应用，还需要在GSLB/SLB上开发新的重定向接口。

第三，安全性问题。在这种方式下，每次重定向都会通过与客户端之间的应用协议交互完成，所以在客户端可以通过协议分析了解到整个服务器架构，这会导致一定的安全隐患。