上篇bolg中我们介绍了TCP协议的“面向连接”,仔细分析了其中“三次握手建立连接,四次挥手断开连接”,着重介绍了标识符和各个阶段的状态:这里附上链接:TCP协议(面向连接)基础概念详解
讨论完面向连接后,我们进入下个知识点
可靠传输
1,TCP协议中,可靠传输:确保数据可以安全的达到对端,并且可以有序交付
为了满足“传输数据可靠”,首先从数据简单的收发过程中,设置了如下“”功能“(设计思想)”
(1)面向连接——确保通信双方都具有数据传输的能力,即均具有数据的收,发功能
(2)确认应答机制:每一条发送的数据都需要接收方确认收到进行回复,发送端收到回复后认为数据安全到达
(3)超时重传机制:当等待一定的时间后都没有收到接收端的回复,发送端认为数据可能丢失了,对这条数据进行重新发送
(4)对数据进行包序管理:
$.实现:基于协议字段中的序号和确认序号实现
$.在三次握手过程中,双方告诉对方自己的起始序号
$.协议字段中的序号:告知对端本条数据的起始序号
$.确认序号:接收方告诉发送方,确认序号之前的数据都已经收到了,下次就从这个确认序号开始发送新数据
数据不一定会有序到达,但是接收方会根据“序号”进行数据排序,保证有序交付
(5)数据一致性校验:基于协议字段中的校验和字段时间,倘若不一致则要求重传(确保数据的收发是一条数据)
————————————————————————————
同样,为了更好的保证数据传输可靠,也设计了多种机制来辅助实现:
(1)避免丢包机制:
问题:发送方发送数据过快,接受方来不及处理,TCP接受数据缓冲区产生溢出,数据没有存放的空间直接丢包,造成数据丢失。
解决方法:滑动窗口机制 + 流量控制
(2)滑动窗口机制
滑动窗口机制:接收方每次收到数据后,就会根据协议字段中的窗口大小字段来告诉发送方最多继续发送多少数据,当窗口大小为0时表示不需要再发送数据了
必要条件:保证协议字段中的窗口大小值 <= 当前缓冲区中的剩余空间大小
注:在三次握手过程中会协商一个MSS(代表最大数据段大小,即一条报文中的最大数据大小),每次发送数据时,会告诉接收方自己的win(窗口大小)
注:我们需要发送的信息量被MSS分开发送,期间使用了包序管理等等确认数据传输过程无误,为了数据传输尽量不产生数据丢失,匹配接收方的数据处理能力,引入滑动窗口机制
注:滑动窗口的移动:通过序号管理,基于发送窗口的后沿序号和发送窗口的前沿序号(差值为窗口大小),接收窗口的前沿序号和后沿序号(差值为接收窗口大小)
必要条件二:发送窗口大小 <= 接收窗口大小 | 接收窗口大小 <= 缓冲区剩余空间大小
发送窗口后沿序号:先发送的数据序号,发送后被回复将像后移动
发送窗口的前沿序号:后发送的数据序号,根据必要条件二进行移动满足条件
接收窗口的后沿序号:待先取出的数据序号,最开始为缓冲区起始位置,取出数据后沿移动
接收窗口的前沿序号:最后要取出的数据序号,根据必要条件二进行移动

滑动窗口机制中的协议
(1)停等协议:每一条数据收到回复后才传输下一条数据(适用:网络极差环境)
(2)回退n步协议:从丢包位置开始,往后的数据均进行重新传输(不管后面数据是否已经收到了响应的回复)(适用:网络环境一般的情况)
(3)选择重传协议:丢包数据单个重传(适用:网络情况较好的情况)
拥塞机制
处理问题:开始发送数据时,不能知道当前网络环境,当网络环境比较差的时候,依旧发送大量数据,造成数据丢失,要求重传
机制作用:最开始缓慢发送数据,用于网络探测,当网络环境较好时,数据传输速度以近乎指数级进行传输,直到到达阈值(:窗口大小),传输过程中发现网络变差立刻重新开始探测,数据再次以缓慢的传输速率传输

————————————————————————————
到这里我们发现,这么多机制,好像都在耽搁着TCP数据的发送,看起来繁琐复杂,
我们为了在足够安全的条件下尽量肯可能的挽回损失的性能,我们也提出了一些相应的机制:
(1)快速重传机制:
问题:任意一条数据丢失,发送方通常会等到超时才会重传,效率不高(等待超时的时间比较长)
机制:当后面数据被回复,确认接收端收到数据后,前面数据还没有收到,则立即对前面数据进行重传(这里连续发送三次,发送方发送三次重传请求,才可以对数据进行重穿(这是为了避免前面数据只是延迟到达而不是丢失))
捎带应答机制
接收方会对每一次收到的数据进行确认回复,但是每一条数据确认回复都只是报头中的一些信息(甚至可能回复的就是一个单纯的TCP报头)
那么我们如果在进行确认回复的时候,正好有数据需要发送給对方,那么将二者结合起来就可以节省时间了
延迟应答机制
问题:在前面的滑动窗口机制中,滑动窗口的大小可能是一直变化的,那么对于缓冲区中的接收窗口来说,也是不断变化的,这几影响到对数据的吞吐量,并且由于数据大概率没有从缓冲区取出,接收窗口随着发送窗口大小调节变小,造成吞吐量变小,效率降低
机制:收到数据后,延迟一小会,多给上层取出数据的机会,上层取出,窗口大小可保持不变,就可以保证一个相对稳定的大的传输吞吐量
————————————————————————————
至此,关于“可靠传输解释基本完毕”
感谢观看,还有批评指正

©著作权归作者所有:来自51CTO博客作者菜菜变大佬的原创作品,如需转载,请注明出处,否则将追究法律责任

更多相关文章

  1. 强大:MyBatis 流式查询
  2. Python学习系列之七大数据类型
  3. 初识 PHP 运行原理及数据类型
  4. CV学习笔记(十九):文本数据集生成(text_renderer)
  5. CV学习笔记(二十):数据集拼接生成
  6. CV学习笔记(二十五):数据集标注与制作
  7. CV学习笔记(二十七):Python Base64 格式图片上传
  8. 数据结构与算法—小白也能搞懂二叉排序(查找)树
  9. 数据结构与算法—队列(搞懂最常用数据结构之一)

随机推荐

  1. Android是什么 之三-------手机之硬件形
  2. android kernel 初始化 1
  3. Android 6.0棉花糖新特性,
  4. android TextView 走马灯效果
  5. Android api,Android SDK
  6. android后台进程隐藏手段
  7. ch026 Android Socket
  8. Uyghur Android
  9. android的布局练习
  10. Fragment 中的onConfigurationChanged 在