《HTTP 权威指南》读书笔记：第四章-连接管理

1. TCP 连接

• 四元组：源IP、源端口、目的IP、目的端口
• 浏览器与web服务器交互流程：
  1. 浏览器从url中解析主机名
  2. 查询主机名的IP地址（DNS）
  3. 浏览器从url中获取端口号
  4. 浏览器对服务器IP发起TCP连接
  5. 浏览器向服务器发送一条http请求报文
  6. 浏览器读取服务器的http响应报文
  7. 浏览器关闭tcp连接
• tcp的特性，即tcp握手后双方保持的连接数据：
  1. 端口：标识连接双方
  2. 数据包序号（seq）：用于保证不重不漏不乱序
  3. 窗口尺寸：用于流控
• http（over tsl）over tcp
• tcp基于ip分组（或ip数据报）的小块数据来发送。
• 每个tcp数据包包括：
  1. ip分组首部（20 byte）
  2. tcp段首部（20 byte）
  3. 内容数据

2. TCP性能

HTTP事务时延：

1. DNS解析
2. 建立tcp连接
3. 客户端发送http请求，服务器读取并处理请求
4. 服务器回送响应

1. TCP握手：

1. client 向 server 发送ctl=syn和seq=client-seq
2. s 回复 ctl=syn+ack、ack=client-seq+1 和 seq=server-seq
3. s向c确认ctl=ack、ack=server-seq+1

2. 延迟确认

• 每个tcp段都有一个序列号和数据完整性校验和。每个段接收者收到完好的段时，都会回送小的确认分组。如果发送者没有在指定的时间窗口内收到确认信息，就认为分组已被破坏或者损毁，并重发数据。
• 由于确认报文很小，所以tcp允许在发往相同方向的输出数据分组中对其进行“捎带”，即将返回的确认信息与输出的数据分组结合在一起，可以有效利用网络。
• “延迟确认”算法在一个特定的时间窗口（100~200ms）内将确认信息放在缓冲区中以等待能够捎带它的输出数据分组。如果超时就在单独的分组中传送。

3. TCP 慢启动

• 连接建立后，起初会限制连接的最大速度，如果数据成功传输，会随着时间的推移提高传输的速度。这种调谐称为TCP慢启动，用于防止因特网的突然过载和拥塞。
• 慢启动限制可以传输的分组数，可以发送的分组数指数增加，称为“打开拥塞窗口”
• 因此新建连接的传输速度比“已调谐”连接慢。

3. HTTP 连接的处理

Http 的 Connection 首部字段有一个由逗号分隔的连接标签列表，比如 Connection:close 说明发送完下一条报文后必须关闭连接。

串行事务处理时延

• 每个事务都要新建一条tcp连接，连接时延和慢启动时延会累加。
• 加载一副图片时页面其他部分没动静

4. 并行连接

HTTP客户端打开多条tcp连接，并行处理http事务，每个事务都有自己的tcp连接。

• 可以重叠部分时延
• 带宽不足的话没意义
• 多建立连接会额外产生一些开销
• 服务器负载增大，一般限制一个客户端并行连接不超过4个
• 同时刷多个图片使用户体验感觉更快

5. 持久连接

• 需求场景：站点局部性（site locality）
• http/1.1 和 http/1.0的各种增强版本
• 定义：在事务处理结束后仍然保持在打开状态的tcp连接
• 避免建立连接的时延，和慢启动的拥塞适应阶段
• 管理持久连接要特别小心，不然就会累积大量的空闲连接，耗费客户端和服务器的资源
• 现在，很多web应用程序会打开少量的并行连接，其中每个都是持久连接。
• HTTP/1.1 persistent HTTP/1.0+keep-alive

http/1.0+keep alive

• http/1.0的扩展
• 长连接握手过程：客户端通过包含 Connection: Keep-Alive 首部请求一条连接保持在打开状态，如果服务器愿意为下一条请求将连接保持在打开状态，就在响应中包含相同的首部。
• 承诺但不保证，随时可以关闭空闲的连接
• timeout是在响应首部发送的，它估计了服务器希望保持长连接的时间，max估计了服务器希望为多少个事务保持长连接。

限制

• http/1.0中ka不是默认的
• 每个报文都要包含ka首部，否则服务器会在那条请求后关闭连接
• Content-Length必须正确或是用分块传输编码方式编码
• 哑代理：代理服务器不能转发的首部：Connection、Proxy-Ahtuenticate、Proxy-Connection、Transfer-Encoding

http/1.1 持久连接

• http/1.1默认持久连接，要在报文中显示添加Connection:close才能在事务处理结束之后关闭连接。
• 承诺但不保证，随时可以关闭连接

限制

• 发送Connection:close首部后客户端就不能在这条tcp连接上发送更多的请求了
• Content-Length必须正确或是用分块传输编码方式编码
• HTTP/1.1的代理必须分别管理与客户端和服务器的持久连接——每个持久连接都只适用于一跳传输
• HTTP/1.1设备可以在任意时刻关闭连接
• 一个客户端对任何服务器或代理最多只能维持两条持久连接，以防止服务器过载

6. 管道化连接

• HTTP/1.1允许在持久连接上可选地使用请求管道
• 在请求1的响应到达之前，发送请求2、3、…
• 如果客户端无法确认连接是持久的，就不应使用管道
• 必须按照与请求相同的顺序回送响应。http报文没有序列号标签
• 客户端必须做好连接随时关闭的准备，重发请求
• 非幂等的请求不应该用管道化方式发送

队头阻塞

• 后续响应先于队头请求的响应到达，为了保持顺序，要把他们缓存起来等待队头响应，队头响应延迟了，后续响应都会被延迟
• tcp队头阻塞，要想避免就不能用tcp，google的quic协议基于udp
• http队头阻塞，要想避免就用http2

7. 关闭连接

• s和c都可以在任意时刻关闭一条tcp连接，通常在一条报文结束时但出错时也可能在中间
• 每条HTTP响应都应该有精确的Content-Length首部，没有或者错误的话就要以服务器发出的连接关闭来说明数据的真实末尾
• 客户端收到一条随连接关闭而结束的http响应，且实际传输的实体长度与Content-Length不等时，就应该质疑长度的正确性
• 客户端做好连接随时被关闭的准备，重建连接重复发送请求
• 管道化只发送幂等的请求（get,put,head,delete,trace,options），大多数浏览器重载post请求前都会提示用户
• tcp可以全关闭——close()，也可以半关闭——shutdown()
• 关闭输出信道总是安全的，关闭输入信道比较危险。如果对端向你已关闭的信道发送数据，操作系统对象对端机器回送一条“连接被对端重置”的报文，这条报文通常被作为严重错误处理，清空缓存，如果有操作系统缓存的未被应用程序读取的响应，就都丢失了。
• 关闭流程：双方先关闭输出信道，周期性检查输入信道的状态，如果在一定时间内对端没关闭输入信道，应用程序强制关闭连接。