http权威指南笔记

URL

1.Url语法通用格式

<scheme>://<user>:<password>@<host>:<port>/<path>;<params>?<query>#<frag>

方案 访问服务器以获取资源时要使用哪种协议 无
用户 某些方案访问资源时需要的用户名 匿名
密码 用户名后面可能要包含的密码， 中间由冒号（ :） 分隔 <E-mail 地址 >
主机 资源宿主服务器的主机名或点分 IP 地址 无
端口 资源宿主服务器正在监听的端口号。 很多方案都有默认端
口号（ HTTP 的默认端口号为 80）
每个方案特有
路径 服务器上资源的本地名， 由一个斜杠（ /） 将其与前面的
URL 组件分隔开来。 路径组件的语法是与服务器和方案有
关的（ 本章稍后会讲到 URL 路径可以分为若干个段， 每
段都可以有其特有的组件。）
无
参数 某些方案会用这个组件来指定输入参数。 参数为名 / 值对。
URL 中可以包含多个参数字段， 它们相互之间以及与路径
的其余部分之间用分号（ ;） 分隔
无
查询 某些方案会用这个组件传递参数以激活应用程序（ 比如数
据库、 公告板、 搜索引擎以及其他因特网网关）。 查询组
件的内容没有通用格式。 用字符“ ?” 将其与 URL 的其余
部分分隔开来
无
片段 一小片或一部分资源的名字。 引用对象时， 不会将 frag 字
段传送给服务器； 这个字段是在客户端内部使用的。 通过
字符“ #” 将其与 URL 的其余部分分隔开来 无

2.字符编码
原因：数据传输可能要通过不同的协议来传送资源，不同的协议在传输数据时可能使用不同的机制，比如传输电子邮件的简单邮件传输协议（ Simple Mail Transfer Protocol， SMTP）， 所使用的传输方法就会剥去一些特定的字符。 为了避开这些问题， URL 只能使用一些相对较小的、 通用的安全字母表中的字符。

3.字符限制：
在 URL 中， 有几个字符被保留起来， 有着特殊的含义。 有些字符不在定义的 USASCII 可打印字符集中。 还有些字符会与某些因特网网关和协议产生混淆， 因此不
赞成使用。

保留及受限字符：

% 保留作为编码字符的转义标志
/ 保留作为路径组件中分隔路径段的定界符
. 保留在路径组件中使用
.. 保留在路径组件中使用
# 保留作为分段定界符使用
? 保留作为查询字符串定界符使用
; 保留作为参数定界符使用
: 保留作为方案、 用户 / 口令， 以及主机 / 端口组件的定界符使用
$, + 保留
@ & = 在某些方案的上下文中有特殊的含义， 保留
{ } | \ ^ ~ [ ] ' 由于各种传输 Agent 代理， 比如各种网关的不安全处理， 使用受限
< > " 不安全； 这些字符在 URL 范围之外通常是有意义的， 比如在文档中对 URL 自身
进行定界（ 比如 http://www.joes-hardware.com）， 所以应该对其进行编码
0x00-0x1F, 0x7F 受限， 这些十六进制范围内的字符都在 US-ASCII 字符集的不可打印区间内
>0x7F 受限， 十六进制值在此范围内的字符都不在 US-ASCII 字符集的 7 比特范围内

---

http报文

1.报文的组成成分
起始行、首部块、主体。起始行和首部就是由行分隔的 ASCII 文本。 每行都以一个由两个字符组成的行终止序列作为结束， 其中包括一个回车符（ ASCII 码 13） 和一个换行符（ ASCII 码 10）。这个行终止序列可以写做 CRLF。 需要指出的是， 尽管 HTTP 规范中说明应该用CRLF 来表示行终止， 但稳健的应用程序也应该接受单个换行符作为行的终止。 有些老的， 或不完整的 HTTP 应用程序并不总是既发送回车符， 又发送换行符。

实体的主体或报文的主体（ 或者就称为主体） 是一个可选的数据块。 与起始行和首
部不同的是， 主体中可以包含文本或二进制数据， 也可以为空。

2.常用http方法
GET：从服务器获取一份文档,读取文档。
HEAD：只从服务器获取文档的首部。一般用于不获取资源而了解资源情况。
POST：向服务器发送需要处理的数据。
PUT：将请求的主体部分存储在服务器上。
TRACE：对可能经过代理服务器传送到服务器上去的报文进行追踪。
OPTIONS：决定可以在服务器上执行哪些方法。
DELETE：从服务器上删除一份文档。

