Loading [MathJax]/jax/input/TeX/config.js
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >TCP可靠传输,流量控制,拥塞控制是时候一篇搞定了

TCP可靠传输,流量控制,拥塞控制是时候一篇搞定了

作者头像
山月
发布于 2020-05-26 02:57:22
发布于 2020-05-26 02:57:22
2.1K00
代码可运行
举报
运行总次数:0
代码可运行

目录

  • 抓包过程以及TCP包首部
  • 可靠传输
  • 窗口概念引出
    • 接收窗口 rwnd 和发送窗口 cwnd
  • 流量控制
    • 举例来说明具体TCP流量控制过程
  • 拥塞控制
    • 慢开始和拥塞避免算法
    • 快重传和快恢复算法
  • 流量控制和拥塞控制的区别

抓包过程以及TCP包首部

使用了 Wireshark 进行抓包,用两个最常用的 curl 和 ping 命令来演示抓包情况,开启抓包。

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
## 先访问我自己的网站首页
 curl https://zengzhiqin.kuaizhan.com 
## 再查看我自己网站的地址
 ping https://zengzhiqin.kuaizhan.com

Wireshark根据 ping 命令得到的地址进行条件过滤,得到上面两个命令所得到的包,主要有 TCP(https基于tcp协议)协议和 ICMP(ping命令是基于 ICMP 协议)协议的包,如下图所示:

抓包分析

TCP首部数据一一对应

TCP头部

可靠传输

TCP 实现可靠传输的四种实现方法:

  1. 校验
  2. 序号
  3. 确认
  4. 重传

第1,2两种机制,在我公众号另外一篇有详细讲解,这里我主要讲述第3,4种。

可靠传输目的:就是要让发送方发送的所有数据,接收方都能完整,按序收到。

正如宫本武藏的口头禅“排好队,一个一个来”一样,使用最笨的方法来解决最难的问题,既然你要可靠那么就一个一个确认,只要你没告诉我你收到了,那么我就一直重发

可靠传输的工作原理:停止等待协议

可靠与不可靠解决方式

我分为了四张图,竖线代表的是时间轴,RTT代表数据包发过去然后确认包发回来的往返时间,分别是”无差错你好我好大家好的情况下“,”发送超时或者失败“情况下,”确认超时“和”确认丢失“的情况下来分析的。通过这种确认重传机制,TCP就可以实现可靠传输,也就是第3,4点的实现方式。需要知道的一点是,重传这个动作是发送方自发行为,并不需要接收方通知它进行重传。

窗口概念引出

上面的方法,确实不错哈,用了最简单的方法解决了可靠传输这个问题,可是网络时时刻刻那么忙,我等你一来一回的确认宫本武藏一个大招跳出去估计是一节一节的落地了,黄花菜都凉了。

上述停止等待协议最大的问题是信道利用率太低了

停止等待传输

RTT时间是由网络状况决定拯救不了,T2一般也是固定的,由公式可看出,想要提高信道利用率只能从 T1 下手。

流水线传输

发送方可以连续发送多个包,不用每次都停下来等待确认再继续发,将上面这些的连续发送的包用一个窗口来包含起来即TCP窗口的由来,如下图:

滑动窗口

既然你发送方为了不一个一个包发可以有窗口技术,那么我接收方肯定也不甘落后得学起来啊,即不进行一个一个确认,转而累积确认

接收方累积确认方式

接收窗口 rwnd 和发送窗口 cwnd

此处涉及到二个窗口:

  1. 接收窗口receiver window(即rwnd),是接收方根据自己的承受能力设置的接收缓存值大小,反映了接收方的接收能力,来做流量控制
  2. 拥塞窗口congestion window(即cwnd),是发送方根据网络拥塞程度设置的网络窗口值,发送窗口=min(rwnd,cwnd)即是接收窗口和拥塞窗口的最小值,来做拥塞控制

窗口数据结构如下:

窗口数据结构

其实看似这么高深的东西,一步步想过来竟是如此简单,感叹一句”啊,聪明的人类“(调皮一下哈哈哈)。

流量控制

上面说到了通过窗口可以增大信道的利用率,然后就是窗口的大小怎么设置,设置多大,窗口还可以用来做什么?

发送方如果发的过快,那么接收方就会来不及接受,就会丢包,这肯定不行啊,万一别人给我发了很多红包丢一个我都不想哒~

分段传输

