TCP队头阻塞
最近面试的时候被面试官问到这个问题当场麻了，所以特地写篇博客学习一下。
定义
TCP数据包是有序传输，中间一个数据包丢失，会等待该数据包重传，造成后面的数据包的阻塞。队头阻塞主要是 TCP 协议的可靠性机制引入的。TCP 使用序列号来标识数据的顺序，数据必须按照顺序处理，如果前面的数据丢失，后面的数据就算到达了也不会通知应用层来处理。
解决方案
按照网上所说，TCP队头阻塞的原因是TCP自身的实现的原因，无法避免，所以采用google的quic协议来替代。
那么同时我也去了解了一下quic协议。
quic
定义
Quic 全称 quick udp internet connection [1]，“快速 UDP 互联网连接”，（和英文 quick 谐音，简称“快”）是由 google 提出的使用 udp 进行多路并发传输的协议。
出现的背景
- 协议历史悠久导致中间设备僵化。
- 依赖于操作系统的实现导致协议本身僵化。
- 建立连接的握手延迟大。
- 队头阻塞。
quic解决tcp队头阻塞的方式
QUIC 协议选择了 UDP，因为 UDP 本身没有连接的概念，不需要三次握手，优化了连接建立的握手延迟，同时在应用程序层面实现了 TCP 的可靠性，TLS 的安全性和 HTTP2 的并发性，只需要用户端和服务端的应用程序支持 QUIC 协议，完全避开了操作系统和中间设备的限制。但是这是只是一部分原因，同时因为quic协议采用了多路复用的。
QUIC 的多路复用和 HTTP2 类似。在一条 QUIC 连接上可以并发发送多个 HTTP 请求 (stream)。但是 QUIC 的多路复用相比 HTTP2 有一个很大的优势。
QUIC 一个连接上的多个 stream 之间没有依赖。这样假如 stream2 丢了一个 udp packet，也只会影响 stream2 的处理。不会影响 stream2 之前及之后的 stream 的处理。
这也就在很大程度上缓解甚至消除了队头阻塞的影响。
