歐亞網路 (香港到倫敦) 的 latency

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

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

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

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

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

是怎麼了 @_@

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

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

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

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 是由併力科技代理，不跟他們談的原因有兩個：

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

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

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

從台固到 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

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

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：

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

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

國內的網路，與 CDN

前陣子跟一堆老外們談 CDN 服務，計費方式還蠻彈性的，常見的兩種包括以實際流量計算，或是 MRTG 五分鐘圖 sorting 95% 流量計算。

不過，值得提出來的，CDN 的價錢比起國內的頻寬都便宜。以 Slideshare 這個站公開的數據來看 (Panther Express and S3)，每個月重新計算，第一個 8TB 是 USD$0.28/GB，第二個 8TB 是 USD$0.24/GB。

如果網站有區域性，100Mbps (MRTG 五分鐘圖 sorting 95% 計算方式) 大約是 20TB/month，照比率計算，第一個 8TB 換算成 sorting 95% 是 40Mbps 的量，也就是 NTD$1764/Mbps。這個價錢如果在國內的 ISP 只買 40Mbps，在不靠關係，又要有一定的網路品質，是不可能的數字...

以目前來看，把靜態檔案丟到 Amazon S3 上，以 reverse proxy CDN 算是相當好的方式。

對了，國外的 CDN 大多都有提供試用的服務，跟 sales 要求，通常都有測試的機會。Wikipedia 上的 Content delivery network 這個條目下面列的公司都可以寫信去問看看。

寫自己的 PHP Controller

我對於 Zend Framework 的 Zend_Controller 實在是搞不太懂，要求使用 PHP5，但又沒用到 PHP5 的特性...

我理想中的 Controller 是透過 PHP5 的 ArrayAccess 實做這樣的效果的：

$name = $c['name'];
$c['Content-Type'] = 'text/plain; charset=UTF-8';

我花了點時間開始寫自己的 Controller，希望善用 PHP5 語言特性使得寫起來比較方便，順便玩玩 Mercurial 的操作方式。

目前 Repository 放在 freeHG 上：Hasname Controller，有想要看看到底是怎麼搞的人可以自己 clone 回去看，等之後功能比較完整後再開始來寫文件。

太久沒到這邊來寫 blog...

太久沒寫 Blog 反而被標上 Spam Blog？XD (寫文章需要 CAPTCHA)

FreeBSD 上 rpc.lockd 的問題

FreeBSD 上 rpc.lockd 常常會自己掛掉。如果是 clients 的 rpc.lockd 掛掉，會使得 flock() over NFS 掛掉，而如果是 servers 的 rpc.lockd 掛掉，會使得所有 clients 的 flock() over NFS 掛掉 =_=

這個問題自從我們將某幾台 ccbsd*.csie clients 換成 FreeBSD 6.0-RELEASE 後就發現這幾台一直有問題，後來決定將 cchome.csie 與 mailgate.csie 也一起升級到 FreeBSD 6.0-RELEASE，看看能不能解決這個問題。結果反而變成大家都有問題... -_- 而且 ccsun*.csie 只要一開機，所有的 clients 就會炸掉，但這些 ccsun*.csie 裡面，如果只開 ccserv.csie 也不會有事情...。

這個問題當時猜測是 FreeBSD 4.x 與 6.x 的 clients 混在一起跑造成的，於是狠下心來將 ccbsd*.csie 全部升級到 FreeBSD 6.0-RELEASE (另外一個原因是 FreeBSD 4.x 已經不繼續維護了)，結果升級上去發現問題還是沒變好，只好試著惡搞所有能惡搞的功能 (像是 mount_nfs 裡的 -L local lock)，發現還是沒有用。

前幾天想到 ktrace 可以看 system call 的情況，拿出來追，發現 uid=daemon 的 rpc.lockd 最後居然是死在 SIGPIPE，將這個 bug 用 send-pr 送出去幹剿後，rpc.lockd 的 maintainer 丟出一個神秘的 patch：把 SIGPIPE 用 signal(SIGPIPE, SIG_IGN) 堵掉，#bsdchat 上面看到這個 patch 把他叫做「掩耳盜鈴」，當作沒聽到，幹就對了 XD：Problem Report bin/97768 : NFS rpc.lockd will die automatically。

