Tag: http

讓 nginx 看到 5xx 回應時，去另外一台有開 debug-mode 的 server 上再跑一次

Debug 模式會比一般的模式來的慢，但可以看到更多資訊。以往的問題是 5xx 難以重製，而 NGINX 的「Capturing 5xx Errors with a Debug Server」這篇文章介紹了如何用 nginx 實作標題的功能。

如果是隨機造成的問題就沒辦法重製，但如果是 client 的狀態造成的問題，就很有可能可以抓出來... 不是解決所有問題，但可以幫助解掉以前不太好解的狀況。

利用 HSTS 資訊得知網站紀錄的 sniffly

看到「sniffly」這個工具，可以利用 HSTS 資訊檢測逛過哪些網站，程式碼在「diracdeltas/sniffly」這邊可以找到：

Sniffly is an attack that abuses HTTP Strict Transport Security and Content Security Policy to allow arbitrary websites to sniff a user's browsing history. It has been tested in Firefox and Chrome.

測試網站則可以在這邊看到，作者拿 Alexa 上的資料網站來掃，所以熱門網站應該都會被放進去...

主要是利用 HSTS + CSP policy 的 timing attack (有逛過網站而瀏覽器裡有 HSTS 時的 redirect 會比較快，沒有逛過的時候會因為有網路連線而比較慢)：

Sniffly sets a CSP policy that restricts images to HTTP, so image sources are blocked before they are redirected to HTTPS. This is crucial! If the browser completes a request to the HTTPS site, then it will receive the HSTS pin, and the attack will no longer work when the user visits Sniffly.

When an image gets blocked by CSP, its onerror handler is called. In this case, the onerror handler does some fancy tricks to time how long it took for the image to be redirected from HTTP to HTTPS. If this time is on the order of a millisecond, it was an HSTS redirect (no network request was made), which means the user has visited the image's domain before. If it's on the order of 100 milliseconds, then a network request probably occurred, meaning that the user hasn't visited the image's domain.

由於這個技巧，HTTPS Everywhere 必須關閉才會比較準確。

nginx 1.9.6 釋出

在 nginx 的官網上可以直接看到連結，點進 CHANGES 後可以看到兩項關於 HTTP/2 的修正：

    *) Bugfix: a segmentation fault might occur in a worker process when
       using HTTP/2.
       Thanks to Piotr Sikora and Denis Andzakovic.

    *) Bugfix: the $server_protocol variable was empty when using HTTP/2.

    *) Bugfix: backend SSL connections in the stream module might be timed
       out unexpectedly.

    *) Bugfix: a segmentation fault might occur in a worker process if
       different ssl_session_cache settings were used in different virtual
       servers.

    *) Bugfix: nginx/Windows could not be built with MinGW gcc; the bug had
       appeared in 1.9.4.
       Thanks to Kouhei Sutou.

    *) Bugfix: time was not updated when the timer_resolution directive was
       used on Windows.

    *) Miscellaneous minor fixes and improvements.
       Thanks to Markus Linnala, Kurtis Nusbaum and Piotr Sikora.

關於 HTTP/2 的錯誤修正意外的少 (畢竟 1.9.5 是第一個正式版)，看起來 codebase 已經穩下來了？話說 NGINX Mainline 這邊是不打算更新了嗎...

Apache 2.4.17：內建支援 HTTP/2

在 Zite 上突然看到 mod_h2 的文章，想說不是早就放出來很久了嗎... 仔細看才發現是 Apache HTTP Server 2.4.17 發行了：「how to h2 in apache」。

Support for HTTP/2 is finally being released with Apache httpd 2.4.17! This pages gives advice on how to build/deploy/configure it. The plan is to update this as people find out new things (read: bugs) or give recommendations on what works best for them.

