基础排查：
-
ping 工具，目的测试到对端的 IP 链路是否有丢包，RTT（Round-Trip Time）是否有大的波动。详细命令
ping -c 100 -i 0.01 -s 1024
 - mtr -n 通过 MTR 可以看到每一条的路由是否有丢包
- telnet 80 端口是否能通。保证 80 是通的才能下载
- 提供报错时的 OSS response header 中的 requestID 信息，一般 500 2XX 3XX 4XX 都会有 requestID 返回，504、502、503 这种网络超时的状态没有 requestID
案例：DNS 解析不稳定导致 curl 延迟
分析：
通过上述信息基本可以判断是 DNS 问题，本次 curl 的时间都不稳定，加上 DNS 解析时间后，发现是卡在了 DNS 解析上，经过沟通发现阿里云的 DNS 223.5.5.5 在广东的节点已经撤销，建议使用运营商的 DNS 或者 114 的 DNS。
案例：本地机房下载 OSS 资源超时
分析：
- 首先理清楚自己访问 OSS 架构是否是直接请求到 OSS 还是中间有 proxy 代理，如果有 proxy 代理的情况下先自己排查 client 到 proxy 的链路情况。
- 自己先找个其他 region 的 bucket 看下是否能否复现问题，以此排除掉是不是 OSS 的问题。
- 最好能够在客户端抓包分析一下，看看网络上卡在哪里导致的连接失败。
案例：下载 socketTimeout
常见于 SDK 、API 调用时的报错，客户源可能是在云主机或者 PC 端。通过文章开始所说道的信息我们判断是是否为必现问题，如果问题必现的话很容易能定位。如果不容易出现只能分层排查。
分析：
- 先看下主机的 socket 资源是否足够分配，通过可以用 netstat 或者 ss 命令来查看本机的 socket 连接数，如果主机 TCP 占用较慢，很容易出现连接数资源不够分配的情况
- 看下主机的 ulimit -n 的文件描述符是否够用。
- 如果用户使用的是 SDK ，需要确认 OSSClient 在初始化时是否限制了连接数和超时时间。如果通过前面测试发现网路不好抖动很大，建议把 sockettimeout 的时间放长些。
// 创建ClientConfiguration。ClientConfiguration是OSSClient的配置类，可配置代理、连接超时、最大连接数等参数。
ClientConfiguration conf = new ClientConfiguration();
// 设置OSSClient允许打开的最大HTTP连接数，默认为1024个。
conf.setMaxConnections(200);
// 设置Socket层传输数据的超时时间，默认为50000毫秒。
conf.setSocketTimeout(10000);
// 设置建立连接的超时时间，默认为50000毫秒。
conf.setConnectionTimeout(10000);
// 设置从连接池中获取连接的超时时间（单位：毫秒），默认不超时。
conf.setConnectionRequestTimeout(1000);
// 设置连接空闲超时时间。超时则关闭连接，默认为60000毫秒。
conf.setIdleConnectionTime(10000);
// 设置失败请求重试次数，默认为3次。
conf.setMaxErrorRetry(5);
// 设置是否支持将自定义域名作为Endpoint，默认支持。
conf.setSupportCname(true);
// 创建OSSClient实例。
OSSClient ossClient = new OSSClient(endpoint, accessKeyId, accessKeySecret, conf);
// 关闭OSSClient。
ossClient.shutdown();一些特殊的架构场景，比如加了一些 proxy 产品，这种情况经常会遇到瓶颈，需要分开来看，如下图是我们总结一些常用的架构。
第一种架构：
- 先确认访问到 CDN 的 URL 是否回到了 OSS ，还是直接访问 OSS 超时了。
- 如果是访问 CDN 出现超时，需要确认是某个节点还是大面积节点出现问题。可以通过 17ce 这种批量测试网站检查下。
- 如果是不同的 client 请求到同一个 CDN 节点超时，很可能 CDN 节点故障需要工单升级处理。
- 如果是访问 CDN 正常，但是固定 OSS 源站出现超时，经过不同的客户端测试都能复现证明 OSS 确实出现问题，需要工单升级处理。
如果访问 CDN 、OSS 都没有超时，很可能是 CDN 回 OSS 超时。这种回源链路超时，基本很难复现，需要升级工单快速跟进处理。
第二种架构
- 还是一样的方法，先确认是访问 CDN 、waf 、OSS 哪个产品出现的超时。定位好环节后再进行分析。
- 客户端有条件的情况下建议先查下到 WAF 的日志，或者 WAF 的回源日志确认下是否是 WAF 的问题导致超时。PS WAF 对回源 CDN 如果过于频繁会出现被拉黑的情况，目的是为了防攻击，如果出现回源 WAF 超时要升级工单确认下是否触发了防攻击的策略。
第三种架构
-
与之前比较，多了一个 proxy 的转发在用户的业务 server 和 OSS 之间。这种情况先排查 server 到 proxy 之间的链路。
- server- proxy 是否有链路抖动，ping MTR 结果都可以。
- proxy 带宽是否有被打满。
- proxy 是否有 NAT 的转换导致 OSS 建立连接 session 混乱。
- proxy 到 OSS 的链路，可以通过 ping MTR 测试。
案例：通过内网地址 wget 下载慢
- 如果 type 类型是 normal / multipart 文件读取数据是多线程的，一般情况下不会慢，如果慢的话，需要提供 requestID 升级阿里云查询下。
- 如果是 append 文件读取速度是单线程的，符合预期。
结论：
append 类型的文件是追加写，wget 下载时，服务端的 read 是单线程，所以速度提不上去。