F5ＷＥＢ加速技術方案2011年2月

目錄TOC\o"1-2"\h\z\u1.前言 22.加速WEB應用，大幅提高用戶體驗效果 42.1SOffload 42.2OneConnect降低服務器TCP連接數(shù)量 52.3頁面壓縮降低帶寬占用和提高客戶端響應速度 52.4RAMCache減小服務器端壓力 72.5應用智能緩存優(yōu)化動態(tài)內(nèi)容 92.6IBR閱讀器智能限制 102.7ExpressDocuments加速文檔下載 122.8ExpressConnects并行處理頁面下載 133.結論 19前言始終以來，通過低速鏈路連接的遠程站點都運用專用服務器硬件以便實現(xiàn)最佳性能。但由于成本壓力、技能欠缺以及須要更好地處理平安問題等緣由。將服務器功能整合到主數(shù)據(jù)中心，是實現(xiàn)服務器整合的主要方法。應用網(wǎng)絡化也帶來了類似的問題，但稍有區(qū)分。很多常用的應用平臺都從客戶端-服務器模式向基于web的模式遷移。這樣一來，便可通過供應應用，而不必在每個終端用戶的PC上安裝客戶端。Web閱讀器成為通用客戶端。雖然這種方法避開了在每個PC上安裝客戶端，的確會減輕應用的管理負擔（某些狀況下，在客戶端-服務器互動設計不志向且涉及到多次數(shù)據(jù)庫來回操作的廣域網(wǎng)上，這種方法還可幫助提高應用性能），但通常會增加網(wǎng)絡壓力（由于須要傳遞數(shù)據(jù)的格式化信息，因此增加了網(wǎng)絡流量）。在最糟糕的狀況下，可將用戶響應時間延長10倍。

