隨著網際網路使用者對安全性、保密性的需求日益提升，大洋彼岸的Google、Apple帶頭強推HTTPS，將網站升級成為HTTPS已經如風潮般席捲了國內外網際網路廠商，《Google透明度報告：各大熱門網站的HTTPS使用情況》中指出，相當多數量的網站已經轉向HTTPS協議。

然而，對於網際網路廠商來說，並不是部署了HTTPS就可以高枕無憂，要讓HTTPS發揮最大作用，往往還需要與HSTS、HTTP 2。0、OSCP stapling等其它技術一起使用。本文羅列了網站在實現HTTPS中遇到的5個技術難點，幫助廣大需要進行HTTPS升級和已經升級為HTTPS的網際網路廠商呈現出升級HTTPS後更好的使用者體驗。

HSTS

即使我們將一個HTTP網站升級為HTTPS網站，當我們在瀏覽器中鍵入以www為開頭的網址時，網頁並不會自動跳轉為HTTPS網站，因為瀏覽器預設開啟HTTP網站，基於此，我們就需要對HTTP的訪問在伺服器端做301、302或307重定向，使之跳轉到HTTPS網站。

其中最常用的就是302重定向了：

302重定向是一條對網站瀏覽器的指令，來使瀏覽器顯示被要求顯示的URL，當一個網頁經歷短期的URL變化時使用。

301重定向

是302重定向的升級版，301重定向是永久的重定向，搜尋引擎在抓取新內容的同時也將舊的網址交換為重定向之後的網址。

但是它們存在一個共同的弱點：

當使用301、302跳轉時，只要修改

location指令

，網站就會被劫持。

對此，

國際網際網路工程組織IET

E推行了一種新的Web安全協議：HSTS，即307跳轉。

採用HSTS協議的網站將保證瀏覽器始終連線到該網站的HTTPS加密版本，不需要使用者手動在URL位址列中輸入加密地址。幫助網站採用全域性加密，使用者看到的就是該網站的安全版本。

HSTS的作用還包括阻止基於SSL Strip的中間人攻擊，萬一證書有錯誤，則顯示錯誤，使用者不能迴避警告。從而能夠更加有效安全的保障使用者的訪問。

目前主流的瀏覽器大多已支援HSTS，但IE 11以下版本還不支援HSTS。

HTTP/2

HTTP/2即超文字傳輸協議2。0，是HTTP協議的升級版。由網際網路工程任務組的Hypertext Transfer Protocol Bis工作小組進行開發，以SPDY為原型，經過兩年多的討論和完善最終確定。

SPDY是一種HTTP相容協議，由Google發起，Chrome、Opera、Firefox以及Amazon Silk等瀏覽器均已提供支援，並對當前的HTTP協議有4個改進：

多路複用請求

對請求劃分優先順序

壓縮HTTP頭

伺服器推送流（即Server Push技術）

HTTP/2相比於SPDY，優勢更加明顯：

HTTP/2採用

二進位制

格式傳輸資料，其在協議的解析和最佳化擴充套件上帶來更多的優勢和可能

HTTP/2對訊息頭採用HPACK進行壓縮傳輸，能夠節省訊息頭佔用的網路的流量

Server Push的服務端能夠更快地把資源推送給

客戶端

。

即便如此，HTTP/2在往返時延（RTT）上仍存在問題，尤其是在行動網路方面。所以谷歌正在測試另一項協議，即QUIC；QUIC在TCP到UDP的網路轉換上更加流暢。

更多特性可見：一文讀懂 HTTP/2 特性

OSCP stapling

在HTTPS通訊過程時，瀏覽器透過CRL和OCSP來驗證伺服器端下發的證書鏈是否已經被撤銷。

CA機構在CRL中列舉在有效期內但是被撤銷的

數字證書

，CA機構會維護並定期更新CRL列表，但隨著時間的推移，體現出兩個不足之處：

CRL列表越來越大

瀏覽器更新不及時的時候，會造成誤判

