CloudFlare 正式推出 HTTP/2,可以與 SPDY 同時混搭

CloudFlare 推出了 HTTP/2 服務,與其他 CDN 業者不一樣的地方在於,他可以同時接受 HTTP/2 與 SPDY:「HTTP/2 is here! Goodbye SPDY? Not quite yet」。

CloudFlare 拿自家的 www.cloudflare.com 官網測試,顯示 HTTP/2 的效能比 SPDY 又好了不少:

Access via HTTP Protocol Version Average Page Load time
HTTP 1.x 9.07 sec.
SPDY/3.1 7.06 sec.
HTTP/2 4.27 sec.

在正式上 HTTP/2 前,有 80.38% 對 www.cloudflare.com 的 SSL/TLS 連線是 SPDY:

During the week before our HTTP/2 launch, 80.38% of all SSL/TLS connections to our own website at www.cloudflare.com were made over SPDY/3.1.

上線後其實沒有想像中的高:

Protocol Version Percentage of Hits
HTTP 1.x 19.36%
SPDY/3.1 57.02%
HTTP/2 23.62%

這也說明了為什麼 CloudFlare 要推出 SPDY + HTTP/2 的服務:

Why choose, if you can have both? Today CloudFlare is introducing HTTP/2 support for all customers using SSL/TLS connections, while still supporting SPDY. There is no need to make a decision between SPDY or HTTP/2. Both are automatically there for you and your customers.

剛剛連到後台確認,由於本來已經打開 SPDY 的使用者會自動開啟 HTTP/2,這表示全球 HTTP/2 的使用率會馬上拉高很多,有太多資源掛在 CloudFlare 上:(像是 cdnjs.com,剛剛確認也已經是 HTTP/2 了)

If you are a customer on the Free or Pro plan, there is no need to do anything at all. Both SPDY and HTTP/2 are already enabled for you.

Customers on Business and Enterprise plans can enable HTTP/2 within the "Network" application of the CloudFlare Dashboard.

CloudFlare 全面支援 DNSSEC

CloudFlare 宣佈全面支援 DNSSEC 了:「Announcing Universal DNSSEC: Secure DNS for Every Domain」。

另外也因為現在需要把 public key 手動 copy & paste 到 DNS 註冊商會很麻煩 (而且有可能會貼錯),所以 CloudFlare 的人試著往 IETF 標準化這件事情:

At CloudFlare, we care about advancing what’s possible on the Internet, so we have published an Internet Draft proposing a protocol for DNS providers such as CloudFlare to communicate directly to registries and registrars. We are pushing it to become an accepted Internet Standard RFC.

CloudFlare 通過 PCI DSS 3.1 Level 1

CloudFlare 宣佈通過 PCI DSS 3.1 Level 1:「CloudFlare is now PCI 3.1 certified」。

早在去年的時候 CloudFlare 就已經通過 PCI DSS 2.0 Level 1:「CloudFlare is PCI Certified」,這次過 PCI DSS 3.1 主要還是因為 2.0 即將失效,不升級就不能處理信用卡資料了...

CloudFlare 對 Brotli 的測試

之前有提過這件事情,由於 Firefox 已經支援 Brotli 了 (Google 推出 Brotli 無損壓縮法),所以 CloudFlare 的人整理了目前的效能比較:「Results of experimenting with Brotli for dynamic web content」。

主要還是 Brotli 拿了不少資源來換壓縮率,對於 static content 由於可以事先算好而大勝不少 (大約可以再榨出 15% 的壓縮率,從 zlib 9 的 27.7% 降到 brotli 10 的 23.3%):

The current state of Brotli gives us some mixed impressions. There is no yes/no answer to the question "Is Brotli better than gzip?". It definitely looks like a big win for static content compression, but on the web where the content is dynamic we also need to consider on-the-fly compression.

另外對於大檔案、網路速度不快的連線來說也頗有幫助,但對於 on-the-fly 的壓縮反而會比較慢。

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 技術,如果是的話就要煩惱某些網站的流量有機會被導到中國了。

LinkedIn 的工程師分析 TCP Anycast 技術的穩定性與效能

LinkedIn 的工程師測試了 TCP Anycast 技術的穩定性以及效能:「TCP over IP Anycast - Pipe dream or Reality?」。

