TCP协议中滑动窗口解决的问题以及QUIC协议的提出

滑动窗口主要是为了解决接收方的Ack丢失导致的阻塞问题，滑动窗口的概念大幅度提高了 TCP 传输数据时抗干扰的能力，一般丢失一两个 ACK 根本没关系。但如果是发送的包丢失，或者出错，窗口就无法向前滑动，出现了队头阻塞的现象。所以它不是解决了丢包问题，丢包依旧要阻塞
所以，其有一个难以避免的缺点就是，必然会有头部阻塞问题（就是会有延时，发收信息都可能会变慢）。
因为tcp协议很难修改，新加协议又不被人接受，所以提出可以在UDP上加以修改的QUIC协议！（注意：是基于udp的传输层协议）
其有如下的优点：

1.QUIC 协议在传输层就支持多路复用，避免了队头阻塞问题。
2.QUIC 协议基于 UDP，更自由更高效
3.QUIC 协议借鉴了 TFO 的思想，支持会话上下文缓存，方便恢复，具备实现 0-RTT 的可能

所以是多路复用解决了阻塞问题，但是其安全问题怎么解决的呢？
答案是其的纠错机制：冗余机制。
我们如果经常在leetcode上刷题，会遇到136题，找到只出现一个次的数字。有一种经典的解法就是利用了这个机制，那就是异或运算的规则！
有：
a ^ a = 0
a ^ 0 = a

A1 ^ A2 ^ A3 ^ … ^ An = T
那么有了T和A1到An-1，就很容易求得An了，求其余值也是一样。
也就是说，只要我们能保证只丢失或者只错一个包，那么只要在发之前多发一个T包，就必然能把这个错包找到。

当然要注意的是，这种方案仅仅在只发生一个错包或丢包时有效，如果丢失两个包就无能为力了(这也就是为什么只发一个冗余包就够的原因)。因此数据包和冗余包之间的比值需要精心设计，如果比值过高，很容易出现丢两个包的情况，如果比值过低，又会导致冗余度太高，需要设计者根据概率计算结果进行权衡。