【OSS 排查方案-3】OSS 的網絡排查

作者：張醫博

背景

鑒于之前遇到很多 本地-》OSS ，上傳、下載下傳總是慢的情況，或者上傳、下載下傳經常出現錯誤或者異常的問題。根據多個典型案例，抽象出一下排查方案，希望對大家快速定位問題有所幫助。

一、必要了解資訊

• requestID ，一般情況都會有，辨別此次 OSS request 到達 OSS 服務端後傳回的标志。除非建聯失敗，否則都會有這個 requestID 的，當問題比較難排查時可以将 requestID 提供給阿裡雲客服作為定位線索。
• 明确 上傳/下載下傳 的方式（阿裡的工具、SDK、API、浏覽器），不同的方式會有不同的思路，類似 JAVA SDK 如果 maxconnection 設小了，也會造成連結等待逾時。
• 使用内網還是公網，大多數我們建議在 ECS 和 OSS 同可用區時最好使用内網，這樣費用低，速度還快，公網一般出現擁塞，會被網絡無限擴大。
• 在 client 端 ping traceroute MTR 到 OSS 服務端的截圖資訊，看看到公/私網是否有丢包，或者用 tcpdump 抓包看下網絡是否有高延遲高丢包以及 TCP 協定棧異常的問題。
• 是否有明顯報錯，基本上遇到 socket timeout 的情況，都是網絡逾時，可以從本機的網絡以及本機連接配接數，或者 client 是否有逾時設定來排查。。
• 以上資訊收集到後準備測試，源 OSS URL 測試（舉例）：curl -svo /dev/null http://img.oss-cn-hangzhou.aliyuncs.com/uploads/temp/2018-01-02%20%2013-52-15-operate-stat.xls
• 如果要是 CDN -》 OSS 的問題，可以分别固定 CDN 和 OSS 源站進行測試 curl -I -x CDNIP:80 http://xxx/xxx ，固定源站 curl -I -x http://xxx.oss-cn-xxx.aliyuncs.com/xxx 如果測試 OSS 200 正常， CDN 異常，則問題可能發生在 CDN 側。

二、明确自己的服務架構逐層排查

• 本地 -》 OSS
• 本地 -》proxy -》OSSproxy 種類有很多，
• SLB
• WAF
• 高防

三、場景拟合

1、長時間或者間斷性不能通路到 OSS

這種情況，先确認一下自己 bucket 有沒有欠費，是否有被拉黑等，其次再本地的 PC 端 ping 下自己要通路的 OSS 公網域名（如果是用内網 ECS 通過私網 OSS 域名上傳，可以 ping 私網域名）是否能通，以及 traceroute 到對端 OSS 的路由路徑，看下是否斷在了哪一跳。同時請自己網外的他人協助下同時發起 ping 和

traceroute 測試，看是否同樣通路不通。如果是一樣場景，可以将搜集的資訊回報給阿裡雲客服排查服務端是否異常。

場景2、本機上傳檔案到 OSS 逾時，然後自動恢複

如圖，遇到這類問題，需要先擷取到必要資訊。然後結合圖中的 error 來看 socket 的異常，基本判斷是由于網絡問題導緻了 Header 響應逾時。側面的 MTR TRACEROUTE 也可以看出來當時的網絡品質如何，如網絡正常但依然逾時，可以直接抓包看下是哪端導緻。

場景3、使用 JAVA SDK 上傳檔案逾時傳回 502

[chat-service] 2017-12-22 11:09:17,443 - com.aliyun.oss:73 -51224385 [http-nio-9081-exec-137] WARN - [Server]Unable to execute HTTP request: The difference between the request time and the current time is too large. [ErrorCode]: RequestTimeTooSkewed [RequestId]: 5A3C77583373BA19746BB032 [HostId]: sobot.oss-cn-beijing.aliyuncs.com [ResponseError]: <?xml version="1.0" encoding="UTF-8"?> <Error> <Code>RequestTimeTooSkewed</Code> <Message>The difference between the request time and the current time is too large.</Message> <RequestId>5A3C77583373BA19746BB032</RequestId> <HostId>xxx.oss-cn-beijing.aliyuncs.com</HostId> <MaxAllowedSkewMilliseconds>900000</MaxAllowedSkewMilliseconds> <RequestTime>2017-12-22T02:53:44.000Z</RequestTime> <ServerTime>2017-12-22T03:09:12.000Z</ServerTime> </Error>
           

如圖，可以出現這種 Message ，已經明确告訴你本地與 OSS 服務端的時間差 >15min 導緻。“The difference between the request time and the current time is too large”，出現此問題，一般與以下兩個原因有關系：

1）使用者本地的時間與服務端器的時區不一緻，要求使用者本地是标準的 GMT 或者 UTC 時間。

2）網絡擁堵導緻的等待時間過長超過 15min 。

3）JAVA SDK 參數配置不合理，比如 max connection

具體處理工作流如下

場景4、OSSFTP 上傳到 OSS 時，抓包出現 zeroWindows

1、OSSFTP 是将遠端的 OSS 挂載到本地，但操作的檔案每次都是發起 HTTP 請求遠端 OSS ，是以受到網絡和本地 IO 的影響，高敏感的業務是不太适合的。

2、看資料包中用戶端發生的 ZeroWindows （代表 本地協定棧的 cache buffer 出現過滿，應用層無法消費掉 buffer 的資料）

3、通過 ECS 機器檢視自己 CPU 、内網、網卡 是否有跑滿情況，這種情況負載過高必然回導緻慢的情況。

建議：

1、由于 OSSFTP 是串行，而且是 FTPCLIET->FTPSERVER->OSS SERVER 兩段操作性能無法保證，推薦使用 ossutil ，

連結：

https://help.aliyun.com/document_detail/50452.html?spm=5176.doc31935.6.1032.YMtcGp

2、ossutil 在上傳大檔案時可以采用分片多線程的粒度上傳，而我們的 ossftp 是不存在分片的。是以還是推薦 ossutil

未完待續