背景：鉴于之前遇到很多 本地-》OSS ，上传、下载总是慢的情况，或者上传、下载经常出现错误或者异常的问题。根据多个典型案例，抽象出一下排查方案，希望对大家快速定位问题有所帮助。
一、必要了解信息
- requestID ，一般情况都会有，标识此次 OSS request 到达 OSS 服务端后返回的标志。除非建联失败，否则都会有这个 requestID 的，当问题比较难排查时可以将 requestID 提供给阿里云客服作为定位线索。
- 明确 上传/下载 的方式（阿里的工具、SDK、API、浏览器），不同的方式会有不同的思路，类似 JAVA SDK 如果 maxconnection 设小了，也会造成链接等待超时。
- 使用内网还是公网，大多数我们建议在 ECS 和 OSS 同可用区时最好使用内网，这样费用低，速度还快，公网一般出现拥塞，会被网络无限扩大。
- 在 client 端 ping traceroute MTR 到 OSS 服务端的截图信息，看看到公/私网是否有丢包，或者用 tcpdump 抓包看下网络是否有高延迟高丢包以及 TCP 协议栈异常的问题。
- 是否有明显报错，基本上遇到 socket timeout 的情况，都是网络超时，可以从本机的网络以及本机连接数，或者 client 是否有超时设置来排查。。
- 以上信息收集到后准备测试，源 OSS URL 测试（举例）：curl -svo /dev/null http://img.oss-cn-hangzhou.aliyuncs.com/uploads/temp/2018-01-02%20%2013-52-15-operate-stat.xls
- 如果要是 CDN -》 OSS 的问题，可以分别固定 CDN 和 OSS 源站进行测试 curl -I -x CDNIP:80 http://xxx/xxx，固定源站 curl -I -x http://xxx.oss-cn-xxx.aliyuncs.com/xxx 如果测试 OSS 200 正常， CDN 异常，则问题可能发生在 CDN 侧。
二、明确自己的服务架构逐层排查
- 本地 -》 OSS
- 本地 -》proxy -》OSSproxy 种类有很多，
- SLB
- WAF
- 高防
三、场景拟合
1、长时间或者间断性不能访问到 OSS
这种情况，先确认一下自己 bucket 有没有欠费，是否有被拉黑等，其次再本地的 PC 端 ping 下自己要访问的 OSS 公网域名（如果是用内网 ECS 通过私网 OSS 域名上传，可以 ping 私网域名）是否能通，以及 traceroute 到对端 OSS 的路由路径，看下是否断在了哪一跳。同时请自己网外的他人协助下同时发起 ping 和
traceroute 测试，看是否同样访问不通。如果是一样场景，可以将搜集的信息反馈给阿里云客服排查服务端是否异常。
场景2、本机上传文件到 OSS 超时，然后自动恢复
如图，遇到这类问题，需要先获取到必要信息。然后结合图中的 error 来看 socket 的异常，基本判断是由于网络问题导致了 Header 响应超时。侧面的 MTR TRACEROUTE 也可以看出来当时的网络质量如何，如网络正常但依然超时，可以直接抓包看下是哪端导致。
场景3、使用 JAVA SDK 上传文件超时返回 502
[chat-service] 2017-12-22 11:09:17,443 - com.aliyun.oss:73 -51224385 [http-nio-9081-exec-137] WARN - [Server]Unable to execute HTTP request: The difference between the request time and the current time is too large. [ErrorCode]: RequestTimeTooSkewed [RequestId]: 5A3C77583373BA19746BB032 [HostId]: sobot.oss-cn-beijing.aliyuncs.com [ResponseError]: <?xml version="1.0" encoding="UTF-8"?> <Error> <Code>RequestTimeTooSkewed</Code> <Message>The difference between the request time and the current time is too large.</Message> <RequestId>5A3C77583373BA19746BB032</RequestId> <HostId>xxx.oss-cn-beijing.aliyuncs.com</HostId> <MaxAllowedSkewMilliseconds>900000</MaxAllowedSkewMilliseconds> <RequestTime>2017-12-22T02:53:44.000Z</RequestTime> <ServerTime>2017-12-22T03:09:12.000Z</ServerTime> </Error>
如图，可以出现这种 Message ，已经明确告诉你本地与 OSS 服务端的时间差 >15min 导致。“The difference between the request time and the current time is too large”，出现此问题，一般与以下两个原因有关系：
1）用户本地的时间与服务端器的时区不一致，要求用户本地是标准的 GMT 或者 UTC 时间。
2）网络拥堵导致的等待时间过长超过 15min 。
3）JAVA SDK 参数配置不合理，比如 max connection
1）用户本地的时间与服务端器的时区不一致，要求用户本地是标准的 GMT 或者 UTC 时间。
2）网络拥堵导致的等待时间过长超过 15min 。
3）JAVA SDK 参数配置不合理，比如 max connection
具体处理工作流如下
场景4、OSSFTP 上传到 OSS 时，抓包出现 zeroWindows
1、OSSFTP 是将远端的 OSS 挂载到本地，但操作的文件每次都是发起 HTTP 请求远端 OSS ，所以受到网络和本地 IO 的影响，高敏感的业务是不太适合的。
2、看数据包中客户端发生的 ZeroWindows （代表 本地协议栈的 cache buffer 出现过满，应用层无法消费掉 buffer 的数据）
3、通过 ECS 机器查看自己 CPU 、内网、网卡 是否有跑满情况，这种情况负载过高必然回导致慢的情况。
建议：
1、由于 OSSFTP 是串行，而且是 FTPCLIET->FTPSERVER->OSS SERVER 两段操作性能无法保证，推荐使用 ossutil ，
链接：https://help.aliyun.com/document_detail/50452.html?spm=5176.doc31935.6.1032.YMtcGp
2、ossutil 在上传大文件时可以采用分片多线程的粒度上传，而我们的 ossftp 是不存在分片的。所以还是推荐 ossutil
未完待续
2、看数据包中客户端发生的 ZeroWindows （代表 本地协议栈的 cache buffer 出现过满，应用层无法消费掉 buffer 的数据）
3、通过 ECS 机器查看自己 CPU 、内网、网卡 是否有跑满情况，这种情况负载过高必然回导致慢的情况。
建议：
1、由于 OSSFTP 是串行，而且是 FTPCLIET->FTPSERVER->OSS SERVER 两段操作性能无法保证，推荐使用 ossutil ，
链接：https://help.aliyun.com/document_detail/50452.html?spm=5176.doc31935.6.1032.YMtcGp
2、ossutil 在上传大文件时可以采用分片多线程的粒度上传，而我们的 ossftp 是不存在分片的。所以还是推荐 ossutil
未完待续