F5web加速技術(shù)方案

1、F5加速技術(shù)方案目 錄1. 前言22. 加速WEB應(yīng)用，大幅提高用戶體驗效果42.1 HTTPS Offload42.2 One Connect降低服務(wù)器TCP連接數(shù)量52.3 HTTP頁面壓縮降低帶寬占用和提高客戶端響應(yīng)速度52.4 RAM Cache減小服務(wù)器端壓力72.5 應(yīng)用智能緩存優(yōu)化動態(tài)內(nèi)容92.6 IBR 瀏覽器智能控制102.7 Express Documents加速文檔下載122.8 Express Connects并行處理頁面下載133. 結(jié)論191. 前言一直以來，通過低速鏈路連接的遠程站點都使用專用服務(wù)器硬件以便實現(xiàn)最佳性能。但由于成本壓力、技能欠缺以及需要更好地處理安

2、全問題等原因。將服務(wù)器功能整合到主數(shù)據(jù)中心，是實現(xiàn)服務(wù)器整合的主要方法。應(yīng)用網(wǎng)絡(luò)化也帶來了類似的問題，但稍有區(qū)別。許多常用的應(yīng)用平臺都從客戶端-服務(wù)器模式向基于web的模式遷移。這樣一來，便可通過HTTP提供應(yīng)用，而不必在每個終端用戶的PC上安裝客戶端。Web瀏覽器成為通用客戶端。雖然這種方法避免了在每個PC上安裝客戶端，確實會減輕應(yīng)用的管理負擔(dān)（某些情況下，在客戶端-服務(wù)器互動設(shè)計不理想且涉及到多次數(shù)據(jù)庫來回操作的廣域網(wǎng)上，這種方法還可幫助提高應(yīng)用性能），但通常會增加網(wǎng)絡(luò)壓力（由于需要傳遞數(shù)據(jù)的格式化信息，因此增加了網(wǎng)絡(luò)流量）。在最糟糕的情況下，可將用戶響應(yīng)時間延長10倍。廣域網(wǎng)加速設(shè)備采用

3、了多種技術(shù)。這些技術(shù)可以大致分為四類，每一類技術(shù)都可解決廣域網(wǎng)中的某個特定問題。 帶寬：帶寬通常是稀缺資源，因此必須要節(jié)約使用。帶寬瓶頸可通過壓縮技術(shù)得以解決。壓縮技術(shù)通常分兩類，第一類是基于字典流的傳統(tǒng)壓縮技術(shù)。在此類技術(shù)中，每一端的設(shè)備都構(gòu)建通用模式字典，然后以短標(biāo)識符替代它們。因此，從理論上說，帶寬可節(jié)省近90%，但未經(jīng)壓縮且未經(jīng)加密的數(shù)據(jù)通常占到50%左右。第二類壓縮技術(shù)認為，在一般的網(wǎng)絡(luò)中，大部分的數(shù)據(jù)（如文件）通常是來回傳輸?shù)?，修改幅度很小。因此，在任一端使用硬盤來保存這些數(shù)據(jù)，只傳輸發(fā)生變化的信息（或變量），最多可將網(wǎng)絡(luò)備份等帶寬密集型任務(wù)和其他文件密集型任務(wù)的帶寬減少99%。

4、時延：時延是廣域網(wǎng)固有的問題。在低速鏈路上，即使傳播延遲很短，仍存在較長的串行化延遲。延時問題可通過加速技術(shù)得以解決，其中最基本的是TCP加速。這項技術(shù)認為，延時造成的響應(yīng)時間減慢多半是TCP協(xié)議等待確認的結(jié)果。最簡便的解決方法是讓攔截設(shè)備“監(jiān)聽”TCP ACK消息，并管理廣域網(wǎng)上的信息傳輸。這樣，最終主機便認為遠程端與它并排位于局域網(wǎng)上，從而能夠以更快的速度與加速平臺互動。此外，在“閑談式”協(xié)議（如CIFS、Microsoft Exchange MAPI等）所在的應(yīng)用級別，應(yīng)用加速也可以“欺騙”應(yīng)用響應(yīng)速度和TCP ACK。另一種加速技術(shù)是Web加速，它使用嵌入在廣域網(wǎng)加速設(shè)備中的web代理

