《HTTP权威指南》学习笔记

---

Web及HTTP基础

Web客户端和服务器
Web 内容都是存储在 Web 服务器上的。 Web 服务器所使用的是 HTTP 协议， 因此经常会被称为 HTTP 服务器。 这些 HTTP 服务器存储了因特网中的数据， 如果HTTP 客户端发出请求的话， 它们会提供数据。
客户端向服务器发送 HTTP 请求，服务器会在 HTTP 响应中回送所请求的数据。

资源
Web 服务器是 Web 资源（ Web resource） 的宿主。 Web 资源是 Web 内容的源头。
【Web资源可以是静态文件，如文本文件、HTML文件；也可以是根据需要生成内容的软件程序，这些动态内容资源可以根据你的身份、 所请求的信息或每天的不同时段来产生内容 】
所有类型的内容来源都是资源。

• 媒体类型
  MIME（Multipurpose Internet Mail Extension， 多用途因特网邮件扩展）在电子邮件系统中工作得非常好， 因此 HTTP 也采纳了它， 用它来描述并标记多媒体内容。
  Web 服务器会为所有 HTTP 对象数据附加一个 MIME 类型。
  当 Web浏览器从服务器中取回一个对象时， 会去查看相关的 MIME 类型， 看看它是否知道应该如何处理这个对象。

Content-type: image/jpeg 中的image就是一种MIME类型

• URI与URL
  服务器资源名被称为统一资源标识符（ Uniform Resource Identifier， URI）。
  统一资源定位符（ URL） 是资源标识符最常见的形式。 URL 描述了一台特定服务器上某资源的特定位置。 它们可以明确说明如何从一个精确、 固定的位置获取资源。
• 事务
  一个 HTTP 事务由一条（ 从客户端发往服务器的） 请求命令和一个（ 从服务器发回客户端的） 响应结果组成。 这种通信是通过名为 HTTP 报文（ HTTP message）的格式化数据块进行的。

/* 常见的请求报文header格式 */
GET / HTTP/1.1
Host: www.google.com.hk
Content-Type: application/json
Cache-Control: no-cache

/* 响应报文header */
HTTP/1.0 200 OK www.joes-hardware.com
Content-type: image/gif
Content-length: 8572方法

/* 一些常见的HTTP方法 */
GET 从服务器向客户端发送命名资源
PUT 将来自客户端的数据存储到一个命名的服务器资源中去
DELETE 从服务器中删除命名资源
POST 将客户端数据发送到一个服务器网关应用程序
HEAD 仅发送命名资源响应中的 HTTP 首部

/* 一些常见的HTTP状态码 */
200 OK。文档正确返回
302 Redirect（重定向）。到其他地方去获取资源
404 Not Found（没找到）。无法找到这个资源

一个“Web页面” 通常并不是单个资源，而是一组资源的集合

报文

一个简单事务所使用的HTTP报文

HTTP 报文包括以下三个部分：
• 起始行
报文的第一行就是起始行，在请求报文中用来说明要做些什么，在响应报文中说明出现了什么情况。
• 首部字段
起始行后面有零个或多个首部字段。每个首部字段都包含一个名字和一个值，为了便于解析，两者之间用冒号（ :）来分隔。首部以一个空行结束。添加一个首部字段和添加新行一样简单。
• 主体
空行之后就是可选的报文主体了，其中包含了所有类型的数据。请求主体中包括了要发送给Web服务器的数据；响应主体中装载了要返回给客户端的数据。起始行和首部都是文本形式且都是结构化的，而主体中可以包含任意的二进制数据（比如图片、视频、音轨、软件程序）。当然，主体中也可以包含文本。

连接

• TCP/IP
  HTTP 是个应用层协议。HTTP 无需操心网络通信的具体细节； 它把联网的细节都交给了通用、 可靠的因特网传输协议TCP/IP。

