srfc srfcn

作者|罗成

编辑|肖志

在访问网站和应用程序时，您经常会遇到各种性能问题。比如网页加载慢，显卡，网络错误等。，其中一个关键因素是网络协议。本文将系统介绍TCP、UDP、HTTP1.1、HTTPS(包括最新的TLS1.3协议)、SPDY、HTTP2等协议存在的问题，以及在具体场景下如何通过网络协议的优化来提高访问速度。

注:本文整理自腾讯TEG基础设施部高级工程师罗成在ArchSummit 2017深圳站的演讲。

WEB性能优化问题

说到WEB性能优化，就意味着我们遇到了很多性能问题。

如上图所示，当你看到这一行的时候，我相信很多场景都会浮现在你的脑海里，比如你无法访问网络，或者页面一直在加载，或者内容可能99%的时间都卡在里面，包括视频卡顿，短视频直播，从wifi重新加载到4G网络。遇到这么多web问题的主要原因是什么？

我简单罗列一下，总结成以下两种情况。

页面大小与页面和页面的元素类型数量直接相关，也就是说页面越大，元素越多，动态交互越频繁，相应的性能可能受到的影响就越大。页面优化也是前端优化的主战场。

网络环境和终端配置，包括用户手机硬件的性能和软件的操作系统版本也会影响性能。而这两个主要与运营商和用户的配置有关，也是我们几乎无法影响的部分。

网络协议

今天，我将重点讨论网络协议。网络协议是一个非常重要和关键的因素，但它很容易被大家忽视。那么说到网络协议，我们会遇到或者使用哪些网络协议呢？

接下来我以最主流的互联网下一代HTTP2协议为例简单介绍一下。

如上图所示，WEB请求需要经过的协议栈。左边是客户端，右边是数据中心或服务器。

从客户端发送请求后，它将首先通过HTTP1.1协议。那为什么题目是HTTP2请求，却提到了HTTP1.1？这是因为虽然HTTP2是一个全新的协议，但是它仍然遵循了HTTP1.1的大部分语义，比如GET请求和POST请求都使用了HTTP1.1的语义，对于页面或者JaScript，我们仍然使用HTTP1.1的语义，HTTP1.1的下一层是HTTP2，使用了全新的帧控制语义。换句话说，HTTP2 frame封装了HTTP1.1的语义，比如GET request就是用HTTP2的头封装的。POST请求的主体数据由HTTP2的数据帧封装。然后到达TLS协议，传输加密层。那为什么这里有加密？

主要原因是HTTP2 RFC7540协议规定HTTP2有两种实现，一种是H2，强制使用TLS进行加密；另一个是H2C，其中C是明文，这意味着纯文本，不需要加密。虽然协议是这么规定的，但是目前所有主流的实现，包括所有的浏览器和所有的操作系统，都是使用TLS加密的。换句话说，如果使用HTTP2，就必须使用TLS加密，所以在过程中会遇到TLS问题。然后下到TCP层，再下到IP网络层，还有以太网和运营商网络的物理层，再到正确的服务器协议。两边的端口可以认为是对称的，不再介绍。

这么多协议，要注意哪些？或者更具体的说，对于我们大多数WEB应用开发者来说，应该注意哪些呢？上图中白色虚线向上的部分是客户端可以影响或优化的部分，即提出的协议包括TCP、TLS和HTTP。我们已经定义了需要优化的协议，所以让我来分析它们会有什么问题。

HTTP1.1的性能

HTTP1.1的性能问题

让我们从使用最广泛、最古老的HTTP1.1协议开始。

接触过web开发的同学都知道，HTTP1.1最大的性能问题是单链接串行。当TCP链路上有多个请求时。如上图所示。请求只能一个接一个的发送，这是它最大的问题。