5、來進一步加快請求速度。Web加速尤其適用于來自支持 web 的核心應(yīng)用、不斷重復(fù)的序列。根據(jù)經(jīng)驗，設(shè)備中所提供的加速技術(shù)越多，效果越好。 網(wǎng)絡(luò)資源爭用：網(wǎng)絡(luò)資源爭用也是低速廣域網(wǎng)中的常見問題。不同的應(yīng)用對延時和響應(yīng)時間有著不同要求，而某些應(yīng)用在教育環(huán)境中更受歡迎。優(yōu)良的廣域網(wǎng)加速設(shè)備可通過服務(wù)質(zhì)量（QoS）技術(shù)為延遲敏感型應(yīng)用和重要應(yīng)用分配高于其他服務(wù)的優(yōu)先級。更優(yōu)秀的加速產(chǎn)品還能使用基于策略的多路徑技術(shù)，來優(yōu)化那些存在著多條路徑且每條路徑都有不同特征的網(wǎng)絡(luò)。 可視性：網(wǎng)絡(luò)管理員需要了解服務(wù)在網(wǎng)絡(luò)上的運行方式。與沒有提供全面的網(wǎng)絡(luò)管理工具的解決方案相比，具有強大的流量分析和報告功能的設(shè)備能夠提

6、供更高價值。下面針對F5廣域網(wǎng)加速技術(shù)和WEB加速技術(shù)進行分析。2. 加速WEB應(yīng)用，大幅提高用戶體驗效果2.1 HTTPS Offload在SSL處理過程中，所有的傳輸內(nèi)容均采用加密算法處理。其中最重要的兩個部分為SSL握手時交換秘鑰的非對稱加密和數(shù)據(jù)傳輸時的對稱加密。在現(xiàn)有的系統(tǒng)中，通常非對成加密采用1024位的密鑰進行加解密，因此對服務(wù)器的CPU占用率非常高。在一臺最新型號的雙Xeon服務(wù)器上，大約每秒鐘400次非對稱加解密就能導(dǎo)致CPU占用率100%。同時對稱加密通常采用128位，最高256位加密的加解密也會導(dǎo)致服務(wù)器CPU占用率居高不下，同樣的服務(wù)器SSL流量大約能達到150Mbps

7、。因此當(dāng)我們在部署SSL應(yīng)用時，必須考慮到以下參數(shù)：lTPS：Transection Per Second，也就是每秒鐘完成的非對稱加解密次數(shù)lBulk：SSL對稱加解密的吞吐能力，通常以Mbps來進行衡量。當(dāng)SSL的客戶端壓力超過400TPS時，單臺服務(wù)器就很難處理請求了。因此，必須采用SSL加速設(shè)備來進行處理。BIGIP-LTM/WA系列可從最低2000TPS到480,00TPS實現(xiàn)全硬件處理SSL非對稱加密和對稱加密流量。其實現(xiàn)的結(jié)構(gòu)如下：所有的SSL流量均在BIGIP-LTM/WA上終結(jié)，BIGIP-LTM/WA與服務(wù)器之間可采用HTTP或者弱加密的SSL進行通訊。這樣，就極大的減小了

