跳到主要内容

HTTP

HTTP 超文本传输协议(HyperText Transfer Protocol)，是一个客户端(用户)和服务端(网站)之间的请求和应答的标准，通常使用 TCP 协议。通过使用网页浏览器、网络爬虫或者其他工具。客户端发起一个 HTTP 请求到服务器上指定端口(默认端口 80)。

尽管 TCP/IP 协议协议是互联网上最流行的应用，但是在 HTTP 协议中并没有规定它必须使用或者它支持的层。事实上 HTTP 可以在任何互联网协议或其他网络上实现。

版本发展历程​

  • HTTP/0.9：为了便于服务器和客户端处理，采用了纯文本格式，只能用 get 请求，在响应请求之后会立即关闭连接。
  • HTTP/1.0：增加了 0.9 版本，引入了 HTTP Header 的概念，传输的数据不在仅限于文本，可以解析图片音乐等，增加了响应状态码和 post、head 等请求方法
  • HTTP/1.1：正式标准，允许持久链接，允许响应数据分块，增加了缓存管理和控制，增加了 put、delete 等新方法
  • HTTP/2：使用 Hpack 算法压缩头部，减少数据传输量。允许服务端主动向客户端推送数据，二进制协议可以发起多个请求，使用时需要对请求加密通信
  • HTTP/3：基于 UDP 的 QUIC 协议

HTTP/1.1​

HTTP/1.1 消除了大量歧义内容并引入多项改进：

  • 连接可以复用，节省了多次打开 TCP 连接加载网页文档资源时间
  • 增加管线化技术，允许在第一个应答被完全发送之前就发送第二个请求，以降低通信延迟
  • 支持响应分块
  • 引入额外的缓存控制机制
  • 引入内容协商机制，包括语言，编码，类型等，并允许客户端与服务器之间约定以最合适的内容进行交换
  • 凭借 Host 头，能够是不同域名配置在同一个 IP 地址的服务器上

HTTP/1.1 存在的性能瓶颈：

  • 请求/响应头部(Header)未经压缩就发送，首部信息越多延迟越大。只能压缩 body 部分
  • 发送冗⻓的⾸部。每次互相发送相同的⾸部造成的浪费较多
  • 服务器是按请求顺序响应的，如果服务器响应慢，会导致客户端一直请求不到数据，队头阻塞
  • 没有请求优先级控制
  • 请求只能从客户端开始，服务端只能被动响应

HTTP/2​

HTTP/2 协议是基于 HTTPS 的，所以 HTTP/2 的安全性也是有保障的

相比较 HTTP/1.x 性能上的改进：

  • 二进制协议：采用二进制协议而不是文本协议，头信息和数据体都是二进制，并且统称为帧：头部信息帧和数据帧
  • 头部压缩：因为在 headers 在一系列请求中常常是相似的，其移除了重复和传输重复数据的成本。（HPACK 算法：在客户端和服务端同时维护一张头信息表，所有字段都会存入这个表，生成一个索引号，以后就不用发送同样字段，只发送索引号即可）
  • 多路复用：复用协议，并行的请求能在同一个连接中处理，移除了 HTTP/1.x 中顺序和阻塞的约束
  • 服务器推送：允许服务器直接提供浏览器渲染页面所需资源，而无须浏览器在收到、解析页面后再提起一轮请求，节约了加载时间

还存在哪些缺陷：

多个 HTTP 请求在复用一个 TCP 连接，下层的 TCP 协议是不知道有多少个 HTTP 请求的。所以一旦发生丢包现象，就会触发 TCP 的重传机制，这样在一个 TCP 连接的所有 HTTP 请求都必须等待这个丢了的包被重传回来。

HTTP/3​

在 HTTP/3 中，弃用 TCP 协议，改为使用 UDP 协议的 QUIC 协议实现。此变化主要为了解决 HTTP/2 存在的队头阻塞问题。

  • HTTP/1.1 中的管道传输中如果一个请求阻塞了，那么队列后请求也统统被阻塞住
  • HTTP/2 多个请求复用一个 TCP 连接，受到 TCP 拥塞控制的影响，少量的丢包就可能导致整个 TCP 连接上的所有流被阻塞

这都是基于 TCP 传输层的问题，所以 HTTP/3 把下层的 TCP 协议改成了 UDP

请求方法​

HTTP 定义了一组请求方法，以表明要对给定资源执行的操作

GET：从服务器获取一份文档
HEAD：只从服务器获取文档首部
POST：向服务器发送需要处理的数据
PUT：向服务器发送需要处理的数据
DELETE：从服务器删除一份文档
CONNECT：Sever Error(服务端错误状态码)
OPTIONS：决定可以在服务器上执行那些方法
TRACE：对可能经过代理服务器传送到服务器上去的报文进行追踪
GET 和 POST 的区别？
  1. GET 请求会被浏览器主动缓存下来，POST 不会
  2. GET 请求参数放在 URL 中，POST 放在请求体（浏览器存在 URL 长度限制）
  3. GET 是幂等的，POST 不是