第二个问题是头部没有压缩。头，尤其是HTTP请求Cookie和Host的时候，有相同的浏览器模型。如果每个请求都携带相同的信息，显然是重复的。这是多余的，浪费带宽，而且会因为性能问题影响用户的访问速度。为什么？由于运营商网络的上下行带宽严重不对称，上行带宽很可能只有下行带宽的1/10甚至不到1/10，也就是说，如果它的带宽是十兆或者一兆，那么它的上行可能只有100K甚至几十k，如果平均头大小是1500字节，那么它一次可能有十个头，在带宽层面会影响用户接入性能。因此，在3G和4G移动网络环境下，未压缩报头的问题更为重要。

HTTP1.1的优化

有很多优化的方法和策略，也很有效，那么都是什么呢？

总结一下，HTTP1.1主要有两个优化方向。

第一点是增加并发连接数；第二点是减少出站请求的数量。如上图，无论是单个域名多TCP连接，还是域名碎片化，都是用多个域名来增加并发连接数。应该注意，并发连接不是并发请求。因为HTTP1.1试图在单条链路上实现并发请求，但是失败了。例如，流水线被队列头阻塞。所以只能通过增加并发连接数来提高用户的访问性能。除此之外，还有其他的优化策略，包括缓存、CSS Sprite、数据uri、图像内联等等。其本质是减少请求的数量，即在一个响应中返回多个响应，从而减少请求的数量。

这些HTTP1.1优化策略和手段在HTTP1.1时代已经取得了非常好的效果，也是有效的。

HTTPS/HTTP2加速了HTTP1.1的淘汰

随着HTTPS的全站化趋势越来越明显，HTTP2的正式发布逐渐成为主流，HTTP1.1的优化策略已经失败。为什么这么说？

HTTPS性能的一个特点或缺点是连接成本非常高。如果HTTP1.1采用增加并发连接数的方法来提高性能，由于其连接成本高，并发连接的并发成本也会很高，从而降低性能。

HTTP2的特点是支持复用。一条链路上允许多个请求，并且允许并发请求。那么HTTP1.1减少请求数量就显得有点多余了。相反，它可能会降低缓存命中率和性能。

所以从这个角度来说，http1.1的优化策略可能行不通，有副作用。

HTTP和HTTPS的比较

HTTP与HTTPS连接成本

接下来，我将简单介绍一下为什么HTTPS的连接费用很高。从协议层面来说，它的连接成本高在哪里？

如上图，左图是一个HTTP1.1的请求流程或者代价，HTTP1.1请求很简单，只需要建立一个TCP连接，然后发送一个HTTP请求和响应。整个过程只需要两个RTT就可以实现一个HTTP请求。

右图显示了一个HTTPS请求。首先，HTTPS通过三次握手建立TCP连接；然后发送HTTP1.1请求。为什么这是HTTP1.1数据？因为如果要求用户主动输入网址，大多数用户不会主动输入HTTPS。例如，当访问腾讯时，他们不会输入https://www.qq.com，而是www.qq.com或http://www.qq.com。为了强制用户使用HTTPS，将返回一个302跳转。关于302跳转，HTTPS使用的端口是443，HTTP是80。新端口必须重新建立新的TCP连接，这就增加了另一个TCP连接建立过程；TCP连接建立后，TLS握手阶段开始。

TLS握手分为两个阶段:第一阶段是完全握手，在这个阶段中，协议版本、密码套件、请求证书和验证证书被协商；客户端拿到证书后，即使证书的签名是ok的，证书时间仍然有效，但是仍然需要检查证书的状态，因为可能存在主动撤销证书的情况，证书的密钥可能泄露或者CA可能被攻击，所以需要查询证书的状态。查询证书状态是OCSP，在线证书状态检查，查询证书状态需要分析一个CA的三点DNS，并建立TCP连接，然后建立包括OCSP在内的请求响应，通过HTTP请求完成。三次握手且状态ok后，开始TLS完全握手的第二阶段，协商对称密钥，即非对称密钥交换计算；完成后，协商整个TLS过程，发送HTTP加密数据。到目前为止已经到了第九个RTT，比http1.1多了7个RTT，什么概念？

没有优化的HTTPS明显比HTTP慢。