由於 stateless 再加上一個封包就傳的完的情況下,Anycast 技術被用在 DNS 上已經很長一段時間了,目前大多數 CDN 業者也都有用 Anycast 技術加快 CDN 的回應速度。

但 TCP 因為 stateful,如果 router 上採用的方式有問題,那麼就會導致封包可能會送到不同節點,這會是個嚴重的問題。不過很早之前,幾乎所有的骨幹 router 都已經支援 flow-based load balancing policy:

Most routers now do a per-flow load balancing, meaning packets on a TCP connection are always sent over the same path, but even a small percentage of routers with per-packet load balancing can cause the website to be unreachable for users behind that router.

所以 LinkedIn 的人試著測試 TCP Anycast 技術的穩定性:

So, to validate the assumption that TCP over anycast in the modern internet is no longer a problem, we ran a few synthetic tests.

測試的方式是設定 web server,讓下載速度不快,然後設了好幾個點並且放出對應的 routing,用 Catchpoint 服務監控,如果不穩定的話,應該就會收到 RST 中斷連線:

We configured our U.S. PoPs to announce an anycast IP address and then configured multiple agents in Catchpoint, a synthetic monitoring service, to download an object from that IP address. Our web servers were configured to deliberately send the response back slowly, taking over a minute for the complete data transfer. If the internet was unstable for TCP over anycast, we would observe continuous or intermittent failures when downloading the object. We would also observe TCP RSTs at the PoPs.

而好消息是,測試起來相當穩定:

But even after running these tests for a week, we did not notice any substantial instability problems! This gave us confidence to proceed further.

所以也因此可以看到 CacheFlyCloudFlare 兩家採用 TCP Anycast 技術:

[S]ome popular CDNs have also started using anycast for HTTP traffic.

由於穩定性的部份沒問題,所以接下來就是討論效率。

Anycast 是基於 routing 而決定要怎麼走,目標是希望可以透過 routing 取得 latency 最低的點。但實務上會把成本考慮進去,有可能會走到比較遠的點。在測試中可以發現北美的部份 Anycast 表現的比 GeoIP 好,但離開北美就掉很多:

所以 LinkedIn 決定用「Regional Anycast」,先用 GeoIP 決定要丟到哪個洲,而每個洲共用一個 Anycast 位置,這個方法讓效能提昇不少,全球在分配時 sub-optimal 的比率從 31% 降到 10% (i.e. 沒有分配到最好的點的比率):

上面主要是讀 LinkedIn 文章的心得,後面就是感想了。

TCP Anycast 用 CDN 上其實是相當吃虧的技術,由於 routing 的掌控權不再自己手上,有很多重要的手段是沒辦法做到的。

首先是當對外流量已經滿載時,不能切換到其他機房的機器,這邊講的「對外流量」不是 CDN 本身而已,而是中途任何的線路滿載都算,像是 HiNet 對 CloudFlare 香港機房的情況就很明顯。

另外在被 DDoS 時,由於沒辦法導流,在被攻擊時幾乎只剩下 clean pipe 類的解法,而同時間其他用戶會因為流量大量流入機房而一起被波及到。GeoIP 的方式彈性就大很多。

當然,還是有可以列出來的好處。主要是對於需要有固定 IP 應用來說 (像是 firewall 設定需求),TCP Anycast 滿足了這點。

只能說不同市場有不同的產品線在供應啦,不同的情境下有不同的需求...

CloudFlare 開始測試 HTTP/2

CloudFlare 宣佈開始測試 HTTP/2 了:「Test all the things: IPv6, HTTP/2, SHA-2」。

網站是 https://http2.cloudflare.com/,如果有裝 HTTP/2 and SPDY indicator 的人應該會看到藍色的閃電:

原來的站則是綠色的 SPDY/3.1:

接下來就是花時間等待了。

為了解決 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

TVBS 的 CloudFlare 客製化...

