2. 程式人生 > >基於 Nginx 的 HTTPS 效能優化

基於 Nginx 的 HTTPS 效能優化

阿新 • • 發佈：2018-12-05

前言

分享一個卓見雲的較多客戶遇到HTTPS優化案例。

隨著相關瀏覽器對HTTP協議的“不安全”、紅色頁面警告等嚴格措施的出臺，以及向 iOS 應用的 ATS 要求和微信、支付寶小程式強制 HTTPS 需求，以及在合規方面如等級保護對傳輸安全性的要求都在推動 HTTPS 的發展。

雖然 HTTPS 優化了網站訪問體驗（防劫持）以及讓傳輸更加安全，但是很多網站主趕鴨子上架式的使用了 HTTPS 後往往都會遇到諸如：頁面載入速度變慢、伺服器負載過高以及證書過期不及時更新等問題。

所以本文就來探討一下 HTTPS 的優化實踐。

選型

其實像 Apache Httpd、LigHttpd、Canddy 等 Web 服務軟體都可以設定 HTTPS，但是在相應的擴充套件生態和更新率上都不如 Nginx。 Nginx 作為大型網際網路網站的 Web 入口軟體有著廣泛的支援率，例如阿里系的 Tengine、CloudFlare 的 cloudflare-nginx、又拍雲用的 OpenResty 都是基於 Nginx 而來的，Nginx 是接受過大規模訪問驗證的。同時大家也將自己開發的元件回饋給 Nginx 社群，讓 Nginx 有著非常良好的擴充套件生態。

image

​ 圖1-1 Nginx 在全網的使用情況

所以說 Nginx 是一款很好的 Web 服務軟體，選擇 Nginx 在提升效能的同時能極大的降低我們的擴充套件成本。

新功能

圍繞 Web 服務已經有非常多的新功能需要我們關注並應用了，這裡先羅列相關新功能。

HTTP/2

相比廉頗老矣的 HTTP/1.x，HTTP/2 在底層傳輸做了很大的改動和優化包括有：

  1. 每個伺服器只用一個連線，節省多次建立連線的時間，在TLS上效果尤為明顯
  2. 加速 TLS 交付，HTTP/2 只耗時一次 TLS 握手，通過一個連線上的多路利用實現最佳效能
  3. 更安全，通過減少 TLS 的效能損失，讓更多應用使用 TLS，從而讓使用者資訊更安全

image

在 Akamai 的 HTTP/2 DEMO中，載入300張圖片，HTTP/2 的優越性極大的顯現了出來，在 HTTP/1.X 需要 14.8s 的操作中，HTTP/2 僅需不到1s。

HTTP/2 現在已經獲得了絕大多數的現代瀏覽器的支援。只要我們保證 Nginx 版本大於 1.9.5 即可。當然建議保持最新的 Nginx 穩定版本以便更新相關補丁。同時 HTTP/2 在現代瀏覽器的支援上還需要 OpenSSL 版本大於 1.0.2。

TLS 1.3

和 HTTP/1.x 一樣，目前受到主流支援的 TLS 協議版本是 1.1 和 1.2，分別釋出於 2006年和2008年，也都已經落後於時代的需求了。在2018年8月份，IETF終於宣佈TLS 1.3規範正式釋出了，標準規範（Standards Track）定義在 rfc8446。

image
image

TLS 1.3 相較之前版本的優化內容有：

  1. 握手時間：同等情況下，TLSv1.3 比 TLSv1.2 少一個 RTT
  2. 應用資料：在會話複用場景下，支援 0-RTT 傳送應用資料
  3. 握手訊息：從 ServerHello 之後都是密文。
  4. 會話複用機制：棄用了 Session ID 方式的會話複用，採用 PSK 機制的會話複用。
  5. 金鑰演算法：TLSv1.3 只支援 PFS （即完全前向安全）的金鑰交換演算法，禁用 RSA 這種金鑰交換演算法。對稱金鑰演算法只採用 AEAD 型別的加密演算法，禁用CBC 模式的 AES、RC4 演算法。
  6. 金鑰匯出演算法：TLSv1.3 使用新設計的叫做 HKDF 的演算法，而 TLSv1.2 是使用PRF演算法，稍後我們再來看看這兩種演算法的差別。