如上图，在最好的wifi网络环境下，平均RTT为70毫秒，7个RTT为490毫秒，4G为100毫秒，3G为200毫秒，7个RTT超过1秒。而且这只是一个请求，一个页面一般会有很多请求，请求之间可能存在依赖关系，造成拥塞。这种情况下，一个页面超过几秒是非常正常的，时间消耗只是网络时间消耗；但是，由于协议的规定，它必须与网络进行交互，包括许多其他耗时的工作，如计算耗时、证书验证、密钥计算、内容对称加解密等。因为移动端的性能比较弱，在这个计算层面多几百毫秒是非常正常的。

经过上面的分析，我们可以得出一个基本的结论，即未优化的HTTPS比HTTP慢很多，那么HTTPS是否意味着慢呢？

为了找到慢的原因或者性能瓶颈，我们只从网络协议理论上分析，但实际上在实验环境、真实业务环境、用户场景下，还是那么慢吗，慢在哪里？

为此，我们进行了两个层面的分析。

离线模拟测试

第一个是线下模拟测试。线下模拟测试主要是针对移动端的，因为手机的表现就是流量越来越多，都向移动端倾斜。移动终端有两个特征。第一，手机屏幕比较小，不方便查看数据或者页面性能、调试日志。第二，不方便运行数据分析脚本和控制脚本。于是我们用U连接手机和PC，通过远程调试协议控制手机上的浏览器反复访问我们构建的不同页面。这个页面涉及的元素肯定很多，也有不同的类型。

因此，必须实现离线模拟测试的自动化。靠人工实现效率很低，测试不了那么多页面和场景。而且要注意数据的同比和环比。如果不是，即使测试得到100条数据，1000条数据也不能说明问题，因为数据误差很多，周期性的同比和环比需要1万多条数据才能认为可能有一定的解释意义。

另一个大错误是WIFI。即使是在洲际酒店，腾讯大厦，或者朗科大厦，使用的wifi也经常出现网络抖动，对数据和协议的分析都有很大的影响，因为协议很可能就是这么一个IT，所以几百毫秒的差别很容易在抖动的网络环境下造成问题干扰结论。所以为了消除这些错误，我们经常用U连接手机和PC，绕过wifi，直接用有线网络，因为有线比无线稳定很多，尤其是wifi。

关于工具这个词就是流量控制，因为我们真实用户的网络环境是很不一样的。不同的IP，不同的带宽，不同的丢包率，所以我们用这个工具在实验室里模拟环境。线下的模拟数据显然不能代表我们真实业务的表现。

在线服务速度数据采集

第二部分是在线数据分析。

在服务器上收集数据的方案有两个优点。

第一点是它可以收集客户端不能收集的数据，收集更低层的信息和业务信息。如上图，客户端在左边，也就是你可以使用手机、STW或者负载均衡器，业务服务器在右边。至于业务信息，业务的整体处理时间可以通过LB和业务服务器的交互获得，这是客户端所没有的。第二点是关于协议信息，包括TCP的RTT，TCP是否连接复用，TLS会话是否复用，TLS协议版本，密码套件，握手时间和非对称密钥交换计算时间，HTTP2头压缩比等。这些都是客户得不到的信息。

客户端可以收集一些信息，但是客户端的开发成本很高，因为Android有不同的版本，比如IOS和windows，需要针对不同的操作系统进行开发。但是，它只需要在服务器上开发一次，将数据放在COOKIE中就可以返回给客户端。客户端可以通过JS或普通页面获取信息。得到信息后，它会结合协议相关的信息，上报给数据平台进行分析。

那么这么多数据，我们的数据平台怎么分析呢？

多维数据分析

如上图，由于数据庞大，只截取了几块进行分析。左边是数据维度，比如TCP-reuse表示TCP连接重用，TLS1.2表示TLS协议版本为1.2；右侧是与用户性能相关的监控指标，如开始加载时间、页面活动时间、业务处理时间等。这些维度也可以相互组合，得到三四百个维度。如上图所示，腾讯X五核浏览器在4G网络下使用HTTP2和TLS1.2协议，使用ECDHE不复用TLS会话的首屏时间是多少？通过多维度的对比，我们很容易分辨出它的慢因素。X5在4G下这么多，那么3G下多少钱，wifi下多少钱？通过多维度综合对比，从表面看瓶颈在哪里。