流量控制目的:让发送方根据网络状况动态的调整发送频率,好让接收方来得及接收。

TCP利用滑动窗口机制实现流量控制。发送方的发送窗口是动态变化的,取决于接收方返回的报文段的窗口大小,可能是数据报文段也可能是确认报文,因为TCP包首部都有窗口信息,还是这张图再看一下窗口数据:

举例来说明具体TCP流量控制过程

A主机向B主机发送数据,建立连接的时候 B 告诉 A:”大哥,我的rwnd=400byte“,假设每个报文段都是100byte,初始序号是1,三次流量控制沟通过程如下:

这张图,最后 rwnd=0 了,这种情况持续到接收端腾出了新的接收缓存之后 B会主动给 A发送他的新的 rwnd,0窗口通知的时候 A 就会一直等待接收方新的 rwnd 通知,为了防止新的 rwnd 丢失了,之前的文章很多都分析过这种情况,为了解决包超时收不到确认设置了等待一段时间就重传,四次挥手过程设置了最后需要等待 2MSL 时间发送端才关闭,这些时间都是通过设置计时器来计时,都是为了解决包丢失了造成死锁。同样这里为了解决新的 rwnd 丢失了造成 A 死锁发送端只要收到了0窗口通知就会启动计时器,若时间到了就会重新发送一个0窗口探测报文,接收方再回复现在的接收窗口。

拥塞控制

我家小区网络最好的时候是晚上3-6点,上午10-12点,下午3-5点,这些时间段我玩王者最畅快,晚上8-11点网络高峰时段每次卡一下回过神我就站在了泉水(真的好开心)。

试想一下原本网络就不好,然后你还一次性向网络倒那么多数据包,大家都别过去了都超时,然后超时时间到了又都重发,恶性循环下去使得原本就不富裕的网络更加雪上加霜,因此 TCP 你要自己学聪明,进行拥塞控制。拥塞控制的目的就是防止过多的数据注入到网络中,网络堵塞使得包一直到不了接收端。

拥塞控制起到的作用

拥塞控制算法有四种:

  1. 慢开始
  2. 拥塞避免
  3. 快重传
  4. 快恢复

慢开始和拥塞避免算法

慢开始和拥塞避免算法

一个传输轮次指的是发送了一批报文段并且收到了确认的时间 RTT。

慢开始是指数增长,一直试探网络状况如果健康就一直指数增长。到了ssthresh值的时候,这是慢开始轮限值,开始线性增长,一直增长到网络拥塞的话,跳崖式降低一夜回到解放前,从1开始,将新的ssthresh值调低为原来拥塞时候的一半又开始指数增长,就这样动态的变化。

快重传和快恢复算法

快重传和快恢复算法

从图可以看到这个算法前面和慢开始拥塞避免算法是一致的,主要是调整了跳崖式降低发送速率这个地方,这样从0开始效率太低了,如果是男女朋友间在发送微信岂不是被折磨的心痒痒。

拥塞窗口cwnd每次指数增长一次都是在收到了确认报文的情况下增长的,比如A发送1,23,4,5,6这些报文段,2丢失了,1345都收到了那么每次345收到都会给A发送确认1收到了的确认报文,让他发2(这个地方上一篇有提到),这种算法就是在2的超时计时器到期之前收到了三个确认之后就马上重传2,接收方都催着要了哥,后面三个确认包都到了说明网络很好的嘛就是你迷路了,因此进行快速重传还是将新的ssthresh值调低为原来拥塞时候的一半又开始指数增长,现在一般是用这种,上面那种方法由于效率太低了被淘汰了。

流量控制和拥塞控制的区别

流量控制是点到点的问题,一对一,如果接收方的数据来不及接收那么就能直接找到发送方这个罪魁祸首,主要是因为接收方来不及接受发送方的数据

拥塞控制是多对一,一个接收方 面对多个发送方出现了网络拥堵,接收方找不到具体的发送方,主要是因为网络发生了堵塞发送方数据迟迟到不了接收方

