HTTP学习（二） HTTP连接、代理、缓存

HTTP作为现在非常重要的协议，需要仔细梳理一下。本次学习知识点来自于《HTTP权威指南》，只是文中知识点罗列，算是读书笔记，请有兴趣的读者购买《HTTP权威指南》完整阅读。

一、HTTP连接

1、TCP连接

世界上几乎所有的 HTTP 通信都是由 TCP/IP 承载的， TCP/IP 是全球计算机及网络设备都在使用的一种常用的分组交换网络分层协议集。 

其安全版本 HTTPS 就是在 HTTP 和 TCP 之间插入了一个（称为 TLS 或 SSL的） 密码加密层 

每个 TCP 段都是由 IP 分组承载， 从一个 IP 地址发送到另一个 IP 地址的。 每个 IP分组中都包括：
• 一个 IP 分组首部（通常为 20 字节） ；
• 一个 TCP 段首部（通常为 20 字节） ；
• 一个 TCP 数据块（0 个或多个字节）。
IP 首部包含了源和目的 IP 地址、 长度和其他一些标记。 TCP 段的首部包含了 TCP端口号、 TCP 控制标记， 以及用于数据排序和完整性检查的一些数字值。
2、TCP段协议

3、TCP套接字编程

客户端与服务端的交互过程如下：

3、HTTP连接性能

HTTP连接的性能考察要从TCP连接上进行，主要考察如下几点：

• TCP 连接建立握手；
• TCP 慢启动拥塞控制；
• 数据聚集的 Nagle 算法；
• 用于捎带确认的 TCP 延迟确认算法；
• TIME_WAIT 时延和端口耗尽。
如果要编写高性能的 HTTP 软件， 就应该理解上面的每一个因素 

4、TCP慢启动

TCP 数据传输的性能还取决于 TCP 连接的使用期（age）。 TCP 连接会随着时间进行自我“调谐”， 起初会限制连接的最大速度， 如果数据成功传输， 会随着时间的推移提高传输的速度。 这种调谐被称为 TCP 慢启动（slow start）， 用于防止因特网的突然过载和拥塞。
TCP 慢启动限制了一个 TCP 端点在任意时刻可以传输的分组数。 简单来说， 每成功接收一个分组， 发送端就有了发送另外两个分组的权限。 如果某个 HTTP 事务有大量数据要发送， 是不能一次将所有分组都发送出去的。 必须发送一个分组， 等待确认； 然后可以发送两个分组， 每个分组都必须被确认， 这样就可以发送四个分组了，以此类推。 这种方式被称为“打开拥塞窗口”

5、Nagle算法与TCP_NODELAY
TCP 有一个数据流接口， 应用程序可以通过它将任意尺寸的数据放入 TCP 栈中——即使一次只放一个字节也可以！ 但是， 每个 TCP 段中都至少装载了 40 个字节的标记和首部， 所以如果 TCP 发送了大量包含少量数据的分组， 网络的性能就会严重下降。
Nagle 算法（根据其发明者 John Nagle 命名） 试图在发送一个分组之前， 将大量TCP 数据绑定在一起， 以提高网络效率。
6、TIME_WAIT累积与端口耗尽
TIME_WAIT 端口耗尽是很严重的性能问题， 会影响到性能基准， 但在现实中相对较少出现。 大多数遇到性能基准问题的人最终都会碰到这个问题， 而且性能都会变得出乎意料地差， 所以这个问题值得特别关注。
当某个 TCP 端点关闭 TCP 连接时， 会在内存中维护一个小的控制块， 用来记录最近所关闭连接的 IP 地址和端口号。 这类信息只会维持一小段时间， 通常是所估计的最大分段使用期的两倍（称为 2MSL， 通常为 2 分钟 8） 左右， 以确保在这段时间内不会创建具有相同地址和端口号的新连接。 实际上， 这个算法可以防止在两分钟内创建、 关闭并重新创建两个具有相同 IP 地址和端口号的连接。 用 TIME_WAIT 防止端口号重用时， 这些
情况也限制了可用的连接值组合。 客户端每次连接到服务器上去时， 都会获得一个新的源端口， 以实现连接的唯一性。但由于可用源端口的数量有限（比如， 60 000 个）， 而且在 2MSL 秒（比如， 120秒） 内连接是无法重用的， 连接率就被限制在了 60 000/120=500 次 / 秒。 如果再不断进行优化， 并且服务器的连接率不高于 500 次 / 秒， 就可确保不会遇到 TIME_WAIT 端口耗尽问题。
7、串行事务处理时延


