天天看点

OSS “RequestTimeTooSkewed“RequestTimeTooSkewed时间标准排查代码排查主机问题是有经过网络代理

RequestTimeTooSkewed

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

OSS “RequestTimeTooSkewed“RequestTimeTooSkewed时间标准排查代码排查主机问题是有经过网络代理

时间标准

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

OSS “RequestTimeTooSkewed“RequestTimeTooSkewed时间标准排查代码排查主机问题是有经过网络代理

排查代码

- 如果是用阿里云的 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 可以发现有抖动和丢包。

OSS “RequestTimeTooSkewed“RequestTimeTooSkewed时间标准排查代码排查主机问题是有经过网络代理

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

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

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

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