Net:TCP拥塞控制 - 版本历史

Riguz：/* 慢开始 */

2021-07-13T08:49:47Z

慢开始

←上一版本		2021年7月13日 (二) 08:49的版本
第29行：		第29行：
	;TCP Tahoe:对于TCP Tahoe算法，当发生丢失时，会进入“<span class="article-label">快速重传</span>”机制，慢启动阈值设为之前拥塞窗口值的一半，拥塞窗口值降为初始值，重新进入慢启动阶段。当拥塞窗口值达到慢启动阈值时，每RTT内拥塞窗口增加值则为“MSS除以CWND”的值，所以拥塞窗口按线性速度增加。		;TCP Tahoe:对于TCP Tahoe算法，当发生丢失时，会进入“<span class="article-label">快速重传</span>”机制，慢启动阈值设为之前拥塞窗口值的一半，拥塞窗口值降为初始值，重新进入慢启动阶段。当拥塞窗口值达到慢启动阈值时，每RTT内拥塞窗口增加值则为“MSS除以CWND”的值，所以拥塞窗口按线性速度增加。
	;TCP Reno:TCP Reno算法实现了一个名为“<span class="article-label">快速恢复</span>”的机制，慢启动阈值设为之前拥塞窗口值的一半，和作为新的拥塞窗口值，并跳过慢启动阶段，直接进入拥塞控制阶段。		;TCP Reno:TCP Reno算法实现了一个名为“<span class="article-label">快速恢复</span>”的机制，慢启动阈值设为之前拥塞窗口值的一半，和作为新的拥塞窗口值，并跳过慢启动阶段，直接进入拥塞控制阶段。

			慢启动假设分段的未确认是由于网络拥塞造成的，虽然大部分网络的确如此，但也有其他原因，例如一些链路质量差的网络，会导致分段包丢失。在一些网络环境，例如无线网络，慢启动效率并不好。

			慢启动对于一些短暂的连接性能并不好，一些较旧的网页浏览器会建立大量连续的短暂链接，通过快速开启和关闭链接来请求获得文件，这使得大多数链接处于慢启动模式，导致网页响应时间差。

	==拥塞避免==		==拥塞避免==

Riguz：/* 慢开始 */

2021-07-13T08:45:52Z

慢开始

←上一版本		2021年7月13日 (二) 08:45的版本
第28行：		第28行：

	;TCP Tahoe:对于TCP Tahoe算法，当发生丢失时，会进入“<span class="article-label">快速重传</span>”机制，慢启动阈值设为之前拥塞窗口值的一半，拥塞窗口值降为初始值，重新进入慢启动阶段。当拥塞窗口值达到慢启动阈值时，每RTT内拥塞窗口增加值则为“MSS除以CWND”的值，所以拥塞窗口按线性速度增加。		;TCP Tahoe:对于TCP Tahoe算法，当发生丢失时，会进入“<span class="article-label">快速重传</span>”机制，慢启动阈值设为之前拥塞窗口值的一半，拥塞窗口值降为初始值，重新进入慢启动阶段。当拥塞窗口值达到慢启动阈值时，每RTT内拥塞窗口增加值则为“MSS除以CWND”的值，所以拥塞窗口按线性速度增加。
	T;CP Reno:TCP Reno算法实现了一个名为“<span class="article-label">快速恢复</span>”的机制，慢启动阈值设为之前拥塞窗口值的一半，和作为新的拥塞窗口值，并跳过慢启动阶段，直接进入拥塞控制阶段。		;TCP Reno:TCP Reno算法实现了一个名为“<span class="article-label">快速恢复</span>”的机制，慢启动阈值设为之前拥塞窗口值的一半，和作为新的拥塞窗口值，并跳过慢启动阶段，直接进入拥塞控制阶段。

	==拥塞避免==		==拥塞避免==

Riguz：/* 慢开始 */

2021-07-13T08:45:35Z

慢开始

@@ 第19行： / 第19行： @@
 ==慢开始==
 ==拥塞避免==
 ==快重传==

2021年7月13日 (二) 08:42 Riguz

2021-07-13T08:42:08Z

