关于 HTTP2.0

[mokevip]

HTTP2.0 出来已经有一段时间了，可能是因为前端的原因对这些协议没有太大的关注。

今天突然意识到随着 2.0 的广泛使用，自己以前的一些观念被打破了。

因为入行以来一直被教育，要减少请求减少请求，减少请求次数，减少文件数量。为此 webpack 打包把所有的 js 压缩为几个文件，图片引入也要使用 CSS 图片精灵。

但是 HTTP2.0 的多路复用，允许在一次连接中多次请求，意味着以前的很多请求头传输损耗和三次握手的性能消耗都无限变小？

这是否意味着，在纯 HTTP2.0 的场景下，比如小程序开发中（纯 https ），节约请求数量不再必要？

[KuroNekoFan]

是的，现在还这么做可以说是路径依赖了

[seakingii]

还是有必要的.减少请求数据好处多多.

[mokevip]

@KuroNekoFan 好吧，看来观念要更新了(捂脸)

[mokevip]

@seakingii 还有哪些好处呢，目前明显感觉到的可能就是前端写起来比较省事哈哈

[markgor]

@mokevip img 的同时加载才是主要的，另外浏览器依然对加载有并发数量限制。最后小程序只能 https ，并且小程序的前端代码是托管在小程序所在平台的

[0o0O0o0O0o]

http2 可以说已经普及了，现在应该关注 http3 了😂
https://w3techs.com/technologies/details/ce-http3

[SorcererXW]

网页似乎并不能保证浏览器当前建立的连接就是 http2 ，所以兼容 http1/x 的工作还是不能少吧

[Showfom]

HTTP/2 都已经出来那么多年了，现在都等着各种 Web 软件开启 HTTP/3 嘿嘿

[ampedee]

你这问题问的有点晚了，现在用的 HTTP1.1 十几年前就已经实现了多路复用……

[jinliming2]

@markgor 并发数限制在 HTTP/2 下不一样了。
HTTP/1 下限制连接数是因为 HTTP/1 的特性，单个连接上只能串行传输，要并行传输就得要建立多个 HTTP/TCP 连接，而这个连接是有开销的，并且操作系统对这个也有上限，所以浏览器实现的时候就需要限制连接数。
但 HTTP/2 不一样了，浏览器针对一个主机始终只建立一个 TCP 连接，在这一个连接上进行多路复用并行传输 HTTP ，所以并发数理论上是无限的了。实际上浏览器端和服务端可以通过 HTTP/2 的 SETTINGS_MAX_CONCURRENT_STREAMS 配置来协商并发数限制。

[KiseXu]

CDN 还按照次数计费呢

[seakingii]

@mokevip

1 按次数收费的 API 接口
2 多一次请求就多一次鉴权
3 N 次请求不如一次请求来的稳定,比如在不稳定的移动网络下..
4 万一碰到 H2 用不了,要降级到 H1 的时候,滥用 H2,太多请求就麻烦了
5 楼下的补充


个人倾向于每个请求返回合适的数据,不要太多也不要太少.不能因为 H2 功能增强了就滥开连接.

[LeeReamond]

@seakingii 问下老哥后端怎么对 h2 进行适配？比如我写一个传统后端，访问路由 /api/a 要进行鉴权，然后业务逻辑，/api/b 也要鉴权再跑业务逻辑，难道用户用 http2 先后请求两个路由可以只进行一次鉴权？那岂不是后端逻辑不按开发者规定工作了

[mokevip]

@seakingii 好的

[SmiteChow]

是的，现在已经不推荐打包了，浏览器的包管理（ js/css ）已经能用了.

[seakingii]

@LeeReamond 后端并不关心是 H2 还是 H1

就算是 H2 请求两次路由,也要鉴权两次.所以并不是可以随意将原来一个请求拆分成 N 个子路由

H2 只是提高 了客户端的连接性能.
比方说,原来客户端浏览器限制了一个域名只能同时并发 8 个,那么同时只能做 8 件事情.现在上了 H2,可能同样一个浏览器,现在可以同时做 16 或者或者 32 件事情(比如同时下载 18 个 CSS,图像等等)

[LeeReamond]

@seakingii 那么是否意味着后端无感知，我只需要 nginx 配置兼容 h2 ，自然就能提高网站的使用体验？不过我看 h2 有一些特殊 headers ，比如冒号开头的 header ，后端我又没写相关逻辑，他怎么处理的。

我是常年 http1.1 和 1.2 开发的，没在意这些，昨天看到这个帖子后查了查 h2 感觉用户体验提升很大啊

[seakingii]

@LeeReamond

后端完全不用在意是 H1 还是 H2,不用在意 H2 与 H1 的区别.
甚至可以:

浏览器 -> WEB 服务器(比如 NGINX) 是 H2 的,
WEB 服务 -> 后端 (通过代理) 是 H1 的

这样的架构问题也不是很大.因为一般来说,后端提供的是业务逻辑,业务逻辑一般相对并发少,但执行相对需要较少时间.这样,就算是 H1,发起 TCP 链接的成功相对后端业务的执行时间来说也没看起来那么高.而且代理服务器与后端服务一般是同一个局域网.



H2 解决的最大的问题是浏览器对并发的限制.
1 浏览器对一个域名能发起的请求是有限制的,假设 CHROME 对一个域名同一时间能发起 8 个请求,但你有一个复杂的网页,里面有 10 个 CSS,20 个 JS,100 个图像,那就有得等了,
2 加上如果 CHROME 和 WEB 服务器距离太远,网络不好的话,发起 TCP 的成本太高了.
3 每个请求都有大量的头 header

H2 的改进:
1 多路复用
2 原来的文本协议改成二进制协议
3 头部压缩
4 server push

实践中,我就是这么做的,后端独立运行,用 H1,这样不用管证书,用 NGINX 部署证书上 H2,代理对后端的请求

[LeeReamond]

@seakingii 感谢，nginx 开启 http2 是不是在协议里同时写 1.1 1.2 1.3 2.0 这就算开启了？

[seakingii]

@LeeReamond

1 首先要确定用的 nginx 有没有带 http2 模块
2 其次要有 HTTPS 用的 SSL 证书
3 最后配置里 listen 443 ssl http2;


再简单点,找个 CDN 来代理,例如 Cloudflare 之类,里面鼠标点点就开启 HTTP2 了..