http协议各个版本之解说

最近工作清闲，静下心来觉得要充充电，充什么电好呢，就从一直想弄清http的历史渊源来说吧，毕竟对于http协议各个版本差异我只略知一二。

何谓http?

超文本传输协议

HTTP/0.9

HTTP协议的最初版本，功能简陋，仅支持请求方式GET，并且仅能请求访问HTML格式的资源。

HTTP/1.0

请求行必须在尾部添加协议版本字段（http/1.0）

必须包含头消息

增加了请求方式POST和HEAD

不再局限于0.9版本的HTML格式，根据Content-Type可以支持多种数据格式，即MIME多用途互联网邮件扩展，例如text/html、image/jpeg等

开始支持cache，就是当客户端在规定时间内访问统一网站，直接访问cache即可。

HTTP请求和回应的格式也变了。除了数据部分，每次通信都必须包括头信息（HTTP header），用来描述一些元数据。

新增功能还包括状态码（status code）、多字符集支持、多部分发送（multi-part type）、权限（authorization）、缓存（cache）、内容编码（content encoding）等。

但是1.0版本的工作方式是每次TCP连接只能发送一个请求，当服务器响应后就会关闭这次连接，下一个请求需要再次建立TCP连接，就是不支持keepalive。

TCP连接的新建成本很高，因为需要客户端和服务器三次握手，并且开始时发送速率较慢（slow start）。所以，HTTP 1.0版本的性能比较差。随着网页加载的外部资源越来越多，这个问题就愈发突出了。

为了解决这个问题，有些浏览器在请求时，用了一个非标准的Connection字段。这个字段要求服务器不要关闭TCP连接，以便其他请求复用。服务器同样回应这个字段。


Connection: keep-alive

一个可以复用的TCP连接就建立了，直到客户端或服务器主动关闭连接。但是，这不是标准字段，不同实现的行为可能不一致，因此不是根本的解决办法。

Content-Type 字段

关于字符的编码，1.0版规定，头信息必须是 ASCII 码，后面的数据可以是任何格式。因此，服务器回应的时候，必须告诉客户端，数据是什么格式，这就是Content-Type字段的作用。

常用的content-type值

text/plain

text/html

text/css

image/jpeg

image/png

image/svg+xml

audio/mp4

video/mp4

application/javascript

application/pdf

application/zip

application/atom+xml

这些数据类型总称为MIME type，每个值包括一级类型和二级类型，之间用斜杠分隔。

除了预定义的类型，厂商也可以自定义类型。


application/vnd.debian.binary-package //此类型表明，发送的是Debian系统的二进制数据包。

MIME type还可以在尾部使用分号，添加参数。


Content-Type: text/html; charset=utf-8 //此类型表明，发送的是网页，而且编码是UTF-8。

客户端请求的时候，可以使用Accept字段声明自己可以接受哪些数据格式。


