rfc2914.txt

很多RFC的中文文档

[RFC793]    Postel, J., "传输控制协议", STD 7, RFC 793, September 1981.

[RFC896]     Nagle, J., "在IP/TCP中的拥塞控制", RFC 896, January 1984.

[RFC1122]    Braden, R., Ed., "网络主机的需求-通信层", STD 3, RFC 1122, October 1989.

[RFC1323]    Jacobson, V., Braden, R. and D. Borman, "TCP高性能的扩展", RFC 1323, May      1992.

[RFC2119]   Bradner, S., "在RFCs中标志需求层次的关键字", BCP 14, RFC 2119, March 1997.

[RFC2212]    Shenker, S., Partridge, C. and R. Guerin, "保证服务质量的说明", RFC 2212, September 1997.

[RFC2309]    Braden, R., Clark, D., Crowcroft, J., Davie, B.,
                Deering, S., Estrin, D., Floyd, S., Jacobson, V.,
                Minshall, G., Partridge, C., Peterson, L., Ramakrishnan,
                K.K., Shenker, S., Wroclawski, J., and L. Zhang,
"网络中队列管理和避免拥塞的建议", RFC 2309, April 1998.

[RFC2357]    Mankin, A., Romanow, A., Bradner, S. and V. Paxson,
                "评估可靠的多路传输和应用协议的IETF准则", RFC 2357, June
                1998.

[RFC2414]    Allman, M., Floyd, S. and C. Partridge, "增加中的TCP的初始化窗口", RFC 2414, September 1998.

[RFC2475]    Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.
                and W.  Weiss, "区分服务的体系结构", RFC 2475, December 1998.

[RFC2481]    Ramakrishnan K. and S. Floyd, "添加明确拥塞通告到IP的建议", RFC 2481,
                January 1999.


[RFC2525]    Paxson, V., Allman, M., Dawson, S., Fenner, W., Griner,
                J., Heavens, I., Lahey, K., Semke, J. and B. Volz,
                "有名的TCP应用问题", RFC 2525, March
                1999.

[RFC2581]    Allman, M., Paxson, V. and W. Stevens, "TCP拥塞控制", RFC 2581, April 1999.

[RFC2582]    Floyd, S. and T. Henderson, "TCP的快速修复算法的新的修改", RFC 2582, April 1999.

[RFC2616]    Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P. and T. Berners-Lee, "超文本传输协议 -- HTTP/1.1", RFC 2616, June 1999.

[SCWA99]     S. Savage, N. Cardwell, D. Wetherall, and T. Anderson,
                一个错误行动的接收方的TCP 拥塞控制, ACM
                Computer Communications Review, October 1999.

[TCPB98]     Hari Balakrishnan, Venkata N. Padmanabhan, Srinivasan
Seshan, Mark Stemm, and Randy H. Katz, 一个繁忙的网络服务器的TCP行为:分析和改进, IEEE Infocom, March 1998.  Available from:
               "http://www.cs.berkeley.edu/~hari/papers/infocom98.ps.gz".

[TCPF98]     Dong Lin and H.T. Kung, TCP快速修复策略:分析和改进, IEEE Infocom, March 1998. Available from:
               "http://www.eecs.harvard.edu/networking/papers/infocom- tcp-final-198.pdf".

9.TCP要说明的问题
在这部分我们将讨论TCP拥塞的特殊情况，来阐释拥塞控制原理的实现，包括加入到传输协议产品的一些细节。

