BlueCoat反向代理方案

BlueCoat反向代理方案
一、用户需求分析
用户目前的网站站点设计有HTTP Apache服务器，主要服务的内容是大量新闻和图片及一些Flash视频类的节目。

采用Apache服务器带来的主要挑战有三方面，一方面系统运行在通用操作系统上，网站安全性存在风险。

另一方面Apache服务器的性能受限，通常一台服务器只能处理3000-5000个并发HTTP客户连接。

性能上存在瓶颈。

最后还有在后台存储用户使用基于FC SAN的磁盘阵列。

当为了提升网站性能而增加前面的Apache 服务器时，后台存储的共享也成为了一个复杂的技术问题。

为了解决上述的一些实际问题。

用户需要在HTTP Web Server前端增加硬件反向代理服务器，利用其安全和高性能的特性来降低Apache服务器的负载和被黑客攻击的风险。

同时由于主要的负载都被反向代理服务器所承担，源服务器只需要保持一个基本的HA服务器就可以，也无需涉及复杂的FC SAN共享问题。

二、方案设计原则
考虑用户的实际情况，在方案设计时需要遵循如下原则：
1．标准性
现在构建的HTTP反向代理网络应当符合网络业界的主流标准，保证系统和已有的Web Server的兼容性。

2．合理的性能价格比
在满足当前的业务需求的同时，还考虑到今后业务发展的需求，确保在未来扩容时能
够扩展到更多的性能和容量支持。

同时尽量选择经济的设备，做到最优的性价比。

3．高可靠性
在确保系统可靠工作和数据的可靠性的原则基础上，尽可能的做到高起点，选用先进的技术和设备，使构建的反向代理系统有较高的可靠性，以适应今后的发展。

4．可管理性和可维护性
反向代理设备可以通过多种技术和方式实现了高可靠性，同时也增加了系统的复杂性，从而容易导致维护和管理的复杂性。

因此在方案设计中在提供高可靠性的同时，也要注重提供反向代理系统的可管理性和可维护性。

整个系统应该能够采用基于Web的界面对存储设备进行配置管理。

系统配置工作应该简单明了，流程清晰。

系统应该能够提供远程告警。

5. 高性能
整个反向代理系统应该提供较高的HTTP和HTTPS性能，能够满足大量用户同时使用时的性能要求。

三、技术方案建议
3.1 反向代理网络的总体设计
使用Bluecoat SG设备作为反向代理的方式对源服务器进行加速，利用Bluecoat设备的安全性和强大的性能来实现对源服务器的卸载和安全防护。

同时可以部署多台Bluecoat SG设备在前端，实现高速性能负载均衡和系统高可用性。

并且会降低后台源服务器的部署数量，解决存储共享的问题。

3.1.1 在同一数据中心部署反向代理节点
SG实际部署在源服务器的前端，缓存用户访问的内容，因此大部分的服务压力都会被SG所承担，而不需要源服务器具有高性能的处理能力。

同时由于SG和源服务器之间是通
过内部私网地址的连接，这样保证了内部的源服务器是绝对安全的，因为没有黑客能够从公网上访问到源服务器。

后台的源服务器还可以使用多台Web Server来实现冗余和可靠性。

在Bluecoat的方案中，后台的源服务器组并不需要使用四/七层交换机来实施负载均衡，因为SG设备本身可以具有负载均衡能力。

在从SG向源服务器请求未命中的内容时会根据几种不同的算法进行负责均衡，包括：Round-robin, 最少连接，用户源地址关联，根据用户被加速设备设置的Cookie关联等。

Bluecoat SG设备还可以对后台的源服务器实施健康检查，检查的方法包括四层协议和HTTP协议等。

如果发现某一台源服务器出现故障，SG则会自动将流量切换到别的服务器上。

Bluecoat SG也提供了性能上的显著提升，通常的Web Server具有二方面的性能瓶颈：HTTP并发连接数，HTTP吞吐量。

尽管可以给这些服务器配置较大的内存和更新的CPU，但是其性能依然无法令人满意。

而作为对比，Bluecoat的设备SG810-C可以支持12000个客户端的并发HTTP连接，并且在典型环境下支持150Mbps到200Mbps的反向HTTP 代理吞吐量。

