传输链路

传输链路优化(Transmission Optimization)

今天的传输链路链路优化原则,在若干年后的未来再回头看它们时,其中多数已经成了奇技淫巧,有些甚至成了反模式

经过客户端缓存的节流、经过DNS服务的解析指引,程序发出的请求流量便正式离开客户端,踏上以服务器为目的地的旅途了,这个过程就是本节的主角:传输链路。

可能不少人的第一直觉会认为传输链路是开发者完全不可控的因素,网络路由跳点的数量、运营商铺设线路的质量决定了线路带宽的大小、速率的高低。然而事实并非如此,程序发出的请求能否与应用层、传输层协议提倡的方式相匹配,对传输的效率也会有极大影响。最容易体现这点的是那些前端网页的优化技巧,只要简单搜索一下,就能找到很多以优化链路传输为目的的前端设计原则,譬如经典的雅虎YSlow-23条规则中与传输相关的内容如下。

  1. Minimize HTTP Requests。
    减少请求数量:请求每次都需要建立通信链路进行数据传输,这些开销很昂贵,减少请求的数量可有效的提高访问性能,对于前端开发者,可能用来减少请求数量的手段包括:
  2. Split Components Across Domains。
    扩大并发请求数:现代浏览器(Chrome、Firefox)一般对每个域名支持6个(IE为8-13个)并发请求,如果希望更快地加载大量图片或其他资源,需要进行域名分片(Domain Sharding),将图片同步到不同主机或者同一个主机的不同域名上。
  3. GZip Components。
    启用压缩传输:启用压缩能够大幅度减少需要在网络上传输内容的大小,节省网络流量。
  4. Avoid Redirects。
    避免页面重定向:当页面发生了重定向,就会延迟整个文档的传输。在HTML文档到达之前,页面中不会呈现任何东西,降低了用户体验。
  5. Put Stylesheets at the Top,Put Scripts at the Bottom。
    按重要性调节资源优先级:将重要的、马上就要使用的、对客户端展示影响大的资源,放在HTML的头部,以便优先下载。
  6. …………

这些原则在今天暂时仍算得上有一定价值,但在若干年后再回头看它们,大概率其中多数已经成了奇技淫巧,有些甚至成了反模式。导致这种变化的原因是HTTP协议还在持续发展,从20世纪90年代的HTTP/1.0和HTTP/1.1,到2015年发布的HTTP/2,再到2019年的HTTP/3,由于HTTP协议本身的变化,使得“适合HTTP传输的请求”的特征也在不断变化。

连接数优化

我们知道HTTP(特指HTTP/3以前)是以TCP为传输层的应用层协议,但HTTP over TCP这种搭配只能说是TCP在当今网络中统治性地位所造就的结果,而不能说它们两者配合工作就是合适的。回想一下你上网平均每个页面停留的时间,以及每个页面中包含的资源(HTML、JS、CSS、图片等)数量,可以总结出HTTP传输对象的主要特征是数量多、时间短、资源小、切换快。另一方面,TCP协议要求必须在三次握手完成之后才能开始数据传输,这是一个可能高达“百毫秒”为计时尺度的事件;另外,TCP还有慢启动的特性,使得刚刚建立连接时传输速度是最低的,后面再逐步加速直至稳定。由于TCP协议本身是面向于长时间、大数据传输来设计的,在长时间尺度下,它连接建立的高昂成本才不至于成为瓶颈,它的稳定性和可靠性的优势才能展现出来。因此,可以说HTTP over TCP这种搭配在目标特征上确实是有矛盾的,以至于HTTP/1.x时代,大量短而小的TCP连接导致了网络性能的瓶颈。为了缓解HTTP与TCP之间的矛盾,聪明的程序员们一面致力于减少发出的请求数量,另外一方面也致力于增加客户端到服务端的连接数量,这就是上面Yslow规则中“Minimize HTTP Requests”与“Split Components Across Domains”两条优化措施的根本依据所在。