總結一下就是在更安全的基礎上還做到了更快，目前 TLS 1.3 的重要實現是 OpenSSL 1.1.1 開始支援了，並且 1.1.1 還是一個 LTS 版本，未來的 RHEL8、Debian10 都將其作為主要支援版本。在 Nginx 上的實現需要 Nginx 1.13+。

Brotli

Brotli 是由 Google 於 2015 年 9 月推出的無失真壓縮演算法，它通過用變種的 LZ77 演算法，Huffman 編碼和二階文字建模進行資料壓縮，是一種壓縮比很高的壓縮方法。

根據Google 釋出的研究報告，Brotli 具有如下特點：

  1. 針對常見的 Web 資源內容，Brotli 的效能要比 Gzip 好 17-25%；
  2. Brotli 壓縮級別為 1 時，壓縮速度是最快的，而且此時壓縮率比 gzip 壓縮等級為 9（最高）時還要高；
  3. 在處理不同 HTML 文件時，brotli 依然提供了非常高的壓縮率；

在相容 GZIP 的同時，相較 GZIP：

  1. JavaScript 上縮小 14%
  2. HTML上縮小 21%
  3. CSS上縮小 17%

Brotli 的支援必須依賴 HTTPS，不過換句話說就是隻有在 HTTPS 下才能實現 Brotli。

ECC 證書

橢圓曲線密碼學（Elliptic curve cryptography，縮寫為ECC），一種建立公開金鑰加密的演算法，基於橢圓曲線數學。橢圓曲線在密碼學中的使用是在1985年由Neal Koblitz和Victor Miller分別獨立提出的。

內建 ECDSA 公鑰的證書一般被稱之為 ECC 證書，內建 RSA 公鑰的證書就是 RSA 證書。由於 256 位 ECC Key 在安全性上等同於 3072 位 RSA Key，加上 ECC 運算速度更快，ECDHE 金鑰交換 + ECDSA 數字簽名無疑是最好的選擇。由於同等安全條件下，ECC 演算法所需的 Key 更短，所以 ECC 證書檔案體積比 RSA 證書要小一些。

ECC 證書不僅僅可以用於 HTTPS 場景當中，理論上可以代替所有 RSA 證書的應用場景，如 SSH 金鑰登陸、SMTP 的 TLS 發件等。

不過使用 ECC 證書有兩個點需要注意：

一、 並不是每一個證書型別都支援的，一般商業證書中帶增強型字眼的才支援ECC證書的簽發。

image

二、 ECC證書在一些場景中可能還不被支援，因為一些產品或者軟體可能還不支援 ECC。 這時候就要虛線解決問題了，例如針對部分舊作業系統和瀏覽器不支援ECC，可以通過ECC+RSA雙證書模式來解決問題。

安裝

下載原始碼

綜合上述我們要用到的新特性，我們整合一下需求：

HTTP/2 要求 Nginx 1.9.5+，，OpenSSL 1.0.2+

TLS 1.3 要求 Nginx 1.13+，OpenSSL 1.1.1+

Brotli 要求 HTTPS，並在 Nginx 中新增擴充套件支援

ECC 雙證書 要求 Nginx 1.11+

這裡 Nginx，我個人推薦 1.15+，因為 1.14 雖然已經能支援TLS1.3了，但是一些 TLS1.3 的進階特性還只在 1.15+ 中提供。

然後我們定義一下版本號：

# Version
OpenSSLVersion='openssl-1.1.1a';
nginxVersion='nginx-1.14.1';

建議去官網隨時關注最新版：

http://nginx.org/en/download.html

https://www.openssl.org/source/

https://github.com/eustas/ngx_brotli/releases

Nginx

cd /opt
wget http://nginx.org/download/$nginxVersion.tar.gz
tar xzf $nginxVersion.tar.gz

OpenSSL

cd /opt
wget https://www.openssl.org/source/$OpenSSLVersion.tar.gz
tar xzf $OpenSSLVersion.tar.gz

Brotli

cd /opt
git clone https://github.com/eustas/ngx_brotli.git
cd ngx_brotli
git submodule update --init --recursive

