國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
5
第二章 背景與相關研究
2.1 壅塞崩潰
壅塞崩潰(Congestive Collapse)這個問題最早被發現於 1984 年，第一次觀察到這個 現象是在 1986 年 10 月，當時 NFSnet 的骨幹網路的可用頻寬從 32Kbps 下降到只有 40bps[RFC 896]。其原因在於早期的 TCP 版本在壅塞控制缺乏良好的設計；當網路壅塞 的情況發生時，TCP 於發送端將封包發送出去之後，沒辦法在重送逾時(Retransmission Timeout)的時間內收到接收端所回覆的確認封包(Acknowledgement Packet)，TCP 將視為 一個封包遺失(Packet loss)事件而啟動重送機制；但發送端沒有在重送逾時時間內接收到 來自接收端的確認封包，並非全都是因為封包遺失，而有可能是封包在傳送的過程中遭 遇到網路壅塞的情況，使得封包延遲(Packet Delay)時間拉長，早期的 TCP 版本在這些 情況下會持續重送封包，將使得網路壅塞情況越來越嚴重而造成壅塞崩潰，因此如何設 計一個好的壅塞控制機制，一直是網路中相當重要的課題[1]。
2.2 壅塞控制
壅塞控制這個概念最早於 1986 年由 Nagle 在[13]中提出之後，網路中關於壅塞控制 機制的研究就沒有停過，直到 1988 年 Jacobson 在[11]中詳細討論了慢啟動、快速重傳、
壅塞避免等壅塞控制的方法，成為現今最常用的 AIMD(Additive Increase Multiplicative Decrease)壅塞控制機制的基礎，目前基於 AIMD 為基礎的壅塞控制方法有 TCP Tahoe、
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
6
TCP Reno、TCP NewReno、TCP SACK 等等，在[5]中透過模擬的方式，分析了這幾種 壅塞控制機制的效能。
但隨著多媒體網路應用的興起，越來越多應用程式透過 UDP 傳輸資料，通常這些 網路應用程式不需使用 TCP 的可靠傳輸的特性，例如 IPTV 和 VoIP 等等。但由於 UDP 缺乏壅塞控制機制，這些應用程式必頇針對網路壅塞的情況自行設計應對方式，然而在 應用層實作壅塞控機制並不容易，因此有一些針對不可靠傳輸進行壅塞控制的傳輸層傳 輸協議被提出。
2.3 數據壅塞控制協定(DCCP)
DCCP 是個連線導向的傳輸層傳輸協議，包含了連線的建立與拆除、ECN、壅塞控 制等，它提供了不同的壅塞控制方式供使用者選擇，但並不包含重送機制，是一個不可 靠的傳輸協議[10]。DCCP 和 TCP 相當類似，透過 ACK 封包來確認資料是否送達接收 端，ACK 訊息中包含了發送端送出的封包是否到達目的地，以及標頭中是否含有 ECN 標記。在連線建立的時候，使用者可透過壅塞控制編號(CCID)選擇不同的壅塞控制機。
2.4 TCP 的壅塞控制
由於網路並非完美無缺，少部分的封包可能在傳遞的過程中遺失。一般而言，網路 壅塞是造成封包遺失的最大原因，此時傳輸協議必頇要盡快做出反應降低傳送速率以舒 緩網路的壅塞。TCP 使用 AIMD 的方式調整傳輸速率，此外還有慢啟動、壅塞迴避等狀 態來避免網路壅塞[11]，以上這些方式最早出現在 TCP Tahoe 和 Reno 版本中[5]。
2.4.1 TCP Tahoe 和 Reno
在每條 TCP 建立的連線之中，發送端利用壅塞視窗之控制來限制兩個終端節點之 間未經確認的封包總數上限，亦即已送出但尚未到達的封包總數之上限，藉此來控制傳 輸速率。當接收端收到一個封包，便會回覆一個 ACK 給發送端，告知目前所收到最新
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
7
的封包序號；當發送端收到 ACK 之後，便再送出一個封包，壅塞控制窗口內的未被確 認封包總數維持於窗口上限。若接收端收到跳序的封包時，它會送回一個 duplicate ACK 重複前一個封包序號給傳送端，藉以回報異常狀況。
TCP 在連結建立的開始或是逾時產生後會進入慢啟動機制[16]。接收端每收到一個 封包，便回送一個 ACK，而傳送端在接收到每一個 ACK 後便增加壅塞視窗之大小，以 倍數的方式遞增直到產生封包遺失，當接收端發生連線逾時，CWND (Congestion Window)會降至初始值，再以倍數成長至 threshold，此時便進入壅塞避免階段，此因既 已偵測到傳輸速率之極限，理當調整減緩 CWND 的擴張速度。當 CWND 增長至 threshold 之後每接到一個 ACK，CWND 只增加一格，這個過程持續不斷的進行，直到壅塞產生 後，縮減 CWND 並將 threshold 減半。而 TCP Tahoe 和 Reno 對於收到 duplicate ACK 有 著不同的處理方式。
當傳送端收到三個 duplicate ACK 時，TCP Tahoe 處理的方式和處理連線逾時相同 (即等到 Timeout 才啟動封包遺失相關動作)，而 Reno 則認為等到 Timeout 發生後再進行 重傳常會耗時過久，影響效能，因此加上了 Fast Retransmit 機制，當傳送端收到三個 duplicate ACK 後，便假設此重複 ACK 所回報序號之下一個封包已經遺失，但網路只有 輕微壅塞故立即重傳該封包，並進入 Fast Recovery，不頇等到 Timeout。
在 Fast Retransmit 之後，所進入的狀態是擁塞避免階段，而非慢啟動階段，此機制 稱為 Fast Recovery，之後如果等到連線逾時仍然沒有收到 ACK，TCP Reno 將會視為網 路嚴重壅塞，並進入慢啟動狀態。
2.4.2 TCP Vegas
TCP Vegas 利用封包來回時間(Round-Trip Time)來調整 CWND[2]，並使用遞增的方 式來增加 CWND 的大小，雖然這種測量網路頻寬的方式較為準確，但相較於其他 TCP 版本，TCP Vegas 對於頻寬的競爭力較為薄弱，所以不受一般人青睞。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
8
2.4.3 其他版本 TCP
NewReno 和 SACK 的出現是用來改善並增進 Reno 的效能[5, 6]。在特殊的網路環境 中，例如無線網路，封包遺失的主因不再是網路壅塞，原本的壅塞控制機制反而會造成 傳輸速度緩慢，因此有許多不同的 TCP 版本被提出法來改善這些問題[9, 14]。
2.5 DCCP 的壅塞控制
DCCP 目前定義了 CCID2 與 CCID3 兩種不同的壅塞控制方法。
2.5.1 CCID 2: TCP-Like 壅塞控制
在 DCCP 中 CCID2[7]制定的壅塞控制機制是和 TCP 相當類似的，其中也有幾個重 要的狀態，分別是慢啟動(Slow Start)、壅塞迴避(Congestion Avoidance)和重送逾時 (Retransmission Timeout)，最大的不同在於沒有重送(Retransmission)機制。如同 TCP 一 般，在 CCID2 中利用壅塞視窗(Congestion Windows)配合 AIMD 的演算法來控制傳輸速 率，另外 CCID2 也針對 ACK 封包進行壅塞控制。
2.5.2 CCID 3: TFRC 壅塞控制
TFRC 是以傳輸速率(Rate-Based) [8]為基礎的壅塞控制機制。不同於 TCP 使用 CWND，TFRC 而是以(1)所列計算式來估計並控制發送端的傳輸速率，主要透過
RTT(Round Trip Time)與封包遺失(Packet Loss)作為依據，並以計算出的 X 值為限制，控 制傳輸速率。
√ √ ))) (1) s=平均封包大小
p=封包遺失率 RTT=封包延遲
t_RTO=TCP Retransmission Timeout 時間
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
9
TFRC 的壅塞控制方式必頇在傳送端和接收端之間建立起連線，用以進行網路參數 的回饋。當傳輸開始時，TFRC 效法 TCP 的慢啟動階段，以便快速的增加傳輸速率來取 得公平的頻寬，等到發生第一個封包遺失事件後，傳送端會收到接收端傳回的回饋訊息 (feedback)，進而結束慢啟動階段，並將接收端回饋的網路參數代入公式(1)中，重新預 估可用的傳輸速率後，再以此傳輸速率發送數據封包。
在 TFRC 傳輸速率公式中(1)，最重要的兩個參數分別是封包遺失率與 RTT，這兩 項參數的改變將會大幅影響傳輸速率的估計。TFRC 透過封包標頭中的序號，接收端可 以計算出封包遺失率 p 回饋給傳送端；在由標頭中的時間戳記(timestamp)就可計算出封 包往返時間 RTT。TFRC 假設在同一段時間內，造成封包遺失的原因都是相同的，故將 一個 RTT 之內所有的封包遺失都視為一個封包遺失事件，因此估計出的傳輸速率會較 為平緩。
2.6 VoIP 語音封包產生流程
VoIP 使用網際網路來傳送語音資料，其作法是將語音從麥克風擷取後，由類比訊 號轉為數位訊號，經由壓縮演算法封裝為數據封包，透過網路傳輸，接收端後將數據封 包解壓縮後，再轉換成為類比訊號由喇叭播出，如圖所示。
圖 1 VoIP 語音封包產生流程
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
10
2.6.1 取樣與編碼
麥克風將聲音轉換成為有強弱幅度變化的電壓信號，此信號是一種類比信號，經由 數位轉換的過程後成為數位信號，才能由電腦處理。
在取樣過後，電腦將數位訊號進行編碼，在過程中通常會加入壓縮的動作來減少網 路頻寬的消耗，在壓縮前必頇先從取樣後的數位音訊訊號取出一小段，經由編碼器 (Codec)編碼後輸出壓縮過後的資訊，每一段資訊稱為一個訊框(Frame)，一個訊框會包 含 10 毫秒到 30 毫秒的音訊訊號，依不同的編碼器會有不同的標準。
在編碼的過程中，可以選擇不同的壓縮演算法。高壓縮率所產生的語音封包較小，
音質較差，所需的網路頻寬也較小，相反的低壓縮率所產生的語音封包較大，音質較佳，
但所需的頻寬也較大。目前針對語音壓縮演算法主要的有：G.723、G.729a、iLBC、
Speex[19, 20, 21, 23]等，表 1 是幾個常見編碼器的參數。
表 1 各種常見語音壓縮編碼的參數
Codec Sampling Rate Frame Size Bit-rate
G.723 8kHz 67.5ms 6.4Kbps
G.729 8kHz 20ms 8Kbps
iLBC 8kHz 30ms/20ms 13.3/15Kbps
Speex 8kHz/16kHz 20ms/40ms 2.15-44Kbps 2.6.2 封包封裝與傳輸
編碼之後透過網路傳輸前，會將訊框封裝(Packetization)成為封包後才交由網路傳遞，
一般網路電話應用程式會將編碼過後的資料封裝成 RTP 封包，再加上傳輸層傳輸協議 封包標頭與 IP 標頭後成為一個 IP 封包，當一段語音資料封裝成為 IP 封包後，由 IP 封 包標頭中所記錄的位置資訊，即能透過網路傳送至目的地。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
11
2.6.3 影響通話品質的參數
影響通話品質的參數可由使用者端和網路端兩個方向來說明。以使用者端來說，較 差的收音設備和環境中的噪音，或是由喇叭發出聲音後再由麥克風接收產生的回音，甚 至是不同編碼器(Codec)有不同的失真程度，都會降影響網路電話的通話品質；另外在網 路傳輸的過程中，網路情況好壞會造成封包延遲(Packet Delay)、封包遺失(Packet Loss)、
封包抖動(Jitter)等情形，諸如此類問題皆可能降低網路電話的通話品質。
2.7 VoIP 通話品質評量指標
網路語音品質評估指標分為主觀與客觀兩種。主觀的語音評估方式是利用人的耳朵 直接收聽語音，並給此段語音評分，常見的指標為 MOS；客觀的方式是利用數學模型，
將系統中的參數代入計算出分數，常見的指標有 E-Model。
2.7.1 MOS
一般常用來衡量 VoIP 通話品質的指標是依據 ITUT 所制定 MOS(Mean Opinion Score)分數[22]，MOS 是一種較為主觀的語音品質測量指標，收聽者按照從 1 到 5 分對 語音會話品質來進行分級，分數由高至低分為最好和最壞，如表 2。
表 2 Mean Opinion Score 定義
MOS Quality Impairment
5
Excellent Imperceptible4
Good Perceptible but not annoying3
Fair Slightly annoying2
Poor Annoying1
Bad Very annoying‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
12
2.7.2 E-Model
除此之外，還可以利用同為 ITUT 所制定的 E-Model[17]，E-Model 透過語音傳輸過
除此之外，還可以利用同為 ITUT 所制定的 E-Model[17]，E-Model 透過語音傳輸過