←上一版本		2021年7月13日 (二) 08:42的版本
第1行：		第1行：
	TCP拥塞控制是传输控制协议（英語：Transmission Control Protocol，縮寫TCP）避免网络拥塞的算法，是互联网上主要的一个拥塞控制措施。它使用一套基于线增积减模式的多样化网络拥塞控制方法（包括慢启动和拥塞窗口等模式）来控制拥塞。在互联网上应用中有相当多的具体实现算法。		TCP拥塞控制是传输控制协议（英語：Transmission Control Protocol，縮寫TCP）避免网络拥塞的算法，是互联网上主要的一个拥塞控制措施。它使用一套基于线增积减模式的多样化网络拥塞控制方法（包括慢启动和拥塞窗口等模式）来控制拥塞。在互联网上应用中有相当多的具体实现算法。

	TCP使用多种拥塞控制策略来避免雪崩式拥塞。TCP会为每条连接维护一个“拥塞窗口”来限制可能在端对端间传输的未确认分组总数量。这类似TCP流量控制机制中使用的滑动窗口。TCP在一个连接初始化或超时后使用一种“慢启动”机制来增加拥塞窗口的大小。它的起始值一般为最大分段大小（Maximum segment size，MSS）的两倍，虽然名为“慢启动”，初始值也相当低，但其增长极快：当每个分段得到确认时，拥塞窗口会增加一个MSS，使得在每次往返时间（round-trip ~~time，RTT）内拥塞窗口能高效地双倍增长。~~		TCP使用多种拥塞控制策略来避免雪崩式拥塞。TCP会为每条连接维护一个“拥塞窗口”来限制可能在端对端间传输的未确认分组总数量。这类似TCP流量控制机制中使用的滑动窗口。TCP在一个连接初始化或超时后使用一种“慢启动”机制来增加拥塞窗口的大小。它的起始值一般为最大分段大小<span class="article-label">（Maximum segment size，MSS）</span>的两倍，虽然名为“慢启动”，初始值也相当低，但其增长极快：当每个分段得到确认时，拥塞窗口会增加一个MSS，使得在每次<span class="article-label">往返时间（round-trip time，RTT）</span>内拥塞窗口能高效地双倍增长。

	当拥塞窗口超过慢启动阈值（ssthresh）时，算法就会进入一个名为“拥塞避免”的阶段。在拥塞避免阶段，只要未收到重复确认，拥塞窗口则在每次往返时间内线性增加一个MSS大小。		当拥塞窗口超过慢启动阈值（ssthresh）时，算法就会进入一个名为“拥塞避免”的阶段。在拥塞避免阶段，只要未收到重复确认，拥塞窗口则在每次往返时间内线性增加一个MSS大小。

Riguz：/* 拥塞窗口 */

2021-07-13T08:40:14Z

拥塞窗口

←上一版本		2021年7月13日 (二) 08:40的版本
第6行：		第6行：

	=拥塞窗口=		=拥塞窗口=
	在TCP中，拥塞窗口（congestion window）是任何时刻内确定能被发送出去的字节数的控制因素之一，是阻止发送方至接收方之间的链路变得拥塞的手段。他是由发送方维护，通过估计链路的拥塞程度计算出来的，与由接收方维护的接收窗口大小并不冲突。		在TCP中，<span class="article-label">拥塞窗口（congestion window）</span>是任何时刻内确定能被发送出去的字节数的控制因素之一，是阻止发送方至接收方之间的链路变得拥塞的手段。他是由发送方维护，通过估计链路的拥塞程度计算出来的，与由接收方维护的接收窗口大小并不冲突。

	当一条连接建立后，每个主机独立维护一个拥塞窗口并设置值为连接所能承受的MSS的最小倍数，之后的变化依靠线增积减机制来控制，这意味如果所有分段到达接收方和确认包准时地回到发送方，拥塞窗口会增加一定数量。该窗口会保持指数增大，直到发生超时或者超过一个称为“慢启动阈值（ssthresh）”的限值。如果发送方到达这个阈值时，每收到一个新确认包，拥塞窗口只按照线性速度增加自身值的倒数。		当一条连接建立后，每个主机独立维护一个拥塞窗口并设置值为连接所能承受的MSS的最小倍数，之后的变化依靠线增积减机制来控制，这意味如果所有分段到达接收方和确认包准时地回到发送方，拥塞窗口会增加一定数量。该窗口会保持指数增大，直到发生超时或者超过一个称为“<span class="article-label">慢启动阈值（ssthresh）</span>”的限值。如果发送方到达这个阈值时，每收到一个新确认包，拥塞窗口只按照线性速度增加自身值的倒数。

	TCP 主要通过四个算法来进行拥塞控制：		TCP 主要通过四个算法来进行拥塞控制：

	慢开始、拥塞避免、快重传、快恢复。		慢开始、拥塞避免、快重传、快恢复。

	=拥塞控制方法=		=拥塞控制方法=

