Computer Networking — 1.4 Delay, Loss, and Throughput in Packet-Switched Networks

contributed by <kaeteyaruyo>

tags: `Computer Networking`

在 1.1 時我們有提到，網際網路可以被視為一個提供使用者存取分散在各個終端設備上的應用服務的基礎建設。理想的情況下，我們會希望網際網路可以在一瞬間之內把所有我們希望傳送的資料都傳到目的地的終端機器上，而且沒有損失任何資料。但這種要求根本就是天方夜譚，在現實中是不可能做到的。實際上，電腦網路的吞吐量 (throughput，也就是每秒可以傳輸的資料量上限) 一定是會受限的，傳遞封包時一定會有延遲，也一定會有掉包的問題。一方面，現實中的物理法則造成了這些延遲、掉包，還有吞吐量的限制；另一方面，也因為有這些問題，才會有這麼多有趣的議題需要我們去解決－－這些議題多到我們這一門 computer networking 的課根本講不完，多到可以成就出上千位的 PhD！（這結論？？？）在這個小節中，我們就要開始探討和量化電腦網路中的延遲、掉包以及吞吐量的議題。

1.4.1 Overview of Delay in Packet-Switched Networks

在網路上，一個封包會從某台主機 (source) 出來，經過一連串的路由器，最後抵達另一台主機 (destination)。當一個封包從某一個節點（可能是主機或是路由器）一路經過接下來的節點時，他可能會在每個節點因各種延遲而耽誤。在這些延遲當中，最重要的是節點處理延遲 (nodal processing delay)、佇列延遲 (queuing delay)、傳輸延遲 (transmission delay)，以及傳播延遲 (propagation delay)。把這些延遲通通加總起來，就可以得到節點總延遲 (total nodal delay)。網路上的應用程式（像是搜尋引擎、網頁瀏覽、 e-mail 、地圖、即時訊息、語音電話等）的效能，會大大地受到這些延遲的影響。為了更深入地了解封包交換和電腦網路，我們必須要搞懂這些延遲的特性和重要性。

Types of Delay

上圖中展示了我們剛剛有提到的幾種延遲的類型。這張圖展示了一個封包要從某台電腦被送到另一台電腦途中的其中一小段路程，封包被從某台電腦送到 A 路由器上，準備要被送去路由器 B。我們的目標是要分析在路由器 A 上的節點延遲是由哪些因素造成的。我們可以看到，路由器 A 有一條往外連的線路通向路由器 B，在出口處有一個緩衝佇列擋著。當封包從上游的節點抵達了A 之後，路由器 A 會把封包的標頭拆開來看，好決定這個封包應該要透過哪一條線路往外送。在這個例子中，這條線路就是往 B 的那一條。一個封包只有在該線路沒有在傳輸其它封包，且緩衝佇列中也沒有任何一個封包時，才可以被往外送；反之，這個封包就必須被排進佇列中。

Processing Delay

處理延遲指的是「把封包的標頭拆開來看，好決定這個封包應該要透過哪一條線路往外送」的所需時間
也包含了一些其它因素，像是做錯誤檢測（檢查封包是否有因傳輸時的某些原因造成位元等級的錯誤）所需的時間
在高速的路由器中，處理延遲的大小大概都在微秒等級，甚至更少
在節點處理結束之後，路由器就會把封包導向要送出的那條線路的緩衝佇列中（關於路由器的操作，我們待第四章再細談）

Queuing Delay

如果一個封包被塞在佇列中，那他就會受到排隊延遲的影響
到底會等多久，這取決於佇列中還有幾個封包等在前面
- 如果佇列是空的，而且現在也這條線也沒有在傳輸任何封包，那麼排隊延遲就會是 0
- 如果當前流量非常大，有很多其它封包已經等在前面的話，那排隊延遲就會非常久
- 我們待會就會看到，已經等在隊伍中的封包數量會是當前這個佇列所收到的流量其密度和特徵的函數
在實作上，排隊延遲的大小在幾微秒到幾毫秒不等

Transmission Delay