編譯

cd /opt/$nginxVersion/
./configure \
--prefix=/usr/local/nginx \  ## 編譯後安裝的目錄位置
--with-openssl=/opt/$OpenSSLVersion \ ## 指定單獨編譯入 OpenSSL 的原始碼位置 --with-openssl-opt=enable-tls1_3 \ ## 開啟 TLS 1.3 支援 --with-http_v2_module \ ## 開啟 HTTP/2 --with-http_ssl_module \ ## 開啟 HTTPS 支援 --with-http_gzip_static_module \ ## 開啟 GZip 壓縮 --add-module=/opt/ngx_brotli ## 編譯入 ngx_BroTli 擴充套件 make && make install ## 編譯並安裝

後續還有相關變數設定和設定服務、開啟啟動等步驟，篇幅限制就省略了，這篇文章有介紹在 Ubuntu 下的 Nginx 編譯：https://www.mf8.biz/ubuntu-nginx/ 。

配置

接下來我們需要修改配置檔案。

HTTP2

listen 443 ssl http2;

只要在 server{}  下的lisen 443 ssl 後新增 http2 即可。而且從 1.15 開始，只要寫了這一句話就不需要再寫 ssl on 了，很多小夥伴可能用了 1.15+ 以後衍用原配置檔案會報錯，就是因為這一點。

TLS 1.3

ssl_protocols    TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;

如果不打算繼續支援 IE8，或者一些合規的要求，可以去掉TLSv1。

然後我們再修改對應的加密演算法，加入TLS1.3引入的新演算法：

ssl_ciphers        TLS13-AES-256-GCM-SHA384:TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256:TLS13-AES-128-CCM-8-SHA256:TLS13-AES-128-CCM-SHA256:EECDH+CHACHA20:EECDH+CHACHA20-draft:EECDH+ECDSA+AES128:EECDH+aRSA+AES128:RSA+AES128:EECDH+ECDSA+AES256:EECDH+aRSA+AES256:RSA+AES256:EECDH+ECDSA+3DES:EECDH+aRSA+3DES:RSA+3DES:!MD5;

如果不打算繼續支援 IE8，可以去掉包含 3DES 的 Cipher Suite。

預設情況下 Nginx 因為安全原因，沒有開啟 TLS 1.3 0-RTT，可以通過新增 ssl_early_data on; 指令開啟 0-RTT的支援。

————

實驗性嘗試

眾所周知，TLS1.3 由於更新了很久，很多瀏覽器的舊版本依舊只支援 Draft 版本，如 23 26 28 分別在 Chrome、FirFox 上有支援，反而正式版由於草案出來很久，導致TLS1.3在瀏覽器上相容性不少太好。

可以使用 https://github.com/hakasenyang/openssl-patch/ 提供的 OpenSSL Patch 讓 OpenSSL 1.1.1 同時支援草案23,26,28和正式版輸出。 不過由於不是官方指令碼，穩定性和安全性有待考量。

ECC雙證書

雙證書配置的很簡單了，保證域名的證書有RSA和ECC各一份即可。

  ##證書部分
  ssl_certificate /usr/local/nginx/conf/ssl/www.mf8.biz-ecc.crt; #ECC證書
  ssl_certificate_key /usr/local/nginx/conf/ssl/www.mf8.biz-ecc.key; #ECC金鑰 ssl_certificate /usr/local/nginx/conf/ssl/www.mf8.biz.crt; #RSA證書 ssl_certificate_key /usr/local/nginx/conf/ssl/www.mf8.biz.key; #RSA金鑰

Brotli

需要在對應配置檔案中，新增下面程式碼即可：

    brotli                     on;
    brotli_comp_level          6;
    brotli_min_length 1k; brotli_types text/plain text/css text/xml text/javascript text/x-component application/json application/javascript application/x-javascript application/xml application/xhtml+xml application/rss+xml application/atom+xml application/x-font-ttf application/vnd.ms-fontobject image/svg+xml image/x-icon font/opentype;