8、服務(wù)器端對HTTPS處理的壓力，可將服務(wù)器的處理能力釋放出來，更加專注的處理業(yè)務(wù)邏輯。在BIGIP-LTM/WA可處理單向SSL連接，雙向SSL連接。并且可同時處理多種類型和多個應(yīng)用的SSL加解密處理。2.2 One Connect降低服務(wù)器TCP連接數(shù)量用戶因連接和斷開網(wǎng)絡(luò)連接而產(chǎn)生的周期性網(wǎng)絡(luò)請求會耗費掉企業(yè)寶貴的 web 應(yīng)用資源。即使每個連接開銷很小，但合到一起，它們將影響到總的應(yīng)用負載，對于電子商務(wù)站點和擁有大量用戶的企業(yè)應(yīng)用來說，這一點尤為明顯。在Apache Server的標(biāo)準(zhǔn)配置中，一臺服務(wù)器的最高并發(fā)連接數(shù)為1024個，而MicroSoft IIS可配置為2048個?？梢娺B接

9、數(shù)對于服務(wù)器是一個極大的限制,在應(yīng)用服務(wù)器上比如Weblogic，WebSphere上，連接數(shù)的增加將會給系統(tǒng)增加大量的開銷。 連接優(yōu)化將處理連接的責(zé)任移交給了 F5 BIGIP-LTM/WA。網(wǎng)絡(luò)流量在 BIGIP-LTM/WA和源應(yīng)用之間的小型資源池和永久連接中進行多路傳輸。BIGIP-LTM/WA將成千上萬個用戶的連接匯聚成為少數(shù)的服務(wù)器連接，最終可顯著降低源應(yīng)用的負載。 與其它的連接優(yōu)化技術(shù)不同，F(xiàn)5 采用了動態(tài)連接池的方式，當(dāng)每一個用戶請求發(fā)送到BIGIP-LTM/WA時，根據(jù)負載均衡策略，BIGIP-LTM/WA將在請求將被發(fā)送到的服務(wù)器端尋找空閑的連接，如果有空閑連接，則直接將請

10、求通過該連接發(fā)送到服務(wù)器，如果沒有空閑連接，則新建一個連接與服務(wù)器端通訊。這樣，既保證了在服務(wù)器端始終維持最小的連接數(shù)，又避免了由于沒有空閑連接而導(dǎo)致的客戶端請求排隊的現(xiàn)象。2.3 HTTP頁面壓縮降低帶寬占用和提高客戶端響應(yīng)速度應(yīng)用和網(wǎng)絡(luò)延遲問題進一步降低了 web 內(nèi)容的傳輸速度。BIGIP-LTM/Web Accelerator專利技術(shù) Express 壓縮技術(shù)能夠消除因壓縮算法所帶來的延遲，為撥號和寬帶用戶帶來額外的性能提升。事實上，借助 Express 壓縮，撥號用戶的訪問速率將比原來快 5 到 10 倍，同時帶寬利用率和成本將降低 70%-80%。 Web ServerClient

11、 1Client 2BIG-IP/WACompression on the BIG-IP/WA響應(yīng)時間的加快，帶來了用戶滿意度和員工效率的提升，從而使基于 web 的應(yīng)用得到更加廣泛的應(yīng)用。單在更低帶寬成本方面所節(jié)約的費用（尤其在遠程銷售辦公機構(gòu)或人員方面所節(jié)省的費用），就足以補償在設(shè)備購置方面的投資，甚至是后者的好幾倍。使用工業(yè)標(biāo)準(zhǔn)的GZIP和Deflate壓縮算法來壓縮HTTP流量；降低帶寬消耗、縮短最終用戶在慢速 / 低帶寬連接條件下的下載時間。 一個典型的HTTP壓縮處理的流程如下：BIGIP-LTM/WA接收到瀏覽器的HTTP請求后，根據(jù)瀏覽器的accept-encoding字段頭檢

