HTTP/1.1
优点
简单
HTTP 基本的报文格式就是 header + body,头部信息也是 key-value 简单文本的形式,易于理解,降低了学习和使用的门槛。灵活和易于扩展
HTTP 协议里的各类请求方法、URI/URL、状态码、头字段等每个组成要求都没有被固定死,都允许开发人员
自定义和扩充
。
同时 HTTP 由于是工作在应用层( OSI 第七层),则它下层可以随意变化,比如:
- HTTPS 就是在 HTTP 与 TCP 层之间增加了 SSL/TLS 安全传输层;
- HTTP/1.1 和 HTTP/2.0 传输协议使用的是 TCP 协议,而到了 HTTP/3.0 传输协议改用了 UDP 协议
缺点
- 无状态:双刃剑
- 好处:服务器不会去记忆 HTTP 的状态,所以不需要额外的资源来记录状态信息,这能减轻服务器的负担,能够把更多的 CPU 和内存用来对外提供服务
- 坏处:在完成有关联性的操作时会非常麻烦。例如:登录->添加购物车->下单->结算->支付,这系列操作都要知道用户的身份才行。但服务器不知道这些请求是有关联的,每次都要问一遍身份信息
解决方案:Cookie 技术
相当于在客户端第一次请求后,服务器会下发一个装有客户信息的「小贴纸」,后续客户端请求服务器的时候,带上「小贴纸」,服务器就能认得用户
- 不安全:
- 通信使用明文(不加密),内容可能会被窃听
- 不验证通信方的身份,因此有可能遭遇伪装。比如,访问假的淘宝、拼多多,那你钱没了
- 无法证明报文的完整性,所以有可能已遭篡改。
解决方案:HTTPS,也就是通过引入 SSL/TLS 层
性能
HTTP 协议是基于 TCP/IP,并且使用了「请求 - 应答」的通信模式
- 长连接
- HTTP/1.0 性能上的一个很大的问题,那就是每发起一个请求,都要新建一次 TCP 连接(三次握手)
- HTTP/1.1 提出了长连接的通信方式,也叫持久连接,特点是,只要任意一端没有明确提出断开连接,则保持 TCP 连接状态
- 管道网络传输
- 同一个 TCP 连接里面,客户端可以发起多个请求,只要第一个请求发出去了,不必等其回来,就可以发第二个请求出去,可以减少整体的响应时间
- 举例来说,客户端需要请求两个资源。以前的做法是,在同一个 TCP 连接里面,先发送 A 请求,然后等待服务器做出回应,收到后再发出 B 请求。那么,管道机制则是允许浏览器同时发出 A 请求和 B 请求
- 但是服务器必须按照接收请求的顺序发送对这些管道化请求的响应;如果服务端在处理 A 请求时耗时比较长,那么后续的请求的处理都会被阻塞住,这称为「队头堵塞」。所以,HTTP/1.1 管道解决了请求的队头阻塞,但是没有解决响应的队头阻塞
实际上 HTTP/1.1 管道化技术不是默认开启,而且浏览器基本都没有支持
- 队头阻塞:「请求 - 应答」的模式会造成 HTTP 的性能问题
当顺序发送的请求序列中的一个请求因为某种原因被阻塞时,在后面排队的所有请求也一同被阻塞了,会招致客户端一直请求不到数据,这也就是「队头阻塞」
总结:HTTP/1.1 的性能一般,后续的 HTTP/2 和 HTTP/3 就是在优化 HTTP 的性能