TCP 提供了：
• 无差错的数据传输
• 按序传输（ 数据总是会按照发送的顺序到达）
• 未分段的数据流（ 可以在任意时刻以任意尺寸将数据发送出去）
只要建立了 TCP 连接， 客户端和服务器之间的报文交换就不会丢失、不会被破坏，
也不会在接收时出现错序了。

HTTP 网络协议栈

• 连接、 IP地址及端口号
  在 HTTP 客户端向服务器发送报文之前，需要用网际协议（Internet Protocol，IP）地址和端口号在客户端和服务器之间建立一条TCP/IP 连接。
  【在 TCP 中，你需要知道服务器的 IP 地址，以及与服务器上运行的特定软件相关的TCP 端口号。（URL 就是资源的地址，所以自然能够为我们提供存储资源的机器的 IP 地址）】
  HTTP 的 URL 中没有端口号时， 可以假设默认端口号是 80。

  
  
  

  基本的浏览器连接处理

步骤如下：
(a) 浏览器从 URL 中解析出服务器的主机名；
(b) 浏览器将服务器的主机名转换成服务器的 IP 地址；
(c) 浏览器将端口号（ 如果有的话） 从 URL 中解析出来；
(d) 浏览器建立一条与 Web 服务器的 TCP 连接；
(e) 浏览器向服务器发送一条 HTTP 请求报文；
(f) 服务器向浏览器回送一条 HTTP 响应报文；
(g) 关闭连接， 浏览器显示文档。

Web的结构组件
Web 应用程序除了Web 浏览器和 Web 服务器之外，比较重要的还有：
• 代理
位于客户端和服务器之间的 HTTP 中间实体。
代理位于客户端和服务器之间， 接收所有客户端的 HTTP 请求， 并
将这些请求转发给服务器（ 可能会对请求进行修改之后转发）。

在客户端和服务器之间转发流量的代理

• 缓存
HTTP 的仓库， 使常用页面的副本可以保存在离客户端更近的地方。
Web 缓存（ Web cache） 或代理缓存（ proxy cache） 是一种特殊的 HTTP 代理服务器， 可以将经过代理传送的常用文档复制保存起来。 下一个请求同一文档的客户端就可以享受缓存的私有副本所提供的服务了。

保存常用文档本地副本以提高性能的代理缓存

• 网关
连接其他应用程序的特殊 Web 服务器。
网关（ gateway） 是一种特殊的服务器， 作为其他服务器的中间实体使用。 通常用于将 HTTP 流量转换成其他协议。

HTTP/FTP 网关

• 隧道（ tunnel）
对 HTTP 通信报文进行盲转发的特殊代理。
HTTP 隧道通常用来在一条或多条 HTTP 连接上转发非 HTTP 数据， 转发时不会窥探数据。

隧道可以在非 HTTP 网络上转发数据（ 显示的是 HTTP/SSL 隧道）

• Agent 代理
发起自动 HTTP 请求的半智能 Web 客户端。
用户 Agent 代理（ 或者简称为 Agent 代理） 是代表用户发起 HTTP 请求的客户端程序。 所有发布 Web 请求的应用程序都是 HTTP Agent 代理。如Web浏览器、“ 网络蜘蛛”/爬虫（spiders）。

自动搜索引擎“ 网络蜘蛛” 就是 Agent 代理， 可以从世界范围内获取 Web 页面

URL与资源

URL 是浏览器寻找信息时所需的资源位置。
URL 提供了一种统一的资源命名方式。 大多数 URL 都有同样的：“ 方案 :// 服务器位置 / 路径” 结构。

比如说， 你想要获取 URL http://www.joeshardware.com/seasonal/index-fall.html。
那么 URL 分以下三部分：
• URL 的第一部分（http）是 URL 方案（scheme）。方案可以告知 Web 客户端怎样访问资源。在这个例子中，URL 说明要使用 HTTP 协议。
• URL 的第二部分（www.joes-hardware.com）指的是服务器的位置。这部分告知Web 客户端资源位于何处。
• URL 的第三部分（/seasonal/index-fall.html）是资源路径。路径说明了请求的是服务器上哪个特定的本地资源。

