TCP的可靠性传输机制

简介: TCP的可靠性传输机制

1. TCP是一种面向连接,可靠的,字节流的传输协议


TCP使用了 重传机制,滑动窗口,流量控制,拥塞控制来实现可靠的传输


重传机制


1.快速重传


当接收端连续发送3个相同ack给发送端的时候,就证明了ACK的数据在传输过程中丢失,就会立刻发生重传机制。快速重传机制只解决了一个问题,就是超时时间的问题,但是它依然面临着另外一个问题。就是重传的时候,是重传之前的一个,还是重传所有的问题。


比如对于上面的例子,是重传 Seq2 呢?还是重传 Seq2、Seq3、Seq4、Seq5 呢?因为发送端并不清楚这连续的三个 Ack 2 是谁传回来的。


根据 TCP 不同的实现,以上两种情况都是有可能的。可见,这是一把双刃剑。


2.SACK重传机制


通过 添加sack来记录已经收到的数据序列号,这样就能清楚的分清楚上一次重传丢失的序列号来自哪个序列。


拥塞控制


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


于是,就有了拥塞控制,控制的目的就是避免**「发送方」的数据填满整个网络。


为了在「发送方」调节所要发送数据的量,定义了一个叫做「拥塞窗口」**的概念。


拥塞窗口 cwnd是发送方维护的一个的状态变量,它会根据网络的拥塞程度动态变化的。


发送窗口swnd, 接收窗口rwnd。


拥塞窗口变化规则:


  • 只要网络中没有出现拥塞,cwnd增大

  • 网络中出现了拥塞,cwnd就会减少

  • 如果发送方没有在规定时间内接收到ACK应答报文,就是发生了超时重传,就被当作网络中出现了拥塞。


拥塞控制的四个算法:


  1. 1.慢启动

  2. 2.拥塞避免

  3. 3.拥塞发生

  4. 4.快速恢复

  5. 一. 慢启动

  6. 当发送方没收到一个ACK,拥塞窗口cwnd的大小就会加1

  • cwnd初始值 = 1, 收到ACK确认应答之后,cwnd + 1,每次发送2个

  • 当收到2个的ACK取人应答之后,cwnd增加2,于是发送4个

  • 当收到4个的ACK确认的时候,每个cwnd都加1,就是发送4 + 4 = 8个

有一个叫慢启动门限 ssthresh (slow start threshold)状态变量。


当cwnd < ssthresh时,使用慢启动算法


当cwnd >= ssthresh时,使用拥塞避免算法


二. 拥塞避免算法


ssthresh的大小 约等于 65535字节


那么进入拥塞避免算法后,它的规则是:每当收到一个 ACK 时,cwnd 增加 1/cwnd。


当 8 个 ACK 应答确认到来时,每个确认增加 1/8,8 个 ACK 确认 cwnd 一共增加 1,于是这一次能够发送 9 个 MSS 大小的数据,变成了线性增长。

20200905112400609.png

使用拥塞避免算法时减缓拥塞窗口的增长速率。最后当网络足够拥塞的时候,就会发生丢包现象,出现重传。


然后就会触发重传机制,执行拥塞发生算法


三. 拥塞发生


当发生数据包重传之后,有两种重传机制:


  • 超时重传

  • 快速重传

超时重传: 发生了超时重传之后,就会使用用拥塞发生算法


ssthresh 设为 cwnd / 2, cwnd 重置为1


然后就进行慢启动。


快速重传: 当发生丢了一个中间包的情况下,发送三次前一个报的ACK,就会进行快速重传,不需要等待超时重传


这种情况之下:


cwnd = cwnd / 2


ssthresh = cwnd


进入快速恢复算法


快速恢复


当收到3个重复的ACK说明网络情况不是很差,不需要进行超时重传等算法


cwnd = ssthresh + 3 ( 3 的意思是确认有 3 个数据包被收到了)


重传丢失的数据包;


如果再收到重复的 ACK,那么 cwnd 增加 1;


如果收到新数据的 ACK 后,把 cwnd 设置为第一步中的 ssthresh 的值,原因是该 ACK 确认了新的数据,说明从 duplicated ACK 时的数据都已收到,该恢复过程已经结束,可以回到恢复之前的状态了,也即再次进入拥塞避免状态

20200905114128469.png

20200905114220671.png

资料参考 https://zhuanlan.zhihu.com/p/133307545


参考小林coding的博客内容

相关实践学习
容器服务Serverless版ACK Serverless 快速入门:在线魔方应用部署和监控
通过本实验,您将了解到容器服务Serverless版ACK Serverless 的基本产品能力,即可以实现快速部署一个在线魔方应用,并借助阿里云容器服务成熟的产品生态,实现在线应用的企业级监控,提升应用稳定性。
云原生实践公开课
课程大纲 开篇:如何学习并实践云原生技术 基础篇: 5 步上手 Kubernetes 进阶篇:生产环境下的 K8s 实践 相关的阿里云产品:容器服务&nbsp;ACK 容器服务&nbsp;Kubernetes&nbsp;版(简称&nbsp;ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情:&nbsp;https://www.aliyun.com/product/kubernetes
相关文章
|
1月前
|
网络协议 算法 网络性能优化
【计算机网络】TCP 如何实现可靠传输
【计算机网络】TCP 如何实现可靠传输
35 6
|
4月前
|
缓存 网络协议 网络性能优化
UDP实现可靠传输
UDP实现可靠传输
|
4月前
|
缓存 网络协议 物联网
UDP的可靠性传输
UDP的可靠性传输
72 1
|
4月前
|
缓存 网络协议 算法
UDP的可靠性传输2
UDP的可靠性传输2
47 0
|
4月前
|
网络协议 Linux 网络性能优化
TCP如何保证可靠性
TCP如何保证可靠性
26 0
|
4月前
|
缓存 网络协议 算法
UDP如何实现可靠传输
UDP如何实现可靠传输
|
4月前
|
缓存 网络协议 算法
UDP的可靠传输
UDP的可靠传输
61 0
|
6月前
|
缓存 监控 网络协议
2.6 TCP与UDP的可靠性传输
2.6 TCP与UDP的可靠性传输
80 0
|
7月前
|
网络协议 网络架构
TCP协议报文,核心特性可靠的原因,超时重传详细介绍
TCP协议报文,核心特性可靠的原因,超时重传详细介绍
|
7月前
|
网络协议 算法 网络性能优化
TCP为什么是可靠的(怎么保证有效传输的)?
TCP为什么是可靠的(怎么保证有效传输的)?
305 0