另外在「Apache HTTP Server 2.4.17 Released」這邊可以看到公告，不過官方每次改版都直接改掉這個檔案 (沒有存檔)，如果要看歷史紀錄的話到 Internet Archive: Wayback Machine 的頁面上看吧：「https://web.archive.org/web/*/https://www.apache.org/dist/httpd/Announcement2.4.html」。

這樣兩個主流 web server 都支援 HTTP/2 了，接下來最主要的問題是 Android 對 HTTP/2 的支援度：「HTTP/2 protocol」，要等舊版逐漸淘汰掉...

HAProxy 1.6 的兩個大功能：Quote 以及 Lua

HAProxy 1.6.0 出版的公告文章：「[ANNOUNCE] HAProxy 1.6.0 released」。

兩個大功能，第一個是「It’s 2015, let’s use QUOTE in configuration file」，可以用引號了... 另外一個是「Lua Scripting」，需要 Lua 5.3+。

還有提到一些改進，像是支援 SNI，以及對 HTTP/2 的計畫。

CloudFlare 跟百度合作進入中國市場

昨天的大新聞，CloudFlare 宣佈跟百度合作進入中國市場：「How We Extended CloudFlare's Performance and Security Into Mainland China」。

在「China network」這邊可以看到各種限制，首先是需要有牌 (ICP) 才能用：

CloudFlare customers that wish to serve traffic for their domains across the China network must possess a valid Internet Content Provider (ICP) license. An ICP license is a Chinese government issued license required to host or cache Internet content within mainland China. Learn more about how you can obtain an ICP license here.

另外是不支援 HTTPS：

For the moment the China network does not support HTTPS traffic (HTTP only). Support for SSL/TLS will be made available in the coming months.

目前只開放給 Enterprise 用戶：

Initially, the China network will be limited to Enterprise customers. Over time, as we are better able to operationalize the onboarding of customers, we hope to extend the benefits to all plan levels.

由於要 ICP 的關係，對於境外網站沒有太多幫助。另外也不確定是不是還是用 Anycast 技術，如果是的話就要煩惱某些網站的流量有機會被導到中國了。

為了解決 HiNet 到 CloudFlare 機房品質不好而做的掙扎...

前幾天在「TVBS 的 CloudFlare 客製化...」這邊提到這件事情，當天就先隨手測了一些東西。

首先是 CloudFlare 的服務 IP 是互通的，也就是說，我就算拿其他人的 CNAME mapping 來用，只要有送出對應的 Host: 或是 SNI (for HTTPS) 就會通，而 TVBS 當時的 IP address (以及網段) 對於台灣 HiNet 使用者剛好會導到美國機房，還算可以用。

另外 CloudFlare 有提供列表 (文字格式，一行一個網段)，分別是 IPv4 的 https://www.cloudflare.com/ips-v4 以及 IPv6 的 https://www.cloudflare.com/ips-v6。

所以就有幾種組合了，一種是寫 Google Chrome 的 extension 直接改 IP address，不過看了看 JavaScript APIs - Google Chrome 想不出來怎麼寫。

另外一個是先用 iptables 把這些網段的流量導去美國的 CloudFlare 機房。結果這時候發現 HiNet 到 TVBS 已經改回到香港機房了 orz

實際抓了一下發現 188.114.97.100 在巴西機房 (GRU 是 IATA 代碼)，就變成只是測試看看這有沒有用了：

$ curl -x http://188.114.97.100:80/ http://s.plurk.com/cdn-cgi/trace
fl=42f16
h=s.plurk.com
ip=114.32.152.63
ts=1441004146.723
visit_scheme=http
uag=curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
colo=GRU
spdy=off

由於是自己機器出去的封包，不能用 PREROUTING 做，要用 OUTPUT 做：

iptables -t nat -A OUTPUT -d 190.93.240.0/20 -j DNAT --to-destination 188.114.97.100

然後再直接連到 s.plurk.com 就可以看到：

$ curl http://s.plurk.com/cdn-cgi/trace
fl=42f16
h=s.plurk.com
ip=114.32.152.63
ts=1441004011.195
visit_scheme=http
uag=curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
colo=GRU
spdy=off