在封包交換網路上，封包是基於 FIFO 原則進行傳輸的，這些封包只有在完整抵達路由器 A 之後才可以被送出去
當封包的長度是 L 位元，而從路由器 A 到路由器 B 的線路速度是 R bps 的時候，傳輸延遲就是 L/R 秒，這也就是完整的把封包從 A 送到 B 所需的時間
在實作上，傳輸延遲的大小在幾微秒到幾毫秒不等

Propagation Delay

每個位元被放到線路上之後，都需要被傳播到路由器 B 去，其所需的時間就叫作傳播延遲
傳播時間受到該物理介質（如：光纖、銅導線、無線電波…等等）的傳播速度影響，其大小介於
$2 \times 10^{8}$ 公尺每秒到
$3 \times 10^{8}$ 公尺每秒之間不等，也就是略小於或等於光速
傳播延遲可以記為 d / s，當中的 d 就是兩台路由器之間的距離，而 s 則是該線路的傳播速度
一旦整個封包的最後一個位元被傳播到了 B 節點上，他和他前面的所有位元就都已經被儲存在路由器 B 上了。接下來，路由器B就會再做一次上面我們提到的這些事
在廣域網路中，傳播延遲的大小大概在毫秒等級左右

Comparing Transmission and Propagation Delay

剛踏進電腦網路這個領域的人有時候會分不清楚傳輸延遲和傳播延遲（尤其中文又長得這麼像…），他們之間的差異很細微，但是很重要。

-	傳輸延遲	傳播延遲
定義	將一個封包完全放到線路上的時間	將一個位元從一台路由器傳到另一台路由器的時間
公式	$\frac{封包大小}{線路傳輸速度}$	$\frac{線路長度}{線路傳播速度}$
備註	與路由器間的距離無關	與封包大小或傳輸速度無關

我們可以用一個「高速公路上的車隊」的比方來解釋這兩種延遲的觀念。

考慮以下情境：
- 有一條高速公路，每隔 100 km 就有一個收費站
- 在高速公路上的每台車都以 100 km/hr 的速度行駛（在他離開收費站的一瞬間，就馬上從 0 加速到 100 的那種）
- 現在有一群 10 台車組成的車隊，一台接一台的行駛在高速公路上
- 收費站服務一台車需要花 12 秒的時間
- 現在是大半夜，所以高速公路上除了這群車隊以外沒有別的車了
- 每當車隊的第一台車進了收費站，他一定要等到其它九台車都被服務完了，才會整團車隊一起離開
在這個情境中，我們可以做出以下類比：
- 收費站：路由器
- 收費站之間的路：線路
- 車子：位元
- 車隊：封包
- 車子的時速：傳播速度
- 收費站服務的時間：傳輸速度
- 整團車隊一起離開：封包交換
關於延遲的計算
- 一個收費站要把十台車都服務完的所需時間是 (10 cars) / (5 cars/min) = 2 min，這個時長可以類比為傳輸延遲
- 一台車要從一個收費站的出口跑到另外一個收費站的入口所需的時間是 (100 km) / (100 km/hr) = 1 hr，這個時長可以類比為傳播延遲
- 因此，從車隊的一台車離開某收費站開始起算，到車隊的第一台車離開下一個收費站的瞬間為止，總時長（總延遲）就會是 62 min
試想另一種情況：如果收費站服務一台車的時間比一台車從一個收費站開到下一個收費站的時間還久呢？例如：現在車子都以 1000 km/hr 的速度在收費站之間行駛，而收費站現在服務一台車需要一分鐘時間。
- 在收費站中間行駛的時間會變成 (100 km) / (1000 km/hr) = 1 / 10 hr = 6 min
- 收費站把十台車都服務完的所需時間變成 (10 cars) / (1 car/min) = 10 min
- 在這個狀況下，會出現前面幾台車都已經抵達下一個收費站了，後面的車卻還被卡在當前的收費站裡還沒出發的現象。這比較接近真實個封包交換網路的情況：封包當中的前面幾個位元已經抵達了下一個路由器，但後面的位元還在當前的路由器中等待出發
關於傳播延遲、排隊延遲，還有傳輸延遲， [Smith 2009] 提供了相當清楚的討論

如果我們分別以

d_{p r o c}

d_{q u e u e}

d_{t r a n s}

, 和

d_{p r o p}