因此同样的性能要求条件下，会使用数量很少的SG设备就可以满足用户的性能要求，并由此节省了大量的机房空间，电源消耗和空调消耗等相关资源。

从维护成本的角度上来考虑，是更为节省的一个方案。

在反向代理的方案中，对于静态网页的性能提升效果是非常明显的。

因为大部分的静态网页会缓存在本地。

而对于动态网页而言，由于不能缓存在代理服务器内部，所以必须代理回源服务器，此时对源服务器的服务并没有性能卸载的能力。

对于这种动态网页的加速，可以参考后续章节的方案，Bluecoat提供了一种独到的ADN 加速方案来对动态网页进行加速。

这一方案的范围已经超出了反向代理的概念，而是和CDN的方案融合在一起。

3.1.2 异地部署反向代理节点
整个反向代理网络组件包括：GSLB和SLB设备，HTTP缓存设备，Web源服务器等。

这种部署实际上已经成为了CDN的部署。

在新建反向代理节点中部署4台SG缓存设备，其中2台主要用于加速流媒体业务，1台主要用于加速静态网页和Flash视频的业务，1台主要用于加速动态网页的业务。

考虑到业务安全的需要，2台加速HTTP网页的SG缓存设备可以通过SLB设备进行负载均衡。

2台加速流媒体业务的SG缓存设备通过SLB设备进行负载均衡。

这里假定缓存设备中已经存有用户需要访问的内容（用户访问命中的情况），其中第1步是DNS解析，用户解析过一次后就可以把DNS记录缓存在本机上，下次可以不用再去GSLB设备进行解析。

如果用户访问的内容未命中，则会由Cache去源服务器抓取。

对于较简单的单个节点异地反向代理方案，可以不使用GSLB设备，只使用DNS解析到反向代理服务器即可。

3.2 ADN + CDN业务（动态和静态网页同时加速业务）
3.2.1 设计概述
考虑到冗余的设计要求。

在中心节点放置二台SG加速设备，这二台加速设备并不需要一定连接在SLB设备之后来实施负载均衡。

因为Bluecoat的ADN加速方案里提供了不需要SLB的中心点负载均衡。

因此只需要给这二台设备各一个公网IP地址就可以。

二台中心点的设备会设置ADN路由表，自动把源服务器的网段地址广播给所有的边缘的SG设备。

在边缘节点，如果有多台SG设备的话，则可以放置在SLB负载均衡设备后面，使用私网地址，然后在SLB上映射为公网的VIP。

此时SLB负载均衡设备的算法建议使用基于用户源地址Hash的，来保证每个用户的连接都达到同一台SG设备中进行处理。

这样加速效果更好。

边缘节点的SG设备和中心节点的SG设备之间会形成Peer关系，并建立ADN隧道进行加速。

二者的字节缓存是完全同步的。

边缘节点的SG会根据目的地网段的ADN路
由进行数据包转发选择。

如果发现去往目的地的网段有多台SG Peer都可以通达，则会根据自己的设备ID采用Hash的方式自动选择一个Peer作为下一跳。

由于边缘节点有众多SG设备，因此最终会使得流量较为平均的转到中心节点的2台SG设备上。

如果中心节点有一台SG设备故障，则边缘节点的SG设备会自动切换到另外一台中心节点SG上。

Director分发设备需要一个独立的公网IP地址来管理所有的SG设备。

为了管理的目的，每个边缘节点的SG也需要配置一个单独的公网IP地址用于管理。

Director使用SSH 协议管理SG设备。

Director设备也可以被配置为冗余的来保证可靠性。

3.2.2 动态网页加速流程
这些流程可以分步骤解释如下：
1）用户请求内容/dynamic.css，用户的DNS解析请求会达到GSLB设备。

2）GSLB设备作出就近性判断把用户的请求重定向到离用户最近的ADN 节点(边缘节点)的SLB设备上
3）边缘节点SLB把用户请求/dynamic.css 发送给边缘SG。

4）SG设备根据自己的加速策略判断需要进行ADN加速，把用户的请求通过ADN隧道发给对端的SG设备（中心节点）。

