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...

關於各家 CDN 的選擇...

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

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

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

Akamai

先講 Akamai

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

KKBOX (敝公司) 用過 PMD、DSDDSA 三個產品,其中 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 業者:(按照字母排,可能有漏)

CloudFlare 推出 tag-based purge 功能

CloudFlare 推出這個功能很棒啊,不過這後面的資料結構必須設計的夠好才能這樣玩:「Introducing a Powerful Way to Purge Cache on CloudFlare: Purge by Cache-Tag」。

cache purge 一直都是 CDN 的痛處,用過的每一家 CDN 都在比慢的,大概都是 10 mins 起跳,但 CloudFlare 在這塊花了不少功夫:

可以想像到的方式是放入 user_gslin (在使用者停用時可以馬上更新) 或是 pic_id_1234567890 (可以針對各種縮圖一次刷新) 這樣的 tag 去歸類,然後就可以大規模刷...

CloudFlare 在中東弄了四個機房...

CloudFlare 宣佈在中東啟用四個機房:「Now serving the Middle East: 4 new data centers, partnerships」。

據 comment 提到的,有些人本來是連到新加坡機房,現在在中東直接交換,速度上快了不少。

所以現在看起來是亞洲與非洲的彈幕不夠...?

CloudFlare 加速 zlib library

CloudFlare 大幅改善 zlib,使得速度相較原來的版本快了許多:「Fighting Cancer: The Unexpected Benefit Of Open Sourcing Our Code」。

改變的部份主要是 CPU 指令集的特性,以及 longest-match function 的改善。可以看出不同的測試樣本 (corpus) 在壓縮率沒有變差的情況下,大幅改善了速度。

Calgary corpus

Canterbury corpus

Large corpus

Silesia corpus

速度快非常多,跟 Google 以壓縮率為導向而放出來的 zopfli 剛好是兩個極端:「Google 發表與 zlib/deflate 相容的壓縮程式,再小 5%...」。

CloudFlare 的大阪 PoP

CloudFlare 宣佈在大阪建 PoP,將京阪神 (& 西側),以及名古屋地區納入服務範圍:「Osaka, Japan: CloudFlare's 35th data center」。

人剛好就在大阪,實際測試發現還是有些狀況。手機的部份還是會導到東京交換,住的地方也還是到東京交換。看起來還有不少 DNS resolver 的 IP 資訊要調整。

另外這也使得日本地區有完全異地備援的機制,如果東京機房出問題時可以透過大阪撐著,不需要跑到國外 (應該是香港 PoP)。