微信小程序開發者文檔：為什么微信小程序開發者需要關注？小程序要求必須通過 HTTPS 完成與服務端通信，若開發者選擇自行搭建 HTTPS 服 務，那需要自行 SSL 證書申請、部署，完成 https 服務搭建，效率低流程冗長;且 HTTPS 的 SSL 加解析，對服務器的 CPU 有極大的開銷。（廣州小程序開發）
不僅僅是小程序，蘋果 iOS 平臺，Google Android 在 2017 也逐步強制要求開發者使用 HTTPS 接入。HTTPS 似乎是一個繞不開的門檻，讓不少開發者頭痛不已。
微信小程序開發者文檔：為什么微信小程序開發者需要關注？
二、為什么要接入 HTTPS—HTTP 的安全風險
HTTP 協議是一個非常簡單和高效的協議，互聯網大部分的主流應用默認都是使用的HTTP。由于性能和上個世紀 90 年代使用環境的限制，HTTP 協議本身并不是一個為了安全設計的協議，既沒有身份認證，也沒有一致性檢驗，最頭疼的是，HTTP 所有的內容都是明文傳輸的。
另外一方面，互聯網的發展也是日新月異，各種 HTTP 應用不斷地滲透到人們生活的方方面面。不管是社交、購物、金融、游戲、還是搜索，這些 HTTP 服務都能帶給人們極大的便捷，提升生活質量和效率。
顯然，HTTP 和人們生活及經濟利益密切相關，遺憾的是，它不安全。也就意味著這里一 定潛藏著巨大的安全隱患。這些隱患又集中表現在如下兩方面：
1、隱私泄露
由于 HTTP 本身是明文傳輸，用戶和服務端之間的傳輸內容都能被中間者查看。也就是說 你在網上搜索、購物、訪問的網點、點擊的頁面等信息，都可以被「中間人」獲取。由于國人大多不太重視隱私的保護，這里的風險比較隱性，傷害后果也不太好定量評估。已知的一些比較嚴重的隱私泄露事件包括：
QQ 登陸態被不法分子竊取，然后在異地登陸，進行廣告和欺詐行為。
用戶手機號和身份信息泄露。
用戶網上行為泄露。比如搜索了一所醫院，很快就會有人打電話進行推廣(非效果廣告)。
2、頁面劫持
隱私泄露的風險比較隱蔽，用戶基本感知不到。但另外一類劫持的影響就非常明顯非常直接了——頁面劫持，也就是直接篡改用戶的瀏覽頁面。有很多頁面劫持很簡單粗暴，直接插入第三方廣告或者運營商的流量提示信息。
但也有一些劫持做得比較隱蔽，比如下面的京東頁面劫持：其中上圖是使用 HTTP 方面的頁面，頂部箭頭所示的地方出現了一個購物推薦，很逼真，就像京東或者瀏覽器官方的工具。但換成 HTTPS 訪問，就沒有這個工具頁面，顯然是被劫持了。
3、劫持路徑及分類
那劫持到底是如何產生的呢？從技術上來講比較簡單，在內容經過的地方進行監聽篡改就行了。但要想把整個劫持的產業鏈條摸清楚，需要深入黑產內部，比較困難。有一點可以肯定的是，劫持大部分都是在中間的網絡節點發生的，又叫「中間人」(MITM， man in the middle)。如下圖所示：
由于信息傳輸都需要經過上述的「中間人節點」，它們又擁有信息的讀寫權限，如果信息沒有加密，也沒有校驗，那么想要查看隱私，篡改頁面，對于「中間人」來說可謂是輕而易舉。
那劫持又有哪些主要的分類呢?根據劫持路徑劃分的話，主要是下圖所示的三類：
DNS 劫持，客戶端劫持和鏈路劫持。 根據我們的不完全統計，業務遇到的絕大部分劫持 (90%)都屬于鏈路劫持。
三、HTTPS 是解決鏈路劫持的核武器
HTTPS 為什么能很好的解決鏈路劫持呢？主要是三大武器:
1、身份認證—防假冒，防抵賴
每次建立一個全新的 HTTPS 連接時，都需要對身份進行認證，確保用戶訪問的是正確的目的網站。
2、內容加密—防竊聽
內容加密意味端對端的通信內容全都是密文，中間人無法直接查看到明文，HTTPS 所有的應用層內容都是通過對稱加密來實現加密和解密的。
3、一致性校驗—防篡改
通過對數據和共享密鑰的 MAC 碼來防止中間者篡改消息內容，確保數據的一致性。
四、HTTPS 普及之痛
事實上 HTTPS 1995 年就誕生了，是一個非常古老、成熟的協議。同時又能很好地防止內容劫持，保護用戶隱私。但是為什么一直到今天，還有大部分的網站不支持 HTTPS，只使用 HTTP 呢?影響 HTTPS 普及的主要原因可以概括為兩個字：「慢」和「貴」。
1、慢
在未經任何優化的情況下，HTTPS 會嚴重降低用戶的訪問速度。主要因素包括:網絡耗時。由于協議的規定，必須要進行的網絡傳輸。比如 SSL 完全握手，302 跳轉等。最壞情況下可能要增加 7 個 RTT。計算耗時。無論是客戶端還是服務端，都需要進行對稱加解密，協議解析，私鑰計算，證書校驗等計算，增加大量的計算時間。
2、貴
HTTPS 的貴，主要體現在如下三方面：
服務器成本。HTTPS 的私鑰計算會導致服務端性能的急劇下降，甚至不到 HTTP 協議的十分之一，也就是說，如果 HTTP 的性能是 10000cps，HTTPS 的性能可能只有幾百 cps，會增加數倍甚至數十倍的服務器成本。
證書成本。根據證書個數及證書類型，一年可能需要花費幾百到幾百萬不等的證書成本。
開發和運維成本。HTTPS 協議比較復雜，openssl 的開源實現也經常發生安全BUG， 包括協議的配置，證書的更新，過期監控，客戶端的兼容等一系列問題都需要具備專業背景的技術人員跟進處理。
五、騰訊云負載均衡器 HTTPS 的性能優化
騰訊云負載均衡器深針對 HTTPS 推廣應用過程中的痛點進行了深度優化。接下來我們詳細地介紹下這些優化方案：
1、訪問速度的優化
前文提到 HTTPS 非常慢，我們也主要從兩個層面對訪問速度進行了優化：協議棧和前后端資源。
全鏈路協議棧優化
HTTPS 可以認為是 HTTP over SSL，而 HTTPS 又是使用 TCP 協議進行傳輸，所以整個協議棧的優化涉及到三個層面:
TCP 優化。包括擁塞窗口的調整，tcp fast open，reuseport 的支持，最新的 BBR 擁塞控制算法的支持等。
SSL 協議優化。分布式 session cache, session ticket，False start, ocsp stapling file， 動態 record size 等。
SSL 協議優化最重要的目標還是提升簡化握手的比例。騰訊云通過實現全局 session cache 和全局 session ticket 來提升 SSL 的簡化握手比例，節省用戶訪問時間和計算資源。
應用層協議優化。同時支持 SPDY，HTTP2，HSTS 等。
HTTP2 相比 HTTP1.X 最大的優勢就是多路復用，能夠將多個 HTTP 請求通過一個 TCP 連接并行發送，相比 HTTP1.X 的串行發送，性能無疑是提升很多。
由于 HTTP2 是從 SPDY 繼承發展出來的，所以部分較老的客戶端只支持 SPDY，不支持 HTTP2。而大部分新客戶端，只支持 HTTP2，不支持 SPDY。為了同時兼容新老客戶端的性能，騰訊云同時支持 SPDY 和 HTTP2，最大化提升新老版本客戶端的性能。
前后端優化
HTTP2 及 SPDY 最大的特性和優勢就是多路復用，能夠將多個請求通過一個連接并行發送出來。這個特性雖然很強大，但是如果還使用傳統的 HTTP 優化策略，多路復用的效果會很有限。比如域名分片，pipline 等都會影響多路復用的效果。于是我們又通過多次的數據實驗，調整了一些前端資源包括后端接入的策略：
域名收歸。通過頁面資源及性能分析，確實域名收歸方案，比如移動頁面不超過 3 個。
預建連接。STGW 提供預連接頁面，通過對熱點頁面的用戶行為進行分析，提前建立連接，減少協議開銷對用戶體驗的影響。
通過騰訊云遍布全球的 CDN 及 IDC 節點就近完成 HTTPS 卸載。
2、計算性能優化
針對 HTTPS 的計算性能，騰訊云主要從三個層面進行了優化，包括:
盡量減少完全握手的發生，提升簡化握手比例。比如前文提到的全局 sessioncache 和 session ticket。
對于不可避免的完全握手，騰訊云實現了 RSA 異步代理計算，通過對協議棧的改造和 SSL 硬件加速卡的使用，大幅度提升了 HTTPS 的計算能力和防攻擊能力。
對稱加密計算過程也進行了場景使用上的優化。
下面再詳細介紹一下：
RSA 異步代理計算
騰訊云針對 HTTPS 性能消耗最嚴重的環節——非對稱密鑰交換算法進行了重點優化。優化思路主要包括如下三部分:
算法分離。就是將最消耗 CPU 資源的算法剝離出來，不讓消耗本地的 CPU 資源。
代理計算。使用空閑的 CPU 機器或者專門的 SSL 硬件加速卡來完成 RSA 計算。
異步執行。傳統的 openssl 在進行 RSA 的時候，上層應用，比如 NGINX 都需要同步等待。這一步驟也非常影響，必須要進行異步改造，這樣在加速集群進行 RSA 計算的時候，接入服務器也可以接入其他用戶的請求，提升吞吐能力。
通過對 openssl 握手協議棧的深度改造以及 SSL 硬件加速卡的 RSA 計算性能，騰訊云 CLB 的 SSL 計算能力提升了 350%。單機 ECDHE_RSA 處理性能達到了 65000 cps。
對稱加密算法的自動最優選擇
騰訊云根據應用場景匹配最優的對稱加密算法:
對于視頻等流媒體內容，優先使用 aes-gcm。
針對不支持 aes-ni 硬件加速指令的移動終端，使用 chacha20-poly1305 。
針對 IE6 等古董級別的客戶端，使用 RC4 算法。
3、協議的并行卸載
騰訊云 CLB 支持現在主流的全部 HTTP 類協議接入和卸載。包括：
http1.0/http1.1
http2 及前身 spdy3.1
https,包括 ssl3.0, tlsv1.0,tlsv1.1,tlsv1.2
websocket 及 secure websocket。
tcp,udp 透明轉發。
CLB 能夠將上述七層協議統一轉換成 HTTP1.1，透傳給業務。對業務的好處也非常明顯: 0 開發成本就能使用 HTTPS 和 HTTP2，極大減少了適配各種協議和客戶端的壓力。
4、安全
安全涉及的領域和場景非常龐大，HTTPS 雖然能夠徹底解決鏈路劫持，但是對于如下兩類問題卻無能為力:
CC 攻擊，特別是 HTTPS 計算型攻擊，HTTPS 的性能會急劇降低，引入更大的安全風險。
業務安全，包括 SQL 注入，XSS 跨站、網站掛馬等。 上述兩類都是經常困擾業務的風險極大的安全問題。 針對上述問題，騰訊云也設計實現了一套針對 HTTPS 的防 CC 和 WAF 的安全系統，能夠有效地防御這類安全風險。
Keyless（無密鑰加載）
私鑰的重要性
對證書稍微熟悉的朋友都知道，SSL 密鑰和證書都是成對使用的，一個證書一定唯一對應一個私鑰。整個 HTTPS 最重要的一個數據就是 SSL 的私鑰了，如果私鑰泄露，整個握手過程就可以被劫持，簽名可以被偽造，對稱密鑰也可以被破解。整個 HTTPS 就毫無安全可言。
傳統的私鑰使用方案和風險
傳統的私鑰方案就是將私鑰和應用程序綁定在一起。比如大家熟知的 nginx, apache，如果想使用 HTTPS，必須在部署 nginx 的接入機器上部署相關的證書和私鑰。
這種方案會有如下安全上的問題：私鑰部署在云端或者 CDN，如果泄露了怎么辦？
無秘鑰方式
雖然騰訊云的內網非常安全，但是出于對客戶的安全負責，徹底打消用戶對私鑰泄露的顧 慮，確保用戶對私鑰的絕對控制，騰訊云提供一種無私鑰的加載方案。這個方案核心是「不需要把私鑰存儲在騰訊云，允許用戶使用自己的服務器保管私鑰，完成 HTTPS 的接入」。 騰訊云完全接觸不到私鑰，客戶甚至可以把私鑰保存在自己家里的服務器上。
它的接入過程如下：
用戶發起 HTTPS 握手請求。
在涉及到私鑰計算的時候，騰訊云 CLB 會將這個私鑰計算請求通過加密的自定義協議，轉發給用戶自己的 keyless 服務器上。
keyless 服務調用用戶的私鑰完成計算。
keyless 服務將計算結果返回給騰訊云 CLB。
CLB 繼續進行 HTTPS 請求的處理。
整個過程，騰訊云接觸不到 HTTPS 私鑰，需要注意一點的，keyless server 是騰訊云提供一個服務端程序，代碼開源，用戶自主部署，服務端行為用戶掌握得一清二楚。
六、零門檻，HTTPS 快速接入微信小程序
騰訊云 CLB 負載均衡器通過對協議棧及服務端的深度優化，實現了 HTTPS 性能的巨大提升。同時，我們也通過與國際上著名的證書機構合作，極大降低了證書的成本。騰訊云 CLB 在如下幾個方面，能夠為微信小程序接入帶來非常顯著的收益：
提供一鍵式的 SSL 證書申請，CLB 負載均衡服務作為 HTTPS 代理，減輕開發負擔，讓開發者可以專注小程序業務的開發。
使用 HTTPS 并不會降低 client 端的訪問速度。HTTP、HTTPS 訪問時延幾乎一致。
集群內單臺服務器 SSL 加解密性能，高達 6.5Wcps 的完全握手。相比高性能CPU 提升了至少 3.5 倍，節省了服務端成本，極大提升了業務運營及流量突漲時的服務能力， 增強了計算型防攻擊的能力。
支持多種協議卸載及轉換。減少業務適配客戶端各種協議的壓力，業務后端只需要支持 HTTP1.1 就能使用 HTTP2，SPDY，SSL3.0，TLS1.2 等各版本協議。滿足微信小程序，iOS 平臺等對協議的要求。
SSL 證書申請、監控、替換。我們和國際頂級的證書廠商 comodo，symantec 已有深入合作，服務體系完善。
防 CC 及 WAF 功能。能夠有效杜絕慢連接、高頻定點攻擊、SQL 注入、網頁掛馬等應用層攻擊。