網路的延遲（Latency）與頻寬（Bandwidth）是什麼？

網路的 Bufferbloat 問題

Bufferbloat 這個名詞是由 Jim Gettys 在 2010 年創造出來的，這是一個 queuing delay 影響整個網路效能的好例子。

這裡面的問題在於現在許多路由器都配備有很大的緩衝儲存空間，為的就是確保沒有封包會因為裝不下而遺失，但是這個做法卻會破壞了 TCP 連線避免網路擁塞的機制（congestion avoidance mechanisms），並且產生更高的網路延遲。

還好現在已經有一個新的 CoDel active queue management 演算法已經被提出來了，目前正實作於 Linux 3.5+ 版本的核心中，如果你要了解更多關於這方面的資訊，可以參考 ACM Queue 的 Controlling Queue Delay 說明。

光速與 Propagation Latency

愛因斯坦（Einstein）在狹義相對論（special relativity）中指出：任何能量、物質與訊息的傳遞速度上限就是光速，這個現象也成為 propagation time 的一個不可突破的限制。

好消息是光速很快，每秒可以傳遞 299,792,458 公尺，但是壞消息是這個速度是光在真空的狀態下所行走的速度，而我們的網路封包通常都是在一些介質中傳遞（如銅線或光纖），這會造成傳遞的速度下降（詳見下表）。而光在真空中的速度與介質中的速度比就是該介質的折射率（refractive index），折射率越大的介質訊號在其中傳遞的速度就越慢。

目前網路封包在長距離的傳輸上都是使用光纖（optical fiber），其折射率大約是在 1.4 到 1.6 之間，未來如果材料科學日益進步，也有可能可以降低這個數值，若以 1.5 的折射率來計算，訊號在光纖中的傳遞速度已經達到每秒大約 200,000,000 公尺，這已經是一個很快的速度了，另外這個速度也距離理論上的最快速度不遠。

雖然光速非常快，但是在美國紐約與澳洲雪梨之間往返還是要花 160 毫秒的時間，另外這個時間是依據地球上的兩地的最短距離來計算的，實際上也不可能會有這樣的電纜線可以使用，通常網路封包實際的傳輸距離會比這裡的距離更長，並且還要加上中間各個路由器所產生的 routing、processing、queuing 與 transmission delays，因此結合這些零零總總的因素，從美國紐約到澳洲雪梨之間實際的 RTT 大約會在 200 到 300 毫秒之間，不過看起來其實還是很快。

在一般的情況下，我們通常不會在生活中使用毫秒這樣小的單位來計時，但是根據研究顯示，延遲時間達到 100 到 200 毫秒時，人就會感覺到有點「lag」，到了 300 毫秒時，就會感覺更嚴重的遲滯，而到了 1000 毫秒（1 秒）時，人就會開始轉移注意力到其他的事情上了。

也就是說在開發任何應用程式時，若要讓使用者有好的使用經驗，並且可以專心在自己要處理的事情上，你必須要設法將延遲控制在 100 毫秒之內，尤其是在牽涉到網路的應用程式上更容易出現這個問題，所以如果想要發展出好的網路應用程式，在程式發展與設計的各個階段都要小心控制好網路的延遲。

內容傳遞網路

內容傳遞網路（Content delivery network，簡稱 CDN）有許多的優點，其中一個很重要的就是將伺服器分散在不同地點，讓世界各地的使用者可以從離自己最近的伺服氣上取得資料，這樣可以有效減低封包傳遞的 propagation time。

雖然封包傳遞的速度無法加快，但是我們可以透過減短傳輸路徑的方式來讓網路延遲下降，有效利用 CDN 的機制可以對於整體的效能有顯著的提昇。

最後一哩路

雖然橫跨海洋或大陸的距離很長，但是通常主要造成網路延遲的地方卻不是這些長距離傳輸的過程，而是在到達目的地前的最後一哩路（last-mile）。

為了要讓每個人都可以上網，地方的 ISP 必須將電纜線拉到每一家每一戶，把一個地區內所有的網路封包集中到 ISP 的路由器上，再對外進行傳送，而這個動作會因為 ISP 的佈線設計與所使用的技術不同而造成不同的網路延遲，不過通常大約是數十毫秒左右。

