AD自动保持长连接导致无法正常关闭http连接

问题描述：

    客户连接我司服务经常出现超时。

排查过程：

    在客户端抓包发现大量端口复用的包，由于客户业务复杂，既是服务端也是客户端。导致端口占用严重。2分钟左右会复用端口。

    在ad抓包有收到客户端的复用端口连接的syn请求。但ad不回应请求。由某公司工程师分析发现复用端口的的原连接在ad并未释放，依然处于ESTABLISHED状态，导致同样五元组的报文到达后，ad认定为异常包，不处理。

    分析报文发现客户通知ad关闭连接，但ad不回应。工程师给出原因是由于客户端同时发送ssl close notfiy与tcp fin。导致ad不能正常处理关闭流程，而客户端在发送请求后进入fin wait,在fin wait超时（客户端为20秒）后释放链接。

    工程师给出两个解决方案：

    1、修改七层虚拟服务TCP策略,将超时时间修改成1分钟。到达超时时间后ad发送keepalive包，如客户端不回应，ad关闭连接。

    2、打补丁包。使ad回应关闭消息。

    与开发一起分析发现服务端发送的connection: close报文被ad改写为S-Cnection: close。导致数据传输完成后服务端无法通知到客户端关闭连接。

    AD改写后的报头：

Content-Type: application/octet-stream;charset=utf-8
Content-Language: zh-CN
Content-Length: 188
Date: Mon, 06 May 2019 06:21:05 GMT
S-Cnection: close
Server: nginx


    在后台关闭服务自动保持长连接后客户端可收到服务端的关闭通知。正常关闭会话。
修改参数后：

修改参数前：

原因：

    1、ad不回应客户端关闭连接消息

    2、ad主动改写http关闭请求

解决方案：

    1、打补丁，使ad回应关闭消息。

    2、关闭服务自动保持长连接。

建议：

    ad默认对http进行优化。对浏览器类需要长连接的应用保持友好。对高并发短连接确是灾难。希望下个版本可显示的在界面对默认优化参数增加开关（全局开关、单服务开关）。

每天坚持打卡学习签到！！

打卡学习，感谢大佬分享！

每天坚持打卡学习签到！！

感谢楼主的精彩分享，学习了！

感谢作者分享，步骤写的很详细

感谢作者分享，步骤写的很详细

感谢楼主的精彩分享，学习了！

感谢分享，学习一下。

实用的案例，感谢分享！