设置：
我们有一个https://Main.externaldomain/xmlservlet站点，例如，对http://London04.internaldomain/xmlservlet的身份验证/验证/地理定位和代理（略微修改）请求。
根本没有直接访问暴露给最终用户的internaldomain。站点之间的通信偶尔会中断，有时内部域节点变得不可用/死亡。
主站点正在使用org.apache.http.impl.client.DefaultHttpClient（我知道它已被弃用，我们正在逐步升级此遗留代码），readTimeout设置为10.000毫秒。请求和响应具有可变长度的xml有效负载/主体，并且使用Transfer-Encoding: chunked，也使用Keep-Alive: timeout=15。
问题：
有时London04实际上需要超过10秒（比方说2分钟）才能执行。有时它会非优雅地崩溃。有时会发生其他（网络）问题。有时在这2分钟内 - 响应-xml数据的部分正在逐渐填充，部分之间没有10秒的间隙，因此永远不会超过readTimeout，有时会有10秒以上的间隙而HttpClient超时...
我们可以尝试增加Main端的超时，但这很容易使监听器池膨胀/过载（仅通过常规流量，甚至还没有DDOS）。我们需要一种方法来区分内部站点仍在工作 - 生成响应和它真正崩溃/ network_lost /等的情况。在交流过程中，最好的感觉是某种心跳（每5秒钟）。
我们认为Keep-Alive会拯救我们，但它似乎只能保证请求之间的间隙（不是在请求期间），并且在间隙期间似乎没有任何心跳（只是等待/等待超时）。
我们认为chunked-encoding可以通过发送一些心跳（0字节大小的块）来让我们保存，让其他方知道，但似乎没有这样的/默认实现以这种方式支持任何心跳，而且似乎0-字节大小的块是EOD指示器本身......
问题（S）：
如果我们假设KeepAlive / ChunkedEncoding无法帮助我们实现keepAlive / hearbeat / fastDetectionOfDeadBackend，那么我们是正确的：
1）这样的心跳应该在哪个层实现？ HTTP？根据tcp？
2）已经实现它的任何标准框架/库/设置/等？ （如果可能的话：Java，REST）
UPDATE
我也研究了WADL / WSDL的心跳实现者，虽然没有找到REST，检查了WebSockets ......还查看了TCP-keepalive，它似乎是这项任务的正确选择：
但根据那些我必须设置的东西：
这似乎是一个反建议（建议2小时，10分钟已经作为一个奇数值，如果它是5s sane / safe ?? - 可能是我的解决方案......）
我还应该在哪里配置？仅在London04上还是在Main上？ （如果我在Main上设置它 - 它不会泛滥客户端 - >主要前端通信吗？或者站点之间的NAT /等可能会轻易破坏keepalive intent / support吗？）
附：任何RTFM的链接都是受欢迎的 - 我可能只是遗漏了一些明显的东西:)
我的建议是不要使用心跳。让您的面向外部的API返回带有标题的303 See Other，标题指示所需响应的可用时间和位置。
所以你可以打电话：
POST https://public.api/my/call
然后回来
303 See Other
Location: "https://public.api/my/call/results"
Retry-After: 10
在某种程度上，您的服务器可以猜测响应需要多长时间来构建，它应该将其计入Retry-After值。如果稍后对新位置进行GET调用并且尚未构建结果，则返回具有更新的Retry-After值的响应。所以也许你尝试10，如果这不起作用，你告诉客户等待另一个110，总共两分钟。
或者，使用旨在长时间保持打开的协议，例如WebSockets。