http1 & http2 发展与特性

Http

http协议已经被广泛应用在web应用中，常用于一下几种场景：

• 聊天 （全双工，客户端和服务器实时通信）
• 推送 （服务器主动向客户端通信）
• 应答 （传统模式，客户端发起请求，服务器响应）

长连接（TCP）

Http协议本身就是基于请求/应答模式的，只要服务器响应，本次http连接就结束了，但这不意味着TCP通道关闭。

所谓的长连接通常是指 TCP连接 ，TCP通道连接客户端和服务器端，可以保持一段时间不关闭。

http1.1引入了长连接，使用

Connection:keep-alive

首部字段来保证tcp通道长时间存在（需要服务端和客户端同时设置）。

长连接的TCP通道客户端一般不会主动关闭，服务端会自动关闭在一段时间内（可设置）未进行使用的tcp通道连接（超时处理）。

Http1.0

http1.0有两个很大的缺点：

• 连接无法复用 （TCP通道立即关闭）
• 队首请求阻塞 （http、tcp）

在TCP通道上，Http1.0不支持长连接，每次的请求/响应结束后，TCP通道立即关闭。

因此，一般PC端会向一个域名同时建立6~8个连接,手机端则是4~6个,会导致延迟和开销增大。

此外，队首阻塞有两个层面。

1. http应用层队首阻塞：http1协议规定严格按照优先级进行请求发送，意味着低优先级请求的发送必须等待高优先级响应后进行。
2. tcp传输层队首阻塞：tcp要求分组严格按照顺序交付，一个分组未收到，就会阻塞后续的所有高序号分组。直到重传那个丢失的分组。

队首阻塞的情况常常会遇到，比如当某一个请求未抵达服务器，或响应因网络阻塞未返回时影响后面的请求发送，并且在js，css等外部文件下载方面造成很大的延时（同步下载）。

http1.1

http1.1已经被广泛使用。在http1.0的基础上，新增了以下功能：

• TCP通道长连接（持久连接），在响应后不关闭TCP通道
• 新增了首部字段

  Host

  ，客户端指明访问的主机（域名 || [ip + 端口号]），使得服务端可以在同一域名下的不同主机之间实现多个虚拟Web站点。

• Connection

  ，实现持久连接，默认开启

  Keep-Alive

  ，关闭连接复用需要显示的设置成

  Close

• 新增了http流水线机制（http pipelining），允许幂等的请求（GET，HEAD）同时发送，在响应方面仍然是以同步方式的顺序返回
• ....

http1.1的新增特性解决了http1.0的两个大难题，实现了TCP通道连接复用，并支持多个请求同时发送，互不影响。

持久的TCP通道并不能解决所有问题，同一时间一条TCP通道只能有一个请求/应答。

客户端无法再通过TCP通道是否关闭来判断响应发送完成，因此响应中必须包含

Content-Length

首部来辅助浏览器判断一次响应的结束。

浏览器会根据

Content-Length

的值来判断响应是否发送完成，若该首部属性的值过大，则会一直处于pending状态，过小则会对响应体进行截取。

http层伪长连接

虽然http1.1实现了TCP通道在 一段时间内 的复用，这对于pc端很适用，但对于移动端则不然。

移动端的请求比较分散，时间跨度大，因此移动端往往在 应用层 做处理,常常使用一下几种方式：

• http long-polling （长轮询）
• http stream （http流）
• web socket （H5）

长轮询

长轮询是实现http层面（应用）的 伪长连接 ,并没有在模式上进行改变，仍然是请求/应答模式，能够在很大的时间跨度上保持 长连接。

1. 客户端向服务器发送一个请求
2. 服务器端不是立刻响应处理，而是保持Http会话
3. 服务器端需要推送消息时进行响应
4. 客户端接受响应并再次发送一个请求

缺点：

• 长连接的做法会导致服务端一直阻塞请求，造成内存上的闲置，在网站流量大，多并发的情况下会使用大量内存，浪费连接。
• 在断网等极端情况下失去连接，需要重新发送请求，处理复杂
• 后端服务器的响应可能被代理服务器缓存

短轮询

短轮询与长轮询不同处在于，客户端向服务器发送请求后，服务器会立刻返回响应，

http流

