叢集架構規劃和設計只要是涉及到高併發高流量的專案，基本上都需要。

本文主要圍繞兩個方面，一個是IDC的規劃和選擇，另一個是CDN。

一、IDC的規劃和選擇

IDC的選擇是網站上線前要做的最重要的事情之一。哪怕發展初期只有一臺伺服器，選擇一個位置不錯的機房託管，都會助益良多。

也許有人會問IDC是什麼？

我引用百度百科來回答:

IDC為網際網路內容提供商（ICP）、企業、媒體和各類網站提供大規模、高質量、安全可靠的專業化伺服器託管、空間租用、網路批發頻寬以及ASP、EC等業務。IDC是對入駐（Hosting）企業、商戶或網站伺服器群託管的場所；是各種模式電子商務賴以安全運作的基礎設施，也是支援企業及其商業聯盟（其分銷商、供應商、客戶等）實施價值鏈管理的平臺。 名詞解釋（業務理解非演講內容） ICP：網際網路資訊服務，比如新浪、搜狐、網易。網際網路資訊服務可分為經營性資訊服務和非經營性資訊服務兩類。

IDC翻譯過來的單詞極速網際網路資料中心。

1.網站性質決定基礎面

首先，我們需要對網站的性質和情況又足夠確定的資訊。這不單單是說當前的情況，還包括對未來至少一年的預期。因為IDC合同至少要籤一年。

網站性質，第一指網站使用者的分佈範圍。區域性的網站必然選擇本區域內的IDC服務，比如各省衛視的網站，甚至更小一些的各市資訊港等;全國性質的網站，要考慮到北上廣浙等經濟發達地區才是主力消費人群的集聚地，提高這部分使用者的訪問體驗，就需要儘量把IDC選擇在這些區域內；全球性質的網站，比如外貿性質的，或者選擇國內運營商主力外聯節點位置，或者乾脆選擇海外IDC，像香港、美國、日本、新加坡和英國等。

其次考慮網站具體業務的性質。新聞門戶類的網站，與娛樂遊戲類的網站，在高峰時段、流量型別等方面的要求不一樣。比如新聞門戶，高峰在早9點上班前後;而娛樂遊戲類，高峰在晚9點餐飲結束後,可以一直持續到次日凌晨2點，週末更是流量高峰的高峰;至於電子交易類，13點午餐後也有個高峰時段。

再次還有使用者數量級。IDC需要應對的使用者訪問量是十萬、百萬還是千萬，直接關係到對機櫃和出口頻寬的需求。而這也是考察IDC時很重要的一點。當然這個資料換算本身也涉及業務性質的區別。

 

2.IDC廠商服務質量

考察IDC廠商的服務質量，有如下幾個參考指標?

(1)IDC出口總頻寬

出口總頻寬和剩餘頻寬幾乎可以認為是最關鍵的指標。如果不瞭解這個問題，當業務飛速發展時會發現想擴充套件頻寬都擴充套件不了，簡直是致命的打擊。

(2)連通性和穩定性

確定頻寬可以滿足以後，下一步就是確認網路質量，即IDC出口到各大節點或者其他IDC網路的連通性和穩定性。這方面建議自行測試一兩天，如果業務型別對雙休日要求比較嚴格，甚至可以測試一星期來確認其穩定性。

ping測試顯然是最常用的，一般來說，萬分之三以下的丟包率是完全可以接受的。但是不能只以ping測試決定，某些IDC會針對ICMP包進行專門的優先順序設定，所以還需要進一步模擬業務流量的HTTP測試等。

(3)電力供應

需要了解電流上限，這涉及到機櫃和主機的比例。另一個重要問題則是IDC的雙路電力是哪雙路，是否真的足以保證供電率。如果都沒有雙路，基本是不用考慮。

(4)空調散熱和機櫃密度
這個問題可能不太引起關注，但是溫度對伺服器壽命確實有影響。

(5)走線和環境管理

走線是比較能體現IDC工程師水準的一件事。通常根據這些小細節，可以推測出IDC的綜合實力。類似的還有出入證件檢查是否嚴格，是否提供鞋套、顯示器、鍵盤、推車和板凳等。

(6)其他售後服務

包括是否協助上架、是否可以7x24小時接收重啟服務電話、接電話到完成操作的響應速度、除值班電話以外是否還有應急聯絡人等。

 

3.BGP真偽的驗證