简单理解,拥塞控制是路上堵车,流量控制是停车场停车车位不够。

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2020-05-18,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 全栈成长之路 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
你还在为 TCP 重传、滑动窗口、流量控制、拥塞控制发愁吗?看完图解就不愁了
前一篇「硬不硬你说了算!近 40 张图解被问千百遍的 TCP 三次握手和四次挥手面试题」得到了很多读者的认可,在此特别感谢你们的认可,大家都暖暖的。
小林coding
2020/05/18
1.6K1
你还在为 TCP 重传、滑动窗口、流量控制、拥塞控制发愁吗?看完图解就不愁了
tcp流量控制和拥塞控制
说到TCP流量控制和拥塞控制,不得不说一下滑动窗口,TCP流量控制和拥塞控制主要是由滑动窗口来实现的,首先什么是滑动窗口
opencode
2022/12/26
9280
tcp流量控制和拥塞控制
我今天才知道,原来TCP为了保证可靠传输做了这么多
本节内容有点多,不过关于 TCP 的话,除了三四次握手就是可靠传输了,高频重点知识点,大家还是搞清楚比较好。
Java程序猿阿谷
2021/01/14
1.2K0
我今天才知道,原来TCP为了保证可靠传输做了这么多
TCP的拥塞控制_基础知识_四种拥塞控制方法
隐式反馈算法:源点自身通过对网络行为的观察(例如超重传或往返时间RTT)来推断网络是否发生了拥塞。TCP采用的就是隐式反馈算法。
小徐在进步
2024/09/16
9100
TCP的拥塞控制_基础知识_四种拥塞控制方法
浅析 TCP 的流量控制和拥塞控制
在上一篇TCP 滑动窗口原理解析文章中,我们对 TCP 的滑动窗口原理进行一次总结,也提到了流量控制和拥塞控制。
Java极客技术
2023/09/02
7090
浅析 TCP 的流量控制和拥塞控制
TCP 流量控制和拥塞控制
方式1 的问题就是流量控制问题TCP,采用了滑动窗口解决 方式2 的问题说的是拥塞控制问题。
王小明_HIT
2021/04/30
3.2K0
TCP 流量控制和拥塞控制
理解TCP协议三次握手、四次挥手、流量控制、拥塞控制 、重传机制
👨‍💻个人主页: 才疏学浅的木子 🙇‍♂️ 本人也在学习阶段如若发现问题,请告知非常感谢 🙇‍♂️ 📒 本文来自专栏: 计算机网络 🌈 每日一语:真正的勇气是:做出决定,全力以赴! 🌈 TCP协议的理解 TCP概述 TCP报文格式 三次握手 四次挥手 流量控制 拥塞控制 重传机制 超时重传 快速重传 为什么不进行两次握手 为什么关闭连接时客户端会等待2MSL 建立连接后客户端出现故障怎么办 TCP黏包与粘包问题 什么是黏包与粘包 如何解决 TCP概述 TCP是一种面向连接的协议,在发送数据前通信双
才疏学浅的木子
2022/11/20
5640
理解TCP协议三次握手、四次挥手、流量控制、拥塞控制 、重传机制
【编程者必会系列】:TCP/IP之传输层
计算机网络是计算机基础知识的重点,不管你是C++还是JAVA,安卓还是IOS,都必须要会的基础知识。今天学习的就是TCP/IP的传输层知识点总结,很多知识点将来面试中都会问到,值得学习!
张拭心 shixinzhang
2022/11/30
4230
快速了解TCP的流量控制与拥塞控制
数据的传送过程中很可能出现接收方来不及接收的情况,这时就需要对发送方进行控制以免数据丢失。利用滑动窗口机制可以很方便地在TCP连接上对发送方的流量进行控制。TCP的窗口单位是字节,不是报文段,发送方的发送窗口不能超过接收方给出的接收窗口的数值。
全菜工程师小辉
2019/08/16
1.3K0
TCP拥塞控制机制(附面试题)
∑对资源的需求>可用资源 ∑ 对 资 源 的 需 求 > 可 用 资 源 \sum_{}^{} 对资源的需求 >可用资源
全栈程序员站长
2022/09/12
9150
TCP拥塞控制机制(附面试题)
基础知识-网络-TCP滑动窗口,拥塞控制
TCP协议作为一个可靠的面向流的传输协议,其可靠性是由流量控制和滑动窗口协议保证。
BUPTrenyi
2019/07/15
1.2K0
基础知识-网络-TCP滑动窗口,拥塞控制
TCP 协议如何保证可靠传输
  UDP:IP数据报大于1500字节,大于MTU.这个时候发送方IP层就需要分片(fragmentation).把数据报分成若干片,使每一片都小于MTU.而接收方IP层则需要进行数据报的重组.这样就会多做许多事情,而更严重的是,由于UDP的特性,当某一片数据传送中丢失时,接收方便无法重组数据报.将导致丢弃整个UDP数据报.
