【博客356】谈谈http的那些事(三)

内容： 记录http协议

http1.0、http/1.1、http /2.0的区别：

1. http 1.0

链接无法复用：http 1.0 规定浏览器与服务器保持较短时间的链接，浏览器每次请求都和服务器
经过三次握手和慢启动（基本思想是当TCP开始传输数据或发现数据丢失并开始重发时，首先慢慢的
对网路实际容量进行试探，避免由于发送了过量的数据而导致阻塞）建立一个TCP链接，服务器完成
请求处理后立即断开TCP链接，而且不跟踪每个浏览器的历史请求。

线头阻塞（Head of Line (HOL) Blocking）：请求队列的第一个请求因为服务器正忙
（或请求格式问题等其他原因），导致后面的请求被阻塞。

2. http 1.1

支持持久链接：（在request和response中的header中的connection是close或者Keep-Alive
进行控制），一个TCP链接可以传送多个http请求和相应，减少了TCP建立链接和关闭链接的消耗。
另外http1.1允许客户端不用等待上一次请求结果返回，就可以发出下一次请求，但服务器端必须
按照接收到客户端请求的先后顺序依次回送响应结果，以保证客户端能够区分出每次请求的响应内容。

增加了请求头和响应头来扩充功能：
         a. 支持Host请求：
         b. Connection: 请求头的值为Connection时，客户端通知服务器返回本次请求结果
         后保持连接；Connection请求头的值为close时，客户端通知服务器返回本次请求结果
         后关闭连接
         c. 支持断点续传:
         d.身份认证：
         e.状态管理:
         f. 缓存处理：

3. http 2.0
支持多路复用：多路复用允许同时通过单一的HTTP2.0连接发起多重的请求-响应消息，减少了因
http链接多二引起的网络拥塞（在HTTP1.1 协议中，同一时间，浏览器会针对同一域名下的请求
有一定数量限制），解决了慢启动针对突发性和短时性的http链接低效的问题。

将通信的基本单位缩小为帧：即应用层(HTTP)和传输层(TCP or UDP)之间增加一个二进制分帧层。

首部压缩：http 2.0支持DEFLATE和HPACK 算法的压缩。

服务端推送：指客户端请求之前发送数据的机制，在 HTTP 2.0 中，服务器可以对客户端的一个
          请求发送多个响应。

http1.1的优化：

HTTP 1.0规定浏览器与服务器只保持短暂的连接，浏览器的每次请求都需要与服务器建立一个
TCP连接，服务器完成请求处理后立即断开TCP连接

当一个网页文件中包含了很多图像的地址的时候，那就需要很多次的http请求和响应，每次请求
和响应都需要一个单独的连接，每次连接只是传输一个文档和图像，上一次和下一次请求完全分离。
即使图像文件都很小，但是客户端和服务器端每次建立和关闭连接却是一个相对比较费时的过程，
并且会严重影响客户机和服务器的性能。当一个网页文件中包含JavaScript文件，CSS文件等
内容时，也会出现类似上述的情况。

* http1.1为了克服HTTP 1.0的这个缺陷，HTTP 1.1支持持久连接（HTTP/1.1的默认模式使用
带流水线的持久连接），在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接
的消耗和延迟。一个包含有许多图像的网页文件的多个请求和应答可以在一个连接中传输，但每个
单独的网页文件的请求和应答仍然需要使用各自的连接。

* HTTP 1.1还允许客户端不用等待上一次请求结果返回，就可以发出下一次请求，但服务器端必须
按照接收到客户端请求的先后顺序依次回送响应结果，以保证客户端能够区分出每次请求的响应内容，
这样也显著地减少了整个下载过程所需要的时间。

在http1.1，request和reponse头中都有可能出现一个connection的头，此header的含义是当
client和server通信时对于长链接如何进行处理。

在http1.1中，client和server都是默认对方支持长链接的， 如果client使用http1.1协议，
但又不希望使用长链接，则需要在header中指明connection的值为close；如果server方也不想
支持长链接，则在response中也需要明确说明connection的值为close。

* 不论request还是response的header中包含了值为close的connection，都表明当前正在
使用的tcp链接在当天请求处理完毕后会被断掉。以后client再进行新的请求时就必须创建新的
tcp链接了。

*HTTP 1.1在继承了HTTP 1.0优点的基础上，也克服了HTTP 1.0的性能问题。

* 同时：HTTP 1.1通过增加更多的请求头和响应头来改进和扩充HTTP 1.0的功能。
如，HTTP 1.0不支持Host请求头字段，WEB浏览器无法使用主机头名来明确表示要访问服务器
上的哪个WEB站点，这样就无法使用WEB服务器在同一个IP地址和端口号上配置多个虚拟WEB站点。
在HTTP 1.1中增加Host请求头字段后，WEB浏览器可以使用主机头名来明确表示要访问服务器上
的哪个WEB站点，这才实现了在一台WEB服务器上可以在同一个IP地址和端口号上使用不同的主机
名来创建多个虚拟WEB站点。

