- 报文分为请求报文和响应报文，是 HTTP 通信中的基本单位，由 8 位组字节流组成。
- 报文分为报文头部、空行和报文主体。
- 报文主体是可选的，如一个 GET 请求报文中，就没有报文主体。
- 实体其实是报文的一部分，存在于报文主体内，作为请求或响应的有效载荷数据被传输。
- 实体的内容由实体首部和实体主体组成。实体主体是我们想要传输的实际信息，实体首部是对该信息的描述。
- 通常，报文主体等于实体主体。只有当传输中进行编码操作时，实体主体的内容发生变化，才导致它和报文主体产生差异。
- 一个报文里一个包含多个实体，实体里，也有实体头部、实体主体，同样是通过CR+LF分割。
- 常用的内容编码有以下几种。
- gzip（GNU zip）
- compress（UNIX 系统的标准压缩）
- deflate（zlib）
- identity（不进行编码）
- 在传输大容量数据时，通过把数据分割成多块，能够让浏览器逐步显示页面。这种把实体主体分块的功能称为 分块传输编码.
- HTTP 协议中也采纳了 多部分对象集合(Multipart)，发送的一份报文主体内可含有多类型实体。通常是在图片或文本文件等上传时使用。
- 以前，如果下载过程中遇到网络中断的情况，那就必须重头开始。为了解决上述问题，需要一种可恢复的机制。所谓恢复是指能从之前下载中断处恢复下载。
- 要实现该功能需要指定下载的实体范围。像这样，指定范围发送的请求叫做 范围请求（Range Request）。
- 针对范围请求，响应会返回状态码为206 Partial Content的响应报文。如果服务器端无法响应范围请求，则会返回状态码200 OK 和完整的实体内容。
- 当浏览器的默认语言为英语或中文，访问相同 URI 的 Web 页面时，则会显示对应的英语版或中文版的 Web 页面。这样的机制称为内容协商（Content Negotiation）。
- 内容协商机制是指客户端和服务器端就响应的资源内容进行交涉，然后提供给客户端最为适合的资源。内容协商会以响应资源的语言、字符集、编码方式等作为判断的基准。
- 内容协商技术有以下 3 种类型。
- 服务器驱动协商（Server-driven Negotiation）：由服务器端进行内容协商。以请求的首部字段为参考，在服务器端自动处理。
- 客户端驱动协商（Agent-driven Negotiation）：由客户端进行内容协商的方式。用户从浏览器显示的可选项列表中手动选择。
- 透明协商（Transparent Negotiation）：是服务器驱动和客户端驱动的结合体，是由服务器端和客户端各自进行内容协商的一种方法。
- HTTP 状态码负责表示客户端 HTTP 请求的返回结果，标记服务器端的处理是否正常，通知出现的错误等工作。
- 借助状态码，用户可以知道服务器端是正常处理了请求，还是出现了错误。
- 状态码的类别如下：
| 状态码 | 类别 | 原因短语 |
|---|---|---|
| 1XX | Informational 信息性状态码 | 接收的请求正在处理 |
| 2XX | Success 成功状态码 | 请求正常处理完毕 |
| 3XX | Redirection 重定向状态码 | 需要进行附加以完成请求 |
| 4XX | Client Error 客户端错误状态码 | 服务器无法处请求 |
| 5XX | Server Error 服务器状态码 | 服务器处理请求出错 |
- 只要遵守状态码类别的定义，即使改变 RFC2616 中定义的状态码，或服务器端自行创建状态码都没问题。
- 在响应报文内，随状态码一起返回的信息会因方法的不同而发生改变。
- 一些常见的 HTTP 状态码
| 状态码 | 含义 |
|---|---|
| 200 OK | 请求已经正常处理 |
| 204 No Content | 响应报文中不含也不允许返回任何实体的主体 |
| 206 Partial Content | 响应报文中包含由 Content-Range 指定范围的实体内容 |
| 301 Moved Permanently | 请求的资源已被永久性分配了新的URI: Location 首部字段提示的 URI |
| 302 Found | 临时性重定向。该状态码表示请求的资源已被分配了新的 URI，希望用户（本次）能使用新的 URI 访问。 |
| 303 See Other | 请求对应的资源存在着另一个 URI，应使用 GET 方法定向获取请求的资源。 |
| 304 Not Modified | 客户端发送附带条件的请求时，服务器端允许请求访问资源，但因发生请求未满足条件 |
| 307 Temporary Redirect | 临时重定向。该状态码与 302 Found 有着相同的含义 |
| 400 Bad Request | 请求报文中存在语法错误 |
| 401 Unauthorized | 发送的请求需要有通过 HTTP认证（BASIC认证、DIGEST认证）的认证信息。 另外若之前已进行过 1 次请求，则表示用户认证失败。 |
| 403 Forbidden | 请求资源的访问被服务器拒绝了。服务器端没有必要给出拒绝的详细理由 |
| 404 Not Found | 服务器上无法找到请求的资源。或服务器端拒绝请求且不想说明理由时使用。 |
| 500 Internal Server Error | 服务器端在执行请求时发生了错误。也有可能是 Web 应用存在的 bug 或某些临时的故障。 |
| 503 Service Unavailable | 服务器暂时处于超负载或正在进行停机维护，现在无法处理请求。 |
- 即使物理层面只有一台服务器，但只要使用虚拟主机的功能，则可以假想已具有多台服务器。
- 虚拟主机（Virtual Host，又称虚拟服务器）。
- 如果一台服务器内托管了 www.tricorder.jp 和 www.hackr.jp 这两个域名，当收到请求时就需要弄清楚究竟要访问哪个域名。在相同的 IP 地址下，由于虚拟主机可以寄存多个不同主机名和域名的 Web 网站，因此在发送 HTTP 请求时，必须在 Host 首部内完整指定主机名或域名的 URI。
- HTTP 通信时，除客户端和服务器以外，还有一些用于通信数据转发的应用程序，例如代理、网关和隧道。它们可以配合服务器工作。这些应用程序和服务器可以将请求转发给通信线路上的下一站服务器，并且能接收从那台服务器发送的响应再转发给客户端。
- 代理：代理是一种有转发功能的应用程序，它扮演了位于服务器和客户端“中间人”的角色，接收由客户端发送的请求并转发给服务器，同时也接收服务器返回的响应并转发给客户端。
- 网关：网关是转发其他服务器通信数据的服务器，接收从客户端发送来的请求时，它就像自己拥有资源的源服务器一样对请求进行处理。有时客户端可能都不会察觉，自己的通信目标是一个网关。
- 隧道：隧道是在相隔甚远的客户端和服务器两者之间进行中转，并保持双方通信连接的应用程序。
- 代理不改变请求 URI，会直接发送给前方持有资源的目标服务器。
- 持有资源实体的服务器被称为源服务器。
- 每次通过代理服务器转发请求或响应时，会追加写入 Via 首部信息。
- 使用代理服务器的理由有：利用缓存技术减少网络带宽的流量，组织内部针对特定网站的访问控制，以获取访问日志为主要目的，等等。
- 代理有多种使用方法，按两种基准分类。一种是是否使用缓存，另一种是是否会修改报文。
- 缓存代理：代理转发响应时，缓存代理（Caching Proxy）会预先将资源的副本（缓存）保存在代理服务器上。 当代理再次接收到对相同资源的请求时，就可以不从源服务器那里获取资源，而是将之前缓存的资源作为响应返回。
- 透明代理转发请求或响应时，不对报文做任何加工的代理类型被称为透明代理（Transparent Proxy）。反之，对报文内容进行加工的代理被称为非透明代理。
- 网关的工作机制和代理十分相似。而网关能使通信线路上的服务器提供非 HTTP 协议服务。
- 利用网关能提高通信的安全性，因为可以在客户端与网关之间的通信线路上加密以确保连接的安全。 比如，网关可以连接数据库，使用 SQL 语句查询数据。另外，在 Web 购物网站上进行信用卡结算时，网关可以和信用卡结算系统联动。
- 隧道可按要求建立起一条与其他服务器的通信线路，届时使用 SSL 等加密手段进行通信。隧道的目的是确保客户端能与服务器进行安全的通信。
- 隧道本身不会去解析HTTP请求。也就是说，请求保持原样中转给之后的服务器。隧道会在通信双方断开连接时结束。
- 通过隧道的传输，可以和远距离的服务器安全通信。隧道本身是透明的，客户端不用在意隧道的存在。
- 缓存是指代理服务器或客户端本地磁盘内保存的资源副本。利用缓存可减少对源服务器的访问，因此也就节省了通信流量和通信时间。缓存服务器是代理服务器的一种，并归类在缓存代理类型中。
- 缓存服务器的优势在于利用缓存可避免多次从源服务器转发资源。因此客户端可就近从缓存服务器上获取资源，而源服务器也不必多次处理相同的请求了。
- 即使存在缓存，也会因为客户端的要求、缓存的有效期等因素，向源服务器确认资源的有效性。若判断缓存失效，缓存服务器将会再次从源服务器上获取“新”资源。
- 缓存不仅可以存在于缓存服务器内，还可以存在客户端浏览器中。 以 Internet Explorer 程序为例，把客户端缓存称为临时网络文件（Temporary Internet File）。
- 浏览器缓存如果有效，就不必再向服务器请求相同的资源了，可以直接从本地磁盘内读取。