对象存储 OSS 上传、下载发生 "便秘"
再复杂的网络架构和环境中经常遇到各种各样的网络超时问题，OSS 作为很多企业用户的源站经常会遇到下 GET 、PUT 慢的情况，问题就像便秘一样纠缠，作为存储，很多客户端把矛头指向了 OSS ，鉴于情况众多，我们今天具体分析一下都有哪些种便秘堵塞了你的生活。
确认基础信息
- ping 工具，目的测试到对端的 IP 链路是否有丢包，RTT（Round-Trip Time）是否有大的波动。详细命令
ping -c 100 -i 0.01 -s 1024 <IP>
- mtr -n <OSS domain> 通过 MTR 可以看到每一条的路由是否有丢包。
- telnet <OSS domain> 80 端口是否能通。保证 80 是通的才能下载
- 提供报错时的 OSS response header 中的 requestID 信息，一般 500 2XX 3XX 4XX 都会有 requestID 返回，504、502、503 这种网络超时的状态没有 requestID
"便秘" 分类
-
sockettimeout
常见于 SDK 、API 调用时的报错，客户源可能是在云主机或者 PC 端。通过文章开始所说道的信息我们判断是是否为必现问题，如果问题必现的话很容易能定位。如果不容易出现只能分层排查。
- 1、先看下主机的 socket 资源是否足够分配，通过可以用 netstat 或者 ss 命令来查看本机的 socket 连接数，如果主机 TCP 占用较慢，很容易出现连接数资源不够分配的情况
- 2、看下主机的 ulimit -n 的文件描述符是否够用。
- 3、如果用户使用的是 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();
- 4、一些特殊的架构场景，比如加了一些 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 测试。
-
-