• 并行连接
通过多条 TCP 连接发起并发的 HTTP 请求。
• 持久连接
重用 TCP 连接， 以消除连接及关闭时延。
• 管道化连接
通过共享的 TCP 连接发起并发的 HTTP 请求。
• 复用的连接
交替传送请求和响应报文（实验阶段）。
8、持久连接

因此， 初始化了对某服务器 HTTP 请求的应用程序很可能会在不久的将来对那台服务器发起更多的请求（比如， 获取在线图片）。 这种性质被称为站点局部性（site locality）。因此， HTTP/1.1（以及 HTTP/1.0 的各种增强版本） 允许 HTTP 设备在事务处理结束之后将 TCP 连接保持在打开状态， 以便为未来的 HTTP 请求重用现存的连接。 在事务处理结束之后仍然保持在打开状态的 TCP 连接被称为持久连接。 非持久连接会在每个事务结束之后关闭。 持久连接会在不同事务之间保持打开状态， 直到客户端或服务器决定将其关闭为止。 

9、 HTTP/1.0+ keep-alive 连接

在串行连接上实现 4 个HTTP 事务的时间线与在一条持久连接上实现同样事务所需的时间线进行了比较。由于去除了进行连接和关闭连接的开销， 所以时间线有所缩减。
10、keep-alive 

实现 HTTP/1.0 keep-alive 连接的客户端可以通过包含 Connection: Keep-Alive首部请求将一条连接保持在打开状态。
如果服务器愿意为下一条请求将连接保持在打开状态， 就在响应中包含相同的首部（参见图 4-14）。 如果响应中没有 Connection: Keep-Alive 首部， 客户端就认为服务器不支持 keep-alive， 会在发回响应报文之后关闭连接。
11、HTTP/1.1持久连接

HTTP/1.1 逐渐停止了对 keep-alive 连接的支持， 用一种名为持久连接（persistentconnection） 的改进型设计取代了它。 持久连接的目的与 keep-alive 连接的目的相同， 但工作机制更优一些。与 HTTP/1.0+ 的 keep-alive 连接不同， HTTP/1.1 持久连接在默认情况下是激活的。 除非特别指明， 否则 HTTP/1.1 假定所有连接都是持久的。 要在事务处理结束之后将连接关闭， HTTP/1.1 应用程序必须向报文中显式地添加一个 Connection:
close 首部。 这是与以前的 HTTP 协议版本很重要的区别， 在以前的版本中， keepalive 连接要么是可选的， 要么根本就不支持。
HTTP/1.1 客户端假定在收到响应后， 除非响应中包含了 Connection: close 首部， 不然 HTTP/1.1 连接就仍维持在打开状态。 但是， 客户端和服务器仍然可以随时关闭空闲的连接。 不发送 Connection: close 并不意味着服务器承诺永远将连接保持在打开状态。

二、HTTP结构

1、web服务器

Web 服务器实现了 HTTP 和相关的 TCP 连接处理。 负责管理 Web 服务器提供的资源， 以及对 Web 服务器的配置、 控制及扩展方面的管理。Web 服务器逻辑实现了 HTTP 协议、 管理着 Web 资源， 并负责提供 Web 服务器的管理功能。 Web 服务器逻辑和操作系统共同负责管理 TCP 连接。 底层操作系统负责管理底层计算机系统的硬件细节， 并提供了 TCP/IP 网络支持、 负责装载 Web 资源的文件系统以及控制当前计算活动的进程管理功能

上图中的步骤如下：

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

2、报文的内部表示法

3、web连接的输入/输出结构

4、MIME类型

Web 服务器可以用文件的扩展名来说明 MIME 类型。 Web 服务器会为每个资源扫描一个包含了所有扩展名的 MIME 类型的文件， 以确定其 MIME 类型。  

三、代理

1、Web 缓存
代理缓存维护了常用文档的本地副本， 并将它们按需提供， 以减少缓慢且昂贵的因特网通信。 

2、反向代理

3、将WEB请求导向代理的方法

4、没有代理时URL的解析

5、有代理时URL的解析

四、缓存

1、缓冲处理

缓存可以在任意时刻， 以任意的频率对副本进行再验证。 但由于缓存中通常会包含数百万的文档， 而且网络带宽是很珍贵的， 所以大部分缓存只有在客户端发起请求， 并且副本旧得足以需要检测的时候， 才会对副本进行再验证。