Boost HTTP Server在Chromium浏览器中交替出现300ms延迟的排查

成因分析 #

你的问题源于Boost Beast small示例的短连接强制关闭逻辑，与Chromium内核浏览器的TCP栈、连接池策略交互产生的延迟：

1. 强制短连接触发Delayed ACK：示例代码中res.keep_alive(false)会强制返回Connection: close头，每次请求后立即关闭TCP连接。Chromium的TCP栈在处理这种主动关闭的连接时，会触发**延迟确认（Delayed ACK）**机制——收到服务器的FIN包后，不会立即发送ACK，而是等待约300ms再发送，导致服务器端连接的半关闭状态延长。
2. 连接池复用失败叠加延迟：Chromium会尝试复用连接池中的旧连接，当发现旧连接已失效（因服务器强制关闭），才会发起新连接。这个“尝试复用-失败-重建连接”的过程，叠加Delayed ACK的300ms延迟，就表现为每隔一次请求出现初始连接延迟。Firefox的连接池管理和TCP策略不同，因此未触发该问题。

修复方案 #

方案1：启用HTTP长连接（推荐） #

通过支持Keep-Alive复用TCP连接，从根源上避免频繁创建连接的开销：

• 删除示例代码中强制关闭Keep-Alive的代码：

  // 移除这一行：res.keep_alive(false);
  

• 或者根据客户端请求的Connection头自动适配：

  res.keep_alive(req_.keep_alive());
  

修改后，客户端可以复用已有TCP连接，不再需要频繁建立新连接，自然消除延迟。

方案2：优化TCP Socket参数（适配短连接场景） #

如果必须使用短连接，通过调整TCP参数消除Delayed ACK的影响：

• 在服务器的Socket上启用TCP_NODELAY，禁用Nagle算法，确保数据包立即发送：
  在session的run()方法或构造函数中添加：

  beast::error_code ec;
  socket_.set_option(net::tcp::no_delay(true), ec);
  if (ec) {
      fail(ec, "set tcp no delay");
  }
  

• （可选）设置SO_LINGER选项，避免TIME_WAIT状态干扰新连接（需谨慎使用，可能导致未发送数据丢失）：

  socket_.set_option(net::socket_base::linger{true, 0}, ec);
  if (ec) {
      fail(ec, "set linger");
  }
  

内容的提问来源于stack exchange，提问作者Otto Lewis