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

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

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

圖2：顯示下游通道并列出了其特點(diǎn)；顯示上游通道并列出了其特點(diǎn)。


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

圖3：顯示數據請求許可傳輸周期


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

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

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