我遇到了需要检查订单状态的情况。但是远程服务器不会很快返回响应，因为它会转换相对较长的时间。
所以有人建议我使用HttpClient的长链接或半长链接。 但我从来没有遇到过这种未知的情况。所以我想知道如何实现它。有人有什么好主意吗？
如果你所谓的"长链接"或"半长链接"的意思是"保持活动"，那么我想我得到了一个解决方案。有一个名为"连接"的标头，它有两个参数可供选择："保持活动"或"关闭"。在 http 1.0 中，默认情况下它是"关闭"的。但在 Http 1.1 中，"Keep-Alive"是默认值。因此，如果要实现持久链接，则需要在执行这些请求之前调用setRequestHeader("Connection" , "Keep-Alive") HttpGet/HttpPost/HttpPut的方法。
同时，也许您在下面已经知道这一点，希望对您有所帮助：
Http Keep-Alive似乎被严重误解了。这是一个简短的 在 1.0 和 1.1 下描述其工作原理。
HTTP/1.0
在HTTP 1.0下，没有关于keepalive如何运行的官方规范。从本质上讲，它被附加在现有协议上。如果浏览器支持 keep-alive，它会向请求添加一个额外的标头： 连接：保持活动状态 然后，当服务器收到此请求并生成响应时，它还会在响应中添加一个标头：
连接：保持活动状态 在此之后，连接不会断开，而是保持打开状态。当客户端发送另一个请求时，它使用相同的连接。这将持续到客户端或服务器决定会话结束，并且其中一个断开连接。
HTTP/1.1
在HTTP 1.1下，官方的keepalive方法是不同的。所有连接都保持活动状态，除非以下标头另有说明： 连接：关闭 因此，连接：保持活动状态标头不再具有任何意义。此外，还描述了一个可选的 Keep-Alive： 标头，但指定不足，以至于毫无意义。避免它。不可靠的HTTP是一种无状态协议 - 这意味着每个请求都独立于其他请求。保持活力并不能改变这一点。
此外，不能保证客户端或服务器将保持连接打开。即使在 1.1 中，所承诺的只是您可能会收到连接正在关闭的通知。因此，keepalive 是你不应该编写应用程序来依赖的东西。KeepAlive 和 POST HTTP 1.1 规范指出，在 POST 的正文之后，不能有额外的字符。
它还指出，"某些"浏览器可能不遵循此规范，在 POST 正文之后放置一个 CRLF。 嗯嗯。据我所知，大多数浏览器都遵循带有 CRLF 的 POST 正文。有两种方法可以解决此问题：在 POST 请求的上下文中禁止保持连接状态，或者单独忽略一行上的 CRLF。大多数服务器以后一种方式处理此问题，但是如果不进行测试，就无法知道服务器将如何处理它。