能不转发的就不要转发——记一次文件下载丢包填坑之旅

现象：第三方推广网站拉取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