TCP的拥塞控制

如上图所示很好的显示了TCP拥塞控制的算法流程

发送方的发送窗口=min【拥塞窗口,接收端的接收窗口(该窗口可由接收方在交互中动态调整)】

慢开始:

顾名思义,拥塞窗口以2的x次方进行缓慢的增加,但是在几次缓慢的测试后,窗口大小也因为其增长函数的特性在愈加的增大,当窗口增大到ssthresh的时候就会执行拥塞避免算法

拥塞避免:

拥塞避免还是顾名思义就是防止拥塞,为了防止窗口过大而导致的网络拥塞,此时可以看到窗口的上升函数变成了X,较2的x函数来说,增长的速率降低了很多,可以这么理解一开始进行快速的窗口增长,到了一个ssthresh警告值的时候,窗口的增长就不敢在那么离谱了。当拥塞避免模式下窗口进行增大的时候出现了超时重传,就会将拥塞窗口cwnd变为0,同时将sstresh变为发生拥塞窗口时窗口大小的二分之一。然后再进行慢开始和拥塞避免。

只有慢开始和拥塞避免的问题

如果只要慢开始和拥塞避免,那么主要的问题就是仅将出现超时重传作为网络拥塞的判断依据未免太过单薄,有的时候数据的一次两次的超时重传并不能代表整个网络此时的情况。所以就出现了快重传。

快重传

我们在进行传输的的时候一般会一次性传送多个报文,那么假设此时本轮传输报文数量为4个,那么假设第一个报文就出现了错误,快重传约定即使接收到失序报文也要对已接收报文进行确认,即在快重传模式下不能出现累积确认。那么当第一个报文出现错误后,后续的三个报文被对端接收后会发回重复的三个ack,那么发送方就不会重新进行慢开始,而是将当前窗口大小减少一半,然后继续执行拥塞避免的窗口增大,同时还会立即对缺失的报文进行重传。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Mllllk

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值