http2
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