OSS 下載延遲或超時 – 小科科的春天

作者：張醫博

基礎排查：

ping 工具，目的測試到對端的 IP 鏈路是否有丟包，RTT（Round-Trip Time）是否有大的波動。詳細命令

ping -c 100 -i 0.01 -s 1024

![1](https://yqfile.alicdn.com/a573e890357aee4205b86b68a1ce2cb431f8044f.jpeg)

mtr -n 通過 MTR 可以看到每一條的路由是否有丟包
telnet 80 端口是否能通。保證 80 是通的才能下載
提供報錯時的 OSS response header 中的 requestID 信息，一般 500 2XX 3XX 4XX 都會有 requestID 返回，504、502、503 這種網絡超時的狀態沒有 requestID

案例：DNS 解析不穩定導致 curl 延遲

分析：

通過上述信息基本可以判斷是 DNS 問題，本次 curl 的時間都不穩定，加上 DNS 解析時間後，發現是卡在了 DNS 解析上，經過溝通發現阿里雲的 DNS 223.5.5.5 在廣東的節點已經撤銷，建議使用運營商的 DNS 或者 114 的 DNS。

案例：本地機房下載 OSS 資源超時

分析：

首先理清楚自己訪問 OSS 架構是否是直接請求到 OSS 還是中間有 proxy 代理，如果有 proxy 代理的情況下先自己排查 client 到 proxy 的鏈路情況。
自己先找個其他 region 的 bucket 看下是否能否復現問題，以此排除掉是不是 OSS 的問題。
最好能夠在客戶端抓包分析一下，看看網絡上卡在哪裡導致的連接失敗。

案例：下載 socketTimeout

常見於 SDK 、API 調用時的報錯，客戶源可能是在雲主機或者 PC 端。通過文章開始所說道的信息我們判斷是是否為必現問題，如果問題必現的話很容易能定位。如果不容易出現只能分層排查。

分析：

先看下主機的 socket 資源是否足夠分配，通過可以用 netstat 或者 ss 命令來查看本機的 socket 連接數，如果主機 TCP 佔用較慢，很容易出現連接數資源不夠分配的情況
看下主機的 ulimit -n 的文件描述符是否夠用。
如果用戶使用的是 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();
一些特殊的架構場景，比如加了一些 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 測試。

案例：通過內網地址 wget 下載慢

如果 type 類型是 normal / multipart 文件讀取數據是多線程的，一般情況下不會慢，如果慢的話，需要提供 requestID 升級阿里雲查詢下。
如果是 append 文件讀取速度是單線程的，符合預期。

結論：

append 類型的文件是追加寫，wget 下載時，服務端的 read 是單線程，所以速度提不上去。