标签：传输层 tps 拥塞控制 udp 而且 多字节 应用层 网络协议 允许
原文地址https://docs.google.com/document/d/1gY9-YNDNAB1eip-RTPbqphgySwSNSDHLq9D5Bty4FSU/edit
QUIC是一个谷歌提出的新的互联网协议。
QUIC解决出现在现在网络协议的一些传输层和应用层的问题，而且几乎不需要应用更改。QUIC和TCP+TLS+HTTP2十分相似，但是基于UDP实现。使用QUIC作为一个独立的协议可以做到一些别的协议做不到的创新，因为它们受到传统客户端和中间件的阻碍。
和TCP+TLS+HTTP2相比，QUIC的核心优势有以下几点：
简单来说，在发送有效负载前，和TCP+TLS的1~3rt相比，QUIC通常需要0rt。
当QUIC客户端第一次链接到服务端时，客户端必须执行1rt的握手来获取完成握手的所有必要信息。客户端发送一个CHLO，服务端返回一个带有客户端用来继续执行的拒信，包括源地址令牌和服务器证书。下次客户端发送CHLO时，可以使用上次连接缓存的证书来立刻返回一个加密的消息。
QUIC有可插拔的拥塞控制，而且比TCP给拥塞控制提供更丰富的信息。这允许一个QUIC发送者识别重发的ACK和原始的ACK避免TCP的重发歧义问题。QUIC ACK还明确传输数据包发送和接收的延时，以及单调增加的序列号。这允许准确的rt计算。
最后，QUIC的ACK帧支持多达256NACK范围，因此QUIC比TCP（带SACK）在重新排序上更有弹性，而且能够在重新排序和丢失时在线路上保存更多字节。客户端和服务端都可以准确地知道对方哪个包收到了。
基于TCP的HTTP2更大的一个问题是排头阻塞。应用视TCP连接为一个字节流。当一个TCP包丢失，HTTP2连接上没有数据流向前推进，直到包被重传而且被远端接受——甚至当这些数据流已经到达而且在缓存等待。
由于QUIC一开始就是为多路复用操作设计的，因此传输单个流数据丢失的数据报通常只影响该特定的流。每个流的帧可以立即被分发并且在应用推进。
为了在不等待重传情况下从丢包中恢复，QUIC可以用FEC包补充一组包。很像RAID-4，在FEC组里包含部分FEC包。如果组中的一个包丢失，则可以从FEC包和组中剩余的包恢复这个包。发送者可以决定是否发送FEC包来优化特殊的场景（例如，一个请求的开始和结束）。
QUIC连接被一个64位的连接ID识别，被客户端随机生成。相比之下，TCP连接被一个由源地址，源端口，目标地址，目标端口的4元组识别。这意味着如果一个客户端改变地址（例如，从WI-FI切到移动网络）或者端口（如果一个NAT丢失并且这个端口连接重新绑定），任何可用的TPC连接不再有效。当一个QUIC客户端改变IP地址，它可以在不打断执行中的请求的情况下从这个新的IP地址使用这个老的连接ID。
标签：传输层 tps 拥塞控制 udp 而且 多字节 应用层 网络协议 允许
原文地址：https://www.cnblogs.com/gouden/p/12230036.html
