GO HTTP1.1 与 HTTP2.0 的使用和简单分析

测试结果

我们设定服务端处理一次请求需要 10 ms，我们可以得到三个信息

所以我们可以得到结论，对于一个稳定的服务器，HTTP1.1 单位时间的处理效率和连接数成正比，需要更高的处理效率就必须不断的增加 TCP 连接。因为 HTTP1.1 的请求遵循 FIFO。

测试结果

GO HTTP2.0 我没有找到设置连接池数量的地方，但是在测试中执行

发现连接数量一直是 4 个，同时我们可以看到，仅仅 4 个 TCP 连接，就能在并发达到 200 的时候 1s 内执行 2w 次请求。效率远超 HTTP1.1，且不需要更多的 TCP 连接。

考虑基于HTTP的RPC，或者HTTP服务器主动通知客户端的机制，就是HTTP Long-Polling，意思就是客户端发起一个长连接，服务器阻塞忍住不响应直到：

超时，比如5秒后，我们给客户端响应一个keepalive，意思是现在还没有啥事，请继续polling。

拿到结果，这个可能是任何时候，比如300毫秒、1100毫秒、2300毫秒拿到一个事件，响应给客户端，实现了有事件异步通知。

这样客户端和服务器之间RPC的效率就非常高，只有在有事件时才会通知。但是，实际上还有一种情况需要处理：

当客户端断开连接，比如客户端设置了3秒钟TCP请求超时，或者因为客户端Crash时OS回收了FD等等，这个时候服务器应该要终止polling事务，停止获取事件。因为如果这个时候获取了事件，那么如何处理这个事件？只能丢弃，如果客户端再次发起请求，就拿不到这个事件了。

问题就来了，如何在HTTP Handler中探测客户端断开？例如：

---