我是一个IISpipe理员。 我已经做了最好的，我可以用mod_ssl文档，谷歌等，并找不到任何人甚至遇到我的问题，更没有find一个解决scheme。 当然，这让我怀疑我是否能够正确地理解它，但在WireShark的痕迹中我清楚地看到了这一点。
我有一个缓慢的IIS服务器的竞争条件。 IIS服务器成功TLS连接到我的Apache服务器，并发送一个encryption的请求。 Apache服务器响应成功，IIS服务器通常很高兴并完成。 5秒钟后，Apache服务器发送TLS Rec-Layer-1 Encrypted Alert，TLS会话终止。 然而，现在，当客户端服务器通过现有的开放式TLS通道提交第二个或第三个encryption请求时，协商会变得复杂。 所有这些谈判的1000次999次都是完美无缺的。
千分之一的缓慢IIS服务器需要5秒钟才能决定发送一个额外的encryption请求（TLS应用程序数据）。 发生这种情况时，encryption的请求会通过TLS Rec Layer-1encryption警报，导致“底层连接已closures：连接意外closures”。
我没有看到mod_ssl中的任何指令，允许我延长5秒的会话超时。 我忽略了什么？
我可以修改SSLSessionCacheTimeout指令，但对任何特定对话周围的5秒超时没有影响。 有没有人看过这种行为？
听起来像每个应用程序请求是一个单独的HTTP调用 – 在这种情况下，我们的罪魁祸首可能是KeepAliveTimeout – 默认情况是5秒。
closuresHTTP keep-alive会完全解决此问题，但对性能也是有害的，需要新的TCP，然后TLS握手来处理每个请求。 相反，如果您将超时时间调整到一分钟或更长时间，或者应用程序始终发送请求，是否会出现“线上穿越竞争”情况？ 只要Apache服务器没有得到很多连接，就不应该增加这个值。
也许只是试试：
KeepAliveTimeout 120