9.1慢启动
TCP发送方不能通过一次性发送一个很大的数据（例如接收方建议的窗口）来打开一个新的连接。TCP发送方对拥塞窗口的初始值有限制。在慢启动过程中TCP发送方能通过在一个循环周期把两个因素并为一个来提高发送速率。当监测到拥塞或发送方的拥塞窗口比慢启动的临界值大的时候慢启动就结束了。
全局拥塞控制的潜在影响的问题已经被标准化进程鲜明的提出来了，其中包括初始窗口值的增加[参见RFC2414,RFC2581]。
标准化进程提出的问题一般被认为不需要标准化，包括基于速率的步进方式的使用与否，在拥塞窗口到达临界值之前提早结束慢启动的机制。这个机制使得慢启动或多或少比标准的TCP显得保守。
9.2加法式的增加，乘法式的降低
没有拥塞时TCP发送方通过每个循环周期加一个包来增加拥塞窗口。出现拥塞现象时，TCP发送方折半减少拥塞窗口。（更准确地说，新的拥塞窗口是拥塞窗口最小值和接收方建议的窗口的一半）。
全局拥塞控制的潜在影响的问题已经被标准化进程鲜明的提出来了，其中包括对‘纯响应‘的流的返回进行拥塞控制的额外的建议。
一个标准化进程没有提出一般被认为不需要标准化的问题，包括拥塞窗口的改变应用在字节数的上界继续在管道中的情况下，而不是应用在确认后滑动窗口启动的情况下。（很明显，接收方推荐的窗口应用在确认后滑动窗口启动。因为从确认方接收的包被放置在TCP接收方的缓存中，还没有传给应用程序。然而，拥塞窗口随管道中的包的数量而变化，不需要包括被TCP接收方在无序方式下接收的包。）

9.3重传定时器
TCP发送方设置一个重传定时器来告知网络中一个包已被丢弃。当重传定时器到时了，发送方得知已经有包丢失，把当前的窗口设为原先的一半，开始慢启动，重传丢失的包。如果重传定时器因为重传的包没有被接收到的确认而到时，重传定时器也‘回退‘，把下次重传的时间间隔加倍。
标准化进程很有可能鲜明提出这么一个问题，它潜在的影响全局的拥塞控制，它包括当发送方没有受到确认而事实上并没有包被丢弃时，如何使得重传定时器增加重传时间间隔的修正机制。因为重传定时器到时会导致增加数据包在拥塞链路上不必要的传送，所以网络标准化进程对此非常关注。

9.4快速重传和快速修复
当看到三个重复的确认，TCP发送方知道有包丢失。接着TCP发送方把临界值设为当前窗口的一半，减少拥塞窗口到先前的一半，并重传丢失的包。
标准化进程很有可能鲜明提出这么一个问题，它潜在的影响全局的拥塞控制，它包括当只有一两个重复确认就告知有包丢失的建议。如果设计不好的话，这个建议可能导致增加包在拥塞路径上不必要的传输。
一个标准化进程没有提出，一般被认为不需要标准化的问题，是建议如果拥塞窗口允许的话，发送一个‘新‘的或丢失的包来响应重复确认。举个例子，如果只有一个重复确认，没有更多的确认到达，则发送一个新的包响应，来保持‘响应时钟‘运转。这个建议是一个有益的改变，它不涉及到互操作，也不影响全局拥塞控制，因此不需要IETF标准化进程的介入，就被开发商们所应用。（这个问题事实上已经在[DMKM00]中提过，[DMKM00]建议“研究人员试图收到重复确认后在网络中插入新的通信，[TCPB98]和[TCPF98]都讲述过。）

9.5TCP拥塞控制的其它方面
TCP拥塞控制的其它方面在上面的章节中都没有提到，其中包括空闲或有限制的应用的时期的TCP修复[参见HPF00].

10.安全考虑
本文档已经讨论了拥塞控制的危险和拥塞控制的缺乏。章节3.2讨论了如果相互竞争的流不使用兼容的拥塞控制机制而潜在的不公平性，章节5考虑了如果流不使用端到端的拥塞控制而出现拥塞崩溃的危险。
因为本文档没有提出任何特殊的拥塞控制机制，所以也不需要提供拥塞控制相应的安全措施。然而，我们将注意针对拥塞控制的安全性考虑，IETF文档还有很广阔的范围。例如，单独拥塞控制机制试图解决单独的终节点之间的端到端拥塞控制很有活力[参见SCWA99]。要特别关注多路拥塞控制，因为通信的分布很难掌握，并且单个接收方出现错误后报告拥塞的几率很高。
RFC2309也讨论了网络中无响应的流的潜在威胁，就是流在出现拥塞时不减少发送速率，并且描述了网络需要用来处理流对拥塞通告无响应的机制。我们将注意到这些领域在研究，工程，方法，配置的需要。因为网络有数量众多的流，一些单个流的拥塞控制的危险有一定的限度。相反，分散的危险来自许多终端节点的端到端的拥塞控制的广泛的配置。


RFC2914   Internet RFC/STD/FYI/BCP Archives 
RFC2914  拥塞控制原理

RFC文档中文翻译计划                                                                      - 1 -