这一请求过程本身也会被加速，因为通常一个HTTP Request 数据包在几百个字节，如果加速后，则可能只传送12个字节，因此大大缩短了在广域网上的传送延时。

5）SG中心节点收到数据包后，向动态网页的源服务器发起请求
6）动态网页的源服务器响应给SG中心节点真正的用户数据，如数据库表单查询或网上购物明细等页面。

7）SG中心节点收到响应后和自己的字节缓存数据库进行比对，将差量数据传送到对端的
边缘节点SG，这一传送过程的速度会较未加速前大大加快。

8）SG边缘节点收到响应后，根据自己的字节缓存，把源服务器的响应还原并发送给用户。

上述流程就是一个完整的用户请求动态网页加速的流程。

如果用户请求的一个域名下的内容是既有动态网页，又有静态网页。

则SG加速的流程如下：
1）SG判断是否是可缓存的页面，如果是，则检查
a) 是否已经在本地的HTTP对象缓存中且未过期，如果是则直接给用户服务
b) 如果已经在本地的HTTP对象缓存中但对象已经过期，则向源服务器发送IMS请求要求最新的对象。

这一请求过程同样会经过ADN加速。

c) 如果不在本地的HTTP对象缓存中，则向源服务器发送内容请求。

这一请求过程同样会经过ADN加速。

2）SG判断此网页为不可缓存，则会直接把请求发给源服务器并且这一请求过程会经过ADN 加速。

3.2.3 设备选型
这里给出了不同设备型号之间的硬件参数对比：
SG8100-G SG810F SG810E SG510B
磁盘 6X300G 15K 4x300G SCSI 4x144GB SCSI 1x300GB SATA
内存 4GB 4GB 4GB 1GB
网络接口 2个GE标配，可扩展到6个GE 2个GE标配，可扩展到6个GE 2个GE 标配，可扩展到6个GE 2个GE标配，可扩展到6个GE
3.2.4 HTTPS加密动态网页加速业务
在实际的网站类型的客户中，很多网站是使用HTTPS进行加密的业务处理。

而且这些HTTPS的页面往往是个性化的动态的页面。

这就要求CDN/ADN 业务能够提供针对HTTPS
的动态网页加速能力。

而传统的ADN加速方案是无法直接加速HTTPS的业务的。

这一问题的原因在于ADN的字典压缩算法对于加密的数据流是没有显著效果的。

Bluecoat的ADN/CDN解决方案提供了一个完整的解决方案可以对HTTPS类型的动态网页进行加速。

从而扩展CDN/ADN 加速的适应范围。

它的工作原理是利用SSL Proxy来截取HTTPS的流量并对未加密的页面进行字典压缩，然后再把压缩后的流量进行SSL加密传送到ADN 对端设备。

这里也分为二种情况：
1）源服务器使用了HTTPS加密，用户也使用HTTPS协议请求内容。

2）用户使用HTTPS协议请求内容，但是源服务器只使用普通的未加密HTTP。

从SG边缘节点到源服务器之间使用加密的数据传送。

边缘节点的SG会直接向HTTPS源服务器发送请求，并得到源服务器颁发的证书。

边缘节点的SG和中心节点的SG之间会形成一个联合工作的SSL Proxy。

Bluecoat称之为SSL Split Proxy。

边缘节点的SG会把证书传递给中心节点，由中心节点作为客户端和HTTPS源服务器进行直接通讯，并形成一个完整的HTTPS连接。

中心节点的SG在得到SSL内容后可以解密，从而得到了解密后的HTTP内容，能够直接对这些不加密的内容实施高效的字典压缩。

而在边缘节点和中心节点之间，二者使用自己预装的有效证书进行认证和传输加密。

这保证了数据传输的安全性。

在边缘节点的SG会自动根据源服务器颁发证书的信息仿真一个新的证书颁发给客户端。

对于用户来说，这样的技术方案带来的优势是，由于在用户CDN托管的互联网公司会有非常多的源服务器，每个源服务器颁发的证书都是不同的。

而采用了证书仿真和
SSL Split Proxy技术后，整个CDN/ADN 网络的管理会变得异常简单。

Bluecoat SG设备会自动为每个源服务器创建一个新的用于用户端的证书。

这种技术可以大大节省用户的维护成本。

