1
TCP篇3
source link: https://helloteemo.github.io/2021/07/16/%E8%AE%A1%E7%AE%97%E6%9C%BA%E7%BD%91%E7%BB%9C/TCP%E7%AF%873/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
TCP篇3
发表于 2021-07-16 更新于 2021-09-20 分类于 计算机网络 阅读次数： 5
本文字数： 809 阅读时长 ≈ 1 分钟
本文字数： 809 阅读时长 ≈ 1 分钟
书接上文，本文主要介绍TCP的 重传机制、滑动窗口、流量控制、拥塞控制
TCP篇3
重试机制主要用于解决丢包问题。主要包括以下几种重传方式
- 超时重传：超过了一定的时间没有收到ACK响应，则重新上传报文
- 超时间隔加倍策略：针对一份报文的每一次重试的重试时间都加倍
- 快速重传：不以时间为重试单位，而是以数据作为重试单位。在接受到三个相同的ACK报文时，会在定时器过期之前，重传丢失的报文。但是不能确定报文丢失的范围
- SACK：解决快速重传的丢失报文范围问题。在TCP报文的选项中增加已缓存的数据，这样发送方就知道了什么数据没有传成功。
- D-SACK：使用了SACK方法来告诉发送方有哪些数据被重复接受了。
窗口解决的问题是每一次发送包都需要ACK响应才能继续发送包的问题，并且这个问题会随着包往返时间越长而越发明显。
为了解决这个问题，TCP引入的窗口技术，窗口的实现实际上是操作系统开辟的一个缓存空间，发送方主机在等到确认应答返回之前，必须在缓冲区中保留已发送的数据。如果按期收到确认应答，此时数据就可以从缓存区清除。假设窗口大小为 3 个 TCP 段，那么发送方就可以「连续发送」 3 个 TCP 段，并且中途若有 ACK 丢失，可以通过下一个确认应答进行确认。
窗口大小也就是无需等待确认应答，而可以继续发送数据的最大值。
TCP 头里有一个字段叫 Window，也就是窗口大小。
这个字段是接收端告诉发送端自己还有多少缓冲区可以接收数据。于是发送端就可以根据这个接收端的处理能力来发送数据，而不会导致接收端处理不过来。
发送方不能无脑的发数据给接收方，要考虑接收方处理能力。
如果一直无脑的发数据给对方，但对方处理不过来，那么就会导致触发重发机制，从而导致网络流量的无端的浪费。
为了解决这种现象发生，TCP 提供一种机制可以让「发送方」根据「接收方」的实际接收能力控制发送的数据量，这就是所谓的流量控制。
有一种方法是窗口缩小
不想写了。。。
请用钱砸死我！！！
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK