持续创作，加速成长！这是我参与「掘金日新计划 · 10 月更文挑战」的第33天，点击查看活动详情
大家好,我是bug郭,一名双非科班的在校大学生。对C/JAVA、数据结构、Spring系列框架、Linux及MySql、算法等领域感兴趣,喜欢将所学知识写成博客记录下来。 希望该文章对你有所帮助！如果有错误请大佬们指正！共同学习交流
作者简介:
- CSDN java领域新星创作者blog.csdn.net/bug..
- 掘金LV3用户 juejin.cn/user/bug..
- 阿里云社区专家博主,星级博主,developer.aliyun.com/bug..
- 华为云云享专家 bbs.huaweicloud.com/bug..
确认应答
我们刚刚学习32位序号和确认序号时,已经知道TCP由于面向字节流的特点,对传输的数据按照字节顺序进行编号!然后返回确认序号!
如果不对数据进行编号会怎样呢? 当小明发了两条消息给李华时!
这时小明收到"好呀好呀"不知道是啥意思了,因为他发送了两条消息,这是上号还是学习呀,就很迷!
如果我们有确认序号就帮我们解决了这个问题!
小明接收到李华发送的消息,有了确认序号2,表示李华已经接收到了第一条数据,并且给了回应!希望小明发送第二条数据!这就是序号和确认序号的作用!
TCP对每个数据都进行了编号!
每次接收方接收到了数据,就会发生一个ACK确认已经之前的数据已经全部接收到,可以继续发送数据了!
确认应答策略保证了数据传输的可靠性!
超时重传
超时重传相当于对确认应答进行了补充! 我们知道我们网络传输的环境十分复杂,有可能会存在数据丢失丢包的情况,我们此时如何保证数据传输的可靠性呢?
网络正常:
当网络正常没有掉包时,刘备通过张飞发送的"好啊好啊"ACK可以知道张飞已经接收到消息,我们的消息发送成功!
但我们没有接收到ACK时!
当我们没有收到接收方传来的ACK时,我们也不知道是我们的数据丢包了,还是对方的ACK丢包了,这时就无法知道接收方,是否已经接收到了数据!
此时发送方等待了会,没有接收到ACK时会将消息再次发送,这就是超时重传!
可能有人就会说了,那如果是ACK丢了的话,如果我们再次发送一条消息,那消息不就重复了呀?
我们的ACK是在操作系统内核发送的,也就是是说,如果接收方接收到了数据,首先到了接收方操作系统socket的接收缓存队列(阻塞队列)中,然后会记录下接收数据的数据编号,然后将ACK发送个发送方!
如果我们数据丢包了,接收方的接收数缓冲区就没有该数据,会将该数据编号保存,发送一个ACK确认序号!
ACK丢了,发送方再次发送数据到接收方,先到了操作系统内核,然后呢保存到接收缓冲区,发现已经有该数据了,就直接丢弃,就不会再给接收方这个数据了!
这就保证了应用程序调用socketapi拿到的数据不重复!
当网络只是发生抖动,那么超时重传就能保证传输继续!
但是当网络遭受重创,直接卡了网线!
那么无论如何重传也无济于事,那这是发送方就不会一直重传下去了!
并且每次重传的时间间隔会越来越大!
最后停止重传!
这里的每次重传的时间间隔并没有准确的值,也可以自行设置!
