摘要：近年来，符合 DOCSIS™ 标准的线缆调制解调器已在全球得到了广泛部署，使最终用户能够获得始终在线的高带宽因特网连接。由于通过 TCP 可运行最常见的应用，因此我们探索运行在 DOCSIS 数据网络上的 TCP 协议行为就显得非常重要了。
本文概括性地介绍了 TCP 的内在双向性，并就 DOCSIS 协议对 TCP 的影响也进行了讨论。最后，我们还将对提高 TCP 以及利用 TCP 的应用性能提出方案，在线缆调制解调器中嵌入应用感知 (application awareness)。
TCP 特点介绍
TCP 是最常见的因特网应用传输协议，由于其是基于连接的协议，因此能够保证每个从服务器传输的数据包都能到达目的客户端应用。为了保证每个数据包均能到达其目的地，TCP 使用了握手协议 (Handshake Protocol)。服务器与客户端都跟踪正在传输/接收的数据包。
服务器同时向客户端发送数个数据包并等待已接收到数据包的确认。如果在给定时间内确认 (ACK) 未返回至服务器--则服务器将"停机"，并不再发送下一个数据包。如果最终仍不能接收到ACK，那么服务器将重新传输未确认的数据包。服务器等待 ACK 到达前发送的数据包数量取决于"窗口大小"。窗口大小对 TCP 的性能有很大影响--窗口越小，服务器停止传输等待 ACK 到达的几率就越高。
从客户端到服务器的 TCP 会话由于其具有较小的窗口尺寸，因此具有"猝发性"。尽管物理通道能够实现高数据速率，但应用在客户端实际获得的吞吐量则由 TCP 协议所限，只是高速率的一小部分。对 TCP 应用性能影响最大的不是数据速率，而是吞吐量。如果将窗口大小调整得更大些，那么数据包数量就会增加，流量也就 "更通畅"。
DOCSIS 基本原理
CableLabs® DOCSIS规范定义了线缆调制解调器传输的物理层 (PHY) 方面与接入线缆通道的媒体接入控制 (MAC) 协议。DOCSIS 就下行传输（从线缆调制解调器终端系统的传输或至家庭线缆调制解调器的 CMTS）和上行传输（从家庭返回至CMTS）的不同传输特点进行了定义。PHY 与 MAC 层都有差异，并导致 DOCSIS 通道工作不对称。
下行通道根据定义可在连续传输中支持高达 40Mbit/sec 的速率。CMTS 负责从"因特网云 (Internet cloud)"接收数据包并将其通过有线网络 (cable network) 发送至线缆调制解调器。CMTS 决定着数据包传输的顺序与优先级。此外，由于CMTS完全占有下行媒体，因此无需协商即可对其进行访问。
另一方面，上行通道则大为不同。在上行通道中，所有共享媒体的调制解调器竞争获得上行访问权。希望发送数据的线缆调制解调器需首先请求 CMTS 以获得传输机会。CMTS 随后将从调制解调器收集请求，并发送消息以表明每个调制解调器在上行通道能够发送数据的时间。调制解调器一次只可请求一个传输机会，这就限制了调制解调器每秒钟可执行的上行传输数量。
DOCSIS™ 1.0 线缆调制解调器上的 TCP 性能
DOCSIS 1.0 可支持线缆调制解调器与 CMTS 之间的数据通信。线缆调制解调器平等竞争以利用上行通道。需进行上行数据传输的线缆调制解调器必须首先从 CMTS请求许可。CMTS 随后将该消息与网络上所有其他线缆调制解调器发送的其他类似请求一并处理。CMTS 而后将确定如何向发出请求的线缆调制解调器分配上行通道，并发送消息以便"映射"对进入时间分段的上行使用。
线缆调制解调器可进行的上行传输数量限于每秒数百次。
在 DOCSIS 1.0 中，线缆调制解调器能够在每个上行传输猝发中发送一个数据包。就 TCP 而言--这意味着客户端应用可发送至服务器的 ACK 数量有限。
下面的例子显示了 TCP 上运行的应用对带宽瓶颈的影响：
例 1 -- DOCSIS 1.0 设备中的 TCP 性能
设备特点：
DOCSIS 1.0
下行--256QAM 速率为 5.12Mbaud/sec（即约 40Mbit/sec）
上行 --16QAM、2.56Mbaud（即约 10Mbit/sec）
假定：
每秒猝发数量： 300
每次猝发数据包数量： 1
每秒 TCP ACK 数量： 300
单个 ACK 确认的字节数： 3036
最大可获得的 TCP 下行带宽： 7.2Mbit/sec
上例显示出 DOCSIS 1.0 线缆调制解调器可获得的最大 TCP 吞吐量限于 7.2 Mbit/sec，尽管下行通道能够实现大得多的带宽。
采用 DOCSIS 1.1 线缆调制解调器实现TCP性能改善
与 DOCSIS 1.0 相比，DOCSIS 1.1 拥有几种不同的改善。尽管这些改善是因为希望实现语音应用功能而在 MAC 协议中实现的，不过协议所添加的工具还是能够显著改善 TCP 上的数据传输。这些改善包括多服务流、有效负载报头压缩、级连等。
级联是 DOCSIS 1.0 中可选的特性，在DOCSIS 1.1中则是必需的部分。级联使得线缆调制解调器可将若干个数据包组合在一起并将其作为一个数据包传输。这意味着每秒调制解调器可发送的数据包数量不再限于 CMTS 所限制的传输量。这对TCP 性能而言尤其重要。由于 ACK 是短数据包，因此几个 ACK 可和并在一起统一传输（可一次猝发传输）。
级联能够避开上述例 1 中的瓶颈。例2显示利用级联可实现下行最高带宽。
例2--DOCSIS 1.1设备中的TCP性能
设备特点：
DOCSIS 1.0
下行 -- 256QAM 速率为 5.12Mbaud/sec（即约 40Mbit/sec）
上行 --16QAM，2.56Mbaud（即约10Mbit/sec）
假定：
每秒猝发数量： 300
最大猝发字节： 1518
每次猝发最大ACK数量： 23
每秒TCP ACK数量： 300*23 = 6900
单个ACK确认的字节数： 3036
最大可获得的TCP下行带宽： 40Mbit/sec
请注意：ACK不是瓶颈。在6000 ACKs/sec的速率上，确认速度可达170Mbit/sec，这大大高于下行的容量。
我们从例2可以得出结论，TCP 性能瓶颈已经通过采用级联得到解决。尽管级联确实提供了某些改善，但改善仅限于单个TCP会话活动状态，而且不能解决所有实际情况中的问题。
DOCSIS™ 2.0调制解调器上的TCP性能
DOCSIS 1.0到DOCSIS 1.1的升级推出了几种新的MAC机制，旨在获得语音服务等应用所要求的服务质量，而DOCSIS 2.0规范则致力于改善上行PHY。这一改善要解决两个问题--吞吐量和稳健性。上行调制增强后可支持64QAM，并增加了5.12Mbaud/sec 的波特率，从而使上行传输达到约30Mbit/sec。
对上行通道容量的改善实现了更高的数据传输。这是一种显著改善，使用户能够获得更多带宽进行信息发送，这对文件共享和游戏等应用都相当重要。我们还应注意到，DOCSIS 2.0实现的额外上行带宽并不会直接改善 TCP 性能，这点也很重要。如上所示，发送 ACK的瓶颈在于 MAC 协议，它每秒钟只允许有限数量的猝发。
双向流量对 TCP 性能的影响
目前，我们已讨论了单个 TCP 会话的性能，假定的情况为调制解调器没有进行其他上行传输。在上行流量存在的情况下，发送下行数据的TCP会话性能会下降。上行流量可为任何类型的流量，TCP或其他类型都可以，其来自客户端，并通过线缆调制解调器传输至因特网。上行传输的来源可能是电子邮件和附件、点击网站、文件共享、游戏应用以及许多其他情况等。
在例3中，我们将重新审视TCP的性能，不过这次我们假定线缆调制解调器还要进行其他上行流量。
例3 -- TCP性能 - DOCSIS 1.0 + 上行
设备特点：
DOCSIS 1.0
下行 -- 256QAM 速率为5.12Mbaud/sec（即约40Mbit/sec）
上行 --16QAM，2.56Mbaud（即约 10Mbit/sec）
假定：
每秒猝发数量： 300
每次猝发的数据包数量： 1
每秒TCP ACK数量： 100（假定三分之二的猝发为数据）
单个ACK确认的字节数： 3036
最高可获得的TCP下行带宽： 2.4Mbit/sec
例3所示的TCP应用性能遭到很大衰减。例1中，所有猝发都用于传输ACK，而例3中，只有三分之一的猝发用于ACK，三分之二的猝发用于发送其他数据。每秒ACK的数量减至原数量的三分之一。这就直接造成下行TCP性能下降三分之二。
例4-- TCP性能 - DOCSIS 1.1 + 上行
在本例中，DOCSIS 1.1线缆调制解调器工作于下行与上行流量。假定数据包长度定义为1518字节，不可能将ACK与上行发送的数据包相级联。
每秒可在上行发送的ACK数量将有所差异。现在它取决于级联在一起的ACK数量。此外，我们还假定级联在一起的ACK数量约为三。
设备特点：
DOCSIS 1.0
下行 -- 256QAM 速率为 5.12Mbaud/sec（即约40Mbit/sec）
上行 --16QAM，2.56Mbaud（即约10Mbit/sec）
假定：
每秒猝发数量： 300
最大猝发字节数： 1518
每秒TCP ACK的猝发数： 100（假定三分之二用于数据）
每次猝发最大ACK数量： 3
每秒TCP ACK数量： 300
单个ACK确认的字节数： 3036
最高可获得的TCP下行带宽： 7.2Mbit/sec
即便对 DOCSIS 1.1线缆调制解调器而言，上行流量的影响也非常大。预计DOCSIS 1.1 线缆调制解调器的性能将大大好于 DOCSIS 1.0 线缆调制解调器，但相比于线缆调制解调器只进行下行传输的情况，还是造成了大幅度性能降级。
过滤 ACK
如 DOCSIS 所定义的那样，线缆调制解调器不检查其所传输数据包的内容。如果我们让线缆调制解调器检查数据包--我们将其称作感知，我们就可以改善线缆调制解调器的 TCP 应用性能。
举例而言，如果线缆调制解调器就先前接收的数据包要传输多个 ACK，那么它只能传输最近的 ACK。TCP 协议认为该 ACK 表明此前所有数据包都由客户端适当接收。因此，该 ACK 包括它之前所有 ACK 传达的所有信息，而此前这些 ACK 都可舍弃。仅发送最近 ACK 而舍弃其余未传输 ACK 的工作就称作 ACK 过滤。
例5反映了双向流量情况（同时进行上行和下行流量）中可预计的下行 TCP 性能改善。
例5-- TCP 性能 - DOCSIS 1.0 + 上行 + ACK 过滤
本例中，我们显示了，启用 ACK 过滤的 DOCSIS 1.0 线缆调制解调器可在上行流量存在的情况下实现 30Mbit/sec的性能。
设备特点：
DOCSIS 1.0
下行 -- 256QAM 速率为 5.12Mbaud/sec（即约 40Mbit/sec）
上行 --16QAM，2.56Mbaud（即约10Mbit/sec）
假定：
每秒猝发数量 300
最大猝发字节数： 1518
每秒 TCP ACK 的猝发数： 100 （假定三分之二猝发用于数据）
每次猝发最大 ACK 数量： 3 确认所有先前数据包
每秒相应 TCP ACK 数量： 1000
单个 ACK 确认的字节数： 3036
最高可获得的 TCP 下行带宽： 30Mbit/sec
在例 5 中，300个猝发仅有 100 个进行传输。启用 ACK 过滤后，就相当于传输了1000 个 ACK！这样实现的性能改善使线缆调制解调器目前可获得高达 30Mbit/sec的下行 TCP。
ACK过滤--一种"设备友好"解决方案
性能改善与实现改善所需的更多带宽之间通常都有权衡取舍的问题。ACK 过滤则没有这种情况。性能改善的同时还取消了原计划进行上行传输的一些数据包。减去不必要的数据包增加了上行带宽。
结论
因为需要从客户端向服务器发送确认，因此 TCP 性能要求双向流量。DOCSIS 的不对称性限制了 TCP 性能。从 DOCSIS 1.0 到 DOCSIS 1.1 的升级采用级联大幅提高了TCP 的性能。
即便采用了级联，某些情况下TCP性能仍可能大幅降级。本文介绍的 ACK 过滤可作为一种有效的"设备"友好方法，即便在上述情况下也可提高 TCP 性能。
CableLabs 与 DOCSIS 是有线电视实验室公司 (Cable Television Laboratories, Inc) 的商标。
3/20/2005
|
