现象:第三方推广网站拉取feed文件经常不完整
整个调用链是这样的:HA负载均衡->前台nginx->后台nginx->tomcat把文件流输出到response
排查1:
tomcat无相关错误日志
后台nginx的body_bytes_sent总是完整的
前台的nginx的body_bytes_sent容易出现不完整
HAProxy至前台nginx未排查
外网至HAProxy的https连接以及网络状况未排查
问题明显出在前台nginx这一层。
排查2:
通过浏览器访问外网地址下载文件基本都是成功
Googlebot经常不完整
curl命令或RESTClient工具经常不完整,分析curl日志可以看到明显丢包
排查3:
curl -H "Connection:keep-alive" "文件url" > /home/ubuntu/test/`date +%F_%H:%M:%S`.csv 2> /home/ubuntu/test/`date +%F_%H:%M:%S`.log
经常得到以下结果,是否加keep-alive都一样,字节数是随机的
curl: (18) transfer closed with 279035 bytes remaining to read
windows下用wireshark抓包也有明显的丢包情况
过滤器:ip.src == 本机IP or ip.dst == 本机IP
怀疑过tomcat输出文件流的时候没有添加content-length,但加入后问题仍存在,客户端没有像浏览器那么只能会重发。
也怀疑过nginx的缓存设置,但因为是网络问题,很难模拟,也很难在线上调试。
反观整个调用链,也有很多不科学的地方:比如tomcat返回流,而不是返回X-Accel-Redirect,增加了很多不必要的IO开销,多层转发也是,用https也是。
所以最后采用了一种非常轻快的网络架构:HA->后台nginx->文件的方式,果然连接速度要快个几十倍,完全没有丢包问题!
而关于这个过程也引申出一个方法论的问题。是应该死磕层层分析问题根源,还是直接采用简单有效的解决方法?
再挖深下去大概会是nginx缓冲区的逻辑、流文件传输的逻辑、https的性能损耗,然而这种流传输本来就不是文件下载的最佳实践。
最后,附带转载OS网络层面参数调优的文章~
http://blog.csdn.net/anghlq/article/details/17302151