為了防止大家看糊塗了，放一個完整的 server{}供大家參考：

    server {
        listen       443 ssl http2; # 開啟 http/2
        server_name mf8.biz www.mf8.biz; #證書部分 ssl_certificate /usr/local/nginx/conf/ssl/www.mf8.biz-ecc.crt; #ECC證書 ssl_certificate_key /usr/local/nginx/conf/ssl/www.mf8.biz-ecc.key; #ECC金鑰 ssl_certificate /usr/local/nginx/conf/ssl/www.mf8.biz.crt; #RSA證書 sl_certificate_key /usr/local/nginx/conf/ssl/www.mf8.biz.key; #RSA金鑰 #TLS 握手優化 ssl_session_cache shared:SSL:1m; ssl_session_timeout 5m; keepalive_timeout 75s; keepalive_requests 100; #TLS 版本控制 ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; ssl_ciphers 'TLS13-AES-256-GCM-SHA384:TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256:TLS13-AES-128-CCM-8-SHA256:TLS13-AES-128-CCM-SHA256:EECDH+CHACHA20:EECDH+CHACHA20-draft:EECDH+ECDSA+AES128:EECDH+aRSA+AES128:RSA+AES128:EECDH+ECDSA+AES256:EECDH+aRSA+AES256:RSA+AES256:EECDH+ECDSA+3DES:EECDH+aRSA+3DES:RSA+3DES:!MD5'; # 開啟 1.3 o-RTT ssl_early_data on; # GZip 和 Brotli gzip on; gzip_comp_level 6; gzip_min_length 1k; gzip_types text/plain text/css text/xml text/javascript text/x-component application/json application/javascript application/x-javascript application/xml application/xhtml+xml application/rss+xml application/atom+xml application/x-font-ttf application/vnd.ms-fontobject image/svg+xml image/x-icon font/opentype; brotli on; brotli_comp_level 6; brotli_min_length 1k; brotli_types text/plain text/css text/xml text/javascript text/x-component application/json application/javascript application/x-javascript application/xml application/xhtml+xml application/rss+xml application/atom+xml application/x-font-ttf application/vnd.ms-fontobject image/svg+xml image/x-icon font/opentype; location / { root html; index index.html index.htm; } }

先驗證一下配置檔案是否有誤：

nginx -t

如果反饋的是：

nginx: the configuration file /usr/local/nginx/conf/nginx.conf syntax is ok
nginx: configuration file /usr/local/nginx/conf/nginx.conf test is successful

就可以重啟 Nginx ，然後到對應網站中去檢視效果了。

驗證

HTTP/2

通過瀏覽器的開發者工具，我們可以在 Network 欄目中看到 Protocol 中顯示 h2 有無來判斷。

image

TLS 1.3

老地方，我們可以通過瀏覽器的開發者工具 中的 Security 欄目看到 Connection 欄目下是否有顯示 TLS 1.3

image

ECC 雙證書

ECC 雙證書配置了以後無非就是在舊瀏覽器設別上的驗證了。這裡用足夠老的上古XP虛擬機器來給大家證明一波。

XP系統上：

image

現代作業系統上的：

image

Brotli

通過瀏覽器的開發者工具，我們可以在 Network 欄目中，開啟具體頁面的頭資訊，看到 accept-encoding 中有 br 字眼就行。

image

總結

通過上述手段應該可以讓 HTTPS 訪問的體驗優化不少，而且會比沒做 HTTPS 的網站訪問可能更快。

這樣的模式比較適合雲伺服器單機或者簡單叢集上搭建，如果有應用 SLB 七層代理、WAF、CDN 這樣的產品可能會讓我們的這些操作都白費。 我們的這幾項操作都是自建的 Web 七層服務，如果有設定 SLB 七層代理、WAF、CDN 這樣設定在雲伺服器之前就會被覆蓋掉。

由於 SLB 七層和CDN這樣的產品會更加追求廣泛的相容性和穩定性並不會第一時間就用上上述的這些新特性（HTTP/2 是普遍有的），但是他們都配備了阿里雲的 Tengine 的外部專用演算法加速硬體如 Intel® QuickAssist Technology(QAT) 加速器可以顯著提高SSL/TLS握手階段效能。 所有 HTTPS 的加密解密都在 SLB 或 CDN 上完成，而不會落到ECS上，可以顯著降低 ECS 的負載壓力，並且提升訪問體驗。

目前雲上的網路產品中能支援四層的都是可以繼續相容我們這套設計的，例如：SLB 的四層轉發（TCP UDP）、DDOS高防的四層轉發。

 

原文連結
本文為雲棲社群原創內容，未經允許不得轉載。

相關推薦

基於 Nginx 的 HTTPS 效能優化實踐

前言 分享一個卓見雲的較多客戶遇到HTTPS優化案例。 隨著相關瀏覽器對HTTP協議的“不安全”、紅色頁面警告等嚴格措施的出臺，以及向 iOS 應用的 ATS 要求和微信、支付寶小程式強制 HTTPS 需求，以及在合規方面如等級保護對傳輸安全性的要求都在推動 HTTPS 的發展。 雖然 HTTPS 優化

基於 Nginx 的 HTTPS 效能優化

前言 分享一個卓見雲的較多客戶遇到HTTPS優化案例。 隨著相關瀏覽器對HTTP協議的“不安全”、紅色頁面警告等嚴格措施的出臺，以及向 iOS 應用的 ATS 要求和微信、支付寶小程式強制 HTTPS 需求，以及在合規方面如等級保護對傳輸安全性的要求都在推動 HTTPS 的發展。 雖然 HTTPS 優化

nginx 配置效能優化

nginx是一個高併發web伺服器，所以沒有很好的優化配置可能會產生效能瓶頸與安全問題。 1.隱藏nginx版本號，防止根據某個軟體版本漏洞來攻擊伺服器  在http模組中新增server_tokens off; 或者在nginx編譯安裝前改掉所有涉及版本號的檔案，具體有哪些檔案有版

基於Spark UI效能優化與除錯——初級篇

Spark有幾種部署的模式，單機版、叢集版等等，平時單機版在資料量不大的時候可以跟傳統的java程式一樣進行斷電除錯、但是在叢集上除錯就比較麻煩了...遠端斷點不太方便，只能通過Log的形式進行資料分析，利用spark ui做效能調整和優化。 那麼本篇就介紹下如何利用Ui做效能分析，因為本人的經驗也不是很

[看圖說話] 基於Spark UI效能優化與除錯——初級篇

Spark有幾種部署的模式，單機版、叢集版等等，平時單機版在資料量不大的時候可以跟傳統的java程式一樣進行斷電除錯、但是在叢集上除錯就比較麻煩了...遠端斷點不太方便，只能通過Log的形式進行資料分析，利用spark ui做效能調整和優化。 那麼本篇就介紹下如何利用Ui做效

Nginx配置效能優化

大多數的Nginx安裝指南告訴你如下基礎知識——通過apt-get安裝，修改這裡或那裡的幾行配置，好了，你已經有了一個Web伺服器了。而且，在大多數情況下，一個常規安裝的nginx對你的網站來說已經能很好地工作了。然而，如果你真的想擠壓出Nginx的效能，你必須更深入一些。

基於nginx建立CA實現https加密連接

nginx https openssl 前幾篇博客分別實現了nginx的http訪問和apache的https加密連接，那麽現在就將它們組合在一起，實現基於nginx的https加密連接。一、環境準備 這次我還是準備了兩個虛擬機和一臺真實計算機，其中一臺IP為172.16.128.7

百萬併發下的 Nginx 效能優化之道，值得看！！！

Nginx 很火，火到無論是創業公司，還是 BAT 等一線網際網路公司，都會使用Nginx。因為它就像一個萬能藥，在任何存在效能需求的場合總能找見它的身影。它可以輕鬆在百萬併發連線下實現高吞吐量的 Web 服務，同時諸多應用場景下的問題都可以通過種種 Nginx 模組得以解決，而我們所需的工

Nginx 效能優化（配置檔案詳解）

  隨著訪問量的不斷增加，需要對 Nginx 和核心做相應的優化來滿足高併發使用者的訪問，那下面在單臺 Nginx 伺服器來優化相關引數。 Nginx.conf 配置優化： worker_processes 8; nginx 程序數，建議按照 cpu 數目來指定，一般為它的倍數。worke

新增Nginx http_concat模組優化前端Js效能

宣告：本博文用於學習總結及工作心得 環境: Ubuntu16.04、Tomcat7、Nginx 1.5.6 發現問題： 最近在生產伺服器使用過程中，發現一個以前被忽略的問題；專案中如果存在大量的js,css或者其它一些靜態資源，每次訪問的時候，都需要發出大量的請求，造成載入速度過慢；

Nginx 效能優化實踐

概要： Nginx 反向代理與負載均衡 Nginx 實現快取記憶體 Nginx 效能引數調優 一、Nginx 反向代理實現 知識點： 反向代理基本配置 負載均衡配置與引數解析 負載均衡演算法詳解 反向代理基本配置 提問：什麼是反向代理其與正向代理有什麼區別？

Linux運維Nginx軟體優化之Nginx效能優化

1. 優化nginx worker進行個數 nginx服務主要有兩個重要程序： 01) master程序：可以控制nginx服務的啟動 停止 或重啟 02) worker程序：處理使用者請求資訊，幫助使用者向後端服務進行請求(php mysql) 新增worker程序方法

