QUIC协议对于传输可靠性的保障机制

今天在看 frp的文档 时看到文档中提到QUIC协议，其底层采用UDP传输，具有传输效率高，连接延迟低的优点。

出于对它的好奇，所以找了一些对这个协议的详解博客文章来了解它的通信机制。

具体可见：QUIC 协议详解 - 知乎 (zhihu.com)

其他暂且不提，由于本人半吊子水平，看到以上提到的那篇博客中所说的QUIC协议对于传输可靠性的保障措施有些不太明白，在这里借用该博客资料及部分原文说明：

可靠传输有 2 个重要特点：

（1）完整性：发送端发出的数据包，接收端都能收到

（2）有序性：接收端能按序组装数据包，解码得到有效的数据

1. 关于完整性，QUIC协议通过确认应答机制保证其可靠传输

当时我就有个疑问，如果服务器的 SACK 因为丢包导致客户端没有接收到确认包应该怎么处理？
答案是客户端对未接收到确认包的PKN在超时后一律重传（事实证明这个是大部分协议都会有的处理机制，还是看得少了）

另外此图存在一些歧义，我一开始以为 PKN=1,2,3 和 SACK=1,3 是一个单独的包，但实际上也有可能是客户端连续发送了
3个PKN递增的包，而服务器响应了1和3，所以客户端重传2，并将PKN按顺序递增到4。

按上图这个情况，如果SACK丢失了，则客户端会将1,2,3全部重新传输。


2) 关于有序性，原文中提到通过offset确定数据包的顺序，而PKN设计为严格单调递增，递增是为了解决数据包的重传歧义问题

由于原始包和重传包的序列号是一样的，客户端不知道服务器返回的 ACK 包到底是原始包的，还是重传包的。但 QUIC 的原始包和重传包的序列号是不同的，也就可以判断 ACK 包的归属。

这里博主说的一开始我没有搞明白为什么还要判断原始包和重传包，
直到看到这篇文章：基于UDP的可靠传输QUIC - 知乎 (zhihu.com)

显然，客户端发送重传包的情况有 服务器未接收到 和 服务器收到了但是客户端没有收到确认包 这两种情况，头一种情况不存在重传歧义问题，但是第二种情况如果是由于中间的网络原因导致客户端接收确认包超时了，导致发送了重传包，

那么此时服务器接收到重传包后再次发送的确认包将有可能和第一次发送的确认包混杂在一起。这种情况下如果PKN不是严格递增的话就会导致客户端无法确定数据包和确认包的对应关系。