所以多维数据分析的最终目的是找到性能瓶颈和速度优化方向，那么有哪些优化方向呢？

WEB访问速度优化方向

优化方向有三个。第一议定书；第二资源；第三个用户行为。

草案

TCP速度优化

那么如何优化协议层呢？协议的底层是TCP，而TCP最明显的性能问题就是需要三次握手来建立一个TCP连接，然后发送应用层数据，相比普通握手浪费了一个RTT。如上图，左侧是普通的握手。每个TCP连接都需要建立一个握手，发送没有任何运动组数据的SYN包，RTT就浪费了。

TFO是TCP快速开放。应用层数据与SYN数据包同时发出。但是，它的前提是，第一次建立握手和连接的时候，也发送SYN包。不同的是服务器在返回SYN+ACK的时候会返回一个COOKIE。之后用户发起一个TCP连接，用这个COOKIE发送SYN包，然后就可以直接带HTTP数据了。换句话说，应用层数据与SYN数据包同时发出，这降低了RTT对性能的影响。TCP快开性能是一个收益数据，我们发现80分的数据提升了近100毫秒。但它的缺点是需要操作系统、IOS9+或linux kervel3.7+的支持，不支持Windows系统。另一个优化方案是拥塞控制，它将拥塞窗口从三个增加到十个。

一般来说空之间在TCP协议层面提升速度优化是有限度的，因为优化成本很高，在哪里？它需要操作系统和内核的支持。如果只是服务器端的升级，我们支持和研发，其成本是可以控制的。但最重要的是用户的操作系统需要升级，广大网络设备上的软协议栈或者操作系统需要升级，这一级别的部署压力非常大。所以TCP层面的优化成本是很高的。

TLS速度优化-会话重用

TLS是加密层，加密层最大的问题是完全握手。关于完整的握手，接触过的同学应该都很清楚它的session ID，我就不介绍它的流程了。

在这里，我主要分享两点。如上图。第一，关于IOS Qzone的优化，通过session id握手时间可以提升50%左右；第二，虽然会话票的机制更先进，但是因为不需要服务器提供缓存来提供内存存储，发送票，服务器可以检查。会话ID需要为存储提供内存，然后找出会话缓存是否命中。由于IOS不支持会话票，所以大家一定要注意通过分布式会话缓存来提高IOS会话ID的缓存命中率。很多场景下没有办法简化握手，比如用户第一次打开一个APP和一个浏览器，用户退出后再重新启动浏览器，或者关闭后再打开浏览器页面，都可能导致会话缓存无法简化握手，因为会话票都是基于内存的，不是存储在硬盘里的。

TLS速度优化-错误启动

完整握手的优化方法是抢跑，也就是偷跑。类似于TFO，左边有一个普通的握手如上图所示，TLS的两个RTT握手必须进行四次才能建立连接，发送应用层数据。当clientKeyExchange中没有交换时，即在完整握手的第二阶段，错误启动将应用层数据一起发送，这提高了RTT。那么，如何启用错误开始呢？其实现在客户端已经基本支持了。如果服务器要启用，需要注意支持PFS(完美前向密码)加密的算法，比如ECDHE和DHE算法，其握手时间会增加30%。

TLS速度优化-ocsp装订

OCSP装订.刚才提到的一些场景是主动撤销证书，所以需要检查证书的状态，因为在某些情况下，证书的状态不是简单的通过检查证书的签名和时间就能发现的，需要实时检查。我们的证已经发了三年了，学校中间可能会有问题，所以他会定期检查。

他的普通流程也差不多。当客户端hello获得证书时，在这个过程中添加的三个RTT需要到CA站点请求OCSP的状态和内容。如上图，右边是OCSP Stapling，其流程相当于服务器代理发布CA的证书状态的功能。它预先从CA站点请求OCSP内容并将其保存在本地服务器上，然后在握手时将签名的内容返回给客户端，然后客户端检查该内容。不需要和CA位点直接交互，所以看起来OCSP钉住减少了三个RTT，效果应该非常明显。

