以前說CDN的優勢是其在網絡邊緣緩存了用戶請求的內容，離用戶近，從而保證用戶的訪問效果;但是動態網頁由於是源站動態生成的內容，CDN的邊緣節點無法存儲用戶請求的內容，請求到了邊緣節點之后還得回源，傳統CDN架構上的優勢就沒有了。那么cdn動態加速還沒有價值?首先讓我們看看cdn動態加速技術是怎么樣的：
讓我們看以下公式：
用戶請求耗費的時間=用戶和邊緣交互的時間+邊緣等待的時間;
其中用戶和邊緣交互的時間，我們可以看做用戶向邊緣請求一個靜態文件的時間，邊緣等待時間，是用戶請求到了以后，邊緣需要向用戶發送數據，確沒有數據可以發送，等他數據到達的這段時間;CDN動態加速技術的本質主要是要減少第二部分的時間;
首先我們說，通過網絡優化和協議優化，我們可以容易的把上面那個公式變成下式：
用戶請求耗費的時間=用戶和邊緣交互的時間+1*RTT(邊緣到源站)+源站的反應時間;
讓我們忽略掉源站的反應時間，因為他和我們今天討論的動態加速沒有關系，我們可以把它看做一個常量;
Ok，讓我們看看，這是怎么做到的，首先讓我們看看，不優化的時候是個什么情況，如圖1所示，最壞情況下邊緣等待的時間 = 建立連接的時間(1*RTT)+發送請求的時間(1*RTT)+數據傳輸中的等待時間。
其中通過優化我們可以把建立連接的時間消滅掉，有兩種發送可以做到這一點：
1. 通過連接復用，保證每次動態請求到達時，邊緣和源之間的通路，連接都已經建立了，它的弊端是在突發情況下很難保證;
2. 通過TCP協議棧的定制，把連接和請求的過程合並起來，這事我們在09年就一直在說，只不過由於種種原因沒有做下去，據說google已經做出來了;
除此以外我們還可以把數據傳輸開始以后的等待時間給去除掉，這里面涉及到了兩個技術，一個是動態路由，一個是TCP協議優化;
動態路由：所謂動態路由，指的是利用CDN節點多的優勢，把每個節點都看做一個路由，在邊緣A和源B之間找到一個最佳路徑，也就是說以前是直接從A到B，變成了A-C-D-B;另外還需要強調的是，D-B之間一定是要通過連接建立，而且D-B一定要很近，時延很小，否則的話TCP協議優化就發揮不了作用;通過動態路由技術我們可以在A-B間建立一個更低的RTT和更小的丟包率的通過;
節點間的TCP協議優化：有了動態路由做保證，節點間的TCP協議優化就是很簡單的事情了，我們要知道用戶的帶寬往往是有限的，而節點間的帶寬往往是冗余的，我們要做到節點間的發送速率高於邊緣到用戶是非常容易的，改幾行代碼就夠了;
通過以上一些技術我們就可以把圖1精簡成圖2：
這還不夠，我們能不能把這一個時延也去掉呢，這是部分可能的，這里面涉及到了一下一些技術：
1. 緩存，部分的動態內容也是可以在很短的時間內緩存的;
2. 預取：通過用戶請求的頁面內容解析，預先感知用戶接下來要獲取的內容，提前預取;
3. 在邊緣生成用戶請求的內容，這個水太深，我說不清楚，點到為止;
4. 證書類：通過在邊緣部署SSL證書，在邊緣將SSL請求，變成普通請求，從而將動態加速變成靜態加速，但是如此是有風險的，把CDN運營商看成安全是不安全的;
除了以上一些技術以外，我還漏了一個，那就是壓縮，壓縮分成兩部分，一部分是http頭支持的壓縮，這些就不要讓CDN幫你干了，源站應該自己做的;另一部分是CDN節點間的，如此可以減少CDN節點間傳遞的數據量，從而變向加快傳輸速度;但是這里會增加機器的CPU負載，同時，有了TCP協議優化技術，不需要通過壓縮來提高傳輸速度，所以個人認為它不重要。