來表示節點處理延遲、排隊延遲、傳輸延遲和傳播延遲，則節點總延遲就可以表示為：

d_{n o d a l} = d_{p r o c} + d_{q u e u e} + d_{t r a n s} + d_{p r o p}

其中各個分項的影響會隨著不同情境有非常巨大的差異，例如：

$d_{p r o p}$ 在兩台位於同一間大學、直接用電線接通的路由器之間，可能就只有幾微秒，完全可以忽略；但在兩台相隔十萬八千里、透過通訊衛星接通的路由器之間，可能就會高達上百毫秒，變成主宰
$d_{n o d a l}$ 的變項
$d_{t r a n s}$ 在線路速度高達 10 Mbps 或以上（例如： LAN）的時候，通常就小到可以忽略；但如果是透過超慢的撥接傳送一個超大封包的話，那可能就會需要耗上幾百毫秒
$d_{p r o c}$ 通常是可以忽略的，但這個變項會大幅影響到一台路由器的最大吞吐量

1.4.2 Queuing Delay and Packet Loss

在節點總延遲中最複雜且最有趣的變項就是排隊延遲了，有一大堆論文和書籍都在探討這個東西[Bertsekas 1991; Daigle 1991; Kleinrock 1975, Kleinrock 1976; Ross 1995]。在這裡我們只做概念性的、直覺的討論，好奇的讀者們可以再自己去翻翻上面的文章（或是考上 PhD 自己寫一本）。和其他三種延遲不同，每個封包感受到的排隊延遲會大不相同。例如：如果有十個封包同時抵達了同一個緩衝佇列，第一個封包因為會馬上被丟出去，所以不會有任何排隊延遲，但是最後一個封包，他必須等前面九個封包都送出去了才可以送出，所以他的排隊延遲會非常大。因此，當我們在描述排隊延遲的時候，通常會使用他的統計特徵，像是平均排隊延遲、排隊延遲的變異數，或是排隊延遲超過某個數字的機率值等等。

排隊延遲什麼時候會很可觀、又是什麼時候小到可以忽略呢？這取決於封包流量抵達緩衝佇列的速度、線路的傳輸速度，以及這個流量的型態（封包每隔一段固定時間就來固定的量還是一次來一大堆）。為了說明的更精確，我們定義：

平均的封包抵達速度是 a （每秒來 a 個封包）
線路的傳輸速度是 R （每秒丟 R 個位元出去）
為了簡化問題，假設每個封包都是 L 位元那麼大，如此一來，平均的抵達速度就會是 La （每秒來 La 個位元）
佇列的長度非常大，可以容納無限個位元

有了這些參數，我們可以定義流量強度 (Traffic Intensity) 為平均抵達速度和傳輸速度的比值，也就是 La / R （沒有單位）。流量強度是估算排隊延遲大小的一個重要依據。

如果 La/R > 1，也就是平均抵達速度超過了線路的傳輸速度，在這個情況下，封包的隊伍會永無止盡的增長，到最後排隊延遲就會趨近無限大！因此，交通工程的黃金定律就是：把你的系統設計到流量強度永遠不會大於 1。
如果 La/R ≤ 1，那麼流量的型態就會是影響排隊延遲的主要因素。
- 如果封包是週期性的抵達的，例如：每 L/R 秒都來一個封包 (a = 1)，那每個封包來的時候緩衝佇列都是空的，就不會有任何排隊延遲
- 如果封包是週期性的大量抵達，這時就會造成很大的平均排隊延遲。例如：每 N(L/R) 秒都來 N 個封包，則第一個封包沒有排隊延遲，但第二個封包會有 L/R 秒的排隊延遲…，以此類推，第 N 個封包就會有 (N - 1)L/R 秒的排隊延遲。平均排隊延遲就是
  $(\frac{N^{2} - N}{2}) \frac{L}{R}$ 秒。

但上面這兩個例子都太理想化了，只有在實驗室才會發生。在現實生活中，通常封包都是隨機抵達的，也就是說，相鄰的兩個封包中間的時間間隔是隨機長度，沒有任何規律的。在這個更接近現實狀況的例子中，只看 La/R 這個數值通常不足以完全描述排隊延遲的統計特徵。儘管如此，我們還是可以透過他的大小很直觀的理解現在的排隊延遲大概有多嚴重。