在这个部署方式下，边缘节点的SG预装了已经签过的数字证书。

当用户访问HTTPS内容时，边缘节点的SG会把预装的数字证书发给用户。

然后边缘节点SG可以把用户的解密内容进行字典压缩，并通过加密ADN隧道传送给对端的中心节点设备。

中心节点设备会以HTTP的方式和源服务器进行通信。

这种方式源服务器不需要支持HTTPS，可以节省大量源服务器的计算资源。

这种方式实际上是对源服务器的HTTPS卸载。

上面的二种部署方案可以共存在边缘节点SG中，SG设备可以根据用户的访问条件，如域名，URL路径，HTTP Header等多种信息来定义，定义部分用户请求需要是全程使用HTTPS加密，部分是需要做HTTPS卸载的。

3.2.5 Reflect Client IP(用户IP地址传送)
如果有网站客户需要统计用户的源IP地址，或者有特别的认证需求是基于源IP地址的。

此时需要把用户的源地址发送给源服务器。

Bluecoat中心节点的SG设备此时需要打开Reflect Client IP选项，并使用用户真正的源地址连接到源服务器来请求内容。

但这里需要注意的是，需要增加四层交换机或设置路由器上的WCCP流量把源服务器送回的流量重定向到中心节点的SG上。

否则会无法建立完整的TCP连接。

3.2.6 保留用户原有域名
在实际的CDN运营中，会有客户提出这样的需求，他们的原有网站已经申请了域名，不想放弃，同时又想通过CDN的方案部署新的服务，并使用全新的域名。

此时Bluecoat 可以提供一个非常好的方案自动的帮助用户实施全新域名的CDN，同时用户原有网站的域名和内容都不需要更改。

这里举例如下：
用户原有的域名和网站URL为：, 希望通过用户的CDN部署为https://, 实际客户访问到https:// 时是访问用户的CDN，然后再作反向代理，其源服务器是 。

这样用户给
其用户的网站提供了SSL卸载服务和CDN服务。

而用户原有的
可以继续保留，用于测试或继续服务的目的。

这里面需要注意的一个技术问题是在原有的网站中其页面内容中还会嵌入大量的连接，都是基于域名的链接。

如果对这样的网页实施CDN加速，用户点击其中CDN加速页面的链接时会直接访问，这样会绕过CDN网络而直接访问源服务器。

为了避免这个问题，通常是需要源网站改写其中的页面，这样的工作量是相当大的。

Bluecoat SG缓存设备提供了一个功能叫做
two way URL rewriting，可以解决这个问题，它可以自动改写网页内部嵌入的链接，如果源网站中页面嵌入的链接为/path/page.htm, 则BluecoatSG 设备在接受到源服务器响应后，把页面中的这个链接自动的改写为：
https:///path/page.htm 这一功能可以避免用户在源网站侧保留域名的同时还需要对自己的网站内容进行大量改写。

是一个提高用户满意度的非常好的功能。

这里面需要注意的是Bluecoat SG 的two way URL rewriting功能目前不能对网页中的ActiveX 控件中的链接进行改写。

如果用户的网站大量使用了AcitveX控件则此功能目前还无法实施。

3.3 BLUECOAT HTTP 业务特点
HTTP缓存是整个反向代理的基础业务。

Bluecoat ProxySG提供了非常丰富的HTTP业务服务功能，包括：
非常灵活的HTTP策略设置
支持认证，授权，SSO
灵活的对象刷新机制
支持HTTP压缩
支持多线程下载
HTTPS加速和缓存
带宽管理
内容安全的保证–对用户上传内容进行病毒扫描
这里需要指出的是，HTTP压缩功能也是免费提供的。

下面就其中的一些具体业务进行详细描述：
3.3.1 HTTPS源服务器卸载
使用Bluecoat SG设备作为反向代理的方式对源服务器进行加速，可利用Bluecoat设备的安全性和强大的性能来实现对源服务器的卸载和安全防护。

如果直接在源服务器上部署HTTPS的业务，则会给源服务器带来很大的压力和资源开销。

如果一个基于软件的HTTP 服务器上实施HTTPS服务，其性能通常只有4-5Mbps的SSL吞吐量，并且能够处理的每秒请求数量也是非常有限的。

