Google Chrome 上看連線是使用 IPv4 或是 IPv6

想說應該會有 extension 可以看連線是 IPv4 或是 IPv6,找了一下果然有:「IPvFoo」。

右上角會出現目前連線的屬性。透過 Google Chrome 提供的 webRequest 取得資訊後更新上去的。

目前比較常見的站台應該是 Facebook (包括 Instagram)、GoogleYahoo,也剛剛好都是 HTTPS Policy 的先驅... 不過可以看出來不是所有的資源都走 IPv6,還是有不少走 IPv4 的 domain。

Twitter 的主網站沒有 IPv6,但幾個自己的子網域有?看起來還在逐步測試開通...

HiNet 的 IPv6 服務已經可以透過網路櫃台直接線上申請 (需要幾個工作天開通),我用 Ubuntu 可以 PPPoE 取得...

Ubuntu 在 Command Line 下自動重撥 PPPoE

HiNetPPPoE 大約三四天會斷一次,但就算設定要自動重撥好像也不太會動,所以需要自己偵測 ppp0 界面是否存在,不是的話就要撥號...

測試 ppp0 界面是否存在可以用 ifconfig 的 exit status 判斷,而重撥則可以用 nmcli 來做,用 cron 去判斷變成:

*/1 * * * * root /sbin/ifconfig ppp0 > /dev/null 2>&1 || /usr/bin/nmcli connection up id "HiNet PPPoE" > /dev/null 2>&1

我是用 "HiNet PPPoE" 這個名稱,如果要用到你自己的機器上的話,把上面的 "HiNet PPPoE" 換成你在 NetworkManager 裡設定的名稱。

Apple 使用 Limelight Networks...

好久沒看到 Limelight Networks 的新聞:「Apple’s Multi-CDN Strategy Adds Limelight Networks To The Mix」。

Dan Rayburn 發現 Apple 把 Limelight Networks 加入 Apple 的下載網路裡。之前用的是 Akamai,另外就是自己建的 CDN,現在加入 Limelight Networks 應該是成本考量:(因為在 Limelight Networks 的財報上有提出來,雖然不是直接講明 Apple)

On Limelight’s earnings call this week, the company mentioned they signed up some customers that they had to give a low price point to, which would impact margins in the short-term, before they expected the economics of scale to kick in.

不過 Limelight Networks 對 HiNet 的品質一直都不是很好,主要還是會導去香港機房,但看起來線路頗壅塞,就再看看吧...

拿 Openvirtuals 的主機跑 Syncthing...

Low End Box 上逛到的主機商 Openvirtuals,在 LEB 上看到的優惠已經沒了,但點進去後看到 Buffalo 的主機年繳有 50% off,加上硬碟空間又大,就決定弄一台玩玩...

SSD-CACHED 的 Mini 是 256MB RAM + 512MB vSwap 以及 90GB 空間,要 USD$16/year,而 Standard 的都是兩倍,但只要 USD$20/year,就決定買 Standard 了...

後台的功能比想像中完整,這是系統資訊與狀態的畫面,功能其實不比 DigitalOcean 差 (不過畫面就普普通通了):

裝了 Ubuntu 14.04 64bits 跑,不過 Linux kernel 偏舊了點,是 2.6.32,查了一下維基百科上的資料,應該是 2009 年底的版本,是目前唯一一個 2.6 上有繼續維護的版本:

Linux two 2.6.32-042stab108.2 #1 SMP Tue May 12 18:07:50 MSK 2015 x86_64 x86_64 x86_64 GNU/Linux

網路的部份,實際測試時發現不是很穩定,HiNet 過去有時候會有不低的 packet loss,可能是中間有線路因為 DDoS 造成不穩定。

反正只是要跑 Synthing 也還好,就先這樣丟著... 上面順便跑個 rtorrent 幫忙 Ubuntu 分擔 ISO Image。

最近 Facebook 破圖的問題 (168.95.1.1 出問題)

最近在 Facebook 上常看到有同事在抱怨破圖,其實是 168.95.1.1 的問題... 在 zsh 下跑一百次查詢可以偵測到對應的問題,不只是 Facebook 的網站,包括 HiNet 自家網站都查不到:

gslin@GSLIN-HOME1404 [~] [01:12/W5] repeat 100 host www.hinet.net 168.95.1.1 | grep REFUSED
Host www.hinet.net not found: 5(REFUSED)
Host www.hinet.net not found: 5(REFUSED)
Host www.hinet.net not found: 5(REFUSED)
Host www.hinet.net not found: 5(REFUSED)
Host www.hinet.net not found: 5(REFUSED)
Host www.hinet.net not found: 5(REFUSED)
Host www.hinet.net not found: 5(REFUSED)

隔壁的 168.95.192.1Google 家的 8.8.8.8 就沒這個問題:

gslin@GSLIN-HOME1404 [~] [01:13/W5] repeat 100 host www.hinet.net 168.95.192.1 | grep REFUSED
gslin@GSLIN-HOME1404 [~] [01:13/W5] repeat 100 host www.hinet.net 8.8.8.8 | grep REFUSED     
gslin@GSLIN-HOME1404 [~] [01:14/W5]

所以 workaround 就呼之欲出了:把 DNS resolver 換成 8.8.8.8

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 業者:(按照字母排,可能有漏)

幾個新發現:IPv6 與 Facebook 台灣機房...

無意間測試時發現的...

