圖片流量節省大殺器：基於CDN的sharpP自適應圖片技術實踐

閱讀原文，不少其它技術乾貨，請訪問騰雲閣。

眼下移動端運營素材大部分依賴圖片，基於對圖片流量更少。渲染速度更快的訴求，咱們推進CDN。X5內核。即通產品部共同推出了一套業務透明，無痛接入的CDN圖片優化方案：基於CDN的sharpP自適應圖片無痛接入方案。據統計效果可在原圖基礎上節省60%-75%的流量，比以前webP無痛接入方案效果提高40%-50%，下降流量的同一時候提升頁面渲染速度。提高用戶體驗。

效果數據

眼下手Q增值業務：VIP中心、遊戲中心、動漫、遊戲公會、特別關心 以及增值渠道的QQ錢包，空間的個性化商城已經接入sharpP自適應，優化效果數據：

sharpP自適應方案在原有webP自適應方案效果提高40%-50%，提高效果主要來自sharpP高於webP的編碼壓縮率。同一時候能優化到webP沒法覆蓋的png圖片（備註：以前webP無痛方案僅僅實現了jpg的支持），sharpP方案和原圖對照可以節省60%-75%的流量。

以咱們的VIP中心爲例，以前webP方案：

上sharpP方案後

在圖片添加的狀況下 圖片流量下降了近100K，頁面速度也有提高，並且sharpP圖片的效果也通過設計同窗的驗證。肉眼差點兒沒法區分，圖片質量參數細節後面會介紹。

方案概述

利用自建CDN結點的緩存，以及帶請求頭的回源能力作到同一個URL依據終端分辨率，以及是否支持sharpP解碼。按需返回不一樣的原圖副本，作到圖片資源的最合理利用：
手Q X5內核支持sharpP圖片的解碼，請求圖片時會帶上accept: image/sharpp標識，User-Agent中會加上手機的分辨率Pixel參數，CDN節點收到請求後，先檢查假設有相應的sharpP自適應副本直接返回。假設沒有則將請求回源到CDN源站，源站會依據請求的User-Agent、Accept參數返回相應分辨率的sharpP圖片副本(原圖上傳後，或第一個用戶請求觸發CDN源站server圖片轉換，生成不一樣尺寸的sharpP圖片), 假設請求頭沒有sharpP標識，則按原有邏輯返回原圖，不影響業務。

整套優化方案接入對基於X5內核的H5業務全然透明，無需修改代碼，就可讓頁面的圖片得到可觀的圖片專項優化效果；app業務接入，音視頻有提供sharpP解碼的sdk的接入。

方案具體解釋

1.何爲sharpP

sharpP是騰訊公司SNG即通產品部音視頻技術中心推出的一種圖片壓縮組件，現已支持iOS、Android、Windows、Linux四個平臺。

編碼壓縮率、編碼耗時、解碼耗時相比webP有明顯的優點。

2.CDN sharpP方案

在原有webP自適應無痛方案基礎上，咱們聯合終端、CDN進一步升級優化。作了例如如下優化改造：
終端支持：增值業務大部分是基於手Q webview的hybird應用，安卓平臺基於X5內核，X5內核於2.1.1版本號開始引入了sharpP組件，支持sharpP解碼，並約定支持sharpP的版本號發起的請求會在http請求的頭部帶上Accept: image/sharpp字段，同一時候X5內核UA中會帶上終端分辨率Pixel字段,iOS平臺由於系統對webview內核的限制。臨時沒法很是好的嵌入sharpP組件，未能支持sharpP解碼。

將來可以在原生app引入sharpP組件。原生請求帶上Accept:image/sharpp，就可以使用到CDN的sharpP能力。

CDN側改造：CDN源站轉換工具集成了sharpP組件。CDN的OC結點新增支持 sharpP副本的緩存，整體流程大體例如如下：

client發起請求後，OC結點依據請求UA檢查Accept字段是否帶有image/sharpp，並獲取Pixel分辨率信息，OC結點推斷是否有知足要求的原圖副本緩存，沒有緩存則將URL+請求頭回源，源站識別請求頭中的信息，返回圖片相應的sharpP副本，OC結點緩存下來。源站圖片假設未轉換完畢(圖片上傳後或第一次請求觸發CDN源站異步轉換)，源站會先返回原圖,max-age=10,讓OC結點臨時不緩存，再次請求時，推斷轉換完畢才返回sharpP圖片並設置默認的緩存時間max-age=25920000。眼下CDN sharpP已支持了咱們BGtop5流量的域名：

