F5负载均衡器后端MVC应用会话超时问题：寻求会话持久化配置建议

既然你已经确认IIS的会话超时配置完全没问题，那问题肯定出在F5的会话持久化（粘性会话）或者相关超时参数上，以下是具体可调整的点：

1. 优化会话持久化算法配置 #

• Cookie持久性（优先推荐）：这是Web应用最可靠的粘性会话方式，F5会给客户端下发BIGipServer<你的池名称>的专属cookie，后续请求通过这个cookie固定到同一后端服务器。
  • 核心要把F5的cookie超时时间设得比IIS的会话超时时间长5-10分钟，比如IIS设20分钟，F5就设25-30分钟，避免cookie先过期导致会话跳转。
  • 选HTTP Cookie类型，一定要设固定过期时间，别用默认的会话型cookie（浏览器一关就失效）。
• 源IP持久性（备选）：如果客户端普遍禁用cookie，才考虑用这个，但要注意多用户共享公网IP时会导致负载不均，尽量不用。
• SSL会话ID持久性（仅HTTPS场景）：基于SSL会话ID绑定，但客户端频繁重建SSL连接时会失效，可靠性远不如cookie。

2. 调整F5的连接超时参数 #

• TCP连接超时：F5默认的TCP空闲超时可能比IIS会话超时短，导致连接被提前断开，会话上下文直接丢失。进入Local Traffic > Profiles > TCP，把Idle Timeout调到和IIS会话超时一致或者更长。
• HTTP会话超时：检查HTTP profile里的Idle Timeout，确保它不会过早关闭HTTP会话，影响后端的会话维持。

3. 关闭干扰会话持久化的F5特性 #

• 确认F5没开启动态会话回收功能，有些场景下F5会因为后端服务器负载高强制切换用户会话，直接关闭这个策略保证会话绑定稳定。
• 如果启用了OneConnect连接复用，检查它的Source Mask配置，要是发现会话绑定被干扰，要么调整掩码要么直接禁用OneConnect（仅在会话出问题时操作，正常情况OneConnect能优化性能）。

4. 验证调整后的效果 #

• 用浏览器开发者工具查看响应头里的F5持久化cookie，确认超时时间符合设置，而且每次请求都带着这个cookie打到同一台服务器。
• 进入F5的Local Traffic > Pools > Statistics查看会话绑定的分布，确保单个用户的请求稳定落在同一后端节点。

内容的提问来源于stack exchange，提问作者chandru arya