http，https，websocket

[wengjq]

https://segmentfault.com/a/1190000011450538

HTTP/2

HTTP/2 是HTTP协议自 1999 年 HTTP 1.1 发布后的首个更新，主要基于 SPDY 协议。于 2014 年 12 月将HTTP/2 标准提议递交至 IESG 进行讨论,最后在 2015 年 5 月以 RFC 7540 正式发表。它底层以二进制传输(而不是以前\r\n分隔的明文)，HTTP数据帧(Frame)为最小的传递数据单位。帧的报头字段定义着类型及其它属性。HTTP/2协议翻译

多路复用

所谓多路复用，先要讲一下 HTTP1 的连接方式。在七层协议中，HTTP 属于应用层协议，它的数据传输层还是 TCP/IP。在 HTTP1 时，浏览器展示页面时，是为每一个文件( js ，图片...)都单独建立一个 Socket 短连接来传输数据。即一个页面可能有多条 Socket 连接,然后传输完马上断开。这看上去没什么问题，但其实HTTP的性能瓶颈就在这。

在使用 HTTP1 协义时，人们采取了很多优化的手段.。比如，把多张小图片合在一张大图片上。前端用 CSS 来切片，以便减少连接数。在 WebApp 上，为了解决上述方法造成的流量浪费，采用将小图片用Base64 方式。直接放在页面中，再通过 Js 方式还原展示。jQuery 的移动版和 WeUI 中都有采用这些方式。比如有时网页文件实在太多，而连接数其实是有限制的，以致需开多个机器来分散等等。

以上种种问题，就是 HTTP/2 的多路复用要解决的。多个HTTP请求可以放在同一个连接中进行。且自有数据流能并行传输。至于怎么区分得开，就要归功于帧的设计(有个 StreamID )了.所以以后不需要那么折腾了。特别是小图合成大图的方式，在 HTTP/2 下是完全没必要的了。

HEAD 压缩

HTTP1 中每次 HTTP 请求，都是必须要带上 HTTP 头的。而 HTTP/2 则在建立连接后，把头字段作为键值对，在两边维护一份字典，相同的就不用再传了，如有新增或变更，则再在传输时带上。减少HTTP头的传输，交互密集时，其实能省不少流量。

服务器推送

就是服务端能主动推东西过去，以前只能是被动的。即当客户端发一个请求过来时，服务端能依据这个请求，推断出你后续还要什么，主动给推过去。大大减少了请求数，加快了反应时间。嗯，现在HTTP/2已经原生支持了。

优先级请求

不过从 HTTP/2 协议上看，有个问题是它维持的这个 TCP 连接，虽然效率和玩法多了，但对 Web 服务端而言，单个连接 内存占用之类要比以前要多了，要注意资源耗尽问题。不过相对它的好处。这到无所谓了。另外以前就有个 Keep-Alive ，是 HTTP1 的持久连接方案。 HTTP/2 兼容 HTTP1，它通过 HTTP/1.1 Upgrade header 字段来询问服务端是否支持 HTTP/2 ，并且通过 h2/h2c 来标明自己是 tls 的 HTTP/2 还是明文的 HTTP/2 。在 HTTP/2 的协议规范中有一个详细的说明。

HTTP

https://hit-alibaba.github.io/interview/basic/network/HTTP.html