如何提高 DOCSIS 线缆调制解调器的 TCP 性能
——
加入技术交流群
摘要
近年来，符合 DOCSIS标准的线缆调制解调器已在全球得到了广泛部署，使最终用户能够获得始终在线的高带宽因特网连接。由于通过 TCP 可运行最常见的应用，因此我们探索运行在 DOCSIS 数据网络上的 TCP 协议行为就显得非常重要了。
本文概括性地介绍了 TCP 的内在双向性，并就 DOCSIS 协议对 TCP 的影响也进行了讨论。最后，我们还将对提高 TCP 以及利用 TCP 的应用性能提出方案，在线缆调制解调器中嵌入应用感知 (application awareness)。
TCP 特点介绍
TCP 是最常见的因特网应用传输协议，由于其是基于连接的协议，因此能够保证每个从服务器传输的数据包都能到达目的客户端应用。为了保证每个数据包均能到达其目的地，TCP 使用了握手协议 (Handshake Protocol)。服务器与客户端都跟踪正在传输/接收的数据包。
服务器同时向客户端发送数个数据包并等待已接收到数据包的确认。如果在给定时间内确认 (ACK) 未返回至服务器--则服务器将"停机"，并不再发送下一个数据包。如果最终仍不能接收到ACK，那么服务器将重新传输未确认的数据包。服务器等待 ACK 到达前发送的数据包数量取决于"窗口大小"。窗口大小对 TCP 的性能有很大影响--窗口越小，服务器停止传输等待 ACK 到达的几率就越高。。
图1 显示了采用较小窗口大小的“猝发性”传输与较大窗口大小的“更通畅”传输
图 1 显示了从客户端到服务器的 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 随后将从调制解调器收集请求，并发送消息以表明每个调制解调器在上行通道能够发送数据的时间。调制解调器一次只可请求一个传输机会，这就限制了调制解调器每秒钟可执行的上行传输数量。
图 2显示了上下行通道之间的差异。
图2：显示下游通道并列出了其特点；显示上游通道并列出了其特点。
DOCSIS 1.0 线缆调制解调器上的 TCP 性能
DOCSIS 1.0 可支持线缆调制解调器与 CMTS 之间的数据通信。线缆调制解调器平等竞争以利用上行通道。需进行上行数据传输的线缆调制解调器必须首先从 CMTS请求许可。CMTS 随后将该消息与网络上所有其他线缆调制解调器发送的其他类似请求一并处理。CMTS 而后将确定如何向发出请求的线缆调制解调器分配上行通道，并发送消息以便"映射"对进入时间分段的上行使用。
线缆调制解调器可进行的上行传输数量限于每秒数百次。
在 DOCSIS 1.0 中，线缆调制解调器能够在每个上行传输猝发中发送一个数据包。就 TCP 而言--这意味着客户端应用可发送至服务器的 ACK 数量有限。图3显示了从下行接收数据包到向服务器发送确认的周期。
图3：显示数据请求许可传输周期
下面的例子显示了 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标准的线缆调制解调器已在全球得到了广泛部署，使最终用户能够获得始终在线的高带宽因特网连接。由于通过 TCP 可运行最常见的应用，因此我们探索运行在 DOCSIS 数据网络上的 TCP 协议行为就显得非常重要了。
本文概括性地介绍了 TCP 的内在双向性，并就 DOCSIS 协议对 TCP 的影响也进行了讨论。最后，我们还将对提高 TCP 以及利用 TCP 的应用性能提出方案，在线缆调制解调器中嵌入应用感知 (application awareness)。
TCP 特点介绍
TCP 是最常见的因特网应用传输协议，由于其是基于连接的协议，因此能够保证每个从服务器传输的数据包都能到达目的客户端应用。为了保证每个数据包均能到达其目的地，TCP 使用了握手协议 (Handshake Protocol)。服务器与客户端都跟踪正在传输/接收的数据包。
服务器同时向客户端发送数个数据包并等待已接收到数据包的确认。如果在给定时间内确认 (ACK) 未返回至服务器--则服务器将"停机"，并不再发送下一个数据包。如果最终仍不能接收到ACK，那么服务器将重新传输未确认的数据包。服务器等待 ACK 到达前发送的数据包数量取决于"窗口大小"。窗口大小对 TCP 的性能有很大影响--窗口越小，服务器停止传输等待 ACK 到达的几率就越高。。
图1 显示了采用较小窗口大小的“猝发性”传输与较大窗口大小的“更通畅”传输
图 1 显示了从客户端到服务器的 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 随后将从调制解调器收集请求，并发送消息以表明每个调制解调器在上行通道能够发送数据的时间。调制解调器一次只可请求一个传输机会，这就限制了调制解调器每秒钟可执行的上行传输数量。
图 2显示了上下行通道之间的差异。
图2：显示下游通道并列出了其特点；显示上游通道并列出了其特点。
DOCSIS 1.0 线缆调制解调器上的 TCP 性能
DOCSIS 1.0 可支持线缆调制解调器与 CMTS 之间的数据通信。线缆调制解调器平等竞争以利用上行通道。需进行上行数据传输的线缆调制解调器必须首先从 CMTS请求许可。CMTS 随后将该消息与网络上所有其他线缆调制解调器发送的其他类似请求一并处理。CMTS 而后将确定如何向发出请求的线缆调制解调器分配上行通道，并发送消息以便"映射"对进入时间分段的上行使用。
线缆调制解调器可进行的上行传输数量限于每秒数百次。
在 DOCSIS 1.0 中，线缆调制解调器能够在每个上行传输猝发中发送一个数据包。就 TCP 而言--这意味着客户端应用可发送至服务器的 ACK 数量有限。图3显示了从下行接收数据包到向服务器发送确认的周期。
图3：显示数据请求许可传输周期
下面的例子显示了 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标准的线缆调制解调器已在全球得到了广泛部署，使最终用户能够获得始终在线的高带宽因特网连接。由于通过 TCP 可运行最常见的应用，因此我们探索运行在 DOCSIS 数据网络上的 TCP 协议行为就显得非常重要了。
本文概括性地介绍了 TCP 的内在双向性，并就 DOCSIS 协议对 TCP 的影响也进行了讨论。最后，我们还将对提高 TCP 以及利用 TCP 的应用性能提出方案，在线缆调制解调器中嵌入应用感知 (application awareness)。
TCP 特点介绍
TCP 是最常见的因特网应用传输协议，由于其是基于连接的协议，因此能够保证每个从服务器传输的数据包都能到达目的客户端应用。为了保证每个数据包均能到达其目的地，TCP 使用了握手协议 (Handshake Protocol)。服务器与客户端都跟踪正在传输/接收的数据包。
服务器同时向客户端发送数个数据包并等待已接收到数据包的确认。如果在给定时间内确认 (ACK) 未返回至服务器--则服务器将"停机"，并不再发送下一个数据包。如果最终仍不能接收到ACK，那么服务器将重新传输未确认的数据包。服务器等待 ACK 到达前发送的数据包数量取决于"窗口大小"。窗口大小对 TCP 的性能有很大影响--窗口越小，服务器停止传输等待 ACK 到达的几率就越高。。
图1 显示了采用较小窗口大小的“猝发性”传输与较大窗口大小的“更通畅”传输
图 1 显示了从客户端到服务器的 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 随后将从调制解调器收集请求，并发送消息以表明每个调制解调器在上行通道能够发送数据的时间。调制解调器一次只可请求一个传输机会，这就限制了调制解调器每秒钟可执行的上行传输数量。
图 2显示了上下行通道之间的差异。
图2：显示下游通道并列出了其特点；显示上游通道并列出了其特点。
DOCSIS 1.0 线缆调制解调器上的 TCP 性能
DOCSIS 1.0 可支持线缆调制解调器与 CMTS 之间的数据通信。线缆调制解调器平等竞争以利用上行通道。需进行上行数据传输的线缆调制解调器必须首先从 CMTS请求许可。CMTS 随后将该消息与网络上所有其他线缆调制解调器发送的其他类似请求一并处理。CMTS 而后将确定如何向发出请求的线缆调制解调器分配上行通道，并发送消息以便"映射"对进入时间分段的上行使用。
线缆调制解调器可进行的上行传输数量限于每秒数百次。
在 DOCSIS 1.0 中，线缆调制解调器能够在每个上行传输猝发中发送一个数据包。就 TCP 而言--这意味着客户端应用可发送至服务器的 ACK 数量有限。图3显示了从下行接收数据包到向服务器发送确认的周期。
图3：显示数据请求许可传输周期
下面的例子显示了 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标准的线缆调制解调器已在全球得到了广泛部署，使最终用户能够获得始终在线的高带宽因特网连接。由于通过 TCP 可运行最常见的应用，因此我们探索运行在 DOCSIS 数据网络上的 TCP 协议行为就显得非常重要了。
本文概括性地介绍了 TCP 的内在双向性，并就 DOCSIS 协议对 TCP 的影响也进行了讨论。最后，我们还将对提高 TCP 以及利用 TCP 的应用性能提出方案，在线缆调制解调器中嵌入应用感知 (application awareness)。
TCP 特点介绍
TCP 是最常见的因特网应用传输协议，由于其是基于连接的协议，因此能够保证每个从服务器传输的数据包都能到达目的客户端应用。为了保证每个数据包均能到达其目的地，TCP 使用了握手协议 (Handshake Protocol)。服务器与客户端都跟踪正在传输/接收的数据包。
服务器同时向客户端发送数个数据包并等待已接收到数据包的确认。如果在给定时间内确认 (ACK) 未返回至服务器--则服务器将"停机"，并不再发送下一个数据包。如果最终仍不能接收到ACK，那么服务器将重新传输未确认的数据包。服务器等待 ACK 到达前发送的数据包数量取决于"窗口大小"。窗口大小对 TCP 的性能有很大影响--窗口越小，服务器停止传输等待 ACK 到达的几率就越高。。
图1 显示了采用较小窗口大小的“猝发性”传输与较大窗口大小的“更通畅”传输
图 1 显示了从客户端到服务器的 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 随后将从调制解调器收集请求，并发送消息以表明每个调制解调器在上行通道能够发送数据的时间。调制解调器一次只可请求一个传输机会，这就限制了调制解调器每秒钟可执行的上行传输数量。
图 2显示了上下行通道之间的差异。
图2：显示下游通道并列出了其特点；显示上游通道并列出了其特点。
DOCSIS 1.0 线缆调制解调器上的 TCP 性能
DOCSIS 1.0 可支持线缆调制解调器与 CMTS 之间的数据通信。线缆调制解调器平等竞争以利用上行通道。需进行上行数据传输的线缆调制解调器必须首先从 CMTS请求许可。CMTS 随后将该消息与网络上所有其他线缆调制解调器发送的其他类似请求一并处理。CMTS 而后将确定如何向发出请求的线缆调制解调器分配上行通道，并发送消息以便"映射"对进入时间分段的上行使用。
线缆调制解调器可进行的上行传输数量限于每秒数百次。
在 DOCSIS 1.0 中，线缆调制解调器能够在每个上行传输猝发中发送一个数据包。就 TCP 而言--这意味着客户端应用可发送至服务器的 ACK 数量有限。图3显示了从下行接收数据包到向服务器发送确认的周期。
图3：显示数据请求许可传输周期
下面的例子显示了 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 上的数据传输。这些改善包括多服务流、有效负载报头压缩、级连等。
评论