12、查瀏覽器是否支持HTTP壓縮； 如果瀏覽器支持HTTP壓縮，WA則檢查請求Match的Policy，如果Policy選擇了內(nèi)容壓縮，并且可Cache，則開始的內(nèi)容是否在自身Cache內(nèi)有存放； 如果在WA本地（包括內(nèi)存和硬盤）上已經(jīng)有請求內(nèi)容存在，則直接將請求內(nèi)容；如果可Cache但在WA本地?zé)o法找到相應(yīng)內(nèi)容，WA則將請求轉(zhuǎn)發(fā)到服務(wù)器，在服務(wù)器返回內(nèi)容后，將頁面進行壓縮后，緩存在本地，再將請求返回給發(fā)起請求的客戶端。在開啟HTTP壓縮功能后，對于HTML頁面，CSS等文本類型的數(shù)據(jù)，通常可以取得80%左右的壓縮率，而對于一些已經(jīng)壓縮過的文件類型，如jpg，gif，pdf等文件，壓縮則可能獲得完

13、全相反的結(jié)果。在BIGIP-LTM/WA的配置中，可以靈活的定義那些內(nèi)容需要壓縮，那些類型不進行壓縮，甚至可以定義到特定的URI來進行壓縮處理。廣域網(wǎng)訪問的網(wǎng)絡(luò)延時與帶寬瓶頸經(jīng)常給用戶的WEB應(yīng)用的正常訪問帶來不便，通過在F5 BIGIP-LTM/WA上啟用HTTP壓縮功能，可以帶來以下好處：l 更快的頁面下載速度：在采用壓縮技術(shù)后，同樣的頁面?zhèn)鬟f到客戶端的時間和包數(shù)量大大減小，從而提高了客戶端的頁面下載速度。l 更小的帶寬消耗：支持廣泛數(shù)據(jù)類型的壓縮：例如HTTP, XML, Javascript, J2EE applications and many others，啟用帶寬壓縮所帶來的帶寬

14、節(jié)省可以達到80%。l 客戶端自適應(yīng)的壓縮處理能力(技術(shù)專利)：F5 BIG-IP-LTM可以通過探測到客戶端的Round Trip Time來識別用戶是通過寬帶還是窄帶方式上網(wǎng)，然后決定是否要對該用戶啟用HTTP壓縮功能。l 對用戶完全透明，不需要在客戶端安裝程序：F5 BIG-IP-LTM/WA應(yīng)用交換機采用的壓縮算法是目前常用WEB瀏覽器廣泛支持的GZIP和Deflate算法，因此對用戶完全透明，不需要預(yù)先安裝客戶端解壓程序。2.4 RAM Cache減小服務(wù)器端壓力在BIGIP-LTM上，可以通過配置內(nèi)存Cache來提高系統(tǒng)響應(yīng)速度，并減小服務(wù)器端的壓力。通過內(nèi)存Cache機制，BIG

15、IP-LTM/WA可以把頻繁訪問的內(nèi)容存放在內(nèi)存中，當(dāng)下一次請求到達時，直接從內(nèi)存返回用戶請求的頁面。從而降低了服務(wù)器的請求壓力。2.4.1 使用RAM高速緩存的時機使用RAM高速緩存特性可以降低后臺服務(wù)器的流量負載。如果站點上的某個對象會頻繁用到，站點有大量的靜態(tài)內(nèi)容，或者站點上的對象經(jīng)過壓縮，那么此功能非常有用。 頻繁用到的對象如果在一些時期內(nèi)，頻繁用到站點上的某些特定內(nèi)容，那么便可使用此特性。通過對RAM高速緩存的配置，內(nèi)容服務(wù)器僅需在每個有效期內(nèi)向BIG-IP系統(tǒng)提供一次相關(guān)內(nèi)容。 靜態(tài)內(nèi)容如果站點由大量靜態(tài)內(nèi)容組成，例如CSS、javascript、圖像或徽標(biāo)，此特性也很有用。 內(nèi)容

