作者：张裕鹏 日期：2022-3-11
1. 什么是 TCP 的队头阻塞
假设某个数据包超时未收到确认应答，当前窗口就会阻塞在原地，重新发送该数据包，在收到该重发数据包的确认应答前，就不会有新增的可发送数据包了。也就是说，因为某个数据包丢失，当前窗口阻塞在原地，同样阻塞了后续所有数据包的发送。
TCP 因为超时确认或丢包引起的滑动窗口阻塞问题就是TCP的队头阻塞问题。
2. QUIC 如何解决队头阻塞问题
QUIC 通过单向递增的 Packet Number，配合 Stream ID 与 Offset 字段信息，可以支持非连续确认应答 Ack 而不影响数据包的正确组装，摆脱了 TCP 必须按顺序确认应答Ack 的限制（也即不能出现非连续的空位），解决了 TCP 因某个数据包重传而阻塞后续所有待发送数据包的问题（也即队头阻塞问题）。
3. QUIC 消息确认机制
QUIC 可以支持非连续的数据包确认应答Ack，自然也就要求每个数据包的确认应答Ack 都能返回给发送端（TCP 中间丢失几个Ack 对数据包的确认应答影响不大），发送端收到该数据包的确认应答后才会释放该数据包所占用的缓存资源，已发送但未收到确认应答的数据包会保存在缓存链表中等待可能的重传。QUIC 对确认应答Ack 丢失的容忍度比较低，自然对 Ack 的传输能力进行了增强，Quic Ack Frame 可以同时提供 256 个 Ack Block，在丢包率比较高的网络下，更多的 Ack Block 可以提高Ack 送达的成功率，减少重传量。
4. QUIC 如何实现无感迁移
QUIC 摆脱了TCP 的诸多限制，可以重新设计连接标识，QUIC 数据包结构中有一个Connection ID 字段专门标识连接，Connection ID 是一个64位的通用唯一标识 UUID (Universally Unique IDentifier)。借助Connection ID，QUIC 的连接不再绑定IP 与 Port 信息，即便因为网络迁移或切换导致Source IP 和Source Port 发生变化，只要Connection ID 不变就仍是同一个连接，协议层只需要将控制块中记录的Source IP 和Source Port 信息更新即可，不需要像TCP 那样先断开连接，这就可以保证连接的顺畅迁移或切换，用户基本不会感知到连接切换过程。
5. TCP的拥塞控制机制
TCP 发送数据的速率受到两个因素限制：一个是目前接收窗口的大小，通过接收端的实际接收能力来控制发送速率的机制称为流量控制机制；另一个是目前拥塞窗口的大小，通过慢启动和拥塞避免算法来控制发送速率的机制称为拥塞控制机制，TCP 发送窗口大小被限制为不超过接收窗口和拥塞窗口的较小值。
TCP 的拥塞控制实际上包含了四个算法：慢启动、拥塞避免、快速重传、快速恢复。
6. QUIC 如何降低重传概率
TCP 的拥塞控制机制是被超时重传或者快速重传触发的，想要提高网络传输效率，容易想到两个方案：一个是改进拥塞控制算法；另一个是降低重传次数。
7. TCP 的流量控制
TCP 提供一种机制可以让「发送方」根据「接收方」的实际接收能力控制发送的数据量，这就是所谓的流量控制。
8. TCP 的拥塞控制
一般来说，计算机网络都处在一个共享的环境。因此也有可能会因为其他主机之间的通信使得网络拥堵。
在网络出现拥堵时，如果继续发送大量数据包，可能会导致数据包时延、丢失等，这时 TCP 就会重传数据，但是一重传就会导致网络的负担更重，于是会导致更大的延迟以及更多的丢包，这个情况就会进入恶性循环被不断地放大….
所以，TCP 不能忽略网络上发生的事，它被设计成一个无私的协议，当网络发送拥塞时，TCP 会自我牺牲，降低发送的数据量。
于是，就有了拥塞控制，控制的目的就是避免「发送方」的数据填满整个网络。
只要「发送方」没有在规定时间内接收到 ACK 应答报文，也就是发生了超时重传，就会认为网络出现了用拥塞。
关于 TCP 如何保证可靠性，可以参考：你还在为 TCP 重传、滑动窗口、流量控制、拥塞控制发愁吗？看完图解就不愁了
参考：
若有收获，就点个赞吧
0 人点赞