Riguz：/* 快重传 */

2021-07-13T08:38:44Z

快重传

←上一版本		2021年7月13日 (二) 08:38的版本
第25行：		第25行：

	快速重传就是基于以下机制：如果假设重复阈值为3，当发送方收到4次相同确认号的分段确认（第1次收到确认期望序列号，加3次重复的期望序列号确认）时，则可以认为继续发送更高序列号的分段将会被接受方丢弃，而且会无法有序送达。发送方应该忽略超时计时器的等待重发，立即重发重复分段确认中确认号对应序列号的分段。		快速重传就是基于以下机制：如果假设重复阈值为3，当发送方收到4次相同确认号的分段确认（第1次收到确认期望序列号，加3次重复的期望序列号确认）时，则可以认为继续发送更高序列号的分段将会被接受方丢弃，而且会无法有序送达。发送方应该忽略超时计时器的等待重发，立即重发重复分段确认中确认号对应序列号的分段。

			即：

			在接收方，要求每次接收到报文段都应该对最后一个已收到的有序报文段进行确认。例如已经接收到 M1 和 M2，此时收到 M4，应当发送对 M2 的确认。

			在发送方，如果收到三个重复确认，那么可以知道下一个报文段丢失，此时执行快重传，立即重传下一个报文段。例如收到三个 M2，则 M3 丢失，立即重传 M3。

	==快恢复==		==快恢复==

	[[Category:Network]]		[[Category:Network]]

Riguz：/* 拥塞控制方法 */

2021-07-13T06:02:13Z

拥塞控制方法

←上一版本		2021年7月13日 (二) 06:02的版本
第15行：		第15行：
	=拥塞控制方法=		=拥塞控制方法=

	[[Image:TCP-cwnd.jpg\|~~400px~~]]		[[Image:TCP-cwnd.jpg\|600px]]

	==慢开始==		==慢开始==

Riguz：/* 拥塞控制方法 */

2021-07-13T06:01:45Z

拥塞控制方法

←上一版本		2021年7月13日 (二) 06:01的版本
第14行：		第14行：
	慢开始、拥塞避免、快重传、快恢复。		慢开始、拥塞避免、快重传、快恢复。
	=拥塞控制方法=		=拥塞控制方法=

			[[Image:TCP-cwnd.jpg\|400px]]

	==慢开始==		==慢开始==
	==拥塞避免==		==拥塞避免==

Riguz：/* 快重传 */

2021-07-13T06:00:30Z

快重传

←上一版本		2021年7月13日 (二) 06:00的版本
第17行：		第17行：
	==拥塞避免==		==拥塞避免==
	==快重传==		==快重传==
			快速重传（Fast retransmit）是对TCP发送方降低等待重发丢失分段用时的一种改进。TCP发送方每发送一个分段都会启动一个超时计时器，如果没能在特定时间内接收到相应分段的确认，发送方就假设这个分段在网络上丢失了，需要重发。这也是 TCP 用来估计 RTT 的测量方法。

			重复确认（duplicate cumulative acknowledgements，DupAcks）就是这个阶段的基础，其基于以下过程：如果接收方接收到一个数据分段，就会将该分段的序列号加上数据字节长的值，作为分段确认的确认号，发送回发送方，表示期望发送方发送下一个序列号的分段。但是如果接收方提前收到更下一个序列号的分段——或者说接收到无序到达的分段，即之前期望确认号对应的分段出现接收丢失——接收方需要立即使用之前的确认号发送分段确认。此时如果发送方收到接收方相同确认号的分段确认超过1次，并且该对应序列号的分段超时计时器仍没超时的话，则这就是出现重复确认，需要进入快速重传。

			快速重传就是基于以下机制：如果假设重复阈值为3，当发送方收到4次相同确认号的分段确认（第1次收到确认期望序列号，加3次重复的期望序列号确认）时，则可以认为继续发送更高序列号的分段将会被接受方丢弃，而且会无法有序送达。发送方应该忽略超时计时器的等待重发，立即重发重复分段确认中确认号对应序列号的分段。

	==快恢复==		==快恢复==

	[[Category:Network]]		[[Category:Network]]

