# 传输链路
经过客户端缓存的节流、DNS服务的解析指引，程序发出的请求流量便正式离开客户端，踏上以服务器为目的地的旅途了，这个过程就是本节的主角：传输链路。
可能不少人的第一直觉会认为传输链路是开发者完全不可控的因素，网络路由跳点的数量、运营商铺设线路的质量决定了线路带宽的大小、速率的高低。然而事实并非如此，程序发出的请求能否与应用层、传输层协议提倡的方式相匹配，也会对传输的效率有极大影响。最容易体现这点的是那些前端网页的优化技巧，只要简单搜索一下，就能找到很多以优化链路传输为目的的前端设计原则，譬如经典的雅虎YSlow-23条规则[1]中与传输相关的内容如下。
- 减少请求数量（Minimize HTTP Requests）：请求每次都需要建立通信链路进行数据传输，这些开销很昂贵，减少请求的数量可有效提高访问性能，对于前端开发者，可用于减少请求数量的手段包括：
- 雪碧图（CSS Sprite）
- CSS、JS文件合并/内联（Concatenation/Inline）
- 分段文档（Multipart Document）
- 媒体（图片、音频）内联（Data Base64 URI）
- 合并Ajax请求（Batch Ajax Request）
- 扩大并发请求数（Split Components Across Domain）：对于每个域名，现代浏览器（Chrome、Firefox）一般支持6个（IE为8～13个）并发请求。如果希望更快地加载大量图片或其他资源，需要进行域名分片（Domain Sharding），将图片同步到不同主机或者同一个主机的不同域名上。
- 启用压缩传输（GZip Component）：启用压缩能够大幅度减少需要在网络上传输的内容的大小，节省网络流量。
- 避免页面重定向（Avoid Redirect）：当页面发生了重定向，就会造成整个文档的传输延迟。在HTML文档到达之前，页面中不会呈现任何东西，降低了用户体验。
- 按重要性调节资源优先级（Put Stylesheet at the Top，Put Script at the Bottom）：将重要的、马上就要使用的、对客户端展示影响大的资源，放在HTML的头部，以便优先下载。
……
这些原则在今天仍有一定价值，但若干年后再回头看它们，其中多数原则大概率会变成Tricks，甚至成了反模式。导致这种变化的原因是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连接数量，这是有数据统计作为支撑的。经测试HTTP Archive对最近五年数百万个URL地址采样得出的结论：在页面平均请求没有改变的情况下（桌面端下降3.8%，移动端上升1.4%），TCP连接正在持续且幅度较大地下降（桌面端下降36.4%，移动端下降28.6%）。
但是开发人员节省TCP连接的优化措施并非只有好处，它们也带来了诸多不良的副作用。
- 如果你用雪碧图将多张图片合并，意味着任何场景下哪怕只用到其中一张小图，也必须完整加载整张大图片；任何场景下哪怕对一张小图要进行修改，都会导致整个缓存失效，类似地，样式、脚本等其他文件的合并也会存在同样的问题。
- 如果你使用了媒体内嵌，除了要承受Base64编码导致传输容量膨胀1/3的代价外（Base64以8位表示6位数据），也将无法有效利用缓存。
- 如果你合并了异步请求，这就会导致所有请求的返回时间都受最慢的那个请求的拖累，导致整体响应速度下降。
- 如果你把图片放到不同子域下面，将会导致更大的DNS解析负担，而且浏览器对两个不同子域下的同一图片必须持有两份缓存，也使得缓存效率下降。
由此可见，一旦在技术根基上出现问题，依赖使用者通过各种Tricks去解决，无论如何都难以摆脱“两害相权取其轻”的权衡困境，否则这就不是Tricks而是一种标准的设计模式了。
在另一方面，HTTP的设计者们并不是没有尝试过在协议层面去解决连接成本过高的问题，即使HTTP协议的最初版本（指HTTP/1.0，忽略非正式的HTTP/0.9版本）就已经支持了[1]连接复用技术，即今天大家所熟知的持久连接（Persistent Connection），也称为连接Keep-Alive机制。持久连接的原理是让客户端对同一个域名长期持有一个或多个不会用完即断的TCP连接。典型做法是在客户端维护一个FIFO队列，在每次取完数据[2]之后一段时间内先不自动断开连接，以便在获取下一个资源时直接复用，避免创建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）技术。
有了多路复用的支持，HTTP/2就可以对每个域名只维持一个TCP连接（One Connection Per Origin）并以任意顺序传输任意数量的资源了，这样既减轻了服务器的连接压力，也不需要开发者去考虑域名分片这种事情来突破浏览器对每个域名最多6个的连接数限制。更重要的是，没有TCP连接数的压力，就无须刻意压缩HTTP请求，所有通过合并、内联文件（无论是图片、样式、脚本）以减少请求数的需求都不再成立，甚至会被当作徒增副作用的反模式。
说这是反模式，也许还有一些前端开发人员会不同意，认为HTTP请求少一些总是好的，减少请求数量，最起码也减少了传输中耗费的Header。这里必须先承认一个事实，在HTTP传输中的Header占传输成本的比重是相当大的，对于许多小资源，甚至可能出现Header的容量比Body还要大，以至于在HTTP/2中必须专门考虑如何进行Header压缩的问题。但是，以下几个因素决定了通过合并资源文件减少请求数，对节省Header成本并没有太大帮助。
- Header的传输成本在Ajax（尤其是只返回少量数据的请求）请求中是比重很大的开销，但在图片、样式、脚本这些静态资源的请求中，通常并不占主要地位。
- 在HTTP/2中Header压缩的原理是基于字典编码的信息复用。简而言之，同一个连接上产生的请求和响应越多，动态字典积累得越全，头部压缩效果也就越好。所以HTTP/2是单域名单连接的机制，合并资源和域名分片反而不利于提升Header压缩效果。
- 与HTTP/1.x相比，HTTP/2本身变得更适合传输小资源，譬如传输1000张10KB的小图，HTTP/2肯定要比HTTP/1.x快，但传输10张1000KB的大图，则大概率HTTP/1.x会更快些。这是TCP连接数量（相当于多点下载）的影响，但更多是由TCP协议可靠传输机制导致的，一个错误的TCP包会导致所有的流都必须等待这个包重传成功，这是HTTP/3要解决的问题。因此，把小文件合并成大文件，在HTTP/2下是毫无益处的。
# 传输压缩
HTTP很早就支持了GZip压缩，因为HTTP传输的内容主要是文本数据，譬如HTML、CSS、Script等，而对于文本数据启用压缩的收益是非常高的，传输数据量一般会降至原有的20%左右。对于那些不适合压缩的资源，Web服务器能根据MIME类型自动判断是否对响应进行压缩，这样，已经采用过压缩算法存储的资源，如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 Connection，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协议接到数据包丢失或损坏通知之前，可能已经收到了大量的正确数据，但是在纠正错误之前，其他的正常请求都会等待甚至被重发，这也是在4.3.1节中笔者提到HTTP/2未能解决传输大文件慢的根本原因。
QUIC的另一个设计目标是面向移动设备的专门支持，由于以前TCP、UDP传输协议在设计时根本不可能设想到今天移动设备盛行的场景，因此肯定不会有任何专门的支持。QUIC在移动设备上的优势体现在网络切换时的响应速度上，譬如当移动设备在不同Wi-Fi热点之间切换，或者从Wi-Fi切换到移动网络时，如果使用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%的网站的支持。可以肯定地说，目前网络链路传输领域正处于新旧交替的时代，许多既有设备、程序、知识都会在未来几年时间里出现重大更新。