如果流量強度很接近 0，這表示來的封包很少，而且封包之間的時間差很大。每個封包來的時候，幾乎都沒有其他人在排隊。因此，平均排隊延遲就會很接近 0
如果流量強度很接近 1，這表示會有幾段時間之內，平均抵達速度是超過線路傳輸速度的（因為封包到來的速度一直變化），在這段時間之內，封包會排隊；等到平均抵達速度低於線路傳輸速度之後，隊伍才會逐漸縮短。

隨著流量強度往 1 逼近，平均隊伍長度就會變得越來越長。我們可以量化平均排隊延遲和流量強度的關係，並作圖如下所示：

這張圖上有一個很重要的資訊，那就是當流量強度趨近於 1 的時候，平均排隊延遲會增長的非常快。一點點的流量增長，都會導致延遲嚴重地增加。你或許有在高速公路上體會過這種狀況：平日就已經很容易塞車的路段（流量強度已經很接近 1），如果遇到連假，車流比平常又更多了一點，那平均車速就會慢的不可思議。

Packet Loss

到剛才為止我們都是在「假設佇列的長度非常大，可以容納無限個位元」的狀況下探討排隊延遲的。但實際上，緩衝佇列不可能無限長，他的容量是有限的，大小會跟路由器的設計方式和價格有關。由於佇列的容量有限，排隊延遲不可能真的長到變成無限大。反之，當流量強度大到某個程度，隊伍會把整個緩衝佇列都塞滿，新來的封包沒辦法被排進隊伍中，路由器就會把這個封包丟掉，造成丟包 (Packet Loss)。

從終端設備的角度來看，「丟包」就是一個「封包被丟到核心網路中了，但是從來就沒有到達他的目的地過」的狀況。隨著流量強度增加，封包遺失的比例就會越高。因此，我們在評估一個節點的效能的時候，不會單純只看他的延遲，也會看他丟包的機率。在接下來的章節我們會談到，在端到端的基礎上 (on an end-to-end basis)（這句看不懂），這些遺失的封包會被重送，以確保所有資料最後都可以從源頭送到目的地。

1.4.3 End-to-End Delay

在 1.4.2 我們討論的重點都放在單一節點的延遲上，接著讓我們來計算一個封包從起點送到終點會有多少的延遲。為了幫助我們清楚掌握這個概念，我們先做以下假設：

在起點 (source) 和終點 (destination) 的主機之間，總共有 N - 1 台路由器
在這段傳送期間，網路不壅塞（所以排隊延遲可以忽略）
路徑上的每台路由器還有起點的節點處理延遲都是
$d_{p r o c}$
從路徑上的每台路由器還有起點出去的線路傳輸速率都是 R bits/sec
每條線路的傳播延遲都是
$d_{p r o p}$

把每個節點的處理延遲都加總就會得到端到端延遲 (end-to-end delay) 為

d_{e n d - e n d} = N (d_{p r o c} + d_{t r a n s} + d_{p r o p})

其中

d_{t r a n s} = \frac{L}{R}

， L 是封包的長度。這條式子是我們在 1.3.1 當中提到的式子一般化的版本，加入了原本的式子中沒有考慮到的節點處理延遲和傳播延遲。

TODO: Generalize Equation above to the case of heterogeneous delays at the nodes and to the presence of an average queuing delay at each node.

Traceroute

為了親身體驗什麼叫「端到端延遲」，我們可以使用 Traceroute 這套程式來進行檢測。Traceroute 在任何電腦上都可以執行，使用者指定一個目標的 hostname， traceroute 就會對目標主機發出數個特別的封包。這些封包在通往終點的路上會經過一系列的路由器，每一台路由器收到這些封包的其中一個後，就會往起點回傳一個短短的訊息，包含這台路由器的名字和位址。

