还在死守TCP吗，来看看即将成为HTTP3.0标准协议的QUIC

文章目录

背景
为什么需要QUIC
为什么QUIC能撼动TCP的霸主地位
QUIC 缺点
展望未来
参考

背景

一段时间以来被称为 HTTP-over-QUIC 的协议现在已经改变了名称，将正式成为 HTTP/3。这是由马克•诺丁汉(Mark Nottingham)最初的建议引发的

具体博客地址

为什么需要QUIC

随着移动互联网快速发展以及物联网的逐步兴起，网络交互的场景越来越丰富，网络传输的内容也越来越庞大，用户对网络传输效率和 WEB 响应速度的要求也越来越高。

但是传统的协议比如TCP，一直有如下缺点：

依赖于操作系统的实现导致协议本身僵化。

TCP 是由操作系统在内核层面实现的，应用程序只能使用，不能直接修改。虽然应用程序的更新迭代非常快速和简单。但是 TCP 的迭代却非常缓慢，原因就是操作系统升级很麻烦。

现在移动终端更加流行，但是移动端部分用户的操作系统升级依然可能滞后数年时间。PC 端的系统升级滞后得更加严重，windows xp 现在还有大量用户在使用，尽管它已经存在快 20 年。

服务端系统不依赖用户升级，但是由于操作系统升级涉及到底层软件和运行库的更新，所以也比较保守和缓慢。

这也就意味着即使 TCP 有比较好的特性更新，也很难快速推广。比如 TCP Fast Open。它虽然 2013 年就被提出了，但是 Windows 很多系统版本依然不支持它

建立连接的握手延迟大。

不管是 HTTP1.0/1.1 还是 HTTPS，HTTP2，都使用了 TCP 进行传输。HTTPS 和 HTTP2 还需要使用 TLS 协议来进行安全传输。这就出现了两个握手延迟：

1.TCP 三次握手导致的 TCP 连接建立的延迟。

2.TLS 完全握手需要至少 2 个 RTT 才能建立，简化握手需要 1 个 RTT 的握手延迟。

对于很多短连接场景，这样的握手延迟影响很大，且无法消除

队头阻塞

队头阻塞主要是 TCP 协议的可靠性机制引入的。TCP 使用序列号来标识数据的顺序，数据必须按照顺序处理，如果前面的数据丢失，后面的数据就算到达了也不会通知应用层来处理。

另外 TLS 协议层面也有一个队头阻塞，因为 TLS 协议都是按照 record 来处理数据的，如果一个 record 中丢失了数据，也会导致整个 record 无法正确处理。

概括来讲，TCP 和 TLS1.2 之前的协议存在着结构性的问题，如果继续在现有的 TCP、TLS 协议之上实现一个全新的应用层协议，依赖于操作系统、中间设备还有用户的支持。部署成本非常高，阻力非常大。

所以 QUIC 协议选择了 UDP，因为 UDP 本身没有连接的概念，不需要三次握手，优化了连接建立的握手延迟，同时在应用程序层面实现了 TCP 的可靠性，TLS 的安全性和 HTTP2 的并发性，只需要用户端和服务端的应用程序支持 QUIC 协议，完全避开了操作系统和中间设备的限制。

中间设备的僵化

可能是 TCP 协议使用得太久，也非常可靠。所以我们很多中间设备，包括防火墙、NAT 网关，整流器等出现了一些约定俗成的动作。

比如有些防火墙只允许通过 80 和 443，不放通其他端口。NAT 网关在转换网络地址时重写传输层的头部，有可能导致双方无法使用新的传输格式。整流器和中间代理有时候出于安全的需要，会删除一些它们不认识的选项字段。

TCP 协议本来是支持端口、选项及特性的增加和修改。但是由于 TCP 协议和知名端口及选项使用的历史太悠久，中间设备已经依赖于这些潜规则，所以对这些内容的修改很容易遭到中间环节的干扰而失败。

为什么QUIC能撼动TCP的霸主地位

QUIC 协议是 Google 提出的一套基于 UDP 的开源协议，它汇集了 TCP和 UDP 的优点，传输高效并且可靠，解决了TCP目前遇到的困境。QUIC优点如下:

更新迭代更容易：TCP 和 UDP 协议是操作系统内核实现的，部署进度慢。QUIC直接基于客户端实现，能实现快速迭代更新
没有队头阻塞的多路复用： TCP 为了保证可靠性，使用了基于字节序号的 Sequence Number 及 Ack 来确认消息的有序到达，数据必须按照顺序处理，可能会造成队头阻塞。HTTP2 支持多路复用，但是由于强制使用 TLS，还存在一个 TLS 协议层面的队头阻塞，QUIC 最基本的传输单元是 Packet，不会超过 MTU 的大小，整个加密和认证过程都是基于 Packet 的，不会跨越多个 Packet。这样就能避免 TLS 协议存在的队头阻塞。Stream 之间相互独立，比如 Stream2 丢了一个 Pakcet，不会影响 Stream3 和 Stream4，所以也不存在 TCP 队头阻塞。
自由选择拥塞控制：TCP 的拥塞控制实际上包含了四个算法：慢启动，拥塞避免，快速重传，快速恢复，QUIC 协议当前默认使用了 TCP 协议的 Cubic 拥塞控制算法，同时也支持 CubicBytes, Reno, RenoBytes, BBR, PCC 等拥塞控制算法。从拥塞算法本身来看，QUIC 只是按照 TCP 协议重新实现了一遍，那么 QUIC 协议到底改进在哪些方面呢？主要有如下几点：

