2018 February 15

《http权威指南》部分摘录

http基础

URL（Uniform Resource Locator） URI（Uniform Resource Identifier），URN（Uniform Resource Name）分别都是什么
FTP（file transport protocol）文件传输协议http（hyper text transport protocol）超文本传输协议
永久统一资源定位符(persistent uniform resource locators，PURL)是用 URL 来实现 URN 功能的一个例子。

参数

参数 URL http://www.joes-hardware.com/hammers;sale=false/index.html;graphics=true
查询字符串 URL http://www.joes-hardware.com/inventory-check.cgi?item=12731&color=blue 主要是中间的分隔符，和前边的分隔符不一样
片段 http://www.joes-hardware.com/tools.html#drills
url不安全字符需要进行转译

常见方案格式

http

HTTP 使用术语流入(inbound)和流出(outbound)来描述事务处理(transaction) 的方向

这是请求报文的格式:
<method> <request-URL> <version> <headers>
<entity-body>
这是响应报文的格式(注意，只有起始行的语法有所不同):
<version> <status> <reason-phrase> <headers>
<entity-body>

http 方法

GET 是最常用的方法。通常用于请求服务器发送某个资源。
PUT 与 GET 从服务器读取文档相反，PUT 方法会向服务器写入文档。有些发布系统允许用户创建 Web 页面，并用 PUT 直接将其安装到 Web 服务器上去
HEAD 方法与 GET 方法的行为很类似，但服务器在响应中只返回首部。不会返回实体的主体部分。这就允许客户端在未获取实际资源的情况下，对资源的首部进行检查。使用 HEAD，可以: 1 在不获取资源的情况下了解资源的情况(比如，判断其类型); 2 通过查看响应中的状态码，看看某个对象是否存在; 3 通过查看首部，测试资源是否被修改了。
POST 方法起初是用来向服务器输入数据的 3。实际上，通常会用它来支持 HTML 的表单。表单中填好的数据通常会被送给服务器，然后由服务器将其发送到它要去的地方(比如，送到一个服务器网关程序中，然后由这个程序对其进行处理)。
TRACE 客户端发起一个请求时，这个请求可能要穿过防火墙、代理、网关或其他一些应用程序。每个中间节点都可能会修改原始的 HTTP 请求。TRACE 方法允许客户端在最终将请求发送给服务器时，看看它变成了什么样子。 TRACE 请求会在目的服务器端发起一个“环回”诊断。行程最后一站的服务器会弹回一条 TRACE 响应，并在响应主体中携带它收到的原始请求报文。这样客户端就可以查看在所有中间 HTTP 应用程序组成的请求 / 响应链上，原始报文是否，以及如何被毁坏或修改过
OPTIONS OPTIONS 方法请求 Web 服务器告知其支持的各种功能。可以询问服务器通常支持哪些方法，或者对某些特殊资源支持哪些方法。(有些服务器可能只支持对一些特殊类型的对象使用特定的操作)。这为客户端应用程序提供了一种手段，使其不用实际访问那些资源就能判定访问各种资源的最优方式。
DELETE 顾名思义，DELETE 方法所做的事情就是请服务器删除请求 URL 所指定的资源。但是，客户端应用程序无法保证删除操作一定会被执行。因为 HTTP 规范允许服务器在不通知客户端的情况下撤销请求。
拓展 HTTP 被设计成字段可扩展的，这样新的特性就不会使老的软件失效了。扩展方法指的就是没有在 HTTP/1.1 规范中定义的方法。服务器会为它所管理的资源实现一些 HTTP 服务，这些方法为开发者提供了一种扩展这些 HTTP 服务能力的手段。表 3-5 列出了一些常见的扩展方法实例。这些方法就是 WebDAV HTTP 扩展(参见第 19 章)包含的所有方法，这些方法有助于通过 HTTP 将 Web 内容发布到 Web 服务器上去。

状态码

首部

TCP连接

世界上几乎所有的 HTTP 通信都是由 TCP/IP 承载的，TCP/IP 是全球计算机及网络设备都在使用的一种常用的分组交换网络分层协议集。客户端应用程序可以打开一条 TCP/IP 连接，连接到可能运行在世界任何地方的服务器应用程序。一旦连接建立起来了，在客户端和服务器的计算机之间交换的报文就永远不会丢失、受损或失序

HTTP 连接实际上就是 TCP 连接及其使用规则。TCP 连接是因特网上的可靠连接。要想正确、快速地发送数据，就需要了解 TCP 的一些基本知识。