安全方法：请求不会对服务器产生什么效果，比如GET、HEAD。

3.状态码
100~199：信息提示
200~299：成功
300~399：重定向
400~499：客户端错误
500~599：服务器错误

---

TCP连接管理

1.浏览器通过URL获取资源流程：
（1）.浏览器解析出主机
（2）.浏览器查询出主机的ip地址并获取端口号
（3）.浏览器向服务器发送http get请求
（4）.浏览器从服务器读取http响应报文
（5）.浏览器解关闭连接

2.TCP流是分段的、由ip分组发送
https也是比http多了个安全层（TSL or SSL）每个TCP分组都是由IP分组承载，由一个ip地址发送到另一个ip地址，每个ip分组包括：
• 一个 IP 分组首部（ 通常为 20 字节） ；
• 一个 TCP 段首部（ 通常为 20 字节） ；
• 一个 TCP 数据块（ 0 个或多个字节）。

3.TCP性能考虑
3.1.HTTP事务的时延
HTTP 事务的时延有以下几种主要原因。
(1) 客户端首先需要根据 URI 确定 Web 服务器的 IP 地址和端口号。 如果最近没有对
URI 中的主机名进行访问， 通过 DNS 解析系统将 URI 中的主机名转换成一个 IP
地址可能要花费数十秒的时间 3。
(2) 接下来， 客户端会向服务器发送一条 TCP 连接请求， 并等待服务器回送一个请
求接受应答。 每条新的 TCP 连接都会有连接建立时延。 这个值通常最多只有一
两秒钟， 但如果有数百个 HTTP 事务的话， 这个值会快速地叠加上去。
(3) 一旦连接建立起来了， 客户端就会通过新建立的 TCP 管道来发送 HTTP 请求。
数据到达时， Web 服务器会从 TCP 连接中读取请求报文， 并对请求进行处理。
(4) 然后， Web 服务器会回送 HTTP 响应， 这也需要花费时间。

这些 TCP 网络时延的大小取决于硬件速度、 网络和服务器的负载， 请求和响应报文
的尺寸， 以及客户端和服务器之间的距离。

3.2.TCP 相关时延:
• TCP 连接建立握手；
• TCP 慢启动拥塞控制；
• 数据聚集的 Nagle 算法；
• 用于捎带确认的 TCP 延迟确认算法；
• TIME_WAIT 时延和端口耗尽。

3.3.TCP连接的握手时延
3.4.TCP启动慢可以通过长连接优化
3.4.TIME_WAIT累积与端口耗尽

4.TCP连接处理

串行连接：性能时延可能会叠加。
并行连接：并发请求，不一定快，可能快，因为时延重叠了，可能慢因为多并发竞争抢资源堵塞了。
持久连接： 允许 HTTP 设备在事务处理结束之后将 TCP 连接保持在打开状态， 以便为未来的 HTTP 请求重用现存的连接，用于消除连接及关闭时延，比如HTTP/1.0+ keep-alive连接。注意Keep-Alive和哑代理的问题。
管道化连接：通过共享的 TCP 连接发起并发的 HTTP 请求。这是相对于 keep-alive 连接的又一性能优化。 在响应到达之前， 可以将多条请求放入队列。 当第一条请求通过网络流向地球另一端的服务器时， 第二条和第三条请求也可以开始发送了。 在高时延网
络条件下， 这样做可以降低网络的环回时间， 提高性能。

---

Web服务器

web服务器一般执行以下几项相同的任务。
(1) 建立连接——接受一个客户端连接， 或者如果不希望与这个客户端建立连接， 就
将其关闭。
一旦新连接建立起来并被接受， 服务器就会将新连接添加到其现存 Web 服务器连接列表中， 做好监视连
接上数据传输的准备。
(2) 接收请求——从网络中读取一条 HTTP 请求报文。
(3) 处理请求——对请求报文进行解释， 并采取行动。
(4) 访问资源——访问报文中指定的资源。
(5) 构建响应——创建带有正确首部的 HTTP 响应报文。
(6) 发送响应——将响应回送给客户端。
(7) 记录事务处理过程——将与已完成事务有关的内容记录在一个日志文件中。