通过前端开发者的各种Tricks,的确能够减少消耗TCP连接数量,这是有数据统计作为支撑的。图4-2和图4-3展示了 HTTP Archive对最近五年来数百万个URL地址采样得出的结论:页面平均请求没有改变的情况下(桌面端下降3.8%,移动端上升1.4%),TCP连接正在持续且幅度较大地下降(桌面端下降36.4%,移动端下降28.6%)。

图4-2 HTTP平均请求数量,70余个,没有明显变化

图4-3 TCP连接数量,约15个,有明显下降趋势

但是,通过开发人员的Tricks来节省TCP连接,这样的优化措施并非只有好处,它们同时也带来了诸多不良的副作用:

  • 如果你用CSS Sprites将多张图片合并,意味着任何场景下哪怕只用到其中一张小图,也必须完整加载整个大图片;任何场景下哪怕一张小图要进行修改,都会导致整个缓存失效,类似地,样式、脚本等其他文件的合并也会造成同样的问题。
  • 如果你使用了媒体内嵌,除了要承受Base64编码导致传输容量膨胀1/3的代价外(Base64以8 bit表示6 bit数据),也将无法有效利用缓存。
  • 如果你合并了异步请求,这就会导致所有请求返回时间都受最慢的那个请求的拖累,整体响应速度下降.
  • 如果你把图片放到不同子域下面,将会导致更大的DNS解析负担,而且浏览器对两个不同子域下的同一图片必须持有两份缓存,也使得缓存效率的下降。
  • ……

由此可见,一旦在技术根基上出现问题,依赖使用者通过各种Tricks去解决,无论如何都难以摆脱“两害相权取其轻”的权衡困境,否则这就不是Tricks而是会成为一种标准的设计模式了。

在另一方面,HTTP的设计者们并不是没有尝试过在协议层面去解决连接成本过高的问题,即使是HTTP协议的最初版本(指HTTP/1.0,忽略非正式的HTTP/0.9版本)就已经支持了(连接复用技术在HTTP/1.0中并不是默认开启的,是在HTTP/1.1中变为默认开启)连接复用技术,即今天大家所熟知的持久连接(Persistent Connection),也称为连接Keep-Alive机制。持久连接的原理是让客户端对同一个域名长期持有一个或多个不会用完即断的TCP连接。典型做法是在客户端维护一个FIFO队列,每次取完数据(如何在不断开连接下判断取完数据将会放到稍后传输压缩部分去讨论)之后一段时间内不自动断开连接,以便获取下一个资源时直接复用,避免创建TCP连接的成本。

但是,连接复用技术依然是不完美的,最明显的副作用是“队首阻塞”(Head-of-Line Blocking)问题。请设想以下场景:浏览器有10个资源需要从服务器中获取,此时它将10个资源放入队列,入列顺序只能是按照浏览器预见这些资源的先后顺序来决定的。但如果这10个资源中的第1个就让服务器陷入长时间运算状态会怎样呢?当它的请求被发送到服务端之后,服务端开始计算,而运算结果出来之前TCP连接中并没有任何数据返回,此时后面9个资源都必须阻塞等待。因为服务端虽然可以并行处理另外9个请求(譬如第1个是复杂运算请求,消耗CPU资源,第2个是数据库访问,消耗数据库资源,第3个是访问某张图片,消耗磁盘I/O资源,这就很适合并行),但问题是处理结果无法及时返回客户端,服务端不能哪个请求先完成就返回哪个,更不可能将所有要返回的资源混杂到一起交叉传输,原因是只使用一个TCP连接来传输多个资源的话,如果顺序乱了,客户端就很难区分哪个数据包归属哪个资源了。

2014年,IETF发布的RFC 7230中提出了名为“HTTP管道”(HTTP Pipelining)复用技术,试图在HTTP服务器中也建立类似客户端的FIFO队列,让客户端一次将所有要请求的资源名单全部发给服务端,由服务端来安排返回顺序,管理传输队列。无论队列维护在服务端还是客户端,其实都无法完全避免队首阻塞的问题,但由于服务端能够较为准确地评估资源消耗情况,进而能够更紧凑地安排资源传输,保证队列中两项工作之间尽量减少空隙,甚至做到并行化传输,从而提升链路传输的效率。可是,由于HTTP管道需要多方共同支持,协调起来相当复杂,推广得并不算成功。