OPTIONS 请求？
  1. 主要用于跨域的时候，而且只有复杂请求的时候才会出现，默认 GET 和 POST 都是简单请求，但如果自定义 headers 信息，就变成复杂请求
  2. 为了避免发送的数据浪费，所以先发送一个预检请求，如果能访问，再发送数据
  3. 预检请求的时间可以自己控制(可以控制发送 options 的间隔时间) 服务端控制

跨域​

浏览器不能执行其他网站的脚本。它是由浏览器的同源策略造成的，是浏览器对 JavaScript 实施的安全限制。

所谓同源策略就是两个页面具有相同的协议(protocol)、主机(host)和端口号(port)，当一个请求的 url 的协议、主机、端口三者之间任意一个与当前页面 url 不同即为跨域。

跨域限制以下行为：

  • Cookie、LocalStorage 和 IndexDB 无法读取
  • DOM 和 JS 对象无法获取
  • Ajax 请求发送不出去

跨域的解决办法：

  • JSONP
  • Iframe
  • CORS
  • Nginx 反向代理
  • Websocket

https://blog.csdn.net/lgxzzz/article/details/121618676

缓存​

HTTP 缓存有两种实现方式强制缓存和协商缓存

强制缓存​

强缓存指的是只要浏览器判断缓存没有过期，则直接使用浏览器的本地缓存，决定是否使用缓存的主动性在于浏览器这边。

  • Cache-Control 新版本 相对时间
    • no-cache 需要使用对比缓存验证数据,强制向源服务器再次验证
    • no-store 所有内容都不会缓存，强制缓存和对比缓存都不会触发
    • private 客户端可以缓存
    • public 客户端和代理服务器都可以缓存
    • max-age=60 缓存内容将在 60 秒后失效
  • Expires 旧版本 绝对时间

如果 HTTP 响应头部同时有 Cache-Control 和 Expires 字段的话，Cache-Control 的优先级高于 Expires 。

协商缓存​

协商缓存就是与服务端协商之后，通过协商结果来判断是否使用本地缓存。

实现缓存

视频讲解：Node 实现 HTTP 强制缓存&协商缓存
代码：https://github.com/iiLsss/cache

HTTPS​

HTTP 采用明文传输，中间人可以获取到明文数据(从而实现对数据的篡改)。这时候 HTTPS 就登场了。HTTPS = HTTP + SSL/TLS， SSL 安全套接层(Secure Sockets Layer) 发展到 v3 改名为 TLS 传输层安全(Transport Layer Security)，主要目标是提供数据的完整性和保密性

客户端使用非对称加密与服务器进行通信，实现身份验证并协商对称加密使用的秘钥

原理​

第一步 ClientHello​

首先，由客户端向服务器发起加密通信请求，也就是 ClientHello 请求。

  • 客户端支持的 SSL/TLS 协议版本，如 TLS 1.2 版本。
  • 客户端生产的随机数（Client Random），后面用于生成「会话秘钥」条件之一。
  • 客户端支持的密码套件列表，如 RSA 加密算法。
第二步 SeverHello​

服务器收到客户端请求后，向客户端发出响应，也就是 SeverHello。服务器回应的内容有如下内容：

  • 确认 SSL/ TLS 协议版本，如果浏览器不支持，则关闭加密通信。
  • 服务器生产的随机数（Server Random），也是后面用于生产「会话秘钥」条件之一。
  • 确认的密码套件列表，如 RSA 加密算法。
  • 服务器的数字证书。
第三步 客户端回应​

客户端收到服务器的回应之后，首先通过浏览器或者操作系统中的 CA 公钥，确认服务器的数字证书的真实性。如果证书没有问题，客户端会从数字证书中取出服务器的公钥，然后使用它加密报文，向服务器发送如下信息：

  • 一个随机数（pre-master key）。该随机数会被服务器公钥加密。
  • 加密通信算法改变通知，表示随后的信息都将用「会话秘钥」加密通信。
  • 客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要，用来供服务端校验。

服务器和客户端有了这三个随机数（Client Random、Server Random、pre-master key），接着就用双方协商的加密算法，各自生成本次通信的「会话秘钥」。

第四步 服务器的最后回应​

服务器收到客户端的第三个随机数（pre-master key）之后，通过协商的加密算法，计算出本次通信的「会话秘钥」。

  • 加密通信算法改变通知，表示随后的信息都将用「会话秘钥」加密通信。
  • 服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要，用来供客户端校验。

至此，整个 SSL/TLS 的握手阶段全部结束。接下来，客户端与服务器进入加密通信，就完全是使用普通的 HTTP 协议，只不过用「会话秘钥」加密内容。

https://zhuanlan.zhihu.com/p/43789231

https 主要在 SSL/TLS 阶段使用非对称加密，基于 CA 证书的验证身份。为本次对话生成一个会话密钥的过程

参考资料​

https://blog.csdn.net/lgxzzz/article/details/121618676