雖然這個方法看起來很鳥，但我還是決定把這個 patch 弄進所有 ccbsd*.csie 上跑，然後開 ktrace 盯著看還會有什麼死法。跑了快一天，發現 ccbsd*.csie 跑起來好像不錯，寫了封信跟 maintainer 講... 沒多久就看到 cvs commit 記錄：cvs commit: src/usr.sbin/rpc.lockd kern.c，結果才剛 commit 完沒多久就發現 uid=root rpc.lockd 死掉 XD

看了一下 uid=root rpc.lockd 死掉時 ktrace 的紀錄，發現也是 SIGPIPE 的問題，正覺得奇怪，明明 mask 掉了，怎麼還會死在 SIGPIPE... 回頭看 patch 發現是因為 signal() 在 fork() 後才做，所以 uid=root 那隻沒有處理 SIGPIPE，只好再跟 maintainer 講，問看看能不能把 signal() 放到 fork() 前。(主要是他對 rpc.lockd 比較熟，可能會比較清楚各類後遺症 XD)

結果 maintainer 就叫我去測測，沒問題就照我說的 patch 進 -current XD 我就跑去跟 chwong 要了 cchome.csie 與 mailgate.csie 的 root，要跑 ktrace 盯著看。

測了一天看起來沒問題：rpc.lockd 沒死，mutt 看信也都很正常，看起來 locking 功能運作得很好，就回封信跟 maintainer 講這個情況，過不久就看到他把 signal() 搬到 fork() 前的 cvs commit 紀錄：cvs commit: src/usr.sbin/rpc.lockd kern.c，這個 patch 的 rpc.lockd 到現在都還活得很好，看起來在 6/1 那天就會進 RELENG_6 了 :)

然後在 #bsdchat 上看到 rafan 把這個 patch 也丟進 csie.ntu 的機器上跑，發現對於 NFSv2 的 Sun 也正常多了 (打開 debug mode 還是會看到一堆 error msg，不過至少會動...)，於是我剛剛就很高興的跑去學校把 ccsun*.csie 通通開起來測，目前看起來也都沒問題...

折騰了兩個月，NFS 的 rpc.lockd 這件事情看起來暫時穩定多了，希望有長輩把 rpc.lockd 修一修，尤其是 recovery 的部分，如果寫完的話才能隨意關機開機 XD

lighttpd + WordPress 2.0 對於 Permlink 的處理

lighttpd + WordPress 2.0 使用 Permlink 的設定，重點在於 lighttpd.conf 裡的 mod_rewrite：

url.rewrite = ( "^/(archives|categories|comments|feed)/" => "/index.php" )

WordPress 裡 Permlink 則是設成：

/archives/%year%/%monthnum%/%day%/%post_id%/

Category 的部份則是：

/categories

FreeBSD NFS locking 問題

我們一直以為是 4.x 與 5.x/6.x 之間的問題，結果剛剛 ericlin 丟了一個這幾天的討論串過來，大光頭 Kris 還提供了一個 patch，是 lock_proc.c 這個檔案從 1.17 到 1.18 的 patch (6.0-RELEASE 是 1.18)：NFS locking question。

這個 patch 看起來是 transmit_result() 與 transmit4_result() 的修正，不知道 4.x 有沒有 svc_getcaller()，如果有的話可以試著 patch 看看...

IE7 的 SSL 安全政策

有長輩測試 IE7 Beta2 後發現 IE7 Beta2 對於 SSL 設定有問題的站台會整個擋掉，而不會像以前那樣跳初一個小視窗出來要你確認：Stupid Google SSL Certificates。

文章裡 Jeremy Wright 舉了 Google 的例子：他說 Google 的某些服務使用了 www.google.com 的 SSL Certificate，但是使用的站台並不是 www.google.com。

不過我不記得 Google 哪個服務是這樣惡搞的啊？還是 Firefox 遇到同一個 Domain 的情況不會哀哀叫？這樣就太糟了...

在交大使用 Bittorrent 的問題

這幾天用 Bittorrent 抓一些東西，發現如果不是使用 BitComet (目前唯一一個有支援 Header Encryption 的 Bittorrent Client，而且 Windows Only...)，幾乎不會動 (檔案很熱門也一樣)。

即使只有放在出國電路的部份 (自己購買的出國電路)，但是因為是 Default Gateway，所以可以很明顯感覺出來。

真無奈，兩邊 (ISP 與發展者) 互相鬥法，最後就得靠一些數學方法 (Cryptosystem) 決戰... 輸的永遠是使用者 (需要更多的 CPU resource 做運算)。

Apache 2.1 - MPM event

