三個被當成同義詞亂用的詞
當有人說自己的網路「很快」，他們通常指的是三件不同的事，而且自己沒意識到。頻寬是這條鏈路每秒能搬多少資料；延遲是一個位元從這頭到那頭要花多久；吞吐量則是你實際上每秒真正搬動了多少資料。它們感覺很像，但其實是三種完全不同的量測，把它們搞混是學網路時最常見的錯誤。
有個鮮明的方式可以把它們分開：想像一條高速公路。頻寬就是它有幾條車道，也就是容量；延遲是這趟車程本身要開多久，主要由距離和速限決定；吞吐量則是另一端每小時實際抵達幾台車，這取決於車道數、車流量，以及路上任何收費站。把路拓寬（更多頻寬）一點也不能縮短一段五百公里的車程（延遲）。
延遲究竟從哪裡來
在第二篇我們看到，路由器採用儲存轉發：它必須收完一整個封包，才能把它送出去。光是這個事實，就埋下了所有延遲的種子。一個封包跨越一段鏈路所花的總時間，是四個部分的總和，而每一部分的成因都完全不同。把它們分開命名，才讓工程師有辦法診斷一個慢吞吞的網路，而不是只能聳聳肩。
- 處理延遲——路由器讀取標頭、檢查錯誤，並決定要把封包往哪裡送。極短，通常是微秒等級。
- 排隊延遲——如果其他封包已經在等同一條外送鏈路，這個封包就得排隊。這是變化最劇烈的一項：鏈路閒置時是零，壅塞時則大得驚人。
- 傳輸延遲——把封包的每個位元都推上線路所需的時間，等於封包大小除以鏈路頻寬。一個 12,000 位元的封包在 100 Mbps 鏈路上要花 12,000 / 100,000,000 = 0.12 毫秒。
- 傳播延遲——一個位元以接近光速在線路上實際跑完全程所需的時間，等於距離除以訊號速度。它不在乎封包有多大，只在乎要跑多遠。
初學者最容易混淆的就是傳輸延遲與傳播延遲。傳輸延遲取決於封包多大、管子多粗；傳播延遲只取決於距離。一則跨大西洋光纖的短訊息幾乎全是傳播延遲；同一個房間裡用慢速數據機傳一個巨大檔案幾乎全是傳輸延遲。它們互相獨立，只有它們的總和才是你感受到的延遲。
為什麼更多頻寬贏不過光速
這裡有一個值得刻進腦海的迷思：買更多頻寬並不會降低延遲。頻寬只縮短延遲中的「傳輸」那一塊，它讓你能更快地把位元倒上線路。但傳播延遲是由距離和物理決定的，再多錢也無法把它變短。光在玻璃光纖中大約每秒跑 200,000 公里，所以從紐約到倫敦（約 5,600 公里）的訊號，不管你的方案承諾每秒幾 Gb，單程都需要大約 28 毫秒。
這就是為什麼即使用飛快的光纖，打給地球另一端的視訊通話還是會卡頓，也是為什麼競技玩家在意的是 ping 值而不是頻寬。一個來回——去了又回，常被稱為來回時間或 RTT——的下限由地理決定。你可以無限地加車道，卻沒辦法讓車程比距離所允許的還短。
吞吐量：你實際拿到的
頻寬是鏈路的額定容量；吞吐量則是你端到端真正達到的速率，而且幾乎總是更低。一條路徑是一串鏈路，而一條鏈條的強度取決於最弱的那一環。如果你家的鏈路是 1 Gbps，但它要經過一台只能以 10 Mbps 送出的伺服器，那你的吞吐量就是 min(R1, R2) = 10 Mbps。那條最慢的鏈路就是瓶頸，光靠它就封死了整個傳輸的上限。
client ===== 1 Gbps =====> [router] ----- 10 Mbps -----> server
^^^^^^^^^
bottleneck
throughput = min(1 Gbps, 10 Mbps) = 10 Mbps
(the fat first link cannot rescue the thin second one)就連瓶頸速率也只是個樂觀的天花板。真正的吞吐量會被鏈路繁忙時的排隊、通訊協定的額外負擔（每個標頭都是不屬於你資料的位元組），以及封包遺失時的重傳一點一點吃掉。真正有用、屬於應用程式的每秒位元組數——你的檔案，扣掉所有機械開銷——有它自己的名字，叫做 goodput（有效吞吐量），這才是你該拿去跟下載實際完成時間對照的誠實數字。
把三者拼在一起
頻寬與延遲相乘，會得到一個出乎意料有用的量。bandwidth-delay product（頻寬延遲乘積）等於頻寬乘以來回時間，它告訴你同一時間能有多少位元「在路上」——已經送出但還沒收到確認。把它想成管子的容積：一根又粗（高頻寬）又長（高延遲）的管子，在任何水從另一端流出來之前就已經裝了一大堆水。一個沒有讓至少這麼多位元同時在路上的通訊協定，會讓鏈路閒置，不管它有多大的容量都還是覺得慢。
這正是 頻寬延遲乘積所解釋、也是 TCP 的壅塞控制終其一生試圖填補的缺口：送得夠多以填滿這根又長又粗的管子，但又不能多到讓佇列溢位。一個謹慎的駕駛溫和地加速、用力地煞車——我們會在傳輸層那一階好好認識這個機制。現在的重點是：「快」從來不是一個數字，而是「你能倒多少」「它要跑多遠」「真正撐過這趟旅程的有多少」三者之間的協商。