一、问题背景

OA系统部署完毕，小范围上线使用后，收到用户反馈，说是通过消息对话框或者其他一些涉及文件上传如审批的模块，上传文件速度非常慢，2M的文件上传要几分钟，几十兆的文件基本就失败了。

客户OA 系统 web端地址： https://oa.example.com

文件上传链路：

用户 -----> https://oa.example.com:443  ---- >客户网络设备(NAT)----> 外部反向代理 outer_nginx_vip:443  -------> 文件服务A ---->内部反向代理  inner_nginx_vip:80 ----> 文件服务B ----> mongoDB

二、问题排查

客户网络是电信 100M带宽。

我用账号测试在公司网络（电信网）涉及文件上传的地方都测试上传了，没问题。

另一位同事也做了测试没问题，但是如果用笔记本连公司wifi（移动网），就能复现这个问题。

这个问题并不是所有用户都有反馈，只有一定比例的用户，说明并不是全局性的。

1. 初步认为文件上传过程中 移动/联通/电信之间的转网导致上传速度慢

分别用 在移动/电信网络下， tracert  oa.example.com  没发现有什么问题，在移动网络下测试电信地址，经过的路由当然要多，说明不了什么，而且反馈的客户本身使用电信网络的也不少，所以排除这个原因。

2. 可能是服务器时间同步、OA系统文件模块问题

2.1. 发现代理服务器、文件服务器和数据服务器之间有几十秒的时间差，于是搭建内网ntp服务器，将所有服务器全部同步一遍，然后将反向代理、文件服务相关工程，文件存储相关数据库全部重启一遍，问题依然存在

2.2.  测试上传几个文件，跟踪文件上传日志，从nginx反向代理日志到文件服务工程日志，没发现有什么问题

2.2.  不经客户外网接入设备，直接通过与内网OA 服务器同一个网段的Windows服务器，将域名oa.example.com 写hosts解析到 nginx_vip 上传文件，非常快

说明不是OA系统文件模块本身问题。

3. 因为是有一定概率出现问题，怀疑问题出在客户网络设备的负载均衡器上

客户方网络人员于是将 NAT 映射的内网地址从 nginx_vip 改为 nginx01_ip，测试发现问题依然存在，问题不在这里。

4. 在内网服务器上搭建其他服务，将端口映射出去，测试文件上传

4.1 在 nginx01 服务器上使用nexus搭建一个web服务，将 8081端口映射到 oa.example.com，通过登录 http:// oa.example.com:8081测试文件上传。

那么， 这个服务经过的 客户网络设备跟OA文件服务是相同的。

测试发现，不同用户上传，有人快，有人慢/失败；同一个用户某天快，某天慢/失败。

4.2. 将内网的  nginx01 、db01 两台服务器的 22 端口分别临时映射到 oa.example.com，通过 ssh  username@oa.example.com 直接SSH 远程到内网服务器

使用 SSH 客户端工具通过 sftp直接上传文件，发现 几十k的小文件可以，几兆、几十兆的文件上传一会，就直接中断了，不只是慢，而是直接失败

5.  怀疑客户接入层网络设备中使用了ECMP，且某条链路有问题

测试用nexus上传文件发现一个非常诡异的现象：在家里通过vpn接入客户网络，大小文件，上传一定成功；如果直接通过公网，会某天成功，某天会失败。

这就很让人不可思议了，开始怀疑接入设备对接收的请求报文，使用了某种调度算法，当来源不变，调度走的链路不变，而来源ip是其中一个因子。

家里宽带的出口公网ip，每天都是变化的，对客户接入设备而言可以理解为 源ip变了，那么请求报文被调度走的链路可能不一样。

当某天在家通过浏览器上传失败时，改为接口调用命令行接口调用上传：

curl -v -u username:password --upload-file file.zip http://oa.example.com:8081/repository/test/ file.zip

在家里Windows电脑上执行失败，但是登录我的一台云主机执行同样的命令是成功的。

我们做了如下测试：

nexus 文件上传， http协议

SSH  文件上传，sftp协议

OA 文件上传，http协议

通过上述测试，不管使用什么协议，都有失败的概率，那么底层问题应该出在tcp上。

当然在做nexus 、sftp文件OA系统文件上传时间，同时开启了客户端Wireshark抓包，抓包条件为 ip.host == xx.xx.xx.xx

xx.xx.xx.xx 为 oa.example.com 的公网ip

当文件上传慢/失败时，有大量的 乱序、丢包，从而导致tcp层的大量的重传，进而导致文件上传慢/失败。

当文件上传正常时，乱序、丢包是偶现，影响不大。

三、 客户网络设备问题排查

从上面测试结果看，基本可以确认问题出在客户的接入网络设备上了。

通过跟客户网络人员逐层设备抓包测试，发现问题可能是负载和汇聚直接互联的接口，两个一组聚合，协商出了问题。

注： 深信服网络设备上，可以直接通过设备的管理界面，设置抓包参数开启抓包，生成抓包文件，用wireshark分析。

负载  和 汇聚层  ，负载模式下，2X2  有4条线路

当关闭 链路3时，原来上传有问题，上传都ok了，通过公网上传100M左右的文件也很快了，这也解释了问什么一定概率的用户文件上传失败了。

四、问题处理反思

一开始就应该开启wireshark 抓包，就能知道文件上传慢、失败是因为 底层tcp报文 大量的 乱序、丢包和重传，这样就不用做那么多后面的文件上传测试了。

当然，如果没有那么多的链路段测试，客户网络人员不会如此配合，毕竟经过这些测试之后，问题都指向了接入层网络设备，跟上层应用没有关系！

五、参考

Nexus REST and Integration API

https://help.sonatype.com/repomanager3/integrations/rest-and-integration-api

Wireshark网络抓包(一)——数据包、着色规则和提示

https://www.cnblogs.com/strick/p/6261463.html

Wireshark网络抓包(二)——过滤器

https://www.cnblogs.com/strick/p/6261915.html

Wireshark网络抓包(三)——网络协议

https://www.cnblogs.com/strick/p/6262284.html

Wireshark网络抓包(四)——工具

https://www.cnblogs.com/strick/p/6344486.html