但是，事实上并非如此。为什么？因为客户端会缓存OCSP，所以可能会在没有请求的情况下缓存OCSP七天，也就是在这七天的时间里，如果用户访问网站很多，可能是上千次，因为一个页面有很多请求，所以可能只有1‰的机会增加这三个RTT。你需要注意的不一定是这个效果。

TLS速度优化-动态记录大小

现在我们来分析一下动态记录大小，也就是记录块大小的动态调整。

先简单解释一下TLS协议层的线头阻塞问题的背景，因为TLS协议传输最基本的单位是记录，一个记录块最多不能超过16K，而有些服务器实现，比如最早版本的Nginx，默认大小是16K。那么16K会怎么样呢？如果中间丢失了一个字节，或者TCP芯片中丢失了一个段，那么16K就无法验证，即使收到15.99K的数据，也没有办法处理，因为丢失一个数据，一个包，就会导致整个记录无法处理。

那么如何解决呢？有两种方法。

第一种是适当降低缓冲，比如不实名登记制的话降到4k，即使丢失也只是影响4K的数据，不会影响16K的数据。

第二，借鉴TCP的慢启动原理。云耀斑提供了一个补丁。在TLS连接刚建立的时候，因为不了解网络情况和拥塞情况，我们会把记录设置降低，比如降低到1K，等发送速度提高后再把记录大小设置为16K。大概就是这么个思路，也有开源代码。有兴趣可以了解一下。

刚才提到的这些优化策略都是针对TLS1.2及之前版本的。接下来介绍TLS 1.3版，这是一个革命性的、非常创新的、具有里程碑意义的协议。

TLS1.3速度优化

TLS1.3速度优化-ortt握手

性能上的创新在于可以实现1RTT的完全握手和0RTT的简化握手。换句话说，TLS连接级没有握手原则，不会增加RTT的延迟。TLS1.3还在草案阶段，所以我在这里介绍是因为如果你想早点尝试的话可以用，因为OpenSSL1.1.1和Nginx1.13.0已经分别支持TLS1.3的最新草案draft20。而关于TLS1.3的最新讨论可能会在今年秋天正式发布。如果客户端可以控制的话，可以试试，包括Firefox也支持TLS1.3，当然这些都是草案版本，这里就给大家介绍一下。具体流程其实比较复杂，这里就不详细介绍了。

HTTPS速度优化

HTTPS速度优化-HSTS减少了302跳

HSTS实际上是HTTP的报头。它的作用是服务器告诉客户端，在规定的时间内访问我的网站，必须使用HTTPS而不是HTTP。然而，他有一个问题，HSTS是通过HTTP返回的，这很可能被中间人劫持。换句话说，客户端可能永远不知道服务器已经发送了HSTS，所以没有办法使用https。在这种情况下，有一个脆弱的预加载列表机制。比如chrome浏览器会把你的网站放在白名单里，当你提出访问请求时，它会使用HTTPS；默认情况下。对于客户端来说也是如此。

HTTPS速度优化-spdy &；& ampHTTP2

SPDY和HTTP2。为什么提到SPDY？主要有两点。

第一，因为HTTP2非常普及，正式发布，所以它的所有特性和主要特性还是用在SPDY上，除了头压缩算法，所以我开始研究SPDY的协议，现在很多人可能只知道HTTP2不知道SPDY。所以也是向协议致敬，因为它是鼻祖。

第二，大部分老客户端只支持SPDY，比如Android 4.4之前，IOS仍然支持SPDY。为了兼容老版本，提高性能，同时支持SPDY和HTTP2。

它有三个特点。