根據美國聯邦通信委員會（Federal Communications Commission，簡稱 FCC）在 2013 上半年的 Measuring Broadband America 報告顯示，在網路流量較大的時段，光纖在 ISP 路由器到使用者家中這段傳輸所花費的平均時間是 18 毫秒，而一般的電纜線（cable）花費的時間是 26 毫秒，而 DSL 則是 44 毫秒。

這裡的 18 到 44 毫秒只是網路封包從使用者的家裡傳輸到最近的 ISP 路由器所花費的時間，根本還沒開始對外進行後續的傳送。FCC 這份報告是針對美國所做的研究，不過不果你在哪裡，最後一哩路的網路延遲是每一個 ISP 都會遇到的問題，如果你有興趣看看自己的 ISP 所提供的網路品質，在 Linux 與 Mac OS X 中可以使用 traceroute 指令來檢測看看，若在 Windows 系統則可使用 tracert：

traceroute google.com

輸出為

traceroute to google.com (74.125.224.102), 64 hops max, 52 byte packets
1 10.1.10.1 (10.1.10.1) 7.120 ms 8.925 ms 1.199 ms1
2 96.157.100.1 (96.157.100.1) 20.894 ms 32.138 ms 28.928 ms
3 x.santaclara.xxxx.com (68.85.191.29) 9.953 ms 11.359 ms 9.686 ms
4 x.oakland.xxx.com (68.86.143.98) 24.013 ms 21.423 ms 19.594 ms
5 68.86.91.205 (68.86.91.205) 16.578 ms 71.938 ms 36.496 ms
6 x.sanjose.ca.xxx.com (68.86.85.78) 17.135 ms 17.978 ms 22.870 ms
7 x.529bryant.xxx.com (68.86.87.142) 25.568 ms 22.865 ms 23.392 ms
8 66.208.228.226 (66.208.228.226) 40.582 ms 16.058 ms 15.629 ms
9 72.14.232.136 (72.14.232.136) 20.149 ms 20.210 ms 18.020 ms
10 64.233.174.109 (64.233.174.109) 63.946 ms 18.995 ms 18.150 ms
11 x.1e100.net (74.125.224.102) 18.467 ms 17.839 ms 17.958 ms2
1第一個節點：最近的無線路由器。

2最後一個節點：Google 的伺服器。

在這個例子中，網路封包從桑尼維爾（Sunnyvale）轉送到聖塔克拉拉（Santa Clara）、奧克蘭（Oakland）、聖荷西（San Jose），然後傳送至「529 Bryant」資料中心，在那裏轉送到 Google 的伺服器上，整個過程平均花費大約 18 毫秒，看起來狀況很不錯。

在來看從中華電信的 ADSL 到 www.hinet.net 網站的狀況：

traceroute www.hinet.net

traceroute to www.hinet.net (202.39.253.11), 30 hops max, 60 byte packets
1 192.168.0.1 (192.168.0.1) 1.892 ms 2.899 ms 3.924 ms3
2 h254.s98.ts.hinet.net (168.95.98.254) 36.023 ms 46.580 ms 55.882 ms4
3 TNE1-3302.hinet.net (168.95.55.66) 65.940 ms 75.746 ms 85.351 ms
4 220-128-26-174.HINET-IP.hinet.net (220.128.26.174) 101.891 ms 111.215 ms 120.804 ms
5 TPDT-3011.hinet.net (220.128.3.2) 134.804 ms 143.425 ms 154.244 ms
6 TPDB-3407.hinet.net (220.128.1.237) 159.549 ms 39.179 ms 38.197 ms
7 211.22.41.237 (211.22.41.237) 48.753 ms 59.041 ms 69.141 ms
8 202-39-253-11.HINET-IP.hinet.net (202.39.253.11) 77.444 ms 88.009 ms 97.337 ms5
3第一個節點：最近的無線路由器。

4第二個節點：中華電信 ADSL 機房的路由器，從這裡開始網路延遲很明顯了。

5最後一個節點：HiNet 網站。

最後一哩路的問題會跟你的 ISP 所使用的技術、網路拓撲結構有關係，甚至跟你在什麼時間上網也會有關，以一般的使用者而言，如果你想要讓上網的速度可以更快，選擇網路延遲較低的 ISP 是一個值得一試的方法。

對於大部份的網站而言，效能的瓶頸通常都會發生在網路的延遲而不是頻寬上，至於為什麼是這樣你必須先了解 TCP 與 HTTP 的運作流程，我們在後面的文章將會有詳細的解說。

請繼續閱讀下一頁。