tcp可靠传输的机制有哪些(面试必看
一、综述
1、确认和重传:接收方收到报文就会确认,发送方发送一段时间后没有收到确认就重传。
2、数据校验
3、数据合理分片和排序:
UDP:IP数据报大于1500字节,大于MTU.这个时候发送方IP层就需要分片(fragmentation).把数据报分成若干片,使每一片都小于MTU.而接收方IP层则需要进行数据报的重组.这样就会多做许多事情,而更严重的是,由于UDP的特性,当某一片数据传送中丢失时,接收方便无法重组数据报.将导致丢弃整个UDP数据报.
tcp会按MTU合理分片,接收方会缓存未按序到达的数据,重新排序后再交给应用层。
4、流量控制:当接收方来不及处理发送方的数据,能提示发送方降低发送的速率,防止包丢失。
5、拥塞控制:当网络拥塞时,减少数据的发送。
二、滑动窗口
上面笼统地说了tcp保证可靠传输的机制,下面说说如何用滑动窗口来实现。
为什么要使用滑动窗口
因为发送端希望在收到确认前,继续发送其它报文段。比如说在收到0号报文的确认前还发出了1-3号的报文,这样提高了信道的利用率。但可以想想,0-4发出去后可能要重传,所以需要一个缓冲区维护这些报文,所以就有了窗口。
RTT:往返时间。
窗口是什么
接收窗口:
“接收窗口”大小取决于应用(比如说tomcat:8080端口的监听进程)、系统、硬件的限制。图中,接收窗口是31~50,大小为20。
在接收窗口中,黑色的表示已收到的数据,白色的表示未收到的数据。
当收到窗口左边的数据,如27,则丢弃,因为这部分已经交付给主机;
当收到窗口左边的数据,如52,则丢弃,因为还没轮到它;
当收到已收到的窗口中的数据,如32,丢弃;
当收到未收到的窗口中的数据,如35,缓存在窗口中。
发送窗口:
发送窗口的大小swnd=min(rwnd,cwnd)。rwnd是接收窗口,cwnd用于拥塞控制,暂时可以理解为swnd= rwnd =20。
图中分为四个区段,其中P1到P3是发送窗口。
tips:发送窗口以字节为单位。为了方便画图,图中展示得像以报文为单位一样。但这不影响理解。
三、重传和确认
什么时候发确认:这是一个复杂的策略。我们这里先简单地认为每收到一个报文就发一个确认。
怎么确认(累计确认):
情况1:发送ack=31(为什么这个也要发,这个确认可以用于后面的拥塞控制)
情况2:发送ack=34,并把接收窗口左边缘设置成34,右边缘设置成53
累计确认的好处:情况1中ack=31比描述收到32和33简单;坏处:可能要重传已经接收的数据。
发送方收到确认时怎么处理:
情况1:收到ack=31,什么都不做,或者说继续发送可用窗口中的内容,如42~50
情况2:收到ack=34,发送窗口窗口的左边缘设置成34,右边缘设置成53
什么时候重传:因为每个报文都有超时计数器,超时才重传。超时重传时间的选择也是一个策略。
tcp缓存和窗口的关系:窗口是缓存的一部分。
发送缓存=发送窗口+ P3右边的一部分
接收缓存=接收窗口+部分已确认但主机还没处理完的数据。
四、流量控制
一图流,简单来说就是接收方处理不过来的时候,就把窗口缩小,并把窗口值告诉发送端。
当窗口值为0,而接受方把窗口值恢复(比如ACK=1,ack=601,rwnd=200),但确认丢失,进入相互等待的死锁局面。所以如果窗口值为0,发送端就会开启一个持续计数器,每个一段时间询问一下接收方。
五、拥塞控制
swnd=min(rwnd,cwnd),cwnd就是拥塞窗口大小。
慢开始和拥塞避免
ssthresh:处理拥塞时参照的一个参数。例子中初始值为16,后来变为12。
当cwnd> ssthresh,cwnd以慢开始的方法指数增长;
当cwnd< ssthresh,cwnd以拥塞避免的方法线性增长。
值得注意的几个点
1上图是cwnd随传输轮次的变化,每过一个RTT就算一轮。
2超时就可以认为是拥塞了
快重传和快恢复:上一个算法的加强版
快重传:收到3个同样的确认就立刻重传,不等到超时;
快恢复:cwnd不是从1重新开始。
标签: tcp, 滑动窗口
好文要顶 关注我 收藏该文
浅井光一
关注 - 4
粉丝 - 19
+加关注
1 0
« 上一篇:内存管理
» 下一篇:线程的创建终止和生命周期
posted @ 2016-05-08 19:12 浅井光一 阅读(5517) 评论(0) 编辑 收藏一、综述
1、确认和重传:接收方收到报文就会确认,发送方发送一段时间后没有收到确认就重传。
2、数据校验
3、数据合理分片和排序:
UDP:IP数据报大于1500字节,大于MTU.这个时候发送方IP层就需要分片(fragmentation).把数据报分成若干片,使每一片都小于MTU.而接收方IP层则需要进行数据报的重组.这样就会多做许多事情,而更严重的是,由于UDP的特性,当某一片数据传送中丢失时,接收方便无法重组数据报.将导致丢弃整个UDP数据报.
tcp会按MTU合理分片,接收方会缓存未按序到达的数据,重新排序后再交给应用层。
4、流量控制:当接收方来不及处理发送方的数据,能提示发送方降低发送的速率,防止包丢失。
5、拥塞控制:当网络拥塞时,减少数据的发送。
二、滑动窗口
上面笼统地说了tcp保证可靠传输的机制,下面说说如何用滑动窗口来实现。
为什么要使用滑动窗口
因为发送端希望在收到确认前,继续发送其它报文段。比如说在收到0号报文的确认前还发出了1-3号的报文,这样提高了信道的利用率。但可以想想,0-4发出去后可能要重传,所以需要一个缓冲区维护这些报文,所以就有了窗口。
RTT:往返时间。
窗口是什么
接收窗口:
“接收窗口”大小取决于应用(比如说tomcat:8080端口的监听进程)、系统、硬件的限制。图中,接收窗口是31~50,大小为20。
在接收窗口中,黑色的表示已收到的数据,白色的表示未收到的数据。
当收到窗口左边的数据,如27,则丢弃,因为这部分已经交付给主机;
当收到窗口左边的数据,如52,则丢弃,因为还没轮到它;
当收到已收到的窗口中的数据,如32,丢弃;
当收到未收到的窗口中的数据,如35,缓存在窗口中。
发送窗口:
发送窗口的大小swnd=min(rwnd,cwnd)。rwnd是接收窗口,cwnd用于拥塞控制,暂时可以理解为swnd= rwnd =20。
图中分为四个区段,其中P1到P3是发送窗口。
tips:发送窗口以字节为单位。为了方便画图,图中展示得像以报文为单位一样。但这不影响理解。
三、重传和确认
什么时候发确认:这是一个复杂的策略。我们这里先简单地认为每收到一个报文就发一个确认。
怎么确认(累计确认):
情况1:发送ack=31(为什么这个也要发,这个确认可以用于后面的拥塞控制)
情况2:发送ack=34,并把接收窗口左边缘设置成34,右边缘设置成53
累计确认的好处:情况1中ack=31比描述收到32和33简单;坏处:可能要重传已经接收的数据。
发送方收到确认时怎么处理:
情况1:收到ack=31,什么都不做,或者说继续发送可用窗口中的内容,如42~50
情况2:收到ack=34,发送窗口窗口的左边缘设置成34,右边缘设置成53
什么时候重传:因为每个报文都有超时计数器,超时才重传。超时重传时间的选择也是一个策略。
tcp缓存和窗口的关系:窗口是缓存的一部分。
发送缓存=发送窗口+ P3右边的一部分
接收缓存=接收窗口+部分已确认但主机还没处理完的数据。
四、流量控制
一图流,简单来说就是接收方处理不过来的时候,就把窗口缩小,并把窗口值告诉发送端。
当窗口值为0,而接受方把窗口值恢复(比如ACK=1,ack=601,rwnd=200),但确认丢失,进入相互等待的死锁局面。所以如果窗口值为0,发送端就会开启一个持续计数器,每个一段时间询问一下接收方。
五、拥塞控制
swnd=min(rwnd,cwnd),cwnd就是拥塞窗口大小。
慢开始和拥塞避免
ssthresh:处理拥塞时参照的一个参数。例子中初始值为16,后来变为12。
当cwnd> ssthresh,cwnd以慢开始的方法指数增长;
当cwnd< ssthresh,cwnd以拥塞避免的方法线性增长。
值得注意的几个点
1上图是cwnd随传输轮次的变化,每过一个RTT就算一轮。
2超时就可以认为是拥塞了
快重传和快恢复:上一个算法的加强版
快重传:收到3个同样的确认就立刻重传,不等到超时;
快恢复:cwnd不是从1重新开始。
作者:kexinJiao
链接:https://www.jianshu.com/p/17d0ad2e8fd2
来源:简书
简书著作权归作者所有,任何形式的转载都请联系作者获得授权并注明出处。
tcp可靠传输的机制有哪些(面试必看的更多相关文章
- TCP可靠传输的实现
TCP可靠传输的实现 1.概述 为方便描述可靠传输原理,假定数据传输只在一个方向上进行,即A发送数据,B给出确认 2.以字节为单位的滑动窗口 TCP的滑动窗口是以字节为单位的.为了 ...
- 深入浅出图解【计算机网络】 之 【TCP可靠传输的实现2: 超时重传+拥塞控制】
[前言]上一篇文章介绍了关于TCP的基础知识,以及建立(释放)连接和滑动窗口的概念. 本篇文章将延续上一篇的思路,继续介绍TCP实现可靠传输的机制. 超时重传 上一篇文章里介绍过TCP采用停止等待协议 ...
- TCP可靠传输及流量控制实现原理
一.为什么TCP是可靠传输? 1. 停止等待协议 通过确认与超时重传机制实现可靠传输 在发送完一个分组后,必须暂时保留已发送的分组的副本. 分组和确认分组都必须进行编号. 超时计时器的重传时间应当比数 ...
- 计算机网络概述 传输层 TCP可靠传输的实现
TCP可靠传输的实现 TCP的可靠性表现在:它向应用层提供的数据是 无差错的.有序的.无丢失的,简单的说就是:TCP最终递交给应用层的数据和发送者发送的数据是一模一样的. TCP采用了流量控制.拥塞控 ...
- TCP可靠传输的工作原理
TCP可靠传输的工作原理 一.停止等待协议 1.1.简介 在发送完一个分组后,必须暂时保留已发送的分组的副本. 分组和确认分组都必须进行编号. 超时计时器的重传时间应当比数据在分组传输的平均往返时间更 ...
- TCP 可靠传输与流量控制的实现
TCP 可靠传输与流量控制的实现 一.TCP可靠传输的实现 现在所讲的可靠传输是根据之前所说的可靠传输原理的实现,是现实中应用的技术. 1.1.以字节为单位的滑动窗口 如图A端一份文件分为了多个字节, ...
- TCP可靠传输
1. TCP 可靠性如何保证? 信道可靠:用三次握手.四次挥手保证连接正确: 数据正确:分区编号.校验和.超时重传: 传输控制:流量控制.拥塞控制 2. 重传机制 TCP可靠传输方式是序列号与确认应答 ...
- 计算机网络传输层之TCP可靠传输
文章转自:https://blog.csdn.net/weixin_43914604/article/details/105524592 学习课程:<2019王道考研计算机网络> 学习目的 ...
- 计算机网络(9)-----TCP可靠传输的实现
TCP可靠传输的实现 以字节为单位的滑动窗口 滑动窗口的滑动是以字节为单位的,发送方A和接收方B在TCP三次握手的前两次握手时协商好了发送窗口和接受窗口的大小,发送方A根据B发送来的确认连接报文中标明 ...
随机推荐
- Vue3+Typescript+Node.js实现微信端公众号H5支付(JSAPI v3)教程--各种填坑
----微信支付文档,不得不说,挺乱!(吐槽截止) 功能背景 微信公众号中,点击菜单或者扫码,打开公众号中的H5页面,进行支付. 一.技术栈 前端:Vue:3.0.0,typescript:3.9.3 ...
- 设计模式 - Bridge 桥模式
Bridge桥模式也属于"的单一职责"模式中的典型模式.问题描述:我们绘制图形时,图形可以有不同形状以及不同颜色,比如圆形可以是红的,绿的,方形可以是红的绿的,如果用代码来描绘这些 ...
- sonar-project.propertie分析参数
SonarScanner 是当您的构建系统没有特定扫描仪时使用的扫描仪. 配置您的项目 在你的项目根目录中创建一个名为的配置文件 sonar-project.properties # must be ...
- Less3
继续第三关的学习 1.根据第一关的记录,我们判断出是什么注入 id=1' and '1'='1 id=1' and '1'='2 返回不同,所以存在字符型的注入 2. 这时候我们再用正常的报错猜解准备 ...
- JVM:垃圾收集器与对象的"存活"问题
垃圾收集器垃圾收集(Garbage Collection,GC).当需要排查各种内存溢出.内存泄露问题时,当垃圾收集成为系统更高并发量的瓶颈时,我们需要去了解GC和内存分配. 检查对象的"存 ...
- SQLServer聚集索引导致的插入性能低
1,新表默认会在主键上建立聚集索引.对于非专业DBA, 默认配置在大多数情况下够用. 2,当初为了优化查询速度. 把聚集索引建立在非自增主键的唯一索引列. 数据量上千万后,插入性能开始显现不足. 随着 ...
- jquery正则表达式验证【是否带有小数、是否中文名称组成、是否全由8位数字组成、电话码格式、邮件地址】
1 <form name="myform" action="" onsubmit="return fun1()"> 2 < ...
- Shooting Bricks题解
题目传送门 以后我绝对不会一直磕着一道题磕几个小时了...感觉还是自己节奏出了问题,不知为啥感觉有点小慌... 算了,其实再回头仔细看一下这个题dp的思路还是比较好想出来的,打代码之前一定要做好足够的 ...
- 开发笔记----- python3 小甜点
一.字典内容排序 1.根据 值大小排序,默认reverse=False:从小到大排序,True:从大到小排序.例: >>> dic1 = {'a1':4,'b1':12,'c1':1 ...
- 几个简单的文本处理工具:diff,patch,grep,cut,sort,tr
1:文本处理工具: 1:diff and patch : diff是比较文件或者目录的不同,主要有3个用法: diff file1 file2 :比较file1和file2的不同:diff -u ...