如何提高 DOCSIS 線纜調(diào)制解調(diào)器的 TCP 性能

　摘要
　　近年來，符合 DOCSIS標準的線纜調(diào)制解調(diào)器已在全球得到了廣泛部署，使最終用戶能夠獲得始終在線的高帶寬因特網(wǎng)連接。由于通過 TCP 可運行最常見的應(yīng)用，因此我們探索運行在 DOCSIS 數(shù)據(jù)網(wǎng)絡(luò)上的 TCP 協(xié)議行為就顯得非常重要了。
　　本文概括性地介紹了 TCP 的內(nèi)在雙向性，并就 DOCSIS 協(xié)議對 TCP 的影響也進行了討論。最后，我們還將對提高 TCP 以及利用 TCP 的應(yīng)用性能提出方案，在線纜調(diào)制解調(diào)器中嵌入應(yīng)用感知 (application awareness)。
　　TCP 特點介紹
　　TCP 是最常見的因特網(wǎng)應(yīng)用傳輸協(xié)議，由于其是基于連接的協(xié)議，因此能夠保證每個從服務(wù)器傳輸?shù)臄?shù)據(jù)包都能到達目的客戶端應(yīng)用。為了保證每個數(shù)據(jù)包均能到達其目的地，TCP 使用了握手協(xié)議 (Handshake Protocol)。服務(wù)器與客戶端都跟蹤正在傳輸/接收的數(shù)據(jù)包。
　　服務(wù)器同時向客戶端發(fā)送數(shù)個數(shù)據(jù)包并等待已接收到數(shù)據(jù)包的確認。如果在給定時間內(nèi)確認 (ACK) 未返回至服務(wù)器--則服務(wù)器將"停機"，并不再發(fā)送下一個數(shù)據(jù)包。如果最終仍不能接收到ACK，那么服務(wù)器將重新傳輸未確認的數(shù)據(jù)包。服務(wù)器等待 ACK 到達前發(fā)送的數(shù)據(jù)包數(shù)量取決于"窗口大小"。窗口大小對 TCP 的性能有很大影響--窗口越小，服務(wù)器停止傳輸?shù)却?ACK 到達的幾率就越高。。
　　
圖1　顯示了采用較小窗口大小的“猝發(fā)性”傳輸與較大窗口大小的“更通暢”傳輸

　　圖 1 顯示了從客戶端到服務(wù)器的 TCP 會話示例，由于其具有較小的窗口尺寸，因此具有“猝發(fā)性”。盡管物理通道能夠?qū)崿F(xiàn)高數(shù)據(jù)速率，但應(yīng)用在客戶端實際獲得的吞吐量則由 TCP 協(xié)議所限，只是高速率的一小部分。對 TCP 應(yīng)用性能影響最大的不是數(shù)據(jù)速率，而是吞吐量。如果將窗口大小調(diào)整得更大些，那么數(shù)據(jù)包數(shù)量就會增加，流量也就 “更通暢”。
　
　　DOCSIS 基本原理
　　CableLabs? DOCSIS規(guī)范定義了線纜調(diào)制解調(diào)器傳輸?shù)奈锢韺?(PHY) 方面與接入線纜通道的媒體接入控制 (MAC) 協(xié)議。DOCSIS 就下行傳輸（從線纜調(diào)制解調(diào)器終端系統(tǒng)的傳輸或至家庭線纜調(diào)制解調(diào)器的 CMTS）和上行傳輸（從家庭返回至CMTS）的不同傳輸特點進行了定義。PHY 與 MAC 層都有差異，并導致 DOCSIS 通道工作不對稱。
　　下行通道根據(jù)定義可在連續(xù)傳輸中支持高達 40Mbit/sec 的速率。CMTS 負責從"因特網(wǎng)云 (Internet cloud)"接收數(shù)據(jù)包并將其通過有線網(wǎng)絡(luò) (cable network) 發(fā)送至線纜調(diào)制解調(diào)器。CMTS 決定著數(shù)據(jù)包傳輸?shù)捻樞蚺c優(yōu)先級。此外，由于CMTS完全占有下行媒體，因此無需協(xié)商即可對其進行訪問。
　　另一方面，上行通道則大為不同。在上行通道中，所有共享媒體的調(diào)制解調(diào)器競爭獲得上行訪問權(quán)。希望發(fā)送數(shù)據(jù)的線纜調(diào)制解調(diào)器需首先請求 CMTS 以獲得傳輸機會。CMTS 隨后將從調(diào)制解調(diào)器收集請求，并發(fā)送消息以表明每個調(diào)制解調(diào)器在上行通道能夠發(fā)送數(shù)據(jù)的時間。調(diào)制解調(diào)器一次只可請求一個傳輸機會，這就限制了調(diào)制解調(diào)器每秒鐘可執(zhí)行的上行傳輸數(shù)量。
　　圖 2顯示了上下行通道之間的差異。

