Gea-Suan Lin's BLOG for Networking

Saturday, October 15, 2011

Akamai 與 CDNetworks...

這幾天在 CDN 產業裡面兩個比較大的大消息，一個是 KDDI 丟出打算併購 CDNetworks 的消息。另外一個是傳言 Google 要併購 Akamai。

前者的消息已經確認 (KDDI to Buy CDNetworks to Ensure Smooth Internet Access: Kyodo)，後者 Google 則是否認這則消息 (Google Is Said Not to Be Planning to Acquire Akamai Technologies Business)。

不過 CDN 技術愈來愈成熟，就愈來愈像賣頻寬的公司...

Sunday, September 25, 2011

在 Slashdot 上看到歐亞網路 (香港到倫敦) 的 latency 又降低 20ms 了：「Low-Latency Network Shaves Milliseconds from UK-Asia Traffic」、「Low-Latency Network To Connect London And HK」。

主要的改善是來自於本來走西伯利亞的線路，現在改走蒙古... 不知道友沒有其他更低的線路... :o

Wednesday, May 18, 2011

www.ipv6.org.tw 的品質...

不知道最近在做什麼大事業，從台灣固網提供的 IPv6 native network 過去：

gslin@ipv6-test [~] (4:37) sudo ping6 -c 10 -i 0.2 www.ipv6.org.tw
PING6(56=40+8+8 bytes) 2001:4541:0:5:2e0:81ff:feb0:ddc3 --> 2001:c50:ffff:1:21a:92ff:fe43:d665
16 bytes from 2001:c50:ffff:1:21a:92ff:fe43:d665, icmp_seq=0 hlim=56 time=112.814 ms
16 bytes from 2001:c50:ffff:1:21a:92ff:fe43:d665, icmp_seq=1 hlim=56 time=137.987 ms
16 bytes from 2001:c50:ffff:1:21a:92ff:fe43:d665, icmp_seq=2 hlim=56 time=107.889 ms
16 bytes from 2001:c50:ffff:1:21a:92ff:fe43:d665, icmp_seq=3 hlim=56 time=114.263 ms
16 bytes from 2001:c50:ffff:1:21a:92ff:fe43:d665, icmp_seq=4 hlim=56 time=101.525 ms
16 bytes from 2001:c50:ffff:1:21a:92ff:fe43:d665, icmp_seq=5 hlim=56 time=118.025 ms
16 bytes from 2001:c50:ffff:1:21a:92ff:fe43:d665, icmp_seq=6 hlim=56 time=100.039 ms
16 bytes from 2001:c50:ffff:1:21a:92ff:fe43:d665, icmp_seq=7 hlim=56 time=113.664 ms
16 bytes from 2001:c50:ffff:1:21a:92ff:fe43:d665, icmp_seq=8 hlim=56 time=146.900 ms
16 bytes from 2001:c50:ffff:1:21a:92ff:fe43:d665, icmp_seq=9 hlim=56 time=124.038 ms

--- www.ipv6.org.tw ping6 statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 100.039/117.714/146.900/14.235 ms

然後用 IPv4 過去：

gslin@ipv6-test [~] (4:37) sudo ping -c 10 -i 0.2 www.ipv6.org.tw
PING www.ipv6.org.tw (210.17.9.228): 56 data bytes
64 bytes from 210.17.9.228: icmp_seq=0 ttl=57 time=111.309 ms
64 bytes from 210.17.9.228: icmp_seq=1 ttl=57 time=117.711 ms
64 bytes from 210.17.9.228: icmp_seq=2 ttl=57 time=90.354 ms
64 bytes from 210.17.9.228: icmp_seq=3 ttl=57 time=122.724 ms
64 bytes from 210.17.9.228: icmp_seq=4 ttl=57 time=132.470 ms
64 bytes from 210.17.9.228: icmp_seq=5 ttl=57 time=92.495 ms
64 bytes from 210.17.9.228: icmp_seq=6 ttl=57 time=114.230 ms
64 bytes from 210.17.9.228: icmp_seq=7 ttl=57 time=135.975 ms
64 bytes from 210.17.9.228: icmp_seq=8 ttl=57 time=121.982 ms
64 bytes from 210.17.9.228: icmp_seq=9 ttl=57 time=93.132 ms