接收请求:
连接的输入/输出处理结构主要有以下：
• 单线程 Web 服务器
单线程的 Web 服务器一次只处理一个请求， 直到其完成为止。 一个事务处理结
束之后， 才去处理下一条连接。 这种结构易于实现， 但在处理过程中， 所有其他
连接都会被忽略。 这样会造成严重的性能问题， 只适用于低负荷的服务器， 以及
type-o-serve 这样的诊断工具。
• 多进程及多线程 Web 服务器
多进程和多线程 Web 服务器用多个进程，或更高效的线程同时对请求进行处理。 5
可以根据需要创建， 或者预先创建一些线程 / 进程。 6 有些服务器会为每条连接
分配一个线程 / 进程， 但当服务器同时要处理成百、 上千， 甚至数以万计的连接
时， 需要的进程或线程数量可能会消耗太多的内存或系统资源。 因此， 很多多线
程 Web 服务器都会对线程 / 进程的最大数量进行限制。
• 复用 I/O 的服务器
为了支持大量的连接， 很多 Web 服务器都采用了复用结构。 在复用结构中， 要
同时监视所有连接上的活动。 当连接的状态发生变化时（ 比如， 有数据可用， 或
出现错误时）， 就对那条连接进行少量的处理； 处理结束之后， 将连接返回到开
放连接列表中， 等待下一次状态变化。 只有在有事情可做时才会对连接进行处
理； 在空闲连接上等待的时候并不会绑定线程和进程。
• 复用的多线程 Web 服务器
有些系统会将多线程和复用功能结合在一起， 以利用计算机平台上的多个 CPU。
多个线程（ 通常是一个物理处理器） 中的每一个都在观察打开的连接（ 或打开的
连接中的一个子集）， 并对每条连接执行少量的任务。

访问资源
Web 服务器支持各种不同类型的资源映射， 但最简单的资源映射形式就是用请求
URI 作为名字来访问 Web 服务器文件系统中的文件。 通常， Web 服务器的文件系
统中会有一个特殊的文件夹专门用于存放 Web 内容。 这个文件夹被称为文档的根目
录（ document root， 或 docroot）。 Web 服务器从请求报文中获取 URI， 并将其附加
在文档根目录的后面。

---

代理

1.代理与网关的对比

代理连接的是两个或多个使用相同协议的应用程序， 而网关连接的则是
两个或多个使用不同协议的端点。 网关扮演的是“ 协议转换器” 的角色， 即使客户
端和服务器使用的是不同的协议， 客户端也可以通过它完成与服务器之间的事务
处理。
2.代理的一些使用场景
• 儿童过滤器
• 文档访问控制
• 安全防火墙
• Web 缓存
• 反向代理
• 内容路由器，根据因特网流量状况以及内容类型将
请求导向特定的 Web 服务器。
• 转码器
• 匿名者
3.代理如何获取到流量
• 修改客户端
很多 Web 客户端， 包括网景和微软的浏览器， 都支持手工和自动的代理配置。
如果将客户端配置为使用代理服务器， 客户端就会将 HTTP 请求有意地直接发送
给代理， 而不是原始服务器。
• 修改网络
网络基础设施可以通过若干种技术手段， 在客户端不知道， 或没有参与的情况
下， 拦截网络流量并将其导入代理。 这种拦截通常都依赖于监视 HTTP 流量的交
换设备及路由设备， 在客户端毫不知情的情况下， 对其进行拦截， 并将流量导入
一个代理。
• 修改 DNS 的命名空间
放在 Web 服务器之前的代理服务器——替代物， 会直接假扮 Web 服务器的名
字和 IP 地址， 这样， 所有的请求就会发送给这些替代物， 而不是服务器了（ 参
见图 6-14c）。 要实现这一点， 可以手工编辑 DNS 名称列表， 或者用特殊的动态
DNS 服务器根据需要来确定适当的代理或服务器。 有时在安装过程中， 真实服
务器的 IP 地址和名称被修改了， 替代物得到的会是之前的地址和名称。
• 修改 Web 服务器
也可以将某些 Web 服务器配置为向客户端发送一条 HTTP 重定向命令（ 响应码
305）， 将客户端请求重定向到一个代理上去。 收到重定向命令后， 客户端会与代
理进行通信。
4.与代理请求有关的一些棘手问题
• 代理请求中的 URI 和服务器请求中的 URI 有何不同；
(1) 没有设置客户端使用代理时， 它会发送部分 URI。
(2) 设置客户端使用代理时， 它会发送完整 URI。
• 拦截和反向代理是如何将服务器主机信息隐藏起来的；
• 修改 URI 的规则；
• 代理是怎样影响浏览器的智能 URI 自动完成机制， 或主机名扩展特性的。