基於Nginx實現10萬+併發，你應該做的Linux核心優化

由於預設的Linux核心引數考慮的是最通用場景，這明顯不符合用於支援高併發訪問的Web伺服器的定義，所以需要修改Linux核心引數，是的Nginx可以擁有更高的效能； 在優化核心時，可以做的事情很多，不過，我們通常會根據業務特點來進行調整，當Nginx作為靜態web內容

Nginx-效能優化-ab壓力測試工具

章節目錄 nginx 效能優化的點 當前系統性能的評估 ab 壓力測試工具使用 1.nginx 效能優化的點 當前系統結構瓶頸 可用方案：觀察指標-top、壓力測試-substatus、線上系統可以支撐的併發。 清除當前架構、當前業務，每個服務可以支撐多少併發,多少QPS。 瞭解業

大型網際網路公司必備的架構技術棧——分散式架構、高可擴充套件、高效能、高併發、效能優化、Spring boot、Redis、ActiveMQ、Nginx、Mycat、Netty、Jvm大型分散式專案實戰

效能優化 JVM調優 Java程式效能優化 Tomcat Mysql Spring IOC Spring AOP Spring MVC Spring 5新特性 Mybatis 分散式架構 架構核心服務層技術 架構關鍵技術設施 分散式訊息通訊 非同

