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

　　圖 1 顯示了從客戶端到服務(wù)器的 TCP 會(huì)話示例,由于其具有較小的窗口尺寸,因此具有“猝發(fā)性”。盡管物理通道能夠?qū)崿F(xiàn)高數(shù)據(jù)速率,但應(yīng)用在客戶端實(shí)際獲得的吞吐量則由 TCP 協(xié)議所限,只是高速率的一小部分。對 TCP 應(yīng)用性能影響最大的不是數(shù)據(jù)速率,而是吞吐量。如果將窗口大小調(diào)整得更大些,那么數(shù)據(jù)包數(shù)量就會(huì)增加,流量也就 “更通暢”。
　
　　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）的不同傳輸特點(diǎn)進(jìn)行了定義。PHY 與 MAC 層都有差異,并導(dǎo)致 DOCSIS 通道工作不對稱。
　　下行通道根據(jù)定義可在連續(xù)傳輸中支持高達(dá) 40Mbit/sec 的速率。CMTS 負(fù)責(zé)從"因特網(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é)商即可對其進(jìn)行訪問。
　　另一方面,上行通道則大為不同。在上行通道中,所有共享媒體的調(diào)制解調(diào)器競爭獲得上行訪問權(quán)。希望發(fā)送數(shù)據(jù)的線纜調(diào)制解調(diào)器需首先請求 CMTS 以獲得傳輸機(jī)會(huì)。CMTS 隨后將從調(diào)制解調(diào)器收集請求,并發(fā)送消息以表明每個(gè)調(diào)制解調(diào)器在上行通道能夠發(fā)送數(shù)據(jù)的時(shí)間。調(diào)制解調(diào)器一次只可請求一個(gè)傳輸機(jī)會(huì),這就限制了調(diào)制解調(diào)器每秒鐘可執(zhí)行的上行傳輸數(shù)量。
　　圖 2顯示了上下行通道之間的差異。

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


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

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


　　下面的例子顯示了 TCP 上運(yùn)行的應(yīng)用對帶寬瓶頸的影響：
　　例 1 -- DOCSIS 1.0 設(shè)備中的 TCP 性能
　　設(shè)備特點(diǎn)：
　　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
　　單個(gè) ACK 確認(rèn)的字節(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)器實(shí)現(xiàn)TCP性能改善
　　與 DOCSIS 1.0 相比,DOCSIS 1.1 擁有幾種不同的改善。盡管這些改善是因?yàn)橄Ｍ麑?shí)現(xiàn)語音應(yīng)用功能而在 MAC 協(xié)議中實(shí)現(xiàn)的,不過協(xié)議所添加的工具還是能夠顯著改善 TCP 上的數(shù)據(jù)傳輸。這些改善包括多服務(wù)流、有效負(fù)載報(bào)頭壓縮、級連等。