作者：張醫博
客戶端的循環冗餘校驗和服務端不一致，可以上傳成功
排查
出現類似問題，需要先收集信息，經常發生在 Java sdk 上傳的過程中。
- requestID 出現 checksum 不一致的情況一定會伴隨有 requestID 信息。
- 上傳方式是通過 SDK 還是自己調 API 上傳，需要明確 SDK 的版本信息。
- 問題能否穩定復現，能復現最好提供網絡抓包便於問題分析。
- tcpdump -i <出口網卡> -s0 host -w checksum.pcap
分析：
- 收集到 requestID 後，先升級到阿里雲確認是否已經上傳成功，一般 checksum 不一致並不會導致上傳失敗， checksum 是對文件進行循環冗餘計算的方法，和 MD5 不一樣，如果 MD5 不一致，文件上傳一定失敗。如果日誌記錄上傳成功，可以校驗文件的 MD5 是否一致，如果一致的話請忽略 checksum 不一致的情況。
- 出現 checksum 不一致的情況和網絡以及系統主機都有關係，先通過網絡抓包分析下，客戶端發起 request header 中的 crc64 是否和 requestID 查到的 crc64，如果一致的話說明用戶上傳網絡傳輸中被篡改了，如果不一致的話說明客戶本地寫入到內存後就出現問題。
- 如果用戶本地計算寫入到內存和服務端的不一致，需要用戶在本地代碼中進行 debug ，在上傳請求發起前，先打印出 crc64 記錄到本地，看看與 SDK 計算的是否一致，確保文件在上傳前不要有其他進行在佔用，或者讀寫。如果本地計算的 crc64 和 SDK 一致 說明不是計算問題，而是寫入到內存後出現了問題，說明是客戶端的系統導致的異常。
建議：
- 如果出現 checksum 不一致，但是文件 MD5 一致的話客戶可以將 crc64 關掉，替換成 MD5 的校驗方式，在 header 增加 Content-MD5 頭，MD5 值要全部大寫，然後在 base64 編碼。
- Java SDK 關閉 crc64 的方法
關閉 crc 的方法如下：
https://help.aliyun.com/document_detail/32010.html?spm=a2c4g.11186623.6.702.5bb84b4eKVgJfk
String endpoint = "<yourEndpoint>";
String accessKeyId = "<yourAccessKeyId>";
String accessKeySecret = "<yourAccessKeySecret>";
ClientConfiguration conf = new ClientConfiguration();
conf.setCrcCheckEnabled(false);
// 創建OSSClient實例。
OSSClient ossClient = new OSSClient(endpoint, accessKeyId, accessKeySecret, conf);- 使用 https 協議上傳，將 endpoint 協議頭改為 https 即可，看下更換為 https 協議後問題是否還能復現。