URL的语法
大多数 URL 方案的 URL 语法都建立在这个由 9 部分构成的通用格式上：

://:@:/;?#

URL 最重要的 3 个部分是方案（scheme）、主机（host）和路径（path）。

• 方案实际上是规定如何访问指定资源的主要标识符， 它会告诉负责解析 URL 的应用程序应该使用什么协议。
• 主机组件标识了因特网上能够访问资源的宿主机器。端口组件标识了服务器正在监听的网络端口，对下层使用了 TCP 协议的 HTTP 来说，默认端口号为 80。
  【URL 的主机和端口组件提供了哪台机器装载了资源，以及在那台机器的什么地方可以找到能对目标资源进行访问的服务器这两组信息】
• URL 的路径组件说明了资源位于服务器的什么地方。

URL 是可移植的（portable）。它要统一地命名因特网上所有的资源，这也就意味着要通过各种不同的协议来传送这些资源。这些协议在传输数据时都会使用不同的机制，所以，设计 URL，使其可以通过任意因特网协议安全地传输是很重要的。(安全传输意味着 URL 的传输不能丢失信息)
URL要设计成可读的。
URL 还得是完整的。需要有一种转义机制，能够将不安全的字符编码为安全字符，再进行传输。

编码机制
为了避开安全字符集表示法带来的限制，人们设计了一种编码机制，用来在 URL 中表示各种不安全的字符。这种编码机制就是通过一种“转义” 表示法来表示不安全字符的， 这种转义表示法包含一个百分号（%），后面跟着两个表示字符 ASCII 码的十六进制数。

字符    ASCII码    示例URL
~      126(0x7E)   http://www.joes-hardware.com/%7Ejoe
空格   32(0x20)    http://www.joes-hardware.com/more%20tools.html
%     37(0x25)    http://www.joes-hardware.com/100%25satisfaction.html

HTTP报文

报文流
HTTP 报文是在 HTTP 应用程序之间发送的数据块。这些数据块以一些文本形式的元信息（meta-information） 开头，这些信息描述了报文的内容及含义，后面跟着可选的数据部分。这些报文在客户端、服务器和代理之间流动。

报文流入源端服务器并流回到客户端

报文的组成部分
HTTP 报文是简单的格式化数据块。每条报文都包含一条来自客户端的请求，或者一条来自服务器的响应。它们由三个部分组成：对报文进行描述的起始行（start line）、包含属性的首部（header）块，以及可选的、包含数据的主体（body） 部分。

HTTP 报文的三个部分

• 报文的语法
  所有的 HTTP 报文都可以分为两类：请求报文（request message）和响应报文（response message）。请求报文会向 Web 服务器请求一个动作。响应报文会将请求的结果返回给客户端。请求和响应报文的基本报文结构相同。

  
  
  

  包含请求和响应报文的 HTTP 事务

这是请求报文的格式：
  


这是响应报文的格式（注意，只有起始行的语法有所不同）：
  

状态码分类

常见状态码

方法

• 安全方法
  GET 方法和 HEAD 方法都被认为是安全的。
  【安全方法并不一定是什么动作都不执行的（ 实际上， 这是由 Web 开发者决定的）。使用安全方法的目的就是当使用可能引发某一动作的不安全方法时， 允许 HTTP 应用程序开发者通知用户。 】
• GET 方法通常用于请求服务器发送某个资源。
• HEAD 方法与 GET 方法的行为类似，但服务器在响应中只返回首部。

使用 HEAD，可以：
• 在不获取资源的情况下了解资源的情况（ 比如， 判断其类型） ；
• 通过查看响应中的状态码，看看某个对象是否存在；
• 通过查看首部，测试资源是否被修改了。

