上传 OSS 出现慢的场景，OSS 会返回一个 requestID 属性，请保留这个 requestID 这是 OSS 所有信息的查询入口，升级阿里云时可以快速定位问题，如果上传超时的话时没有这个属性的。 requestID 可以通过抓包获取到，也可以在代码中解析 OSS 的返回 http result 结果获得。

客户端在上传 OSS 时用的内网的地址还是公网的 OSS 地址，如果使用了阿里云主机服务，并且和 OSS 是同一个 region ，强烈推荐使用 internal 内网地址操作 OSS 这能大大提升你的请求速度。OSS 提供的域名可以参考 https://help.aliyun.com/document_detail/31837.html?spm=a2c4g.11186623.6.571.4dcd2841C29fHi

如果走公网上传 OSS ，速度无法保证，排查需要结合多个网络测试命令，比如常用ping -c 50 -i 0.01 -s 1024 mar traceroute ，如下测试客户端的网络出口也不是很稳定，需要多次的测试。

排除客户端出口带宽是否被打满，可以通过 iftop 看下客户端的出口流量。

etstat 查看下主机的 TCP 链接是否被打高

客户端的上传代码读取的是本地文件还是网络流，如果是读取的网络流然后上传到 OSS ，那读文件的时间也会影响到上传时间。建议用本地文件先测试。

客户端的代码是否开启过 crc64 ，开启这个功能对上传的性能影响比较大，开启 crc 后，要在本地先对文件循环冗余校验完后，在开始上传，很消耗性能。

"看病" 对号入座，按照上面描述的分成多个问题进行描述，基本都是上传延迟的问题。

该病例，使用 ossutil 工具对比 OSS 的 SDK 上传速度比 osstuil 慢几十倍。

结论：如果使用 OSS SDK 时建议关闭掉 crc64 ，可以在请求头中增加 Content-MD5 的方式用 MD5 替换 crc64 ，性能更快。

分析：通过 JAVA 2.8.3 版本的上传接口 PutObjectResult putObject(String bucketName, String key, InputStream input) 上传文件到 OSS ，通过打印前后的系统时间发现每次上传都要几十秒，但是通过 requestID 和抓包的结果都很快。

通过完成的抓包，可以看到网络传输开始到结束的时间非常短，物理的传输时间都很短，证明确实很快就完成上传的操作，但为什么打印的时间差和抓包有这么大差距，需要看下客户端的代码。发现客户端的代码再调用 putobject 时传入的文件是一个网络流，通过公网去读源文件，代码 debug 发现时间整体卡在了读的延迟上，于是更换了本地文件测试后发现秒传。

结论： 建议出现这类问题先抓包看下实际的物理传输是不是真的慢，还仅是自己打印的时间慢而已。

分析：

第一个问题：客户端时再内蒙古，OSS 再杭州，通过公网上传 OSS，在学校内部上传作业失败率很高，但是在校外上传失败率明显下降。日志报链接失败。

第二个问题：客户端网络内无法解析公网域名。

结论： 综合现象来看当客户端由学校转移到家里后失败率就下降，学校的网络避免不了嫌疑，但是由于一致没有抓包链接失败的包，只能从网络的角度分析，客户端的弱网导致了链接失败超时。此类问题只能通过抓现象包来进行分析，遇到这类问题第一时间抓包保留现场。

分析：

出现这种跨国传输超时，要先在本地抓包，判断是否被国际链路出口封堵导致，一般跨国的 OSS 传输建议购买全球加速 CDN 的方式来做，或者使用阿里云的高速通道和专线。

分析：

客户端先尝试开始的基础排查，先确定客户端的网络是稳定的，如果无法解决后，第一时间获取到上传时间过长的 requestID 或者抓包升级到阿里云。

通过 SDK 上传小文件到 OSS ，自己代码中调用时间打印发现超过 20s

分析：

出现这种问题，先在本地部署个抓包看下是否真的上传有延迟，该案例是程序问题， SDK 再读取文件是通过网络流读取，这部分时间也算到 SDK 的上传时间内。导致打印的时间过长，切换到本地文件测试后时间恢复正常。

2018-10-26 10:06:05.962 nodejs.ResponseErrorException: ResponseError: socket hang up, GET http://prod33.vpc100-oss-cn-beijing.aliyuncs.com/webpack-hot-middleware/-/webpack-hot-middleware-2.24.3.tgz -1 (connected: true, keepalive socket: true, agent status: {"createSocketCount":3436,"createSocketErrorCount":0,"closeSocketCount":3433,"errorSocketCount":0,"timeoutSocketCount":58,"requestCount":3520,"freeSockets":{},"sockets":{"prod33.vpc100-oss-cn-beijing.aliyuncs.com:80:":3},"requests":{}}, socketHandledRequests: 2, socketHandledResponses: 1)headers: {}

2018-10-26 10:46:15.042 nodejs.ResponseErrorException: ResponseError: socket hang up, GET http://pro-rd-cnpm.vpc100-oss-cn-beijing.aliyuncs.com/is-binary-path/-/is-binary-path-1.0.1.tgz -1 (connected: true, keepalive socket: true, agent status: {"createSocketCount":633,"createSocketErrorCount":0,"closeSocketCount":632,"errorSocketCount":0,"timeoutSocketCount":1,"requestCount":632,"freeSockets":{},"sockets":{"pro-rd-cnpm.vpc100-oss-cn-beijing.aliyuncs.com:80:":1},"requests":{}}, socketHandledRequests: 2, socketHandledResponses: 1)

2018-10-26 10:46:15.042 nodejs.ResponseErrorException: ResponseError: socket hang up, GET http://pro-rd-cnpm.vpc100-oss-cn-beijing.aliyuncs.com/is-binary-path/-/is-binary-path-1.0.1.tgz -1 (connected: true, keepalive socket: true, agent status: {"createSocketCount":633,"createSocketErrorCount":0,"closeSocketCount":632,"errorSocketCount":0,"timeoutSocketCount":1,"requestCount":632,"freeSockets":{},"sockets":{"pro-rd-cnpm.vpc100-oss-cn-beijing.aliyuncs.com:80:":1},"requests":{}}, socketHandledRequests: 2, socketHandledResponses: 1)headers: {}

分析：

结论：

2018/10/24 14:03:47 hlg_matting_PreF (pid=15693)(error): parseUrl2Image.hpp(186), read_element: image_url_service connect fail: Could not resolve host: disanzhe.oss-cn-hangzhou-internal.aliyuncs.com, url: https://disanzhe.oss-cn-hangzhou-internal.aliyuncs.com/mattings/0/images/20181024-135354-f5ee.jpg

通过报错可以看出客户端发出的 DNS 请求都失败，导致的请求 OSS 超时，这种问题，直接看下 DNS 服务是否异常，或者 DNS 出现异常、限流等问题，并不是 OSS 故障。

问题：

客户端通过驻云工具上传 OSS 同一个 bucket 不通 prefix，经常出现 curl error 的情况，由于驻云客户端不是阿里云开发的，所以错误定义并不是很清晰，逐一排查。

分析：