可插拔：应用程序层面就能实现不同的拥塞控制算法，不需要操作系统，不需要内核支持，即使是单个应用程序的不同连接也能支持配置不同的拥塞控制
扩展方便：应用程序不需要停机和升级就能实现拥塞控制的变更，我们在服务端只需要修改一下配置，reload 一下，完全不需要停止服务就能实现拥塞控制的切

更多的 Ack 块：TCP 的 Sack 选项能够告诉发送方已经接收到的连续 Segment 的范围，方便发送方进行选择性重传。

由于 TCP 头部最大只有 60 个字节，标准头部占用了 20 字节，所以 Tcp Option 最大长度只有 40 字节，再加上 Tcp Timestamp option 占用了 10 个字节 [25]，所以留给 Sack 选项的只有 30 个字节。
每一个 Sack Block 的长度是 8 个，加上 Sack Option 头部 2 个字节，也就意味着 Tcp Sack Option 最大只能提供 3 个 Block。
但是 Quic Ack Frame 可以同时提供 256 个 Ack Block，在丢包率比较高的网络下，更多的 Sack Block 可以提升网络的恢复速度，减少重传量
握手更迅速：TCP需三次握手才能建立连接，有等待时延，如果用了TLS加密，还会进一步增加时延。QUIC采用了类似于TCP Fast Open的设计，在之前已经连接过的情况下可以无需握手，直接开始传送数据，连接建立时延为0
连接保持：TCP 连接是由四元组标识的（源 IP，源端口，目的 IP，目的端口），当其中一项发生改变，都需要重新建立和服务端的 TCP 连接。QUIC连接不再以 IP 及端口四元组标识，而是以一个 64 位的随机数作为 ID 来标识，这样就算 IP 或者端口发生变化时，只要 ID 不变，这条连接依然维持着。这就意味着：在IP地址和端口变化的情况下（比如从Wi-Fi切换到流量），可以无需重新建立连接，继续通信

QUIC 缺点

既然QUIC如此优秀，但是为什么还是没有大量普及呢？有如下原因

QUIC 基于 UDP ，目前很多网络运营商会降低 UDP 包的优先级，使得 UDP 丢包率特别高
支持QUIC协议的浏览器比较少

展望未来

阿里云CDN目前也是在慢慢支持QUIC

原文链接

快手也是自研了KQUIC

原文链接

参考

博客
知乎

还在死守TCP吗，来看看即将成为HTTP3.0标准协议的QUIC相关推荐

比锐速还强的 TCP拥塞控制技术 —— TCP-BBR 测试及开启教程
比锐速还强的 TCP拥塞控制技术 -- TCP-BBR 测试及开启教程网络资源 Toyo 7个月前 (12-08) 56评论文章目录 [显示] 本文最后更新于 2017年6月11日 02:36 可 ...
图解 | 为什么HTTP3.0要弃用TCP协议，而改用UDP协议？
点击上方蓝色小字,关注"涛哥聊Python" 重磅干货,第一时间送达来源:后端技术指南针作者:指南针氪金入口 1. 大白和小黑生活不止眼前的苟且,还有诗和远方的田野. 新的一 ...
babel 7.0.0-0_我们即将接近7.0 Babel版本。这是我们一直在做的所有很酷的事情。...
babel 7.0.0-0 by Henry Zhu 朱Henry 我们即将接近7.0 Babel版本. 这是我们一直在做的所有很酷的事情. (We're nearing the 7.0 Babel ...
Rust即将发布1.0版本，Go持续获得关注：如何在新生语言之间做出抉择
没有什么比谈论一门新语言能够让程序员更加兴奋.更加固执己见的了.作为两枚冉冉升起的新星,Go和Rust让我们置身在这场旋窝之中.作为灵感相似但是动机与目标完全不同的两门语言,Go和Rust可谓都是出身 ...
你还在为 TCP 重传、滑动窗口、流量控制、拥塞控制发愁吗？看完图解就不愁了...
每日一句英语学习,每天进步一点点: 来自:小林coding 前言前一篇「硬不硬你说了算!近 40 张图解被问千百遍的 TCP 三次握手和四次挥手面试题」得到了很多读者的认可,在此特别感谢你们的认可, ...
（五）比老干妈还香的TCP酱油
什么是TCP协议一.概要在网络层有Ip协议解决了网络区域的划分,不同网络位置定位等问题,但这无法保证数据是否是完整的,列举几个原因: 在数据链接层中会发送数据帧(过大会分帧发送),数据帧经过交换 ...
Web1.0时期进入Web3.0时代，即将跨入Web4.0时代
网站的功能性现在已经彻底地变革,我们经历过的一种巨大的转变,就是网站从"静态内容"的展示转向"动态内容"的传递,从早期的Web1.0时期进入Web 2.0时代. ...
还在用 Python 2.x？Python 3.7.0 正式发布！
6 月 27 日,期待已久的 Python 3.7.0 正式发布,与之同行的还有 3.6.6 版本的更新.此次,最新版的 Python 3.7.0 带来了诸多的新功能和优化,接下来,让我们一睹为快. ...
还在关注“宏颜获水”？DuerOS 5.0让你更惊讶
智造观点在2019年百度AI开发者大会上,DuerOS迎来了全新的5.0升级版,目前安装基数已经超过4亿台.DuerOS5.0采用全双工模式,可以在不需要唤醒词的情况下做出响应.同时,安装了Duer ...