OSS “RequestTimeTooSkewed“

RequestTimeTooSkewed

- 经常遇到，但是原因比较多，分析难以下手，具体的表象可以看下面的截图，由于客户端（下文称之为 client）发出的请求时间和实际上服务端（下文称之为 oss） 收到的时间差大雨 15min 导致（oss Time - client Time > 15min） 

时间标准

- 先排除掉最简单的问题，确认时间是否为标准的 UTC、GMT、CST 时间，如果时区不是东八区，只要换算成 +8 小时一致即可。有的人可能使用自己的 NTP 时钟同步出现异常，导致 client 和 oss 收到时间相差 15min

排查代码

- 如果是用阿里云的 OSS SDK 的话，先检查下 OSS SDK 初始化链接数是多大，client 的并非请求是否已经超过了 SDK 的设置。

以下用 JAVA SDK 为例子默认的 maxconnect 是 1024 。在本机执行 netstat 命令看下 client 程序对应的 TCP 链接数有没有超过 1024。

排查主机问题

- 使用 netstat 命令看下主机的 TCP 链接数（UDP TCP） 有没有超过 ulimit 的设置。

- 查看主机出口的网络带宽有没有被打满

是有经过网络代理

- client 是直传到 OSS ，还是经过 proxy 传输到 OSS ，如果有代理先要排查 client 到 proxy 链路是否有抖动丢包重传，以及 proxy 到 OSS 的链路。

- proxy 如果链接数或者带宽被打满都会造成上传延迟、拥堵，导致 RequestTimeTooSkewed

排查网络问题

如果使用阿里云的 ECS 建议走内网的 internal 形式的域名操作 OSS 这个是阿里云内部网络，性能很稳定速度也很快，如果走公网的话并不是很可靠。

走公网的情况就需要做测试了。

- 如果 client 到 OSS 是走公网上传下载，发生 RequestTimeTooSkewed 问题时，可以同步 ping -c 50 -i 0.01 -s 1024 通过 ping 可以发现有抖动和丢包。

- traceroute <OSS域名>  看下每一跳的延迟

- mtr <OSS域名> 看下公网链路是否有丢包。

- 当时异常方法都查不到原因只能使用终极办法 tcpdump 、或者 Wireshark 抓包。

tcpdump -i <出口网卡> -s0 host <OSS域名> -w slow_packet.pacp