Old Driver 的自信，讓 CDN 加速再加速

CDN 的存在，加快了用戶的訪問速度，使用戶能夠在不提高網速下，得到更好的訪問體驗。購物時，能夠更快的顯示商品圖片；看電影時，能夠隨意的拖拽瀏覽。若是把數據資源比做是一件件包裹，那麼用戶的帶寬就像是一輛擁有最大容量限制的貨車。在未使用 CDN 加速前，貨車只能行駛在普通的道路上，被各類紅綠燈以及堵車所迫。當採用 CDN 以後，貨車就像是得到了 VIP 特權，駛上了高速公路，可以更加的通暢高效。

那麼是否有曾想過，如何讓這輛貨車可以行駛的更快一些，貨物可以運送的更快一些呢?

智能壓縮 - 將貨物打包得更小巧

在 HTTP 訪問中，資源壓縮一般須要客戶端和服務端二者的配合，例如用戶發起請求時，將會攜帶 Accept- Encoding 頭字段，來代表客戶端能夠支持的壓縮算法。而另外一端服務端，則須要識別該頭字段，同時選擇出一種支持的算法來壓縮資源，並返回給用戶 Content-Encoding 頭字段，代表服務端已經採用某種算法對資源進行了壓縮。

例如使用 chrome 訪問 http://Upyun.com 時請求頭中攜帶的 Accept-Encoding 頭字段：

與之對應的響應頭中，Content-Encoding: gzip 代表服務端採用的壓縮算法，Vary 頭字段則用於內容協商。

又拍雲的智能壓縮包括 Gzip 和 Brotli 兩大主流壓縮算法，支持 1-5 的壓縮等級。即便源站不支持 Gzip 和 Brotli 算法，也能響應出對應的內容，同時減小源站壓縮時的 CPU 消耗。

智能壓縮功能開啓後，文件大小變化能夠直接在訪問時看到。

302 調度-選擇更合適的路線

DNS 的解析錯誤會致使用戶的訪問出現較高延遲，例如用戶本能夠直接訪問上海節點，卻從山東繞一大圈返回到上海訪問，從而增長了用戶的訪問耗時，影響訪問體驗。

例如當用戶第一次訪問到廣東珠海時（圖1，2中的 113.106.98.34 節點），邊緣節點會根據內部準確的 DNS 解析出用戶應該訪問的節點（圖1，2中的58.222.18.2 節點），而後放置在 Location 頭字段中，客戶端接受到 302 響應以後，會訪問 Location 中的位置，從而實現加速。

須要注意的是：302 跳轉自己須要必定的消耗，所以只有當用戶客戶端支持 302 調整，而且資源均爲大文件的狀況下，開啓 302 調度，纔可以擁有較好的效果。

開啓方法十分簡單，只需在又拍雲控制檯中找到「性能優化」一欄，選擇其「HTTP 302 調度」功能，開啓便可。

頁面壓縮-擠掉貨物中的空氣

若是要運輸的貨物是一份蓬鬆的被子（塞滿註釋、重複的空白符的 HTML 文件），開啓頁面壓縮功能後，在 CDN 傳輸時，這個被子就像是裝進了真空壓縮袋， HTML 以及內嵌於 HTML 文檔中的 javascript 和 css 註釋、重複的空白符刪去了，頁面的冗餘內容大大減小，同時被子內容並未改變，只是變得更薄更小，傳輸效率大大提高。

視頻拖拉-拆開便是精彩

打開控制檯的視頻拉取功能，含有關鍵幀的 MP4 和 FLV 格式文件，便可隨意掌控視頻播放控制條， FLV 支持按字節拖拉，MP4 按照時間拖拉。由此擴展，只需讓播放器發起約定格式的請求，例如 http://example.com/video/test.mp4?start=20&end=30。這樣在視頻播放時直接就能從 20s 的位置開始播放，並在 30s 位置結束播放。客戶在收到包括一打開的瞬間，看到的就是發貨人準備的精彩內容。

在 CDN 這條高速公路上，還有許多網絡建築師準備的優秀方案，像是可以明顯減小圖片體積的 WebP 自適應功能，優化視頻體積大小的窄帶高清功能等，讓大貨車在 CDN 這條高速公路跑的更快，更穩。

瞭解更多：

雲分發 - 快速穩定內容分發網絡CDN