HTTP 1.0 / 1.1 / 2.0 的区别 - 计算机网络复习笔记

计算机网络复习笔记-Http 1.0/1.1/2.0 区别

什么是Http？

Http （超文本传输协议，HyperText Transfer Protocol）是一个简单的请求-响应协议，它通常基于TCP进行连接。所有的WWW文件都必须遵守这个标准。设计HTTP最初的目的是为了提供一种发布和接收HTML页面的方法。是用于从WWW服务器传输超文本到本地浏览器的传输协议。默认使用80端口，HTTP客户端发起一个请求，建立一个到服务器指定端口（默认是80端口）的TCP连接。请求和响应消息的头以ASCII码形式给出；而消息内容则具有一个类似MIME的格式。

Http 报文格式

Http协议的请求报文和响应报文的结构基本相同，由三大部分组成：

• 起始行（start line）: 描述请求或响应的基本信息
• 头部字段集合（header）：使用key-value形成更详细的说明报文
• 消息正文（entity）： 实际传输的数据，文本或是二进制数据（视频，图片等）

请求行报文头格式：

Method–空格–URL–空格–Version–换行

请求方法：表示对资源的操作 如GET/HEAD/PUT/POST
请求目标：表示对了请求方法要操作的资源，通常是一个URL
版本号：表示报文要使用的Http协议版本

常用的请求方法：

GET 请求获取Request-URI所标识的资源
POST 在Request-URI所标识的资源后附加新的数据
HEAD 请求获取由Request-URI所标识的资源的响应消息报头
PUT 请求服务器存储一个资源，并用Request-URI作为其标识
DELETE 请求服务器删除Request-URI所标识的资源
TRACE 请求服务器回送收到的请求信息，主要用于测试或诊断
CONNECT 保留将来使用
OPTIONS 请求查询服务器的性能，或者查询与资源相关的选项和需求

响应行报文头格式：

Version–空格–Status Code–空格–Reason–换行

版本号：表示报文要使用的Http协议版本
状态码：三位数，表示处理结果，如404，200，500
补充：作为补充说明帮助了解状态码的原因

；

为什么Http是基于TCP连接？

HTTP使用TCP而不是UDP的原因在于（打开）一个网页必须传送很多数据，而TCP协议提供传输控制，按顺序组织数据，和错误纠正。HTTP协议的瓶颈及其优化技巧都是基于TCP协议本身的特性。如TCP建立连接时三次握手有1.5个RTT（round-trip time）的延迟，为了避免每次请求的都经历握手带来的延迟，应用层会选择不同策略的http长链接方案。又如TCP在建立连接的初期有慢启动（slow start）的特性，所以连接的重用总是比新建连接性能要好。

Http标准现状

HTTP连接使用的是“请求—响应”的方式，不仅在请求时需要先建立连接，而且需要客户端向服务器发出请求后，服务器端才能回复数据。

• HTTP 1.0是第一个在通讯中指定版本号的HTTP 协议版本，至今仍被广泛采用，特别是在代理服务器中。
• HTTP/1.1是当前版本，持久连接（Connection ： Keep-Alive）被默认采用，并能很好地配合代理服务器工作，还支持以管道方式同时发送多个请求，以便降低线路负载，提高传输速度。
• HTTP／2.0在HTTP 1.x的基础上，大幅度的提高了web性能，减少了网络延迟。HTTP1.0和1.1在之后很长的一段时间内会一直并存，这是由于网络基础设施更新缓慢所决定的。

Http 1.0

HTTP 协议老的标准是HTTP/1.0，为了提高系统的效率，HTTP 1.0规定浏览器与服务器只保持短暂的连接，浏览器的每次请求都需要与服务器建立一个TCP连接，服务器完成请求处理后立即断开TCP连接，服务器不跟踪每个客户也不记录过去的请求。
这样做的缺点是由于每次客户端向服务器请求时都要重新建立TCP连接，当网页中包含有外部的静态资源的加载，如：图片，css和JS文件等，客户端还要根据这些资源的URL重新与服务器进行TCP的连接，即使图像文件都很小，但是客户端和服务器端每次建立和关闭连接却是一个相对比较费时的过程，并且会严重影响客户机和服务器的性能。
因此，Http1.0最明显的缺点之一就是连接无法复用，客户端是依据域名来向服务器建立连接，一般PC端浏览器会针对单个域名的服务器同时建立6～8个连接，手机端的连接数则一般控制在4～6个。显然连接数并不是越多越好，资源开销和整体延迟都会随之增大。连接无法复用会导致每次请求都经历三次握手和慢启动。三次握手在高延迟的场景下影响较明显，慢启动则对文件类大请求影响较大。
Http1.0的另外一个问题则是 head of line blocking: 会导致带宽无法被充分利用，以及后续健康请求被阻塞。假设有5个请求同时发出,对于HTTP1.0的实现, 在第一个请求没有收到回复之前，后续从应用层发出的请求只能排队，请求2，3，4，5只能等请求1的响应回来之后才能逐个发出。网络通畅的时候影响不大，一旦请求1的request因为什么原因没有抵达服务器，或者服务器响应因为网络阻塞没有及时返回，影响的就是所有后续请求，问题就变得比较严重了。