imgcache.gtimg.cn、i.gtimg.cn、imgcache.qq.com、qzonestyle.gtimg.cn、qzs.qq.com

整體方案：結合以前咱們作的自適應、webP方案，與sharpP可以全然兼容，在CDN源站是3項單獨的配置，可以按需配合或單獨使用，整體方案例如如下圖

優先推斷是否有自適應，而後檢查sharpP。假設sharpP和webP都支持優先返回sharpP。

3.項目中踩過的坑

1）運營商內容劫持，由於同一個URL可能返回不一樣的內容(不一樣分辨率的sharpP/原圖) 線上觀察發現聯通運營商會在請求到咱們自建CDN結點以前加一層緩存，默認會按URL來緩存內容，事實上就是內容劫持。致使不一樣請求頭。返回錯亂與咱們指望的不一致。後面找到一種解決方法，基於http協議的vary字段。CDN源站以及CDN結點返回內容的時候帶上 Vary：User-Agent，Accept 字段，告訴運營商的緩存server依據請求的Accept+User-Agent+Url來緩存內容。經驗證可以解決這個問題。
2）質量參數設置，儘量保證圖片壓縮的更小。效果與原圖差距不大
sharpP採用有損壓縮。轉換工具會讀取原圖質量參數，適當下降：假設原圖質量參數低於75則保持原質量參數直接轉sharpP。假設質量參數高於75，則在原圖基礎上下降一些質量參數。依據業務要求自行設置，眼下依據觀察質量參數不低於75的sharpP圖片基本肉眼沒法區分。

3）新的業務開啓sharpP自適應，源站圖片轉換致使磁盤IO壓力過大
用腳本凌晨閒時對存量圖片預轉換生成各尺寸的副本；轉換工具監聽圖片文件夾的新增文件，用戶上傳後就作轉換；轉換腳本作了優化，僅僅有第一次請求觸發轉換。
4）sharpP轉換工具對某些圖片轉換失敗，生成空文件
捕獲轉換失敗錯誤碼，空文件用原圖替換，避免返回給結點空文件
5）有時候業務圖片需要強制使用原圖
支持nosharpp參數，url帶上參數後，CDN強制返回原圖。

6）圖片緩存清理
由於一 個圖片URL，相應了多份CDN結點緩存副本，假設圖片更新的時候，可能有個別副本緩存刷新不及時，致使不一樣分辨率、sharpP、原圖的用戶看到的圖片不一致。需要優化CDN緩存刷新工具。支持一次清理所有緩存副本。
以上皆爲項目推動中遇到的問題，未考慮周全可能就會影響功能，線上實施前得在測試結點充分驗證。結點部署要控制節奏。並且要有無缺的線上監控機制。以及功能回退的能力。

4.圖片檢測監控

1）爲了提升接入效率。下降人工驗證步驟。咱們開發了圖片檢測監控工具。定時監控業務頁面圖片在各OC結點返回是否正常。原理：工具依據業務URL。抓取頁面內所有CDN域名的圖片，隨機抽取一部分OC結點，構造sharpP。webP。原圖3種請求，依據返回的圖片格式，大小對照驗證圖片是否正常。

2）現網圖片載入數據上報：爲了監控不少其它用戶的圖片載入真實數據，咱們在業務中接入了圖片載入上報組件。原理是利用X5內核收集的資源載入信息，過濾出圖片信息，上報圖片類型，返回碼，載入耗時。網絡類型等。

5.sharpP開啓驗證

上傳一張新圖片。使用手Q安卓版本號訪問已支持sharpP域名的CDN圖片，假設請求帶了Accept:image/sharpp。檢查返回圖片格式是否爲sharpP

假設舊的圖片未按預期返回，返回了webP或原圖多是OC結點緩存，正常3天后過時回源則會返回sharpP圖片。

將來規劃

1）app業務接入sharpP優化方案眼下僅僅有安卓平臺基於X5內核的應用能獲得這套CDN sharpP方案的優化效果，依據CDN日誌的流量統計BG內最大的流量仍是來自終端發起的請求。興許咱們計劃聯合CDN大流量的終端業務接入sharpP解碼組件，讓這套方案能給不少其它業務帶來收益，同一時候也爲公司和用戶節省流量成本。
2）sharpP工具優化 sharpP組件在不斷優化。包含轉碼效率、成功率，gif格式支持等。CDN轉換工具也將迭代支持。

---

相關推薦

藉助騰訊雲CDN開啓全站https及問題解決分享

騰訊雲CDN產品相關文檔

---

閱讀原文，不少其它技術乾貨，請訪問騰雲閣。

文章來源公衆號：小時光茶社（Tech Teahouse）