Net:TCP拥塞控制:修订间差异
无编辑摘要 |
|||
第19行: | 第19行: | ||
==慢开始== | ==慢开始== | ||
慢启动(Slow-start)是用于结合其他阶段算法,来避免发送过多数据到网络中而导致网络拥塞,算法在RFC 5681中定义。 | |||
* 慢启动初始启动时设置拥塞窗口值(cwnd)为1、2、4或10个MSS。拥塞窗口在每接收到一个确认包时增加,每个RTT内成倍增加, | |||
* 发送速率随着慢启动的进行而增加,直到遇到出现丢失、达到慢启动阈值(ssthresh)、或者接收方的接收窗口进行限制。 | |||
* 当达到慢启动阈值(ssthresh)时,慢启动算法就会转换为线性增长的阶段,算法控制每个RTT内拥塞窗口只增加1个分段量。 | |||
对于处理报文丢失这个事件上,不同拥塞控制算法表现有所不同: | |||
;TCP Tahoe:对于TCP Tahoe算法,当发生丢失时,会进入“<span class="article-label">快速重传</span>”机制,慢启动阈值设为之前拥塞窗口值的一半,拥塞窗口值降为初始值,重新进入慢启动阶段。当拥塞窗口值达到慢启动阈值时,每RTT内拥塞窗口增加值则为“MSS除以CWND”的值,所以拥塞窗口按线性速度增加。 | |||
T;CP Reno:TCP Reno算法实现了一个名为“<span class="article-label">快速恢复</span>”的机制,慢启动阈值设为之前拥塞窗口值的一半,和作为新的拥塞窗口值,并跳过慢启动阶段,直接进入拥塞控制阶段。 | |||
==拥塞避免== | ==拥塞避免== | ||
==快重传== | ==快重传== |
2021年7月13日 (二) 08:45的版本
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 主要通过四个算法来进行拥塞控制:
慢开始、拥塞避免、快重传、快恢复。
拥塞控制方法
慢开始
慢启动(Slow-start)是用于结合其他阶段算法,来避免发送过多数据到网络中而导致网络拥塞,算法在RFC 5681中定义。
- 慢启动初始启动时设置拥塞窗口值(cwnd)为1、2、4或10个MSS。拥塞窗口在每接收到一个确认包时增加,每个RTT内成倍增加,
- 发送速率随着慢启动的进行而增加,直到遇到出现丢失、达到慢启动阈值(ssthresh)、或者接收方的接收窗口进行限制。
- 当达到慢启动阈值(ssthresh)时,慢启动算法就会转换为线性增长的阶段,算法控制每个RTT内拥塞窗口只增加1个分段量。
对于处理报文丢失这个事件上,不同拥塞控制算法表现有所不同:
- TCP Tahoe
- 对于TCP Tahoe算法,当发生丢失时,会进入“快速重传”机制,慢启动阈值设为之前拥塞窗口值的一半,拥塞窗口值降为初始值,重新进入慢启动阶段。当拥塞窗口值达到慢启动阈值时,每RTT内拥塞窗口增加值则为“MSS除以CWND”的值,所以拥塞窗口按线性速度增加。
T;CP Reno:TCP Reno算法实现了一个名为“快速恢复”的机制,慢启动阈值设为之前拥塞窗口值的一半,和作为新的拥塞窗口值,并跳过慢启动阶段,直接进入拥塞控制阶段。
拥塞避免
快重传
快速重传(Fast retransmit)是对TCP发送方降低等待重发丢失分段用时的一种改进。TCP发送方每发送一个分段都会启动一个超时计时器,如果没能在特定时间内接收到相应分段的确认,发送方就假设这个分段在网络上丢失了,需要重发。这也是 TCP 用来估计 RTT 的测量方法。
重复确认(duplicate cumulative acknowledgements,DupAcks)就是这个阶段的基础,其基于以下过程:如果接收方接收到一个数据分段,就会将该分段的序列号加上数据字节长的值,作为分段确认的确认号,发送回发送方,表示期望发送方发送下一个序列号的分段。但是如果接收方提前收到更下一个序列号的分段——或者说接收到无序到达的分段,即之前期望确认号对应的分段出现接收丢失——接收方需要立即使用之前的确认号发送分段确认。此时如果发送方收到接收方相同确认号的分段确认超过1次,并且该对应序列号的分段超时计时器仍没超时的话,则这就是出现重复确认,需要进入快速重传。
快速重传就是基于以下机制:如果假设重复阈值为3,当发送方收到4次相同确认号的分段确认(第1次收到确认期望序列号,加3次重复的期望序列号确认)时,则可以认为继续发送更高序列号的分段将会被接受方丢弃,而且会无法有序送达。发送方应该忽略超时计时器的等待重发,立即重发重复分段确认中确认号对应序列号的分段。
即:
在接收方,要求每次接收到报文段都应该对最后一个已收到的有序报文段进行确认。例如已经接收到 M1 和 M2,此时收到 M4,应当发送对 M2 的确认。
在发送方,如果收到三个重复确认,那么可以知道下一个报文段丢失,此时执行快重传,立即重传下一个报文段。例如收到三个 M2,则 M3 丢失,立即重传 M3。