網站運維技術與實踐之集羣架構規劃

集羣架構規劃和設計只要是涉及到高併發高流量的項目，基本上都須要。

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

1、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

 

 

2、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服務軟件如Bind九、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等陳舊瀏覽器淘汰便可。

 

 最後還要說一下，本篇還要續篇，能夠理解爲下文，下文主要講緩存和本地負載均衡。但願這篇文章可以給你們帶來有益的啓發和收穫。