Keep alive 分析

基本概念

从概念上讲，涉及两个层面：

• HTTP Keep-Alive（应用层）
• TCP Keepalive（传输层）。

虽然它们都叫 "Keep-Alive"，但工作方式和目的略有不同。在您遇到的场景中，两者共同作用来解决问题。

1. HTTP Keep-Alive (持久连接)

首先，我们谈谈在 IIS 中配置的 HTTP Keep-Alive。

HTTP Keep-Alive 在 HTTP 协议中，是以 HTTP 请求头 (Request Header) 或者响应头 (Response Header) 的形式出现的，由 HTTP 协议层处理。

目的: 它的主要目的是性能优化。在早期的 HTTP/1.0 中，浏览器每请求一个资源（如一个 HTML 文件、一张图片、一个 CSS 文件），都需要建立一个新的 TCP 连接。完成请求后，连接就关闭。建立 TCP 连接（需要三次握手）和关闭它（需要四次挥手）本身是有开销的。如果一个网页包含几十个资源，这种开銷会非常大，导致页面加载缓慢。

工作方式: HTTP Keep-Alive (在 HTTP/1.1 中成为默认行为，也称为持久连接 Persistent Connection) 允许多个连续的 HTTP 请求和响应重用同一个 TCP 连接。

1. 客户端（浏览器）向服务器发送第一个请求。
2. 服务器响应后，不立即关闭 TCP 连接，而是保持它打开一段时间，等待客户端的下一个请求。
3. 客户端可以直接在这个已建立的连接上发送第二个、第三个请求...
4. 这大大减少了重复建立连接的延迟和服务器资源消耗。

关键点: HTTP Keep-Alive 本身不会主动发送“保活”数据包。它只是一个约定，告诉服务器：“嘿，处理完这个请求后别挂断，我可能还有事找你。” 连接的“保活”实际上是由更底层的机制来处理的。

2. TCP Keepalive (真正的“保活”数据包)

现在我们来看看真正发送“保活”数据包的机制——TCP Keepalive。这是在操作系统内核的 TCP/IP 协议栈层面实现的。

目的: 它的主要目的是检测“僵死”连接并维持有效连接。想象一下，客户端和服务器建立了一个 TCP 连接，但之后客户端突然断电或网络断开。服务器不知道对方已经“死亡”，它的 TCP 连接会一直处于 ESTABLISHED (已建立) 状态，白白占用系统资源。TCP Keepalive 就是为了解决这个问题。

工作方式:

1. 空闲检测: 当一个 TCP 连接上没有任何数据传输（即处于空闲状态）达到一个特定的时间（在 Windows 上默认为 2 小时，这个值叫 KeepAliveTime）后，服务器的 TCP 协议栈会启动 Keepalive 探测。
2. 发送探测包: 服务器会向客户端发送一个特殊的 TCP 段（Segment），我们通常称之为“探测包”或“保活包”。这个数据包非常小，不包含任何应用层数据。它通常是一个 ACK 包，其序列号（Sequence Number）被设置为一个对方未确认的值。
3. 期望的响应:
   • 如果客户端网络正常: 客户端的 TCP 协议栈会识别出这是一个 Keepalive 探测，并立即回复一个 ACK 包。当服务器收到这个响应后，它就知道连接仍然是“活的”，然后重置其内部的空闲计时器，等待下一个 2 小时（或您设定的 KeepAliveTime）的空闲时间。
   • 如果客户端已崩溃或网络不通: 服务器发送的探测包将得不到任何响应。
4. 重试与断开: 在第一次探测失败后，服务器不会立即放弃。它会每隔一段时间（KeepAliveInterval，Windows 默认 1 秒）重试一次，直到达到最大重试次数（TcpMaxDataRetransmissions，Windows 默认 10 次）。如果所有重试都失败了，服务器就会判定该连接已“死亡”，并强制关闭它，释放相关资源。

它会真正在物理层面产生网络流量。

HTTP Keep-Alive

这里详细介绍如何配置 HTTP Keep Alive

配置参数

