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 看下每一跳的延遲
• mtr 看下公網鍊路是否有丢包。
• 當時異常方法都查不到原因隻能使用終極辦法 tcpdump 、或者 Wireshark 抓包。

tcpdump -i <出口網卡> -s0 host -w slow_packet.pacp