作者：張醫博
基礎排查：
- ping 工具，目的測試到對端的 IP 鍊路是否有丢包，RTT（Round-Trip Time）是否有大的波動。詳細指令
ping -c 100 -i 0.01 -s 1024
 - mtr -n 通過 MTR 可以看到每一條的路由是否有丢包
OSS 下載下傳延遲或逾時 - telnet 80 端口是否能通。保證 80 是通的才能下載下傳
OSS 下載下傳延遲或逾時 - 提供報錯時的 OSS response header 中的 requestID 資訊，一般 500 2XX 3XX 4XX 都會有 requestID 傳回，504、502、503 這種網絡逾時的狀态沒有 requestID
OSS 下載下傳延遲或逾時
案例：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 占用較慢，很容易出現連接配接數資源不夠配置設定的情況
OSS 下載下傳延遲或逾時 - 看下主機的 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 是單線程，是以速度提不上去。