Riguz：建立內容為「TCP拥塞控制是传输控制协议（英語：Transmission Control Protocol，縮寫TCP）避免网络拥塞的算法，是互联网上主要的一个拥塞控…」的新頁面

2021-07-13T05:56:24Z

建立內容為「TCP拥塞控制是传输控制协议（英語：Transmission Control Protocol，縮寫TCP）避免网络拥塞的算法，是互联网上主要的一个拥塞控…」的新頁面

新页面

TCP拥塞控制是传输控制协议（英語：Transmission Control Protocol，縮寫TCP）避免网络拥塞的算法，是互联网上主要的一个拥塞控制措施。它使用一套基于线增积减模式的多样化网络拥塞控制方法（包括慢启动和拥塞窗口等模式）来控制拥塞。在互联网上应用中有相当多的具体实现算法。

TCP使用多种拥塞控制策略来避免雪崩式拥塞。TCP会为每条连接维护一个“拥塞窗口”来限制可能在端对端间传输的未确认分组总数量。这类似TCP流量控制机制中使用的滑动窗口。TCP在一个连接初始化或超时后使用一种“慢启动”机制来增加拥塞窗口的大小。它的起始值一般为最大分段大小（Maximum segment size，MSS）的两倍，虽然名为“慢启动”，初始值也相当低，但其增长极快：当每个分段得到确认时，拥塞窗口会增加一个MSS，使得在每次往返时间（round-trip time，RTT）内拥塞窗口能高效地双倍增长。

当拥塞窗口超过慢启动阈值（ssthresh）时，算法就会进入一个名为“拥塞避免”的阶段。在拥塞避免阶段，只要未收到重复确认，拥塞窗口则在每次往返时间内线性增加一个MSS大小。

=拥塞窗口=
在TCP中，拥塞窗口（congestion window）是任何时刻内确定能被发送出去的字节数的控制因素之一，是阻止发送方至接收方之间的链路变得拥塞的手段。他是由发送方维护，通过估计链路的拥塞程度计算出来的，与由接收方维护的接收窗口大小并不冲突。

当一条连接建立后，每个主机独立维护一个拥塞窗口并设置值为连接所能承受的MSS的最小倍数，之后的变化依靠线增积减机制来控制，这意味如果所有分段到达接收方和确认包准时地回到发送方，拥塞窗口会增加一定数量。该窗口会保持指数增大，直到发生超时或者超过一个称为“慢启动阈值（ssthresh）”的限值。如果发送方到达这个阈值时，每收到一个新确认包，拥塞窗口只按照线性速度增加自身值的倒数。

TCP 主要通过四个算法来进行拥塞控制：

慢开始、拥塞避免、快重传、快恢复。
=拥塞控制方法=
==慢开始==
==拥塞避免==
==快重传==
==快恢复==

[[Category:Network]]

Net:TCP拥塞控制 - 版本历史

Riguz：​/* 慢开始 */

Riguz：​/* 慢开始 */

Riguz：​/* 慢开始 */

2021年7月13日 (二) 08:42 Riguz

Riguz：​/* 拥塞窗口 */

Riguz：​/* 快重传 */

Riguz：​/* 拥塞控制方法 */

Riguz：​/* 拥塞控制方法 */

Riguz：​/* 快重传 */

Riguz：​建立內容為「TCP拥塞控制是传输控制协议（英語：Transmission Control Protocol，縮寫TCP）避免网络拥塞的算法，是互联网上主要的一个拥塞控…」的新頁面

Riguz：/* 慢开始 */

Riguz：/* 慢开始 */

Riguz：/* 慢开始 */

Riguz：/* 拥塞窗口 */

Riguz：/* 快重传 */

Riguz：/* 拥塞控制方法 */

Riguz：/* 拥塞控制方法 */

Riguz：/* 快重传 */

Riguz：建立內容為「TCP拥塞控制是传输控制协议（英語：Transmission Control Protocol，縮寫TCP）避免网络拥塞的算法，是互联网上主要的一个拥塞控…」的新頁面