說明：本文內容來自門戶taobao團隊，爲老男孩linux運維實戰培訓教學案例之一
我現在在杭州的淘寶研發中心，在對康伯做採訪。康伯先跟我們大家介紹一下你自己，包括你的團隊。
大家好，我是康伯，這是我花名，我的真名叫XXX。我的團隊是負責整個淘寶的CDN的建設、運維。
我們也知道，這一次淘寶“雙十一”事件，其實CDN這一塊也面臨着非常大的壓力。我們想了解一下，在這個事件之前，你做了什麼樣的預案？在整個的事件發生的過程當中，預案和你整個的一個實際的情況有哪些比較大的差異？
我們第一時間知道這個活動的時候，就對我們的系統做過一些評估。當時，我們預計流量會增長大概30%左右。在預案中認爲我們的系統是有30%的餘量的。但是我們覺得30%是不太夠的，我們臨時採取了一些措施，比如說去擴了一些性能不太好的一些點、內存，又去到上海又去臨時建了一個點，包括在杭州的一些地方，我們都去臨時增加了一些資源，把整個系統這個能力擴大到了50%左右。
老男1孩點評：上面內容是對即將到來的流量的預估，未雨綢繆，這是我們做運維的要特別注意的，預留資源，不要可丁可卯，在預估的流量基礎上又加了很多服務點，比預估的流量多20%-50%的流量準備，贊！那麼是不是夠用了呢，我們繼續往下看。
但是還沒有到這天活動的時候，我們就發現我們的這個預案做得不夠，活動開始前的一天，流量就已經衝到了一個新的高峯，在這基礎上，雙十一這天流量就會達到我們當時整個設計的一個頂峯值。如果這樣就意味着我們的服務質量可能會下降，可能會放棄一些用戶。針對這些情況我們又臨時調整了預案，比如說是否要臨時的放棄一些用戶，或者說再增加一些節點等。
老男孩點評：當預估不足時，就考驗網站的架構健壯和團隊的臨危應變處理能力了。在高併發高流量時，放棄一些用戶是不得以的做法，但有時也是必要的，否則整個服務質量會極度下降，甚至發生雪崩。壯士解腕雖不可取，但有時是不得以而保全大局的辦法。當然，正確預估提前做好準備是最重要的，臨時的加點（後備資源）能力也是需要具備的。注* 成語：壯士解腕 勇士手腕被蝮蛇咬傷，就立即截斷，以免毒性擴散全身。比喻作事要當機立斷，不可猶豫不決。“壯士解腕”的措施要提前請示相關領導，以免造成其它餓果。
這裏老男\孩舉個戰爭的例子，也許關係不大，但還是想說下。話說大將軍衛青帶領大兵深入匈奴腹地尋找匈奴主力打擊匈奴，漢武帝在甘泉宮（遠離國都的一地名）指揮作戰，原投降漢朝的將領趙信部又再次投降匈奴老大依志斜單于。由於衛青的軍隊都是精銳，很牛，匈奴不敢正面作戰，正無計可施，趙信想起來一條通往甘泉宮的小路（老鷹澗，曾經和衛青一起走過），只能一人一騎通過。於是建議依志斜單于派兵3000，他來偷襲甘泉宮活捉漢武帝。從此路走，一夜即可到達甘泉宮。
這一招非常要命，幸好衛青提前獲得了趙信部隊奔襲老鷹澗的消息（一個獵人彙報的），但是，回師是不可能了，因爲，大部隊輜重人數多，距離又遠，無論如何一夜趕不回去，而且，大軍回師，匈奴主力會乘勝追擊，也非常危險。
於是，衛青採取了一個不得以的被動方案，大兵原地不動，把兵權交給身邊的將軍，只帶着飛將軍李廣兩人快速返回。兩人回去怎麼能抵擋匈奴3000大兵呢，皇帝的身邊就幾百人護衛。
這是因爲衛青知道唯一能救駕的的軍隊就是，距離甘泉宮比較近的烈士後代組成的還未上戰場的娃娃軍，約3萬人，但是這部分人必須有漢武帝的親昭纔可以調動。
衛青星夜趕到娃娃軍駐紮地，說明緊急情況，皇帝危在旦夕，仍然調不動這部分軍隊。情急之下，衛青拿出了當年太后調兵的虎符（這是調兵的最高信物），結果調動了這3萬大軍。於是，趙信匈奴部馬上奔到甘泉宮時，正被衛青堵個正着，趙信一看漢軍早有準備而且人多，灰溜溜的撤走了。
這時衛青趕到甘泉宮見到漢武帝說明情況，結果被漢武帝一頓質問：
a.不在前方指揮軍隊，爲什麼不打招呼，而擅離值守？---> 這在漢代是重罪。
b.你是怎麼調動朕的娃娃軍隊的--->前面已敘述，這個軍隊必須皇帝親自下昭才能調動。
結果，衛青雖然救了駕，卻被漢武帝收回了調兵虎符，有意無意削奪了兵權，冷落了好幾年。
臨危時，最能考驗一個人的水平和魄力了，從衛青的思想看，這次救駕是無可指責的，是有功勞的；可在老大看來，卻是另一個想法。救駕雖好，但讓老大看到了權利危機。衛青今日能調動軍隊救駕，明日就有能力調動軍隊造反。是不是很可怕，如果你是老大，你覺得是不是？
本例意在說明：
a.重大事情考驗一個人的真正能力和魄力。
b.事前要先申請，事後要回報，這個是做下屬必須要遵守的，否則，後果不堪設想。
c.面對最緊急的問題，你覺得做的很好，但老大未必滿意。相反，也許老大的反應也許不是你想得到的結果。
d.知己知彼，未雨綢繆是重中之重，是成敗的關鍵，兵法裏是，網站運維也是一樣的。
e.很多事情只能有舍有得，無法兼得，衛青冒着丟失性命的危險，去救老大了。是個好員工。運維工作也有很多這樣的情況（如網站宕機了，需要做調整，是先搞定還是先申請？），人生何嘗不是如此。會做的也要會表現才更好，方式方法要得當。不是對的就能做的對。在培訓中老\男孩老師特別在意給中心的學生介紹這些經驗，這些也許比技術本身重要的多。
在雙十一的一早，我們就發現了，情況比我們預想的還要複雜。當時那天早上九點的時候，我們就發現流量就已經竄高到了整個設計的極限值。按照我們的經驗來說，晚上比早上的早高峯還要高30%的，那等於說我們整個系統缺少30%的能力來支撐。我們馬上採取了很多措施，最主要的簡單說來就是開源節流，當時第一反應就是調動的所有資源投入到CDN系統去，保證它不出問題。當然前面介紹到說我們可能會放棄一些用戶，但那是我們到了不得已的時候才採取的措施。事實證明我們當天做完一些措施之後，就沒有去用這種極端的措施。那我現在來說一下當時我們主要做些什麼：第一個在杭州，我們可以調動資源的地方，及時的去增加資源，這樣在晚上高峯來臨之前，我們能多餘出
老男|孩點評：在選CDN時，除了質量等關鍵信息外，要求機房能臨時快速增加帶寬也是談判的內容（合同裏要有，平時流量不太高時就請機房開帶寬演示下，不要讓合同成了廢紙，到用時沒資源或者不理你），很多同學問我DDOS如何解決？讓機房臨時加帶寬就是個辦法，當然，自身的架構也要能頂的住。這點taobao做的確實很棒。能短時間調動10幾G的帶寬。可能你會說，taobao是大客戶受重視，這是一方面，他們調用這麼大的帶寬資源，不光是客戶大小，事先在各種準備上也一定做到了位。2贊。
補充3篇DDOS解決相關文章，
1）DDOS***17條經驗 http://oldboy.blog.51cto.com/2561410/845349
2）輕鬆應對IDC機房帶寬突然暴漲問題 http://oldboy.blog.51cto.com/2561410/909696
3）千萬級PV/IP規模高性能高併發網站架構http://oldboy.blog.51cto.com/2561410/736710
另外一個在業務方面我們採取了一些節流的措施，來保證這些壓力不要一下子衝到我們CDN上來，比如說我們的活動頁面是非常大的，上面有非常多的大圖，我們發現這個活動頁面給我們的流量壓力帶來非常大的衝擊。我們就及時找UED的同學去做優化，把頁面儘量優化縮小又不影響用戶感受。比如說延遲加載，當用戶打開頁面的時候，先顯示首屏的一些圖片，底下還有六七屏的圖片只有在用戶往下拖動的時候纔會顯示出來，這樣我們節省了很大的流量；包括在我們一些上線詳情頁，也是採取了同樣的優化措施，保證用戶訪問感受的同時，保證我們的CDN不被壓跨。
老|男孩點評：平時給大家培訓講課時，大家想不到這樣的場景，這麼大的門戶還會去找UED壓縮圖片，今天大家相信了吧。優化高訪問量圖片和延遲加載是很好的手段。小平同志說，黑貓白貓，抓到耗子的就是好貓；老男孩也說，黑方案白方案，能解決問題的就是好方案。在老男孩曾經的運維生涯中，也多次遇到過類似的問題，一張圖片幾百K，不到一日就產生近20T的流量，帶寬佔用過G，後來把圖片優化爲10K，流量瞬間驟減數十倍。
這裏也順便提下，前端優化都網站來說非常重要，如：apache和nginx的expires功能
優點：
1)提升用戶體驗（用戶訪問速度快了）。
2節省網站的帶寬流量。
結果：既提升用戶體驗了，公司也少花錢了！
當使用了expires功能後，當用戶訪問了一次資源後，在expires時間過期之前，
就不會在去服務器下載該資源了，除非用戶瀏覽器端主動清空瀏覽器緩存。
那麼就會有一個問題存在，如果網站更新文件後，用戶再訪問時的內容還是舊的（上面已提到不會在下載了），怎麼解決這個問題？
解答：
1)首先，對於大多公司業務來說，圖片等資源一般很少會去修改。因此，taobao,360buy等公司可以肆無忌憚的把expires設置爲10年。一年節省費用可能是上億人民幣。最重要的還有提供用戶體驗。
2)對於js,css偶爾會變化的資源，一般expires設置時間會比較短。如1-30天，或則，在更新上採取策略， 如，更新後以新的文件名發佈，這樣對於用戶又是新的資源了。
3）特殊緩存，google首頁expires一日（經常會變更圖片），網站的js統計代碼不會設置緩存，
如http://www.baidu.com/js/bdsug.js?v=
當然其他模塊也有同樣的功效：如apache的壓縮模塊mod_deflate。
更多的前端優化，參考老男孩的培訓視頻或相關文檔，大的方向可以參考yslow的14條。
再之後呢，我們發現流量的增長還是比較猛，我們又採取了一些其他的措施，比如說我們臨時把某些頁面的大圖換成小圖來節省流量，因爲大圖原來在CATCH前端都是存在的，如果把它換成小圖，就涉及到這些圖片可能要全部重新生成一次，對於源服務器的壓力是非常大的，我們就採取了逐步切換的方式，先切換一個流量比較小頻道，然後上線，觀察這個對後端的壓力，在看到這樣對我們後端基本沒有什麼太大沖擊的情況下，我們再逐步的把一些頁面全部換成小圖。但是我們仍然在我們的搜索的頁面保留了大圖的功能，用戶在需要看大圖的時候，還可以切換到大圖，這樣一方面節省了CDN的流量，保證我們的服務能力，另一方面也保證我們用戶仍能得到一個高質量的訪問。
老|男孩點評：這些是更細緻的圖片細節上優化。講的非常好。老男孩曾經就這樣幹過。這是被逼無奈了。曾經一個朋友蹲拘留所了，後來我拖了關係把他搞出來了，跟我說，裏面的窩頭真好吃。湯也好喝。原來硬的象石頭一樣的窩頭，和芥水一樣的湯，都說很好吃好喝。因爲，在裏面餓的沒得吃，就是這些還搶着吃。還帶回來一個窩頭當給大家展示，讓我哭笑不得。
在採取過措施之後，晚高峯的流量也是被我們做過這些控制，還保持跟早高峯差不多。實際上等於我們一天節省了30%左右的流量。但在這個過程中還會有很多問題，因爲我們的用戶的分佈不均勻，比如說在大的省市，流量的增長非常迅速，那爲了保證這些地方的一些用戶，我們可能會使這些地方的用戶訪問慢一點，但是我們保證了圖片的正常顯示；我們讓他去訪問周邊的地方，比如說上海可能會到浙江來，廣東的我們會讓他去到廣西這樣的一些措施，然後保證整個訪問質量不受太大影響，而且保證了我們的服務能力。
老男孩點評：中等規模以上的網站，架構的好的，都要具備全局調度的能力，簡單就是一個機房一個地區的調度，複雜的就是全局的DNS全國各個市調度，就象指揮千軍萬馬打仗一樣，將“敵人”的大股力量分化瓦解到不同的城市節點，逐一“消滅”，那才叫爽。雖然切換到非用戶所在地，犧牲了一些用戶體驗，但換來了，整體“戰爭”的勝利。3贊！
那經過這麼多優化措施之後呢，我們那天是整體上是承載了一個比我們平常多了50%的流量，或者說在我們不做那些降級的優化措施的情況下是的80%增長的流量，在這樣一個突發的情況下我們做到了。
其實這個事件的背後也是和其他的團隊同力協作最終達到一個的結果，假設當初不和UED部門去協作的話，那你可能沒有辦法把這一塊的流量給降下來。另外一個感觸就是謝天謝地，總算雙十一事件沒有出現宕機等情況。那其實根據我們的瞭解，這也和整個CDN優化團隊在過去一年的技術積累是非常相關的？
對，是這樣的，在2010年初，我們CDN的流量還是比較小。那到了今天這個流量已經增長了四倍。雙十一那天，與年初相比增長了大概六倍左右，這在我們以前是不可想象的。因爲面對這樣一個增長，可以說是一個爆發。如果我們不做優化，系統可能今天就會出現各種各樣的問題，特別是面對雙十一這種高壓的情況下。
我給大家分享一下，我們在這一年裏都做了一些什麼樣的優化。實際上對於我們整個系統來說，淘寶的CDN可能跟其他公司它的CDN面臨的問題不一樣，淘寶面臨的是一個我們有巨大的商品數，和隨之而來的巨大的圖片量。這些圖片量的訪問熱度又不像一般的CDN那樣非常集中，因爲有很多的商品，只有用戶訪問了十來次，幾十次，這樣對於CDN本身效果是不太明顯的。
我們年初的時候有一個很大的挑戰，我們舊的架構下邊 CDN的命中率越來越低，最低的時候都已經降到了85%左右。實際上這樣的話，帶來的難題就是，我們的源服務器和二及CACHE的服務器能力要求非常高，那投入會非常大；另外就是，我們本身是希望CDN能加速用戶的訪問，但是一旦命中率比較低的時候，大量的回源反而會拖慢整個頁面的訪問速度，這樣是我們不可接受的。
我們採取了一些優化手段：比如說我們原來對於圖片的大小是沒有預期的，年初我們的CDN開發團隊，加上我們運維，對我們的訪問做了一些詳細分析，分析出到底現在這些圖片它是多大，佔多大的流量比例，預估了一下，如果我們要求命中率提高到96%、97%，會需要多大的存儲空間。之後我們對架構做了一些改變，我們發現我們做到了命中率基本在96%、97%左右，這對於我們整個前端頁面的響應速度是一個非常大的提升。
另外一個就是我們在之前用的是Netscaler或者F5這種硬件的這種負載平衡設備。這些硬件負載平衡設備有一個很明顯的瓶頸，就是性能可能一般只跑到六個G或者七個G，那就不會再增長了。如果要再增長，就需要再加一套設備，這是一個非常大的投資。
還有一個問題是它們的一些算法有問題，我剛纔介紹說，我們有非常多的圖片的，在這種情況下，一臺機器存的圖片量不可能特別多，比如說我們只能存到三千萬張圖片。但是對於整個淘寶的圖片來說，我們有兩百億張。那三千萬張對於兩百億張這是很小的一個基數，而且我們又沒有熱點，那基本上來說這個命中率就降的非常多。那我們怎麼應對這個問題？我們就需要做一些七層的URL 哈希的動作，就是說同一份圖片我們只存在一臺機器上，這樣每個節點有30或者40臺機器的話，就等於我們有可能存了有12個億，那我們就佔整體量可能有10%或者20%的圖片來提高命中率。
但在這種情況下，硬件的一些算法又會有一些問題，最常見的比如說原來有30臺機器，我現在要加10臺機器進去擴容的時候，會發現原來所有的圖片都失效了，全部要重新去緩存一遍，這對我們是一個非常大的衝擊；另外一個情況正好相反，就是說我壞了一臺機器時，也會發現同樣的問題，這是我們不可接受的。我們的CDN開發團隊就創新性的用了一個軟件來解決這個問題，在整個架構中，把硬件負載平衡減掉，去掉了硬件的性能瓶頸，然後用LVS這一套開源的負載均衡來做這個調度，使我們的整個節點的性能一下子提升了一倍。
就像我剛纔前面說到的，某一個節點在活動的時候跑到過
老男孩點評：這部分講的非常好，雖然很多公司也是這麼做的。4贊。在2009年初的時候，老男孩linux培訓課程中就開始加入了lvs/haproxy 4-7層架構，這是一套非常不錯的架構。L4DR模式支持大併發，L7層可以橫向擴展，對於象taobao的CDN，可以採取多個圖片域，多VIP（可在DNS層控制），然後採用多組L4-L7，而不是大家想象的就兩臺LVS而已。一致性哈希是大規模CDN的重要算法，尤其是解決宕機機器和新加機器的問題，在2009-2010期間，好多老男孩的學生去taobao面試都被考了同一個問題。大規模的百億張圖片數量如何存儲類似的問題。
比較遺憾的是該篇內容沒有透漏技術細節。有興趣的可以加老男孩一起交流。
特別說明：哈希或一致性哈希是前端CACHE負載均衡常用的手段。
我們又做了很多其他的優化，比如說對於HAproxy我們去做客戶端的keep alive，也就說長連接來減少用戶建立連接的時間，這樣平均每個請求可能會減少幾百個毫秒，還有一些優化，就是說我們前面說的我們Object非常多，大家都知道，做Cache的時候，實際上很重要的就是命中率的提升。如果說熱點相對集中，我們是可以直接把它放在內存裏邊的，如果內存放不下，我們就會到硬盤上去找。但是傳統的硬盤性能非常差，比如說傳統的SAS盤，我只能撐到一百多到兩百的IOPS。對於整個節點，一兩百的IOPS是不能滿足要求的。所以我們就引入了SSD，但是SSD的成本又非常高，我們的開發團隊發明了一套算法，把那些訪問很集中的一些東西放在那個SSD盤上，因爲SSD提供很好的一個讀性能，我們就讓這些80%左左右的這種讀從SSD上產生，剩下的圖片我們把它放在傳統那種SAS或者更低廉的一些SATA盤上，這樣我們整個節點的性能非常好，單機可以支撐三千到四千IO，這是我們系統沒有任何顯示出訪問慢，或者其他不好的表現。
因爲每臺機器的成本又降得非常低，如果可以，比如說追求一個大的存儲，我可以用全SSD，但是我SSD的成本相對要高很多，我可以用比較廉價的SAS或者SATA來存一些訪問頻度不是很高的，用SSD存訪問頻度高的文件，這樣整體上的性能就協調的非常好，成本也非常低。整體上可以這麼說，我們通過這樣一年的優化，在原來硬件基礎上投資50%實現了性能是原來兩倍的一個架構。現在我們總體的這種TCO是原來的1/4左右。
老|男孩點評：熱點數據存儲的思路非常好，我在培訓時講到磁盤組成及原理的課程時和存儲問題時，有關熱點數據，必須要舉的一個案例就是taobao的這個熱點存儲思路。現如今看來，對很多中小型公司還是很新穎的存儲方式。順便說下，大公司無論做什麼都要考慮性價比問題，而不光是要把問題解決，因爲，設備的奇數太大，做一點點就會節省非常多的成本。阿里，聯想的大規模的雲計算其實歸根結底都在解決性價比問題，否則，就無法推向市場，真正的應用到商業市場中。
這個數據還是比較驚人的，在簡單回顧一下，在整個優化過程中，有沒有遇到特別困難的地方？
特別困難的話，實際上對我們來說，仍然是在這個我剛纔提到的，沒有熱點，數量是非常多的情況。沒有熱點，就意味着我們要儘量多的把圖片存到前端，我們在做URL哈希的時候，實際上是面臨了很大的問題，我剛纔也提到SSD，現在的規格只有
在接下來的兩三年的時間，對於CDN團隊來講，主要的工作可能是什麼？ 前面我們說到，就說整個一年除了架構以外，我們還做了很多工作。我們流量在漲到可能有四倍到五倍，這個就不光是去優化軟件就能實現了，我們還做了很多部署的工作。
下面第一個，我們還是會大力的推進布點的情況。我們現在在全國有30多個點，基本上都分佈在一些省會城市，或者說一線城市，比如北京、天津、上海、廣州、杭州和其他省會城市。明年我們希望把這個點數量做到100個，這樣我們就會覆蓋大部分的二線城市，比如說像溫州、嘉興，或者東莞這種流量比較大的城市，後年規模可能會再擴一倍，到兩百個點，這當然只是我們現在的一個期望。到時候我們可能說，每一個市我們至少有一個點，當地用戶都去訪問他本地，達到一個最快的訪問速度。
另外一個方面，實際上我們現在在做很多其他內容的CDN嘗試，比如動態的或者說HTTPS加速，或者說視頻。因爲大家知道靜態內容，放到每個CDN節點是比較容易的事情，但是我們淘寶的一個業務，整體上所有走交易的流程都是在杭州本地完成的，一些偏遠的地區，它到杭州的網絡質量還不是特別好，我們希望把這些動態內容也能通過我們的CDN技術去加速，讓這些邊遠的地區也享受到比較快的訪問速度； 對於HTTPS的需求，這塊我們更多的一些是跟交易相關的流程，我們是希望既享受速度，又享受安全，所以這要就有HTTPS的請求；另外我們現在雖然大力的推廣，讓賣家把這些圖片都放到淘寶本地來，用我們的CDN給賣家提供優質的服務，但是我相信視頻還是一個方向，比如說我們去買一件衣服，我們看到有一段視頻的話，用戶感受跟我去看一個死板的圖片，肯定是不一樣感受，這也是我們要努力去做到的一個方向。
是不是可以暢想在未來的兩三年，我們廣大的包括農村地方的，或者三線城市的那些人民，他們購物的時候也會更快？
對，這是我們CDN團隊的使命，我們要讓全國所有有購物需求的人，在訪問淘寶的時候都要最快。
這是非常美好的一個願景。最後一個問題，在現在淘寶網，當然它的很多方面都走在了前面，包括我們CDN的一些優化，那其他的可能有一些比較小的團隊，也在從事電子商務方面的一些工作，也可能有自己的網站，他們也可能面臨非常大的問題，你作爲一個比較有經驗的CDN團隊的負責人，能不能給他們提一些建議？
那我大概說一下，這個建議是我的一面之詞，實際上對於每一個網站來說，CDN都是有需求的。做CDN的同行，要更多的去關注業務，因爲我們很多做技術的人，會限於這個技術的壁壘裏面，他只會去考慮技術，不會考慮業務。通過不管是雙十一事件，還是說我們整個一年的CDN優化路程來看，我們瞭解業務是必要的，包括現在我們對有些業務不清楚的地方，也阻礙着我們CDN的發展。業務非常重要，包括我們雙十一的時候做的一些措施，比如圖片的延時加載，大圖換成小圖，又保留大圖的功能，這樣都是在非常熟悉業務的情況下做出的一個決定。
如果我們不熟悉這些業務，我們當天肯定做不出這些決定來，沒法應付這麼大的流量；另外你瞭解了業務，你才能夠去做好你的CDN，讓你的CDN發揮最大的用途，你知道你的業務需要什麼樣的CDN；另外一個希望我們淘寶的CDN以後可以爲大家服務，我這打個廣告，淘寶的CDN現在具備給其他網站提供服務的能力，那我們希望把淘寶的先進技術開源一部分到社區去，我們前面提到的一致性哈希的算法，或者說對於HAproxy的改進，我們都會開源到社區去，希望同行業會用到這些技術。另外一個我們會大力的去建點，我們也希望，到時候我們可以跟這些網站合作，讓他們把一些內容放到我們這邊來服務。
非常感謝康伯接受我們的採訪，我們也希望CDN團隊能夠再接再厲，給我們廣大的網民提供更流暢的服務。謝謝。
老|男孩點評：感謝馬雲，感謝康伯，感謝爲此文付出的所有的朋友們，沒有你們就沒有這篇優秀文章的誕生。
阿里集團的團隊在國內是非常棒的，在很多技術領域都走在了前列，更可貴的是把自己的技術經驗開源，在此，我代表廣大的國內技術朋友們，對你們（阿里集團團隊）表示真摯的感謝！希望你們能開源更多的技術和產品。這是利國利民的好事。
有的朋友問CDN的原理，可以看下老男孩的相冊，有原理圖。