『30 天沉淀 90 mins』Day 2 http1.1 与 http2.0 入门

HTTP

参考资料:

  1. 小林Coding-HTTP

HTTP基础

HTTP 是超文本传输协议,也就是HyperText Transfer Protocol。

HTTP 错误码分类:

HTTP 常见字段:

  1. Host 指定域名
  2. Content-Lentgh 数据长度
  • HTTP 协议通过设置回车符、换行符作为 HTTP header 的边界,
  • 通过 Content-Length 字段作为 HTTP body 的边界,这两个方式都是为了解决“粘包”的问题。
  1. Connection 常用于客户端要求服务器使用「HTTP 长连接」机制, 一般填 “Keep Alive”
  2. Content-Type 数据格式
  3. Content-Encoding 数据压缩格式

GET,POST

根据 RFC 规范。

  • GET 的语义是从服务器获取指定的资源
  • POST 的语义是根据请求负荷(报文body)对指定的资源做出处理

安全与幂等

  • 在 HTTP 协议里,所谓的「安全」是指请求方法不会「破坏」服务器上的资源。——GET
  • 所谓的「幂等」,意思是多次执行相同的操作,结果都是「相同」的。——GET
  • POST 由于会修改服务器上的资源不满足上述条件

HTTP 缓存

对于重复性的 HTTP 请求,可以把请求缓存在本地,立刻响应结果

强制缓存

利用下面这两个 HTTP 响应头部字段实现的,它们都用来表示资源在客户端缓存的有效期:

  • Cache-Control, 是一个相对时间;
  • Expires,是一个绝对时间;
    浏览器再次发出请求访问时查本地缓存,优先使用 Cache-Control,每次相应刷新字段。

协商缓存

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

前端喜欢问这玩意--,懒得看了

HTTP 1.1

优点:

  1. 简单,HTTP 基本的报文格式就是 header + body,头部信息也是 key-value 简单文本的形式,易于理解,降低了学习和使用的门槛。
  2. 灵活和易于扩展,HTTP 协议里的各类请求方法、URI/URL、状态码、头字段等每个组成要求都没有被固定死,都允许开发人员自定义和扩充。
  3. 应用广泛和跨平台
  4. 管道传输,批量请求,解决了请求的队头阻塞,但是没有解决响应的队头阻塞。(默认不开启)

缺点:

  1. 无状态,如例如登录->添加购物车->下单->结算->支付,每次都需要验证用户身份
  2. 不安全
  • 通信使用明文(不加密),内容可能会被窃听。
  • 不验证通信方的身份,因此有可能遭遇伪装。
  • 无法证明报文的完整性(正确性),所以有可能已遭篡改。

性能瓶颈

  1. Header未经压缩就发送,首部信息越多延迟越大。只能压缩 Body 的部分;(http2.0)
  2. 发送冗长的首部。每次互相发送相同的首部造成的浪费较多;(http2.0)
  3. 响应队头阻塞,服务器是按请求的顺序响应的,如果服务器响应慢,会招致客户端一直请求不到数据;(http3.0 QUIC)
  4. 没有请求优先级控制;
  5. 请求只能从客户端开始,服务器只能被动响应。(服务器不能主动推送,http2.0 solved)

HTTP2.0

基于 https, 安全性有保障

性能上的改进

  1. 头部压缩,如果你同时发出多个请求,他们的头是一样的或是相似的,那么,协议会帮你消除重复的部分。
  • HPACK: 在客户端和服务器同时维护一张头信息表,所有字段都会存入这个表,生成一个索引号,以后就不发送同样字段了,只发送索引号,这样就提高速度了。
  1. 二进制格式,HTTP/2 不再像 HTTP/1.1 里的纯文本形式的报文,而是全面采用了二进制格式。
  • 头信息和数据体都是二进制,并且统称为帧(frame):头信息帧(Headers Frame)和数据帧(Data Frame)。
  • 收到报文后直接解析二进制,比如 200 原来用 '2','0','0' 三个字节来表示,压缩以后是 10001000 即 200 在静态表中表示(在http2.0中出现),只需要 1 个字节即可!
  1. 并发传输,引出了 Stream 概念,多个 Stream 复用在一条 TCP 连接。
  • 针对不同的 HTTP 请求用独一无二的 Stream ID 来区分,接收端可以通过 Stream ID 有序组装成 HTTP 消息,不同 Stream 的帧是可以乱序发送的,因此可以并发不同的 Stream ,也就是 HTTP/2 可以并行交错地发送请求和响应。
  • 客户端收到后,会根据相同的 Stream ID 有序组装成 HTTP 消息。
  1. 服务器推送,可以主动向客户端发送消息。
  • 客户端和服务器双方都可以建立 Stream, Stream ID 也是有区别的,客户端建立的 Stream 必须是奇数号,而服务器建立的 Stream 必须是偶数号。

缺点

  • 由于基于TCP协议,存在 TCP 协议上的队头阻塞。
  • 一旦发生了丢包现象,就会触发 TCP 的重传机制,这样在一个 TCP 连接中的所有的 HTTP 请求都必须等待这个丢了的包被重传回来
posted @ 2023-08-23 01:07  Roshin  阅读(20)  评论(0编辑  收藏  举报
-->