一个网络通讯问题的解决

某个OpenAPI应用在大并发量情况下，其中某个jsp总会堵在一个for循环的JspWriter.write处，通过jstack观察如下：

在测试环境下做同样用户日志的压测，奇怪的是并不能重现此问题，之后通过tcpflow定位到此接口调用方(调用方的User-Agent是一个公司内的客户端标识)，但依然没有想到什么好的定位方法。
后来有一天，突然想到可以通过伴随压力测试先确认一下是否是网络通讯层的问题，伴随压力测试是用线上机器作为压测服务端，而压测客户端是和线上机器在同一内网的另一台机器。在增压后如果出问题的线程栈数量和增压数量没有成正比增加则可以证明是网络层的问题，压测发现果然如此。
接下来上tcpdump来抓包，抓了几个包发现如下疑点：

• 每次调用返回的response很大，通常需要很多次TCP分包，导致整体响应经常超秒
• 经常出现TCP接收端（客户端）ack动作很慢，导致发送端（服务端）发送缓慢
• 如果在网页中调用此接口则不会出现数据量大的问题，整体响应在几百毫秒内完成

通过上述分析，基本可以确认是客户端的问题了，回过头来仔细看了看客户端的HTTP头，发现居然是没有支持gzip压缩的！而之所以在网页中调用会很快，是因为浏览器默认会支持gzip压缩，所以只要通知客户端的同学在HTTP头中增加：“Accept-Encoding: gzip”，并且客户端需要支持gzip的解压缩，问题就会解决了。