--- www.ipv6.org.tw ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 90.354/113.238/135.975/15.608 ms

是怎麼了 @_@

Monday, April 11, 2011

Level 3 以 30 億美金的股票買下 Global Crossing

Level 3 與 Global Crossing 這兩家在全世界都是屬於超大 ISP (兩個都是 Tier 1 network，而且都有在 NASDAQ 掛牌)。

今天這兩家公司往 SEC 丟申請，Level 3 準備以價值 USD$3B 的股票買下 Global Crossing... (拉椅子看好戲啊)

Friday, November 19, 2010

CDN

很久沒寫這個 blog 了，來清理一下以免草長太長 XD

這兩年實際用過不少家 CDN 了，包括一開始的 Panther Express (後來被 CDNetworks 併購)，後來也跟 EdgeCast 租用，接下來是 AWS CloudFront 的出現，再來是跟 Akamai 租用。

其實很多單位都只是把 CDN 當作是一種 cache server 的服務，目的只是減少維護的成本，以及提高穩定性。一堆 CDN 業者吹捧的那些功能其實都只是附加的，甚至連 CDN 最重要的 latency issue，大多數的客戶根本不在乎。

既然只是當作 HA cache server，這項技術其實不難，用兩台 HAProxy 當作 Load balancer (約 NTD$0.1M) 加上兩台 Squid2 (約 NTD$0.5M)，以這幾年的 CPU 與 RAM 在 NTD$0.6M 內就可以打死。實際流量大約可以跑出 300Mbps+。

如果改用 Lusca (就 Squid2 的設定檔稍做修改就可以跑，或是參考網路上很多 Squid 的文件，門檻比較低)，大約可以跑到 600Mbps+。如果可以用 Traffic Server，那麼幾乎就是壓榨出硬體極限 (就目前看起來跑 1Gbps+ 應該沒問題)。

如過遇到大量的量衝進來時，反而會因為 cache 集中性高，幾乎都是 memory hit 而不太會影響效能。

在這麼低的一次性資本支出成本下，國內的客戶在找 CDN 談的時候幾乎都是當作頻寬費用在談。事實上也的確應該當作頻寬費用在談就好，不需要被 sales 催眠以為那些進階功能很好用。

國內目前有經銷商的有 Akamai 與 EdgeCast。我建議在台灣都不要跟這兩家經銷商談。

Akamai 是由併力科技代理，不跟他們談的原因有兩個：

Akamai 的優點在於他的密度，這是要在自己網站把所有最佳化都做到底以後才看的出來比其他 CDN 好。國內的網站都沒有能力做到這點。
Akamai 的台灣是唯一經銷商，而這家經銷商的態度很強勢。就每次開會與解決問題的觀感並不好。

EdgeCast 在台灣則是怡德。我們當初跟 EdgeCast 接觸的時候是直接跟國外原廠接觸。怡德是後來代理的公司，這家公司在代理之前跟網路內容產業根本沒關係，代理後也有跑來找我們談，我的建議是「能直接跟 EdgeCast 原廠聯絡就直接聯絡」。

有機會再看看還能聊什麼...

Sunday, November 23, 2008

從台固到 www.ru

從台灣 NTT 到日本，再到美國，再到英國，然後轉進俄羅斯：