HTTP 紧挨着 TCP，位于其上层，所以 HTTP 事务的性能在很大程度上取决于底层 TCP 通道的性能。

HTTP 事务的时延有以下几种主要原因。 (1) 客户端首先需要根据 URI 确定 Web 服务器的 IP 地址和端口号。如果最近没有对 URI 中的主机名进行访问，通过 DNS 解析系统将 URI 中的主机名转换成一个 IP 地址可能要花费数十秒的时间 3。 (2) 接下来，客户端会向服务器发送一条 TCP 连接请求，并等待服务器回送一个请求接受应答。每条新的 TCP 连接都会有连接建立时延。这个值通常最多只有一两秒钟，但如果有数百个 HTTP 事务的话，这个值会快速地叠加上去。 (3) 一旦连接建立起来了，客户端就会通过新建立的 TCP 管道来发送 HTTP 请求。数据到达时，Web 服务器会从 TCP 连接中读取请求报文，并对请求进行处理。因特网传输请求报文，以及服务器处理请求报文都需要时间。 (4) 然后，Web 服务器会回送 HTTP 响应，这也需要花费时间。这些 TCP 网络时延的大小取决于硬件速度、网络和服务器的负载，请求和响应报文的尺寸，以及客户端和服务器之间的距离。TCP 协议的技术复杂性也会对时延产生巨大的影响。

性能聚焦区域

• TCP 连接建立握手; • TCP 慢启动拥塞控制; • 数据聚集的 Nagle 算法; • 用于捎带确认的 TCP 延迟确认算法; • TIME_W AIT 时延和端口耗尽

Keep-Alive连接的限制和规则

通用软件Web服务器

通用软件 Web 服务器都运行在标准的、有网络功能的计算机系统上。可以选择开源软件(比如 Apache 或 W3C 的 Jigsaw)或者商业软件(比如微软和 iPlanet 的 Web 服务器)。基本上所有的计算机和操作系统中都有可用的 Web 服务器软件。尽管不同类型的 Web 服务器程序有数万个(包括定制的和特殊用途的 Web 服务器)，但大多数 Web 服务器软件都来自少数几个组织。 • 免费的 Apache 软件占据了所有因特网 Web 服务器中大约 60% 的市场。 • 微软的 W eb 服务器占据了另外 30%。 • Sun 的 iPlanet 占据了另外 3%。

Web服务器设备

