236
技術社區[雲棲]
超詳解析 | CDN HTTPS優化實踐，全網一分鍾生效
目前主流網站都依賴 HTTPS（HTTP over TLS/SSL）實現服務器認證、數據加密和完整性保護，比如2015年阿裏巴巴旗下所有網站就完成全站HTTPS化；同時主流網站也普遍使用CDN技術用以提高網站的性能、可靠性和安全性。目前，HTTPS和CDN技術幾乎都已成為商業網站必須的基礎服務。
然而長期以來，HTTPS和CDN兩種技術的設計和發展是獨立的，HTTPS 設計之初是一種端到端（End-to-End）的協議，而CDN卻是以中間人（Man in the Middle）的方式工作。原始網站是如何授權給中間的CDN廠商、如何完成瀏覽器 - CDN - 原始網站之間的身份認證、秘鑰交換和數據保護，以及如何撤銷這種授權，無論學術界還是工業在以前都沒有沒有係統性的考慮。
總的來說HTTPS是未來的趨勢。它的應用會越來越廣泛，CDN也就需要對此做出相應的變化。
近日，在阿裏雲棲社區2017在線技術峰會，阿裏雲CDN技術專家容恪來為大家解析CDN HTTPS紅包背後的技術實踐。本文主要從SSL/TLS及HTTP/2開始談起，著重分析了HTTPS 架構和優化實踐，最後對用戶如何更好使用 HTTPS做出指導。以下是精彩內容整理：
HTTPS
對於HTTPS，其實是在HTTP 之下增加了 SSL/TLS的傳輸。在整個TCP/IP協議中的結構如圖，傳輸層之上是會話層，會話層中傳輸的是SSL/TLS協議，HTTP 是在應用層。如果不用 SL/TLS 協議，則 HTTP傳輸的數據是明文。
SSL（Secure Socket Layer）是安全套接層，TLS（Transport Layer Security）是傳輸層安全協議，建立在SSL3.0協議規範，是 SSL3.0 的後續版本。SSL 直到 3.0版本才大規模的部署和應用。 TLS 版本相比於 SSL 變化明顯的是支持的加密算法不同。當前最新使用的是TLS1.2協議。1.3版本還在草案階段。
圖為SSL/TLS 握手過程，它在基於TCP的連接已經建立起來後，Client端會把自己的協議版本號以及加密算法還有生成的相關隨機數一並發給server，server會選擇最終的協議版本和加密算法以及server證書發給Client。Client會對server證書進行驗證，校驗通過後，兩者再去協商密鑰，用於後續 HTTPS 數據的加解密。
HTTP/2協議特性
HTTP/2也是非常關鍵的協議，在2015年已經正式的公布了，它是為了解決HTTP原先版本的低效不安全等問題而產生，並不是為了要完全顛覆HTTP,而是在HTTP基礎上做了加強，它的特性有二進製協議，支持頭部壓縮，多路複用以及服務器推送。服務器推送指在Client端發送請求時，Server端會根據Client請求來做一些判斷，會把Client請求中頁麵包含的一些資源提前推送給Clinet端，提升了傳輸效率。HTTP/2上更主要的是加強協議的安全性。
HTTP/2頭已經變成二進製格式，並且分為消息頭、消息體都封裝成二進製格式傳輸。
頭部壓縮是HTTP/2中非常重要的特點，它針對同一個Client和一個server之間進行數據傳輸時，有一些header在多次的請求中是相同的，這樣多次請求就會出現多次傳輸相同的 header。HTTP/2協議針對這種情況對所有header信息建立索引，如果在下一次傳輸時相同的header直接用索引的編號去傳輸，這樣就不會傳輸一長串的字符串，減少了網絡傳輸信息量，提升了傳輸效率。當然，頭部壓縮也存在一些缺點 ，因為不管是Client端還是server端，都要維持索引表，確定每個索引值對應HTTP header的信息，通過占用更多內存換取數據量傳輸的減少，也可以認為是通過空間換時間。對於現在內存日益擴大的情況下，增加傳輸效率才是更重要的。
HTTP/2協議多路複用的功能如圖，HTTP之前的版本最多支持keep live，可以在一個TCP連接上傳輸多個HTTP請求，對於最基本的keep live，隻能在一個請求傳輸完進行下一個請求的傳輸，以及在這個基礎上還有pipeline，可以在請求方向上同時傳輸多個get請求，但都不是真正的多路複用。HTTP/2在 TCP 連接的基礎上，增加了stream的概念，每個 stream 都可以處理單獨的一個 HTTP 請求。在這個基礎上，在一條TCP連接上可以同時傳輸多個 sream，而且不同 stream都有對應編號。因此就支持了真正的多路複用。
Why HTTPS?
HTTPS有效的防止網站內容被篡改被劫持，加強了網站的安全性。當前的一些形勢也對 HTTPS 的要求越來越強烈：Chrome/Firefox未來將 HTTP 標記為不安全，現在我們訪問HTTP協議已經出現歎號的提醒了；Apple ATS也會要求App Store 的 app 使用 HTTPS；HTTP/2協議已經在使用，主流瀏覽器隻支持基於 TLS 的 HTTP/2；Google搜索排名給 HTTPS 網站的加權；此外美英政府網站要求 HTTPS。
CDN HTTPS架構中首要的就是證書管理，CDN節點的基本架構是通過LVS作為四層的負載均衡，用tengine作為七層的負載均衡，cache 軟件是自研的 Swift，依托此架構高效的處理 HTTP 請求。在需要支持 HTTPS時，首先要有證書管理中心，存儲用戶的證書和私鑰，我們做了一個改進，在每個節點會做一個動態證書的加載功能，按需動態加載，。訪問流程是，當Client發起一個HTTPS，最終會被某一台tengine處理，當tengine接收到 SSL 握手信息，它會提取出來SNI 信息，也就是要訪問的域名信息，根據域名去動態的取到域名對應的證書以及密鑰，在這個基礎上進行了SSL握手，握手完成後，再進行下麵HTTP請求的處理。證書和私鑰我們都是動態的加載，隻存儲在內存中並且混淆存儲，全方位保障安全性。
全鏈路支持 HTTPS
我們可以全鏈路支持 HTTPS，對於一個具有兩級節點的CDN架構中，從Client到L1節點，從L1到L2，以及L2回到自己的源站，整個鏈路中有三段TCP的連接，每一段CDN都支持了HTTPS，第一段需要用戶自己的證書，第二段是我們的證書，保證傳輸數據的加密。第三段需要用戶的源站支持 HTTPS，並且 CDN 的回源也用 HTTPS。
無私鑰解決方案
越來越多的用戶更看重自己的證書和私鑰的安全性，希望將私鑰存儲在在用戶私有的服務器 ，而不需要提供給 CDN。針對這種情況，CDN推出無私鑰解決方案。用戶需要自己搭建一個私鑰服務器 KeyServer。當有HTTPS握手時，會從握手信息中提取SNI，確定請求訪問的域名，將域名配置拿到。對於該域名，如果用戶配置了自己的KeyServer，tengine 給KeyServer發送待解密或者簽名數據，KeyServer 響應結果， tenine 拿到結果並完成握手。這種方案，通過將 SSL 握手過程中需要用到私鑰的部分通過KeyServer進行剝離，實現了將私鑰保存在客戶的私有服務器上。CDN 也實現了一套 KeyServer 程序。接下來 CDN 會整理出來搭建 KeyServer 集群的完整方案，如果用戶想要搭建自己的KeyServer，CDN 可以為用戶提供剞劂方案以及源碼。
CDN HTTPS 特性
CDN HTTPS 特性如下：
動態證書，快速生效，全網 1 分鍾可以生效；
支持 SPDY 和 HTTP/2；
豐富的配置項，可動態設置；
支持用戶 KeyServer，實現無私鑰服務；
與阿裏雲證書中心 CAS 聯動，可申請免費證書。
HTTPS 優化實踐
多次握手包含了多次非對稱數據加解密以及證書的傳輸，現實中確實會消耗較多的性能。那麼，HTTPS一定會變慢嗎？
上圖並不能完全代表HTTPS所有的訪問都能提升，隻是在某些場景下我們做的優化實現了請求的響應速度沒有下降，甚至某些場景還有所提升。
優化方法如下：
- 減少握手：SSL Session ID/Session Ticket，TCP KeepAlive也是需要的；
- HTTP/2：多路複用和頭部壓縮可以有效提升數據傳輸效率；
- 域名合並：減少 SSL 握手，提升重用；
- 協議棧優化：調整TCP 初始化窗口，快速重傳；
- 優先算法：ECDSA > RSA。
峰值的應對上，五福開獎的QPS是非常大的，超過了以往處理值，如何應對呢？方法如下：
- Cache 係統預熱，全部加載到一級節點，避免的訪問時回源；
- 調度係統也要做工作，包含預判峰值；熱點地區統計，臨近非熱點地區分攤；依據節點能力按比例分配；
- 如此大的峰值肯定可能超過我們的預期，我們也要做限流。
證書
根據自己的域名情況進行申請，單域名、多域名還是泛域名，申請渠道有阿裏雲CAS以及其他廠商。
阿裏雲雲盾證書服務可以簽發Symantec、CFCA、GeoTrust證書。CFCA側重於國內的金融機構。證書分為DV、OV、EV，DV指域名級別證書，OV、EV是公司企業級別證書。
源站改造，支持 HTTPS
工作中最繁瑣的就是源站改造，最基本的包括以下幾方麵：
- 頁麵資源：會有很多HTTP鏈接，HTTPS中引用這種鏈接會有告警，尤其再有異步調用時，甚至不會執行了；
- SSL/TLS：TLS 版本 1.0 以上，支持SNI；
- 優化配置：開啟Session ID/Session Ticket；
- 證書：支持SHA256，SHA-1 已經不安全；
- HSTS：可以考慮強製 HTTPS。
用戶直接輸入域名，怎麼 HTTPS?
當用戶瀏覽地址欄輸入域名訪問時，瀏覽器大部分缺省是通過HTTP訪問的，這時我們的用戶自己的網站就要做一個配置，做302的跳轉，所有的HTTP請求都讓它訪問HTTPS，這可以實現HTTPS的訪問，如果僅僅 302 的話，以後的訪問請求每次都需要從HTTP跳轉到HTTPS，多了一次 HTTP 請求的處理。對此，還需要有另外的配置，瀏覽器的訪問跟隨了跳轉後，重新發起一個HTTPS請求，服務器除了正常給到內容外，會多加一個STS的header，header標識告訴瀏覽器以後這個域名就要強製走HTTPS，並給出一個超大的超時時間。
用戶關掉瀏覽器，下次又要訪問網站時，瀏覽器直接會把HTTP請求在內部轉成HTTPS，實現了真正的HTTPS，以後瀏覽器在這個超時時間內都會通過HTTPS進行訪問。
最後更新：2017-06-19 15:01:50