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