在IDC規劃和採購時，大家可能聽的比較多的一句話就是“雙線BGP接入”，甚至五線七線等。那麼這些宣傳的真偽如何?

其實我們可以通過其IP及AS好歸屬很簡單對比出來。

BGP真偽驗證可以參考這篇博文:https://hqidi.com/73.html

 

 

二、CDN規劃

在叢集規劃中，有一句話叫“快取為王”。這個思想，可以從作業系統底層設計開始，層層類推到網站叢集的總體規劃。

當然，這其中如CPU二級快取、RAID卡快取之類，我們通過對比測試發現其作用，並作出恰當的採購和維護即可。而在網路資料層面，諸如MySQL的query cache、InnoDB buffer pool,或者memcached、Redis等，多有賴於資料庫管理人員和後端開發人員，運維人員以配合為主，這裡不再贅述。從網頁伺服器之外，到使用者瀏覽器這一段，才是運維的主要戰場。這個戰場，又分為兩個部分:第一部分是瀏覽器快取,前雅虎首席效能官史蒂夫.桑德斯針對網站效能有一句名言，叫做"最快的HTTP請求是沒有產生請求"，就是針對瀏覽器快取來說的;第二部分是代理伺服器快取，在大規模網路環境下，這一部分可以擴充套件成為一個完整的內容分發網路（Content Delivery Network）。

關於CDN可以參考我的這篇文章:https://www.cnblogs.com/youcong/p/9607448.html

1.CDN原理

CDN的工作原理用一句話概括，就是將內容提供商的資料，以最快捷的方式分發到離使用者儘可能近的地方與使用者互動，以節省內容重複傳輸的時間。“網際網路高速公路的最後一公里”，正是對CDN的形象描述。

上面這句話中，有三個關鍵字，分別代表CDN技術中的三個關鍵點。

(1)內容資料:在早期網際網路環境中，80%以上的內容都是靜態文字，CDN技術近乎特指靜態內容加速。到如今，網際網路上提供的內容，在靜態文字和圖片之外，還包括各種動態生成的頁面、視訊、視訊碼流等。

(2)分發方式:從內容提供商到離使用者最近的CDN節點，資料流向可以由內容提供商主動發往CDN節點的，也可以是由CDN節點向內容提供商發請求下載。不同的分發方式，會導致CDN的效果、實現和管理方式，都大不相同。

(3)儘可能近:網際網路上的距離與現實距離並不完全等同。尤其在國內的現實環境中，同城網民跨網訪問都慢如蝸牛。這裡，我們需要對使用者的上網接入環境有所判斷，找到真正“近”的CDN節點提供服務。

CDN工作原理圖:

 

 

 

 2.DNS原理

DNS是提高叢集可用性的重要工具，也是CDN系統最常用的全域性負載排程工具。掌握DNS的原理和管理，是網站運維人員的重要職責。

(1)DNS的由來

在網路剛剛出現的時候，只有IP地址。後來出現主機名的概念，於是NIC（NetWork Information Center,網際網路資訊中心)提供了一個文字檔案供大家下載，檔名叫"hosts.txt",裡面儲存有整個網路中所有主機的主機名和對應的IP地址。每隔幾天，NIC就收集一次全網主機的資訊來更新這個文字，然後各主機的管理員們隨後下載這個文字維護新的主機名對映。同時這也是Hosts檔案的由來。

網際網路的先行者們大大低估了這個“怪物”的成長速度。IPv4的故事大家已經熟知，hosts.txt則更早碰到了天花板-沒人能維護這個飛速增長的主機名和IP地址對映關係。

所以為了規範網際網路上百花齊放的主機名，同時也為了構建一個可管理的體現，最終形成了RFC1034,DNS就此誕生了（這段簡要的概述，描繪了DNS的前世今生）。

 

(2)DNS的設計
DNS設計之初，提出瞭如下幾個要求?

(1)能夠指明網路地址、路由等資訊。

(2)分散式儲存(以確保資料正確性，在失敗時可以使用快取資料)。

(3)資料格式支援多協議傳輸,這裡指的是應用層協議,即FTP、SSH、RSYNC、SMTP等。

(4)支援多協議訪問,這裡指的是網路層協議，即TCP和UDP協議。

可以說，DNS系統，是全世界最早、規模最大的分散式系統。

(3)DNS組成