所以Http 1.1 和 Http 2.0 主要就是针对这两个问题提出了解决方案和办法：

解决办法
解决连接无法复用问题 ：

• http1.0协议头里可以设置Connection:Keep-Alive 在Http首部里设置Keep-Alive可以在一定时间内复用连接，具体复用时间的长短可以由服务器控制，一般在15s左右。一段时间内的连接复用对PC端浏览器的体验帮助很大，因为大部分的请求在集中在一小段时间以内。但对移动app来说，成效不大，app端的请求比较分散且时间跨度相对较大。所以移动端app一般会从应用层寻求其它解决方案。

• 在Http 1.1 和 Http 2.0 中： Connection的默认值就是Keep-Alive，如果要关闭连接复用需要显式的设置Connection:Close 。如果client使用http1.1 / 2.0 协议，但又不希望使用长链接，则需要在header中指明connection的值为close；如果server方也不想支持长链接，则在response中也需要明确说明connection的值为close。不论request还是response的header中包含了值为close的connection，都表明当前正在使用的tcp链接在当天请求处理完毕后会被断掉。以后client再进行新的请求时就必须创建新的tcp链接了。

解决head of line blocking问题 :
HTTP1.1和HTTP2.0的最大优势就是对于头部阻塞问题的解决.

• HTTP1.1的解决方案 - http pipelining： 和图一相比最大的差别是，请求2，3不用等请求1的response返回之后才发出，而是几乎在同一时间把request发向了服务器。2，3及所有后续共用该连接的请求节约了等待的时间，极大的降低了整体延迟。

• 缺点: pipelining只能适用于http1.1，一般来说，支持http1.1的server都要求支持pipelining。 只有幂等的请求（GET，HEAD）能使用pipelining，非幂等请求比如POST不能使用，因为请求之间可能会存在先后依赖关系。head of line blocking并没有完全得到解决，server的response还是要求依次返回，遵循FIFO(first in first out)原则。绝大部分的http代理服务器不支持pipelining。和不支持pipelining的老服务器协商有问题。可能会导致新的Front of queue blocking问题。正是因为有这么多的问题，各大浏览器厂商要么是根本就不支持pipelining，要么就是默认关掉了pipelining机制，而且启用的条件十分苛刻。

Http 2.0 的解决方案
多路复用（multiplexing）, 请求优先级（request prioritization）, 首部压缩（header packet）,服务器推送（server push）

• 多路复用（multiplexing） multiplexing允许同时通过单一的 HTTP/2 连接发起多重的请求-响应消息。在 HTTP/1.1 协议中浏览器客户端在同一时间，针对同一域名下的请求有一定数量限制，超过限制数目的请求会被阻塞。这也是为何一些站点会有多个静态资源 CDN 域名的原因之一，拿 Twitter 为例，http://twimg.com，目的就是变相的解决浏览器针对同一域名的请求限制阻塞问题。 而 HTTP/2 的多路复用(Multiplexing) 则允许同时通过单一的 HTTP/2 连接发起多重的请求-响应消息。因此 HTTP/2 可以很容易的去实现多流并行而不用依赖建立多个 TCP 连接，HTTP/2 把 HTTP 协议通信的基本单位缩小为一个一个的帧，这些帧对应着逻辑流中的消息。并行地在同一个 TCP 连接上双向交换消息。
• 首部压缩（Header Compression） HTTP/1.1并不支持 HTTP 首部压缩，为此 SPDY 和 HTTP/2 应运而生， SPDY 使用的是通用的DEFLATE 算法，而 HTTP/2 则使用了专门为首部压缩而设计的 HPACK 算法。
• 服务端推送（Server Push）：服务器推送是一种在客户端请求之前发送数据的机制。在 HTTP/2 中，服务器可以对客户端的一个请求发送多个响应。Server Push 让 HTTP1.x 时代使用内嵌资源的优化手段变得没有意义；如果一个请求是由你的主页发起的，服务器很可能会响应主页内容、logo 以及样式表，因为它知道客户端会用到这些东西。这相当于在一个 HTML 文档内集合了所有的资源。不过与之相比，服务器推送还有一个很大的优势：可以缓存，也让在遵循同源的情况下，不同页面之间可以共享缓存资源成为可能。

参考文章https://baike.baidu.com/item/HTTP%202.0/12520156?fr=aladdin
https://blog.csdn.net/qq_39207948/article/details/80969968