队首阻塞问题一直持续到第二代的HTTP协议,即HTTP/2发布后才算是被比较完美地解决。在HTTP/1.x中,HTTP请求就是传输过程中最小粒度的信息单位了,所以如果将多个请求切碎,再混杂在一块传输,客户端势必难以分辨重组出有效信息。而在HTTP/2中,帧(Frame)才是最小粒度的信息单位,它可以用来描述各种数据,譬如请求的Headers、Body,或者用来做控制标识,譬如打开流、关闭流。这里说的流(Stream)是一个逻辑上的数据通道概念,每个帧都附带一个流ID以标识这个帧属于哪个流。这样,在同一个TCP连接中传输的多个数据帧就可以根据流ID轻易区分出开来,在客户端毫不费力地将不同流中的数据重组出不同HTTP请求和响应报文来。这项设计是HTTP/2的最重要的技术特征一,被称为HTTP/2 多路复用(HTTP/2 Multiplexing)技术,如图4-4所示。

图4-4 HTTP/2的多路复用(图片来源

有了多路复用的支持,HTTP/2就可以对每个域名只维持一个TCP连接(One Connection Per Origin)来以任意顺序传输任意数量的资源,既减轻了服务器的连接压力,开发者也不用去考虑域名分片这种事情来突破浏览器对每个域名最多6个连接数限制了。而更重要的是,没有了TCP连接数的压力,就无须刻意压缩HTTP请求了,所有通过合并、内联文件(无论是图片、样式、脚本)以减少请求数的需求都不再成立,甚至反而是徒增副作用的反模式。

说这是反模式,也许还有一些前端开发者会不同意,认为HTTP请求少一些总是好的,减少请求数量,最起码还减少了传输中耗费的Headers。必须先承认一个事实,在HTTP传输中Headers占传输成本的比重是相当的大,对于许多小资源,甚至可能出现Headers的容量比Body的还要大,以至于在HTTP/2中必须专门考虑如何进行Header压缩的问题。但是,以下几个因素决定了通过合并资源文件减少请求数,对节省Headers成本也并没有太大帮助:

  • Header的传输成本在Ajax(尤其是只返回少量数据的请求)请求中可能是比重很大的开销,但在图片、样式、脚本这些静态资源的请求中,通常并不占主要。
  • 在HTTP/2中Header压缩的原理是基于字典编码的信息复用,简而言之是同一个连接上产生的请求和响应越多,动态字典积累得越全,头部压缩效果也就越好。所以HTTP/2是单域名单连接的机制,合并资源和域名分片反而对性能提升不利。
  • 与HTTP/1.x相反,HTTP/2本身反而变得更适合传输小资源了,譬如传输1000张10K的小图,HTTP/2要比HTTP/1.x快,但传输10张1000K的大图,则应该HTTP/1.x会更快。这一方面是TCP连接数量(相当于多点下载)的影响,更多的是由于TCP协议可靠传输机制导致的,一个错误的TCP包会导致所有的流都必须等待这个包重传成功,这个问题就是HTTP/3要解决的目标了。因此,把小文件合并成大文件,在HTTP/2下是毫无好处的。

传输压缩

我们接下来再来讨论链路优化中缓存、连接之外另一个主要话题:压缩,同时也是为了解决上一节遗留的问题:如何不以断开TCP连接为标志来判断资源已传输完毕。

HTTP很早就支持了GZip压缩,由于HTTP传输的主要内容,譬如HTML、CSS、Script等,主要是文本数据,对于文本数据启用压缩的收益是非常高的,传输数据量一般会降至原有的20%左右。而对于那些不适合压缩的资源,Web服务器则能根据MINE类型来自动判断是否对响应进行压缩,这样,已经采用过压缩算法存储的资源,如JPEG、PNG图片,便不会被二次压缩,空耗性能。

不过,大概就没有多少人想过压缩与之前提到的用于节约TCP的持久连接机制是存在冲突的。在网络时代的早期,服务器处理能力还很薄弱,为了启用压缩,会是把静态资源先预先压缩为.gz文件的形式存放起来,当客户端可以接受压缩版本的资源时(请求的Header中包含Accept-Encoding: gzip)就返回压缩后的版本(响应的Header中包含Content-Encoding: gzip),否则就返回未压缩的原版,这种方式被称为“静态预压缩”(Static Precompression)。而现代的Web服务器处理能力有了大幅提升,已经没有人再采用麻烦的预压缩方式了,都是由服务器对符合条件的请求将在输出时进行“即时压缩”(On-The-Fly Compression),整个压缩过程全部在内存的数据流中完成,不必等资源压缩完成再返回响应,这样可以显著提高“首字节时间”(Time To First Byte,TTFB),改善Web性能体验。而这个过程中唯一不好的地方就是服务器再也没有办法给出Content-Length这个响应Header了,因为输出Header时服务器还不知道压缩后资源的确切大小。

到这里,大家想明白即时压缩与持久链接的冲突在哪了吗?持久链接机制不再依靠TCP连接是否关闭来判断资源请求是否结束,它会重用同一个连接以便向同一个域名请求多个资源,这样,客户端就必须要有除了关闭连接之外的其他机制来判断一个资源什么时候算传递完毕,这个机制最初(在HTTP/1.0时)就只有Content-Length,即靠着请求Header中明确给出资源的长度,传输到达该长度即宣告一个资源的传输已结束。由于启用即时压缩后就无法给出Content-Length了,如果是HTTP/1.0的话,持久链接和即时压缩只能二选其一,事实上在HTTP/1.0中两者都支持,却默认都是不启用的。依靠Content-Length来判断传输结束的缺陷,不仅仅在于即时压缩这一种场景,譬如对于动态内容(Ajax、PHP、JSP等输出),服务器也同样无法事项得知Content-Length。

HTTP/1.1版本中修复了这个缺陷,增加了另一种“分块传输编码”(Chunked Transfer Encoding)的资源结束判断机制,彻底解决了Content-Length与持久链接的冲突问题。分块编码原理相当简单:在响应Header中加入“Transfer-Encoding: chunked”之后,就代表这个响应报文将采用分块编码。此时,报文中的Body需要改为用一系列“分块”来传输。每个分块包含十六进制的长度值和对应长度的数据内容,长度值独占一行,数据从下一行开始。最后以一个长度值为0的分块来表示资源结束。举个具体例子(例子来自于维基百科,为便于观察,只分块,未压缩):

HTTP/1.1 200 OK
Date: Sat, 11 Apr 2020 04:44:00 GMT
Transfer-Encoding: chunked
Connection: keep-alive

25
This is the data in the first chunk

1C
and this is the second one

3
con

8
sequence

0

根据分块长度可知,前两个分块包含显式的回车换行符(CRLF,即\r\n字符)

"This is the data in the first chunk\r\n"      (37 字符 => 十六进制: 0x25)
"and this is the second one\r\n"               (28 字符 => 十六进制: 0x1C)
"con"                                          (3  字符 => 十六进制: 0x03)
"sequence"                                     (8  字符 => 十六进制: 0x08)

所以解码后的内容为:

This is the data in the first chunk
and this is the second one
consequence

一般来说,Web服务器给出的数据分块大小应该(但并不强制)是一致的,而不是如例子中那样随意。HTTP/1.1通过分块传输解决了即时压缩与持久连接并存的问题,到了HTTP/2,由于多路复用和单域名单连接的设计,已经无须再刻意强去提久链接机制了,但数据压缩仍然有节约传输带宽的重要价值。

快速UDP网络连接

HTTP是应用层协议而不是传输层协议,它的设计原本并不应该过多地考虑底层的传输细节,从职责上讲,持久连接、多路复用、分块编码这些能力,已经或多或少超过了应用层的范畴。要从根本上改进HTTP,必须直接替换掉HTTP over TCP的根基,即TCP传输协议,这便最新一代HTTP/3协议的设计重点。

推动替换TCP协议的先驱者并不是IETF,而是Google公司。目前,世界上只有Google公司具有这样的能力,这并不是因为Google的技术实力雄厚,而是由于它同时持有着占浏览器市场70%份额的Chrome浏览器与占移动领域半壁江山的Android操作系统。

2013年,Google在它的服务器(如Google.com、YouTube.com等)及Chrome浏览器上同时启用了名为“快速UDP网络连接”(Quick UDP Internet Connections,QUIC)的全新传输协议。在2015年,Google将QUIC提交给IETF,并在IETF的推动下对QUIC进行重新规范化(为以示区别,业界习惯将此前的版本称为gQUIC,规范化后的版本称为iQUIC),使其不仅能满足HTTP传输协议,日后还能支持SMTP、DNS、SSH、Telnet、NTP等多种其他上层协议。2018年末,IETF正式批准了HTTP over QUIC使用HTTP/3的版本号,将其确立为最新一代的互联网标准。

从名字上就能看出QUIC会以UDP协议为基础,而UDP协议没有丢包自动重传的特性,因此QUIC的可靠传输能力并不是由底层协议提供,而是完全由自己来实现。由QUIC自己实现的好处是能对每个流能做单独的控制,如果在一个流中发生错误,协议栈仍然可以独立地继续为其他流提供服务。这对提高易出错链路的性能非常有用,因为在大多数情况下,TCP协议接到数据包丢失或损坏通知之前,可能已经收到了大量的正确数据,但是在纠正错误之前,其他的正常请求都会等待甚至被重发,这也是在连接数优化一节中,笔者提到HTTP/2未能解决传输大文件慢的根本原因。

QUIC的另一个设计目标是面向移动设备的专门支持,由于以前TCP、UDP传输协议在设计时根本不可能设想到今天移动设备盛行的场景,因此肯定不会有任何专门的支持。QUIC在移动设备上的优势体现在网络切换时的响应速度上,譬如当移动设备在不同WiFi热点之间切换,或者从WiFi切换到移动网络时,如果使用TCP协议,现存的所有连接都必定会超时、中断,然后根据需要重新创建。这个过程会带来很高的延迟,因为超时和重新握手都需要大量时间。为此,QUIC提出了连接标识符的概念,该标识符可以唯一地标识客户端与服务器之间的连接,而无须依靠IP地址。这样,切换网络后,只需向服务端发送一个包含此标识符的数据包即可重用既有的连接,因为即使用户的IP地址发生变化,原始连接连接标识符依然是有效的。

无论是TCP协议还是HTTP协议,都已经存在了数十年时间。它们积累了大量用户的同时,也承载了很重的技术惯性,要使HTTP从TCP迁移走,即使由Google和IETF来推动依然不是一件容易的事情。一个最显著的问题是互联网基础设施中的许多中间设备,都只面向TCP协议去建造,仅对UDP提供很基础的支持,有的甚至完全阻止UDP的流量。因此,Google在Chromium的网络协议栈中同时启用了QUIC和传统TCP连接,并在QUIC连接失败时以零延迟回退到TCP连接,尽可能让用户无感知地逐步地扩大QUIC的使用面。

根据W3Techs的数据,截至2020年10月,全球已有48.9%的网站支持了HTTP/2协议,按照维基百科中的记录,这个数字在2019年6月时还只是36.5%。在HTTP/3方面,今天也已经得到了7.2%网站的支持。可以肯定地说,目前网络链路传输领域正处于新旧交替的时代,许多既有的设备、程序、知识都会在未来几年时间里出现重大更新。

Kudos to Star
总字数: 6,621 字  最后更新: 1/12/2021, 12:22:02 PM