1. ARQ自动重传协议
自动重传请求（Automatic Repeat-reQuest），通过使用确认和超时这两个机制，在不可靠服务的基础上实现可靠的信息传输，其中包括停止等待ARQ协议和连续ARQ协议
1.1 停止等待ARQ
发送窗口大小为1，接收窗口大小也为1
发送方每发送一个数据包，就要等待接收方返回ack包，如果在定时时间内没收到ack包，则需要重新发送，而这个超时时间，是需要经过RTT往返时延（从发送方发送数据开始，到发送方接收到来自接收方的确认消息）来计算出来的。
当数据正常传输时，发送完M1数据包后，等待接收方的M1数据包ACK，收到后继续发送M2数据包并等待ACK
当数据传输出错时，假设数据包M1丢失，则一定超时时间后，进行一次重传。
1.2 连续ARQ
连续ARQ发送方可连续发送多个分组的数据，而不需要像停止等待ARQ一样，等到应答再进行发送，大大提升带宽的利用率。
1）滑动窗口概念
滑动窗口协议在发送方和接收方之间各自维持一个滑动窗口，两个窗口大小不一定相同。
主要提供TCP的可靠性（基于确认重传机制）以及TCP的流控特性（控制网络传输时的流量，避免拥塞发生）。
滑动窗口其实类似一个收费站，收费站也就是窗口的位置是不变的，数据不停的在进行滑动。
2）滑动窗口重发机制
发送端维护一个窗口，窗口内有多个分组，分组个数等于窗口的大小，窗口内的分组可以直接连续发送数据，不需要等待接收端返回的ACK，这样可以提升对信道的利用率。
TCP协议提供两种滑动窗口协议：回退（Go-Back-N）以及选择重传（Selective Repeat来解决连续ARQ模式下传输数据出错的问题。
1）回退（Go-Back-N）协议
发送窗口大小 n > 1，接收窗口 = 1，当发生数据丢失时，会重传所有大于最后一个ACK的包
在这种模式下，发送端会维护一块发送端的数据缓存，当需要重发窗口中的分组报文，便会从缓存里读取数据发送。
这里采用的是累计确认的形式，不像停止等待ARQ，现在不需要对数据帧进行逐个的确认，而是对按序到达的最后一个分组进行确认，假设发送方发送了5个包，但是第三个包丢失，则接收方只返回前两个包的ACK，此时发送方因为不知道后面的三个包有没有发送成功，只能选择这三个包进行重传。
2）选择重传（Selective Repeat）协议
发送窗口大小 > 1，接收窗口大小 > 1，当发生数据丢失，只重传丢失的数据包。
此时已经无法依赖ACK包去做选择重传了，因为ACK只能表示收到了哪些包，但中间的包丢失时，则无法表示。
所以在这里引入了SACK**(Selective Acknowledgement)**，存储在TCP头部的可变选项中，记录接收窗口缓存中还未收到的数据包信息。
具体例子如下：
1.3 总结
| 协议 | 窗口大小 | 是否有序接收 | 具体做法 |
|---|---|---|---|
| 停止等待ARQ | 发送=1， 接收=1 | 有序 | 发送窗口每次只能发送一个数据包，然后就停止等待ack包。接收窗口有序的接收数据包，接收成功后发送ack包给发送窗口，如果收到的数据包是无序的，就直接丢弃 |
| 连续ARQ-回退协议 | 发送 = N，接收 = 1 | 有序 | 发送窗口每次最多一次性发送n个数据包，接收窗口有序的接收数据包，当接收到有序的数据包后，发送ack包给发送窗口，如果收到的数据包时无序的，就直接丢弃。当数据包丢失的时候，会将发送窗口中的后面的所有数据包都重新发送 |
| 连续ARQ-选择重传协议 | 发送 = N，接收 = N | 无序 | 发送窗口每次最多一次性发送n个数据包，接收窗口无序的接收数据包，当接收到数据包后，发送ack包给发送窗口，ack中会携带SACK信息，也就是接收窗口中的缓存信息。发送端会根据SACK信息来只重传丢失的数据包 |
2. TCP的流量控制
目的：防止分组丢失进而触发自动重传机制，造成网络流量的浪费。
原理：如果发送者发送数据过快，接收者来不及接收，那么就会有数据分组丢失。为了避免这种分组丢失，接收端会通知发送端它的接收窗口大小（TCP首部中有一个窗口大小值），此时发送者也将发送窗口大小更改为这个值，让接收者来得及接收。
具体案例：假设一开始主机A和B的窗口都是400，那么在发送时，主机A会连续发送400个字节的数据，如果201~300号意外丢失了，主机B会返回响应ACK=1，ack=201，rwnd=300，这表示主机B已接收到201号之前的数据，并将自己的接收窗口设置为300。此时A收到后将发送窗口大小也设置为300，达到流量控制的目的。
3. TCP的拥塞控制
目的：防止过多的数据注入到网络中，避免出现网络负载过大的情况，常用的算法就是：
慢开始、拥塞避免、快重传、快恢复
原理：发送方维持一个拥塞窗口cwnd（congestion window）的状态变量，拥塞窗口的大小取决于网络的拥塞程度，并且动态地在变化。另外考虑到接受方的接收能力 发送方的发送窗口小于或等于拥塞窗口
3.1 慢开始算法
原理：一开始不发送大量的数据，防止网络负载过大，由小到大逐渐增加拥塞窗口的大小，来探测网络的拥塞程度
具体案例：发送方每次经过一个传输轮次之后，拥塞窗口cwnd就直接加倍，这样比直接一下把许多报文注入网络要慢的多。
3.2 拥塞避免算法
原理：当拥塞窗口cwnd到达慢开始门限ssthresh后，让拥塞窗口缓慢增长，每经过一个传输轮次后，将cwnd值加一，而不是直接加倍。使cwnd已经到达一定值的情况下，网络不容易出现阻塞。
慢开始门限ssthresh与拥塞窗口cwnd的关系：
当cwnd<ssthresh时，使用慢开始算法
当cwnd>ssthresh时，改用拥塞避免算法
当cwnd=ssthresh时，慢开始与拥塞避免算法任意
具体案例：拥塞窗口cwnd初始值为1，慢开始门限ssthresh初始值是16
1）在cwnd<ssthresh，执行慢开始算法，cwnd的值在经过一个轮次传输后值翻倍
2）当cwnd>ssthresh，执行拥塞避免算法，每一个轮次，cwnd的值只加1
3）当cmnd = 24时，假设发生网络阻塞，将进行”乘法减小“，ssthresh = cwnd / 2，cwnd为0，重新开始慢开始算法
3.3 快重传算法
原理：快速进行重传，当接收方在收到一个失序的报文段后就立即发出重复确认，发送方只要一连收到三个重复确认就认为是网络阻塞，立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期。（提高网络吞吐量百分之20左右）
具体案例：
3.4 快恢复算法
原理：快速恢复传输，和快重传搭配使用，当发生快重传时，进行”乘法减小“算法，此时不会再进行慢开始算法，而是执行快恢复算法，直接将cwnd设置为ssthresh减半后的值。
具体案例：cwnd为24时，收到三个重复确认，则进行快重传，此时执行”乘法减小“算法，ssthresh = cwnd/2，cwnd = ssthresh，直接便开始了拥塞避免算法。文章来源：https://www.toymoban.com/news/detail-859018.html
注意：在TCP Reno版本采用快恢复算法时，慢开始算法只是在TCP连接建立时和网络出现超时时才使用，其他例如收到三个重复的确认，则会执行快恢复算法。
文章来源地址https://www.toymoban.com/news/detail-859018.html
到了这里，关于网络编程——TCP的特性之自动重传/流量控制/拥塞控制，一篇说清楚的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
