小隔間裡的人生

使用者和管理者都可以試試看喔。

剛剛看到一篇文章，提到 Aaron Hopkins 寫了一篇分析，簡介了一些加速網頁瀏覽的方法。

先說結論好了：使用者端可以做的就是打開 HTTP pipelining，Firefox 使用者只要在 URL 列打 about:config 然後找出 network.http.pipelining，改成 true 即可。而在伺服器端，也有些有趣的設定可以做，例如說使用 4 個 hostname (就算對應到同一個 IP 也無妨)、打開 HTTP keepalive、想辦法減少 HTTP header 的大小 (例如少送不必要的 cookie 之類)。

接下來我們就細說從頭，為什麼會得到上面的那些結論 ? 根據 Hopkins 的第一次模擬，他假設了 1.5M / 384k 的 100ms ADSL 使用者，每次 request 的大小是 500 bytes，得到下面的比較圖：

可以觀察到：

• 小檔太多的話，在下載頻寬被吃完前，上傳頻寬就已經被 request 吃掉了 (每抓一個小檔就要送一次 request)；object size 差不多要到 100k 才會完整利用所有下載頻寬。也就是說，以前流行的那種把大圖切成很多小圖在傳的技術其實並不會比較快。
• 一定要打開 HTTP keepalive，也一定要生出 4 個 hostname，效能的提升十分明顯。至於為什麼是 4 個 hostname 呢 ? 因為 Firefox 和 IE 在使用 HTTP/1.1 的時候每個 hostname 最多只會用 2 個 connection、而且總 connection 數最多是 8，所以選擇 4 個 hostname 可以榨出所有能力。
• 如果使用者打開 HTTP pipelining 的話那是最好，問題在於你不可能控制使用者的設定…

下一個模擬是告訴你到底設定 4 個 hostname 和 HTTP keepalive 能幫你爭取到多少加速空間 (比較標準是沒開 keepalive 然後只有 1 個 hostname)：

可以觀察到：

• 如果 object 不大的話，無論連線速率和品質如何都能得到不錯的提升，從 0.5 倍到快 7 倍都有可能。
• 對於 rtt 比較大的使用者，效能的提升很顯著。
• 如果使用者有大頻寬的話，效能的提升也很顯著。

最後一個模擬是告訴你為什麼要想辦法把 HTTP header 縮小：

可以觀察到 object 越小，header size 的影響就越明顯。

接下來他給了一些建議：

• 打開 HTTP keepalive。如果怕把 server connection pool 塞爆的話，不妨把 timeout 設短一點；另外，static 檔案可以另外用一個專門的伺服器來處理。
• 少用一些額外的檔案，像是 img / CSS / js 之類的；如果要用的話，想辦法把它們統整起來。
• 使用 4 個 hostname。
• 想辦法讓 cache 派上用場，例如說把 Expires 設長一點；當檔案有變動時，直接改 URI 讓 browser 重新讀取 (例如說在 URI 裡加上版本編號之類)。
• 想辦法把 HTTP header 縮小，這可以從 cookie 下手。一般來說 cookie 都是設定成對整個 domain 都有影響，也就是說雖然你的 img / CSS / js 根本不會用到 cookie，在載入的時候 browser 還是會把 cookie 送出去；解法就是把這些 static 檔案放在另外的 domain 裡。
• 想辦法把 object 縮小，例如說開啟 gzip 壓縮功能。
• 想辦法把小檔放在離使用者近一點的地方，例如使用 CDN，或是直接根據使用者的來源來選定 colocation。
• 開發者要從使用者的角度來看問題，直接從隔壁用 GE 連上網站的開發者是無法了解位在遠端而且還常斷線的使用者的苦處的。
• 想辦法說服 browser 的大廠在預設值裡把 HTTP pipelining 打開；從第一個模擬裡面可以知道這招比 設 4 個 hostname + 打開 HTTP keepalive 還猛。

Technorati Tags: web, usability, browser, http, optimize