而如果在HTTP源服务器前端部署Bluecoat SG设备，则可以利用Bluecoat的设备内置的SSL硬件加速卡实现对HTTP源服务器的SSL加速功能，从而使得源服务器专注于HTTP服务，而将SSL加密的任务交给SG设备来处理。

在Bluecoat SG设备上，可以通过二种方式装入数字证书用于颁发给用户的访问。

一种是在Bluecoat设备上自己签发的证书，这种证书不需要去互联网上的证书发放机构进行签署，但是用户的浏览器可能没有直接设置为信任Bluecoat签发的证书并弹出一个提升窗口让用户确认是否信任这个证书。

另一种方式是装入经过互联网上证书发放机构发放的标准数字证书，如VeriSign，Baltimore等公司签发的数字证书，这些证书通常是被用户客户端所信任的。

3.3.2 HTTP 压缩
Bluecoat SG设备支持标准的HTTP1.1压缩，可以支持的HTTP压缩算法是GZIP和deflate。

对于Bluecoat SG来说，如果源服务器没有使用HTTP压缩，而Client端请求压缩对象，则可以把未压缩的HTTP对象压缩后缓存在本地，对于后续的HTTP访问则直接提供压缩后的对象进行服务，不需要再去源服务器拿去内容和重新压缩。

Bluecoat HTTP压缩功能是可以根据策略设定来启用的，例如，可以根据用户访问URL 的不同来确定是否启用HTTP压缩。

另外如果用户请求的是非压缩的对象，则Bluecoat会缺省给用户非压缩的对象。

对于一些不能压缩的对象，如GIF图像文件和JPG图像文件，此时尽管HTTP策略设定压缩这些对象，但是Bluecoat设备也会自动忽略这些请求而给用户服务非压缩的对象。

3.3.3 多线程下载
Bluecoat SG设备支持标准的HTTP Byte-Range字头，可以被多线程下载程序如Flashget用于多线程下载。

因此利用Bluecoat设备可以支持常见的多线程下载程序。

但是目前Bluecoat设备还不能限制单个用户同时使用的多线程下载的线程个数。

3.3.4 典型HTTP策略设置
Bluecoat的HTTP策略引擎提供了非常丰富的HTTP策略控制功能，常见的应用案例包括：
1）去除用户请求的No-cache header来保证源服务器的安全。

2）根据用户的User agent header来判断用户的浏览器版本和类型来判断用户是否能够得到理想的页面效果
3）进行HTTP重定向来实现用户访问转向
4）强制缓存指定的内容
5）对HTTP源服务器的错误代码响应提供定制的出错提示页面
6）拒绝某些指定用户对内容的访问
3.4 BLUECOAT网络安全设计
3.4.1 Bluecoat 抗DDOS攻击和Port Scanning
Blue Coat提供了完整的抗DDOS攻击能力，包括如下的技术特性：
SG 可以限制单个客户地址的HTTP/TCP连接数量，并且对超过了连接数量限制的客户连接请求进行拒绝和复位。

对于被限制访问的客户，可以设定限制访问的时间间隔，时间到期后恢复这些客户的访问权限。

这一防护能力是针对TCP以上的协议。

对于常见的底层DDOS攻击如ICMP Flood, TCP SYN Flood，SG可以进行安全防护并且不会因此而消耗系统资源。

对于ICMP Flood，Bluecoat的设备可以实施限速，保证不会因为大量的Ping响应而导致系统资源过载。

对于TCP Syn Flood，可以对不完整的TCP连接不分配资源，从而不会导致系统资源过载。

对于端口扫描的攻击，缺省Bluecoat设备不会打开任何端口。

只有提供HTTP服务的80端口和SSH及HTTPS管理端口。

对于这些提供服务的端口还可以实施访问控制，只有信任的客户才可以访问这些端口。

3.4.2 SGOS 操作系统
Blue Coat专用设备的操作系统SGOS是一个专门为高速对象缓存应用而开发的操作系统，它通过了国际著名的安全认证：ICSA Labs安全认证。

表示这个操作系统是一个非常安全和没有后门的操作系统。