一個完整的DNS系統，由下面的三個元素組成。

a.域名空間和資源記錄

域名空間是一個樹狀結構。樹狀結構的每個節點都對應一個資源集(可能為空);每個節點的標記為0~63B；節點的域名由從節點到根的標記連線組成。

當域名的節點最多不超過127個，不過一般來說，實際軟體實現中支援的域名長度不會超過255B。

資源記錄是和名字相關的資料。

b.名字伺服器

伺服器端程式，用來保留域名空間和資源記錄，並響應相關客戶請求。一般名字伺服器只儲存域名空間的一個子集，以使子整合為這個子集的權威。一個子集內的資訊又叫做一個區，其他資訊通過其他名字伺服器查詢。

c.解析器

客戶端程式，可以訪問至少一個名字伺服器，接收這個名字伺服器返回的結果或者轉向其他名字伺服器查詢。

 

(4)DNS查詢過程

a.遞迴查詢

遞迴查詢可以用一句話來歸納："請對方辯友正面回答!",也就是說，客戶端請求必須得到名字伺服器一個"yes or no"的響應結果，然後完成這次解析。

一般情況下，電腦客戶端都會使用遞迴查詢。

b.迭代查詢

迭代查詢可用醫院諮詢臺做比喻。

進醫院看病的人，先到諮詢臺問:“我牙疼找誰看?”

諮詢臺會說:"你掛牙科號，上三樓右拐牙科分診臺。”

也就是說:伺服器端(諮詢臺)返回一個可能知道該域名(牙科)解析結果的名字伺服器(分診臺)，然後客戶端重新去那臺查詢。

注意:迭代查詢這個過程是可以累加的，因為本次獲得的這個名字伺服器，可能會繼續返回一個"可能"知道該域名的名字伺服器。就好像你到了三樓分診臺，按提示到了某診室，裡頭還有好幾個醫生，然後你要再詢問一次，才知道最後誰給你看病。

 

 

3.DNS查詢結構實現

 關於DNS查詢結構實現涉及比較多東西，後期會詳講。

 

4.DNS排程

(1)DNS負載均衡

因為A記錄可以返回多個，所以在LVS沒有誕生的中古時代，人們使用DNS做負載均衡的。不過這種負載均衡有很多問題:沒有健康檢查、沒有權重設定、沒有雜湊分佈、沒有故障轉移等。最重要的是，DNS設計中的TTL時間會導致故障發生時，即便運維人員手動干預，依然無法讓使用者的訪問路由立刻變更為最新狀態。

所以，DNS負載均衡至今依然是一項重要的應用，但絕對不是可信賴的負載均衡應用。

 

(2)動態DNS

所謂動態DNS，即針對相同的DNS解析請求，可以根據實際情況的變化響應不同的解析結果。

一類動態DNS以F5的GTM為代表，從公開文件中可知其首選排程演算法是RTT。但是我們注意到DNS首選協議是UDP的，只有在資料包大小大於512B和zone transfer的時候才採用TCP協議。而UDP協議並沒有RTT概念。由此可知，GTM是採用被動RTT方式來更新自己內部的動態路由表的。其工作流程大致如下:

a.NS返回一臺GTM的IP給LDNS，LDNS請求到IP;

b.GTM在就近路由表中查詢並返回離LDNS最近的解析結果;

c.如果路由表中還沒有LDNS所在網段，這臺GTM會聯合其他GTM共同對LDNS發起TCP請求，計算RTT並彙總RTT結果，從而更新路由表返回最近結果;

 

另一類動態DNS則是根據請求的IP地址對應的view做區分，幾個主要的DNS服務軟體如Bind9、TinyDNS、WINMyDNS都支援這種動態解析。這種動態解析的運維難點，在於如何收集足夠準確的IP段地址歸屬資訊，並保持定期更新。目前來看，主要來源有幾個:每月MaxMind的GeoLite資料庫、不定期更新的純真資料庫和自建DNS資料庫的請求日誌歸類分析。

 

5.其他排程方法

除了最常見的DNS排程外，CDN中還有其他排程方式，近年來比較常見的，是針對特定場景下的IP排程方式。

(1)視訊流排程

在之前對DNS原理的介紹中，我們已經知道採用DNS排程的最大問題，就是使用者配置的DNS是不受網路運維控制,因此帶來的解析偏差，會導致請求響應的跨網路長距離訪問。對於圖片或者頁面文字，結果可能是由十幾毫秒變成幾十或上百毫秒。而檔案越大，傳輸延遲效果會明顯。這對於視訊網站來說，是最不可忍受的事情。