圖2：顯示下游通道并列出了其特點；顯示上游通道并列出了其特點。


　　DOCSIS 1.0 線纜調(diào)制解調(diào)器上的 TCP 性能
　　DOCSIS 1.0 可支持線纜調(diào)制解調(diào)器與 CMTS 之間的數(shù)據(jù)通信。線纜調(diào)制解調(diào)器平等競爭以利用上行通道。需進行上行數(shù)據(jù)傳輸?shù)木€纜調(diào)制解調(diào)器必須首先從 CMTS請求許可。CMTS 隨后將該消息與網(wǎng)絡(luò)上所有其他線纜調(diào)制解調(diào)器發(fā)送的其他類似請求一并處理。CMTS 而后將確定如何向發(fā)出請求的線纜調(diào)制解調(diào)器分配上行通道，并發(fā)送消息以便"映射"對進入時間分段的上行使用。
　　線纜調(diào)制解調(diào)器可進行的上行傳輸數(shù)量限于每秒數(shù)百次。
　　在 DOCSIS 1.0 中，線纜調(diào)制解調(diào)器能夠在每個上行傳輸猝發(fā)中發(fā)送一個數(shù)據(jù)包。就 TCP 而言--這意味著客戶端應(yīng)用可發(fā)送至服務(wù)器的 ACK 數(shù)量有限。圖3顯示了從下行接收數(shù)據(jù)包到向服務(wù)器發(fā)送確認的周期。

圖3：顯示數(shù)據(jù)請求許可傳輸周期


　　下面的例子顯示了 TCP 上運行的應(yīng)用對帶寬瓶頸的影響：
　　例 1 -- DOCSIS 1.0 設(shè)備中的 TCP 性能
　　設(shè)備特點：
　　DOCSIS 1.0
　　下行--256QAM 速率為 5.12Mbaud/sec（即約 40Mbit/sec）
　　上行 --16QAM、2.56Mbaud（即約 10Mbit/sec）
　　假定：
　　每秒猝發(fā)數(shù)量： 300
　　每次猝發(fā)數(shù)據(jù)包數(shù)量： 1
　　每秒 TCP ACK 數(shù)量： 300
　　單個 ACK 確認的字節(jié)數(shù)： 3036
　　最大可獲得的 TCP 下行帶寬： 7.2Mbit/sec

　　上例顯示出 DOCSIS 1.0 線纜調(diào)制解調(diào)器可獲得的最大 TCP 吞吐量限于 7.2 Mbit/sec，盡管下行通道能夠?qū)崿F(xiàn)大得多的帶寬。

　　采用 DOCSIS 1.1 線纜調(diào)制解調(diào)器實現(xiàn)TCP性能改善
　　與 DOCSIS 1.0 相比，DOCSIS 1.1 擁有幾種不同的改善。盡管這些改善是因為希望實現(xiàn)語音應(yīng)用功能而在 MAC 協(xié)議中實現(xiàn)的，不過協(xié)議所添加的工具還是能夠顯著改善 TCP 上的數(shù)據(jù)傳輸。這些改善包括多服務(wù)流、有效負載報頭壓縮、級連等。