CloudFlare 在台灣的節點上線了

前兩天開始就開始在社群網站還有通訊軟體群組上看到在傳 CloudFlare 的系統狀態監測頁面 “CloudFlare system status” 上多了 TPE – Taipei, Taiwan 的結點
status

CloudFlare 的 CEO 也在 Twitter 上間接證實了這件事:

稍為搜尋了一下,能找到這個點的最新公開紀錄只有在 CloudFlare system status 4/6 上的一個 DNS Propagation delays in APAC, Incident Report for CloudFlare 裡面看到,明確的建置以及上線時間就不知道了:

根據在 CloudFlare support 上面的文章:Which CloudFlare data center do I reach?,每個節點都是使用 Location Code: City, (State,) Country 這樣的格式來表示,而 location code 是使用最靠近的主要國際機場的 IATA 代碼 ( Each location code is the IATA code of the nearest major international airport.),冷知識一下,雖然上面也寫著 Taipei,不過 TPE 是桃園國際機場 Taiwan Taoyuan International Airport 的代號,也許外國人比較認得台北認不得桃園吧?

昨天看的時候看起來只有免費方案的流量會倒到台灣的點去,應該可以算是初期的測試,而付費流量像是 cdnjs.com, digitalocean.com 以及 cloudflare.com 都還是繼續倒到香港,而今天早上看的時候發現付費用戶的流量都已經改倒到台灣了,看圖:

Trace 可以看到是 TPE 的字樣,先前都是 HKG (香港)

目前看起來從台灣學術網路、中華電信、遠傳、亞太的追蹤結果都是走到 TPE 上面去的,有興趣了解自己使用的網站 / 線路使用的是哪一個節點,可以在網址的 hostname 部份後面接上 /cdn-cgi/trace 就會看到類似上面那張截圖的結果 (前提當然是該網站有使用 CloudFlare ,其他 cdn 業者作法可能不盡相同),這邊是一些範例:

截至目前為止,CloudFlare 的 network map 上還無法看到台灣的節點,推測因為還在測試階段:

https://www.cloudflare.com/network-map

閱讀全文

Test if your web server supports http/2.0 or spdy via Protocol Negotiation

Cloudflare started to support http/2.0 in production environment yesterday(HTTP/2 is here! Goodbye SPDY? Not quite yet), not like NGINX open source version(NGINX Open Source 1.9.5 Released with HTTP/2 Support), which dropped spdy support, Cloudflare supports them both like Google and Facebook does. Cloudflare is not the first CDN company to support http/2, KeyCDN launched there http/2.0 support from the early Oct 2015(KeyCDN Launches HTTP/2 Support), cdn77 started their http/2.0 support since Aug 2015(HTTP/2 Support for All Customers), but both of KeyCDN and cdn77 doesn’t support http/2 + spdy, now Cloudflare supports both, so maybe it’s just worthy(BTW, akamai also support them both), without a doubt it’s a good very good news to us, but how to test if a web server support http/2.0? Here we go.

In the beginning, I think you should know a little bit about the Application-Layer Protocol Negotiation , on Wikipedia:

Application-Layer Protocol Negotiation, on Wikipediais a Transport Layer Security (TLS) extension for application layer protocol negotiation. ALPN allows the application layer to negotiate which protocol should be performed over a secure connection in a manner which avoids additional round trips and which is independent of the application layer protocols. It is used by HTTP/2.

We can use TLS-ALPN to get the supported protocols by the server desired order, here we will use OpenSSL client as an example.

On OpenSSL man page:

-nextprotoneg protocols
enable Next Protocol Negotiation TLS extension and provide a list of comma-separated protocol names that the client should advertise support for. The list should contain most wanted protocols first. Protocol names are printable ASCII strings, for example “http/1.1” or “spdy/3”. Empty list of protocols is treated specially and will cause the client to advertise support for the TLS extension but disconnect just after receiving ServerHello with a list of server supported protocols.

The syntax should be like this:
openssl s_client -nextprotoneg NULL -servername host.domain.name -connect host.ip.or.domain:port

Because there may be many domains pointing to a same IP address, we should tell the server which domain we are going to connect by servername, and I don’t want to get a verify error, so I will also tell OpenSSL the path we store certificates by CApath, for example, on Ubuntu 14.04 LTS:

[bash]
$ openssl s_client -CApath /etc/ssl/certs -nextprotoneg NULL -servername www.peterdavehello.org -connect www.peterdavehello.org:443 | grep ‘Protocols advertised by server’
[/bash]

We will get this result:

depth=2 C = IL, O = StartCom Ltd., OU = Secure Digital Certificate Signing, CN = StartCom Certification Authority
verify return:1
depth=1 C = IL, O = StartCom Ltd., OU = Secure Digital Certificate Signing, CN = StartCom Class 1 Primary Intermediate Server CA
verify return:1
depth=0 C = TW, CN = www.peterdavehello.org, emailAddress = hsu @peterdavehello.org
verify return:1
Protocols advertised by server: h2, http/1.1

Which means www.peterdavehello.org wanna use http/2.0 first, and then http/1.1, if you do this test on www.google.com, you’ll get another result like this:

depth=3 C = US, O = Equifax, OU = Equifax Secure Certificate Authority
verify return:1
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify return:1
depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = www.google.com
verify return:1
read:errno=0
Protocols advertised by server: h2, spdy/3.1, http/1.1

So we know that Google supports http/2.0, spdy/3.1 and http/1.1!

The funniest thing I noticed is that the result of Facebook is a little bit more complex and also unstable, test result 1:

depth=3 C = US, O = GTE Corporation, OU = “GTE CyberTrust Solutions, Inc.”, CN = GTE CyberTrust Global Root
verify return:1
depth=2 C = IE, O = Baltimore, OU = CyberTrust, CN = Baltimore CyberTrust Root
verify return:1
depth=1 C = NL, L = Amsterdam, O = Verizon Enterprise Solutions, OU = Cybertrust, CN = Verizon Akamai SureServer CA G14-SHA2
verify return:1
depth=0 C = US, ST = CA, L = Santa Clara, O = Akamai Technologies Inc., CN = http2.akamai.com
verify return:1
Protocols advertised by server: h2, h2-14, spdy/3.1, spdy/3, http/1.1, http/1.0

Test result 2:

depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert High Assurance EV Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert SHA2 High Assurance Server CA
verify return:1
depth=0 C = US, ST = CA, L = Menlo Park, O = “Facebook, Inc.”, CN = *.facebook.com
verify return:1
Protocols advertised by server: spdy/3.1-fb-0.5, spdy/3.1, spdy/3, http/1.1

I guess Facebook is still testing their http/2.0 feature.