1、HTTP/0.9
0.9版本的HTTP协议极其简单，只有一个GET命令，并且改版协议规定只能返回HTML格式的字符串，不能返回别的格式的数据。
请求：GET /index.html
响应：<html><body>Hello HTTP/0.9</body></html>
流程：
- 客户端和服务端建立TCP连接。
- 客户端发送GET请求到服务端，请求index.html页面的数据。
- 服务端发送完响应，关闭TCP连接。
特点：简单，一个请求需要一个连接。
2、HTTP/1.0
相比0.9版本的HTTP协议，1.0版本的内容大大增加。可以发送除了文字之外的图像，视频，二进制等文件，并且新增了POST和HEAD命令，请求和响应的格式也相对复杂了一些。
请求：第一行请求命令+版本信息，后面的多行为头信息
GET / HTTP/1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5)
Accept: */*
响应：响应头信息 + 空行(\r\n) + 数据部分
HTTP/1.0 200 OK
Content-Type: text/plain
Content-Length: 2345
Expires: Thu, 05 Dec 2020 16:00:00 GMT
Last-Modified: Wed, 5 August 2020 15:55:28 GMT
Server: Apache 0.84
<html>
<body>Hello World</body>
</html>
1.0版本的HTTP协议最主要的缺点还是跟0.9版本一样，每一个TCP连接只能发送一个HTTP请求，服务器发送完响应，就关闭连接。如果后面需要请求新的数据，则需要再次建立TCP连接，但是TCP建立连接的三次握手成本比较高，并且TCP连接初始的时候发送数据的速度相对较慢，有一个慢启动和拥塞避免的阶段。极端情况，如果每次请求的数据很少，但是请求有很频繁，这样每次请求很少的数据都需要建立连接然后断开，显得很傻。
为了解决这个问题，在1.0版本使用了一个非标准的Connection头部字段。当客户端再请求头部信息里面带上Connection：keep-alive的时候，服务器在发送完响应数据之后，就不会断开TCP连接了，从而达到复用同一个TCP连接的目的。但是由于不是标准字段，不同的实现可能导致表现得不一致，因此不能从根本上解决这个问题。
3、HTTP/1.1
1.1版本相比1.0版本，最突出的变化就是引入了持久化连接的功能，不需要显示的声明Connection：keep-alive，默认每个建立的TCP连接不关闭，可以被多个请求复用。当然如果建立连接的客户端和服务端发现对方在一段时间内都没有动静，就可以选择主动的关闭连接。
这里说一下，关闭TCP连接的规范做法是由客户端在发送最后一个请求的时候带上Connection：close，明确的告诉服务器关闭连接，这样服务器在响应完这最后一个HTTP请求之后，就会主动关闭TCP连接。当前，针对同一个域名，大多数的浏览器支持同时建立6个持久化连接。
特点：
- 管道机制（pipelining）：在同一个TCP连接里面，客户端可以同时发送多个HTTP请求，但是服务器只能按照请求的顺序一个一个的响应，先到的请求先响应。（针对1.0版本，同一个TCP连接里面，只能发送一个HTTP请求，接收响应，在发送下一个HTTP请求，接收响应……）
- Content-Length字段：由于服务器可以返回多个响应，所以需要标记每一次返回的数据包是属于哪一个响应的。Content-Length：540表明本次响应的长度是540字节，后面如果还有多的数据，就是下一个响应的数据了。
- 分块传输编码（Transfer-Encoding）：只要响应带了Transfer-Encoding字段，就不能再带Content-Length字段。对于服务器来说，有的响应操作很快，但是有的响应操作耗时比较久，这时如果一直等到响应操作全部完成再一起返回响应数据的话，效率会很低。1.1版本提供了一种更好的处理办法，就是当响应产生一块数据就直接发送这些数据，不用一直等待。才用“流模式”（stream）代替“缓存模式”（buffer）。Transfer-Encoding字段表明响应将有数量未定的数据块组成。Transfer-Encoding：chunked。在每一块非空的数据块之前，有一个16进制的数值表示该数据块的长度，最后带一个长度为0的块，表示本次响应的数据块发送完毕。
另外，1.1版本还增加了PUT、DELETE、PATCH等方法，客户端还可以携带Host字段表明请求服务器的域名。
缺点：对头堵塞（Head-of-line blocking），虽然1.1版本是允许复用同一个TCP连接，并且客户端可以同时发送多个HTTP请求，但是前面也说了，服务器还是只能按照请求的顺序一个一个的处理（虽然可以分块的返回响应，但说到底还是按照请求的顺序来处里的）。一旦前面的响应处理得比较慢的时候，后面的请求哪怕能很快的处理也只能老老实实的等着前面的处理完。
针对对头堵塞的问题，可以通过减少请求数和同时多开持久化连接分开处理不同的请求来解决。
4、HTTP/2
2015年，HTTP/2发布。因为下一个版本会是HTTP/3，所以该版本没有交2.0。
针对1.1版本的一些重要改进：
- 二进制协议：1.1 版的头信息是文本，数据部分可以是文本，也可以是二进制。2版本的头信息和数据部分都是二进制，且统称为“帧”。
- 多工：同一个TCP连接里面，客户端和服务器可以同时发送多个请求和多个响应，并且不用按照顺序来。由于服务器不用按顺序来处理响应，所以避免了“对头堵塞”的问题。
- 数据流：由于2版本的数据包不是按照顺序发送的，同一个TCP连接里面相连的两个数据包可能是属于不同的响应，因此，必须要有一种方法来区分每一个数据包属于哪个响应。2版本中，每个请求或者响应的所有数据包，称为一个数据流（stream），并且每一个数据流都有一个唯一的编号ID，请求数据流的编号ID为奇数，响应数据流的编号ID为偶数。每个数据包在发送的时候带上对应数据流的编号ID，这样服务器和客户端就能分区是属于哪一个数据流。最后，客户端还能指定数据流的优先级，优先级越高，服务器会越快做出响应。
- 头部信息压缩：由于HTTP协议是无状态的，所以很多请求都存在很多重复的头部信息，这样会导致带宽浪费，也影响传输速度。2版本针对这一点做了优化，引入了头部信息压缩机制，主要是通过服务端和客户端同时维护一张头部信息表，所有的头部信息在表里面都会有对应的记录，并且会有一个索引号，这样后面只需要发送索引号即可。
- 服务器推送：2版本还允许服务器主动给客户端推送数据。举例，当客户端请求的某个网页里面包含了很多的静态资源的时候，服务器可以猜测到客户端的下一步动作，直接主动给客户端推送这些静态资源数据，而不用等客户端请求时在响应，可以提高客户端页面的加载速度。
711
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
