Tag: anycast

Home » Posts tagged "anycast"

Cloudflare 推出 1.1.1.1 的 DNS Resolver 服務

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 沒有提供而已...

CDN, Cloud, Computer, DNS, Murmuring, Network, Privacy, Security, Service1 Comment

中華的 DNS 架構

在 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 層拆出不同區域的用戶？

Computer, DNS, Murmuring, Network, Service1 Comment

Google CDN 進入 Beta

最近 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 之類的證照。

不過不得不說價錢其實還蠻便宜的，無論是歐美還是亞洲區。

CDN, Cloud, Computer, Murmuring, Network, WWWNo Comment

Google 的 Load balancer：Seesaw

前幾天因為流感而睡太多，來消化一些文章。

上個星期 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 的花樣...

Computer, Murmuring, Network, Software, WWWNo Comment

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.

所以也因此可以看到 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 滿足了這點。

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

CDN, Computer, Murmuring, Network, Security, WWWNo Comment

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

Browser, CDN, Cloud, Computer, GoogleChrome, Murmuring, Network, Software, WWWNo Comment

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, Cloud, Computer, Murmuring, Network1 Comment

EdgeCast 提供的 DNS 服務：EdgeCast Route

Zite 上看到 EdgeCast 也要進入 DNS 服務這個市場了：「CDN Provider EdgeCast Gets Into The DNS Market With Launch Of EdgeCast Route」。

服務的頁面已經公開，並且公開價錢：「Managed DNS Provider | Outsourced DNS Service | Route | EdgeCast」，服務分成三種：

Standard Routing

利用 EdgeCast 的 IP Anycast Network 服務。每百萬個 query 是 USD$0.4 (超過十億個 query 的部份降到半價 USD$0.2)。

Adaptive Availability

除了 IP Anycast Network 外，還可以設定 health check 與 ratio (以達到 load sharing 的功能)。每百萬個 query 是 USD$0.6 (超過十億個 query 的部份降到半價 USD$0.3)。

Advanced Policy Routing

可以依照這些條件分析：GeoIP、GeoCountry、GeoCity、ASN、IP Group、Network Groups、Anycast PoPs 或是 IP Type。每百萬個 query 是 USD$1.5 (超過十億個 query 的部份降到 USD$1)。

另外價錢還有 zone 的部份。前面 50 個 zone 是 USD$50/month (算是低消吧？)，後面每 50 個 zone 是 USD$35/month。而 health check 的部份是每個 USD$0.5/month。

可以設這麼細，而且又取這個名字，算是跟 Amazon Route 53 打對台？不過那個 Geo 系列以及 ASN 的部份看起來不賴啊，以前是自己寫 DNS resolver 處理這部份，把國外流量指到 CDN 上，然後台灣流量放在台灣的機房 (因為 CDN 不一定有台灣機房的 PoP)。

找機會來看看效果如何...

CDN, Cloud, Computer, DNS, Murmuring, NetworkNo Comment Cloud, Computer, DNS, Murmuring, NetworkNo Comment

AWS Route53 降價、新增巴西 PoP...

公告在這裡：「Amazon Route 53 - Now an Even Better Value」、「Amazon CloudFront & Route 53 - New Edge Location: Brazil」。

Route53 的部份，對於少量使用的人來說，每個 domain 每年的代管價錢從 USD$12 降到 USD$6，而對於大量使用的人來說，更有可能降到 USD$1.2。對於有大量 domain 希望上 Anycast DNS 的人來說是個好消息。

另外一個消息是 AWS 新增巴西的 PoP，是南美的第一個點。包括 CloudFront 以及 Route53 都將受益。不過頻寬費用與 request 費用比之前最貴的東京 20% 以上。如果費用層級再多，AWS 應該要提供可以客製化不同等級的 CDN service (設定只要某些 PoP)，不然花不太下手啊...

AWS, Cloud, Computer, DNS, Murmuring, NetworkNo Comment

Recent Comments

Archives

Blogroll