Web 服务器设备(Web server appliance)是预先打包好的软硬件解决方案。厂商会在他们选择的计算机平台上预先安装好软件服务器，并将软件配置好。下面是一些 Web 服务器设备的例子: • Sun/Cobalt RaQ Web 设备(http://www.cobalt.com); • 东芝的 Magnia SG10(http://www.toshiba.com);

嵌入式Web服务器嵌入式服务器(embeded server)是要嵌入到消费类产品(比如打印机或家用设备) 中去的小型 Web 服务器。嵌入式 Web 服务器允许用户通过便捷的 Web 浏览器接口来管理其消费者设备。有些嵌入式 Web 服务器甚至可以在小于一平方英寸的空间内实现，但通常只能提供最小特性功能集。下面是两种非常小的嵌入式 Web 服务器实例: • IPic 火柴头大小的 Web 服务器(http://www-ccs.cs.umass.edu/~shri/iPic.html); • NetMedia SitePlayer SP1 以太网 Web 服务器(http://www.siteplayer.com)。

最小的Perl Web服务器要构建一个特性完备的 HTTP 服务器，是需要做一些工作的。Apache Web 服务器的内核有超过 50 000 行的代码，那些可选处理模块的代码量更是远远超过这个数字。

连接的输入/输出处理结构

高性能的 Web 服务器能够同时支持数千条连接。这些连接使得服务器可以与世界各地的客户端进行通信，每个客户端都向服务器打开了一条或多条连接。某些连接可能在快速地向 Web 服务器发送请求，而其他一些连接则可能在慢慢发送，或者不经常发送请求，还有一些可能是空闲的，安静地等待着将来可能出现的动作。因为请求可能会在任意时刻到达，所以 Web 服务器会不停地观察有无新的 Web 请求。不同的 Web 服务器结构会以不同的方式为请求服务，如图 5-7 所示。 • 单线程 Web 服务器(参见图 5-7a) 单线程的 Web 服务器一次只处理一个请求，直到其完成为止。一个事务处理结束之后，才去处理下一条连接。这种结构易于实现，但在处理过程中，所有其他连接都会被忽略。这样会造成严重的性能问题，只适用于低负荷的服务器，以及 type-o-serve 这样的诊断工具。 • 多进程及多线程 Web 服务器(参见图 5-7b) 多进程和多线程 Web 服务器用多个进程，或更高效的线程同时对请求进行处理。5 可以根据需要创建，或者预先创建一些线程 / 进程。6 有些服务器会为每条连接分配一个线程 / 进程，但当服务器同时要处理成百、上千，甚至数以万计的连接时，需要的进程或线程数量可能会消耗太多的内存或系统资源。因此，很多多线程 Web 服务器都会对线程 / 进程的最大数量进行限制。 • 复用 I/O 的服务器(参见图 5-7c) 为了支持大量的连接，很多 Web 服务器都采用了复用结构。在复用结构中，要同时监视所有连接上的活动。当连接的状态发生变化时(比如，有数据可用，或出现错误时)，就对那条连接进行少量的处理;处理结束之后，将连接返回到开放连接列表中，等待下一次状态变化。只有在有事情可做时才会对连接进行处理;在空闲连接上等待的时候并不会绑定线程和进程。 • 复用的多线程 Web 服务器(参见图 5-7d) 有些系统会将多线程和复用功能结合在一起，以利用计算机平台上的多个 CPU。多个线程(通常是一个物理处理器)中的每一个都在观察打开的连接(或打开的连接中的一个子集)，并对每条连接执行少量的任务。

目录列表

Web 服务器可以接收对目录 URL 的请求，其路径可以解析为一个目录，而不是文件。我们可以对大多数 Web 服务器进行配置，使其在客户端请求目录 URL 时采取不同的动作。 • 返回一个错误。 • 不返回目录，返回一个特殊的默认“索引文件”。 • 扫描目录，返回一个包含目录内容的 HTML 页面。大多数 Web 服务器都会去查找目录中一个名为 index.html 或 index.htm 的文件来代表此目录。如果用户请求的是一个目录的 URL，而且这个目录中有一个名为 index. html(或 index.htm)的文件，服务器就会返回那个文件的内容。

代理服务器的部署

• 出口代理可以将代理固定在本地网络的出口点，以便控制本地网络与大型因特网之间的流量。可以在公司网络中使用出口代理(参见图 6-11a)，提供针对公司外部恶意黑客的防火墙保护，或降低带宽费用，提高因特网流量的性能。小学可能会使用过滤出口代理来防止早熟的学生浏览不恰当的内容。 • 访问(入口)代理代理常被放在 ISP 访问点上，用以处理来自客户的聚合请求。ISP 使用缓存代理来存储常用文档的副本，以提高用户(尤其是高速连接用户)的下载速度，降低因特网带宽耗费(参见图 6-11b)。 • 反向代理代理通常会被部署在网络边缘，在 Web 服务器之前，作为替代物(也常被称为反向代理，参见图 6-11c)使用，在那里它们可以处理所有传送给 Web 服务器的请求，并只在必要时向 Web 服务器请求资源。替代物可以提高 Web 服务器的安全特性，或者将快速的 Web 服务器缓存放在较慢的服务器之前，以提高性能。反向代理通常会直接冒用 Web 服务器的名字和 IP 地址，这样所有的请求就会被发送给代理而不是服务器了。 • 网络交换代理可以将具有足够处理能力的代理放在网络之间的因特网对等交换点上，通过缓存来减轻因特网节点的拥塞，并对流量进行监视，参见图 6-11d。

客户端的代理配置:手工配置很多 Web 客户端都允许用户手工配置代理。网景的 Navigator 和微软的 Internet Explorer 都为代理配置提供了便捷的支持。在网景的 Navigator 6 中，可以通过菜单选项 Edit(编辑)→ Preferences(首选项)→ Advanced(高级)→ Proxies(代理)，然后选中单选按钮“Manual proxy”(手工配置代理)来指定代理。在微软的 Internet Explorer 5 中，可以在 Tools(工具)→ Internet Options(Internet 选项)菜单中，选择一个连接，点击“Settings”(设置)，选中“Use a proxy s e r v e r ”( 使用代理服务器 ) 框，并点击 “ A d v a n c e d ”( 高级 )，来手工指定代理。其他浏览器都有不同的方式来进行手工配置的修改，但其思想是一样的:为代理指定主机和端口。有些 ISP 会向客户发送预先配置好的浏览器，或定制好的操作系统，使其将 Web 流量重定向到代理服务器上。

客户端代理配置:P AC文件手工代理配置很简单但有些死板。只能为所有内容指定唯一的一个代理服务器，而且不支持故障转移。手工代理配置还会给大型组织带来管理问题。如果配置过的浏览器基数很大，那么需要进行修改的时候，重新配置每个浏览器是非常困难，甚至是不可能的。 PAC 文件是一些小型的 JavaScript 程序，可以在运行过程中计算代理设置，因此，是一种更动态的代理配置解决方案。访问每个文档时，JavaScript 函数都会选择恰当的代理服务器。要使用 PAC 文件，就要用 JavaScript PAC 文件的 URI 来配置浏览器[配置方式与手工配置类似，但要在“automatic configuration”(自动配置)框中提供一个 URI]。浏览器会从这个 URI 上获取 PAC 文件，并用 JavaScript 逻辑为每次访问计算恰当的代理服务器。PAC 文件的后缀通常是 .pac，MIME 类型通常是 application/x-ns- proxy-autoconfig。每个 P AC 文件都必须定义一个名为 FindProxyForURL(url,host) 的函数，用来计算访问 URI 时使用的适当的代理服务器。函数的返回值可以是表 6-1 列出的任意值。

Web Caching(《Web 缓存》19)

• 缓存减少了冗余的数据传输，节省了你的网络费用。 • 缓存缓解了网络瓶颈的问题。不需要更多的带宽就能够更快地加载页面。 • 缓存降低了对原始服务器的要求。服务器可以更快地响应，避免过载的出现。 • 缓存降低了距离时延，因为从较远的地方加载页面会更慢一些。

命中和未命中的

这样看来缓存是有所帮助的。但缓存无法保存世界上每份文档的副本。3 可以用已有的副本为某些到达缓存的请求提供服务。这被称为缓存命中(cache hit)，参见图 7-4a。其他一些到达缓存的请求可能会由于没有副本可用，而被转发给原始服务器。这被称为缓存未命中(cache miss)，参见图 7-4b。

缓存的处理步骤

(1) 接收——缓存从网络中读取抵达的请求报文。 (2) 解析——缓存对报文进行解析，提取出 URL 和各种首部。 (3) 查询——缓存查看是否有本地副本可用，如果没有，就获取一份副本(并将其保存在本地)。 (4) 新鲜度检测——缓存查看已缓存副本是否足够新鲜，如果不是，就询问服务器是否有任何更新。 (5) 创建响应——缓存会用新的首部和已缓存的主体来构建一条响应报文。 (6) 发送——缓存通过网络将响应发回给客户端。 (7) 日志——缓存可选地创建一个日志文件条目来描述这个事务。

网关 HTTP 扩展和接口的发展是由用户需求驱动的。要在 Web 上发布更复杂资源的需求出现时，人们很快就明确了一点:单个应用程序无法处理所有这些能想到的资源。为了解决这个问题，开发者提出了网关(gateway)的概念，网关可以作为某种翻译器使用，它抽象出了一种能够到达资源的方法。网关是资源和应用程序之间的粘合剂。应用程序可以(通过 HTTP 或其他已定义的接口)请求网关来处理某条请求，网关可以提供一条响应。网关可以向数据库发送查询语句，或者生成动态的内容，就像一个门一样:进去一条请求，出来一个响应。图 8-1 显示的是一种资源网关。在这里，Joe 的五金商店服务器就是作为连接数据库内容的网关使用的——注意，客户端只是在通过 HTTP 请求资源，而 Joe 的五金商店的服务器在与网关进行交互以获取资源。有些网关会自动将 HTTP 流量转换为其他协议，这样 HTTP 客户端无需了解其他协议，就可以与其他应用程序进行交互了(参见图 8-2)。

• http://www.robotstxt.org/wc/robots.html Web 机器人页面——机器人开发者所需的资源，包括因特网机器人的登记注册。 • http://www.searchengineworld.com 搜索引擎世界——搜索引擎和机器人的相关资源。 • http://www.searchtools.com Web 站点和内部网络的搜索工具——搜索工具和机器人的相关资源。 • http://search.cpan.org/doc/IL Y AZ/perl_ste/WWW/RobotRules.pm RobotRules 的 Perl 语言资源。 • http://www.conman.org/people/spc/robots2.html 拒绝机器人访问的扩展标准。 • Managing Gigabytes: Compressing and Indexing Documents and Images(《海量数据管理——文档和图像的压缩与索引》) Witten, I.、Moffat, A. 和 Bell, T. 编写，Morgan Kaufmann 公司出版。