共计 718 个字符，预计需要花费 2 分钟才能阅读完成。
记一次线上异样思考【HTTP】
背景
领取时向渠道申请，偶发的呈现了 NoHttpResponseException 异样，频次不高，没有法则。
异样申请重试之后数据都是失常的。
这种能够排除是业务代码问题，问题可能就呈现再 HttpClient 使用上了。
简要剖析和解决方案
我的项目中利用到了长连贯能够回顾下 :
- HTTP 的 keep-alive 个别咱们都会带上两头的横杠，一般的 HTTP 连贯是客户端连贯上服务端，
而后完结申请后，由客户端或者服务端进行 http 连贯的敞开。下次再发送申请的时候，
客户端再发动一个连贯，传送数据，敞开连贯。这么个流程重复。
然而一旦客户端发送 connection: keep-alive 头给服务端，
且服务端也承受这个 keep-alive 的话，这个连贯就能够复用了。
一个 HTTP 解决完之后，另外一个 HTTP 数据包也间接从这个连贯发送。
缩小新建和断开 TCP 连贯的耗费。
<br/>
<br/> - TCP 的 keepalive 是偏重在放弃客户端和服务端的连贯，
一方会不定期发送心跳包给另一方，
没有断掉一方的定时发送几次心跳包。如果距离发送几次，
对方都返回的是 RST，而不是 ACK，那么就开释以后连贯。
从 HTTP 长连贯和 TCP 长连贯能够揣测到：进入客户端刚刚获取到了 HTTP 的连贯，而服务端的 TCP 监测到长时间没有通信
端开了 TCP。断开后 HTTP 申请就会被回绝掉，就会导致 NoHttpResponseException。
异样复现：
在程序获取到连贯后调用之前断点（在建设长连贯后），期待服务端 TCP 断开，而后触发调用
能够看下抓包的数据（192. 为本地）(172.* 为近程)，超过一段时间 TCP 没有通信，近程服务端会断开 TCP
解决计划通过弥补机制重试：
正文完