HTTP/1.1 的优点有哪些？
「简单、灵活和易于扩展、应用广泛和跨平台」
1. 简单
HTTP 基本的报文格式就是 header + body，头部信息也是 key-value 简单文本的形式，易于理解。
2. 灵活和易于扩展
HTTP 协议里的各类请求方法、URI/URL、状态码、头字段等每个组成要求都没有被固定死，都允许开发人员自定义和扩充。
同时 HTTP 由于是工作在应用层（ OSI 第七层），则它下层可以随意变化，比如：
- HTTPS 就是在 HTTP 与 TCP 层之间增加了 SSL/TLS 安全传输层；
- HTTP/1.1 和 HTTP/2.0 传输协议使用的是 TCP 协议，而到了 HTTP/3.0 传输协议改用了 UDP 协议。
3. 应用广泛和跨平台
HTTP/1.1 的缺点有哪些？
HTTP 协议里有优缺点一体的双刃剑，分别是「无状态、明文传输」，同时还有一大缺点「不安全」。
1. 无状态双刃剑
无状态的好处，因为服务器不会去记忆 HTTP 的状态，所以不需要额外的资源来记录状态信息，这能减轻服务器的负担。
无状态的坏处，没有记忆能力，那么在完成有关联性的操作时会非常麻烦。
例如登录->添加购物车->下单->结算->支付，这系列操作都要知道用户的身份才行。但服务器不知道这些请求是有关联的，每次都要问一遍身份信息。
通常使用 Cookie 技术来解决无状态问题。
Cookie 通过在请求和响应报文中写入 Cookie 信息来控制客户端的状态。
相当于，在客户端第一次请求后，服务器会下发一个装有客户信息的「小贴纸」，后续客户端请求服务器的时候，带上「小贴纸」，服务器就能认得了
2. 明文传输双刃剑
明文传输虽然易于阅读，但也增加了信息泄露的风险。
HTTP/1.1 的性能如何？
HTTP 协议是基于 TCP/IP ，并且使用了「请求 - 应答 」的通信模式，所以性能的关键就在这两点里。
1. 长连接
早期 HTTP/1.0 性能上的一个很大的问题，那就是每发起一个请求，都要新建一次 TCP 连接（三次握手），而且是串行请求，做了无谓的 TCP 连接建立和断开，增加了通信开销。
HTTP/1.1 提出了长连接的通信方式，也叫持久连接。这种方式减少了 TCP 连接的重复建立和断开所造成的额外开销，减轻了服务器端的负载。
持久连接的特点是，只要任意一端没有明确提出断开连接，则保持 TCP 连接状态。
如果某个 HTTP 长连接超过一定时间没有任何数据交互，服务端就会主动断开这个连接。
2. 管道网络传输
HTTP/1.1 采用了长连接的方式，这使得管道（pipeline）网络传输成为了可能。
即可在同一个 TCP 连接里面，客户端可以发起多个请求，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的响应时间。
举例来说，客户端需要请求两个资源。以前的做法是，在同一个 TCP 连接里面，先发送 A 请求，然后等待服务器做出回应，收到后再发出 B 请求。那么，管道机制则是允许浏览器同时发出 A 请求和 B 请求，如下图：
但是服务器必须按照接收请求的顺序发送对这些管道化请求的响应。
如果服务端在处理 A 请求时耗时比较长，那么后续的请求的处理都会被阻塞住，这称为「队头堵塞」。
所以，HTTP/1.1 管道解决了请求的队头阻塞，但是没有解决响应的队头阻塞。
注意：
实际上 HTTP/1.1 管道化技术不是默认开启，而且浏览器基本都没有支持，知道有这个功能，但是没有被使用就行了。
3. 队头阻塞
「请求 - 应答」的模式会造成 HTTP 的性能问题。
当顺序发送的请求序列中的一个请求因为某种原因被阻塞时，在后面排队的所有请求也一同被阻塞了，会招致客户端一直请求不到数据，这就是「队头阻塞」，好比上班的路上塞车。
总之 HTTP/1.1 的性能一般，后续的 HTTP/2 和 HTTP/3 就是在优化 HTTP 的性能。
HTTP/1.1采用了长连接来提高性能，只要客户端和服务器端没有一方主动断开连接，就会在一定时间内保持连接，从而避免了多次连接和断开产生的开销，长连接使得管道网络传输成为可能，之前的情况是必须等第一个请求得到响应时才能发送第二个请求，如果使用管道网络传输，那么就可以在发送的第一个请求没有得到响应时就发送第二个请求，但是服务器必须按照接收请求的顺序发送对这些管道化请求的响应，如果服务端在处理某一个请求时耗时比较长，那么后续的请求的处理都会被阻塞住，这称为「队头堵塞」，就和堵车一样，会导致客户端一直请求不到数据。
所以，HTTP/1.1 管道解决了请求的队头阻塞，但是没有解决响应的队头阻塞，不过管道网络传输默认关闭，且大多数浏览器没有支持，知道就行。