一、综述

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可靠传输的机制有哪些(面试必看的更多相关文章

  1. TCP可靠传输的实现

    TCP可靠传输的实现 1.概述      为方便描述可靠传输原理,假定数据传输只在一个方向上进行,即A发送数据,B给出确认 2.以字节为单位的滑动窗口      TCP的滑动窗口是以字节为单位的.为了 ...

  2. 深入浅出图解【计算机网络】 之 【TCP可靠传输的实现2: 超时重传+拥塞控制】

    [前言]上一篇文章介绍了关于TCP的基础知识,以及建立(释放)连接和滑动窗口的概念. 本篇文章将延续上一篇的思路,继续介绍TCP实现可靠传输的机制. 超时重传 上一篇文章里介绍过TCP采用停止等待协议 ...

  3. TCP可靠传输及流量控制实现原理

    一.为什么TCP是可靠传输? 1. 停止等待协议 通过确认与超时重传机制实现可靠传输 在发送完一个分组后,必须暂时保留已发送的分组的副本. 分组和确认分组都必须进行编号. 超时计时器的重传时间应当比数 ...

  4. 计算机网络概述 传输层 TCP可靠传输的实现

    TCP可靠传输的实现 TCP的可靠性表现在:它向应用层提供的数据是 无差错的.有序的.无丢失的,简单的说就是:TCP最终递交给应用层的数据和发送者发送的数据是一模一样的. TCP采用了流量控制.拥塞控 ...

  5. TCP可靠传输的工作原理

    TCP可靠传输的工作原理 一.停止等待协议 1.1.简介 在发送完一个分组后,必须暂时保留已发送的分组的副本. 分组和确认分组都必须进行编号. 超时计时器的重传时间应当比数据在分组传输的平均往返时间更 ...

  6. TCP 可靠传输与流量控制的实现

    TCP 可靠传输与流量控制的实现 一.TCP可靠传输的实现 现在所讲的可靠传输是根据之前所说的可靠传输原理的实现,是现实中应用的技术. 1.1.以字节为单位的滑动窗口 如图A端一份文件分为了多个字节, ...

  7. TCP可靠传输

    1. TCP 可靠性如何保证? 信道可靠:用三次握手.四次挥手保证连接正确: 数据正确:分区编号.校验和.超时重传: 传输控制:流量控制.拥塞控制 2. 重传机制 TCP可靠传输方式是序列号与确认应答 ...

  8. 计算机网络传输层之TCP可靠传输

    文章转自:https://blog.csdn.net/weixin_43914604/article/details/105524592 学习课程:<2019王道考研计算机网络> 学习目的 ...

  9. 计算机网络(9)-----TCP可靠传输的实现

    TCP可靠传输的实现 以字节为单位的滑动窗口 滑动窗口的滑动是以字节为单位的,发送方A和接收方B在TCP三次握手的前两次握手时协商好了发送窗口和接受窗口的大小,发送方A根据B发送来的确认连接报文中标明 ...

随机推荐

  1. 2021.10.10考试总结[NOIP模拟73]

    T1 小L的疑惑 对于\(P_i\),如果所有比\(P_i\)小的数加起来也达不到\(P_i-1\),那么值域肯定不连续.否则设原来值域最大值为\(mx\),则\(P_i\)会让值域最大值增致\(mx ...

  2. SVN查看项目修改记录及修改内容

    工具/原料 svn 一,查看修改记录 1 选择要查看的文件夹,打开之后在空白的地方右键. 2 选择svn里面的"查看日志".show_Log 3 在弹出的日志框里,可以看到,你可以 ...

  3. binary-tree-preorder-traversal leetcode C++

    Given a binary tree, return the preorder traversal of its nodes' values. For example: Given binary t ...

  4. lvs 四层负载相关

    都打开 /etc/sysctl.conf 中的 net.ip4.ip_forward=1.开启路由转发功能. 分发器 : eth0:192.168.1.66 (VIP) eth1:192.168.2. ...

  5. 基于消息队列 RocketMQ 的大型分布式应用上云最佳实践

    作者|绍舒 审核&校对:岁月.佳佳 编辑&排版:雯燕 前言 消息队列是分布式互联网架构的重要基础设施,在以下场景都有着重要的应用: 应用解耦 削峰填谷 异步通知 分布式事务 大数据处理 ...

  6. $router 和 $route的区别

    router router是VueRouter的一个对象,通过Vue.use(VueRouter)和VueRouter构造函数得到一个router的实例对象,这个对象中是一个全局对象,他包含了所有的路 ...

  7. js中的特数值-null-undefined-NaN

    一.补充 1.js中的三大特殊数据:undefined.null.NaN NaN :非法的数值运算得到的结果 特殊之处: 是一个数值型数据,但不是一个数字 NaN不等于任何值,和任何数据都不相等,Na ...

  8. Spring Ioc 容器初始化过程

    IOC 是如何工作的? 通过 ApplicationContext 创建 Spring 容器,容器读取配置文件 "/beans.xml" 并管理定义的 Bean 实例对象.   通 ...

  9. 【JAVA】笔记(5)--- final;抽象方法;抽象类;接口;解析继承,关联,与实现;

    final: 1.理解:凡是final修饰的东西都具有了不变的特性: 2.修饰对象: 1)final+类--->类无法被继承: 2)final+方法--->方法无法被覆盖: 3)final ...

  10. Hi3516开发笔记(一):海思HI3516DV300芯片介绍,入手开发板以及Demo测试

    前言   目前主流国产芯片为RV11XX.RK33XX.Hi35XX系列,本系列开启Hi3516系列的开发教程.   Hi3516DV300芯片介绍   Hi3516DV300为专业行Smart IP ...