HTTP 协议

概况

HTTP 是超文本传输协议,它定义了客户端和服务器之间交换报文的格式和方式,默认采用80端口,它使用TCP作为传输层协议,保证了数据传输的可靠性

HTTP 是一个无状态的协议,HTTP 服务器不会保存关于客户端的任务信息

HTTP 有两种连接模式,一种是持续连接,一种是非持续连接;
非持续连接指的是服务器必须为每一个请求的对象建立和维护一个全新的连接;持续连接,TCP 连接默认不关闭,可以被多个请求复用;采用持续连接的好处是可以避免每次建立 TCP 连接三次握手时所花费的时间;

在HTTP1.0 以前使用的非持续的连接,但是可以在请求时,加上Connection: keep-alive 来要求服务器不要关闭 TCP 连接

在HTTP1.1以后默认采用的是持续的连接;目前对于同一个域,大多数浏览器支持同时建立 6 个持久连接

HTTP 协议的各个版本

HTTP 是基于 TCP/IP 协议的应用层协议; 它不涉及数据包传输,主要规定了客户端和服务器之间的通信格式,默认使用80端口

HTTP/0.9

最早的版本是0.9版本,该版本及其简单,只有一个命令 GET

1
2
GET / index.html
// TCP 连接建立后,客户端向服务器请求网页 index.html

协议规定,服务器只能回应 HTML 格式的字符串,不能回应别的格式
服务器发送完毕,就关闭 TCP 连接

HTTP/1.0

HTTP1.0 版本发布,内容大大增加

  1. 首先,任何格式内容都可以发送; 可以传输文字 / 图像 / 视频 / 二进制 文件
  2. 除了 GET 命令,还引入了 POST / HEAD 命令,使传输信息变得更丰富
  3. HTTP 请求和回应格式也发生改变了,每次通信都必须包含头信息,用来描述一些元数据
  4. 新增状态码 / 缓存 / 内容编码 / 字符编码 /等等

Content-Type 字段

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

  • text/plain
  • text/html
  • text/css
  • image/jpeg
    …

Content-Encoding 字符

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

1
2
3
Content-Encoding: gzip
Content-Encoding: compress
Content-Encoding: deflate

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

1
Accept-Encoding: gizp,deflate

HTTP/1.0 的缺点

每次 TCP 连接只能发送一个请求,发送数据完毕,连接就关闭,如果还要请求其他资源,就必须再新建一个连接
TCP 连接的新建成本高,所以 HTTP/1.0 版本性能较差
为了解决这个问题,有些浏览器在请求时,用了一个非标准的 Connection 字段

1
Connection:keep-alive

这个字符要求服务器不要关闭 TCP 连接,以便其他请求复用,服务器同样回应这个字段

1
Connection:keep-alive

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

HTTP/1.1

HTTP/1.1版本的发布,它进一步完善了 HTTP 协议

持久连接

1.1版本的最大变化,就是引入了持久连接,即 TCP 连接默认不关闭,可以被多个请求复用,不用声明 Connection:keep-alive
客户端和服务器发现对方一段时间没有活动,就可以主动关闭连接;不过,规范的做法是,客户端在最后一个请求时,发送 Connection: close,明确要求服务器关闭 TCP 连接,对于同一个域名,大多数浏览器允许同时建立 6 个持久连接

管道机制

1.1版本引入了管道机制,即在同一个 TCP 连接里面,客户端可以同时发送多个请求,这样就进一步改进了 HTTP 协议的效率

举例来说,客户端需要请求两个资源,在1.1版本以前的做法是,在同一个 TCP 连接里面,先发送 A 请求,然后等待服务器做出回应,收到后再发送B请求,管道机制则是允许浏览器同时发送A请求和B请求,但服务器还是按照顺序,先回应A请求,完成后再回应B请求

另外增加了 PUT / PATCH / DELETE 等方法

缺点

虽然1.1版本允许复用 TCP 连接,但是同一个 TCP 连接里面,所有的数据通信是依次进行的,服务器只有处理完一个回应,才会进行下一个回应,要是前一个回应特别慢,后面就会 有许多请排队等着,这称为 队头阻塞
为了避免这个问题,只有两种方法: 一是减少请求数, 二是同时打开多个持久连接,这就是我们对网站优化时，使用雪碧图、合并脚本的原因。

HTTP/2

HTTP/2 是谷歌自行研发的 SPDY 协议,主要解决 HTTP/1.1 效率不高的问题

HTTP/2 主要有以下新的特性:

二进制协议

HTTP/2 是一个二进制协议,在 HTTP/1.1 版本中,报文的头信息必须是文本(ASCII编码),数据体可以是文本,也可以是二进制,HTTP/2 则是一个彻底的二进制协议,头信息和数据体都是二进制的,并且统称为 “ 帧 “ ,可以分为头信息帧和数据帧
帧的概念是它实现多路复用的基础

多路复用

HTTP/2 实现了多路复用,HTTP/2 仍然复用 TCP 连接,但是一个连接里,客户端和服务器都可以同时发送多个请求或回应,而且不用按照顺序一一发送,这样就避免了 “队头阻塞” 的问题

数据流

HTTP/2 使用了数据流的概念,因为HTTP/2 的数据包不是按顺序发送的,同一个连接里面连续的数据包,可能属于不同的请求;因此,必须要对数据包做标记,指出它属于哪个请求;HTTP/2 将每个请求或回应的所有数据包,称为一个数据流;
每个数据流都有一个独一无二的编号;数据包发送的时候,都必须标记数据流 ID ,用来区分它属于哪个数据流

头信息压缩