更精確的說，假設在起點跟終點間總共有 N - 1 台路由器，那麼起點就會送出 N 個這種特別的封包到網路上，每一個封包的收件地址都是終點的主機。這 N 個封包會被編號，第一個編號是 1，最後一個編號是 N，中間以此類推。當第 n 台路由器收到第 n 個封包的時候，他不會把這個封包繼續往下送，而是會回傳一段訊息給起點主機。當終點主機收到第 N 個封包時，它同樣也會回傳這種訊息給起點。起點主機會記錄這些封包寄出到收到回傳的訊息中間所經過的時間，還有回傳訊息的路由器（或目標主機）的地址跟名字。有了這些資訊，起點主機就可以重建封包送往終點時所經過的路徑，也可以決定來回中間任意一台路由器所需的時間。 Traceroute 實際上會執行上述流程三次，所以其實會送出

3 \times N

個封包給終點。RFC 1393 詳細說明了這支程式是怎麼被實作的。

以下是一個 Traceroute 的輸出範例。這次實驗的起點是從 gaia.cs.umass.edu （在 University of Massachusetts 裡的一台電腦）出發的，送往 cis.poly.edu （在 Polytechnic University in Brooklyn 裡的一台電腦）。每一列的輸出總共有六個欄位，分別是封包的編號 n 、路由器的名字、路由器的位址（可以是 IPv4 或是 IPv6，看啟動程式時怎麼下參數），還有三次實驗所測得的時間差。如果起點收到來自某台路由器的回傳訊息少於三個（可能是因為丟包），那他就會放一個星號 * 在該伺服器的那一列，提示使用者這台伺服器測得的來回時間差數量少於三次。

1 cs-gw (128.119.240.254) 1.009 ms 0.899 ms 0.993 ms
2 128.119.3.154 (128.119.3.154) 0.931 ms 0.441 ms 0.651 ms
3 -border4-rt-gi-1-3.gw.umass.edu (128.119.2.194) 1.032 ms 0.484 ms 0.451 ms
4 -acr1-ge-2-1-0.Boston.cw.net (208.172.51.129) 10.006 ms 8.150 ms 8.460 ms
5 -agr4-loopback.NewYork.cw.net (206.24.194.104) 12.272 ms 14.344 ms 13.267 ms
6 -acr2-loopback.NewYork.cw.net (206.24.194.62) 13.225 ms 12.292 ms 12.148 ms
7 -pos10-2.core2.NewYork1.Level3.net (209.244.160.133) 12.218 ms 11.823 ms 11.793 ms
8 -gige9-1-52.hsipaccess1.NewYork1.Level3.net (64.159.17.39) 13.081 ms 11.556 ms 13.297 ms
9 -p0-0.polyu.bbnplanet.net (4.25.109.122) 12.716 ms 13.052 ms 12.786 ms
10 cis.poly.edu (128.238.32.126) 14.080 ms 13.035 ms 12.802 ms

在這條路徑上，總共有九台路由器在起點跟終點之間。大部分的路由器都有自己的名字，並且所有的路由器都有自己的位址。例如：第三台路由器的名字叫做 border4-rt-gi-1-3.gw.umass.edu ，它的位址是 128.119.2.194 。在這個路由器上，我們測到第一次的來回時間差是 1.03 msec，而第二次、第三次分別是 0.48 和 0.45 msec 。這個來回時間差包含了我們上面提到的所有延遲，也就是傳輸延遲、傳播延遲、節點處理延遲和排隊延遲。其中排隊延遲是不固定的，所以有時候會發現編號比較小的封包的來回時間差居然比編號比較大的封包來回時間差還要大。在上方的例子中我們就有看到這樣的現象，第六台路由器的延遲比第七台還要大！

你也想試試看 Traceroute 嗎？我們非常推薦你到 http://www.traceroute.org 上試試看。只要從網頁提供的清單上選擇起點和終點， Traceroute 程式就會印出結果。除了這個網站之外，也還有許多免費的圖形化介面版本 Traceroute。本書作者最推薦的其中一個就是 PingPlotter [PingPlotter 2016]。

End System, Application, and Other Delays

除了節點處理延遲、傳輸延遲，還有排隊延遲以外，終端系統內還有其他可能會造成重大傳輸延遲的因素。例如：有些終端系統要送封包到共享介質 (shared medium) （像是 Wi-Fi 或是 Cable modem 之類的）上時，會故意在傳送的過程中加上延遲，因為這套傳輸協定是為了跟其他終端系統共享傳輸介質而設計的。我們會在第六章詳細討論這類傳輸協定。另一個重要的延遲類型是 media packetization delay ，這在即時語音通話系統當中非常常見。在語音通話系統中，發話端必須先在封包內填滿已編碼的數位語音訊號，才可以把它送到網際網路上。這個要把封包填滿的所需時間，就叫做 packetization delay ，會大幅影響使用者感受到的通訊品質。這個議題在本章最後的 homework 中會詳細討論。

