1.基础概念
HTTP/1.1 于 1997 年正式发布（RFC 2068），1999 年修订（RFC 2616），是目前使用时间最长、覆盖最广的 HTTP 版本。相比 HTTP/1.0，它在性能、功能和健壮性上都有根本性的提升。
HTTP 基本的报文格式就是 header + body，头部信息也是 key-value 简单文本的形式，易于理解。
灵活、易扩展。各类请求方法、URL、状态码，等每个组成都没有固定死，开发者可以自定义与扩充，HTTP在应用层其下层可以灵活变化（https就是HTTP与TCP之间增加SSL/TSL安全传输协议）
应用广泛、支持跨平台。
1.1 长连接
为了解决早期HTTP/1.0每次都要建立连接导致通信效率低的性能问题，因为HTTP基于TCP/IP协议
为了解决上述 TCP 连接问题，HTTP/1.1 提出了长连接的通信方式，也叫持久连接。这种方式的好处在于减少了 TCP 连接的重复建立和断开所造成的额外开销，减轻了服务器端的负载。
持久连接的特点是，只要任意一端没有明确提出断开连接，则保持 TCP 连接状态。如果某个 HTTP 长连接超过一定时间没有任何数据交互，服务端就会主动断开这个连接。
通过 Connection: keep-alive 保持连接，Connection: close 主动断开。服务器也可通过 Keep-Alive: timeout=60, max=100 控制连接最长存活时间和最多复用次数。
可以看到，长连接可以减少TCP握手和挥手次数，加强效率。
1.2 管道传输
因为HTTP/1.1 采用了长连接的方式，这使得管道（pipeline）网络传输成为了可能。如下图
即可在同一个 TCP 连接里面，客户端可以发起多个请求，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的 响应时间。但是服务器必须按照接收请求的顺序发送对这些管道化请求的响应。
如果服务端在处理 A 请求时耗时比较长，那么后续的请求的处理都会被阻塞住，这称为「队头堵塞」。所以，HTTP/1.1 管道解决了请求的队头阻塞，但是没有解决响应的队头阻塞。
注意：HTTP/1.1 管道化技术不是默认开启，而且浏览器基本都没有支持，所以后面讨论HTTP/1.1 都是建立在没有使用管道化的前提。同时并发请求也不会是采用管道化，而是一次性开启多个TCP连接。
1.3 缓存机制增强
HTTP/1.0 只有 Expires 和 Last-Modified 两个简单的缓存头。HTTP/1.1 引入了更精细的控制体系：
Cache-Control 常用指令包括 max-age=3600（新鲜期秒数）、no-cache（必须协商验证）、no-store（不缓存）、public/private（共享缓存或私有缓存）。ETag 是服务器为资源生成的指纹，比 Last-Modified 精度更高，解决了 1 秒内多次修改无法感知的问题。
1.4 新增状态和方法
HTTP/1.1 将方法从 3 个扩展到 8 个：
| 方法 | 语义 | 幂等 |
|---|---|---|
| GET | 获取资源 | 是 |
| HEAD | 只取响应头 | 是 |
| POST | 提交数据 | 否 |
| PUT | 整体替换资源 | 是 |
| DELETE | 删除资源 | 是 |
| OPTIONS | 查询支持的方法 | 是 |
| TRACE | 回显请求（调试） | 是 |
| CONNECT | 建立隧道（HTTPS代理） | — |
2.其他内容
-
Host 头强制要求
HTTP/1.0 中Host头是可选的，HTTP/1.1 将其列为必填字段。这使得一台物理服务器可以托管多个域名（虚拟主机），服务器通过Host字段区分请求属于哪个站点，是现代 Web 托管的基础。 -
范围请求（Range Request）
HTTP/1.1 新增了Range请求头，允许客户端只请求资源的某一段字节范围：Range: bytes=0-1023服务器返回
206 Partial Content表示成功。这是断点续传、多线程下载、视频拖拽播放的基础机制。 -
内容协商（Content Negotiation）
客户端通过请求头告知服务器自己的偏好，服务器返回最合适的版本：
Accept: text/html, application/json— 期望的内容类型Accept-Language: zh-CN, en— 期望的语言Accept-Encoding: gzip, br— 支持的压缩算法
服务端响应时通过Content-Type、Content-Language、Content-Encoding告知实际返回的格式。其中Accept-Encoding/Content-Encoding是最常用的，开启gzip压缩通常可将文本响应体体积压缩 60%~80%。
-
100 Continue 机制
当客户端需要发送一个大请求体（如上传大文件）时，可以先发送带有Expect: 100-continue的请求头，等服务器回复100 Continue后再发送请求体。如果服务器直接返回4xx，客户端就无需传输大体积数据，避免了无效带宽消耗。 -
分块传输编码（Chunked Transfer Encoding）
HTTP/1.0 要求响应头中必须有Content-Length，服务器必须提前知道响应体总大小才能发送。HTTP/1.1 允许使用Transfer-Encoding: chunked，服务器可以边生成内容边发送，每个"块"携带自身的大小，以大小为0的终止块结束，无需预知总长度。这对于动态生成的页面、流式 API 响应非常重要。