http2

Posted 2021-03-21 siqi

 

http1 问题
    1. tcp连接数显示（4~6）
        一个浏览器对一个domain发起的tcp是有限时的，每个tcp建立链接也会耗时，同时多个tcp对服务器也会有压力
    2. 线头阻塞问题
        每个tcp链接只能同时处理一个请求（请求-响应），浏览器先先进先出方式（FIFO）处理，上一个没有完成后面就会阻塞。

        HTTP管线化（英语：HTTP pipelining）是将多个HTTP请求（request）整批提交的技术，而在发送过程中不需先等待服务器的回应
        管线化机制须透过永久连线（persistent connection）完成，并且只有 GET 和 HEAD 等要求可以进行管线化，非幂等的方法，例如POST将不会被管线化
        管线化问题：如果第一个请求阻塞，后面的请求也会被阻塞住。
    
        管线化机制须透过永久连线（persistent connection）完成，并且只有 GET 和 HEAD 等要求可以进行管线化，非幂等的方法，例如POST将不会被管线化
        HTTP持久连接（HTTP persistent connection）是使用同一个TCP连接来发送和接收多个HTTP请求/应答，而不是为每一个新的请求/应答打开新的连接的方法
    
        普通模式，即非KeepAlive模式时每个请求/应答客户和服务器都要新建一个连接，完成之后立即断开连接（HTTP协议为无连接的协议）
        当使用Keep-Alive模式（又称持久连接）时，Keep-Alive功能使客户端到服 务器端的连接持续有效，当出现对服务器的后继请求时，Keep-Alive功能避免了建立或者重新建立连接。
    
    3. Header 内容多，相同且没有压缩
    4. 为了尽可能减少请求数，需要做合并文件无形中增大了请求的内容

http2
    1. 二进制分帧层 (Binary Framing Layer)
        二进制传输代替原本的明文传输
        h2的所有字段均小写
    2. 多路复用 (MultiPlexing)
        在一个 TCP 连接上，我们可以向对方不断发送帧，每帧的 stream identifier 的标明这一帧属于哪个流，然后在对方接收时，根据 stream identifier 拼接每个流的所有帧组成一整块数据。
        把 HTTP/1.1 每个请求都当作一个流，那么多个请求变成多个流，请求响应数据分成多个帧，不同流中的帧交错地发送给对方，这就是 HTTP/2 中的多路复用。

        流的概念实现了单连接上多请求 - 响应并行，解决了线头阻塞的问题，减少了 TCP 连接数量和 TCP 连接慢启动造成的问题
    
        所以 http2 对于同一域名只需要创建一个连接，而不是像 http/1.1 那样创建 6~8 个连接
    
    3. 服务端推送 (Server Push)
        客户端可以缓存推送的资源
        客户端可以拒收推送过来的资源
        推送资源可以由不同页面共享
        服务器可以按照优先级推送资源
    
    4. Header 压缩 (HPACK)
        动态字典上下文有关，需要为每个 HTTP/2 连接维护不同的字典
        HTTP/2 使用了一份静态哈夫曼码表（详见），也需要内置在客户端和服务端之中
    5、应用层的重置连接
        对于 HTTP/1 来说，是通过设置 tcp segment 里的 reset flag 来通知对端关闭连接的。这种方式会直接断开连接，下次再发请求就必须重新建立连接。HTTP/2 引入 RST_STREAM 类型的 frame，可以在不断开连接的前提下取消某个 request 的 stream，表现更好。
    
    6. 请求优先级设置
        HTTP/2 里的每个 stream 都可以设置依赖 (Dependency) 和权重，可以按依赖树分配优先级，解决了关键请求被阻塞的问题
    7. 流量控制
        每个 http2 流都拥有自己的公示的流量窗口，它可以限制另一端发送数据。对于每个流来说，两端都必须告诉对方自己还有足够的空间来处理新的数据，而在该窗口被扩大前，另一端只被允许发送这么多数据。
    8. HTTP/1 的几种优化可以弃用
        合并文件、内联资源、雪碧图、域名分片对于 HTTP/2 来说是不必要的，使用 h2 尽可能将资源细粒化，文件分解地尽可能散，不用担心请求数多



SSL/TLS
    SSL:安全套接层(Secure Sockets Layer)
    TLS:传输层安全协议(Transport Layer Security)
    SSL标准化后叫做TLS只是不同阶段的叫法，用来解决http明文传出问题
    SSL 直接在传输控制协议 (TCP) 基础上高效运行

    TLS与SSL在传输层与应用层之间对网络连接进行加密

http协议协商

    HTTP Upgrade
        为了更方便地部署新协议，HTTP/1.1 引入了 Upgrade 机制，它使得客户端和服务端之间可以借助已有的 HTTP 语法升级到其它协议
    
        要发起 HTTP/1.1 协议升级，客户端必须在请求头部中指定这两个字段：
    
        Connection: Upgrade
        Upgrade: protocol-name[/protocol-version]
    
    基于 HTTPS 的协议协商非常简单，多了 TLS 之后，双方必须等到成功建立 TLS 连接之后才能发送应用数据。而要建立 TLS 连接，本来就要进行 CipherSuite 等参数的协商。
    引入 HTTP/2 之后，需要做的只是在原本的协商机制中把对 HTTP 协议的协商加进去。
    
    ALPN：应用层协议协商
        客户端在建立 TLS 连接的 Client Hello 握手中，通过 ALPN 扩展列出了自己支持的各种应用层协议
        如果服务端支持 HTTP/2，在 Server Hello 中指定 ALPN 的结果为 h2 就可以了；如果服务端不支持 HTTP/2，从客户端的 ALPN 列表中选一个自己支持的即可。
    
    并不是所有 HTTP/2 客户端都支持 ALPN，理论上建立 TLS 连接后，依然可以再通过 HTTP Upgrade 进行协议升级，只是这样会额外引入一次往返。

浏览器    服务器    协商结果
不支持 　　HTTP/2   不支持 HTTP/2    不协商，使用 HTTP/1.1
不支持 　　HTTP/2   支持 HTTP/2    不协商，使用 HTTP/1.1
支持 　　HTTP/2    不支持 HTTP/2    协商，使用 HTTP/1.1
支持 　　HTTP/2    支持 HTTP/2    协商，使用 HTTP/2





https://www.nihaoshijie.com.cn/index.php/archives/698/
https://zh.wikipedia.org/wiki/HTTP%E7%AE%A1%E7%B7%9A%E5%8C%96
https://developers.google.com/web/fundamentals/performance/http2?
https://tools.keycdn.com/http2-test
https://imququ.com/post/protocol-negotiation-in-http2.html