1.4.4 Throughput in Computer Networks

除了延遲和掉包之外，另一個評估網路效能的重要指標就是端到端吞吐量 (end-to-end throughput)。吞吐量有分兩種，想像主機 A 正在傳送一個大檔案（影片之類的）給主機 B，則

瞬時吞吐量 (Instantaneous throughput) 指的是某個瞬間主機 B 收到的資料量，單位是 bits/sec ，可以想像成瞬時速率的感覺。許多 P2P 的下載軟體都會在介面上顯示這個數字（下載速度那欄）
平均吞吐量 (Average throughput) 指的是檔案大小和總傳輸時間的比值，可以想像成平均速率的感覺。如果這個檔案大小為 F bits ，而主機 B 花了 T 秒才收到整個檔案，則平均吞吐量就是 F/T bits/sec

在某些應用程式中，低延遲和穩定的瞬時吞吐量比較重要，如網路電話可能就會希望瞬時吞吐量維持在 24 kbps 左右（如果是視訊電話，則可能需要到 256 kbps 以上）；但是在另一些應用程式中，較大的平均吞吐量反而比較重要，偶爾有延遲則可以容忍，如檔案傳輸軟體。
為了讓我們更了解吞吐量這個重要的概念，讓我們來看看以下幾個例子。

上圖 (a) 展示了一個簡單的網路，有一台伺服器、一台客戶端，他們中間有一台路由器，用兩條線路分別連接兩者。今天伺服器上面有一支程式想要傳送檔案給客戶端
- 我們先假設
  - 伺服器和路由器之間那條線路的傳輸速率為
    $R_{s}$ bps
  - 路由器和客戶端之間那條線路的傳輸速率為
    $R_{c}$ bps
  - 在這整個網路上，就只有伺服器正在傳資料給客戶端而已，沒有其他流量了