在 mclee 那邊看到 Apache 2.2 出版了，翻 Overview of new features in Apache 2.2 的時候看到 Apache MPM event，回頭看記錄發現 Apache 2.1 就有了。

不知道我是不是有猜錯，這應該是 Event-driven 的 module 吧？hmmm...

Linux epoll() performance

在找一些資料的時候發現 zmx 的舊文章 (也沒有很舊，半年前的文章)，談 Linux epoll() performance 的改善：Comparing and Evaluating epoll, select, and poll。

這篇文章裡提到了 epoll() 在 idle connection 很少的情況下，與 poll() 或 select() 改善的空間不會太多，大概就只有省下從 kernel 要修改 userland space 的時間吧。

對於 Connection 數目很大的 HTTP server (所謂的 The C10K problem)，BSD 上的 ACCEPT_FILTER_HTTP 還是很重要，可以省下 accept() 進來卻慢慢送 Header 的情況 :p

Web Performance Tools - Siege

剛剛在 ijliao 那邊看到 O3 Magazine，看了 Lighttpd 的測試報告，發現測試報告裡面不是用 ab，而是用 Siege。看了一下 ab 與 Siege 的差別：

Siege is an http regression testing and benchmarking utility. It was designed to let web developers measure the performance of their code under duress, to see how it will stand up to load on the internet. Siege supports basic authentication, cookies, HTTP and HTTPS protocols. It allows the user hit a web server with a configurable number of concurrent simulated users. Those users place the webserver "under siege."

這樣看說明可能看不太出來，Siege 與 ab 主要的差別在於同時發出的 Request 不一樣 (於是會比較逼近真實的情況)。

查了一下 FreeBSD Ports 裡面，發現在 benchmarks/siege 下面有，邊裝邊找中文的說明文件，在 Siege：压力模拟/测试工具 這篇裡面有很簡單的說明，等下來用 WWW::Mechanize 寫個小程式抓網頁 url 測試看看。

Thread-safe gethostbyname() on FreeBSD 6.0

前陣子在我個人板上有寫，FreeBSD 6.0 的 gethost*() 已經 Thread-safe 了：

1. gethostbyname manpage on FreeBSD 6.0
2. gethostbyname manpage on FreeBSD 5.4

在最下面 BUGS 的地方寫的還蠻清楚的，所以我就寫了個小程式測試，在不同的 Thread 裡面不斷的呼叫 gethostbyname()，看傳回來的位置是什麼：

#include <netdb.h>
#include <pthread.h>
#include <stdio.h>

#define THREAD_NUM      (3)

void *thread_start()
{
    const pthread_t tid = pthread_self();

    int i;
    for (i = 0; i < 5; i++) {
        struct hostent *p = gethostbyname("ccca.nctu.edu.tw");
        printf("tid = %d, gethostbyname() = %p\n", tid, p);
        sleep(1);
    }

    return;
}

int main(void)
{
    pthread_t tid[THREAD_NUM];

    int i;
    for (i = 0; i < THREAD_NUM; i++)
        pthread_create(tid + i, NULL, thread_start, NULL);

    sleep(10);
}

Squid 3 的設定

Squid 3 網站上的 20051125 版 是有問題的，後來透過 cvs 抓到的版本就 okay 了。本來是要在 www.cs.nctu.edu.tw 上面測試的，後來被提醒 11/25 碩班甄試放榜，那我們就換回舊的版本了。

我後來在 netnews.nctu.edu.tw 上面架了一個，bind 在 127.0.0.1:3128 上面給自己用 (putty tunnel，3128:127.0.0.1:3128，然後把我 Laptop 與 Desktop 的 Firefox 都設定 127.0.0.1:3128 為 Proxy Server)，因為 netnews.nctu.edu.tw 是 FreeBSD 6.0，所以我在安裝的時候特地把 Thread 有關的選項打開 (像是 aufs)，先測看看 stability 如何，晚點再來測試看看 performance。

這是我 compile 時的參數：

--prefix=/home/squid --enable-storeio="ufs aufs diskd" --enable-disk-io="Blocking" --enable-removal-policies="heap lru" --disable-wccp --enable-cache-digests --disable-poll --disable-select --enable-kqueue --disable-epoll --disable-ident-lookups --enable-underscores --disable-unlinkd --enable-x-accelerator-vary --with-aufs-threads=8 --with-pthreads --with-aio

會同時把這麼多東西 compile 進去主要是要測試各種 algorithm 的效能，實際在跑的時候可能會再拔掉一些 :p