nginx的http2.0性能太逆天了，HTTPS網站性能優化

m## 關於http2.0
請閱讀： [HTTP 2.0的那些事][(http://mrpeak.cn/blog/http2/)

背景

我們七層負載層，使用了5臺24U+64G內存的物理機支行nginx做https加解密與proxy_pass。每天上下班時段，5臺機CPU基本在50%左右，算是計算型。
優化手段：keepalive、換TLS1.2加密算法優化(參考：1,2)等，收效不大。
特別簡明一下keepalive選項，不論服務端如何支持，關鍵是客戶端不跟你keep，你玩個屁。

測試過程

• 硬件： 24U+64G物理機2臺，1臺跟測試，1臺跑ngx； 同個局域網內，1GB網卡。

• nginx -V:

  version: openresty/1.9.7.3
  built by gcc 4.8.5 20150623 (Red Hat 4.8.5-4) (GCC)
  built with OpenSSL 1.0.1e-fips 11 Feb 2013
  TLS SNI support enabled
  –with-http_v2_module

• Apache的ab壓測工具: yum安裝

• boom 是模擬ab的golang實現的壓測工具: https://github.com/rakyll/boom
• nghttp2 的 h2load 壓測工具: https://github.com/tatsuhiro-t/nghttp2
• CentOS-7 64位
• 測試文件大小：5k，10k的圖片，作靜態文件的https測試。
• 測試過程簡單來看參數：-c=100~3000，-n=1k~10kw 的各種組合, 使用h2load時-m=1~1000都有試過，-m範圍大小，對http2結果影響不太大。

圖：

放流量圖你就明白了：

下圖爲使用ab與boom時：

此時ab與boom都有使用-k，反正怎麼玩，測量與時間都大概在這個水平。
例如以下命令，基本上要跑個半小時：

boom -c 1000 -n 1000000 -allow-insecure https://172.16.9.234/5k.jpg
ab -c 1000 -n 1000000 -khttps://172.16.9.234/5k.jpg

參數不變換成http2時：

h2load -c 1000 -n 1000000 -m1 https://172.16.9.234/5k.jpg

h2load運行結果如下：

再有下圖爲h2load測試http2時：

千兆網卡，流出流量全滿上。

結論

以下結論經過多次重複測試，只代表本人意見，轉載請註明from：toontong.

1. 同等併發數下，http2.0只用了43秒傳輸完4.3G數據；而http1.1用40多分鐘。
2. 單論傳輸性能提升10倍不止，對我們關鍵的https CPU佔用效果非常明顯。
3. 對web服務整體性能提升當然沒10倍，原因還有連接建立在需時等，更多原因要深研http2原理了。
4. go1.6後纔有http2-client庫的支持，低版本go感覺可以使用https://github.com/tatsuhiro-t/go-nghttp2
5. 如果真普及http2.0，對整個互聯流量，互聯網公司的機器節約，都是大大福音。

---