不過巴西也太遠了點，而且不知道哪天這段 IP 又會被 anycast 進去... orz

關於各家 CDN 的選擇...

在使用 CDN 前，先考慮上 SPDY 或 HTTP/2 (i.e. 全站 HTTPS)，改善的效果跟 CDN latency 帶來的效益有得拼。尤其是 server 放在美國機房的情況，SPDY 與 HTTP/2 帶來的效能提昇是相當明顯的。

會寫這篇是因為這兩個禮拜意外被問到好幾次，所以來整理幾家如果讓我來選，我會選擇的 CDN。至少再被問到的時候可以直接從這邊開始說明。

下面的圖是從我家裡 HiNet 光世代測試的結果 (最後是走兩條電話線)，所以會有個 10ms 的 latency 基底，如果要計算 latency 的效能影響請考慮進去。

Akamai

先講 Akamai。

Akamai 的歷史很久了，再加上併購了不少公司，所以產品成熟度很夠，你要什麼產品都有提供，只要拿的出錢就可以。

KKBOX (敝公司) 用過 PMD、DSD、DSA 三個產品，其中 PMD 與 DSD 只有保障服務可靠度 (availability)，DSA 還有保障效能提昇 (performance)。早期是用 PMD + DSD，現在改用 PMD + DSA。

在功能面上，雖然 Akamai 是大公司，但各種新功能跟的蠻快的。主要就是為了 SPDY 以及之後預期會有的 HTTP/2 而選了 DSA，另外也剛好有效能提昇 SLA 需求而一併升級。

品質上來說，Akamai 在全球的點 (PoP) 夠密集 (差不多是有 ISP 機房就會放)，當初會選擇 Akamai 是為了敝公司在泰國與馬來西亞兩個地區的用戶，而 PMD 在這兩個地區的品質都還不錯。

在台灣也有好幾個點，但除非你買的產品線等級夠高 (i.e. 合約有保證 performance，像是 DSA)，不然平常不會分到台灣的點，以最近的情況來說是深夜才有機會指回台灣。

這是 Akamai DSD 的圖：

而這是 DSA 的圖：

可以看得出來 latency 的差異。

在 SLA 的部份，是目前少數有提供保證 100% availability SLA 的 CDN。

成本考量上，價錢是最硬的，但由於 CDN 這個領域競爭得很激烈，只要超過某一個 commit level 後有機會壓到跟 CloudFront 拼的價錢，也就是說，有經濟規模就有機會在台灣變成重點客戶而坐下來談價錢 (不確定多少，但 CloudFront 的第一個級距 10TB/month 應該是基本吧)。

另一方面，因為透過業務談價錢，會需要開會討論，所以對使用方的人力成本偏高。不過因為如此，台灣有 Akamai 辦公室與經銷商，稅務會比較好處理。(參考：「零壹科技正式代理Akamai 推展雲端優化服務解決方案」)

總結來說，適合已經有量，而且台灣是重要客群的公司。

EdgeCast

再來講 EdgeCast。

EdgeCast 的功能比 Akamai 少很多，自從被 Verizon 買進去後就沒推出什麼比較有趣的產品了 (參考「Verizon 打算買下 EdgeCast...」)，感覺上是電信公司買來補產品線的啦，所以也不用太期待之後會有什麼新產品推出來...

比較特別的是 EdgeCast 跟 HiNet 有合作 (參考「EdgeCast 與 HiNet 合作...」)，所以也是少數在台灣有機房的 CDN 業者。在台灣的 PoP 據說是在高雄 HiNet 機房內：

另外 EdgeCast 有 Network Map 可以看在全球有哪些 PoP。

價錢上聽朋友說比 Akamai 低了不少，不過自己沒經手過無法確認。同樣是透過業務談，所以也有類似的人力與稅務優缺點。不過據說也可以直接 bypass 國內的業務，直接跟國外談，不過這樣搞境外稅務的問題就要自己解決了。

