幹壞事是進步最大的原動力
Cloudflare 推出了 BYOIP 的服務，用客戶的 IP address 放 routing 出去：「Bringing Your Own IPs to Cloudflare (BYOIP)」。
照敘述上看起來應該是 anycast，不過這邊沒明講：
When you BYOIP with Cloudflare, this means we announce your IP space in over 200 cities around the world and tie your IP prefix to the service (or services!) of your choosing.
裡面沒有提到 IPv4 或是 IPv6，在 https://developers.cloudflare.com/byoip/ 這邊看起來也沒提到，以 Cloudflare 的技術架構，應該是都支援？
用自己的 IP 的好處，一個明顯的方向就是 firewall 會好設不少，另外如果需要服務中國或是其他管制地區，比較不會因為 IP space 混用誤殺受到影響？
Google 宣佈 Hangouts 將會使用固定 IP 位置，讓系統管理員更方便管理：「Dedicated Hangouts Meet IP addresses」。
We’re adding a range of official, fixed IP addresses to be used exclusively for classic Hangouts and Hangouts Meet in G Suite domains.
目前看到的資訊是：
IPv4: 74.125.250.0/24
IPv6: 2001:4860:4864:5::0/64
然後文章裡的說明是二月 14 日會變更：
Hangouts Meet and classic Hangouts will stop using the old IP address on February 14, 2019.
管理者可以調整關於這段 IP 的流量，通常是調高優先權？不過要調低也是可以...
AWS 推出了 Global Accelerator，利用 AWS 的網路加速：「New – AWS Global Accelerator for Availability and Performance」。
這個產品有點像是 GCP 的 Premium Network 的概念，從名稱叫做 Data Transfer-Premium (DT-Premium) 也可以看出來這點。另外 Cloudflare 也有類似的產品，叫做 Spectrum。
使用者的連線會先進入最接近使用者的 AWS Edge，然後走 AWS 自己的網路到真正服務所在的 AWS 區域：
AWS 自家的 CloudFront 可以做類似的事情，但是 CloudFront 是 DNS-based service，而且只吃 HTTP 類的連線；這次推出的 Global Accelerator 則是 Anycast-based service，同時支援 TCP 與 UDP。
目前的 edge 只有北美、歐洲與亞洲：
AWS Global Accelerator is available in US East (N. Virginia), US East (Ohio), US West (Oregon), US West (N. California), Europe (Ireland), Europe (Frankfurt), Asia Pacific (Tokyo) and Asia Pacific (Singapore).
這類服務通常也都可以擋下一些 DDoS 攻擊，畢竟是拿大水管在擋...
Cloudflare 推出了 1.1.1.1 上的 DNS Resolver 服務：「Announcing 1.1.1.1: the fastest, privacy-first consumer DNS service」，主打項目是隱私以及效能。
然後因為這個 IP 的特殊性，上面有不少奇怪的流量... 而 Cloudflare 跟 APNIC 交換條件後取得這個 IP address 的使用權 (然後 anycast 發出去)：
APNIC's research group held the IP addresses 1.1.1.1 and 1.0.0.1. While the addresses were valid, so many people had entered them into various random systems that they were continuously overwhelmed by a flood of garbage traffic. APNIC wanted to study this garbage traffic but any time they'd tried to announce the IPs, the flood would overwhelm any conventional network.
We talked to the APNIC team about how we wanted to create a privacy-first, extremely fast DNS system. They thought it was a laudable goal. We offered Cloudflare's network to receive and study the garbage traffic in exchange for being able to offer a DNS resolver on the memorable IPs. And, with that, 1.1.1.1 was born.
Cloudflare 做了效能比較表 (與 Google Public DNS 及 OpenDNS 比較)，可以看到平均速度快不少：
在台灣的話，HiNet 非固定制 (也就是 PPPoE 連線的使用者) 連到 8.8.8.8 有奇怪的 latency：
可以比較同一台機器對 168.95.1.1 的反應速度：
不過如果你是 HiNet 固定制 (固 2 或是固 6 IP 那種，不透過 PPPoE，直接設定 IP address 使用 bridge mode 連線的使用者)，兩者的 latency 就差不多，不知道是 Google 還是 HiNet 的架構造成的。
另外比較奇怪的一點是在文章最後面提到的 https://1.1.1.1/，理論上不會發 IP-based 的 SSL certificate 才對？不知道 CEO 老大是有什麼誤解... XD
Visit https://1.1.1.1/ from any device to get started with the Internet's fastest, privacy-first DNS service.
Update：查了資料發現是可以發的，只是大多數的 CA 沒有提供而已...
在 Twitter 上看到「HiNet DNS系統設備維護作業」這則維護公告，裡面提到了會對 HiNet DNS 系統維護，但範圍是雲林以南：
起訖日期：2017-10-19
時間： 14:00 ~ 16:00
範圍：雲林(含)以南
說明：親愛的HiNet客戶您好﹕ 為提昇網路服務品質，HiNet DNS系統將於106/10/19(星期四)下午2:00到4:00進行設備維護，期間DNS查詢服務將可能發生瞬斷情形，若影響上網服務造成您的不便，敬請見諒，並感謝您對HiNet的支持與愛護。 祝您 身體健康 萬事如意 中華電信數據通信分公司 敬上 客服專線：0800-080-412
這樣聽起來中華有在自己內部網路跑 anycast service 了？而且這樣應該表示有機會在 DNS 層拆出不同區域的用戶？
最近 CDN 產業裡有不少蕭期，其中一個新聞是 Google CDN 進入 beta，Google 藉由在全球佈署的機房來服務。
不過雖然進入了 Beta，但仍然有很嚴重的技術限制，只能透過 GCE 當 origin server，這使得實用性低很多：
Origins
Delivers HTTP/HTTPS content originating from Compute Engine VM instances. External origin servers are not supported.
有些特點是跟一般 CDN 不同的，一個是 Google 對 HTTPS 的口號，所以 HTTP 與 HTTPS 的價錢相同。其實你就當做他把 HTTP 的費用收的跟 HTTPS 一樣就好：
SSL Shouldn't Cost Extra
The web is moving to HTTPS, and your cacheable content should, too. With Cloud CDN, you can secure your content using SSL/TLS for no additional charge.
另外一個特點是從技術上就宣稱完全使用 Anycast，而不是見到的 DNS + Anycast：
Anycast
Serve all your content from a single IP address with low latency worldwide.
另外，計價的方式與其他的 CDN 有不少地方不一樣，另外也有針對中國地區另外處理。
首先是他把 Cache Egress (從 CDN 給使用者) 與 Cache Fill (從 CDN 到 Origin 取得資源) 分開收，一的般 CDN 都只收 Cache Egress 這塊。
再來是中國大陸地區的價錢另外標示，有特地標明不是從中國大陸地區直接提供服務：
Traffic destined for mainland China is served from Google locations outside of mainland China. Performance and reliability may be lower than for traffic served from in-country locations.
言下之意就是另外買 optimized 的頻寬來服務，但還是不會像在中國大陸地區有機房的效果這麼好，不過好處是不需要 ICP 之類的證照。
不過不得不說價錢其實還蠻便宜的，無論是歐美還是亞洲區。
前幾天因為流感而睡太多，來消化一些文章。
上個星期 Google 放出一套用 Go 寫的 Load balancer，叫 Seesaw：「Seesaw: scalable and robust load balancing」。
比較有趣的是 BGP 與 anycast VIP 的能力：
Seesaw v2 provides full support for anycast VIPs - that is, it will advertise an anycast VIP when it becomes available and will withdraw the anycast VIP if it becomes unavailable.
Google 這個規模玩的是不同 scale 的花樣...
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.
所以也因此可以看到 CacheFly 與 CloudFlare 兩家採用 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 滿足了這點。
只能說不同市場有不同的產品線在供應啦，不同的情境下有不同的需求...
前幾天在「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，但針對台灣地區 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...