HTTP2.0, HTTP1.1, HTTP1.0的特点，HTTPS vs. HTTP

HTTP2.0 相比于 HTTP1.X 大幅度的提升了web性能。
在与HTTP/1.1完全语义兼容的基础上，进一步减少了网络延迟。
示范例子：https://http2.akamai.com/demo

多路复用(Multiplexing)
多路复用允许同时通过单一的HTTP/2连接发起多重的请求-响应消息。
而HTTP/1.1协议中浏览器客户端在同一时间，针对同一域名下的请求有一定数量限制。超过限制数目的请求会被阻塞。下图为不同浏览器对该限制的数目, 数据取自Roundup on Parallel Connections。

这是一些站点会有多个静态资源CDN域名的原因之一，例如Twitter，http://twimg.com/
目的是变相解决浏览器针对同一域名的请求限制阻塞问题。
而HTTP/2的多路复用(Multiplexing)则允许同时通过单一的HTTP/2连接发起多重的请求-响应消息。

基于上图，HTTP/2可以很容易的去实现多流并行而不用依赖建立多个TCP连接，HTTP/2把HTTP协议通信的基本单位缩小为一个一个的帧，这些帧对应着逻辑流中的消息，并行地在同一个TCP连接上双向交换消息。

二进制分帧
在不改动HTTP/1.x的语义、方法、状态码、URI以及首部字段…的情况下，HTTP/2是如何做到突破HTTP1.1的性能限制，改进传输性能，实现低延迟和高吞吐量的？
关键之一就是在应用层(HTTP/2)和传输层(TCP or UDP)之间增加一个二进制分帧层。

HTTP2.0_divide_frame

在二进制分帧层中，HTTP/2会将所有传输的信息分割为更小的消息和帧(frame), 并对它们采用二进制格式的编码，其中HTTP1.x的首部信息会被封装到HEADER frame，而相应的Request Body则封装到DATA frame里面。
HTTP/2通信都在一个连接上完成，这个连接可以承载任意数量的双向数据流。

在过去，HTTP性能优化的关键并不在高带宽，而是低延迟。TCP连接会随着时间进行自我调谐，起初会限制连接的最大速度，如果数据成功传输，会随着时间的推移提高传输的速度。这种调谐则被称为TCP慢启动。由于这种原因，让原本就具有突发性和短时性的HTTP连接变的十分低效。

HTTP/2通过让所有数据流共用同一个连接，可以更有效地使用TCP连接，让高带宽也能真正服务于HTTP的性能提升。

总结：

扫描二维码关注公众号，回复： 3860774 查看本文章

单连接多资源的方式，减少服务端的链接压力，内存占用更少，连接吞吐量更大
由于TCP连接的减少而使网络拥塞状况得以改善，同时慢启动时间的减少，使拥塞和丢包恢复速度更快

首部压缩(Header Compression)
HTTP/1.1不支持HTTP首部压缩，为此SPDY和HTTP/2.0应运而生，SPDY使用的是通用的DEFLATE算法，而HTTP/2则使用了专门为首部压缩而设计的HPACK算法。

服务端推送(Server Push)
服务端推送是一种在客户端请求之前发生数据的机制。在HTTP/2中，服务器可以对客户端的一个请求发生多个响应。Server Push让HTTP1.x时代使用内嵌资源的优化手段变得没有意义；如果一个请求是由你的主页发起的，服务端很可能会响应主页内容、logo以及样式表。相当于在一个HTML文档内集合了所有资源。更值得一提的是，服务端推送还有一个很大的优势：可以缓存！也让在遵循同源的情况下，不同页面之间可以共享缓存资源成为可能。

HTTP/2 缓存策略 + Cache Digests
关于 Server Push ，一个常见的问题是：

「如果客户端早已在缓存中有了一份 copy 怎么办？」

因为 Push 本身具有投机性，所以肯定会出现推送过去的东西浏览器不需要的情况。
这种情况下，HTTP/2 允许客户端通过 RESET_STREAM 主动取消 Push ，然而这样的话，原本可以用于更好方向的 Push 就白白的浪费掉数据往返的价值。
对此，一个推荐的解决方案是，客户端使用一个简洁的 Cache Digest 来告诉服务器，哪些东西已经在缓存，因此服务器也就会知道哪些是客户端所需要的。
因为 Cache Digest 使用的是 Golumb Compressed Sets，浏览器客户端可以通过一个连接发送少于 1K 字节的 Packets 给服务端，通知哪些是已经在缓存中存在的。

此处知乎博主推荐了PPT:HTTP/2 for Front-End Developers
TA真的太棒了！很专业，很敬业，很乐于分享！
文末第一个链接中最高赞答案中列了十来条参考文献。一个问题果然需要阅读很多专业文献，深入研究才有话语权啊。再次点赞。

另一个回答总结：

作者：腾讯云技术社区
链接：https://www.zhihu.com/question/34074946/answer/157909115
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

一、多路复用的单一长连接

1.单一长连接
在HTTP/2中，客户端向某个域名的服务器请求页面的过程中，只会创建一条TCP连接，即使这页面可能包含上百个资源。单一的连接应该是HTTP2的主要优势，单一的连接能减少TCP握手带来的时延。HTTP2中用一条单一的长连接，避免了创建多个TCP连接带来的网络开销，提高了吞吐量。