1. 打开 IIS, 找到需要配置 HTTP Keep-Alive 的站点 (site), 应用 (站点下面的 appliation) 或者目录 (directory)
2. 在中间的 Home 面板中，找到 HTTP Response Headers，双击打开它。
   
3. 在打开的 HTTP Response Headers 中，
   1. 鼠标右键，在弹出菜单中，选择 Set Common Headers...
   2. 或者，在最右边的 Action 菜单中，选择 Set Common Headers...
      
4. 在弹出的 Set Common HTTP Response Headers 对话框中，选择 Enable HTTP keep-alive，然后点击确认。
   注意，现在默认它应该就是选中的。
   

See:

• How to enable HTTP keep-alives for a Web site or application

TCP Keep-Alive

它涉及到 Winodws 如何检测网络另一端是否还在存活中 keep-alive ，名字看起来一样，作用并不相同。

这需要修改 Windows 注册表来完成，它涉及到 3 个注册表配置

• KeepAliveTime, 多长时间之后开始进行 Keep alive 检查, 默认 2 小时
• KeepAliveInterval, Keep alive 检查的间隔时间, 默认 1 秒
• TcpMaxDataRetransmissions, 最多重试次数，此参数默认值为 5

Windows Server 2008 和 Windows Vista 的 TCP/IP 协议的 TCP keepalive 功能默认处于禁用状态。
如果通过 Windows 套接字函数 setsockopt 启用此功能，则默认情况下会每两小时发送一次 keepalive 数据包，具体频率由注册表值 KeepAliveTime 控制。
即使启用了此功能，其他上层协议（例如 NetBIOS）也会发送自己的 keepalive 值。如果上层协议使用的 keepalive 间隔小于 TCP keepalive 间隔，则不会发送 TCP keepalive 值。例如，通过 TCP/IP 连接的 NetBIOS 会话每 60 分钟发送一次 NetBIOS keepalive 请求。因此，为 NetBIOS 会话启用的 TCP keepalive 值永远不会被使用。

此条目在本地组策略编辑器中显示为 MSS: (KeepAliveTime)，表示 keepalive 数据包的发送频率（以毫秒为单位，建议设置为 300,000），并存储在注册表项 HKLM\System\CurrentControlSet\Services|Tcpip\Parameters\KeepAliveTime 中。此设置控制 TCP 发送保持连接数据包的频率，以验证空闲连接是否仍然有效。如果远程计算机仍然可达，它会确认收到保持连接数据包。

可能的值:

您可以在注册表中指定 1 到 0xFFFFFFFF 之间的值。本地组策略编辑器 UI 和上表中列出的值旨在帮助您选择最合适的保持连接时间。默认配置为 7,200,000（两小时）。

漏洞

能够连接到网络应用程序的攻击者可以建立大量连接，试图发起拒绝服务 (DoS) 攻击。

一些 TCP 配置

启用时间

1. 启动注册表编辑器
2. 在注册表编辑器的导航栏中，输入如下地址：HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
   
3. 创建一个新的 DWORD (32-bit) 值，命名为 KeepAliveTime。
   
4. 将其值设置为您计算好的毫秒数（例如 180000，选择“十进制”基数输入）, 对应 3 分钟 = 3 * 60 * 1000 = 180000 毫秒。
   
