HTTP连接的存活时间(keep-alive timeout)确实双方都可以设置，但最终生效的是双方设置中较短的那个值。这是因为TCP连接是双向的，任何一方都可以主动关闭连接。
客户端和服务端各自的设置
1. 服务端设置
位置：通常在Web服务器配置中(Nginx/Apache等)
常见配置示例：
Nginx: keepalive_timeout 60s; (默认75秒)
Apache: KeepAliveTimeout 5 (秒)
控制权：服务端可以强制关闭空闲连接，即使客户端希望保持更长时间
2. 客户端设置
位置：HTTP客户端库/框架的配置中
常见配置示例：
Python requests: 通过适配器设置
Apache HttpClient: setValidateAfterInactivity()
OkHttp: .keepAliveDuration()
行为：客户端可以决定何时主动关闭空闲连接
交互机制
协商过程：
通过HTTP头Connection: keep-alive和Keep-Alive: timeout=x(HTTP/1.1)
HTTP/2/3有更复杂的连接管理机制
实际生效时间：
plaintext
实际存活时间 = min(服务端timeout, 客户端timeout)
关闭触发：
任何一方达到自己的timeout值都可以发送FIN包关闭连接
通常服务端设置更严格，因为要管理大量客户端连接
典型场景示例
场景1：服务端设置60秒，客户端设置30秒
连接会在30秒空闲后被关闭(由客户端主动关闭)
场景2：服务端设置30秒，客户端设置60秒
连接会在30秒空闲后被关闭(由服务端主动关闭)
场景3：服务端设置60秒，客户端不设置(或设为0)
连接会立即关闭(因为客户端不希望保持)
最佳实践建议
服务端设置：
公共API服务：建议30-120秒
高并发服务：建议较短(10-30秒)
长连接服务：可设置几分钟甚至更长
客户端设置：
常规应用：与服务端保持一致或略短
移动端应用：建议较短(15-30秒)以节省电量
后台服务：可根据需求延长
特殊考虑：
负载均衡器通常有自己独立的keep-alive设置
HTTP/2/3的连接管理机制与传统HTTP/1.x不同
注意TCP层的keepalive机制(SO_KEEPALIVE)是另一个独立机制
理解这种双向设置机制有助于优化应用性能，避免出现"半开连接"等问题，同时也能更好地管理服务器资源。