ondrej 的 nginx PPA 支援 SPDY + HTTP/2 了...

直接跑去問 ondrej 有沒有意願把 CloudFlare 提供的 patch 放進去,結果也很順利的就更新了:「nginx 1.11.1 (security release) and CloudFlare SPDY + HTTP2 patch」(先前標題還打錯... XDDD)。

所以現在在 nginx PPA 裡的版本同時支援 SPDYHTTP/2 了,可以參考「SSL Server Test: blog.gslin.org (Powered by Qualys SSL Labs)」。

可以看到舊的行動平台都透過 SPDY 連上來了,速度應該會比之前順不少...

CloudFlare 提供的 SPDY + HTTP/2 patch 可以在 nginx 1.11 上面跑了...

SPDY 對行動裝置還是很重要,尤其是 Android 裝置在 5.0 之後才有支援 HTTP/2,但在 3.0 之後就有支援 SPDY,也就是超過一半的 Android 用戶只有 SPDY 但沒有 HTTP/2 能力:

查資料的時候發現當初 CloudFlare 提供的 SPDY + HTTP/2 patch 本來只能對 nginx 1.9.7 更新 (參考之前寫的「CloudFlare 放出可以同時支援 HTTP/2 與 SPDY 的 nginx patch」),後來有人再更新到 1.9.15,而在留言的地方也可以看到有人回報在 1.11.0 上面可以跑:「Update NGINX SPDY patch for 1.9.15」:

Works fine against nginx 1.11.0 and OpenSSL 1.0.2h (with ChaCha20 patch). I am building nginx as an Ubuntu 16.04 package.

而最新版 1.11.1 只有一個安全性更新,應該也可以跑... 來找看看會不會有人包 ppa 出來。

在 Ubuntu 14.04 上執行支援 ALPN 的 nginx

在「Migrate to Ubuntu 16.04」這邊看到換 16.04 的理由:

支援 http2 是升級到 Ubuntu 16.04 很大的動機。原因是前一版 14.04 裡 openssl 太舊,不支援 ALPN 協定,Chrome 瀏覽器又放棄了 NPN 的舊協定,詳細。你要嘛自己編譯 nginx ,要嘛就是升級到 16.04 才能解決。選哪個方法就看各公司的政策,升了 OS 問題就直接解決了。

不過 Ondřej Surý 包了一個有新版 openssl 的套件出來,所以在 12.04 或是 14.04 都可以使用 ALPN 版本的 nginx:「PPA for NGINX with HTTP/2 on Ubuntu 12.04 LTS and higher」。

目前 16.04 上的 Puppet 爛了不少東西,還是得靠 14.04 吃飯... orz

Google Chrome 51 出版,SPDY 被拔掉,HTTP/2 只支援 ALPN

Google Chrome 剛剛出了 51 版:「Stable Channel Update」。

除了界面的改變外,對效能最主要的改變就是 SPDY 被拔掉,HTTP/2 的 NPN 支援也被拔掉:「Transitioning from SPDY to HTTP/2」:

To better align with Chrome's release cycle, SPDY and NPN support will be removed with the release of Chrome 51.

又有一波 migrate 功夫要做了...

Dropbox 從 SPDY 切換到 HTTP/2 發現的現象

Dropbox 將本來的 SPDY 切換到 HTTP/2 後整理了不少資料:「Enabling HTTP/2 for Dropbox web services: experiences and observations」。

大多數都是效能的改善,但「Increased latency for POST requests.」這段頗有趣的,找出了 nginx 的 bug:

POST 的 latency 大約增加了 50%,而實際追蹤問題發現是 nginx 中 SETTINGS_INITIAL_WINDOW_SIZE 預設值的問題,然後提出 patch 改善:「[nginx] HTTP/2: rewritten handling of request body.」:

There is a small issue with setting `SETTINGS_INITIAL_WINDOW_SIZE` to 0: now when client tries to POST data it needs to wait for an additional RTT(between `send HEADERS` and `recv WINDOW_UPDATE`) to start sending data.

CloudFlare 放出可以同時支援 HTTP/2 與 SPDY 的 nginx patch

CloudFlare 放出可以同時支援 HTTP/2SPDYnginx patch:「Open sourcing our NGINX HTTP/2 + SPDY code」。

不過 patch 的版本有點舊:

We've extracted our changes and they are available as a patch here. This patch should build cleanly against NGINX 1.9.7.

如同原文下面 comment 提到的問題,nginx 1.9.7 太舊了 (2015/11/17 放出的版本),到現在有出了不少安全性更新,以及對 HTTP/2 的 bugfix。應該會需要再等官方把新版的 patch 拿出來改之後才能用。

nginx 引入 Dynamic Module 架構

nginx 在 1.9.11 版引入了 Dynamic Module,能夠更方便的決定要掛哪些模組使用了:「Introducing Dynamic Modules in NGINX 1.9.11」。

從以往的:

多了一種選擇:

也因此多了 load_module 功能可以用:

To load a module at runtime, include the new load_module directive in the main context, specifying the path to the shared object file for the module, enclosed in quotation marks. When you reload the configuration or restart NGINX, the module is loaded in. You can specify a path relative to the source directory, as in these examples, or a full path.

load_module "modules/ngx_http_geoip_module.so";
load_module "modules/ngx_stream_module.so";

Google 推出 nginx 上的 PageSpeed 模組

Google 推出了 nginx 上的 Page Speed 模組:「ngx_pagespeed」,想做的事情與 apache 上的 mod_pagespeed 相同,利用各種技術加速網頁的速度:

Nginx module created by Google to help Make the Web Faster by rewriting web pages to reduce latency and bandwidth. It started as a port of mod_pagespeed to Nginx, and for now the documentation links below still all point to mod_pagespeed's documentation.

看之後會不會變成 PPA 裡的一包吧...

CloudFlare 有計劃要放出對 nginx 的 HTTP/2 + SPDY patch

nginx 在 1.9.5 後移除了對 SPDY 的支援,只支援 HTTP/2,剛剛找其他資料的時候在「HTTP/2 is here! Goodbye SPDY? Not quite yet」這邊發現 CloudFlare 的人有打算放 patch,讓 nginx 可以同時支援 HTTP/2 與 SPDY:

同時也可以看到有人抱怨 caniuse 上面的資料與實際使用的情況有蠻大的差距,拿 caniuse 來說服人不太準確。

另外也發現我自己的 blog 有時候 HTTP/2 不會啟用 (透過「HTTP/2 and SPDY indicator」觀察),不知道是什麼原因,也許 nginx 的時候還是有 bug?

nginx 的 TCP Fast Open

在「Enabling TCP Fast Open for NGINX on CentOS 7」這邊看到 nginxTCP Fast Open (TFO,RFC 7413) 的支援早在 1.5.8 就有了,而 Linux Kernel 也是 3.7 之後就全面支援了。

TCP Fast Open 利用第一次連線後產生的 TCP cookie,在第二次連線時可以在 3-way handshake 的過程就開始傳輸,藉此大幅降低 latency。

設定方法不難,先在 kernel 設定 net.ipv4.tcp_fastopen=3,再加上 fastopen=number 就可以了,像是這樣:

listen 80 fastopen=256

不過目前 NGINX Mainline 上的版本好像沒有編進去,暫時沒辦法測...