HTTP/2 实现了头信息压缩,由于 HTTP 1.1 协议不带有状态,每次请求都必须附上所有信息,所以请求的很多字段都是重复的,比如 Cookie 和 User Agent,一模一样的内容,每次请求都必须附带,这会浪费很多带宽,也影响速度

HTTP/2 对这一点做了优化,引入了头新压缩机制,一方面,头信息使用 gzip 或 compress 压缩后再发送;另一方面,客户端和服务器同时维护一张头信息表,所有字段都会存入这个表,生成一个索引号,以后就不发送同样字段了,只发送索引号,这样就能提供速度了

服务器推送

HTTP/2 允许服务器未经请求,主动向客户端发送资源,这叫做服务器推送,使用服务器推送,提前给客户端提送必要的资源,这样就可以相对减少一些延迟时间,这里需要注意的是 HTTP2 下服务器主动推送的是静态资源和 webSocket 以及使用 SSE 等方式向客户端发送即时数据的推送是不同的

HTTP/2 协议缺点

因为 HTTP/2 使用了多路复用,一般来说同一域名下只需要使用一个 TCP 连接,由于多个数据流使用同一个 TCP 连接,遵守同一个同一个流量状态控制和拥塞控制,只要一个数据流遭遇拥塞,剩下的数据流就没法发出去,这样就导致了后面的所有数据都被阻塞, HTTP/2 出现的这个问题是由于其使用 TCP 协议的问题,与它本身的实现没有多大关系

HTTP/3 协议

由于 TCP 本身存在的一些限制,Google 就开发了一个基于 UDP 协议的 QUIC 协议,并且使用在了 HTTP/3上,QUIC 协议在 UDP 协议上实现了 多路复用 / 有序交付 / 重传 等等功能

HTTP 存在的问题

  1. HTTP 报文使用明文的方式发送,可能被第三方窃听
  2. HTTP 报文可能被第三方截取后修改通信内容,接收方没有办法发现报文内容的修改
  3. HTTP 还存在认证的问题,第三方可以冒充他人参与通信

HTTPS

HTTPS 指的是超文本传输安全协议,HTTPS 是基于 HTTP 协议的,不过它会使用 TLS/SSL 来对数据加密,使用 TLS/SSL 协议,所有的信息都是加密的,第三方没有办法窃听;并且它提供了一种校验机制,信息一旦被篡改,通信的双方会立刻发现,它还配备了身份证书,防止身边被冒充的情况出现

TLS 握手实现原理

TLS 的握手过程主要用到了三个方法来保证传输的安全

  1. 首先的对称加密的方法,对称加密的方法是,双方使用同一个密钥对数据进行加密和解密,但对称加密存在的一个问题就是如何保证密钥传输的安全性,因为密钥还是会通过网络传输的,一旦密钥被其他人获取到,那么整个加密过程就毫无作用;这就要用到非对称加密的方法

  2. 非对称加密的方法是,我们拥有两个密钥,一个是公钥,一个是私钥,公钥是公开的,私钥是保密的,用私钥加密的数据只有对应的公钥才能解密,我们可以将公钥公布出去,任务想和我们通信的客户,都可以使用我们提供的公钥对数据进行加密,然后使用私钥进行解密,这样就能保证数据的安全了,但是非对称加密有一个缺点就是加密的过程很慢,因此如果每次通信都使用非对称加密的方法的话,反而会造成等待时间过长的问题; 因此我们可以使用对称加密和非对称加密结合的方法,因为对称加密方式的缺点就是无法保证密钥的安全传输,因此我们可以以非对称加密方式来对对称加密的密钥进行传输,然后以后通信使用对称加密的方式来加密,这样就解决了两个方法各种存在的问题

  3. 但是现在的方法也不一定是安全的,因为我们没有办法确定我们得到的公钥就一定是安全的公钥,可能存在一个中间人,截取了对方发给我们的公钥,然后将他自己的公钥发送给我们,当我们使用他的公钥加密后发送的信息,就可以被他用自己的私钥解密,然后伪装我们以同样的方法向对方发送信息,这样我们的信息就被窃取了,然而我们自己还不知道
    为了解决这样的问题,我们可以使用数字证书的方式,首先我们使用一种 Hash 算法来对我们的公钥和其他信息进行加密生成一个信息摘要,然后让有公信力的认证中心,用它的私钥对消息摘要加密,形成签名,最后将原始的信息和签名结合在一起,称为数字证书,当接收方接收到数字证书的时候,先根据原始信息使用同一的 Hash 算法生成一个摘要,然后使用公证处的公钥来对数字证书中的摘要进行解密,最后将解密的摘要和我们生成的摘要进行对比,就能发现我们得到的信息是否被更改了这个方法最重要的是认证中心的可靠性,一般浏览器里会内置一些顶层的认证中心的证书,相当与我们自动信任了他们,只有这样我们才能保证数据的安全

HTTP 和 HTTPS 的区别

  • HTTPS 协议需要申请证书
  • HTTP 和 HTTPS 使用端口不一样,前者是80, 后者是443
  • HTTP 协议运行在 TCP 之上,所有传输的内容都是明文,HTTPS 运行在 SSL/TLS 之上, SSL/TLS 运行在 TCP 之上,所有传输的内容都是密文传输
  • HTTPS 可以有效的防止运营商劫持

为什么 HTTP/1.1 不能实现多路复用

http/2的多路复用是基于二进制协议实现的,在http/1.1 中头部报文信息必须是文本，服务器接收数据后无法识别多个响应对应的请求
http/2中实现了二进制协议，也就是说 头部信息是二进制的，叫“帧”，所以头部信息和数据体 也称为头部信息帧和数据帧。
同时 http/2 中引入了数据流的概念，帧表示最小的数据单位，每个帧会标识出该帧属于哪个流，流也就是多个帧组合的数据。