16、壓縮對于可壓縮數(shù)據(jù)，RAM高速緩存能夠針對可接受壓縮數(shù)據(jù)的客戶端存儲數(shù)據(jù)。在BIG-IP系統(tǒng)上與壓縮特性一起使用時，RAM高速緩存可以減輕BIG-IP系統(tǒng)和內(nèi)容服務(wù)器的壓力。2.4.2 可以緩存的項目RAM高速緩存特性完全兼容RFC 2616“超文本傳輸協(xié)議HTTP/1.1”中規(guī)定的高速緩存規(guī)則。這意味著，可以將RAM高速緩存配置為緩存以下內(nèi)容類型： 200、203、206、300、301和410響應(yīng)； 缺省響應(yīng)GET方法； 用于URI“包含”列表中指定的URI的其它HTTP方法，或iRule中指定的其它HTTP方法； 基于User-Agent和Accept-Encoding值的內(nèi)容。RAM高

17、速緩存為Vary標(biāo)頭存有不同的內(nèi)容。RAM高速緩存不緩存的項目包括： 高速緩存控制標(biāo)頭指定的私有數(shù)據(jù)； 默認情況下，RAM高速緩存不緩存HEAD、PUT、DELETE、TRACE和CONNECT方法。2.4.3 了解RAM高速緩存機制缺省的RAM高速緩存配置僅緩存HTTP GET方法。通過在URI“包含”列表中指定URI，或者編寫iRule，可以使用RAM高速緩存來同時緩存GET方法和其它方法，包括非HTTP方法。表1.1描述了高速緩存用來存儲緩存內(nèi)容的機制。操作緩存的內(nèi)容刪除刪除所有cookie標(biāo)頭。修改提供時，逐個中繼地修改標(biāo)頭。這些標(biāo)頭包括：Connection、Keep-Alive和T

18、ransfer Encoding。添加添加Date標(biāo)頭，其中包含BIG-IP系統(tǒng)上的當(dāng)前時間。添加Age標(biāo)頭，它反映了項目在緩存中存在的總時長。請注意，此設(shè)置在配置文件中缺省為開。通過在配置文件中，將Insert Age Header屬性變?yōu)閛ff可以禁用此設(shè)置。表1.1高速緩存的存儲機制2.4.4 清空高速緩存中的項目RAM高速緩存可以刪除高速緩存中使用最不頻繁的項目。這將防止選擇新項目進行緩存時，較早的項目仍然占用著高速緩存的空間。高速緩存還使用計分系統(tǒng)，在一段時間之后刪除較早的項目。緩存的項目達到其生存時間期限時，便認為它在高速緩存中已過期。使用HTTP配置文件屬性可以控制每個高速緩存實

19、例的大小，以及項目在高速緩存中過期的速度。2.5 應(yīng)用智能緩存優(yōu)化動態(tài)內(nèi)容應(yīng)用智能緩存 (Application Smart Cache) 完全改變了傳統(tǒng)的靜態(tài)高速緩存模式，能夠高速緩存種類更廣泛的內(nèi)容，包括高級動態(tài) web 頁面和 XML 對象。該項專利技術(shù)為 F5 公司獨有專利技術(shù)。ASC 關(guān)注應(yīng)用邏輯與行為，而不僅僅是單個 web 對象。通過描述某項應(yīng)用的高級邏輯（可高速緩存與不可高速緩存的內(nèi)容、可導(dǎo)致失敗的事件等），WebAccelerator 可消除對復(fù)雜 web 請求的重復(fù)處理。借助應(yīng)用智能高速緩存技術(shù)，WebAccelerator 系統(tǒng)可決定何時使對象無效及如何識別可復(fù)用的內(nèi)容塊

20、。直觀的用戶界面、功能強大、基于 XML 的API 以及基于 HTTP 請求的觸發(fā)裝置相結(jié)合，為用戶提供了功能齊全的控件，從而可使內(nèi)容生效或無效。 現(xiàn)有的高速緩存解決方案未采用 WebAccelerator 和 ASC，僅將對象的失效日期作為參考指南。ASC 支持高速緩存查看 HTTP 請求中的全部內(nèi)容（無論是 URL、cookie、查詢參數(shù)還是其它標(biāo)頭）并生成“智能”無效信息與高速緩存密鑰。通過采用以下兩種密鑰性能，WebAccelerator 解決了長期以來無法解決的對動態(tài)內(nèi)容進行高速緩存的問題： l 由應(yīng)用和用戶事件觸發(fā)的一種高速緩存無效機制。 l 可將符合條件的用戶請求與高速緩存的內(nèi)容