Accept: */* //客户端声明自己可以接受任何格式的数据。

MIME type不仅用在HTTP协议，还可以用在其他地方，比如HTML网页。


<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<!-- 等同于 -->
<meta charset="utf-8" />

Content-Encoding 字段

由于发送的数据可以是任何格式，因此可以把数据压缩后再发送。Content-Encoding字段说明数据的压缩方法。

Content-Encoding: gzip
Content-Encoding: compress
Content-Encoding: deflate

客户端在请求时，用Accept-Encoding字段说明自己可以接受哪些压缩方法。

Accept-Encoding: gzip, deflate

HTTP/1.1

引入了持久连接（persistent connection），即TCP连接默认不关闭，可以被多个请求复用，不用声明Connection: keep-alive。解决了1.0版本的keepalive问题，一个TCP连接可以允许多个HTTP请求；

客户端和服务器发现对方一段时间没有活动，就可以主动关闭连接。不过，规范的做法是，客户端在最后一个请求时，发送Connection: close，明确要求服务器关闭TCP连接。


Connection: close

目前，对于同一个域名，大多数浏览器允许同时建立6个持久连接。降低了延迟同时提高了带宽的利用率。

加入了管道机制，在同一个TCP连接里，允许多个请求同时发送，增加了并发性，进一步改善了HTTP协议的效率；举例来说，客户端需要请求两个资源。以前的做法是，在同一个TCP连接里面，先发送A请求，然后等待服务器做出回应，收到后再发出B请求。管道机制则是允许浏览器同时发出A请求和B请求，但是服务器还是按照顺序，先回应A请求，完成后再回应B请求。

Content-Length 字段

一个TCP连接现在可以传送多个回应，势必就要有一种机制，区分数据包是属于哪一个回应的。这就是Content-length字段的作用，声明本次回应的数据长度。


Content-Length: 3495

上面代码告诉浏览器，本次回应的长度是3495个字节，后面的字节就属于下一个回应了。

在1.0版中，Content-Length字段不是必需的，因为浏览器发现服务器关闭了TCP连接，就表明收到的数据包已经全了。

分块传输编码

使用Content-Length字段的前提条件是，服务器发送回应之前，必须知道回应的数据长度。

对于一些很耗时的动态操作来说，这意味着，服务器要等到所有操作完成，才能发送数据，显然这样的效率不高。更好的处理方法是，产生一块数据，就发送一块，采用"流模式"（stream）取代"缓存模式"（buffer）。

因此，1.1版规定可以不使用Content-Length字段，而使用"分块传输编码"（chunked transfer encoding）。只要请求或回应的头信息有Transfer-Encoding字段，就表明回应将由数量未定的数据块组成。

Transfer-Encoding: chunked

每个非空的数据块之前，会有一个16进制的数值，表示这个块的长度。最后是一个大小为0的块，就表示本次回应的数据发送完了。下面是一个例子。

HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked25
This is the data in the first chunk1C
and this is the second one3
con8
sequence

为了避免这个问题，只有两种方法：一是减少请求数，二是同时多开持久连接。这导致了很多的网页优化技巧，比如合并脚本和样式表、将图片嵌入CSS代码、域名分片（domain sharding）等等。如果HTTP协议设计得更好一些，这些额外的工作是可以避免的。

多路复用带来一个新的问题是，在连接共享的基础之上有可能会导致关键请求被阻塞。SPDY允许给每个request设置优先级，这样重要的请求就会优先得到响应。比如浏览器加载首页，首页的html内容应该优先展示，之后才是各种静态资源文件，脚本文件等加载，这样可以保证用户能第一时间看到网页内容。

允许复用TCP连接，但是同一个TCP连接里面，所有的数据通信是按次序进行的。服务端是按队列顺序处理请求的，服务器只有处理完一个回应，才会进行下一个回应。假如前面的请求处理时间很长，后面就会有许多请求排队等着，这样就造成了“队头阻塞”的问题；同时HTTP是无状态的连接，因此每次请求都需要添加重复的字段，降低了带宽的利用率。

加入了一个新的状态码100（Continue）。客户端事先发送一个只带头域的请求，如果服务器因为权限拒绝了请求，就回送响应码401（Unauthorized）；如果服务器接收此请求就回送响应码100，客户端就可以继续发送带实体的完整请求了。100 (Continue) 状态代码的使用，允许客户端在发request消息body之前先用request header试探一下server，看server要不要接收request body，再决定要不要发request body。

加入了一些cache的新特性，当缓存对象的Age超过Expire时变为stale对象，cache不需要直接抛弃stale对象，而是与源服务器进行重新激活（revalidation）。

支持只发送header信息(不带任何body信息)，如果服务器认为客户端有权限请求服务器，则返回100，否则返回401。客户端如果接受到100，才开始把请求body发送到服务器。这样当服务器返回401的时候，客户端就可以不用发送请求body了，节约了带宽。

有身份认证机制，许多web站点要求用户提供一个用户名—口令对才能访问存放在其服务器中的文档，这种要求称为身份认证(authentication)。HTTP提供特殊的状态码和头部来帮助Web站点执行身份认证。

支持文件断点续传，RANGE:bytes，HTTP/1.0每次传送文件都是从文件头开始，即0字节处开始。RANGE:bytes=XXXX表示要求服务器从文件XXXX字节处开始传送，断点续传。即返回码是206（Partial Content）

新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。

HTTP/2.0

h2已出世多年了，我却未在项目中去使用它的优点。是时候看看了。

HTTP2 相比 HTTP1.1 有如下几个优点：

解析速度快

多路复用

首部压缩

优先级

流量控制

服务器推送

以上的项我是在消化知识后总结出来的，不明白的传送门。

前端性能优化 24 条建议（2020） - SegmentFault 思否

============================额外知识====================================

我们的http具体使用哪种协议，是由服务器nginx来配置的。其中http2还必须在https的基础上去设置，然后高版本协议是向低版本协议兼容的。

http协议各个版本之解说相关推荐

Gnosis发起提案就是否推出Gnosis协议v2版本展开讨论
1月8日,预测市场协议Gnosis官方宣布,社区已发起提议,激励社区成员讨论Gnosis是否应该推出Gnosis协议v2版本.根据提议,截至2021年1月5日,当前Gnosis协议状态为"第 ...
【计算机网络】HTTP协议历史版本
综述 HTTP协议有几个重要的版本,故HTTP应用程序要尽量强健地处理各种不同的 HTTP协议变体. 主要的HTTP版本如下: HTTP/0.9 HTTP的1991原型版本称为HTTP/0.9.这个协 ...
OGC PUCK协议标准版本v1.4 翻译
OGC PUCK协议用于支持IOT中设备的即插即用,其定义了自动获取设备元数据的相关方法,懂的自然懂,多说无益. 最近我在实现IP PUCK.顺带将这个协议的文档整个翻译了一遍.PUCK的部分已经实现 ...
01、ZigBee协议各版本比较Z-Stack各版本比较
文章目录 0.前言 1.ZigBee 各版本规范比较 2.Z-Stack 协议栈各版本比较 0.前言在开始讲ZigBee协议栈之前,作为开发者,首先应该明白什么是 ZigBee 协议,以及什么是 ...
IGMP协议 v1-v3版本简介
本文章主要介绍了IGMP协议的实现过程以及从v1版本到v3版本的演进,阅读本文,您需要具有IGMP协议.组播的一些基础知识. IGMP(Internet Group Management Protoc ...
javax.servlet.GenericServlet类（协议无关版本）
< DOCTYPE html PUBLIC -WCDTD XHTML StrictEN httpwwwworgTRxhtmlDTDxhtml-strictdtd> GenericServl ...
ipad协议最新版本
微信ipad协议又称iPad协议致力于微信辅助系统开发,通过app逆向原理开发的一款微信协议接口.致力于微信更高效的工作与运作.像现在比较常用的系统和功能.提取62数据,即时发圈,查找附近人,清理僵尸 ...
DHT协议(官方版本)
译者前序 DHT协议早在2005年就已经成为了官方BitTorrent协议的一部份,但是我竟然一直没有找到国内的官方翻译稿,所以将其进行翻译,若文中错误,欢迎各位指正.其次,若想彻底理解DHT协议的原 ...
Web版微信协议分析—版本2
微信web协议分析(微信网页版 wx2.qq.com) 1.打开首页,分配一个随机uuid, 2.根据该uuid获取二维码图片. 3.微信客户端扫描该图片,在客户端确认登录. 4.浏览器不停的调用一个 ...

http协议各个版本之解说

http协议各个版本之解说相关推荐

最新文章

热门文章