綜合來說，也是適合已經有量，由於沒有 SPDY 與 HTTP/2，就看 PoP 的點決定合不合用。

CloudFront

Amazon CloudFront 算是很多 startup 的第一嘗試，no commit 以及帳單在同一張可以省下不少功夫。

在 CloudFront 上分成三個不同等級的產品，通常下載用可以拿 Price Class 100 (只有北美與歐洲的 PoP)，而真正要加速用的再拿 Price Class All 用。

而功能面上，CloudFront 的功能說不定還比 EdgeCast 多，不過還是沒支援 SPDY 或 HTTP/2，所以基本上是靠台灣的 PoP 在撐 latency 的。而台灣的 PoP 據說在內湖：

價錢在官網上就擺出來給大家看了，比較大的缺點是不同區域是分開算錢的，不過是可以找台灣的經銷商談 commit level 包價錢啦，不過價錢還是很難談。

綜合來說，適合 startup 用。

CloudFlare

CloudFlare 也是很多人問的一個選擇，不看流量價錢固定是賣點之一。

功能非常多，SSL certificate 涵蓋在所有產品內，另外也是目前少數支援 SPDY 的 CDN。技術上是走 Anycast 而非 GeoDNS dispatch。

HiNet 過去的品質爛到爆炸 (重點在於會 packet loss)，也常常是被 DDoS 的目標。台灣其他的 ISP 過去大多都是到日本機房，但 HiNet 會到香港機房，而 HiNet 的這條線路相當壅塞：

主要還是靠 SPDY 的能耐硬是把效能撐到「堪用」的程度，而 CloudFlare 遇到 DDoS 時就慘了。

價錢也是公開的，但以商用水準的品質來說，已經低到及格線以下了...

綜合來說，自己玩玩的東西還可以啦，任何商業性質的網站都不應該單獨用 (與其他 CDN 服務動態偵測服務搭配著用還加減可以用用)。所以目前看到用最多的服務就是內容農場 (Content Farm) 在用，為了節省頻寬與伺服器的負荷，不太在意品質。

補充

最後補充在台灣有機房的 CDN 業者：(按照字母排，可能有漏)

HTTPS 的進展

Tony Hunt 在「We’re struggling to get traction with SSL because it’s still a “premium service”」這篇文章裡抱怨了目前 web 要朝向 HTTPS only 還很遠，甚至還酸了一下 Let's Encrypt 冨樫問題：

可是東尼... 你的站也沒上 HTTPS 啊 :/

順便整理一下目前 HTTPS 技術發展出來的優點：

現在網站的 best practice 是 HTTPS + HTTP/2，對 SEO 好、速度又快 (這兩個對營收有影響)，而另外也可以增加安全性 (對聲譽有幫助)。

nginx 宣佈了 Early Alpha 版本的 HTTP/2 支援

nginx 宣佈了 Early Alpha 的 HTTP/2 支援：「Announcing an Early Alpha Patch for HTTP/2」。

除了警告這是早期版本不應該用在 production 上，另外也說明了目前的 patch 會讓 SPDY 失效：

Applying this patch removes the SPDY module from the NGINX codebase and replaces it with the HTTP/2 module. After applying this patch, you can no longer configure NGINX to use SPDY.

而在這之後也不會讓 HTTP/2 與 SPDY 同時並存：

This will also be the case for the production-ready release of the HTTP/2 implementation in both NGINX and NGINX Plus. SPDY is being deprecated by Google in early 2016, so there is no need to support both.

但從 HTTP/2 的支援度與 SPDY 的支援度來看，行動裝置都還不支援 HTTP/2，但 iOS 8.4 以及 Android 3+ 都已經支援 SPDY 了，這樣看起來非常的傷啊...

不知道到年底會有什麼其他解決方案出現...