- 在理想的情況下，伺服器往客戶端的吞吐量是多少呢？
  - 我們可以把資料流想像成水流，線路想像成水管
  - 伺服器沒辦法以高於
    $R_{s}$ bps 的速度將資料送出，因為他的水管就這麼粗；同樣道理，客戶端接收資料的速度也沒辦法高於
    $R_{c}$ bps
  - 如果
    $R_{s} < R_{c}$ ，則伺服器以最大速率流出的資料流可以順利的通過接到客戶端的水管，則客戶端感受到的吞吐量就是
    $R_{s}$
  - 如果
    $R_{s} > R_{c}$ ，則路由器就算以最大速度傳輸也無法即時把所有伺服器丟來的資料流都送出去，客戶端感受到的吞吐量是
    $R_{c}$ （這時封包會在路由器越堆越多，是我們最不希望發生的情況 :(）
  - 因此，在這個簡單的兩條線路構成的網路中，吞吐量就是
    $m i n {R_{c}, R_{s}}$ ，也就是瓶頸線路 (bottleneck link) 的傳輸速率
- 現在我們知道吞吐量了，就可以由計算得知，要傳送一個大小為 F bits 的大檔案，所需的時間會是
  $\frac{F}{m i n {R_{s}, R_{c}}}$ 秒
  - 例如：現在你想要下載一個 F = 32 MB 的 MP3 檔案，而
    $R_{s}$ = 2 Mbps ，
    $R_{c}$ = 1 Mbps，那這個檔案就要花 32 秒才能下載下來
- 這個吞吐量和傳輸時間的算式算出的只是近似的結果，因為他並沒有包含 store-and-forward 和節點處理封包的延遲，也沒有考慮個別傳輸協定的限制
上圖 (b) 展示了另一個網路，伺服器和客戶端中間有 N 條線路，他們的傳輸速度依序是
$R_{1}, R_{2}, . . ., R_{N}$ 。套用和上面兩條線路時一樣的概念，我們可以得知在這個網路上的伺服器它的吞吐量會是
$m i n {R_{1}, R_{2}, . . ., R_{N}}$ ，同樣是整條路上的瓶頸線路的傳輸速度

接著這個例子是從現代網際網路的架構簡化來的。上圖 (a) 展示了兩台終端機器，分別是伺服器和客戶端，分別連接到網路上。伺服器上同樣有支程式想要傳送檔案給客戶端
- 我們先假設
  - 伺服器接到網路的那條線路的傳輸速率為
    $R_{s}$ bps
  - 客戶端接到網路的那條線路的傳輸速率為
    $R_{c}$ bps
  - 在這整個網路上，就只有伺服器正在傳資料給客戶端而已，沒有其他流量了
  - 在核心網路上的所有線路都非常高速，高過
    $R_{s}$ 和
    $R_{c}$ bsp 。事實上，現代的網際網路核心都被超額配置 (over-provisioned) 了高速的線路，幾乎不會壅塞
- 由於核心網路上的線路就像是超粗的水管，流量通常可以很順利的通過核心網路，所以吞吐量依然會是
  $\frac{F}{m i n {R_{s}, R_{c}}}$
- 從這個例子我們可以看得出來，現代網際網路的瓶頸線路往往都在接取網路上
最後一個例子，如上圖 (b) 所示，有十對伺服器和客戶端同時在傳輸檔案，這十條路徑共用了核心網路中的其中一條線路
- 我們先假設
  - 每一條伺服器接到網路的線路傳輸速率都是
    $R_{s}$ bps
  - 每一條客戶端接到網路的線路傳輸速率都是
    $R_{c}$ bps
  - 在核心網路中除了被共用的那一條線路傳輸速率是
    $R$ bps 之外，其他的線路都比
    $R_{s}$ ,
    $R_{c}$ 和
    $R$ 快多了
  - 在這整個網路上，就只有這十對電腦正在傳輸資料，沒有其他流量了
- 在這種情況下，個別客戶端感受到的吞吐量是多少呢？
  - 如果
    $R$ 非常大，例如：是
    $R_{s}$ 和
    $R_{c}$ 的數百倍的話，那麼吞吐量就依然是
    $\frac{F}{m i n {R_{s}, R_{c}}}$
  - 但如果
    $R$ 和
    $R_{s}$ 跟
    $R_{c}$ 在同一個數量級的話，瓶頸就可能會變成這條共用的線路。例如：
    $R_{s}$ = 2 Mbps,
    $R_{c}$ = 1 Mbps,
    $R$ = 5 Mbps，則
    $R$ 的頻寬被平分給這十條資料流，每一條就只會分到 500 kbps 而已，因此吞吐量會變成只剩 500 kbps

在以上的例子中，我們可以發現吞吐量是由資料流經過的一系列線路的傳輸速率，以及當時的網路壅塞程度決定的。

如果這一路上都沒有其它同時在傳輸的資料流，那麼吞吐量就會是路徑上最慢的那條線路的傳輸速率
如果有很多條資料流在共用同一條線路（像最後一個例子那樣），即使他有很高的傳輸速率，也有可能因為頻寬被平分而變成傳輸瓶頸

在本章最後的作業和接下來的章節中，我們會更進一步試著去計算網路的吞吐量。

<< 1.3 The Network Core | 目錄 | 1.5 Protocol Layers and Their Service Models >>

Toby T༼ つ

2023/09/23 00:37:23

高速公路上的車隊

Caravan analogy

2023/09/23 00:38:49

練習：https://gaia.cs.umass.edu/kurose_ross/interactive/caravan.php

2023/09/23 01:03:39

平均的封包抵達速度是 a

average packet arrival rate (per second)，翻平均封包抵達率應該會比較好？

2023/09/27 07:06:14

偷偷說，我們學校都用這本，所以超多人看你寫的www

kinoe_T

2023/10/04 17:04:34

真的嗎!? 受寵若驚XDD 謝謝各位~

Guest Dennis2024/02/28 03:59:02

超級感謝作者大大的翻譯今年剛修根本看不懂還好有這些文章幫助（我們學校也是同一本課本哈哈）

Guest Schneider2024/10/18 20:37:23

123