背景

为什么设计成无状态协议以及带来的问题

在HTTP协议诞生之际（也就是HTTP 1.0版本），为了能够快速的处理大量事务，确保协议的可伸缩性，而特意把HTTP协议设计成无状态（stateless）协议。

无状态协议表示：HTTP协议自身不对请求和响应之间的通信状态进行保存，对发送过的请求或响应不做持久化处理。

无状态连接的缺点

这样就会造成一个问题：每一次的HTTP请求就需要建立一次TCP连接，随着后续网络的发展，一个HTML文档就需要很多其他资源，需要发送不止一次的HTTP请求，这就会造成无谓的TCP连接建立和断开，增加通信量的开销。

无状态连接的优点

但是无状态连接也有优点：不必保存，自然可以减少服务器的CPU及内存资源的消耗。

HTTP 1.1 针对无状态协议做了哪些措施？

HTTP 1.1虽然还是无状态协议，但是为了实现期望的保持状态功能，这个版本提供了两种方案：

• 引入了cookie技术
• 持久连接（keep-alive）方案

cookie技术

cookie技术常用来对web页面的登录认证进行持久状态保存。

原理

Cookie会根据从服务端发送的响应报文内的一个叫做Set-Cookie的首部字段信息，通知客户端保存Cookie。当下次客户端再往该服务器发送请求时，客户端会自动在请求报文中加入Cookie值后发送出去。

服务端发现客户端发送过来的Cookie后，会去检查究竟是从哪一个客户端发来的连接请求，然后对比服务器上的记录，最后得到之前的状态信息。

持久连接（keep-alive）方案

持久连接（HTTP Persistent Connections），也称为HTTP keep-alive或HTTP connection reuse，只要任意一端未提出断开连接，则保持TCP连接状态。

在HTTP 1.1中，所有的连接默认就是持久连接。

管线化机制

持久连接使得所数请求以管线化（pipelining）方式发送成为可能。

从前发送请求后需要等待并收到响应，才能发送下一个请求。管线化技术出现后，不用等待响应也可直接发送下一个请求。这样就可以同时并行发送多个请求。但是各个浏览器资源请求并发是有上限的（如谷歌浏览器为 6 个，这导致你必须要减少资源请求数）

线头阻塞

在HTTP 1.1持久连接下，多个HTTP请求放在一个TCP连接里，其响应顺序是按请求顺序来的，如果一个请求出现阻塞，后面的就需要等待，这就是线头阻塞。

HTTP 2.0

多路复用

HTTP 1.1默认连接是持久连接模式，在这个模式下，实现了管线化发送机制，但是又催生了一个线头阻塞的问题，针对这个问题，HTTP 2.0 提出了多路复用。即多个请求复用一个TCP连接，TCP连接分若干流，且互不影响，不需要按顺序响应。

并且，在多路复用模式下，不需要考虑请求并发量的问题。

总结

因为无状态连接，HTTP1.1引入了两钟方案：cookie与keep-alive。而因为keep-alive的实现，也实现了管线化机制，但也催生了线头阻塞问题。

针对HTTP1.1的线头阻塞问题，HTTP2.0提出了多路复用方案。

参考文章

《图解HTTP》- 【日】上野宣著