TCP确认保证可靠性(确认应答,超时重传,窗口控制,快速重传)

众所周知,可靠是TCP的一个特点,那么在这个过程中如何确保TCP的可靠性呢?

TCP确保可靠性的途径:

一、确认应答,超时重传,序列号

数据到达接收方,接收方需要给发送方发送一个确认应答,表示该数据段表示已经收到。

确认序号会表明下一次接收数据的序列号。

如果发送方长时间没有接收到确认应答,那么一种可能是数据丢失,另一种可能就是确认应答丢失,这时发送端就会等待一段时间进行重传。这个等待的时间是2*报文往返时间+偏差值。(发送端每发一个数据包时把那个数据包放入重发队列,如果等到确认应答就把数据包从重发队列删除,超时则重传过去)

二、窗口控制和快速重传

1.为什么进行窗口控制?

在没有窗口控制之前,TCP以一个字段进行传输,然后每发一个段就要进行一次确认应答,确认以后以后才开始进行新的数据传输,虽然保证的可靠性,但是缺点就是大大降低了传输的速度。然后TCP就引入了“窗口”这个概念。确认不再以一个字段为单位进行确认,而是以更大的单位也就是窗口的大小进行确认。这样发送端就不会发一个段就开始确认,而是可继续发送。

还有就是在这个过程中可能出现数据收到了,但是给发送方发的确认应答丢失的情况。这种时候从逻辑上讲是不需要进行重传的,但怎么区分到达是数据丢了还是应答丢了,发还是不发?

窗口控制可以解决这个问题:首先窗口发现没收到应答不会立刻给接收端重发;而是收到接收端的3次应答才会进行重传。因为接收端没有收到数据时会一直告诉发送端它没收到会一直发,但是接收端收到数据只会给一次应答。这样一来是不是就可以区分是没收到应答还是没收到数据的情况了。

2.什么是窗口大小?

窗口大小就是无需等待就可以进行发送的段的最大值。

比如:一个窗口的大小是4,就可以连续发送4个段然后开始等待应答确认;然后收到确认应答以后窗口就会移动到下4个字段。这个窗口也被形象的描述为“滑动窗口”。

3、拥塞控制

有了TCP的窗口控制以后我们知道TCP发送的时候不再以一个字段为单位而是以窗口大小为单位,那么如果我们把窗口大小一开始定的太大那么就很可能会导致网络堵塞甚至导致网络瘫痪。为了避免这种情况就引入了慢启动的机制对数据量进行控制

 ①慢启动:讲拥塞窗口大小定义为1;之后每次收到一次确认应答将窗口大小*2。直到窗口大小到达慢启动阈值后不进行*2,而是+1;

 ②慢启动阈值:设定窗口大小值的一条分界线,到达这个分界线会窗口大小执行+1操作,一般的窗口阈值为65536.

 ③拥塞避免:当发生拥塞时(超时重传就是一种拥塞)把慢启动阈值定为以前的一半,然后把拥塞窗口再次定义为1,再以*2进行增长。

例如:慢启动阈值为10,拥塞窗口为1;然后进行传输,当收到确认应答后窗口大小为2,然后再次收到应答后变成4,再收到变为8,然后变为16,这时候超过阈值了,没有堵塞就执行+1,变为17,然后现在拥塞了,我们就把慢启动阈值的10变为5,然后拥塞窗口重新置成1;再次进行上述操作。

4、快速重传

在遇到3次重复确认应答(高速重发控制)时,代表收到了3个报文段,但是这之前的1个段丢失了,便对它进行立即重传。

然后,先将阈值设为当前窗口大小的一半,然后将拥塞窗口大小设为慢启动阈值+3的大小。

这样可以达到:在TCP通信时,网络吞吐量呈现逐渐的上升,并且随着拥堵来降低吞吐量,再进入慢慢上升的过程,网络不会轻易的发生瘫痪。

 

 

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值