21、連接起來的一種完善的匹配算法。 下圖是對一個動態(tài)站點的真實情況分析結(jié)果：對于使用率較高的應(yīng)用而言，典型的靜態(tài)高速緩存僅可響應(yīng) 20% 的 HTTP 請求。這是因為多數(shù)應(yīng)用都十分復(fù)雜，需要與其它應(yīng)用和數(shù)據(jù)庫進行大量的交互操作，因此，靜態(tài)解決方案并不能滿足對象高速緩存的要求。借助 ASC，WebAccelerator 可直接響應(yīng)高達 80% 的用戶請求（此類請求占用大量計算資源），且無需利用站點的其它基礎(chǔ)設(shè)施。WA的ASC在具體實現(xiàn)中，針對同樣請求的URI，比如都請求 /products.jsp? recordId=12913，傳統(tǒng)的靜態(tài)Cache會認為這是一個動態(tài)頁面，不進行Cache，但在WA

22、工作狀態(tài)下，可根據(jù)變量存在的位置來進行區(qū)分，這些變量名稱的變化的時候，WA 就認為是不同的頁面，所以在Cache時存放的也是不同的頁面。當(dāng)客戶端訪問時，WA則只有在所有的變量都相同的情況下，從本地緩存返回給用戶。這樣，就不需要到服務(wù)器再進行查詢了。前提是可以接受一定的刷新時間，比如10分鐘。默認值為根據(jù)域名、路徑和查詢的參數(shù)來對Cache內(nèi)容進行區(qū)分不同的頁面內(nèi)容。其他的如Cookie，用戶Agent，客戶端IP等則認為是同樣的請求。而這些都是可以根據(jù)實際的應(yīng)用站點進行精確調(diào)整的。比如請求：/products.jsp? recordId=12913和/products.jsp? recordI

23、d=12914，由于請求的query parameter (recordId) 不同。則在WA內(nèi)Cache是兩個頁面，而不管用戶過來的Cookie和瀏覽器類型是什么，只要是相同的query parameter,在有效期內(nèi)都用緩存的頁面進行回應(yīng)。2.6 IBR 瀏覽器智能控制多數(shù)上傳請求僅僅檢查嵌入對象和大圖片的有效性及其更新情況。這就造成不必要的延遲進而引起應(yīng)用性能下降。WebAccelerator 的 Express Loader 技術(shù)消除了大量上傳內(nèi)容更新請求、極大減少了頁面加載的時間以及網(wǎng)絡(luò)的流量。當(dāng)內(nèi)容變動時，WebAccelerator 引導(dǎo)瀏覽器至新的版本，同時正確的內(nèi)容總能得以維

24、護。如果內(nèi)容并未變動，它會立即引導(dǎo)瀏覽器從本地高速緩存加載先前的版本。當(dāng)我們對于一個動態(tài)站點（通常是基于中間件的業(yè)務(wù)系統(tǒng)，如Bea Weblogic, IBM WebSphere, Oracle IAS等）進行分析時，在往返的幾次訪問中，能看見大量的重復(fù)內(nèi)容在不停的傳送，至少，能看見HTTP 304請求到服務(wù)器詢問該內(nèi)容是否改變。這樣，引起了大量的不必要請求，加重了服務(wù)器的負擔(dān)，同時增加了網(wǎng)絡(luò)的消耗，引起客戶端頁面打開速度的變慢。以一個典型的銀行網(wǎng)銀系統(tǒng)為例，在用戶登錄后，所有的內(nèi)容都變成了動態(tài)內(nèi)容，通?？蛻舳硕紩玫揭粋€no-cache或者private的Cache指令，導(dǎo)致客戶端瀏覽器在每

