分布式软件架构——传输链路

传输链路

链路指无源的点到点的物理连接。链路是计算机网络中的一个重要概念，它指的是连接两个网络设备的物理或逻辑路径。简单来说，链路就是电信号或数据在网络中传输的路径。在计算机网络中，链路可以分为物理链路和逻辑链路两种。物理链路是指连接两个网络设备的物理媒介，例如网线、光纤等。逻辑链路则是指通过网络协议建立的逻辑连接，例如TCP/IP协议中的连接。

链路是计算机网络中非常重要的概念，它负责连接网络设备并保证数据的可靠传输。

前端优化

以优化链路传输为目的的前端设计原则未来或许不再使用，比如

1. Minimize HTTP Requests，减少请求数量
   减少请求数量的手段有：

• a.雪碧图（CSS Sprites）
• b.CSS、JS文件合并/内联（Concatenation/Inline）
• c.分段文档（Multipart Document）
• d.媒体（图片、音频）内联（Data Base64 URI）
• e.合并Ajax请求（Batch Ajax Request）
• f. … …

2. Split Components Across Domains，扩大并发请求数
   现代浏览器（Chrome、Firefox）一般可以为每个域名支持6个（IE为8～13个）并发请求。如果想要更快地加载大量图片或其他资源，就需要进行域名分片（Domain Sharding），将图片同步到不同主机或者同一个主机的不同域名上。
3. GZip Components，启用压缩传输
   启用压缩传输能够大幅减少需要在网络上传输的内容大小，节省流量。
4. Avoid Redirects，避免页面重定向
   当页面发生重定向，就会延迟整个文档的传输。
5. Put Stylesheets at the Top, Put Scripts at the Bottom，按重要性调节资源优先级
   将重要的资源放在HTML的头部，以便优先下载。
6. … …

连接数优化

HTTP是以TCP为传输层的应用层协议，但HTTP over TCP这种搭配，只能说是TCP目前在互联网的统治地位所造就的结果，而不能说它们两者配合工作就是合适的。

• 一方面，HTTP传输对象（HTML、JS、CSS、图片等）的主要特征是数量多、时间短、资源小、切换快。
• 另一方面，TCP协议要求三次握手完成后才能开始数据传输，TCP还有慢启动特性，导致通信建立连接时传输速率最低，后面逐步加速稳定。

由于TCP协议本身是面向长时间、大数据传输来设计的，所以只有在一段较长的时间尺度内，TCP协议才能展现出稳定性和可靠性的优势，不会因为建立连接的成本太高，成为了使用瓶颈。

开发Tricks的使用困境

为缓解HTTP与TCP之间的矛盾，程序猿们一方面致力于减少发出的请求数量，另一方面致力于增加客户端到服务端的连接数量。即前面提到的Minimize HTTP Requests和Split Components Across Domains两条优化措施的根本依据。

HTTP Archive对近2016～2020年数百万个URL地址进行了采样，得出一个结论：页面平均请求没有改变的情况下（桌面端下降3.8%，移动端上升1.4%），TCP连接正在持续且幅度较大地下降（桌面端下降36.4%，移动端下降28.6%），如下图

开发Tricks可以节省TCP连接外，也会带来不少副作用。比如，

• CSS Sprites合并多张图片后，只要使用其中一张小图片，也必须加载整个大图片；如果某张小图片需要修改，会导致整个大图的缓存失效；样式、脚本等文件的合并同理；
• 媒体内嵌时，除了要承受Base64编码导致的传输容量膨胀1/3的代价以外，也会无法有效利用缓存；
• 合并异步请求后，导致所有请求的返回时间，都要受最慢请求的拖累，页面整体响应速度下降；
• 图片放到不同子域下面，将会导致更大的DNS解析负担；

连接复用技术的优势和缺陷

HTTP连接复用技术，也即持久连接（Persistent Connection），或者叫连接Keep-Alive机制。它的原理是，让客户端对同一个域名长期持有一个或多个不会用完即断的TCP连接，典型做法是在客户端维护一个FIFO队列，每次取完数据之后的一段时间内，不自动断开连接，以便获取下一个资源时可以直接服用，避免创建TCP连接的成本。
但是，连接复用技术最明显的副作用就是“队首阻塞”（Head-of-Line Blocking）问题。

解决方案：HTTP/2的多路复用技术
HTTP/1.x中，HTTP请求就是传输过程中最小粒度的信息单位，难以重组出有效信息；
HTTP/2中，帧（Frame）才是最小粒度的信息单位，它可以用来描述各种数据，比如请求的Headers、Body，或者用来做控制标识（打开流、关闭流）。
其中流（Stream），是一个逻辑上的数据通道概念，每个帧都附带有一个流ID，以标识这个帧数语哪个流。

与HTTP/1.x相反，HTTP/2本身反而变得更适合传输小资源，比如传输1000张10K的小图，HTTP/2要比HTTP/1.x快，但传输10张1000K的大图，则应该HTTP/1.x会更快。

传输压缩

HTTP很早就支持了GZip压缩，因为HTTP传输的主要内容，比如HTML、CSS、Script等，主要是本文数据，因此对于文本数据启用压缩的收益是非常高的，传输数据量一般会降至原有的20%左右。而对于不适合压缩的资源，Web服务器则能根据MIME（Multipurpose Internet Mail Extensions）类型，来自动判断是否对响应进行压缩。
几种压缩方式：

• 静态预压缩（Static Precompression）：把静态资源预先压缩为.gz文件的形式存放起来；
• 即时压缩（On-The-Fly Compression）：在内存的数据流中完成；

持久连接机制不再依靠TCP连接是否关闭，来判断资源请求是否结束了。它会重用同一个连接，以便向同一个域名请求多个资源。
这个机制最初（HTTP/1.0）就是根据Content-Length判断传输资源是否已经结束。但启动即时压缩后就无法给出Content-Length。依靠Content-Length来判断传输结束是有缺陷的。HTTP1.1版本修复了缺陷，增加了另一种“分块传输编码”（Chunked Transfer Encoding）的资源结束判断机制，彻底解决了Content-Length与持久连接的冲突问题。

快速UDP网络连接

要想从根本上改进HTTP，就必须直接替换掉HTTP over TCP的根基。使用UDP协议替换TCP传输协议就是一种思路，2013年，Google在它的服务器（Google.com、YouTube.com等）启用了名为快速UDP网络连接（Quick UDP Internet Connections,QUIC）的传输协议。2018年末，IETF正式批准了HTTP over QUIC使用HTTP/3的版本号，确立为最新一代的互联网标准。

QUIC自己实现的好处是能对每个流能做单独的控制，如果其中一个流发生错误，协议栈仍然可以独立地继续为其他流提供服务。
QUIC的另一个设计目标是面向移动设备的专门支持，在移动设备上的主要优势体现在网络切换的响应速度上，QUIC提出了连接标识符的概念，可以唯一标识客户端与服务器端之间的连接，而无需依靠IP地址。