黑客不会知道真正的源服务器地址，也无法通过Bluecoat的反向代理设备而去篡改源网站的内容和攻击源服务器。

而作为对比，一个运行在通用操作系统上的Web Server程序，它的安全性是受限于操作系统的安全性的。

在 网站上，可以搜索到成千上万的关于Windows, Linux, UNIX操作系统的安全漏洞。

运行在这样的操作系统之上的网站是非常不
安全的。

如果把这个Web服务器直接暴露在Internet上实际是一个很危险的部署方式。

在对象存储方面，Bluecoat使用的是按照对象URL产生高速索引的存储机制，在硬盘上没有文件系统。

即使黑客获取了Bluecoat代理服务器的硬盘，由于其不了解Bluecoat 的专有存储格式，也无法读出其中存储的数据内容，更不用说篡改其中的内容。

美国军方的很多网站都采用Bluecoat的设备作为反向代理作为安全设备部署在网站的前面，避免其网站遭到黑客的攻击和篡改。

3.4.3 Bluecoat 协议检测
Blue Coat SG可以检测到80或443端口访问的流量是否为真正的HTTP或HTTPS流量。

只有真正的HTTP或HTTPS流量才会被SG进行处理，转发回源服务器或在本地命中。

这种技术可以防止黑客利用80和443端口对反向代理设备或源服务器进行攻击。

对于标准HTTPS协议来说，客户机会使用HTTP Connect method来连接服务器，通过对这些方法的检测，Bluecoat SG设备可以清楚地感知是否是真正的HTTPS客户端在使用443端口还是伪装的HTTPS流量。

3.4.4 防止反向代理服务器成为Open Proxy
Blue Coat反向代理设备可以被同时用作正向代理设备，因此当SG被部署在公网上的时候，需要增加相应的安全策略保证SG设备不会被作为一个公用的代理服务器来被其他非法用户用于访问Internet上的内容。

典型的配置包括：
1）在反向代理服务器上不要配置DNS服务器。

这样非法设定SG为代理服务器的客户将无法访问Internet上的内容。

2）在反向代理服务器上配置ACL控制策略。

检查用户请求的HTTP Host Header是否匹配正在加速的域名，匹配的进行处理，不匹配的则拒绝其访问。

通过上述的二个反向代理上的配置可以保证没有用户或黑客使用代理服务器访问
Internet上的内容。

3.4.5 管理员访问限制和安全
为了防止在公网上的黑客扫描SG的管理端口和进行破坏，在SG设备上可以设置管理员访问控制列表，限制只能有特定的工作站才能访问Bluecoat SG的管理端口。

同时为了保证设备管理的安全，Bluecoat SG设备使用的是HTTPS和SSH协议进行管理。

并且可以定义使用一个专用的HTTPS端口而非标准的443端口。

3.5 用户行为分析和统计及错误定位用户的追踪
Bluecoat ProxySG 提供了多种方式的系统访问日志信息，包括：
HTTP Access Log, Streaming Access Log等。

Bluecoat ProxySG的系统访问日志可以被集中的送往Syslog / ftp服务器进行存储，也可以以实时的方式输出到一个独立的Log 服务器上进行实时监控。

为了确保log日志的安全性，ProxySG还可以把日志信息进行数字签名，确保ProxySG的日志不会被黑客攻击。

典型的ProxySG HTTP Access Log格式为W3C，Squid等标准格式。

同时Bluecoat提供了Reporter工具软件来分析所有Bluecoat设备的用户访问日志。

Reporter工具可以位于一个数据中心，集中地分析反向代理网络中所有的log信息，也可以在每个省网部署一个Reporter工具。

对于用户来说，由于实际运营商网络条件的限制，如果由于错误配置或设备故障引起的电信用户跨网访问用户地址内容的情况出现，则会给用户的访问效果来很大的影响，甚至影响后续业务的发展。

为了避免这个情况的出现，需要反向代理的管理员能够具有追踪和定位能力，把错误定位用户的IP地址迅速定位。

避免这种跨运营商访问的情况出现。

ProxySG 提供了基于策略的log能力。

可以产生一个独立的Log文件，把符合条件的错误定位的用户记录在这个log中，供反向代理系统管理员来进行追踪和分析。

例如：假定电信。