25、次請求這些Object的時候都需要重復(fù)獲取或者發(fā)送HTTP 304指令到服務(wù)器端詢問是否改變。但實際上，在一定的時間范圍內(nèi)，除了用戶的帳號和查詢結(jié)果外，大量的內(nèi)容均是沒有改變的內(nèi)容。在一個較為漂亮的網(wǎng)頁中，至少包含有40個以上的Object(CSS, JS, JPG, GIF等)，這就意味著用戶需要發(fā)送40個HTTP請求來確定這些內(nèi)容是否改變。在寬帶的情況下，這些請求可以快速完成，但在帶寬或延遲較大的情況下，打開頁面的速度就變得非常慢了。在采用IBR技術(shù)后，WA將對頁面中包含的每一個Object進行分析，并在返回的HTML頁面中對每一個Object打上標(biāo)記，同時，將Object設(shè)置為可在客戶端

26、進行緩存并設(shè)置較長的緩存時間。在用戶下一次請求時，將由WA和服務(wù)器端詢問內(nèi)容是否真正改變，如果沒有改變，則在返回的頁面中保持原有的標(biāo)記不變，這時，客戶端在收到HTML頁面后，就會從本地緩存中直接讀取內(nèi)容，而不向站點發(fā)送更新請求。如果Object發(fā)生了改變，則WA將會在返回HTML頁面中改變標(biāo)記，使客戶端瀏覽器緩存的內(nèi)容實效，從而向站點重新發(fā)起請求獲得更新內(nèi)容。由于WA通常與服務(wù)器部署在同一物理位置，因此，WA向服務(wù)器發(fā)起的更新請求可以非?？焖偻瓿桑瑥亩鴾p小了客戶端在廣域網(wǎng)上發(fā)起的更新請求。這樣，既減小了網(wǎng)絡(luò)的傳輸數(shù)據(jù)量，又保證了用戶始終能拿到最新的內(nèi)容。 簡單的說，IBR就是發(fā)動瀏覽器，讓每個

27、客戶端的瀏覽器都變成WA的Cache空間。WA對所有通過的流量進行分析，然后把真正的動態(tài)部分和相對靜態(tài)部分進行分離。讓動態(tài)部分在網(wǎng)絡(luò)上進行傳輸而靜態(tài)部分盡量在瀏覽器的本地Cache，這樣，當(dāng)客戶端再次訪問同樣的網(wǎng)頁時，就無需重復(fù)下載圖片、CSS、JS、文檔等內(nèi)容，而只需要從本地的瀏覽器Cache直接讀取即可。隨之而來的結(jié)果是：頁面加載速度變快，HTTP 連接處理方面的開銷減少了 90%。另外，用戶和 web 服務(wù)器間的流量顯著下降，下載速度提高了 10 倍或 10 倍以上（即使對于撥號用戶亦是如此）。2.7 Express Documents加速文檔下載Express Documents能夠簡化工作任務(wù)，并與諸如 Word、PowerPoint、Excel、PDF 以及其它文檔協(xié)同工作。通過充分利用邊緣和瀏覽器高速緩存，在不影響文檔精度的情況下，Express Documents能夠加快頻繁訪問文檔的存儲及其服務(wù)。 和IBR類似，WA可以對每一個下載的文檔打上特定的標(biāo)記，在文檔第一次被客戶端下載時，將文檔轉(zhuǎn)換為靜態(tài)可Cache內(nèi)容，保存在客戶端本地或者客戶端的Proxy服務(wù)器上。使客戶端可以在本地下載和打開文檔。而在文檔發(fā)生改變的時候，WA通過改變文檔標(biāo)記，使客戶端或本地Proxy