視訊播放與頁面顯示不同，它是一個長期執行的過程，追求的不是瞬間的響應速度，而是長期的碼流穩定。一般的高清網路視訊(720p),碼流要求在4Mbps以上。如果伺服器距離使用者接入還要經過十多跳路由反覆接力，那效果肯定不如人意。

所以視訊網站，一般會使用IP排程來儘可能的解決這個問題，思路如下:

a.視訊播放器發出請求到網站的排程伺服器。這一步可以先通過DNS排程排程來降低後期運算和複雜度;

b.排程伺服器根據HTTP請求的來源IP，確認使用者接入的實際歸屬;

c.排程伺服器查詢實際歸屬地最近的視訊伺服器IP，處理原請求的檔案路徑部分,拼接形成實際的視訊播放下載地址並返回302響應;

d.視訊播放器根據得到的302響應，從視訊伺服器下載視訊播放;

 

(2)動態生成頁面元素連結

視訊流排程說的方法看起來不錯，但實際是有其侷限性的，它意味著原本一次就能完成的請求，被拆成兩次才完成。其中重新建連等時間是多出來的，在動輒上兆位元組(MB）大小的視訊請求中，TCP建連、Header解析等時間可以忽略不計，但是在一個頁面上有上千個只有幾千位元組(KB）甚至幾字節大小的小檔案元素請求的條件下，這個時間累積起來就非常影響使用者體驗了。

不過在大規模網站實踐中，對於頁面元素，也有一些變通的方法，可以針對特定情況來實現IP排程。針對頁面大量使用的某一類元素，比如使用者頭像、商品圖片等。因為其流量較大，重要性較高，原本就配備了專用的服務叢集。這些元素在釋出端不需要域名來做釋出路徑的對應區分即可提供服務。這時，我們可以把排程計算的負載，從圖片釋出的叢集轉移到動態頁面生成釋出的伺服器上。稍微改造之前提到的排程流程變成下面這個步驟。

a.瀏覽器傳送頁面請求到動態頁面伺服器,同樣這一步使用DNS排程來降低複雜度;

b.動態頁面伺服器根據HTTP請求的來源IP，確認使用者接入的實際歸屬;

c.動態頁面伺服器查詢離實際歸屬地最近的圖片伺服器IP，替換動態頁面模板的圖片檔案路徑的主機名部分，拼接形成實際的圖片下載地址;

d.模板編譯成完整的頁面內容後,響應返回給瀏覽器解析渲染;

e.瀏覽器直接根據圖片元素中的地址發起請求;

 

(3)BGP和anycast

anycast是一種網路技術，最早是1998年在RFC1546中提出的，意思是"主機向一個任播地址傳送資料報,網路負責盡力將資料報傳遞到至少一個,最好也只是一個，按任播地址接收資料的伺服器上。其設計初衷是徹底簡化在網路中尋找特定伺服器的任務。

從基礎概念上聽起來有點像後來大家熟悉的LVS。事實上anycast的幾個重要優勢，比如負載均衡、叢集冗餘和攻擊防護，也都是LVS提供的，不過anycast因為通常執行在路由器層面，所以它可以簡便地確定來源主機與目的主機組中的哪臺主機最近。目前，anycast技術最典型的運用就是公共DNS服務。比如我們所熟知的Google Public DNS,其地址為8.8.8.8.

在部署上，anycast對網路資源要求極高，一般需要有自己的自治域號，自治域內不同的路由器對應不同的上聯自治域，並採用BGP協議廣播相同地址，這個IP地址就是anycast地址。路由器後端，可以是直連伺服器，也可以是通過負載均衡叢集，或者仍然採用anycast方式聯絡伺服器。

anycast地址只能作為目的地址,不能作為源地址。因為每次報傳輸的實際主機可能都是不一樣的。這點，我們可以通過DNS解析測試驗證:配置8.8.8.8後,實際在DNS伺服器收到的localDNS地址並不是8.8.8.8.後來IPV6出現後，新的RFC2373中修改明確了anycast的定義。

 

6.動態加速概述
傳統的CDN系統，都是運用在靜態檔案加速上的，即便是視訊點播，也是flv檔案通過關鍵幀資訊科技切分成一個個小的靜態檔案。不過隨著技術和業務需求的發展，CDN系統也確定在慢慢出現針對動態業務的改進和擴充套件

(1)動靜元素分離

現在的網際網路應用，大多是富媒體形式，頁面中圖片、樣式、客戶端指令碼的數量和位元組數，都遠遠超過頁面載體HTML檔案。而頁面加速的根本目的，是為了給應用使用者更好的體驗。只有樣式符合預期的頁面，才是對使用者友好的、合格的頁面:只有頁面元素完整顯示，才是頁面真正載入完畢。

元素的本質變化分為兩個方面，一個是實時變化，一個是非實時變化。

一般請求下，實時變化的元素少數，非實時變化的佔大多數。將快取控制的範圍從CDN擴充套件到瀏覽器端時，很多可以快取幾秒鐘的元素，也可以歸入非實時變化的範疇。那麼，真正絕對不能快取的元素就更少了。

現在，更詳細地規劃原有域名拆分計劃，保證至少實時和非實時變化的元素不要在同一域名下發布。其次，讓過期比較敏感的元素，和不敏感的元素甚至永不過期的元素也在不同域名下發布。

在快取過期維度以外，域名拆分通常還有另一個維度，即平均檔案大小的差異。通常1MB以下和1MB以上的檔案，會拆分到不同域名，甚至可以更詳細到以100KB為界。這通常有快取效能方面的考慮。

這樣，頁面上的大多數元素，都可以通過普通的CDN技術完成加速。只剩下少量的HTML、JSON等資料，需要每次等待源站遙遠的響應。

動靜元素分離是至今為止加速動態網站訪問最基礎最有效的方法。

 

(2)動態頁面區域性更新

動態頁面最早期的實現方法是這樣的，在cgi中解析處理請求引數,通過資料庫處理返回值，拼接字串，然後返回最後的頁面結果。

稍後的實現進化成這樣:動態程式設計師解析處理請求引數,通過資料庫處理返回值後傳遞給模板系統,替換對應模板中的變數,生成最後的頁面結果並返回。

後面這個辦法，因為開啟了模板系統的本地快取，所以釋出伺服器響應效能可以提高很多。但是對於全網CDN系統來說，這些響應都是實時變動的內容,都無法快取。

a.SSI和ESI

動態頁面繼續發展，人們逐漸發現所謂的動態頁面中很多內容其實還是不變的，沒必要一次又一次地生成，於是，SSI在模板技術的基礎上被髮明出來。

使用SSI，動態頁面伺服器只需要生成變化內容的那部分頁面程式碼，然後由靜態頁面釋出伺服器，在響應請求時，通過SSI技術解析載入全部內容。這樣，動態伺服器的負載降低了，服務響應相對也就是更快了。

b.分級校對

ESI對頁面開發人員能力有一定要求，不太適合通用情況。在標準HTML程式碼的環境下，也可以通過一些辦法來盡力節約動態頁面的傳輸。

下面說下基於跨網高延遲條件的設計方案:

001.CDN系統分為邊緣節點和中心節點兩層;

002.邊緣節點收到使用者請求，發起回源請求到中心節點;

003.中心節點發起回源請求到實際的頁面釋出伺服器，並接收最新結果;

004.中心節點本地比對最新結果和上一個版本，得到一個補丁版本;

005.中心節點返回補丁版本給邊緣節點;

006.邊緣節點應用補丁更新本地快取檔案到最新版本，並返回給使用者;

 

(3)傳輸網路優化

Web2.0以來，使用者與伺服器端的互動比重逐漸增加，已經不再是一邊倒的下載流量，上傳流量的優化也成為了CDN系統需要關注的問題。

針對這一方面的問題，目前主要是對TCP/IP層做一些優化。TCP協議設計要求是針對普適場景，有以下三個特徵:

a.慢啟動

TCP初始滑動視窗較小，預設是3。然後在建連的往返過程中翻倍增加。

在網際網路接入頻寬動輒上10MB的今天，這麼小的滑動視窗初始值，顯然是一種浪費。

因為網頁元素本身較小，國內最大的CDN廠商藍汛曾經統計過其服務的全部客戶流量的總統計數，其平臺的平均檔案大小，只有4KB左右。

自Google首先提出這個問題，並將此初始值提高到10之後，這個做法已經逐漸得到廣泛認可。隨後，Linux核心從2.6.34版本開始可以通過IP命令直接修改這個引數，從3.0版本開始預設設定也提高到了10。

當然了，這個設定也不是萬能藥。其主要適用的是短連線和小檔案的場景。對自身業務是否會有較大地效能提升，還需要經過實際測試來判定。

 

b.以丟包判斷鏈路擁塞

主要考慮的是可靠鏈路上的擁塞問題，也就是說如果發現鏈路堵塞了，就減少小滑動視窗，慢一點發包，等擁塞解除再恢復原先的傳輸速度。

而事實中，在移動網際網路的環境下，更多的是行動網路本身的通道問題導致鏈路錯誤引起丟包，結果TCP的滑動視窗一直維持在比較小的狀態，整個資料傳輸陷入越傳越慢的惡性迴圈。從這個場景出發，對於行動網路，出現擁塞時更好的應對反而是儘快地重發資料報。

 

c.滑動視窗的加性增乘性減

在傳輸過程中，如果一切正常，滑動視窗會在每個RTT都加1,。但是如果發生擁塞時，滑動視窗直接減半。這種加減辦法對視訊播放等應用比較不利，一次瞬間的頻寬抖動，需要多幾倍的時間才能恢復到之前的傳輸狀態。

目前有很多商業產品在做TCP優化相關的工作。從部署架構上，可以分為單邊加速和雙邊加速。從協議原理上區分，採用的技術包括資料包快速重傳、滑動視窗加速滑動、ACK複製、合併資料包統一校驗等。

在TCP的擁塞控制演算法方面，Linxu2.6.8到2.6.19版本之間使用BIC，之後預設使用CUBIC。FreeBSD使用New Reno。此外，還有Vegas、HSTCP、FAST TCP、TCP SACK等。它們各自針對之前提到的三個主要特徵做了相應的修改，以適應其他環境。

比如Vegas和FAST TCP不再以丟包為鏈路擁塞的判斷依據而是參考發包佇列的長度;HSTCP則修改了滑動視窗的增減規則，當前視窗越大，增加速度相對標準TCP就越快而減少得也越慢;DataCenterTCP則通過帶有ECN（顯示擁塞通知)的ACK包的比例，動態確定滑動視窗的減少程度。

 

(4)SPDY簡介

在應用層上，也有各種對於加速的嘗試。比如HTML5協議中的WebSocket技術、HTTP協議1.1版本規定的Presisent connnection和pipelining技術、以及很可能成為HTTP協議2.0版本的SPDY技術。

現有的HTTP協議，存在幾個嚴重不足?

a.一個HTTP連線在同一時刻智慧獲取一個資源,而且一旦當前請求耗時比較長，後續請求都會被阻塞;

b.瀏覽器與伺服器之間只能是單向的,即瀏覽器主動向伺服器發請求;

c.Header資訊在每次HTTP請求中都要完整地傳送一遍;

WebSocket和pipelining也可以解決一部分上述問題。但是這兩種技術都要求對網頁進行較大程度地改造甚至是重寫。而SPDY目前則在HTTP協議前提下，通過SSL層的處理，實現了對原有頁面程式碼的相容。

主要來說，SPDY有如下特點:

a.採用多路複用技術，在一個連線上併發請求,而且細化到CSS等重要型別的檔案可以優先請求;

b.伺服器可以主動給瀏覽器推送資料以加強預載入的能力,最新的協議說明中,甚至列出伺服器可以給瀏覽器推送DNS記錄的待實現項;

c.在同一連線內，不用重複傳送相同的Header資訊，而且Header資訊還是通過壓縮方式傳輸的;

d.強制使用SSL以提高安全性。當然這個特點在社群討論中還屢屢被抵制;

從2012年以來，Google、Twitter、FaceBook、Amazon等網站都支援SPDY;而瀏覽器方面，Chrome、Firefox、Opera、Silk也都支援SPDY;伺服器方面，Google最早推出的是Apache的mod_spdy模組,F5公司隨後在其負載均衡產品跟進，Jetty、Nginx等也逐步完成SPDY的支援工作。可以說，SPDY的大規模使用，只等IE6等陳舊瀏覽器淘汰即可。

 

 最後還要說一下，本篇還要續篇，可以理解為下文，下文主要講快取和本地負載均衡。希望這篇文章能夠給大家帶來有益的啟發和收穫。