Java高架構師、分散式架構、高可擴充套件、高效能、高併發、效能優化、Spring boot、Redis、ActiveMQ、Nginx、Mycat、Netty、Jvm大型分散式專案實戰學習架構師之路

工作1-5年開發經驗，當你們提出漲工資的時候，或者要offer的時候底氣怎麼樣，是不是底氣十足，不給漲工資就辭職，是不是有自信提出來主管、或者是專案經理都能同意，他們相當設法把你留住。如果這樣你才是成功。什麼技術都沒有何談工資！ 給你分析一下這些技術，給大家羅列一些技術，看

網頁效能優化開啟Nginx的 gzip 壓縮功能

開啟網站的 gzip 壓縮功能，通常可以高達70%，也就是說，如果你的網頁有30K，壓縮之後就變成9K， 對於大部分網站，顯然可以明顯提高瀏覽速度（注：需要瀏覽器支援）。 nginx 需先編譯gzip模組 編輯 nginx 的配置檔案 vi /etc/nginx/nginx.conf 在 Gzi

百萬併發下的 Nginx 效能優化之道

Nginx很火，因為它就像一個萬能藥，在任何存在效能需求的場合總能找見它的身影。它可以輕鬆在百萬

Nginx安裝與效能優化

NGINX 安裝 前提：完整的編譯環境 gcc g++ make 開發庫等 系統：Linux Ubuntu-server-12.04-64bit 核心：Linux 3.13.0-68-generic apt-get install build-esse

keepalived https健康檢查效能優化

       轉載請註明出處： http://blog.csdn.net/hliyuxin/article/details/43018309        之前線上LVS如果https健康檢查的rs 配置較多，會出現cpu利用率高的問題。通過工具測試發現，整個https健康