TVBS 網站整個使用 CloudFlare,但針對台灣地區 HiNet 的部份仍然保持使用 anycast,但該段 routing 沒有透過香港機房放進 HiNet,而是很特別的走到了 San Jose 的機房:

  3.|-- SNUH-3202.hinet.net        0.0%    10   10.4  10.5   8.8  16.8   2.2
  4.|-- TPDT-3012.hinet.net        0.0%    10   14.5  14.6  10.6  20.6   3.4
  5.|-- r4102-s2.tp.hinet.net      0.0%    10    9.8  10.0   8.7  10.8   0.5
  6.|-- r4002-s2.tp.hinet.net      0.0%    10   10.8  19.0   8.7  82.1  23.0
  7.|-- r12-pa.us.hinet.net        0.0%    10  137.7 138.4 136.9 139.2   0.3
  8.|-- sjo-b21-link.telia.net     0.0%    10  157.0 156.4 155.7 157.7   0.3
  9.|-- cloudflare-ic-309920-sjo-  0.0%    10  146.9 148.6 145.8 167.4   6.6
 10.|-- 198.41.187.120            10.0%    10  145.7 146.7 137.9 156.9   7.6

國內其他 ISP 則是如同一般的情況,走到了日本機房:

  3.|-- 60-199-236-110.static.tfn  0.0%    10    0.3   0.3   0.3   0.3   0.0
  4.|-- 60-199-255-3.static.tfn.n  0.0%    10    0.3   0.3   0.2   0.3   0.0
  5.|-- 60-199-20-153.static.tfn.  0.0%    10    0.2   2.6   0.2  24.2   7.5
  6.|-- 60-199-3-137.static.tfn.n  0.0%    10    0.3   2.2   0.2  20.1   6.3
  7.|-- 60-199-18-90.static.tfn.n  0.0%    10    0.3   0.3   0.3   0.4   0.0
  8.|-- 60-199-3-222.static.tfn.n  0.0%    10    0.4   0.4   0.4   0.5   0.0
  9.|-- xe-1-0-0.r01.taiptw01.tw.  0.0%    10    0.8   3.1   0.7  23.6   7.2
 10.|-- ae-1.r00.taiptw01.tw.bb.g  0.0%    10    5.6   5.5   0.9  39.1  11.9
 11.|-- as-2.r22.tokyjp01.jp.bb.g  0.0%    10   53.2  52.3  49.3  53.8   1.4
 12.|-- ae-8.r25.tokyjp05.jp.bb.g  0.0%    10   52.5  53.0  50.4  56.4   1.7
 13.|-- ae-2.r01.tokyjp03.jp.bb.g  0.0%    10   54.5  53.1  50.1  55.3   1.8
 14.|-- xe-0-0-0-29.r01.tokyjp03.  0.0%    10   79.5  77.2  73.6  79.5   1.6
 15.|-- 198.41.190.120             0.0%    10   54.8  58.8  49.9  78.7  10.5

  3.|-- h61-192-72-154.seed.net.t  0.0%    10    0.4   0.5   0.4   0.6   0.0
  4.|-- R58-145.seed.net.tw       10.0%    10   13.2   8.4   0.5  42.4  13.6
  5.|-- R59-194.seed.net.tw        0.0%    10   52.5  10.8   0.6  52.5  19.7
  6.|-- xe-4-0-0.r01.taiptw01.tw.  0.0%    10    0.6   0.7   0.6   0.8   0.0
  7.|-- ae-1.r00.taiptw01.tw.bb.g  0.0%    10    0.9   0.9   0.8   1.1   0.0
  8.|-- as-2.r22.tokyjp01.jp.bb.g  0.0%    10   70.8  66.5  49.2 102.1  19.4
  9.|-- ae-8.r24.tokyjp05.jp.bb.g  0.0%    10   54.3  58.2  53.2  76.3   6.8
 10.|-- ae-1.r01.tokyjp03.jp.bb.g  0.0%    10   55.6  54.1  48.9  55.7   2.1
 11.|-- xe-0-0-0-29.r01.tokyjp03.  0.0%    10   55.0  56.8  53.0  59.3   1.9
 12.|-- 198.41.186.120             0.0%    10   55.1  54.8  50.7  58.1   2.0

依照 Netcraft 上的資料 (Site report for www.tvbs.com.tw) 應該是六月的時候換去的:

應該是國內比較有量的網站裡面少數用 CloudFlare 的?其他新聞網站大多都用 Akamai...