java - Java REST 的正确心跳/保持 Activity 技术/层是什么？ http？ TCP？编码: chunked?

Question

设置:

我们有一个https://Main.externaldomain/xmlservlet站点，正在对 http://London04.internaldomain/xmlservlet 进行身份验证/验证/地理定位和代理(稍作修改)请求例如。

根本无法直接访问向最终用户公开的内部域。站点之间的通信偶尔会中断，有时内部域节点会变得不可用/死亡。

主站点使用 org.apache.http.impl.client.DefaultHttpClient (我知道它已被弃用，我们正在逐步升级此遗留代码)，并将 readTimeout 设置为 10.000 毫秒。请求和响应具有可变长度的 xml 有效负载/主体和 Transfer-Encoding: chunked使用，也是 Keep-Alive: timeout=15已使用。

问题:

有时 London04 实际上需要超过 10 秒(假设是 2 分钟)才能执行。有时它会不正常地崩溃。有时会发生其他(网络)问题。有时在那 2 分钟内，response-xml-data 的各部分逐渐被填充，各部分之间没有 10 秒的间隙，因此永远不会超过 readTimeout，有时会有 10 秒以上的间隙，HttpClient 会超时...

我们可以尝试增加主端的超时，但这很容易使监听器池膨胀/过载(仅通过常规流量，甚至还没有被 DDOS 攻击)。我们需要一种方法来区分内部站点仍在生成响应的情况和它真正崩溃/网络丢失等情况。最好的感觉就是在交流过程中出现某种心跳(每 5 秒一次)。

我们认为 Keep-Alive 会拯救我们，但它似乎只能确保请求之间的间隙(而不是请求期间的间隙)，而且似乎并不能做到这一点间隙期间的任何心跳(只是有/等待超时)。

我们认为分块编码可以通过发送一些心跳(0字节大小的 block )来让另一方知道来拯救我们，但似乎没有这样/默认的实现来支持任何心跳这种方式，而且似乎0 字节大小的 block 本身就是一个 EOD 指示器...

问题:

如果我们的假设是正确的，KeepAlive/ChunkedEncoding 不会帮助我们实现 keepAlive/hearbeat/fastDetectionOfDeadBackend，那么:

1)这样的心跳应该在哪一层实现？ http？ TCP？

2)任何标准框架/库/设置/等已经实现了它？ (如果可能:Java、REST)

---

更新

我还研究了 WADL/WSDL 的心跳实现器，尽管没有发现 REST 的心跳实现器，但检查了 WebSockets...还研究了 TCP-keepalives，这似乎是完成该任务的正确功能:

• https://en.wikipedia.org/wiki/Keepalive
• http://tldp.org/HOWTO/TCP-Keepalive-HOWTO/usingkeepalive.html
• Socket heartbeat vs keepalive
• WebSockets ping/pong, why not TCP keepalive?

但是根据那些我必须设置类似的东西:

• tcp_keepalive_time=5
• tcp_keepalive_intvl=1
• tcp_keepalive_probes=3

这似乎是一个反建议(建议2小时，10分钟已经作为奇数出现，会是5秒理智/安全吗？如果是的话 - 可能是我的预先解决方案......)

我应该在哪里配置这个？单独在 London04 上还是也在 Main 上？ (如果我将其设置在 Main 上 - 它不会淹没客户端-->主前端通信吗？或者站点之间的 NAT/等可能会轻易破坏 keepalive 意图/支持吗？)

附注欢迎任何指向 RTFM 的链接 - 我可能只是错过了一些明显的东西:)

Answer 1

我的建议是不要使用心跳。让面向外部的 API 返回 303 See Other，其 header 指示何时何地可以获得所需响应。

所以你可以调用:

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，总共需要两分钟。

或者，使用旨在长时间保持开放的协议(protocol)，例如 WebSockets 。