遊戲 Lag 白皮書 › L5 資料中心網路設備
DDoS 防護導流與誤判 DDoS scrubbing latency, false positives
原因 ID dc-ddos · 主要負責 基礎設施團隊（網路基礎設施） · 協同 遊戲開發團隊（伺服器開發）
在含圖解與實驗的完整版中開啟卡片 →
為了擋下攻擊而把流量導向清洗中心時，路徑會變長，有時還會把正常使用者誤判為攻擊而封鎖。
為什麼 偵測到攻擊後（或常態性地）把進來的流量導向清洗中心 → 於是 路徑變長，部分正常封包被判定為攻擊 → 畫面上 整體 ping 上升，只有特定地區／電信業者連不上
- 症狀
- 輸入延遲, 連不上／無限讀取, 瞬移
- 因素
- 延遲, 遺失
- 誰會遇到
- 整個伺服器, 特定地區／電信業者
- 何時
- 人潮湧入時, 偶爾隨機發生
- 負責單位
- 主要負責 基礎設施團隊（網路基礎設施） · 協同 遊戲開發團隊（伺服器開發）
- 遊戲開發團隊要做的事
- 整理遊戲流量模式（port、封包大小、每秒封包數）並提供給基礎設施團隊，UDP 封包維持在 1,200 位元組以下。
- 基礎設施團隊要做的事
- 制定符合遊戲流量模式的防護規則，設置各地區的清洗據點，在通道區段縮小 TCP 封包大小（MSS 調整），以各地區、各電信業者的連線失敗率確認是否誤判。
- 數值參考
- 清洗據點在同一個國家時增加數 ms，經過其他國家的據點時會增加 30～100ms 以上。通常只有進來的方向會繞道，伺服器的回應則直接送出。若清洗後的流量透過通道送回，一次能傳送的大小（MTU）也會變小，有時會演變成只有大封包消失的問題。
- 圖表上
- 從某個時間點起階梯式上升 · RTT（ping）、各地區／電信業者的連線失敗率
- 查看位置
- 把防護設備或服務的導流（清洗）開始與結束紀錄、封鎖 log，與 RTT 圖表、各地區與電信業者的連線失敗率放在同一條時間軸上比對。在問題地區用 mtr、traceroute 確認路徑中是否夾著清洗據點
- 符合的跡象
- 導流開啟的時間點 RTT 升高一階並維持，關閉後恢復。或封鎖 log 中出現正常玩家的位址，且只有該地區、該電信業者的連線失敗率上升
- 不符合的跡象
- 沒有導流、封鎖紀錄的時段 RTT 仍升高時，是「繞遠路的路由」或「BGP 路由變更與收斂」。只有大封包消失時是「MTU 不一致（只有大封包消失）」
- 確認方式
- 用基礎設施工具確認（不需要遊戲程式碼）
出處
- Maximum transmission unit and maximum segment size Cloudflare
進來的流量清洗後經 GRE 通道（MTU 1,476）轉交，出去的回應直接走網際網路（DSR），建議把 TCP MSS 限制在 1,436 以下，不調整的話大封包會被丟棄或分段 - Azure network round-trip latency statistics Microsoft Azure
依據點位置的往返延遲規模：首爾–釜山地區 8ms、首爾–東京 30ms、首爾–新加坡 68ms
相關原因
同一層：L5 資料中心網路設備
同一症狀（輸入延遲）在其他層的原因
查看含圖解與實驗的完整版卡片