HTTP 1.1的持续连接，也需要增加新的请求头来帮助实现，例如，Connection请求头的值为
Keep-Alive时，客户端通知服务器返回本次请求结果后保持连接；Connection请求头的值为
close时，客户端通知服务器返回本次请求结果后关闭连接。

HTTP 1.1还提供了与身份认证、状态管理和Cache缓存等机制相关的请求头和响应头。

HTTP/1.0不支持文件断点续传，RANGE:bytes是HTTP/1.1新增内容，HTTP/1.0每次传送文件
都是从文件头开始，即0字节处开始。RANGE:bytes=XXXX表示要求服务器从文件XXXX字节处开
始传送，这就是我们平时所说的断点续传！


HTTP/1.1相较于 HTTP/1.0 协议的区别主要体现在：

1 缓存处理

2 带宽优化及网络连接的使用

3 错误通知的管理

4 消息在网络中的发送

5 互联网地址的维护

6 安全性及完整性

常用的请求方式:

GET 请求获取Request-URI所标识的资源

POST 在Request-URI所标识的资源后附加新的数据

HEAD 请求获取由Request-URI所标识的资源的响应消息报头

PUT 请求服务器存储一个资源，并用Request-URI作为其标识

DELETE 请求服务器删除Request-URI所标识的资源

TRACE 请求服务器回送收到的请求信息，主要用于测试或诊断

CONNECT 保留将来使用

OPTIONS 请求查询服务器的性能，或者查询与资源相关的选项和需求

http2的优化：

相比 HTTP/1.x，HTTP/2 在底层传输做了很大的改动和优化：

（1） HTTP/2 采用二进制格式传输数据，而非 HTTP/1.x 的文本格式。二进制格式在协议的
解析和优化扩展上带来更多的优势和可能。

（2） HTTP/2 对消息头采用 HPACK 进行压缩传输，能够节省消息头占用的网络的流量。
而 HTTP/1.x 每次请求，都会携带大量冗余头信息，浪费了很多带宽资源。头压缩能够很好的
解决该问题。

（3） 多路复用，直白的说就是所有的请求都是通过一个TCP 连接并发完成。HTTP/1.x 虽然
通过 pipeline 也能并发请求，但是多个请求之间的响应会被阻塞的，所以 pipeline 至今
也没有被普及应用，而 HTTP/2 做到了真正的并发请求。同时，流还支持优先级和流量控制。

（4） Server Push：服务端能够更快的把资源推送给客户端。例如服务端可以主动把 JS 和
 CSS 文件推送给客户端，而不需要客户端解析 HTML 再发送这些请求。当客户端需要的时候，
 它已经在客户端了。

HTTP/2 主要是 HTTP/1.x 在底层传输机制上的完全重构，HTTP/2 是基本兼容 HTTP/1.x 
的语义的(详细兼容性说明请戳这里)。Content-Type 仍然是 Content-Type，只不过它不
再是文本传输了。


与HTTP 1.1相比，主要区别包括：

1、HTTP/2采用二进制格式而非文本格式，比起像HTTP/1.x这样的文本协议，二进制协议解析起
来更高效、“线上”更紧凑，更重要的是错误更少。

2、HTTP/2是完全多路复用的，而非有序并阻塞的——只需一个连接即可实现并行。
HTTP/1.x 有个问题叫线端阻塞(head-of-line blocking), 它是指一个连接(connection)
一次只提交一个请求的效率比较高, 多了就会变慢。 HTTP/1.1 试过用流水线(pipelining)来
解决这个问题, 但是效果并不理想(数据量较大或者速度较慢的响应, 会阻碍排在他后面的请求). 
此外, 由于网络媒介(intermediary )和服务器不能很好的支持流水线, 导致部署起来困难重重。
而多路传输(Multiplexing)能很好的解决这些问题, 因为它能同时处理多个消息的请求和响应; 
甚至可以在传输过程中将一个消息跟另外一个掺杂在一起。所以客户端只需要一个连接就能加载
一个页面。

3、使用报头压缩，HTTP/2降低了开销。假定一个页面有80个资源需要加载, 而每一次请求都有
1000字节的消息头（着同样也并不少见，因为Cookie和引用等东西的存在）, 至少要7到8个来
回去“在线”获得这些消息头。这还不包括响应时间——那只是从客户端那里获取到它们所花的时间
而已。这全都由于TCP的慢启动机制，它会基于对已知有多少个包，来确定还要来回去获取哪些
包 – 这很明显的限制了最初的几个来回可以发送的数据包的数量。

相比之下，即使是头部轻微的压缩也可以是让那些请求只需一个来回就能搞定——有时候甚至一个
包就可以了。这种开销是可以被节省下来的，特别是当你考虑移动客户端应用的时候，即使是良
好条件下，一般也会看到来回的延迟。

4、HTTP/2让服务器可以将响应主动“推送”到客户端缓存中，当浏览器请求一个网页时，服务器
将会发回HTML，在服务器开始发送JavaScript、图片和CSS前，服务器需要等待浏览器解析HTML
和发送所有内嵌资源的请求。服务器推送服务通过“推送”那些它认为客户端将会需要的内容到客户端
的缓存中，以此来避免往返的延迟