OCSP是實時證書線上驗證協議，用來彌補CRL機制的上述不足之處，透過OCSP瀏覽器可以實時向CA機構驗證證書。但OCSP也有自身的弊端：

要求CA機構實時全球高可用

客戶端的訪問隱私可能被洩露

增加瀏覽器的握手延時

於是，

OCSP Stapling技術

被開發出來，作為對OCSP協議缺陷的彌補，這個技術實現了伺服器可以事先模擬瀏覽器對證書鏈進行驗證，並將帶有CA機構簽名的OCSP驗證結果響應儲存到本地。等到真正的握手階段，再將OCSP響應和證書鏈一起下發給瀏覽器，以此避免增加瀏覽器的握手延時。由於瀏覽器不需要直接向 CA 站點查詢證書狀態，這個功能對訪問速度的提升非常明顯。

又拍雲CDN SSL握手時間

如上圖所示，使用

OCSP Stapling

可以在SSL握手階段節約90+毫秒， 效能提升了34。08%左右。

Session ID

HTTPS訪問過程是在TCP三次握手之後進行SSL的四次握手，如果一個業務請求包含多條的加密流，反覆的握手請求勢必會導致較高的延遲。並且如果出於某種原因，對話中斷，就需要重新握手，增加了使用者訪問時間。

Session ID

是一種在網路通訊中使用（通常在一塊資料的HTTP）來識別一個會話，具有一系列相關的資訊交流。SessionID屬性用於唯一地標識在伺服器上包含會話資料的瀏覽器。

SessionID值由

http：//

ASP。NET

隨機生成，並存儲在瀏覽器的不過期Cookie中。每次向

http：//

ASP。NET

應用程式傳送請求時，SessionID值便被髮送到Cookie中。因此，session ID可以有效的減少多次訪問時的握手次數，降低訪問延遲。

SNI技術

過去，只有獨立IP的虛擬主機或VPS才能享有SSL/TLS連線服務。在SSL握手的過程中，不會傳遞域名資訊，所以伺服器端通常返回的是配置中的第一個可用證書；如果要使用多個證書，就只能配置不同的SSL埠或增加IP地址，或者花重金使用一個“多域名SSL證書”或一個“通配型證書”來達到相同效果。

隨著

SNI技術

的出現，在一個IP地址上可以為不同域名分配使用不同

SSL證書

的技術得以實現；這同時意味著，共享IP的虛擬主機也可實現SSL/TLS連線。

SNI技術的實現是用於改善SSL/TLS的技術，它可以在SSLv3/TLSv1中被啟用。當SNI技術實現時，客戶端可以在發起SSL握手請求時提交請求的Host資訊，伺服器接收到資訊後，能夠切換到正確的域，再返回相應的證書。

要使用SNI，需要客戶端和伺服器端同時滿足條件，對於瀏覽器來說，大部分都支援SSLv3/TLSv1，所以都可以享受SNI帶來的便利。對於伺服器來說，Nginx在以SNI為支援的OpenSSL的陪同下即可實現。

以上就是實現HTTPS的5個技術難點，希望大家在進行HTTPS升級的時候，可以順利實現。當然，大家也可以選擇使用又拍雲CDN，又拍雲已經完全攻克了上面提及的技術難點，只需要提供域名，即可輕鬆升級為HTTPS~

推薦閱讀：

免費 SSL 證書申請入口

HTTPS系列乾貨（一）：HTTPS 原理詳解

關於

又拍雲

又拍雲致力於為客戶提供一站式的線上業務加速服務，為使用者網頁圖片、檔案下載、音影片點播、動態內容，全站整體提供加速服務，擁有智慧控制檯面板，具有SSL全鏈路加密最佳化，自定義邊緣規則等特性，同時支援 WebP 、H。265 、Gzip 壓縮、HTTP/2 等新特性，CDN 效能快人一步。另提供安全高可靠的融合雲端儲存，一站式短影片、直播、點播解決方案，實時靈活多終端的雲處理，以及流量營銷等服務。