当一个网络经过慢速连接或链接(如拨号线路)链接到另外一个网络时,经过慢速连接的通讯延迟可能会增长。发生此延迟是由于,在通讯中涉及的终端站所知道的速度与实际的慢速连接的速度之间存在差别。慢速连接致使了网络路径中的瓶颈。这只适用于您使用 TCP 时的面向链接的通讯。
若是接收客户机运行在一个相对较快的网络(如 100 Mb/s 以太网)上而且位于一台运行着带有 Internet 链接共享服务的 Windows XP 的计算机后面,而与此接收方通讯的服务器位于快速网络上的远程访问服务后面,则存在不匹配现象。在这种状况下,接收方的接收窗口被设置为较大的值,此值基于接收客户机链接到的连接的速度。发送方开始时以低速率发送,可是,若是数据包没有丢失,发送方最终将发送几乎占满整个窗口的数据包。
这种状况可能会影响跨同一网络的其余 TCP 链接的性能。数据包排在一个可能会很大的队列中,等待经过慢速网络传送出去。若是发生数据包丢失,就必须从新传送数据,这会形成连接拥塞。
此问题的解决方法是,让在网络边缘运行 Internet 链接共享的计算机自动将接收窗口设置为与慢速连接相适应的较小的尺寸。此设置将覆盖接收方指定的设置。此设置不会对通讯产生不利影响,这是由于,设置窗口尺寸时就好像接收方与慢速连接直接相连同样。运行在 Internet 链接共享计算机上的 QoS 数据包调度程序组件执行此窗口调整。web
在 2002 年 1 月以前,不少人还在经过慢速连接链接到 Internet,例如速度为每秒 56 Kb 的链接。尽管连接速度有限制,但不少用户仍要同时运行多个访问网络的程序。例如,用户可能会同时下载、发电子邮件、聊天甚至使用音频或视频流。这些程序大部分使用 TCP 做为基本传输协议,每一个程序都使用其本身的链接。
第一个使用连接的程序以独占方式使用连接,直到链接达到一种稳定状态。稳定状态致使传输的数据占满整个 TCP 窗口。当下一个程序开始传输数据时,它使用的链接受慢启动算法的制约,此算法限制能够传输的未确认数据的数量。因为已创建的程序正在传输必定数量的数据,所以第二个程序达到稳定状态所需的时间要长得多,而且一样大小的数据传输速度会慢得多。
Windows XP 在慢速连接上运行时执行一种“不足额循环 (DRR)”合理分配方案。Windows 2000 也使用了此方案。在 Windows XP 中,当检测到慢速连接时,将默认打开此方案。此方案分配若干数据流,并为这些流分配新的应用程序数据流。这些数据流以循环方式获得服务。此配置为网络通讯提供了较好的响应速度和性能,并且不要求手动配置。算法
像在 Windows 2000 中同样,程序能够经过 Windows XP 中的 QoS API 利用 QoS。全部程序能够共享百分之百的网络带宽,除非有某一程序特别要求带宽优先权。其余程序也可使用此“保留”的带宽,但请求此带宽的程序正在发送数据时除外。默认状况下,程序在终端计算机的每个接口上能够预留基本连接速度的 20% 的聚合带宽。若是保留带宽的程序发送的数据量没有彻底用完带宽,则保留带宽的未用部分可用于同一主机上的其余数据流。
有关 QoS 数据包调度程序的更多信息,请参考 Windows XP 帮助。Windows 2000 技术库提供了有关 Windows 2000 QoS 的其余信息。windows