相较于HTTP 1.0，1.1 版本增加了以上特性：
1. 新增了连接管理即 keepalive，允许持久连接。
定义：
Keepalive允许客户端和服务器在完成一次请求-响应后，保持连接处于打开状态，以便后续请求复用同一连接，而无需重新建立连接。
工作原理：
- 客户端通过TCP三次握手与服务器建立连接。
- 客户端发送HTTP请求，服务器处理后返回响应。
- 服务器不会立即关闭连接，而是保持空闲状态，等待后续请求。
- 如果客户端在预设时间内发送新的请求，服务器将复用此连接。
- 超过空闲时间后，服务器会关闭连接以节省资源。
优势：
- 减少连接开销： 避免了频繁的TCP连接建立和关闭，节省时间和带宽。
- 提升性能： 特别适用于需要多个小请求的场景，如加载多张图片或脚本。
2. 支持pipeline，无需等待前面的请求响应，即可发送第二次请求。
定义：
Pipeline允许客户端在一个连接中连续发送多个HTTP请求，而无需等待前一个响应。
工作原理：
- 客户端在同一个连接中发送多个请求。
- 服务器按顺序处理请求，并依次返回响应。
- 客户端在发送完所有请求后，等待服务器按顺序返回响应。
优势：
- 减少延迟： 减少等待时间，尤其在高延迟网络中效果显著。
- 提高吞吐量： 客户端可以并行发送请求，提高整体传输效率。
注意事项：
- 服务器处理顺序： 响应必须按请求顺序返回，服务器无法重新排序。
- 潜在问题： 管道中的任何一个请求失败可能导致后续请求处理延迟或失败。
3. 支持分块传输编码（Chunked Transfer Coding）
在HTTP协议中允许服务器将响应分成多个块发送，而无需提前知道内容的总长度。这在处理大型文件时特别有用，因为它提高了传输效率，减少了客户端等待时间。
以下是一个简明的示例：客户端请求从服务器下载一个10GB的视频文件。
传统方法（无分块传输）：
- 客户端发送HTTP GET请求到服务器。
- 服务器处理请求，开始读取视频文件。
- 服务器计算整个文件的大小，并在响应头中设置Content-Length: 10737418240（10GB）。
- 服务器将整个文件一次性发送给客户端。
- 客户端等待接收完整个文件后，才能开始播放。
分块传输方法：
- 客户端发送HTTP GET请求，支持接受分块传输。
- 服务器开始处理请求，并将视频文件分割成多个块（例如，每块1MB）。
- 服务器在响应头中设置Transfer-Encoding: chunked，指示使用分块传输，不设置Content-Length。
- 服务器开始发送第一个块，包含块的大小（以十六进制表示）和块数据。
- 客户端接收到每个块后，立即开始处理（如播放视频），无需等待所有块传输完成。
- 服务器发送完最后一个块后，发送一个0大小的块，表示传输结束（EOF）。
- 客户端完成接收，处理完成。
优点：
客户端可以边下载边处理，提升用户体验。
服务器无需预先计算总长度，减少延迟。
节省内存，适用于大数据传输。
总结：
分块传输编码在处理大文件时显著提升了效率，减少了等待时间，适用于流媒体、大型文件下载等场景。
4. 新增缓存的控制和管理。
HTTP/1.1中，缓存控制和管理主要通过以下机制实现：
1. Cache-Control头部（用于控制缓存行为，如缓存有效期、缓存范围等。）
- max-age=[seconds]：指定资源在缓存中的有效时间。
- s-maxage=[seconds]：针对共享缓存（如CDN）的有效时间
- no-cache：强制每次请求都验证资源是否过期。
- no-store：禁止缓存任何内容。
- public和private：分别允许或限制第三方缓存。
2. ETag头部（提供资源的唯一标识，用于验证资源是否更改。）
- 工作原理：当客户端再次请求资源时，会发送If-None-Match头部，服务器通过ETag判断资源是否过期，若未变化则返回304状态码。
3. Last-Modified头部（指示资源的最后修改时间。）
- 工作原理：客户端在请求中包含If-Modified-Since头部，服务器比较时间戳，若资源未更改则返回304状态码。
4. 缓存验证机制
- 强缓存：直接使用缓存内容，无需服务器验证。
- 协商缓存：客户端携带缓存验证信息（如ETag或Last-Modified），服务器确认资源是否过期后，决定是否返回新内容。
5. 缓存有效期管理
- 过期时间：通过Cache-Control设置资源的缓存时长，过期后客户端会重新请求资源。
- 服务器处理：服务器在接收到过期缓存请求时，会重新生成响应，确保客户端获得最新内容。
6. 缓存控制策略
- 合理设置缓存时间：根据资源更新频率，设置适当的max-age值，平衡缓存和更新需求。
- 使用ETag提升效率：避免频繁的全响应，通过ETag快速判断资源是否变化。
- 灵活运用Cache-Control指令：根据资源类型（如公开或私有）选择合适的缓存策略。
通过以上机制，HTTP/1.1有效地管理了缓存，提升了资源加载速度，减少了服务器负载。合理配置这些头部和机制，可以显著优化网站性能和用户体验。
5. 加入host头
在HTTP/1.1协议中，Host头字段的作用非常重要，主要体现在以下几个方面：
标识目标服务器：
Host头字段指定了请求的目标服务器的域名和端口号（如果端口号非默认）。例如，Host: www.example.com表示请求的目标是www.example.com服务器。这使得服务器能够根据域名确定请求的来源，特别是在虚拟主机环境中，多个网站可以共享同一个IP地址，但通过不同的Host头来区分不同的域名。
支持虚拟主机：
通过Host头，服务器可以托管多个网站，每个网站使用不同的域名。当一个请求到达服务器时，服务器会解析Host头，从而确定应该将请求路由到哪个虚拟主机上，提供相应的资源。这极大提高了服务器资源的利用率。
路由和定位资源：
服务器根据Host头来确定请求的目标资源。这有助于服务器正确地路由请求，确保请求能够到达正确的应用程序或服务。例如，一个服务器可能托管多个应用程序，每个应用程序对应不同的域名，通过Host头可以实现精准的路由。
安全性：
Host头还用于防止某些类型的攻击，如HTTP头注入攻击。通过验证Host头的值，服务器可以确保请求的来源是合法的，从而增强安全性。
区分大小写：
虽然域名通常以小写显示，但Host头是区分大小写的。理论上，不同的大小写可能指向不同的资源，但大多数情况下，服务器会将大小写视为不敏感。
不包含路径信息：
Host头只包含域名和端口号，不包含请求的路径信息。路径信息在URI中指定，Host头的作用是明确请求的目标服务器，而路径则用于定位具体资源。
总结：
Host头在HTTP/1.1中起到了至关重要的作用，它不仅帮助服务器识别请求的目标，还支持虚拟主机的实现，提高资源利用率，同时增强安全性。正确配置和使用Host头是确保HTTP通信正常进行的关键。
6. 名词解释
EOF：End of File，这是一个关键的信号，用于指示文件传输的结束。