http流这种处理方式与长轮询类似，不同之处在于服务器推送响应后，不会停止这次http会话，而是继续保持阻塞状态，等待下一次推送或超时（超时后通知客户端重新发送请求）。

http流的方式处理时，利用ajax的

readystate == 3

来判断服务器是否有推送数据，进行读取，但在IE中，

readystate ==3

时不能够读取数据，因此IE不支持http流的方式。

http流的实现方式很简单，是通过在响应头添加首部

Transfer-Encoding: chunked

，该首部的值

chunked

会使报文采用分块传输。

报文的分块传输不需要关闭tcp通道，也不用

Content-Length

首部来辅助浏览器判断响应的结果。

分块传输是针对响应体，服务端可以间断的发送响应体，每次响应都会包含具体字节长度。

这里

有篇文章

专门介绍了

chunked

分段传输。

web socket

web socket 是H5推出的新技术，基于TCP协议。

web socket通信只使用了一次http请求，创建TCP通道，利用HTTP响应的

101

状态码来触发协议切换，升级到web socket自身协议，后续的请求和响应都是遵循web socket协议。

Http Request

GET / HTTP/1.1
Upgrade: websocket
Connection: Upgrade
Host: example.com
Origin: null
Sec-WebSocket-Key: sN9cRrP/n9NdMgdcy2VJFQ==
Sec-WebSocket-Version: 13           

Http Response

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: fFBooB7FAkLlXgRSz0BT3v4hq5s=
Sec-WebSocket-Origin: null
Sec-WebSocket-Location: ws://example.com/           

http2.0

http1.0和http1.1仍然有很多的问题，http2.0目标便是解决http1.1版本中的两个问题：

• 延迟性 （改动http应用层，而TCP传输层已经被广泛应用，改动代价太大）
• 安全性

为了实现低延迟和高吞吐量，http2增加了了二进制分帧层和首部压缩技术。

二进制分帧

在http应用层，加入了一层二进制分帧层，在http层使用二进制对http请求进行编码。

传输层从应用层获取到的将是纯二进制，原先http1的一个请求文本会被分割成多个二进制帧传递给传输层。

二进制分帧层将一个请求切成碎片（帧，http2.0网络传输的最小单位）打乱发送，解决了队首阻塞的问题。

二进制分帧使用二进制格式来替换原有的文本格式，在解析和差错检测上更加的精准方便（不用考虑换行、空格等）。

首部压缩

由于http是无状态的，因此每次请求/响应都有首部来对所传输的资源进行描述。

在http1中，http层是以文本进行传输的，首部加上cookie可以达到上千字节。

http2采用了首部压缩，目的是减少每次请求的请求头大小，提升了性能，节约开销。

浏览器和服务器同时维护一张首部表，里面会记录一些常用键值对（用户代理、可接受的媒体类型等），拥有唯一序号来与之对应。

每次发送请求时，会从首部表中比较常用键值对，以唯一序号来代替，同时会将该请求首部（首部表以外的属性）与上一次的请求进行比较，只发送有差异性的首部属性。

最终确定出来需要发送的首部,会以哈夫曼编码进行再次压缩。

传输方式

二进制分帧层将请求和响应分为了一个又一个的帧，这些帧在一个tcp通道中是被打乱传输的。

为了能够完整准确的在客户端和服务端将其重新拼接，http2.0引入了流（Stream）的概念，变相的实现了多路复用。

将一个tcp通道在逻辑上切割成了多个并行存在的流，一个流只服务于一个请求/应答，而在实际tcp传输中，其仍然是打乱发送的。

参考博文

• 谈谈HTTP协议中的短轮询、长轮询、长连接和短连接
• HTTP长连接和短连接 - WhyWin - 博客园
• HTTP1.1和HTTP1.0的区别 - 牛小浩 - 博客园
• HTTP 2.0的那些事 | MrPeak技术分享
• 浅析Comet技术在Java Web实时系统开发中的应用
• HTTP 2.0 协议详解 - zqjflash的专栏 - 博客频道 - CSDN.NET
• HTTP 协议中的 Transfer-Encoding | JerryQu 的小站
• HTTP2学习(四)—HTTP2的新特性 · 小路口
• HTTP2.0的总结 - 不忘初心，上下求索。
• zqjflash/http2-protocol: http2协议讲解