第一，复用。在一条链路上同时发送多个请求，这些请求在协议级别上可以是独立的，也可以是相互依赖的。比如先处理第二个请求，可以提前返回。与HTTP1.1相比，它在管道化方面也做出了努力。它允许客户端同时发送多个请求，但是服务器必须严格按照顺序返回，否则就会乱序。它不知道哪个请求对应哪个响应。这会导致即使先处理第三个请求也无法提前返回；或者已经处理了四个请求，但是第三个请求丢失了，那么整个顺序就会乱序。HTTP2最强大的特性是复用，可以发送一百个请求，甚至可以将一百多个请求设置在一起。

关于SPDY和HTTP2，两个你可能容易忽略的东西。第一点是头压缩。压缩后的数据和宣传页面大概会有89%或90%的压缩比，但事实真的是这样吗？通过测试发现，当一个TCP连接发送第一个请求时，当时HTTP2的压缩率只有30%，第二个请求发生时压缩率可以达到60%，第三个请求后可能达到90%，因为SPDY使用的是基于zlib的压缩算法，而HTTP2使用的是基于Hpack的压缩算法，都是基于state 空进行压缩的， 所以如果信息比较冗余和冗余，那么第一个请求发生的时候，头就没那么冗余了，压缩比可能只有30%。

这给了我们一个性能优化的启发，就是如果一个页面要放在下一个页面上，我们可以提前给页面或者域名的连接发送两个空请求来积累数据。当真正的用户请求发起时，已经达到第三次合作，这样用户的头部压缩比可以达到90%。

二是服务器推送。因为Nginx不支持服务器推送，所以这个应用现在在国内很少使用，但是确实有很大的作用。例如，客户端请求一个包含css和图片的html。正常情况下，解析完html后，css请求和图片请求应该分开发出。但是如果服务器知道页面支持服务器推送，客户端只需要发送一个http请求，服务器直接将CSS和图片一起发送，这样就不会先发送请求的多个响应。这是服务器推送的功能，类似于内联，但是相比内联有两个好处，会影响缓存，增加html的大小，包括后台模板的维护，会增加开发和维护成本。对于客户来说，只是多重要求。

HTTP2实用建议

网上有很多关于HTTP2P的实用建议和理论知识的资料，所以我主要告诉大家一些我们在实践中遇到的经验和体会。

第一，用一个环节或者少用几个环节。不需要动用很多人脉。为什么？第一，连接数少，握手开销少。第二，压缩比高，因为一个连接上积累了很多信息，压缩比会更高。第三，更好的利用TCP的特性。为什么？因为TCP的拥塞控制流量控制是基于单个连接的，如果使用多个连接，特别是在网络拥塞的情况下，会放大拥塞系数，加重网络拥塞。如果使用一个连接，在知道窗口拥塞，响应慢的情况下，不会继续发送，但是在多个连接的情况下，大家可能会尝试发送，会加剧网络拥塞。

第二，少用域名，也是为了更好的利用连接，减少DNS解析时间。

第三，如果一定要用很多域名，尽量把多个域名解析到同一个ip，使用同一个证书。因为客户端实现的角度标准是，如果多个域名可以复用同一个ip，同一个证书，那么我就复用这个连接，我不会创建新的连接。比如chrome浏览器；灵活使用服务器推送代替内联；；关于TLS1.2，HTPP2默认使用TLS1.2之前的版本就不能用了。TLS1.2并不支持所有的密码套件，很多密码套件都被列入黑名单，这也是HTPP2中使用率低的原因之一。HTPP2不能解决所有问题。适用于多元素多连接的场景。如果你的页面本身很简单，只有很少的请求，使用普通的TLS是没有问题的。在这种情况下，它不能提高访问性能。但总的来说，肯定是推荐大家使用的。

用户行为

预建连接

预建连接是最简单有效的速度优化方案。为什么？预建立连接的思想是在用户发起真正的连接之前，预先建立连接。这样对于用户来说，连接带来的成本和延迟是潜移默化的。之前的一系列优化方案，甚至0 RTT握手，还是有一些计算，比如验票。

那么如何预先建立连接呢？有两种方法。

第一点是通过链接头标签告诉浏览器，比如连接，就是服务器可以返回；或者告诉浏览器该页面可能需要访问下一个页面，然后提前和我建立预连接。这可以通过支持链接头的浏览器来实现。不支持这个功能怎么办？