• PUT 方法会向服务器写入文档。
  PUT 方法的语义就是让服务器用请求的主体部分来创建一个由所请求的 URL 命名的新文档，或者，如果那个 URL 已经存在的话，就用这个主体来替代它。【因为 PUT 允许用户对内容进行修改，所以很多 Web 服务器都要求在执行 PUT 之前，用密码登录】
• POST 方法起初是用来向服务器输入数据的。
  实际上，通常会用它来支持 HTML的表单。表单中填好的数据通常会被送给服务器，然后由服务器将其发送到它要去的地方。

• TRACE
  客户端发起一个请求时，这个请求可能要穿过防火墙、代理、网关或其他一些应用程序。每个中间节点都可能会修改原始的 HTTP 请求。TRACE 方法允许客户端在最终将请求发送给服务器时，看看它变成了什么样子。
  TRACE 方法主要用于诊断。也就是说，用于验证请求是否如愿穿过了请求 / 响应链。它也是一种很好的工具，可以用来查看代理和其他应用程序对用户请求所产生效果。

  
  
  

  TRACE 示例

• OPTIONS 方法请求 Web 服务器告知其支持的各种功能。可以询问服务器通常支持哪些方法，或者对某些特殊资源支持哪些方法。
  这为客户端应用程序提供了一种手段，使其不用实际访问那些资源就能判定访问各种资源的最优方式。

  
  
  

  OPTIONS 示例
• DELETE 方法所做的事情就是请服务器删除请求 URL 所指定的资源。
  但是，客户端应用程序无法保证删除操作一定会被执行。因为 HTTP 规范允许服务器在不通知客户端的情况下撤销请求。
• 扩展方法指的就是没有在 HTTP/1.1 规范中定义的方法。
  服务器会为它所管理的资源实现一些 HTTP 服务，这些方法为开发者提供了一种扩展这些 HTTP 服务能力的手段。

状态码

• 100~199——信息性状态码
• 200~299——成功状态码
• 300~399——重定向状态码
• 400~499——客户端错误状态码
• 500~599——服务器错误状态码

首部
首部和方法配合工作，共同决定了客户端和服务器能做什么事情。

• 通用首部（客户端和服务器都可以使用）

比如，Date 首部就是一个通用首部， 每一端都可以用它来说明构建报文的时间和日期:
Date: Tue, 3 Oct 1974 02:16:00 GMT

• 请求首部（请求报文特有的）

例如，下面的 Accept 首部就用 来告知服务器客户端会接受与其请求相符的任意媒体类型:
Accept: */*

• 响应首部（为客户端提供信息）

HTTP结构

Web服务器
所有的 Web 服务器（不管功能有何差异）都能够接收请求资源的 HTTP 请求，将内容回送给客户端。
Web 服务器实现了 HTTP（协议） 和相关的 TCP 连接处理，负责管理 Web （服务器提供的）资源，以及对 Web 服务器的（配置、控制及扩展方面的）管理。
Web 服务器逻辑和操作系统共同负责管理 TCP 连接。底层操作系统负责管理底层计算机系统的硬件细节，并提供了 TCP/IP 网络支持、负责装载 Web 资源的文件系统以及控制当前计算活动的进程管理功能。

Web服务器的基本功能
(1) 建立连接— — 接受一个客户端连接， 或者如果不希望与这个客户端建立连接， 就将其关闭。
(2) 接收请求— — 从网络中读取一条 HTTP 请求报文。
(3) 处理请求— — 对请求报文进行解释， 并采取行动。
(4) 访问资源— — 访问报文中指定的资源。
(5) 构建响应— — 创建带有正确首部的 HTTP 响应报文。
(6) 发送响应— — 将响应回送给客户端。
(7) 记录事务处理过程— — 将与已完成事务有关的内容记录在一个日志文件中。

基本 Web 服务器请求的步骤