网络基础

RTT

往返时间（Round-trip Time，RTT）在计算机网络中也是一个重要的性能指标，它表示从发送端发送数据开始，到发送端收到来自接收端的确认（接收端收到数据后便立即发送确认），总共经历的时延。

RTT=客户端最早收到服务端响应时间点 - 客户端最后发送时间点

HTTP1.0

每个请求都需要重新进行握手，传输完成之后就关闭这条TCL链接。同一时间仅会发送4-6个TCP链接。

1.0的缺陷显而易见，就是每个文件都要重新建立TCP链接，非常消耗时间与资源。

HTTP1.1

为了优化1.0的问题，1.1协议允许在一个TCP链接，发起多次HTTP请求，以减少TCP链接的消耗。

所以针对HTTP1.1前端有多种优化手段,比如:

域名分片突破链接限制
合并文件
内联资源
图片雪碧图

Chrome允许开设最多6个TCP链接用于HTTP请求。在Chrome中，浏览器是动态分配请求，以避免HTTP队头阻塞。

HTTP2

HTTP2协议使用了帧的概念。服务端与浏览器建立了一条TCP链接之后，所有的文件全部变成二进制的帧进行传输（Multiplexing 多路传输特性）。客户端在接到这些帧之后进行数据拼装。

之前说过，由于HTTP1.1是依次请求文件的，而HTTP2是按照数据帧来请求。虽然性能有提高，但是，由于仅在一个TCP链接上做数据处理，这个会造成TCP队头阻塞问题。

因为虽然是帧数据，但数据还是按照有序数据队列发出，客户端依次接收数据，如果丢了某个序号TCP包，浏览器会再次等待这个包重新发送。而这个包后续的数据都会被暂存，这样就无法处理后续的数据，就算后面的帧能组装出其他文件，也会因为这个问题而无法得到有效处理。

服务器推送

传统的预加载

<link rel="preload" href="/styles.css" as="style">

大家都会采用preload方式预加载后续所需要的资源，但这样加载还是会消耗请求资源。

HTTP2服务器推送

nginx的实现

server {
    listen 443 ssl http2;
    ...
    location / {
      ...
      http2_push /style.css;
      http2_push /example.png;
    }
}

动态推送

后台在响应请求的时候，生成Link命令。然后将需要推送的文件附带上即可。

Link: </styles.css>; rel=preload; as=style, </example.png>; rel=preload; as=image

动态推送的nginx配置

server {
    listen 443 ssl http2;

    # ...

    root /var/www/html;

    location = / {
        proxy_pass http://upstream;
        http2_push_preload on;
    }
}

HTTP3

HTTP3是包含了HTTP2特性，而基于QUIC新一代的协议，旨在降低带宽成本，提高用户访问速度等等。

使用HTTP3可以节约客户端的RTT，节约重传数据，避免TCP队头阻塞。

QUIC

QUIC是快速UDP网络连接（英语：Quick UDP Internet Connections）的缩写，这是一种实验性的传输层网络传输协议，由Google公司开发，在2013年实现。QUIC使用UDP协议，它在两个端点间创建连接，且支持多路复用连接。在设计之初，QUIC希望能够提供等同于SSL/TLS层级的网络安全保护，减少数据传输及创建连接时的延迟时间，双向控制带宽，以避免网络拥塞。Google希望使用这个协议来取代TCP协议，使网页传输速度加快，计划将QUIC提交至互联网工程任务小组（IETF），让它成为下一代的正式网络规范。

先简答说下使用QUIC有哪些优点：

可以进行重传与恢复
安全性：每个包可以独立的使用IV进行加密或认证处理
0-RTT握手：会保存一个会话密钥，方便网络间迁移

但是 QUIC的缺点也很明显，现在的网络设施基建都是以TCP为基础构建的,所以基建对于UDP包的带宽是预计不足的。

为了避免UDP丢包问题，QUIC协议拥有一个向前纠错 (Forward Error Correction，FEC)特性，这个设计类似Raid，在丢包之后，可以使用其他包进行恢复。不过，恢复的包有限，超过了一定数量无法恢复，只能进行重传。

了解HTTP1 1.1 23协议，拥抱HTTP3来临