在過去幾年中，網路效能最佳化（web performance optimization，簡稱 WPO）這個產業快速成長，這個現象也顯示了網路速度對於使用者而言也越來越重要，如果一個網站可以提供比較快速的網路服務，除了改善使用者經驗之外，連同網站的流量與其附帶的效益也都會跟著增加。
網站速度對於使用者（顧客）的影響應該是顯而易見的，一個網站要讓使用者感覺很好，除了網頁設計與美工之外，瀏覽網頁的流暢度也很重要，如果使用者在瀏覽一家公司的網站時，看網頁老是要等很久，即便網站做得很漂亮，我想大概也不會給使用者什麼好映像，反之如果網站反應速度很快，就比較不會產生這樣的問題。
而要讓網站的速度快，就要先了解許多基本的技術細節，其中會影響網路的兩個重要因素就是延遲（Latency）與頻寬（Bandwidth）：
- 延遲（Latency）：一個封包從來源端送出後，到目的端接收到這個封包，中間所花的時間。
- 頻寬（Bandwidth）：傳輸媒介的最大吞吐量（throughput）。
 |
| 網路的延遲（Latency）與頻寬（Bandwidth）示意圖 |
在了解網路延遲與頻寬的關係之後，接下來就可以更深入研究 TCP 與 UDP 兩種通訊協定的內部結構與效能特性，進而探討以這兩種協定為基礎的應用。
Hibernia Express：減低大西洋的網路延遲
在金融市場上網路的延遲對於頻繁的演算法交易（algorithmic trading）影響很大，只是幾毫秒（milliseconds）的差異也會造幾百萬的虧損或是獲利。在 2011 年年初，Huawei 與 Hibernia Atlantic 兩家公司開始建造一條橫跨大西洋的光纖網路 Hibernia Express，這條網路長達 3000 英哩，連接英國倫敦與美國紐約，而建造這條光纖網路只有一個目的，就是為了可以減少中間的路由器數量，讓交易商在這兩個城市之間使用網路傳輸資料時，可以省下 5 毫秒的網路延遲。
這條光纖網路一旦建造完成，會專門提供給金融機構來使用，建造這條網路需要花費超過 4 億美元，而在建造完成之後，這些金融機構每秒可以透過這條網路節省 8 千萬美元！網路延遲在這裡是非常昂貴的。
網路延遲（Latency）的組成元素
網路的延遲就是一個訊息或是封包從來源端傳送到目的端所需要的時間，這個定義很簡單易懂，但是在這個背後其實還隱藏了很多其他很多有用的資訊，每一種系統中都會有許多會影響網路延遲的原因，了解有哪些影響因素與其運作方式也是很重要的。在網路上有許多路由器專門負責遞送網路封包，這樣的路由器通常會有下面這些會造成網路延遲的因素：
- propagation delay：封包在網路線上傳輸所花費的時間，與網路線上電子訊號跑的速度有關，這個時間就是距離除以訊號傳送速度所得到的數值。假設傳送距離為 d ，傳輸的速率為 s ，那麼 propagation delay 就是 d/s。
- transmission delay：網路卡將資料傳送到網路線上（或從網路線上接收）所花的時間，與網路設備的傳送速度有關（如高速乙太網路傳送速度為 100Mbps）。假設頻寬為 L（bits），數據傳輸速率為 R（bits/sec），這樣產生的 transmission delay 就是 L/R。
- nodal processing delay：路由器處理封包表頭（packet header）、檢查位元資料錯誤與尋找配送路徑等所花費的時間。
- queuing delay：路由器因為某些因素無法立刻將封包傳送到網路上，造成封包暫存在佇列（queue）中等待的時間。
在另一方面，transmission delay 則是由網路設備的資料傳送速度來決定的，這個部份則跟伺服器與使用者之間的距離無關。假設現在有兩條網路，其中一條網路的速度是 1 Mbps，另外一條則是 100 Mbps，如果使用這兩條網路各傳送一個 10 Mb 大小的資料，則將資料放進第一條 1 Mbps 的網路中傳送會需要 10 秒鐘，而放進另一條 100 Mbps 的網路則只需要 0.1 秒。
接著當一個網路封包傳送到路由器（router）時，路由器就會檢查封包的表頭來決定接下來該把這個封包往哪裡遞送，除了表頭之外，也可能會一併檢查封包內部的資料，而這些動作都會需要時間，雖然這些動作大部分都是由硬體在處理，耗費的時間非常少，但是這個時間還是存在的。另外，如果封包傳送給路由器的速度太快，路由器一時來不及處理的話，這些來不及處理的封包就會被放進緩衝區的佇列中等候，而這個等候所耗費的時間就是 queuing delay。
每一個封包再網路上傳送時，都一定會碰到這四種延遲，來源端與目的端的距離越遠，所造成的 propagate delay 就會越長；傳輸過程中如果經過多的路由器，那麼 nodal processing delay 與 transmission delay 也會越長；網路的覆載量比較高的時候，也會有比較高的機率造成路由器來不及處理而把封包放入佇列中，進而增加 queuing delay 的時間。
網路的 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 公尺，這已經是一個很快的速度了，另外這個速度也距離理論上的最快速度不遠。
表一：真空與光纖中訊號傳遞的時間
| 傳輸路徑 | 傳輸距離 | 真空中傳輸時間 | 光纖中傳輸時間 | 光纖中訊號往返時間（Round-trip time，RTT） |
| 紐約到舊金山 | 4,148 km | 14 ms | 21 ms | 42 ms |
| 紐約到倫敦 | 5,585 km | 19 ms | 28 ms | 56 ms |
| 紐約到雪梨 | 15,993 km | 53 ms | 80 ms | 160 ms |
| 地球一圈 | 40,075 km | 133.7 ms | 200 ms | 400 ms |
雖然光速非常快，但是在美國紐約與澳洲雪梨之間往返還是要花 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 的運作流程，我們在後面的文章將會有詳細的解說。
骨幹網路頻寬（Bandwidth）
在一般的網路骨幹上的網路流量都非常大，因此目前大部分網路骨幹都是使用光纖的方式在傳輸資料。光纖比頭髮還要再細一點，其運作的原理有點像光的「導管」，可以將光線由發送端導引至接收端，而一般傳統金屬的電纜線比起光纖來說，會有比較多的訊號遺失、雜訊干擾等問題，另外在長期的維護費用上也會比較高，所以一般來說網路封包在傳遞時，會在這兩種傳輸介質上傳遞，但是在長距離的傳輸時，通常都會使用光纖。
光纖在網路的頻寬上也有明顯的優點，它可以藉著 wavelength-division multiplexing（WDM）技術讓一條光纖網路同時傳輸多個不同波長（頻道）的光線，所以一條光纖網路的頻寬會是單一頻道的資料傳輸速率再乘上其頻道的數目。
在 2010 年初的時候，研究人員已經可以讓一條光纖同時傳輸 400 個不同的頻道，每個頻道的資料傳輸速率是 171 Gbit/s，也就是說一條光纖的傳輸速率可以超過 70Tbit/s！若是使用傳統金屬材質，則需要數千條的電纜線才能達到這樣的速度，也因為如此，所以現在長距離的網路資料傳輸都會使用光纖電纜的方式來佈線，每條光纖電纜中包含數條光纖（通常是 4 條），所以可以提供數百 Tbit/s 的傳輸速度。
末端網路頻寬（Bandwidth）
網路末端的頻寬相對於網路骨幹而言非常小，而且會因為所使用的技術不同而有不一樣的網路頻寬，包含撥接網路、DSL、cable、各種無線網路技術、光纖到府與地方的路由器效能等都會有影響，而對於使用者而言，其可使用的網路頻寬會由頻寬最窄的部份來決定（請參考上面的「網路的延遲與頻寬示意圖」）。Akamai 這家公司經營一個全球性的 CDN 服務，在全球各地佈置了許多伺服器，並且每季提供依照他們自己伺服器上的觀測資料，免費提供世界各國寬頻網路的速度報告，下表是 2013 年第二季的報告中，亞太地區的數據。
全球平均的網路頻寬是 3.3 Mbps，而台灣則是 5.5 Mbps，雖然比平均高，但是跟臨近的國家相比算是有點低，新加坡（Singapore）有 6.5 Mbps、香港（Hong Kong）有 10.8，日本（Japan）與南韓（South Korea）更達到 12 與 13.3 Mbps。
如果以全球的排名來看，南韓目前的上網頻寬是最大的，接下來是日本、瑞士（Switzerland）、香港與拉脫維亞（Latvia）。
這裡我們所討論到的數據都沒有包含手持裝置的部分，通常手持裝置的網路速度都會比一般電腦慢，而且品質相對也比較不穩定。
附帶一提，一般在網路上收看高畫質（HD）的影片時，通常依照不同的 codec 與解析度，大概會需要 2 到 10 Mbps 的網路頻寬，所以依照這裡的數據來看，一般的使用者應該都可以正常收看低解析度的影片，但是這樣也會占去他大部份的頻寬，而如果一個家中有好幾台電腦同時要看這樣的影片，就會有些問題了。
對於一般的使用者來說，找出網路頻寬的瓶頸所在是一個很重要、但也很難處理的問題，而這個時候就可以使用一些網路速度偵測工具來幫助你測量目前的網路頻寬，例如 Hinet 的連線速路測試或 speedtest.net：
使用這些工具你就可以測量出自己網路的實際網路頻寬，看看有沒有符合 ISP 當初所宣稱的速度。
然而有了令人滿意的網路頻寬之後，也不能保證網路品質的穩定度，有時候因為網路塞車、設備損壞、或是遭受網路攻擊等事件，都會影響網路的頻寬與延遲，而這個現象是現在的網路技術難以避免的問題，而如何預測、管理或因應這些情況的變化本收也很複雜。
高網路頻寬與低網路延遲
隨著高畫質網路影片的普及，網路頻寬的需求也不斷增加，目前所有網路上傳輸的資料中，有超過一半都是屬於影片的資料，在這樣的情況下，可以使用幾個方案來處理，首先可以增加光纖電纜中的光纖數量，或是改善 WDM 技術，讓資料的傳輸量可以增加。在網路延遲的改善上，又是另外一個問題，目前是以材料科學的方式，嘗試改善光纖的折射率，而依據目前的狀況來估計，未來大概頂多只能再改善 30% 左右，最終都會碰到光速這個物理極限。另外改善路由器自己的效能也是一個辦法。
而目前在地球上兩地的網路傳輸路徑通常都不是直線，如果可以多拉一些電纜線，讓訊號的傳遞距離縮短，也可以減低網路延遲，但是這個方式也很困難，因為一些各種地理上、政治上的因素，通常也不太可能在任意的路徑上佈線。
因此若要改善應用程式的效能，我們必須精心設計自己的程式架構與所使用的通訊協定，對於網路的使用上做一些最佳化的動作，減少長距離的網路傳輸動作，讓資料儘量靠近使用者，另外透過快取（caching）的方式讓網路延遲可以隱藏在程式的背後，這些技巧我們在之後的文章還會再詳細說明。
參考資料：High Performance Browser Networking