2019-M03 關於 Idempotent 兩三事 早上朋友丟了問我關於解決 idempotent 的問題 原因在於他那邊最近常常發現 存錢的 POST API 在 Server 端常常收到兩次的 Bug 這類型的問題常常發生在 Mobile + API 自動 retry 因為 Mobile 的特性 : 使用 WiFi 會因為移動導致斷線、自動重新連線 導致第一個 POST API 沒有收到正常的回傳值 而自動 retry 因此在很多 POST 等相關 API 都會加上 IDEMPOTENT 參數來避免重送攻擊 概念上很簡單：在 POST 的時候 Client 會帶上一個 IDEMPOTENT 如果 Server 端收到來自同一個 IDENPOTENT 的請求 第二次之後的操作視為 NOP 如果來自不同使用者 但 IDENPOTENT 相同的情況 則回傳 collision 錯誤 因此找到一個不會碰撞的 IDENPOTENT 的產生方式就極為重要 ---- 以下是本文重點 ---- 強者我朋友提出了 UUID[0] 的方式 也就是隨機產生一組 128bit 的隨機字串 但是他的長官認為 是否會有 collision 的狀況 ... 因此廢物我提出了一個 ULID[1] 解決方案用來解釋他很難發生 collision 在 ULID 的 SPEC 下定義使用 128bit 長度：前面 48bit 用來表示時間、後面 80bit 則為隨機 時間戳記本身為 ms 等級計算 因次發生 collision 的前提之一就是要在同一毫秒 而後者 80bit 的隨機數字則假設遭遇到生日攻擊法[2] 使用速算法來計算 collision 發生機率為百萬分之一 (~ 2^-20) 約需要 2^30。大概是 1ms 需要有一億次請求 #謹獻給強者我朋友的長官# [0]: https://tools.ietf.org/html/rfc4122.html [1]: https://github.com/ulid/spec [2]: https://en.wikipedia.org/wiki/Birthday_attack --

※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 106.1.229.215 (臺灣) ※ 文章網址: https://webptt.com/m.aspx?n=bbs/NetSecurity/M.1573698400.A.0F8.html