HTTP连接管理

逃离我推掉我的手 2022-09-22 11:44 138阅读 0赞

整理自《HTTP权威指南》及网络

# TCP 连接 #

大多数HTTP报文是基于TCP连接的。  
假设我们有Web服务器www.windeal.com， 该服务器端口号为80， 有资源index.html。 我们可以通过URLwww.windeal.com:80/index.html 访问该资源。  
此时，Web浏览器和Web服务器进行一下动作：  
1. 从URL中解析出 主机名`www.windeal.com` ， 端口号`80`， 资源URL`index.html`  
2. 通过DNS域名解析，将`www.windeal.com` 解析为IP地址。  
3. 根据服务器IP地址和端口号与服务器建立TCP连接  
4. 浏览器想Web服务器发送GET请求。  
5. Web服务器根据请求的URL，回复响应报文  
6. 关闭TCP连接。

关于TCP连接的细节，此处不做讨论， 我们主要关系HTTP协议栈。

**HTTPS协议**是进行了加密了HTTP协议，在HTTP层和TCP层之间增加了**安全层 TSL/SSL**

# 对TCP性能的考虑 #

一个Web浏览器的忧虑不仅在于其功能的强大与否， 也在于其性能。  
由于HTTP事务的大部分工作都在TCP连接中实现，因此HTTP事务的性能主要取决于其所依赖的TCP连接的性能。  
前面我们已经了解了一次HTTP通信的主要步骤： **DNS解析、TCP连接、HTTP请求、请求处理、HTTP响应、关闭连接**。 这里，我们不考虑关闭连接导致的时延（因为既然要关闭了，考虑时延意义不大）；其他几个步骤都会导致HTTP事务的时延。  
\+ **DNS解析：** 在没有缓存的情况下，将一个URI中共的主机名转换为IP地址可能需要几十秒的时间。  
\+ **TCP连接：** TCP连接的三次握手会花费一定的时间。  
\+ **HTTP请求：** Web客户端（浏览器）发送HTTP请求到Web服务器收到并读取请求报文都需要话费一定时间。  
\+ **请求处理：** Web服务器处理接收到的HTTP请求报文需要话费一定时间  
\+ **HTTP响应：** Web服务器发送HTTP响应报文也需要时间。  
以上网络时间取决于多种因素： 硬件设施、网络和服务器负载、报文尺寸等等。

## 缩小HTTP事务时延 ##

### 缩小TCP连接的握手时延： ###

建立一条TCP连接、TCP连接在发送任何数据，都需要交换一些IP分组进行参数的沟通。 进行IP分组交换是需要话费时间的，因此我们应该尽量减少IP分组的交换。也就是说，TCP连接不应该值传送少量的数据，而应该一次传送更多的数据，以减少IP分组交换的次数，进而缩小握手时延。  
下面是两个充分利用TCP连接一次传送更多数据的例子：  
1. 将HTTP请求报文包含在TCP三次握手的ACK报文中。  
2. 将HTTP响应报文尽可能放在一个IP分组中去。

### TCP的慢启动 ###

TCP连接在启动初期会自动调节数据的传输速度。从一个比较慢的速度开始传输数据，如果成功则慢慢提升传输速度，直到调整到一个合适的速度。  
TCP的慢启动可以防止网络过载和阻塞。

### Nagle算法与TCP\_NODELAY ###

每个TCP段至少装载40bytes的首部，如果TCP负载的大小相对于TCP整个报文的大小占比越小说明这个TCP段的利用率越低。为提升HTTP事务的性能，应提升TCP段的利用率。  
**Nagle算法**鼓励发送全尺寸（LAN上大约是1500bytes， 因特网上只是为512Bytes）的段。Nagle需要在其他（全尺寸的分组都被确认之后才允许发送最后剩下的非全尺寸的分组）  
Nagle算法会引发一些问题： 一些小的HTTP报文可能无法填满一个分组，需要等待一定时延。  
**TCP\_NODELAY：** 用于禁用Nagle算法，此时我们需要自己确保向TCP写入大块的数据。

### TIME\_WAIT和端口耗尽 ###

**TIME\_WAIT**用于防止端口重用，每个客户端连接到Web服务器时，都会获得一个源端口。 但禁止端口重用又会导致**端口耗尽**的问题。

# HTTP连接的处理 #

## Connection 首部 ##

一个从客户端到服务器的HTTP连接可能会经过一些中间设备， 相邻的中间设备的HTTP程序之间可能需要沟通一些选项，这些选项不需要传递到其他的设备上去。此时我们可以通过Connection首部字段中的标签列表来制定不传播到其他HTTP连接中去的选项。  
connection首部字段可以接收三种不同的标签：  
\+ **首部字段名：**列出只与本连接有关的首部字段。  
\+ **任意标签值：** 用于描述此连接的非标准选项  
\+ **close：** 操作完成后，关闭此连接。

## 串行事务处理时延 ##

串行处理HTTP事务可能会增加时延。  
如客户端请求一个带有多个嵌入式图片的页面，如果串行依次建立连接来获取这些对象则大大增加了网络时延。  
以下几种方法可以用于规避串行事务处理时延。  
\+ **并行连接：**通过多条TCP连接发起HTTP请求。  
\+ **持久连接：**重用TCP连接，以消除连接及关闭时延  
\+ **管道化连接：**通过共享的TCP连接发起并发的HTTP请求。

## 并行连接 ##

HTTP允许客户打开多条连接，并行地执行多个HTTP事务。  
并行连接能够克服单挑连接的空载时间 和 带宽限制，从而提高网络加载速度。  
**并行连接并不总是更快：** 当（Modem）的网络带宽较小（单条连接已经满负荷运行）时、建立多条连接可能会增加连接之间的资源竞争，增加内存消耗，这样反而会增加HTTP事务时延。  
**并行连接一般能让人感觉更快一下**

## 持久连接 ##

并行连接有以下缺点：  
\+ 每个事务都打开、关闭一条新的连接， 这回消耗时间和带宽。  
\+ 由于TCP慢启动的特性，每条新连接的性能都会有所降低  
\+ 可以打开i的并行连接数量是有限的。  
为解决这些问题，持久连接出现了。  
HTTP/1.0 开始尝试支持持久连接**keep-alive**，持久连接在HTTP/1.1初始版本中修正了一些问题。  
**keep-alive在最新HTTP/1.1规范中已经被删除了，不应在使用。 但因为它已经被广泛应用与各种浏览器和服务器，因此在设计HTTP程序时，还是应该尽可能对其兼容。**  
实现HTTP/1.0 keep-alive连接的客户端可以通过包含`Connection: Keep-alive`首部请求将一条连接保持在打开状态。然而HTTP连接的另一端不一定会同意进行keep-alive会话，它们可能在任意时刻关闭空闲的keep-alive。 可以用`keep-alive`首部中\*指定的、有逗号分隔的选项）来调节keep-alive的行为，因而我们可以看到如下首部：

Connection: Keep-Alive
    Keep-Alive: max=5, timeout=120;

max表示希望为多少个事务保持连接的活跃状态，timeout表示希望将此连接保持活跃状态的时间。

## 管道化连接 ##

HTTP/1.1允许在持久连接上可选第使用请求管道，对keep-alive连接进一步优化。在响应到达之前，可以煎更多条请求放入队列，当第一条请求通过网络流向服务器时，第二条和第三条请求也开始发送。