音视频学习笔记——TCP网络原理

✊✊✊🌈大家好!本篇文章主要记录自己在进行音视频学习中,整理的包括可靠传输、流量控制、拥塞控制等部分TCP网络原理相关的内容重点😇。


本专栏知识点是通过<零声教育>的音视频流媒体高级开发课程进行系统学习,按照学习重点梳理总结后写下文章,对音视频相关内容感兴趣的读者,可以点击观看课程网址:零声教育


1. TCP的可靠传输

TCP连接的两个端口都有两个窗口

  • 发送窗口:准备发送的数据和已发送但未接收的数据

  • 接收窗口:按序接收但没有上交的数据,不按序接收的数据。
    在这里插入图片描述

  • P3 - P1 = A的发送窗口(又称为通知窗口)

  • P2 - P1 = 已发送但尚未收到确认的字节数

  • P3 - P2 = 允许发送但尚未发送的字节数(又称为可用窗口)

  1. 发送窗口按序发送窗口中的字节流,如果发送且收到确认则滑出窗口。如果已发送但未收到确 认则留在发送窗口中用来准备重传。
  2. 接收窗口将按序接收字节流如果收到的字节流无序则仍然会留在接收窗口中。

2. TCP的流量控制

2.1 流量控制(滑动窗口)

在网络通信中,我们都会希望数据的传输效率更高一些,让通信更加流畅。但是,如果发送方的发送速率太快,可能会导致接收方来不及接收和处理数据。所以需要一种机制控制发送方的传输速率——滑动窗口

注意,流量控制是一种接收方针对发送方来讲的机制。

流量控制过程中:

  • 发送方:一次发送的字节数量不要太多,要让对方来的及接收。
  • 接收方:通过调整滑动窗口来进行流量控制的。
    在这里插入图片描述

现在我们假定数据流向是单向的,也就是说实例A只负责发送数据,不负责处理和接受数据,实例B只负责处理和接收数据,并且对接收到的数据进行应答(ACK)。B的接收窗口大小(Rwnd设置为400)。

假定A每次会发送TCP报文段包含数据100字节,并且A将自己发送窗口大小设置为400字节

  1. A向B连续发送3个TCP报文段,每一个报文段都包含了100字节的数据,其中第3个TCP报文段因某种网络原因丢失
  2. B向A发送回复报文ACK=201,Rwnd=300。表示已经接收到1~200字节的数据,下一次从201字节开始发送就行,并表示自己现在能接受300字节
  3. A收到了来自B的回复报文,了解到B的接收窗口大小(Rwnd)为300,因为没有收到201-300的确认报文,因此此时滑动窗口的位置是201-500,并且发送301-400和401-500的TCP报文段给B。
  4. 当201-300的报文段的超时重传计时器到达时,A重新发送201-300的TCP报文段给B。
  5. A收到了B成功收到401的报文,下一次要从501开始发,而且又进行了一次流量控制rwnd = 100(还能接收100字节的数据)。
  6. 然后A又继续发送了一个序号为501的报文,然后A停止发送。然后收到了B返回的回复序号为601滑动窗口置为0的报文。

2.2 死锁问题

接上一小节,A需一直等待,直到B新发送的接收窗口大小更新的数据(rwnd > 0)才能继续发送数据。
终于,B意图向A更新自己的rwnd,但是因为网络原因,更新报文段丢失了。此时会出现死锁局面,即A在等待B的rwnd,B在等待A的新数据

解决方案:
设置A在收到B的0接收窗口大小(rwnd=0)时会自动启动一个“持续计时器”,当持续计时器timeout时,如果还没有收到来自B的rwnd更新报文段,则会发送一个零窗口探测报文段(携带1字节数据),当B接收到这个TCP报文段后,会给A回复一个rwnd的更新,如果此时rwnd > 0,那么A就可以继续发送数据,如果rwnd=0,则重新启动一个持续计时器,重复上述步骤。

