為什麼 Chrome 又不支持我的 HTTP/2 網站了?
發生了什麼?
伺服器端
我們知道,最初的 Web 訪問協議是 HTTP/1,包括以前的 HTTP/1.0 和現在大部分網站採用的 HTTP/1.1(HTTP/0.9 是試驗性協議,已經廢棄)。但是隨著 Web 應用越來越複雜,之前的 HTTP/1.x 協議就看起來不能滿足日益龐雜的 Web 服務需求了。比如說,明文請求、請求復用等問題。因此,谷歌就開發了一個新的傳輸層協議,名為 SPDY。由於這個新的協議用了的人都說好,因此谷歌就把這個協議提交到了 IETF,然後大家覺得,SPDY 這名字不好聽(SPDY 是谷歌的註冊商標),就乾脆叫 HTTP/2 吧!
SPDY 協議是基於 SSL/TLS 的,谷歌開發了一個名為 下一代協議協商 (NPN)的 SSL/TLS 擴展,用於在客戶端連接伺服器時協商是否採用 HTTP/2 協議。SPDY 協議是由 Web 伺服器所實現支持的,而 NPN 則是由 OpenSSL 等 SSL 實現支持的。
但是,隨著 SPDY 被提交到 IETF,然後變成了 HTTP/2 協議,谷歌也放棄了 SPDY 的開發,全力投入到了 HTTP/2 的開發中,之前所採用 NPN 也被一種新的協商協議 ALPN —— 應用層協議協商 所替代。NPN 和 ALPN 是不兼容的,它們的主要不同是:
- NPN 是伺服器發送所支持的協議列表,由客戶端進行選擇。而 ALPN 則是客戶端發送該列表,由服務端選擇。
- 在 NPN 中,最終的選擇結果是在 Change Cipher Spec 之後發送給服務端的,也就是說是被加密了的。而在 ALPN 中,所有的協商都是明文的。
這樣做的好處主要是安全性方面的考慮,但是這造成了一個問題就是,NPN 已經廣泛地被 OpenSSL 支持,而 ALPN 則目前只有最新的 openssl-1.0.2 才支持。當前的幾個主流 Linux 發行版的 OpenSSL 版本以及支持的協商協議如下:
Linux 發行版 | OpenSSL 版本 | 所支持的協商協議 |
---|---|---|
CentOS/Oracle Linux/RHEL 5.10+ | 0.9.8e | 不支持 |
CentOS/Oracle Linux/RHEL 6.5+, 7.0+ | 1.0.1e | NPN |
Ubuntu 12.04 LTS | 1.0.1 | NPN |
Ubuntu 14.04 LTS | 1.0.1f | NPN |
Ubuntu 16.04 LTS | 1.0.2g | ALPN 和 NPN |
Debian 7.0 | 1.0.1e | NPN |
Debian 8.0 | 1.0.1k | NPN |
從上面我們可以看到,基本上所有的伺服器級的 Linux 發行版都不支持 OpenSSL 及 ALPN,唯一支持的 Ubuntu 16.04 LTS 顯然用的不會很多。不要小看這 0.0.1 的版本差異,對於別的軟體來說這 0.0.1 的差異基本上可以忽略,但是對於 OpenSSL 來說,那就是兩個版本代際。OpenSSL 是個相當底層的庫,很多重要的軟體都依賴於它,因此各個發行版在升級 OpenSSL 時採用的態度是相當保守,比如我們可以看看 CentOS 系統中有哪些軟體使用了 OpenSSL:
$ lsof | grep libssl | awk '{print $1}' | sort | uniq
anvil
fail2ban
gdbus
gmain
httpd
postfix
mysqld
NetworkManager
nginx
php-fpm
puppet
sshd
sudo
tuned
zabbix_agent
沒有經過足夠的測試,Linux 發行版是不會在產品級(伺服器級)的環境中隨便升級的。為了解決舊版本(1.0.1)中的安全問題,他們寧可將新的版本(1.0.2)中安全修復移植回舊版本,也不會升級到有新功能的新版本(1.0.2),這就是你見到了各種 1.0.1e、1.0.1k 這樣的版本號的原因。
當然,你可以自己編譯一個最新 OpenSSL 替代你系統中的 openssl-1.0.1,但是我想你不會這樣做的,是吧?
順便提一句,NPN 和 ALPN 可以並存,但是會客戶端會優先選擇 ALPN。
瀏覽器端(Chrome)
從 Chrome 51 開始,谷歌就去掉了對 SPDY 的支持,不過這不是個事,因為不但使用 SPDY 的 Web 伺服器比較少,而且從 SPDY 升級到 HTTP/2 也很簡單,這方面 Nginx、Apache 等伺服器的配置都很簡單。
但不幸的是,在 Chrome 51 中,谷歌也去掉了對 NPN 的支持!如果你的 Web 伺服器使用的是 openssl-1.0.2 以下的版本,不支持 ALPN 協商,那麼 Chrome 51 及以後版本就會以 HTTP/1 協議訪問你的網站。
谷歌對放棄 NPN 支持做了一個簡短的解釋,但是不管怎麼說,NPN 協議在 Chrome 51 之後的版本不會再次回來了。而另一方面,OpenSSL 在 2016 年 12 月 31 日之後也不會繼續發布 openssl-1.0.1 系列的新版本了,安全修復到此為止。
而在這種情況下,你原本支持 HTTP/2 的網站通過連接復用等 HTTP/2 所提供的新特性,在 Chrome 下訪問取得了不錯的體驗,而現在又跌回了之前的殘舊狀態。
怎麼辦呢?
有幾種辦法:
換瀏覽器
山不來就我,我去就山。Chrome 51+ 不支持帶 NPN 的 HTTP/2 網站,作為瀏覽者,你可以使用其它的瀏覽器,比如 Safari、Edge 之類的。這樣,你就可以用新的協議來訪問世界上那 10% 支持 HTTP/2 的 Web 伺服器了。
但是,作為伺服器運營者,你卻不能忽視高達 50% 以上的 Chrome 用戶。
換伺服器
如上面所示,Ubuntu 16.04 LTS 是目前唯一官方支持 openssl-1.0.2 的 Linux 發行版,如果你一直採用 Ubuntu 做伺服器,考慮一下升級吧。LTS 版本的支持期長達五年。
當然,在產品環境中,即便你是 Ubuntu 伺服器,更新版本也是一件重大事宜,宜慎思之。
重新編譯
既然換伺服器不是一個好的選擇,那你還有一個方案,就是使用新的 openssl-1.0.2 源代碼重新編譯你的 Web 伺服器,比如 nginx。
下面我簡單介紹一下如何用 openssl-1.0.2 來編譯 nginx。(1.0.2 系列的最新版本是 1.0.2j,當然你要非用 1.1.0,我也無話可說……)
首先下載並解壓 openssl-1.0.2j:
# wget https://www.openssl.org/source/openssl-1.0.2j.tar.gz
# tar -zxvf openssl-1.0.2j.tar.gz
然後在編譯 nginx 的時候使用 --with-openssl=../openssl-1.0.2j
選項以及你的其它選項:
./configure --with-openssl=../openssl-1.0.2j --with-http_v2_module --with-http_ssl_module
配置並編譯之後,你可以用 nginx -V
來看一下你的 nginx 中的 OpenSSL 版本。
這種自行編譯的好處是靈活性高,但是你需要隨時注意各個組件是否有嚴重的安全漏洞,並在出了修復版本之後重新編譯。
容器
除了自己編譯之外,如果你的系統環境中已經有了容器支持,你還可以在容器中運行一個 Ubuntu 16.04 LTS,並將 Web 伺服器運行在其中。
總結
以上就是 HTTP/2 和 Chrome 之間的故事,你準備去升級 HTTP/2 支持了嗎?要知道相比 HTTP/2 的訪問體驗,你肯定不會想再回到 HTTP/1 了。
本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive