F5web加速技术方案.docx
《F5web加速技术方案.docx》由会员分享，可在线阅读，更多相关《F5web加速技术方案.docx（17页珍藏版）》请在冰豆网上搜索。
F5web加速技术方案
F5 ＷＥＢ加速技术方案
2011年2月
1.前言
一直以来，通过低速链路连接的远程站点都使用专用服务器硬件以便实现最佳性能。
但由于成本压力、技能欠缺以及需要更好地处理安全问题等原因。
将服务器功能整合到主数据中心，是实现服务器整合的主要方法。
应用网络化也带来了类似的问题，但稍有区别。
许多常用的应用平台都从客户端-服务器模式向基于web的模式迁移。
这样一来，便可通过HTTP提供应用，而不必在每个终端用户的PC上安装客户端。
Web浏览器成为通用客户端。
虽然这种方法避免了在每个PC上安装客户端，确实会减轻应用的管理负担（某些情况下，在客户端-服务器互动设计不理想且涉及到多次数据库来回操作的广域网上，这种方法还可帮助提高应用性能），但通常会增加网络压力（由于需要传递数据的格式化信息，因此增加了网络流量）。
在最糟糕的情况下，可将用户响应时间延长10倍。
广域网加速设备采用了多种技术。
这些技术可以大致分为四类，每一类技术都可解决广域网中的某个特定问题。
•带宽：
带宽通常是稀缺资源，因此必须要节约使用。
带宽瓶颈可通过压缩技术得以解决。
压缩技术通常分两类，第一类是基于字典流的传统压缩技术。
在此类技术中，每一端的设备都构建通用模式字典，然后以短标识符替代它们。
因此，从理论上说，带宽可节省近90%，但未经压缩且未经加密的数据通常占到50%左右。
第二类压缩技术认为，在一般的网络中，大部分的数据（如文件）通常是来回传输的，修改幅度很小。
因此，在任一端使用硬盘来保存这些数据，只传输发生变化的信息（或变量），最多可将网络备份等带宽密集型任务和其他文件密集型任务的带宽减少99%。
•时延：
时延是广域网固有的问题。
在低速链路上，即使传播延迟很短，仍存在较长的串行化延迟。
延时问题可通过加速技术得以解决，其中最基本的是TCP加速。
这项技术认为，延时造成的响应时间减慢多半是TCP协议等待确认的结果。
最简便的解决方法是让拦截设备“监听”TCPACK消息，并管理广域网上的信息传输。
这样，最终主机便认为远程端与它并排位于局域网上，从而能够以更快的速度与加速平台互动。
此外，在“闲谈式”协议（如CIFS、MicrosoftExchangeMAPI等）所在的应用级别，应用加速也可以“欺骗”应用响应速度和TCPACK。
另一种加速技术是Web加速，它使用嵌入在广域网加速设备中的web代理来进一步加快请求速度。
Web加速尤其适用于来自支持web的核心应用、不断重复的序列。
根据经验，设备中所提供的加速技术越多，效果越好。
•网络资源争用：
网络资源争用也是低速广域网中的常见问题。
不同的应用对延时和响应时间有着不同要求，而某些应用在教育环境中更受欢迎。
优良的广域网加速设备可通过服务质量（QoS）技术为延迟敏感型应用和重要应用分配高于其他服务的优先级。
更优秀的加速产品还能使用基于策略的多路径技术，来优化那些存在着多条路径且每条路径都有不同特征的网络。
•可视性：
网络管理员需要了解服务在网络上的运行方式。
与没有提供全面的网络管理工具的解决方案相比，具有强大的流量分析和报告功能的设备能够提供更高价值。
下面针对F5广域网加速技术和WEB加速技术进行分析。
2.加速WEB应用，大幅提高用户体验效果
HTTPSOffload
在SSL处理过程中，所有的传输内容均采用加密算法处理。
其中最重要的两个部分为SSL握手时交换秘钥的非对称加密和数据传输时的对称加密。
在现有的系统中，通常非对成加密采用1024位的密钥进行加解密，因此对服务器的CPU占用率非常高。
在一台最新型号的双Xeon服务器上，大约每秒钟400次非对称加解密就能导致CPU占用率100%。
同时对称加密通常采用128位，最高256位加密的加解密也会导致服务器CPU占用率居高不下，同样的服务器SSL流量大约能达到150Mbps。
因此当我们在部署SSL应用时，必须考虑到以下参数：
TPS：
TransectionPerSecond，也就是每秒钟完成的非对称加解密次数
Bulk：
SSL对称加解密的吞吐能力，通常以Mbps来进行衡量。
当SSL的客户端压力超过400TPS时，单台服务器就很难处理请求了。
因此，必须采用SSL加速设备来进行处理。
BIGIP-LTM/WA系列可从最低2000TPS到480,00TPS实现全硬件处理SSL非对称加密和对称加密流量。
其实现的结构如下：
所有的SSL流量均在BIGIP-LTM/WA上终结，BIGIP-LTM/WA与服务器之间可采用HTTP或者弱加密的SSL进行通讯。
这样，就极大的减小了服务器端对HTTPS处理的压力，可将服务器的处理能力释放出来，更加专注的处理业务逻辑。
在BIGIP-LTM/WA可处理单向SSL连接，双向SSL连接。
并且可同时处理多种类型和多个应用的SSL加解密处理。
OneConnect降低服务器TCP连接数量
用户因连接和断开网络连接而产生的周期性网络请求会耗费掉企业宝贵的web应用资源。
即使每个连接开销很小，但合到一起，它们将影响到总的应用负载，对于电子商务站点和拥有大量用户的企业应用来说，这一点尤为明显。
在ApacheServer的标准配置中，一台服务器的最高并发连接数为1024个，而MicroSoftIIS可配置为2048个。
可见连接数对于服务器是一个极大的限制,在应用服务器上比如Weblogic，WebSphere上，连接数的增加将会给系统增加大量的开销。
连接优化将处理连接的责任移交给了F5BIGIP-LTM/WA。
网络流量在BIGIP-LTM/WA和源应用之间的小型资源池和永久连接中进行多路传输。
BIGIP-LTM/WA将成千上万个用户的连接汇聚成为少数的服务器连接，最终可显著降低源应用的负载。
与其它的连接优化技术不同，F5采用了动态连接池的方式，当每一个用户请求发送到BIGIP-LTM/WA时，根据负载均衡策略，BIGIP-LTM/WA将在请求将被发送到的服务器端寻找空闲的连接，如果有空闲连接，则直接将请求通过该连接发送到服务器，如果没有空闲连接，则新建一个连接与服务器端通讯。
这样，既保证了在服务器端始终维持最小的连接数，又避免了由于没有空闲连接而导致的客户端请求排队的现象。
HTTP页面压缩降低带宽占用和提高客户端响应速度
应用和网络延迟问题进一步降低了web内容的传输速度。
BIGIP-LTM/WebAccelerator专利技术－Express压缩技术能够消除因压缩算法所带来的延迟，为拨号和宽带用户带来额外的性能提升。
事实上，借助Express压缩，拨号用户的访问速率将比原来快5到10倍，同时带宽利用率和成本将降低70%-80%。
WebServer
Client1
Client2
BIG-IP/WA
CompressionontheBIG-IP/WA
响应时间的加快，带来了用户满意度和员工效率的提升，从而使基于web的应用得到更加广泛的应用。
单在更低带宽成本方面所节约的费用（尤其在远程销售办公机构或人员方面所节省的费用），就足以补偿在设备购置方面的投资，甚至是后者的好几倍。
使用工业标准的GZIP和Deflate压缩算法来压缩HTTP流量；降低带宽消耗、缩短最终用户在慢速/低带宽连接条件下的下载时间。
一个典型的HTTP压缩处理的流程如下：
BIGIP-LTM/WA接收到浏览器的HTTP请求后，根据浏览器的accept-encoding字段头检查浏览器是否支持HTTP压缩；
如果浏览器支持HTTP压缩，WA则检查请求Match的Policy，如果Policy选择了内容压缩，并且可Cache，则开始的内容是否在自身Cache内有存放；
如果在WA本地（包括内存和硬盘）上已经有请求内容存在，则直接将请求内容；
如果可Cache但在WA本地无法找到相应内容，WA则将请求转发到服务器，在服务器返回内容后，将页面进行压缩后，缓存在本地，再将请求返回给发起请求的客户端。
在开启HTTP压缩功能后，对于HTML页面，CSS等文本类型的数据，通常可以取得80%左右的压缩率，而对于一些已经压缩过的文件类型，如jpg，gif，pdf等文件，压缩则可能获得完全相反的结果。
在BIGIP-LTM/WA的配置中，可以灵活的定义那些内容需要压缩，那些类型不进行压缩，甚至可以定义到特定的URI来进行压缩处理。
广域网访问的网络延时与带宽瓶颈经常给用户的WEB应用的正常访问带来不便，通过在F5BIGIP-LTM/WA上启用HTTP压缩功能，可以带来以下好处：
●更快的页面下载速度：
在采用压缩技术后，同样的页面传递到客户端的时间和包数量大大减小，从而提高了客户端的页面下载速度。
●更小的带宽消耗：
支持广泛数据类型的压缩：
例如HTTP,XML,Javascript,J2EEapplicationsandmanyothers，启用带宽压缩所带来的带宽节省可以达到80%。
●客户端自适应的压缩处理能力（技术专利）：
F5BIG-IP-LTM可以通过探测到客户端的RoundTripTime来识别用户是通过宽带还是窄带方式上网，然后决定是否要对该用户启用HTTP压缩功能。
●对用户完全透明，不需要在客户端安装程序：
F5BIG-IP-LTM/WA应用交换机采用的压缩算法是目前常用WEB浏览器广泛支持的GZIP和Deflate算法，因此对用户完全透明，不需要预先安装客户端解压程序。
RAMCache减小服务器端压力
在BIGIP-LTM上，可以通过配置内存Cache来提高系统响应速度，并减小服务器端的压力。
通过内存Cache机制，BIGIP-LTM/WA可以把频繁访问的内容存放在内存中，当下一次请求到达时，直接从内存返回用户请求的页面。
从而降低了服务器的请求压力。
使用RAM高速缓存的时机
使用RAM高速缓存特性可以降低后台服务器的流量负载。
如果站点上的某个对象会频繁用到，站点有大量的静态内容，或者站点上的对象经过压缩，那么此功能非常有用。
∙频繁用到的对象
如果在一些时期内，频繁用到站点上的某些特定内容，那么便可使用此特性。
通过对RAM高速缓存的配置，内容服务器仅需在每个有效期内向BIG-IP系统提供一次相关内容。
∙静态内容
如果站点由大量静态内容组成，例如CSS、javascript、图像或徽标，此特性也很有用。
∙内容压缩
对于可压缩数据，RAM高速缓存能够针对可接受压缩数据的客户端存储数据。
在BIG-IP系统上与压缩特性一起使用时，RAM高速缓存可以减轻BIG-IP系统和内容服务器的压力。
可以缓存的项目
RAM高速缓存特性完全兼容RFC2616“超文本传输协议——HTTP/1.1”中规定的高速缓存规则。
这意味着，可以将RAM高速缓存配置为缓存以下内容类型：
∙200、203、206、300、301和410响应；
∙缺省响应GET方法；
∙用于URI“包含”列表中指定的URI的其它HTTP方法，或iRule中指定的其它HTTP方法；
∙基于User-Agent和Accept-Encoding值的内容。
RAM高速缓存为Vary标头存有不同的内容。
RAM高速缓存不缓存的项目包括：
∙高速缓存控制标头指定的私有数据；
∙默认情况下，RAM高速缓存不缓存HEAD、PUT、DELETE、TRACE和CONNECT方法。
了解RAM高速缓存机制
缺省的RAM高速缓存配置仅缓存HTTPGET方法。
通过在URI“包含”列表中指定URI，或者编写iRule，可以使用RAM高速缓存来同时缓存GET方法和其它方法，包括非HTTP方法。
表1.1描述了高速缓存用来存储缓存内容的机制。
操作
缓存的内容
删除
删除所有cookie标头。
修改
提供时，逐个中继地修改标头。
这些标头包括：
Connection、Keep-Alive和TransferEncoding。
添加
添加Date标头，其中包含BIG-IP系统上的当前时间。
添加Age标头，它反映了项目在缓存中存在的总时长。
请注意，此设置在配置文件中缺省为开。
通过在配置文件中，将InsertAgeHeader属性变为off可以禁用此设置。
表1.1高速缓存的存储机制
清空高速缓存中的项目
RAM高速缓存可以删除高速缓存中使用最不频繁的项目。
这将防止选择新项目进行缓存时，较早的项目仍然占用着高速缓存的空间。
高速缓存还使用计分系统，在一段时间之后删除较早的项目。
缓存的项目达到其生存时间期限时，便认为它在高速缓存中已过期。
使用HTTP配置文件属性可以控制每个高速缓存实例的大小，以及项目在高速缓存中过期的速度。
应用智能缓存优化动态内容
应用智能缓存（ApplicationSmartCache）完全改变了传统的静态高速缓存模式，能够高速缓存种类更广泛的内容，包括高级动态web页面和XML对象。
该项专利技术为F5公司独有专利技术。
ASC关注应用逻辑与行为，而不仅仅是单个web对象。
通过描述某项应用的高级逻辑（可高速缓存与不可高速缓存的内容、可导致失败的事件等），WebAccelerator可消除对复杂web请求的重复处理。
借助应用智能高速缓存技术，WebAccelerator系统可决定何时使对象无效及如何识别可复用的内容块。
直观的用户界面、功能强大、基于XML的API以及基于HTTP请求的触发装置相结合，为用户提供了功能齐全的控件，从而可使内容生效或无效。
现有的高速缓存解决方案未采用WebAccelerator和ASC，仅将对象的失效日期作为参考指南。
ASC支持高速缓存查看HTTP请求中的全部内容（无论是URL、cookie、查询参数还是其它标头）并生成“智能”无效信息与高速缓存密钥。
通过采用以下两种密钥性能，WebAccelerator解决了长期以来无法解决的对动态内容进行高速缓存的问题：
●由应用和用户事件触发的一种高速缓存无效机制。
●可将符合条件的用户请求与高速缓存的内容连接起来的一种完善的匹配算法。
下图是对一个动态站点的真实情况分析结果：
对于使用率较高的应用而言，典型的静态高速缓存仅可响应20%的HTTP请求。
这是因为多数应用都十分复杂，需要与其它应用和数据库进行大量的交互操作，因此，静态解决方案并不能满足对象高速缓存的要求。
借助ASC，WebAccelerator可直接响应高达80%的用户请求（此类请求占用大量计算资源），且无需利用站点的其它基础设施。
WA的ASC在具体实现中，针对同样请求的URI，比如都请求?
recordId=12913，传统的静态Cache会认为这是一个动态页面，不进行Cache，但在WA工作状态下，可根据变量存在的位置来进行区分，这些变量名称的变化的时候，WA就认为是不同的页面，所以在Cache时存放的也是不同的页面。
当客户端访问时，WA则只有在所有的变量都相同的情况下，从本地缓存返回给用户。
这样，就不需要到服务器再进行查询了。
前提是可以接受一定的刷新时间，比如10分钟。
默认值为根据域名、路径和查询的参数来对Cache内容进行区分不同的页面内容。
其他的如Cookie，用户Agent，客户端IP等则认为是同样的请求。
而这些都是可以根据实际的应用站点进行精确调整的。
比如请求：
?
recordId=12913和http:
//?
recordId=12914，由于请求的queryparameter（recordId）不同。
则在WA内Cache是两个页面，而不管用户过来的Cookie和浏览器类型是什么，只要是相同的queryparameter,在有效期内都用缓存的页面进行回应。
IBR浏览器智能控制
多数上传请求仅仅检查嵌入对象和大图片的有效性及其更新情况。
这就造成不必要的延迟进而引起应用性能下降。
WebAccelerator的ExpressLoader技术消除了大量上传内容更新请求、极大减少了页面加载的时间以及网络的流量。
当内容变动时，WebAccelerator引导浏览器至新的版本，同时正确的内容总能得以维护。
如果内容并未变动，它会立即引导浏览器从本地高速缓存加载先前的版本。
当我们对于一个动态站点（通常是基于中间件的业务系统，如BeaWeblogic,IBMWebSphere,OracleIAS等）进行分析时，在往返的几次访问中，能看见大量的重复内容在不停的传送，至少，能看见HTTP304请求到服务器询问该内容是否改变。
这样，引起了大量的不必要请求，加重了服务器的负担，同时增加了网络的消耗，引起客户端页面打开速度的变慢。
以一个典型的银行网银系统为例，在用户登录后，所有的内容都变成了动态内容，通常客户端都会得到一个no-cache或者private的Cache指令，导致客户端浏览器在每次请求这些Object的时候都需要重复获取或者发送HTTP304指令到服务器端询问是否改变。
但实际上，在一定的时间范围内，除了用户的帐号和查询结果外，大量的内容均是没有改变的内容。
在一个较为漂亮的网页中，至少包含有40个以上的Object（CSS,JS,JPG,GIF等），这就意味着用户需要发送40个HTTP请求来确定这些内容是否改变。
在宽带的情况下，这些请求可以快速完成，但在带宽或延迟较大的情况下，打开页面的速度就变得非常慢了。
在采用IBR技术后，WA将对页面中包含的每一个Object进行分析，并在返回的HTML页面中对每一个Object打上标记，同时，将Object设置为可在客户端进行缓存并设置较长的缓存时间。
在用户下一次请求时，将由WA和服务器端询问内容是否真正改变，如果没有改变，则在返回的页面中保持原有的标记不变，这时，客户端在收到HTML页面后，就会从本地缓存中直接读取内容，而不向站点发送更新请求。
如果Object发生了改变，则WA将会在返回HTML页面中改变标记，使客户端浏览器缓存的内容实效，从而向站点重新发起请求获得更新内容。
由于WA通常与服务器部署在同一物理位置，因此，WA向服务器发起的更新请求可以非常快速完成，从而减小了客户端在广域网上发起的更新请求。
这样，既减小了网络的传输数据量，又保证了用户始终能拿到最新的内容。
简单的说，IBR就是发动浏览器，让每个客户端的浏览器都变成WA的Cache空间。
WA对所有通过的流量进行分析，然后把真正的动态部分和相对静态部分进行分离。
让动态部分在网络上进行传输而静态部分尽量在浏览器的本地Cache，这样，当客户端再次访问同样的网页时，就无需重复下载图片、CSS、JS、文档等内容，而只需要从本地的浏览器Cache直接读取即可。
随之而来的结果是：
页面加载速度变快，HTTP连接处理方面的开销减少了90%。
另外，用户和web服务器间的流量显著下降，下载速度提高了10倍或10倍以上（即使对于拨号用户亦是如此）。
ExpressDocuments加速文档下载
ExpressDocuments能够简化工作任务，并与诸如Word、PowerPoint、Excel、PDF以及其它文档协同工作。
通过充分利用边缘和浏览器高速缓存，在不影响文档精度的情况下，ExpressDocuments能够加快频繁访问文档的存储及其服务。
和IBR类似，WA可以对每一个下载的文档打上特定的标记，在文档第一次被客户端下载时，将文档转换为静态可Cache内容，保存在客户端本地或者客户端的Proxy服务器上。
使客户端可以在本地下载和打开文档。
而在文档发生改变的时候，WA通过改变文档标记，使客户端或本地Proxy服务器重新获取更新后的文档。
这样，极大地减小了文档本身在广域网上的传输量。
另外，WebAccelerator支持HTTP“范围请求”，这样，大量文档可分成不同部分分别下载并立即显示，而不是等到所有内容全部下载完成才显示。
诸如较大的PDF文件等复杂文档可在几秒钟内下载即让用户看到内容，这就极大改善了用户体验。
ExpressConnects并行处理页面下载
在正常情况下，浏览器对于每一个域名或者IP的访问，只能打开两个连接并行处理所有的HTTP请求。
在一个界面友好的Web页面上，通常包含有40个以上的Object，这些Object的请求都需要在这两个连接中进行请求，并且由于HTTP的Request-Response机制，导致了用户必须在两个连接中等待所有的Object请求结束。
通过WA的ExpressConnects技术，可以将这些Object进行分组，使浏览器发起多个并行的连接进行请求，就像是通过FlashGet等并行下载软件，可以完全的使用网络带宽来进行内容下载。
借助Express连接，标准浏览器服务器连接的速率获得了极大提升，这就好比是一条破旧狭窄的乡间小径，升级改造成了一条超级洲际高速公路。
与每个浏览器请求进行排队并等待前一个请求返回不同，请求与响应将以并行的方式通过网络发送至F5WebAccelerator。
由于F5WebAccelerator极为高效，拥有可观的可用周期，因此它能够立刻发起上述请求，并且在多数情况下，无须源服务器的介入。
因此，通过优化就能实现服务器的可扩展性和带宽容量的提升。
据用户反映，性能上的提升甚至远不止这些。
3.结论．
通过Web应用优化技术，可以极大的提高客户端的页面打开速度，同时减小服务器端的压力。
一个WA的典型应用案例得到以下效果：
当客户端在中国，而WA部署在法国，客户端页面打开的速度基本接近于在法国本地的页面打开速度。
完全克服了由于远程访问带来的延迟。
同时，在另外一个用户使用BIGIP进行优化后，得到了以下效果：
在使用带宽降低66%的同时，服务器压力、服务器软件授权费用和管理时间都降低了1/3,同时，客户端的页面加载时间从原来的3秒钟降低到了1秒钟。
升级会员 