5. (可选但推荐）同样可以创建 KeepAliveInterval，设置为 1000 (1秒)，这是探测失败后的重试间隔。
6. 重启服务器: 修改注册表后，必须重启服务器才能使新的 TCP/IP 参数生效。

完成以上操作后，您的服务器就会在 TCP 连接空闲 3 分钟后，自动发送一个 TCP Keepalive 探测包。这个包会穿过 LB，重置 LB 的空闲计时器，从而完美地解决了连接被意外断开的问题。

产生的影响

为什么默认的 KeepAliveTime 是 2 小时？

将 KeepAliveTime 的默认值设置为 2 小时 (7,200,000 毫秒) 主要是出于以下几点考虑：

1. 资源和网络效率：TCP Keep-Alive 机制的初衷是为了清理那些因意外（如客户端断电、网络中断）而未能正常关闭的“半开放”连接，从而释放服务器资源。它并非设计用来处理活跃连接的临时网络中断。如果默认时间很短，那么系统上成千上万的每一个空闲 TCP 连接都会频繁地发送探测包。这会在整个网络中产生大量不必要的“噪音”流量，并消耗服务器、客户端以及所有中间网络设备（路由器、防火墙）的 CPU 和内存资源。2 小时的默认值是一个非常保守的设定，旨在确保该功能仅作为最后的资源回收手段，而不是常规的网络活动。
2. 协议的普遍适用性：TCP/IP 协议栈需要适应各种各样的网络环境和应用场景。在很多应用中，一个连接长时间处于空闲状态是完全正常的（例如，一个 SSH 会话、数据库连接池中的连接等）。如果默认值很短，可能会错误地中断这些正常但空闲的连接。因此，一个非常长的时间是作为“最大公约数”的安全选择，确保不会干扰大多数标准应用的正常行为。
3. 历史和兼容性：这个默认值在很早期的网络协议设计中就已确立，当时的网络带宽和处理器能力远不如今天。设计的核心思想是“信任连接”，即假定一个连接是有效的，除非有非常充分的理由（长达 2 小时的死寂）去怀疑它。这个传统值一直被沿用至今。

如果将 KeepAliveTime 设置为 3 分钟会有什么影响？
将 KeepAliveTime 从 2 小时缩短到 3 分钟（180,000 毫秒）是一个常见的优化实践，特别是在有状态防火墙或负载均衡器（Load Balancer）等中间设备存在的情况下。这些设备通常有较短的空闲连接超时时间（例如 5-15 分钟）。

主要正面影响：

• 防止连接被中断：这是最直接的好处。通过将 KeepAliveTime 设置得比负载均衡器的空闲超时时间短，操作系统会主动在连接被判定为“空闲”之前发送一个 Keep-Alive 探测包。这个包会重置负载均衡器的空闲计时器，从而有效地“欺骗”它，让它认为连接仍然活跃，避免了因超时而被意外断开的问题。这正是您在处理长时间运行的 SSRS 报表时所需要的。

潜在的负面影响（通常很小）：

1. 网络流量增加：这是最主要的代价。现在，系统上每一个进入空闲状态超过 3 分钟的 TCP 连接都会开始发送探测包。在一个有大量并发连接的繁忙服务器上（例如，大型 Web 服务器或数据库服务器），这可能会导致额外的、可测量的网络流量。不过，由于 Keep-Alive 包非常小（通常不含数据，只有一个 ACK 标志），在现代千兆或万兆网络中，这种额外开销对于大多数系统来说几乎可以忽略不计。
2. 系统资源消耗轻微增加：操作系统需要为每个需要检测的连接维护计时器，并处理探测包的发送和响应。同样，在现代服务器硬件上，这点额外的 CPU 和内存开销通常微不足道，除非服务器承载着数十万甚至上百万个并发连接。
3. 对移动和不稳定网络的影响：对于某些移动设备或处于不稳定网络（如 3G/4G）的客户端，过于频繁的 Keep-Alive 探测可能会因为暂时的网络波动而错误地判断连接已断开，导致连接被提前终止。但在服务器到负载均衡器这样的稳定数据中心网络环境中，这通常不是问题。

结论

对于您的场景——防止负载均衡器中断长时间运行的报表连接——将 KeepAliveTime 调整为一个比负载均衡器超时时间更短的值（例如 3 分钟）是完全正确且推荐的做法。

这种调整的负面影响在现代服务器和网络环境中通常可以忽略不计，而它带来的好处（维持长连接的稳定性）则是实实在在的。这是一种用极小的资源开销换取关键业务连接稳定性的有效策略。

一些参考资料

• TCP/IP-Related Registry Entries
• 如何修改 TCP/IP 最大重新传输超时时间
• KeepAliveTime
• Keep-Alive and HTTPS
• Deprecated TCP parameters
• TCP timeout for established connections in Windows
• 4个实验，彻底搞懂TCP连接的断开