OSS線上業務突發回調失敗

問題描述

客戶回報線上業務大量回調失敗，具體報錯如下。但客戶回報本地去測試向回調服務發起請求，回調服務是可以正常接收請求的，但回調伺服器上找不到OSS發起的回調日志。

com.aliyun.oss.OSSException：Error status ：502

[ErrorCode]: CallbackFailed

[RequestId]: 6131E16DA8654B3338371A32

[HostId]: xxx.oss-cn-shenzhen.aliyuncs.com

問題排查

1. 初步分析

根據報錯來看，502錯誤一種可能是回調服務直接響應了502，另一種可能是OSS向回調服務位址發起回調時候直接連不上或者會阻斷，導緻沒有走到七層。初步判斷是OSS到回調伺服器之間的網絡問題。

2. 基調探測

在

阿裡網站運維監測平台

發起基調探測，探測客戶的回調位址，發起有很多地區都存在連不上的請求，請求被reset （connection reset by peer）。從探測結果來看，也懷疑是回調伺服器的問題。

3. 抓包确認

本地模拟測試發一個post請求到客戶回調服務确實是正常的，沒有複現到問題。是以嘗試到基調平台上抓包，同時由于阿裡網站運維檢平台目前暫時不支援抓包，是以先考慮用第三方基調"聽雲"平台去探測抓包。因為OSS用的深圳區域，是以直接在聽雲上用深圳三大營運商去發起探測，發現也是存在部分請求被重置（reset）的情況。

抓包分析發現有以下幾個點

（1）21、25、26三個包是三次握手包，25号是回調伺服器的握手sync包，通告的win視窗居然是0。

（2）三次握手成功以後，28号包直接發了reset包，從封包看這是服務端發了reset包。

（3）從TTL看，服務端握手sync包(25号)包 的TTL是119，服務端reset包(28号)包的TTL也是119，說明這種現象不太可能是劫持行為。因為如果不是服務端發的reset包，而是被網絡鍊路的其他節點劫持以後發的reset包，那麼TTL不會剛好也是119。基于以上，基本上可以确認是回調伺服器的原因造成的。

問題原因

經過确認，原因是客戶自己回調伺服器的EIP有自帶DDoS的防護功能，防護門檻值是固定的，比如200Mb（入帶寬）。在客戶業務量上漲後，客戶擴容了帶寬，但DDoS 通路門檻值沒有跟着調整，導緻業務量上漲後觸發了DDoS防護機制，開始流量清洗。這次是Sync 通路的清洗，服務端通過回Sync+Ack+Win=0來阻斷這次應用連結。

适用産品

對象存儲OSS