Ubuntu 14.04 的 PPPoE 撥上 HiNet 後,會拿到 IPv6 address (我記得申請完後之前一直拿不到),然後一次拿好幾個 (不知道什麼原因,應該要去翻翻看 IPv6 是不是有什麼特性):

ppp0      Link encap:Point-to-Point Protocol  
          inet addr:1.163.x.x  P-t-P:168.95.x.x  Mask:255.255.255.255
          inet6 addr: 2001:b011:3008:282:xxxx:xxxx:xxxx:xxxx/64 Scope:Global
          inet6 addr: 2001:b011:3008:282:xxxx:xxxx:xxxx:xxxx/64 Scope:Global
          inet6 addr: 2001:b011:3008:282:xxxx:xxxx:xxxx:xxxx/64 Scope:Global
          inet6 addr: 2001:b011:3008:282:xxxx:xxxx:xxxx:xxxx/64 Scope:Global
          inet6 addr: fe80::xxxx:xxxx:xxxx:xxxx/10 Scope:Link
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1492  Metric:1
          RX packets:24632377 errors:0 dropped:0 overruns:0 frame:0
          TX packets:16553423 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3 
          RX bytes:30408127665 (30.4 GB)  TX bytes:2344774062 (2.3 GB)

然後到處亂測發現 Facebook 在台灣有機房:

gslin@GSLIN-HOME1404 [~] [00:32/W3] mtr --report www.facebook.com
Start: Thu Mar 19 00:32:25 2015
HOST: GSLIN-HOME1404              Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- ipv6.dynamic.hinet.net     0.0%    10    6.2   6.5   6.2   7.3   0.0
  2.|-- 2001:b000:82:5:22:2201:1:  0.0%    10    6.1   9.0   6.1  26.4   6.3
  3.|-- 2001:b000:82:4:3201:3302:  0.0%    10    6.7   6.6   6.3   6.8   0.0
  4.|-- 2001:b000:80:3:80:82:3:2   0.0%    10   11.6  10.7   6.9  16.6   2.8
  5.|-- 2001:b000:80:4:3011:3311:  0.0%    10    6.9   7.3   6.4  10.0   1.1
  6.|-- 2001:b000:80:7:0:3:2934:1  0.0%    10   16.8   8.3   6.9  16.8   3.0
  7.|-- po126.msw01.01.tpe1.tfbnw  0.0%    10    7.9   8.0   7.5   8.9   0.0
  8.|-- edge-star6-shv-01-tpe1.fa  0.0%    10    7.3   7.2   6.8   7.6   0.0

再回頭測了 IPv4:

gslin@GSLIN-HOME1404 [~] [00:32/W3] mtr --report -4 www.facebook.com
Start: Thu Mar 19 00:33:18 2015
HOST: GSLIN-HOME1404              Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- h254.s98.ts.hinet.net      0.0%    10    6.9   6.4   5.8   6.9   0.0
  2.|-- SNUH-3301.hinet.net        0.0%    10    6.3  12.2   6.2  60.9  17.1
  3.|-- SNUH-3201.hinet.net        0.0%    10    6.2   6.6   6.2   6.8   0.0
  4.|-- TPDT-3011.hinet.net        0.0%    10    7.8   8.8   7.6  10.5   0.7
  5.|-- tpdb-3311.hinet.net        0.0%    10    6.4   6.7   6.3   7.8   0.3
  6.|-- 203-75-228-33.HINET-IP.hi  0.0%    10    7.4   7.3   7.0   7.6   0.0
  7.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
  8.|-- edge-star-shv-02-tpe1.fac  0.0%    10    7.3   7.3   6.8   7.7   0.0

而且 Facebook 上的圖片會導到 scontent-tpe.xx.fbcdn.net,這樣產生的量應該不小?而用 Googlescontent-tpe.xx.fbcdn.net,可以看到大約是在 2015/02/14 上線的。

透過幾個不同的 ISP 看了一下 routing,應該是跟國內幾個 ISP 有 peering,沒有的就走 TPIX 交換。

不過學術網路 (TANet) 得繞到香港 HKIX 再回來,這就有點虧了,不曉得 Facebook 對學網是不是吐其他的 endpoint 出去。(有租用國際線路 transit 的學校應該會走租用的國際線路,通常是 TWGate 就交換到 TPIX,不會這樣繞...)

對付最近 HiNet 到 CloudFlare 不穩定的情況

解法是透過 proxy.hinet.net:80 的 Proxy 服務避開,利用 Proxy 的 IP 出國優先權比較高至少能通。下面說明一下原因。

這可以解決不少網站不順的問題,像是 Stack Overflow 有用到 CloudFlare 的服務。

可以看一般家用的 IP 去 ping (2015/01/22 00:31):

--- www.cloudflare.com.cdn.cloudflare.net ping statistics ---
101 packets transmitted, 63 received, 37% packet loss, time 104589ms
rtt min/avg/max/mdev = 88.208/131.391/227.889/45.322 ms

即使是這個時間,CloudFlare 的品質仍然是爛到爆炸。

另外看這兩張圖,這是在 HiNet 機房端對 www.cloudflare.com.cdn.cloudflare.net 這個網域的 ICMP ping 的 latency 與 packet loss 記錄:

這是機房端的 IP 監控的資料,可以看到 latency 會飄高,但至少將 packet loss 維持在一定程度以下。這也是為什麼 proxy.hinet.net:80 可以避開這個問題。

另外我利用 HiNet 所配發的 PPPoE static IP 測試,也可以避開這個問題,所以 IP 分享器撥號時使用 PPPoE static IP 的方式也可以避開。