第二点是通过控制页面JS。比如后台页面有一个JS，你可以为了即将到来的页面提前和它建立好联系。当用户发起请求时，JS已经预先为其建立了连接。有很多场景。第一个是首页可以提前预建子页面连接。比如百度首页很简单，搜索结果千差万别，但是搜索结果的网址也可以用AA.com固定，方便建立连接；第二个QQ 空房间，可能有些用户会在QQ 空房间打开相册，有些用户会经常去逛商场挂件和商场逛礼品，所以我们可以根据用户经常去的页面提前为它建立不同的直接预连接，预建的连接也可能随着时间的推移而断开。

那么如何避免呢？可以使用长连接保持。比如浏览器HTTP2会在三分钟以上断网，HTTP会在五分钟以上断网。为了保持长连接，我们可以使用JS定期请求这些页面保持长连接。在这种情况下，连接就相当于一直保持用户在访问过程中建立的状态，这也是预建连接的好处之一。

关于HTTPS速度的一个基本结论是，HTTPS的访问速度可以超越HTTP1.1，最关键最核心的一点是，HTTPS可以使用复用，而HTTP1.1不能。至于优化手段节点，如上图，这是两年前的数据，他们的优化策略是一样的，包括HTTP2和SPDY，没有本质区别。

HTTP2是未来吗？

提到HTTP2的一些强特性对我们很有帮助。如今，HTTP2被认为是互联网的下一代协议，但它真的是我们的未来吗？或者说HTTP2是未来十年最权威最主导的协议？答案是肯定的。是的。因为它的很多特性，比如复用，头压缩，服务器推送，优先级等等。，它的设计非常先进，性能非常优秀，解决了很多性能问题。

但答案也可以是否定的，为什么呢？因为现在的HTTP2是基于TCP和TLS协议的，所以存在一些问题。

第一，TCP协议握手三次。虽然它可以支持TFO，TFO需要操作系统的支持。TFO需要一个额外的RTT来握手，当它第一次建立连接来获取COOKIE时。另外，TLS1.3支持0RTT握手，但是TLS不验证TCP头，TCP头可能被篡改，比如修改窗口数，修改序列号等。，并可能被劫持。

最大的问题是TCP的队列头阻塞。比如我们传输一段，如果第二段丢失了，传输就失败了。为了保证它的可靠性和有序性，我们需要等到第二个数据段到达后，才能传输到应用层。不幸的是，由于HTTP2复用的特性，如果在一个TCP平台上发送50个假设的请求，会加剧队列头阻塞问题。关于TCP的重传，重传序列号和原序列号相同，会导致重传的模糊性。关于拥塞控制，需要升级操作系统，但是TCP的升级成本高，需要用户和网络设备中间商升级支持。

所以从协议层面来说，HTTP2并不是未来十年最占优势或者最权威的协议，那么什么是非常有竞争力的协议呢？就是QUIC协议，用UDP实现HTTP2。以下是它的特点。

拥抱QUIC协议

它支持HTTP2的所有特性，如复用、队列头阻塞、头压缩和服务器推送；。使用TLS 1.3支持0RTT握手；使用UDP传输来使用；基于包加密，对包头的一致性进行验证，一旦被修改就能被发现。

对于我上面提到的协议优化，腾讯云也给予了很好的支持。另外，我们的腾讯云CLB也正式支持QUIC协议，平均性能提升了15%以上。欢迎试用。

作者介绍罗成，2011年毕业于浙江大学，2011-2015年就职于百度运维部，主要负责文件分发、统一访问、安全搜索等事务。2015年至今就职于腾讯，腾讯TEG基础设施部，高级工程师。目前主要负责腾讯STGW(腾讯安全云网关)。对HTTPS、SPDY、HTTP2、QUIC等应用层协议、高性能服务器技术、云网络技术、用户访问速度、分布式文件传输等有深入了解。

今日荐文

点击下图阅读。

为什么30岁的工程师容易跳槽？