Http 的 Keep-Alive，这是干啥的呢，之前听说过，这是一种优化，因为Http是个TCP之上的应用层协议，HTTP发一个请求就要把底层的TCP断了再连上，这是不是有点麻烦了？
起因
我写的系统，有些设计不当，把一些复杂的操作放在前端了，然后并发有点大、请求有点多（8并发，几千个请求），IP段会被服务器机房风控。
事到如今，改程序不是很合适，不想改，那就看看其他方法喽。
实验
实际上，浏览器默认会去尽量复用TCP的，浏览器总是会在请求头中携带Connection: keep-alive
如果服务器的响应头没有响应Connection ，那就默认keep-alive 了。
之前没怎么留意，openresty代理的我的网站都使用了连接保持（似乎所有网站都会去使用）。
Chrome浏览器可以看到底层连接的复用（Firefox似乎不可以）：
之前就好奇这个图是怎么看的，现在知道了，这个图横着是时间轴，竖着是TCP连接ID，每个HTTP请求是一块，这些块会被排列到某个TCP上。
解决问题
紧接着我测试了我的写的系统，本来以为它没有使用连接保持，毕竟我没配置嘛，但是一测发现，似乎连接保持一直都是开着的，Tomcat默认配置了。离谱问题出现了，为啥会被风控呢？
所以，现在我猜测，有以下原因，
服务器机房会分析Http请求
这个样子发到服务器的包太碎了（都是小包），被误判为攻击行为。
我的科学上网会影响连接复用。
但是我不能验证啊，被风控了的话要好久才解开，而且解开之后一段时间很容易再次风控。别问我怎么知道的
于是，我给它套了个Https···
Https，保佑我不被风控————