3. 拥塞控制

3.1 拥塞控制介绍

在网络出现拥堵时,如果继续发送大量数据包,可能会导致数据包时延、丢失等,这时 TCP就会重传数据,但是一重传就会导致网络的负担更重,于是会导致更大的延迟以及更多的丢包,这个情况就会进入恶性循环被不断地放大。

拥塞:当对网络资源的需求超过了现有的资源你的可用部分。
拥塞窗口 cwnd是发送方维护的一个的状态变量,它会根据网络的拥塞程度动态变化的

拥塞控制与流量控制对比:

拥塞控制流量控制
全局性网络点对点
防止过多数据注入到网络控制发送方的速率
针对网络问题发送缓存与接收缓存的问题

3.2 TCP的拥塞控制方法

TCP采用基于窗口的方法进行拥塞控制,该方法属于闭环控制方法。
发送窗口 swnd 和接收窗口 rwnd 是约等于的关系,那么加入了拥塞窗口的概念后,此时发送窗口的值是swnd = min(cwnd, rwnd),即拥塞窗口和接收窗口中的最小值。

拥塞控制主要是四个算法:

  1. 慢启动
  2. 拥塞避免
  3. 拥塞发生
  4. 快速恢复

3.2.1 慢启动算法

TCP 在刚建立连接完成后,首先是有个慢启动的过程,在这过程中,一点一点的提高发送数据包的数量
规则:当发送方每收到一个 ACK,就拥塞窗口 cwnd 的大小就会加 1。
在这里插入图片描述
慢启动算法,发包个数按照指数型增长(1->2->4->8>…)
慢开始门限ssthresh(状态变量)防止拥塞窗口cwnd增长过大引起网络拥塞。

  • 当cwnd < ssthresh,使用慢开始算法。
  • 当cwnd > sshresh,停止使用慢开始算法而使用拥塞避免方法。
  • 当cwnd = sshresh时既可以使用慢开始算法也可以使用拥塞避免算法。

3.2.2 拥塞避免算法
规则:每当收到一个 ACK 时,cwnd 增加 1(线性增长)。
接上前面的慢启动的例子,现假定 ssthresh 为 8:
当cwnd > 8后,使用拥塞避免方法,每收到一个ACK确认,cwnd增加1。
3.2.3 拥塞发生算法
当网络出现拥塞,也就是会发生数据包重传,重传机制主要有两种:

1.超时重传
当发生了「超时重传」,则就会使用拥塞发生算法。
这个时候,sshresh 和 cwnd 的值会发生变化:

ssthresh 设为 cwnd/2,cwnd 重置为 1,执行慢开始算法。

2.快速重传
当接收方发现丢了一个中间包的时候,发送三次前一个包的 ACK,于是发送端就会快速地重传,不必等待超时再重传。
TCP 认为这种情况不严重,因为大部分没丢,只丢了一小部分,则 ssthresh 和cwnd 变化如下:

cwnd = cwnd/2 ,也就是设置为原来的一半; ssthresh = cwnd; 进入快速恢复算法

3.2.4 快速恢复算法
快速恢复算法如下:

  • 拥塞窗口 cwnd = ssthresh + 3 ( 3 的意思是确认有 3 个数据包被收到了)
  • 如果再收到重复的 ACK,那么 cwnd 增加 1, 并且在允许的条件下发送一个报文段
  • 如果收到新数据的 ACK 后,设置 cwnd = ssthresh,接着就进入了拥塞避免算法

4.小结

本文首先整理了可靠传输、流量控制以及遇到死锁问题后应该如何解决,简单介绍了拥塞控制中包括慢启动、拥塞、拥塞发生、快速恢复等的相关算法,对TCP网络原理有了较深的理解。

文章均参考网上资源,进行学习梳理,用于个人学习

  • 49
    点赞
  • 25
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

君莫笑lucky

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值