騰訊技術分享：社交網絡圖片的帶寬壓縮技術演進之路
一、引言
騰訊社交網絡相關產品，例如騰訊課堂、增值會員、動漫、直播、遊戲商城、音樂、Qzone校園等，主要目標羣體定位爲年輕一代，屬於對新事物接受比較高也更喜歡新鮮個性內容的羣體，產品設計上必然使用大量的圖片展現；同時核心產品QQ也涉及大量的圖片存儲及展現，例如QQ羣圖、羣相冊等。php
圖片在產品中的大量使用擁有諸多好處的同時，也帶來如下幾點問題：html
服務器端出口流量增長、文件存儲磁盤增長，運營成本增高；前端
用戶訪問單頁面/產品流量消耗增長，尤爲當前移動互聯網流量按量計費，富圖片會明顯增長用戶訪問成本；程序員
客戶端加載頁面耗時增大，首屏顯示時間延遲，影響用戶使用體驗。web
爲了進一步下降運營帶寬成本，減少用戶訪問流量及提高頁面加載速度，社交網絡 CDN運維緊跟行業圖片優化趨勢，創新引入WebP、SharpP、自適應分辨率、Guetzli等圖像壓縮技術到現網，通過三年多的多部門聯合攻關，已逐漸造成一套覆蓋全圖片類型（JPEG、JPG、PNG、WebP、GIF）多場景的圖片壓縮運營體系，適用於各種型終端，每一年節約外網帶寬幾百G。算法
▲ 示例1：QQ空間GIF採用SharpP編碼後，單圖平均大小降幅90%，高峯期流量降幅30%shell
▲示例2：QQ相冊GIF採用SharpP編碼後，節約流量很是明顯，降幅超過80%數據庫
學習交流：
- 即時通信開發交流羣：320837163[推薦]後端
- 移動端IM開發入門文章：《新手入門一篇就夠：從零開發移動端IM》瀏覽器
（本文同步發佈於：http://www.52im.net/thread-1391-1-1.html）
二、相關文章
《QQ音樂團隊分享：Android中的圖片壓縮技術詳解（上篇）》
《QQ音樂團隊分享：Android中的圖片壓縮技術詳解（下篇）》
《騰訊原創分享(一)：如何大幅提高移動網絡下手機QQ的圖片傳輸速度和成功率》
《騰訊原創分享(二)：如何大幅壓縮移動網絡下APP的流量消耗（上篇）》
《騰訊原創分享(二)：如何大幅壓縮移動網絡下APP的流量消耗（下篇）》
《基於社交網絡的Yelp是如何實現海量用戶圖片的無損壓縮的？》
《騰訊團隊分享 ：一次手Q聊天界面中圖片顯示bug的追蹤過程分享》
三、本文做者
四、技術演進階段一：引入WebP壓縮，對業務強侵入
WebP是Google在2010年推出的新一代web圖片壓縮格式，它的優點體如今：
具備更優的圖像數據壓縮算法，能帶來更小的圖片體積（原圖基礎上節約30%左右大小）；
擁有肉眼識別無差別的圖像質量；
具有了無損和有損的壓縮模式、Alpha 透明以及動畫的特性；
在 JPEG 和 PNG 上的轉化效果都至關優秀、穩定和統一；
支持GIF，對GIF的壓縮效果尤爲顯著，能夠節約企業大量的帶寬資源以及數據空間。
運維同事及時跟進研究WebP並推進應用現網，並基於該技術創建了最初的CDN圖片壓縮訪問方案。
壓縮參數設置：
經過驗證發現，壓縮質量參數在編碼後圖片質量及大小間造成正相關關係，質量參數越高，編碼後圖片質量越好體積也就越大。質量參數設置70%~90%間，能夠達到最優平衡。現網默認設置80%。
編/解碼性能優化：
終端WebP解碼性能，在當前網絡環境下不存在問題，平均解碼耗時在100ms之內。而且，經過有限制的使用WebP圖片，例如限制圖片尺寸、使用的CPU核心及最大頻率等方式，能夠進一步優化編解碼能力。
終端兼容性：
嵌入WebP解碼庫的自有APP以及已知支持WebP的公共瀏覽器，例如Chrome、Opera等，其餘場景下沒法解碼WebP數據（關於主流瀏覽器對WebP的支持狀況點此查看）。
一期主要聯合ISUX開發實現現網CDN的WebP能力引入，並創建了相應壓縮訪問方案，以下圖所示：
服務器端部署異步壓縮工具，對特定規則的圖片應用壓縮，並生成對應的副本文件；
客戶端（Browser+APP）和後臺管理端聯動，客戶端識別載體是否支持WebP解碼，並將結果返回後臺管理端，後臺管理端再根據客戶端能力，肯定最終的資源訪問URL。
大體的原理是：
CDN源站部署WebP編碼工具，對符合規則的資源進行WebP編碼及寫DB操做；
WebP編碼採用異步模式，且編碼成功後才寫DB知會後臺管理，所以即便編碼失敗或耗時長也不影響客戶端實際訪問；
客戶端需先向後臺管理獲取資源路徑，而後才能對資源發起實際請求，向管理端請求資源訪問路徑時，會帶上自身WebP兼容性標籤數據；
CDN緩存是基於訪問URL爲key的，而原圖及WebP副本訪問URL不同(副本爲.webp後綴)，所以實際會在CDN節點緩存兩份不一樣數據。
以上方案在接入CDN的ISUX上使用穩定，而且達到了預期效果，後續也逐步推廣應用到了少許Qzone圖片上。不過因爲該方案對接入業務侵入性較強，要求業務客戶端必須具有WebP兼容性檢測能力，以及訪問URL後臺下發能力，最終接入業務除相冊外，寥寥無幾。
五、技術演進階段二：引入WebP/SharpP/自適應多方式壓縮，業務無痛接入
老架構的圖片壓縮在CDN現網能正常服務部分業務，減少服務器端帶寬消耗和數據存儲的同時，提高了客戶端的加載速度。
但該架構的固有缺陷也十分明顯：
壓縮能力有限，只支持WebP一種方式，跟不上行業壓縮技術趨勢；
壓縮場景有限，只支持兼容WebP格式的部分客戶端訪問；
對業務侵入嚴重，致使實際推廣效果不佳。
基於此，在優化圖片壓縮訪問方案的時候，但願新架構能對業務侵入小甚至無侵入，同時引入更高效的圖片壓縮技術進行現網推廣使用。項目歷時2015~2016共兩年時間，期間咱們也跟隨行業編碼技術趨勢，在優化成熟WebP、自適應方案同時，創新性的引入了SharpP編碼技術。
5.1 編碼技術：優化WebP，新引入騰訊自研SharpP及分辨率自適應調整能力
WebP編碼在原圖基礎上節約30%左右大小，但隨着H.26五、VP9以及AVS2等新編碼技術的出現，圖片壓縮有了進一步優化的空間。
【a. 基於HEVC的SharpP編碼壓縮】：
Sharp是基於新一代圖片編碼標準HEVC，並對編碼性能、效率及支持能力等方面作出優化擴展後，由騰訊社交網絡音視頻實驗室推出的圖像編解碼技術。無論理論仍是實際驗證，基於HEVC的SharpP相對WebP可節約21%大小，相對JPEG可節約43%左右大小。
SharpP系統組成同WebP同樣，包括編碼和解碼兩部分：
編碼：RGB->SharpP
解碼：SharpP->RGB
經過對原HEVC編解碼內核優化、支持漸進式功能及透明通道、動態圖片格式等方式，進一步下降了SharpP編解碼性能消耗並增長對現有圖片類型的兼容性，並作到了質量上的基本不失真。因爲現階段SharpP還屬於騰訊內部自有格式，所以只能應用於騰訊自有APP，經過APP中添加SharpP解碼庫的方式實現客戶端的解碼。
【b. 圖片分辨率自適應調整】：
終端機型分辨率大小不一，相關圖片是以最大分辨率設計的，目前統一標準是750px，但許多中低端機型並不須要高分辨率的圖片，若是能按需返回適當分辨率圖，一樣可達到節約流量及優化性能的目的。經現網驗證，啓用自適應圖片壓縮後，相關產品訪問流量可在原有基礎上，再節約20%左右。
圖片分辨率調整相對WebP/SharpP來講原理簡單，不修改編碼格式只調整分辨率信息，所以無編解碼性能或客戶端兼容問題。咱們將現有終端設備分辨率按以下三級進行劃分，並對應到源站某個固定分辨率的圖片副本：
5.2 運營方案：對業務最小侵入的圖片壓縮訪問架構
讓業務以最小的改動代價來得到最大的帶寬及性能收益，才能讓技術架構更容易推廣。
考慮到Accept、User-Agent屬於標準的HTTP請求頭字段，分別用來承載客戶端的解碼能力信息及屏幕分辨率信息，也屬常理；而且相似Chrome、Opera這種已支持WebP的瀏覽器，請求頭默認有帶上「Accept: image/webp」字段，徹底兼容該套方案。
【a. 基於Accept頭的WebP/SharpP自識別編碼】：
PC瀏覽器，例如Chrome、Opera等，支持WebP解碼狀況下，在請求頭Accept字段中默認有帶上「image/webp」字段，兼容該套壓縮訪問框架。
非瀏覽器類，例如APP、PC客戶端，在發送圖片請求前，可根據編碼能力，自定義添加、或經過底層WebView來統一添加「image/webp」 「image/sharpp」字段。騰訊APP類產品上承載的業務通常較多，分屬不一樣內部開發團隊，爲便於資源接入及統一管理，咱們推薦的方式是APP平臺統一嵌入解碼SDK及修改請求頭Accept字段，其上業務調用APP內嵌WebView來請求圖片資源便可。
爲識別客戶端發送的編碼格式字段並返回正確編碼後的壓縮內容，CDN節點和CDN源站一樣須要提早作好相應的調整部署：
如上圖所示:
騰訊瀏覽器、QQ APP的WebView中預埋WebP/SharpP解碼SDK，並向上提供Accept頭字段的自動修改能力及圖片解碼能力；
CDN節點，根據識別到的Accept頭字段返回對應緩存內容，或者直接透傳請求到源站；
CDN源站，根據獲取到的請求頭字段，讀取預生成的壓縮格式副本或觸發實時壓縮，並響應對應編碼內容給客戶端。
因爲WebP/SharpP編碼有可能失敗或者耗時太高，現網經過如下幾個手段來保障請求數據的及時返回：
在資源到達CDN源站前，實施相關編碼格式預壓縮；
在線編碼採用異步模式，並設置超時；若超時則直接返回原圖，並設置緩存時間max-age=10，便於該次請求內容在CDN能夠儘快過時更新；
若檢測到壓縮後的文件對比原圖無優點（沒有比原圖小），則直接返回原圖內容；
鑑於SharpP比WebP編碼更高效，在 Accept 字段同時帶有 "image/webp"、"image/sharpp" 時，CDN 優先返回 SharpP 編碼內容。
【b. 基於User-Agent的分辨率自適應調整】：
HTTP頭字段中帶的User-Agent，通常不包括分辨率（或格式不統一）。通過調研，咱們認爲以「Pixel/750」這種格式來匹配最標準，也更容易兼容已有客戶端能力。同編碼方案相似，基於User-Agent的自適應方案，一樣須要客戶端WebView頭字段修改能力支持，以及CDN節點和CDN源站的對應功能實現：
如上圖所示，分辨率自適應方案不依賴獨立的解碼SDK，直接使用WebView中自帶的公共SDK便可。
另，此處WebView一樣須要修改UA頭字段，按照格式要求添加分辨率信息後，傳遞給CDN節點或CDN源站，節點及源站再進行相應的邏輯處理：
WebView修改請求頭User-Agent帶上分辨率信息，而後傳遞給CDN。例如User-Agent: Mozilla/5.0 Pixel/480 …；
CDN節點根據UA分辨率數據讀取對應緩存並返回，或者直接透傳請求到源站；
源站根據UA分辨率數據讀取本地預生成的對應副本，或觸發在線壓縮；
在線壓縮採用異步模式，並設置超時時間。失敗或超時狀況下直接返回原圖，而且設置緩存時間max-age=10；
自適應調整後圖片編碼格式與原圖相同，只是分辨率不同。
編碼壓縮和分辨率調整屬於不一樣的兩種圖像壓縮方式，理論上可疊加使用不影響實際功能，且同時帶來疊加後的壓縮比和性能收益。現網應用的時候，咱們也充分考慮到了這點，將兩種不一樣壓縮方案一樣分爲客戶端（SDK+WebView）、CDN節點、CDN源站三個層級，並在對應層級上將兩者功能邏輯耦合在一塊兒，實現交錯疊加能力。
現網結合編碼壓縮和分辨率自適應的最終方案流程圖以下：
該套方案解決了業務侵入性問題，同時經過引入SharpP、自適應能力，提升了編碼效率以及終端適用場景；當前已成功應用到騰訊手Q H五、手Q羣圖片、相冊及Qzone結合版、獨立版等重要業務上，月節約流量400Gbps以上，同時該套方案也正在向全公司內部推廣。
六、技術演進階段三: 持續引領，引入Guetzli補充適用場景，業務無感知
WebP/SharpP編碼壓縮雖然在壓縮效率上更優，但需客戶端具有對應解碼SDK才能正常使用。對現網流量數據分析，發現除WebP/SharpP/自適應圖片外，還存在大量的原圖請求流量，其中JPG格式請求佔比30%左右。
其緣由以下：
CDN靜態已全量圖片壓縮應用，但較多來自獨立APP或PC瀏覽器的訪問，致使jpg原圖流量佔比約9%；
手Q服務號已改造支持新格式，但jpg格式帶寬佔比仍是有35%之多；
QQ羣圖改造編碼壓縮難度大（沒法兼容全部客戶端類型），一直無進展；
騰訊視頻APP已改造支持新格式，但還有來自PC端各類瀏覽器的訪問，致使jpg帶寬佔比35%。
Guetzli是Google 2017年最新推出的圖片編碼算法，用於編碼JPEG格式，官方宣稱比早期的libjpeg減少30%左右大小。此算法只是改進並無改變JPEG編碼算法，所以編碼出來的圖片適用目前已有解碼器。
開源Guetzli工具在編碼文件時，內存及時間消耗都比較高，通過相關優化調整，可大大減少工具性能消耗，延時降低92%，成本節省一半以上，從而具有初步的線上應用能力。當前現網存在大量jpg原圖請求，可應用Guetzli編碼壓縮進行場景覆蓋。據統計，Guetzli優化後圖片大小平均節省30%，用戶側下載延時降低25%左右，相對傳統JPEG編碼優點明顯。
6.1 Guetzli現網應用方案
Guetzli並未改變圖片原有編碼格式，只是對其數據進行優化縮減，所以無論對客戶端仍是CDN節點來講，均可將Guetzli副本當作原圖來處理；惟一須要作的只是準備好工具並在源站部署對應處理邏輯：
【a. 工具優化：】
開源Guetzli工具在現網是無法直接用的，相信只要關注Guetzli的同窗，都知道這個結論。
爲讓工具具有現網應用能力，開發同窗主要從如下兩個方面對其進行了優化：
GPU計算加速：將整個Guetzli的計算算法所有都轉移到了CUDA裏去，利用顯卡的並行能力及浮點計算優點進行加速；
參數調優：對內存分配改用效率更高的TCMalloc庫；優化CUDA的Block Size大小；將計算精度由double改成float。
優化後的Guetzli工具，性能較源開源版本提高90%以上，質量上基本無差別。
【b. 源站處理邏輯】：
簡單的Guetzli應用，直接經過Web方式觸發對應shell命令便可。爲便於業務灰度控制，咱們引入業務ID概念：CDN源站經過請求業務ID來區分是否Guetzli請求，同時經過前端Nginx匹配域名+URL規則，來控制放量範圍。
以下所示：
原理大體以下：
客戶端按照正常狀況發送圖片請求；
Nginx層根據$uri 匹配規則分別轉發請求到不通的後端業務ID，其中一個業務ID開啓Guetzli壓縮，另外一個沒有；
源站Guetzli壓縮支持預壓縮和在線壓縮兩種，其中在線壓縮爲異步模式，並設置有超時時間。若壓縮失敗或超時，則返回原圖並設置max-age=10；
Guetzli副本存儲在Cache層原圖的key位置，即默認使用Guetzli副本代替原圖。
6.2 與原有架構的結合
Guetzli編碼後的圖片仍是JPEG格式，理論上再次進行WebP/SharpP壓縮是可行的，現網實際測試也的確如此。那麼Guetzli是否會和分辨率自適應同樣，在與WebP/SharpP疊加編碼後，壓縮效率和性能收益一樣疊加？
咱們從現網獲取了100張視頻封面做爲測試樣本，Guetzli質量因子設備90，WebP/SharpP質量因子設置70，分別進行獨立的編碼壓縮以及WebP + Guetzli疊加、SharpP + Guetzli疊加。
取得測試數據以下：
從測試數據能夠看出， Guetzli與WebP/SharpP的疊加壓縮必要性不大，疊加的GUE壓縮並無帶來更優的壓縮效率，甚至在色彩單一狀況下，疊加壓縮的圖片比原圖WebP/SharpP壓縮後還要大些。
所以，最終落地方案設計時，沒有對是否疊加壓縮進行強制限制。即Guetzli與原有壓縮訪問架構在源站並行部署，各自覆蓋對應適用場景而且有必定概率疊加使用。
最終落地方案架構如圖所示：
Guetzli編碼優化功能自上線以來，因爲其無敵的現有終端兼容能力，一個月內即完成CDN全量域名推廣，兩個月內即完成QQ看點、騰訊視頻圖片、QQ音樂封面的推廣，節約帶寬近百G，並會隨着時間推移持續增加。
七、本文小結
通過三年多的多部門聯合運做，終於完成圖像壓縮技術方案在騰訊CDN的落地以及全域名實施。
在技術演進的過程當中獲得的收穫：
壓縮訪問方案作到了對現有規範的最大兼容、對業務的最小侵入，使得對內能夠儘快推廣；
相關編碼/分辨率壓縮技術緊跟行業趨勢，在開源基礎上優化、精煉和擴展，優化後的工具能力較開源版本提高明顯，並有逐漸反哺開源社區；
提高自身業務競爭力的同時，也爲行業發展貢獻了一份力量！
以上方案涉及的一些關鍵編碼工具，其中：
WebP工具在開源版本基礎上無修改，直接基於libwebp封裝而成；
Guetzli工具基於開源版本有少許參數調整及BUG修復，相關代碼已開源到GitHub；
SharpP工具從17年3月開始，已採用AVS2做爲新的內核；17年5月正式對外推出基於AVS2的圖片格式，聯合北大、AVS組織一塊兒完善相關規範，並命名爲TPG（Tiny Portable Graphics）。
附錄：微信、QQ團隊相關文章彙總
[1] 有關QQ、微信的技術文章：
《QQ音樂團隊分享：Android中的圖片壓縮技術詳解（上篇）》
《QQ音樂團隊分享：Android中的圖片壓縮技術詳解（下篇）》
《騰訊團隊分享 ：一次手Q聊天界面中圖片顯示bug的追蹤過程分享》
《微信團隊分享：微信Android版小視頻編碼填過的那些坑》
《微信團隊披露：微信界面卡死超級bug「15。。。。」的前因後果》
《月活8.89億的超級IM微信是如何進行Android端兼容測試的》
《微信客戶端團隊負責人技術訪談：如何着手客戶端性能監控和優化》
《微信團隊原創分享：Android版微信的臃腫之困與模塊化實踐之路》
《微信團隊原創分享：微信客戶端SQLite數據庫損壞修復實踐》
《騰訊原創分享(一)：如何大幅提高移動網絡下手機QQ的圖片傳輸速度和成功率》
《騰訊原創分享(二)：如何大幅壓縮移動網絡下APP的流量消耗（下篇）》
《騰訊原創分享(二)：如何大幅壓縮移動網絡下APP的流量消耗（上篇）》
《如約而至：微信自用的移動端IM網絡層跨平臺組件庫Mars已正式開源》
《開源libco庫：單機千萬鏈接、支撐微信8億用戶的後臺框架基石 [源碼下載]》
《微信新一代通訊安全解決方案：基於TLS1.3的MMTLS詳解》
《微信團隊原創分享：Android版微信後臺保活實戰分享(進程保活篇)》
《微信團隊原創分享：Android版微信後臺保活實戰分享(網絡保活篇)》
《Android版微信從300KB到30MB的技術演進(PPT講稿) [附件下載]》
《微信團隊原創分享：Android版微信從300KB到30MB的技術演進》
《微信技術總監談架構：微信之道——大道至簡(PPT講稿) [附件下載]》
《微信海量用戶背後的後臺系統存儲架構(視頻+PPT) [附件下載]》
《微信異步化改造實踐：8億月活、單機千萬鏈接背後的後臺解決方案》
《架構之道：3個程序員成就微信朋友圈日均10億發佈量[有視頻]》
《微信團隊原創分享：Android內存泄漏監控和優化技巧總結》
《微信團隊原創Android資源混淆工具：AndResGuard [有源碼]》
《移動端IM實踐：Android版微信如何大幅提高交互性能（一）》
《移動端IM實踐：Android版微信如何大幅提高交互性能（二）》
《移動端IM實踐：WhatsApp、Line、微信的心跳策略分析》
《移動端IM實踐：谷歌消息推送服務(GCM)研究（來自微信）》
《信鴿團隊原創：一塊兒走過 iOS10 上消息推送(APNS)的坑》
>> 更多同類文章 ……
[2] 有關QQ、微信的技術故事：
《2017微信數據報告：日活躍用戶達9億、日發消息380億條》
《技術往事：創業初期的騰訊——16年前的冬天，誰動了馬化騰的代碼》
《技術往事：史上最全QQ圖標變遷過程，追尋IM巨人的演進歷史》
《開發往事：深度講述2010到2015，微信一路風雨的背後》
《開發往事：記錄微信3.0版背後的故事（距微信1.0發佈9個月時）》
>> 更多同類文章 ……
- 1. 騰訊技術分享：GIF動圖技術詳解及手機QQ動態表情壓縮技術實踐
- 2. 騰訊遊戲容器雲平臺的技術演進之路
- 3. 騰訊雲數據庫CDB技術演進之路
- 4. DuKBitmapImages 圖片壓縮處理技術
- 5. 插件化技術的演進之路
- 6. 技術分享 | OpenShift網絡之SDN
- 7. 騰訊技術官分享出SpringSecurity筆記「全網沸騰」
- 8. android-圖片壓縮技術及壓縮庫
- 9. 【期末複習】寬帶網絡與交換技術(1)
- 10. 【期末複習】南郵寬帶網絡與交換技術
- 更多相關文章...
- • 網站主機 技術 - 網站主機教程
- • XML 相關技術 - XML 教程
- • Docker容器實戰(一) - 封神Server端技術
- • 三篇文章瞭解 TiDB 技術內幕——說存儲
-
每一个你不满意的现在，都有一个你没有努力的曾经。