廣域網(wǎng)加速設備采納了多種技術。這些技術可以大致分為四類，每一類技術都可解決廣域網(wǎng)中的某個特定問題。?帶寬：帶寬通常是稀缺資源，因此必須要節(jié)約運用。帶寬瓶頸可通過壓縮技術得以解決。壓縮技術通常分兩類，第一類是基于字典流的傳統(tǒng)壓縮技術。在此類技術中，每一端的設備都構建通用模式字典，然后以短標識符替代它們。因此，從理論上說，帶寬可節(jié)約近90%，但未經(jīng)壓縮且未經(jīng)加密的數(shù)據(jù)通常占到50%左右。其次類壓縮技術認為，在一般的網(wǎng)絡中，大部分的數(shù)據(jù)（如文件）通常是來回傳輸?shù)模薷姆群苄?。因此，在任一端運用硬盤來保存這些數(shù)據(jù)，只傳輸發(fā)生變更的信息（或變量），最多可將網(wǎng)絡備份等帶寬密集型任務和其他文件密集型任務的帶寬削減99%。?時延：時延是廣域網(wǎng)固有的問題。在低速鏈路上，即使傳播延遲很短，仍存在較長的串行化延遲。延時問題可通過加速技術得以解決，其中最基本的是TCP加速。這項技術認為，延時造成的響應時間減慢多半是TCP協(xié)議等待確認的結果。最簡便的解決方法是讓攔截設備“監(jiān)聽”TCPACK消息，并管理廣域網(wǎng)上的信息傳輸。這樣，最終主機便認為遠程端與它并排位于局域網(wǎng)上，從而能夠以更快的速度與加速平臺互動。此外，在“閑談式”協(xié)議（如CIFS、MicrosoftExchangeMAPI等）所在的應用級別，應用加速也可以“欺瞞”應用響應速度和TCPACK。另一種加速技術是Web加速，它運用嵌入在廣域網(wǎng)加速設備中的web代理來進一步加快懇求速度。Web加速尤其適用于來自支持web的核心應用、不斷重復的序列。依據(jù)閱歷，設備中所供應的加速技術越多，效果越好。?網(wǎng)絡資源爭用：網(wǎng)絡資源爭用也是低速廣域網(wǎng)中的常見問題。不同的應用對延時和響應時間有著不同要求，而某些應用在教化環(huán)境中更受歡迎。優(yōu)良的廣域網(wǎng)加速設備可通過服務質(zhì)量（QoS）技術為延遲敏感型應用和重要應用安排高于其他服務的優(yōu)先級。更優(yōu)秀的加速產(chǎn)品還能運用基于策略的多路徑技術，來優(yōu)化那些存在著多條路徑且每條路徑都有不同特征的網(wǎng)絡。?可視性：網(wǎng)絡管理員須要了解服務在網(wǎng)絡上的運行方式。與沒有供應全面的網(wǎng)絡管理工具的解決方案相比，具有強大的流量分析和報告功能的設備能夠供應更高價值。下面針對F5廣域網(wǎng)加速技術和WEB加速技術進行分析。加速WEB應用，大幅提高用戶體驗效果SOffload在SSL處理過程中，全部的傳輸內(nèi)容均采納加密算法處理。其中最重要的兩個部分為SSL握手時交換秘鑰的非對稱加密和數(shù)據(jù)傳輸時的對稱加密。在現(xiàn)有的系統(tǒng)中，通常非對成加密采納1024位的密鑰進行加解密，因此對服務器的CPU占用率特別高。在一臺最新型號的雙Xeon服務器上，大約每秒鐘400次非對稱加解密就能導致CPU占用率100%。同時對稱加密通常采納128位，最高256位加密的加解密也會導致服務器CPU占用率居高不下，同樣的服務器SSL流量大約能達到150Mbps。因此當我們在部署SSL應用時，必需考慮到以下參數(shù)： TPS：TransectionPerSecond，也就是每秒鐘完成的非對稱加解密次數(shù) Bulk：SSL對稱加解密的吞吐實力，通常以Mbps來進行衡量。當SSL的客戶端壓力超過400TPS時，單臺服務器就很難處理懇求了。因此，必需采納SSL加速設備來進行處理。BIGIP-LTM/WA系列可從最低2000TPS到480,00TPS實現(xiàn)全硬件處理SSL非對稱加密和對稱加密流量。其實現(xiàn)的結構如下：全部的SSL流量均在BIGIP-LTM/WA上終結，BIGIP-LTM/WA與服務器之間可采納或者弱加密的SSL進行通訊。這樣，就極大的減小了服務器端對S處理的壓力，可將服務器的處理實力釋放出來，更加專注的處理業(yè)務邏輯。在BIGIP-LTM/WA可處理單向SSL連接，雙向SSL連接。并且可同時處理多種類型和多個應用的SSL加解密處理。OneConnect降低服務器TCP連接數(shù)量用戶因連接和斷開網(wǎng)絡連接而產(chǎn)生的周期性網(wǎng)絡懇求會耗費掉企業(yè)珍貴的web應用資源。即使每個連接開銷很小，但合到一起，它們將影響到總的應用負載，對于電子商務站點和擁有大量用戶的企業(yè)應用來說，這一點尤為明顯。在ApacheServer的標準配置中，一臺服務器的最高并發(fā)連接數(shù)為1024個，而MicroSoftIIS可配置為2048個?？梢娺B接數(shù)對于服務器是一個極大的限制,在應用服務器上比如Weblogic，WebSphere上，連接數(shù)的增加將會給系統(tǒng)增加大量的開銷。連接優(yōu)化將處理連接的責任移交給了F5BIGIP-LTM/WA。網(wǎng)絡流量在BIGIP-LTM/WA和源應用之間的小型資源池和永久連接中進行多路傳輸。BIGIP-LTM/WA將成千上萬個用戶的連接匯聚成為少數(shù)的服務器連接，最終可顯著降低源應用的負載。與其它的連接優(yōu)化技術不同，F(xiàn)5采納了動態(tài)連接池的方式，當每一個用戶懇求發(fā)送到BIGIP-LTM/WA時，依據(jù)負載均衡策略，BIGIP-LTM/WA將在懇求將被發(fā)送到的服務器端找尋空閑的連接，假如有空閑連接，則干脆將懇求通過該連接發(fā)送到服務器，假如沒有空閑連接，則新建一個連接與服務器端通訊。這樣，既保證了在服務器端始終維持最小的連接數(shù)，又避開了由于沒有空閑連接而導致的客戶端懇求排隊的現(xiàn)象。頁面壓縮降低帶寬占用和提高客戶端響應速度應用和網(wǎng)絡延遲問題進一步降低了web內(nèi)容的傳輸速度。BIGIP-LTM/WebAccelerator專利技術－Express壓縮技術能夠消退因壓縮算法所帶來的延遲，為撥號和寬帶用戶帶來額外的性能提升。事實上，借助Express壓縮，撥號用戶的訪問速率將比原來快5到10倍，同時帶寬利用率和成本將降低70%-80%。WebServerWebServerClient1Client2BIG-IP/WACompressionontheBIG-IP/WA響應時間的加快，帶來了用戶滿足度和員工效率的提升，從而使基于web的應用得到更加廣泛的應用。單在更低帶寬成本方面所節(jié)約的費用（尤其在遠程銷售辦公機構或人員方面所節(jié)約的費用），就足以補償在設備購置方面的投資，甚至是后者的好幾倍。運用工業(yè)標準的GZIP和Deflate壓縮算法來壓縮流量；降低帶寬消耗、縮短最終用戶在慢速/低帶寬連接條件下的下載時間。一個典型的壓縮處理的流程如下：BIGIP-LTM/WA接收到閱讀器的懇求后，依據(jù)閱讀器的accept-encoding字段頭檢查閱讀器是否支持壓縮；假如閱讀器支持壓縮，WA則檢查懇求Match的Policy，假如Policy選擇了內(nèi)容壓縮，并且可Cache，則起先的內(nèi)容是否在自身Cache內(nèi)有存放；假如在WA本地（包括內(nèi)存和硬盤）上已經(jīng)有懇求內(nèi)容存在，則干脆將懇求內(nèi)容；假如可Cache但在WA本地無法找到相應內(nèi)容，WA則將懇求轉(zhuǎn)發(fā)到服務器，在服務器返回內(nèi)容后，將頁面進行壓縮后，緩存在本地，再將懇求返回給發(fā)起懇求的客戶端。在開啟壓縮功能后，對于HTML頁面，CSS等文本類型的數(shù)據(jù)，通?？梢匀〉?0%左右的壓縮率，而對于一些已經(jīng)壓縮過的文件類型，如jpg，gif，pdf等文件，壓縮則可能獲得完全相反的結果。在BIGIP-LTM/WA的配置中，可以敏捷的定義那些內(nèi)容須要壓縮，那些類型不進行壓縮，甚至可以定義到特定的URI來進行壓縮處理。廣域網(wǎng)訪問的網(wǎng)絡延時與帶寬瓶頸常常給用戶的WEB應用的正常訪問帶來不便，通過在F5BIGIP-LTM/WA上啟用壓縮功能，可以帶來以下好處：更快的頁面下載速度：在采納壓縮技術后，同樣的頁面?zhèn)鬟f到客戶端的時間和包數(shù)量大大減小，從而提高了客戶端的頁面下載速度。更小的帶寬消耗：支持廣泛數(shù)據(jù)類型的壓縮：例如,XML,Javascript,J2EEapplicationsandmanyothers，啟用帶寬壓縮所帶來的帶寬節(jié)約可以達到80%?？蛻舳俗赃m應的壓縮處理實力(技術專利)：F5BIG-IP-LTM可以通過探測到客戶端的RoundTripTime來識別用戶是通過寬帶還是窄帶方式上網(wǎng)，然后確定是否要對該用戶啟用壓縮功能。對用戶完全透亮，不須要在客戶端安裝程序：F5BIG-IP-LTM/WA應用交換機采納的壓縮算法是目前常用WEB閱讀器廣泛支持的GZIP和Deflate算法，因此對用戶完全透亮，不須要預先安裝客戶端解壓程序。RAMCache減小服務器端壓力在BIGIP-LTM上，可以通過配置內(nèi)存Cache來提高系統(tǒng)響應速度，并減小服務器端的壓力。通過內(nèi)存Cache機制，BIGIP-LTM/WA可以把頻繁訪問的內(nèi)容存放在內(nèi)存中，當下一次懇求到達時，干脆從內(nèi)存返回用戶懇求的頁面。從而降低了服務器的懇求壓力。運用RAM高速緩存的時機運用RAM高速緩存特性可以降低后臺服務器的流量負載。假如站點上的某個對象會頻繁用到，站點有大量的靜態(tài)內(nèi)容，或者站點上的對象經(jīng)過壓縮，那么此功能特別有用。頻繁用到的對象假如在一些時期內(nèi)，頻繁用到站點上的某些特定內(nèi)容，那么便可運用此特性。通過對RAM高速緩存的配置，內(nèi)容服務器僅需在每個有效期內(nèi)向BIG-IP系統(tǒng)供應一次相關內(nèi)容。靜態(tài)內(nèi)容假如站點由大量靜態(tài)內(nèi)容組成，例如CSS、javascript、圖像或徽標，此特性也很有用。內(nèi)容壓縮對于可壓縮數(shù)據(jù)，RAM高速緩存能夠針對可接受壓縮數(shù)據(jù)的客戶端存儲數(shù)據(jù)。在BIG-IP系統(tǒng)上與壓縮特性一起運用時，RAM高速緩存可以減輕BIG-IP系統(tǒng)和內(nèi)容服務器的壓力?？梢跃彺娴捻椖縍AM高速緩存特性完全兼容RFC2616“超文本傳輸協(xié)議——/1.1”中規(guī)定的高速緩存規(guī)則。這意味著，可以將RAM高速緩存配置為緩存以下內(nèi)容類型：200、203、206、300、301和410響應；缺省響應GET方法；用于URI“包含”列表中指定的URI的其它方法，或iRule中指定的其它方法；基于User-Agent和Accept-Encoding值的內(nèi)容。RAM高速緩存為Vary標頭存有不同的內(nèi)容。RAM高速緩存不緩存的項目包括：高速緩存限制標頭指定的私有數(shù)據(jù)；默認狀況下，RAM高速緩存不緩存HEAD、PUT、DELETE、TRACE和CONNECT方法。了解RAM高速緩存機制缺省的RAM高速緩存配置僅緩存GET方法。通過在URI“包含”列表中指定URI，或者編寫iRule，可以運用RAM高速緩存來同時緩存GET方法和其它方法，包括非方法。表1.1描述了高速緩存用來存儲緩存內(nèi)容的機制。操作緩存的內(nèi)容刪除刪除全部cookie標頭。修改供應時，逐個中繼地修改標頭。這些標頭包括：Connection、Keep-Alive和TransferEncoding。添加添加Date標頭，其中包含BIG-IP系統(tǒng)上的當前時間。添加Age標頭，它反映了項目在緩存中存在的總時長。請留意，此設置在配置文件中缺省為開。通過在配置文件中，將InsertAgeHeader屬性變?yōu)閛ff可以禁用此設置。表1.1 高速緩存的存儲機制清空高速緩存中的項目RAM高速緩存可以刪除高速緩存中運用最不常見的項目。這將防止選擇新項目進行緩存時，較早的項目仍舊占用著高速緩存的空間。高速緩存還運用計分系統(tǒng)，在一段時間之后刪除較早的項目。緩存的項目達到其生存時間期限時，便認為它在高速緩存中已過期。運用配置文件屬性可以限制每個高速緩存實例的大小，以及項目在高速緩存中過期的速度。應用智能緩存優(yōu)化動態(tài)內(nèi)容應用智能緩存(ApplicationSmartCache)完全變更了傳統(tǒng)的靜態(tài)高速緩存模式，能夠高速緩存種類更廣泛的內(nèi)容，包括高級動態(tài)web頁面和XML對象。該項專利技術為F5公司獨有專利技術。ASC關注應用邏輯與行為，而不僅僅是單個web對象。通過描述某項應用的高級邏輯（可高速緩存與不行高速緩存的內(nèi)容、可導致失敗的事務等），WebAccelerator可消退對困難web懇求的重復處理。借助應用智能高速緩存技術，WebAccelerator系統(tǒng)可確定何時使對象無效及如何識別可復用的內(nèi)容塊。直觀的用戶界面、功能強大、基于XML的API以及基于懇求的觸發(fā)裝置相結合，為用戶供應了功能齊全的控件，從而可使內(nèi)容生效或無效?，F(xiàn)有的高速緩存解決方案未采納WebAccelerator和ASC，僅將對象的失效日期作為參考指南。ASC支持高速緩存查看懇求中的全部內(nèi)容（無論是URL、cookie、查詢參數(shù)還是其它標頭）并生成“智能”無效信息與高速緩存密鑰。通過采納以下兩種密鑰性能，WebAccelerator解決了長期以來無法解決的對動態(tài)內(nèi)容進行高速緩存的問題：由應用和用戶事務觸發(fā)的一種高速緩存無效機制?？蓪⒎蠗l件的用戶懇求與高速緩存的內(nèi)容連接起來的一種完善的匹配算法。下圖是對一個動態(tài)站點的真實狀況分析結果：對于運用率較高的應用而言，典型的靜態(tài)高速緩存僅可響應20%的懇求。這是因為多數(shù)應用都特別困難，須要與其它應用和數(shù)據(jù)庫進行大量的交互操作，因此，靜態(tài)解決方案并不能滿足對象高速緩存的要求。借助ASC，WebAccelerator可干脆響應高達80%的用戶懇求（此類懇求占用大量計算資源），且無需利用站點的其它基礎設施。WA的ASC在詳細實現(xiàn)中，針對同樣懇求的URI，比如都懇求://.jsp?recordId=12913，傳統(tǒng)的靜態(tài)Cache會認為這是一個動態(tài)頁面，不進行Cache，但在WA工作狀態(tài)下，可依據(jù)變量存在的位置來進行區(qū)分，這些變量名稱的變更的時候，WA就認為是不同的頁面，所以在Cache時存放的也是不同的頁面。當客戶端訪問時，WA則只有在全部的變量都相同的狀況下，從本地緩存返回給用戶。這樣，就不須要到服務器再進行查詢了。前提是可以接受肯定的刷新時間，比如10分鐘。默認值為依據(jù)域名、路徑和查詢的參數(shù)來對Cache內(nèi)容進行區(qū)分不同的頁面內(nèi)容。其他的如Cookie，用戶Agent，客戶端IP等則認為是同樣的懇求。而這些都是可以依據(jù)實際的應用站點進行精確調(diào)整的。比如懇求：://.jsp?recordId=12913和://，由于懇求的queryparameter(recordId)不同。則在WA內(nèi)Cache是兩個頁面，而不管用戶過來的Cookie和閱讀器類型是什么，只要是相同的queryparameter,在有效期內(nèi)都用緩存的頁面進行回應。IBR閱讀器智能限制多數(shù)上傳懇求僅僅檢查嵌入對象和大圖片的有效性及其更新狀況。這就造成不必要的延遲進而引起應用性能下降。WebAccelerator的ExpressLoader技術消退了大量上傳內(nèi)容更新懇求、極大削減了頁面加載的時間以及網(wǎng)絡的流量。當內(nèi)容變動時，WebAccelerator引導閱讀器至新的版本，同時正確的內(nèi)容總能得以維護。假如內(nèi)容并未變動，它會馬上引導閱讀器從本地高速緩存加載從前的版本。當我們對于一個動態(tài)站點（通常是基于中間件的業(yè)務系統(tǒng)，如BeaWeblogic,IBMWebSphere,OracleIAS等）進行分析時，在來回的幾次訪問中，能望見大量的重復內(nèi)容在不停的傳送，至少，能望見304懇求到服務器詢問該內(nèi)容是否變更。這樣，引起了大量的不必要懇求，加重了服務器的負擔，同時增加了網(wǎng)絡的消耗，引起客戶端頁面打開速度的變慢。以一個典型的銀行網(wǎng)銀系統(tǒng)為例，在用戶登錄后，全部的內(nèi)容都變成了動態(tài)內(nèi)容，通?？蛻舳硕紩玫揭粋€no-cache或者private的Cache指令，導致客戶端閱讀器在每次懇求這些Object的時候都須要重復獲得或者發(fā)送304指令到服務器端詢問是否變更。但事實上，在肯定的時間范圍內(nèi)，除了用戶的帳號和查詢結果外，大量的內(nèi)容均是沒有變更的內(nèi)容。在一個較為美麗的網(wǎng)頁中，至少包含有40個以上的Object(CSS,JS,JPG,GIF等)，這就意味著用戶須要發(fā)送40個懇求來確定這些內(nèi)容是否變更。在寬帶的狀況下，這些懇求可以快速完成，但在帶寬或延遲較大的狀況下，打開頁面的速度就變得特別慢了。在采納IBR技術后，WA將對頁面中包含的每一個Object進行分析，并在返回的HTML頁面中對每一個Object打上標記，同時，將Object設置為可在客戶端進行緩存并設置較長的緩存時間。在用戶下一次懇求時，將由WA和服務器端詢問內(nèi)容是否真正變更，假如沒有變更，則在返回的頁面中保持原有的標記不變，這時，客戶端在收到HTML頁面后，就會從本地緩存中干脆讀取內(nèi)容，而不向站點發(fā)送更新懇求。假如Object發(fā)生了變更，則WA將會在返回HTML頁面中變更標記，使客戶端閱讀器緩存的內(nèi)容實效，從而向站點重新發(fā)起懇求獲得更新內(nèi)容。由于WA通常與服務器部署在同一物理位置，因此，WA向服務器發(fā)起的更新懇求可以特別快速完成，從而減小了客戶端在廣域網(wǎng)上發(fā)起的更新懇求。這樣，既減小了網(wǎng)絡的傳輸數(shù)據(jù)量，又保證了用戶始終能拿到最新的內(nèi)容。簡潔的說，IBR就是發(fā)動閱讀器，讓每個客戶端的閱讀器都變成WA的Cache空間。WA對全部通過的流量進行分析，然后把真正的動態(tài)部分和相對靜態(tài)部分進行分別。讓動態(tài)部分在網(wǎng)絡上進行傳輸而靜態(tài)部分盡量在閱讀器的本地Cache，這樣，當客戶端再次訪問同樣的網(wǎng)頁時，就無需重復下載圖片、CSS、JS、文檔等內(nèi)容，而只須要從本地的閱讀器Cache干脆讀取即可。隨之而來的結果是：頁面加載速度變快，連接處理方面的開銷削減了90%。另外，用戶和web服務器間的流量顯著下降，下載速度提高了10倍或10倍以上（即使對于撥號用戶亦是如此）。ExpressDocuments加速文檔下載ExpressDocuments能夠簡化工作任務，并與諸如Word、PowerPoint、Excel、PDF以及其它文檔協(xié)同工作。通過充分利用邊緣和閱讀器高速緩存，在不影響文檔精度的狀況下，ExpressDocuments能夠加快頻繁訪問文檔的存儲及其服務。和IBR類似，WA可以對每一個下載的文檔打上特定的標記，在文檔第一次被客戶端下載時，將文檔轉(zhuǎn)換為靜態(tài)可Cache內(nèi)容，保存在客戶端本地或者客戶端的Pr