2.多路复用
HTTP2虽然只有一条TCP连接，但是在逻辑上分成了很多stream。
HTTP2把要传输的信息分割成一个个二进制帧，首部信息会被封装到HEADER Frame，相应的request body就放到DATA Frame,一个帧你可以看成路上的一辆车,只要给这些车编号，让1号车都走1号门出，2号车都走2号门出，就把不同的http请求或者响应区分开来了。但是，这里要求同一个请求或者响应的帧必须是有有序的，要保证FIFO的，但是不同的请求或者响应帧可以互相穿插。这就是HTTP2的多路复用，是不是充分利用了网络带宽，是不是提高了并发度？

二、头部压缩和二进制格式

http1.x一直都是plain text,对此我只能想到一个优点，便于阅读和debug。但是，现在很多都走https，SSL也把plain text变成了二进制，那这个优点也没了。
于是HTTP2搞了个HPACK压缩来压缩头部，减少报文大小(调试这样的协议将需要curl这样的工具，要进一步地分析网络数据流需要类似Wireshark的http2解析器)。

三、服务端推动Sever Push
这个功能通常被称作“缓存推送”。主要的思想是：当一个客户端请求资源X，而服务器知道它很可能也需要资源Z的情况下，服务器可以在客户端发送请求前，主动将资源Z推送给客户端。
这个功能帮助客户端将Z放进缓存以备将来之需。

如何理解 TCP/IP, SPDY, WebSocket 三者之间的关系？

SPDY

SPDY的主要目的是减少50%以上的页面加载时间，但是不增加部署的复杂性，不影响客户端和服务端的Web应用，只需要浏览器和Web服务器支持SPDY. 主要有以下几点:

多路复用，一个TCP连接上同时跑多个HTTP请求，请求可设定优先级
去除不需要的HTTP头，压缩HTTP头，以减少需要的网络带宽
使用了SSL作为传输协议提供数据安全
对传输的数据使用gzip进行压缩
提供服务方发起通信，并向客户端推送数据的机制

实质上，SPDY就是在不影响HTTP语义的情况下，替换HTTP底层传输的协议来加快页面加载时间。SPDY的解决办法就是设计一个会话层协议–帧协议，解决多路复用，优先级等问题，然后在其上实现了HTTP语义。

WebSocket

WebSocket则提供使用一个TCP连接进行双向通讯的机制，包括网络协议和API, 以取代网页和服务器采用HTTP轮询进行双向通讯的机制。
本质上来说，WebSocket是不限于HTTP协议的，但由于现存大量的HTTP基础设施、代理、过滤、身份认证等等，WebSocket借用HTTP和HTTPS的端口。
由于使用HTTP端口，因此TCP连接建立后的握手消息是基于HTTP的，由服务器判断这是一个HTTP协议，还是WebSocket协议。WebSocket连接除了建立和关闭时的握手，数据传输和HTTP没任何关系了。
WebSocket也有自己的一套帧协议。

SPDY和WebSocket的关系

补充关系，SPDY侧重给Web页面的加载提速，而WebSocket更强调为Web应用提供一种双向的通讯机制以及API
竞争关系，解决的问题有交集，比如在服务器推送上二者都提供了方案
承载关系，WebSocket的连接建立在SPDY的流之上，将WebSocket的帧映射到SPDY的帧上
融合关系，如微软在HTTP Speed + Mobility中

一道面试经典题：

「在浏览器中输入一个网址后，发生了什么？」

当你在浏览器中输入一个网址，浏览器的处理过程如下：

第一步浏览器查找该域名的 IP 地址

第二步浏览器根据解析得到的IP地址向 web 服务器发送一个 HTTP 请求

第三步服务器收到请求并进行处理

第四步服务器返回一个响应

第五步浏览器对该响应进行解码，渲染显示。

第六步页面显示完成后，浏览器发送异步请求。

浏览器接收域名
发送域名给DNS
DNS返回域名所对应的IP地址
浏览器向因特网中发出请求
路由器依据IP地址，把包裹送达IP所对应的服务器

附一个详解链接:http://www.cnblogs.com/SarahLiu/p/5954832.html

HTTPS vs. HTTP

HTTP 和 HTTPS 的不同之处

HTTP 的 URL 以 http:// 开头，而 HTTPS 的 URL 以 https:// 开头
HTTP 标准端口是 80 ，而 HTTPS 的标准端口是 443
在 OSI 网络模型中，HTTP 工作于应用层，而 HTTPS 工作在传输层( 这么说不对！) HTTP工作在应用层（OSI模型的最高层），SSL协议工作在一个较低的子层，位于TCP/IP协议和HTTP协议之间。在HTTP报文传输前对其加密，并在到达时对其解密。严格地讲，HTTPS并不是一个单独的协议，而是工作在SSL协议上的HTTP协议。
HTTP的信息是明文传输，而HTTPS的信息是加密传输(或者说 HTTP 无需加密，而 HTTPS 对传输的数据进行加密)
采用HTTPS的Web Server需要到CA申请证书（HTTP 无需证书，而 HTTPS 需要认证证书）
HTTPS由HTTP+SSL来实现，可进行加密传输、身份认证等，要比HTTP安全（HTTP 是不安全的，而 HTTPS 是安全的）

使用 HTTPS 连接时，服务器要求有公钥和签名的证书。

当使用 https 连接，服务器响应初始连接，并提供它所支持的加密方法。
作为回应，客户端选择一个连接方法，并且客户端和服务器端交换证书验证彼此身份。
完成之后，在确保使用相同密钥的情况下传输加密信息，然后关闭连接。
为了提供 https 连接支持，服务器必须有一个公钥证书，该证书包含经过证书机构认证的密钥信息，大部分证书都是通过第三方机构授权的，以保证证书是安全的。

SSL中结合使用了对称加密和非对称加密。

换句话说，HTTPS 跟 HTTP 一样，只不过增加了 SSL。

HTTP 包含如下动作：