『30 天沉淀 90 mins』Day 2 http1.1 与 http2.0 入门
HTTP
参考资料:
HTTP基础
HTTP 是超文本传输协议,也就是HyperText Transfer Protocol。
HTTP 错误码分类:
HTTP 常见字段:
- Host 指定域名
- Content-Lentgh 数据长度
- HTTP 协议通过设置回车符、换行符作为 HTTP header 的边界,
- 通过 Content-Length 字段作为 HTTP body 的边界,这两个方式都是为了解决“粘包”的问题。
- Connection 常用于客户端要求服务器使用「HTTP 长连接」机制, 一般填 “Keep Alive”
- Content-Type 数据格式
- Content-Encoding 数据压缩格式
GET,POST
根据 RFC 规范。
- GET 的语义是从服务器获取指定的资源
- POST 的语义是根据请求负荷(报文body)对指定的资源做出处理
安全与幂等
- 在 HTTP 协议里,所谓的「安全」是指请求方法不会「破坏」服务器上的资源。——GET
- 所谓的「幂等」,意思是多次执行相同的操作,结果都是「相同」的。——GET
- POST 由于会修改服务器上的资源不满足上述条件
HTTP 缓存
对于重复性的 HTTP 请求,可以把请求缓存在本地,立刻响应结果
强制缓存
利用下面这两个 HTTP 响应头部字段实现的,它们都用来表示资源在客户端缓存的有效期:
- Cache-Control, 是一个相对时间;
- Expires,是一个绝对时间;
浏览器再次发出请求访问时查本地缓存,优先使用 Cache-Control,每次相应刷新字段。
协商缓存
协商缓存就是与服务端协商之后,通过协商结果来判断是否使用本地缓存。
前端喜欢问这玩意--,懒得看了
HTTP 1.1
优点:
- 简单,HTTP 基本的报文格式就是 header + body,头部信息也是 key-value 简单文本的形式,易于理解,降低了学习和使用的门槛。
- 灵活和易于扩展,HTTP 协议里的各类请求方法、URI/URL、状态码、头字段等每个组成要求都没有被固定死,都允许开发人员自定义和扩充。
- 应用广泛和跨平台
- 管道传输,批量请求,解决了请求的队头阻塞,但是没有解决响应的队头阻塞。(默认不开启)
缺点:
- 无状态,如例如登录->添加购物车->下单->结算->支付,每次都需要验证用户身份
- 不安全
- 通信使用明文(不加密),内容可能会被窃听。
- 不验证通信方的身份,因此有可能遭遇伪装。
- 无法证明报文的完整性(正确性),所以有可能已遭篡改。
性能瓶颈
- Header未经压缩就发送,首部信息越多延迟越大。只能压缩 Body 的部分;(http2.0)
- 发送冗长的首部。每次互相发送相同的首部造成的浪费较多;(http2.0)
- 响应队头阻塞,服务器是按请求的顺序响应的,如果服务器响应慢,会招致客户端一直请求不到数据;(http3.0 QUIC)
- 没有请求优先级控制;
- 请求只能从客户端开始,服务器只能被动响应。(服务器不能主动推送,http2.0 solved)
HTTP2.0
基于 https, 安全性有保障。
性能上的改进:
- 头部压缩,如果你同时发出多个请求,他们的头是一样的或是相似的,那么,协议会帮你消除重复的部分。
HPACK
: 在客户端和服务器同时维护一张头信息表,所有字段都会存入这个表,生成一个索引号,以后就不发送同样字段了,只发送索引号,这样就提高速度了。
- 二进制格式,HTTP/2 不再像 HTTP/1.1 里的纯文本形式的报文,而是全面采用了二进制格式。
- 头信息和数据体都是二进制,并且统称为帧(frame):头信息帧(Headers Frame)和数据帧(Data Frame)。
- 收到报文后直接解析二进制,比如 200 原来用
'2','0','0'
三个字节来表示,压缩以后是10001000
即 200 在静态表中表示(在http2.0中出现),只需要 1 个字节即可!
- 并发传输,引出了 Stream 概念,多个 Stream 复用在一条 TCP 连接。
- 针对不同的 HTTP 请求用独一无二的 Stream ID 来区分,接收端可以通过 Stream ID 有序组装成 HTTP 消息,不同 Stream 的帧是可以乱序发送的,因此可以并发不同的 Stream ,也就是 HTTP/2 可以并行交错地发送请求和响应。
- 客户端收到后,会根据相同的 Stream ID 有序组装成 HTTP 消息。
- 服务器推送,可以主动向客户端发送消息。
- 客户端和服务器双方都可以建立 Stream, Stream ID 也是有区别的,客户端建立的 Stream 必须是奇数号,而服务器建立的 Stream 必须是偶数号。
缺点:
- 由于基于TCP协议,存在 TCP 协议上的队头阻塞。
- 一旦发生了丢包现象,就会触发 TCP 的重传机制,这样在一个 TCP 连接中的所有的 HTTP 请求都必须等待这个丢了的包被重传回来。