跳轉到

D-20260728-03｜UGC 混合下載與伺服器流量邊界

背景與驅動力

client 線上資產源目前只走 Helia／Bitswap，PinningProvider.getGatewayUrl() 與規格既有的 HTTP Gateway 後援沒有接進 production 載入。討論伺服器成本時也混淆了 bootstrap 發現、 relay 轉送與內容供應：找到官方 peer 不代表所有後續 UGC 流量都會經官方伺服器。

考慮過的選項

  • 只走官方 Gateway：可預測但把分散下載退化為中央頻寬支出——否決。
  • 永遠只走 Bitswap：最大化分散，卻在初期 peer 稀少或查找失敗時沒有可用性底線——否決。
  • 強制 Bitswap 排除官方 peer：可壓官方成本，但會降低初期可用性且增加路由複雜度——暫不採。
  • 本機快取、玩家／社群 Bitswap 優先，短 timeout 後轉 HTTP Gateway——採納。

決定

UGC 讀取依序走本機快取、玩家／社群 Bitswap、已設定 HTTP Gateway；所有路徑共用 CID、 大小上限與 sanitizer 驗證。Bootstrap／DHT 只發現 peer，不承載內容；只有官方直接供應 Bitswap、充當 Circuit Relay 或回應 Gateway 時才形成官方伺服器流量。初期先以分來源 metrics 與 relay 容量限制觀察，不增加 Bitswap 的官方 peer 排除規則。現況契約見 pinning-service與PinningProvider。

後果與影響

正常流量仍優先分散在玩家與社群，官方只作可用性保底；短 timeout 增加一次 fallback 延遲， 但避免無限等待。每條路徑共用驗證可防 HTTP 後援形成安全旁路。client 實作與來源 metrics 分別追蹤於 issue 000047、000048。