traceroute to www.ru (194.87.0.50), 64 hops max, 52 byte packets 1 gw-60-199-247-254.pixnet.tw (60.199.247.254) 0.673 ms 0.471 ms 0.492 ms 2 60-199-248-49.static.tfn.net.tw (60.199.248.49) 0.486 ms 0.477 ms 0.491 ms 3 60-199-255-113.static.tfn.net.tw (60.199.255.113) 0.239 ms 0.227 ms 0.241 ms 4 60-199-6-125.static.tfn.net.tw (60.199.6.125) 0.364 ms 0.354 ms 0.366 ms 5 60-199-6-2.static.tfn.net.tw (60.199.6.2) 6.235 ms 0.480 ms 0.364 ms 6 60-199-6-222.static.tfn.net.tw (60.199.6.222) 0.625 ms 0.479 ms 0.589 ms 7 61.58.33.189 (61.58.33.189) 0.697 ms 61.58.33.145 (61.58.33.145) 0.607 ms 0.606 ms 8 xe-1-0-0.r21.taiptw01.tw.bb.gin.ntt.net (129.250.16.169) 0.864 ms 0.728 ms 0.740 ms 9 as-2.r21.tokyjp01.jp.bb.gin.ntt.net (129.250.4.81) 31.596 ms 31.720 ms 31.713 ms 10 ae-3.r21.osakjp01.jp.bb.gin.ntt.net (129.250.4.214) 74.068 ms 40.205 ms 40.090 ms 11 as-1.r21.sttlwa01.us.bb.gin.ntt.net (129.250.3.87) 133.416 ms 133.520 ms 133.534 ms 12 as-1.r20.nycmny01.us.bb.gin.ntt.net (129.250.3.191) 221.853 ms 221.841 ms 221.855 ms 13 as-1.r22.londen03.uk.bb.gin.ntt.net (129.250.3.255) 298.929 ms 295.420 ms 295.305 ms 14 xe-4-4.r01.londen03.uk.bb.gin.ntt.net (129.250.2.66) 289.934 ms 289.922 ms 293.930 ms 15 * * * 16 transtelecom-0.r01.londen05.uk.bb.gin.ntt.net (83.231.146.86) 355.979 ms 357.880 ms 377.121 ms 17 demos-gw.transtelecom.net (217.150.57.89) 350.517 ms 354.882 ms 350.527 ms 18 iki-c1-vl10.demos.net (194.87.0.111) 355.508 ms 354.507 ms 352.039 ms 19 www.ru (194.87.0.50) 352.881 ms 351.010 ms 351.147 ms

日本到俄羅斯居然這麼遠...

Thursday, September 04, 2008

DNS server 與 AS

昨天 #bsdchat 剛好在討論 tw.freebsd.org 的 NS server 的事情。目前很多 freebsd.org 的 subdomain 都只有在當地，像是日本、南韓、德國：

jp.freebsd.org. 3600    IN      NS      ns3.imgsrc.co.jp.
jp.freebsd.org. 3600    IN      NS      castle.jp.freebsd.org.
jp.freebsd.org. 3600    IN      NS      asuka.jp.freebsd.org.

kr.freebsd.org. 86400   IN      NS      ns.ziom.co.kr.
kr.freebsd.org. 86400   IN      NS      ns2.ziom.co.kr.

de.freebsd.org. 10771   IN      NS      ns.cs.tu-berlin.de.
de.freebsd.org. 10771   IN      NS      baerenklau.de.freebsd.org.

這其實對於 DNS 架構來說，並不是很好的設計。比較好的設計是放到不同地區 (不同洲)，確保不會一起掛掉。

主要的原因在於有些服務會對「查不到 DNS record」很敏感，像是 mail system：

對於 username@tw.freebsd.org 的人，發信時如果找不到 tw.freebsd.org 的 MX 與 A record，被認定是 spam 的分數會上升。
對於寄信到 username@tw.freebsd.org 的人，如果找的到 MX 或是 A record，但連不到 mail server，那麼這封信會被保留在 mail system 裡面。但如果找不到，會馬上被退信。

所以，要避免大停電或是大斷線影響其他系統，應該要儘量把 NS server 放到不同地區，不同 AS# 的網路上。