用户7657330
2020/08/14
3.6K0
TCP 协议如何保证可靠传输
Networks 05 - TCP拥塞控制
如果网络出现拥塞, 那么分组会丢失. 那么如果发送方继续重传, 就会导致网络拥塞程度更高. 因此当网络出现拥塞的时候, 应当控制发送的速率. 这点和流量控制相似, 但是流量控制是为了让接收方能够来得及接收, 拥塞控制是为了降低这个网络的拥塞程度.
Reck Zhang
2021/08/11
3780
【计算机网络】传输层 : TCP 拥塞控制 ( 慢开始 | 拥塞避免 | 快重传 | 快恢复 )
② 拥塞问题发展 : 网络中 资源 供应不足 -> 网络性能降低 -> 网络吞吐量随着负荷增加而降低
韩曙亮
2023/03/28
1.9K0
【计算机网络】传输层 : TCP 拥塞控制 ( 慢开始 | 拥塞避免 | 快重传 | 快恢复 )
斐讯面试记录—TCP滑动窗口及拥塞控制
TCP协议作为一个可靠的面向流的传输协议,其可靠性是由流量控制和滑动窗口协议保证,而拥塞控制则由控制窗口结合一系列的控制算法实现。
翎野君
2023/05/12
3140
斐讯面试记录—TCP滑动窗口及拥塞控制
tcp拥塞控制机制
TCP的拥塞控制主要原理依赖于一个拥塞窗口(cwnd)来控制,TCP还有一个对端通告的接收窗口(rwnd)用于流量控制. 由于需要考虑拥塞控制和流量控制两个方面的内容,因此TCP的真正的发送窗口=min(rwnd, cwnd)。但是rwnd是由对端确定的,网络环境对其没有影响,所以在考虑拥塞的时候我们一般不考虑rwnd的值,我们暂时只讨论如何确定cwnd值的大小.
全栈程序员站长
2022/09/12
1.4K0
tcp拥塞控制机制
面试必考 | TCP 协议(第三弹)—流量控制和拥塞控制
MMS(Maximum Segment Size):TCP一次传输发送的最大数据段长度。
用户3946442
2022/04/11
8430
面试必考 | TCP 协议(第三弹)—流量控制和拥塞控制
TCP协议可靠性是如何保证之 流量控制和拥塞控制
TCP/IP协议是非常重要的一个知识点,也一直是面试的高频题,当面试官问你,能说说TCP协议是怎么保证可靠传输的吗,你能回答上吗?
码农富哥
2020/02/27
2.2K0
TCP协议可靠性是如何保证之 流量控制和拥塞控制
【传输层】TCP、三次握手、四次挥手、可靠传输、TCP拥塞控制、慢开始、拥塞避免、快重传、快恢复
文章目录 TCP------打电话----可靠有序、不丢不重复--------提供全双工-------------发送接收缓存----------面向字节流--------搬砖一样加个头运走 TCP首部格式-----源端口目的端口一共4B-------序号字段(报文第一个字节的序号)--------确认号(期待收到的内容的第一个字节的序号)-------以4B单位 数据偏移--------首部长度--4B为单位-------URG--urgent紧急位--有紧急情况可以插队处理(发送方)---------配
20岁爱吃必胜客
2022/12/30
3310
【传输层】TCP、三次握手、四次挥手、可靠传输、TCP拥塞控制、慢开始、拥塞避免、快重传、快恢复
TCP 和 UDP 的区别及流量控制,拥塞控制,快重传,快恢复算法详解
在上一则文章中,对 TCP 的三次握手建立连接和四次挥手释放连接进行了详细地阐述,本节教程针对于 TCP 的其他内容进行讲解,首先是同处于传输层协议的UDP协议,这两者有什么区别与联系呢?
wenzid
2021/08/13
2.1K0
TCP 和 UDP 的区别及流量控制,拥塞控制,快重传,快恢复算法详解
推荐阅读
相关推荐
你还在为 TCP 重传、滑动窗口、流量控制、拥塞控制发愁吗?看完图解就不愁了
更多 >
交个朋友
加入HAI高性能应用服务器交流群
探索HAI应用新境界 共享实践心得
加入腾讯云技术交流站
洞悉AI新动向 Get大咖技术交流群
加入云原生工作实战群
云原生落地实践 技术难题攻坚探讨
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档