即時通訊延遲高怎麼排查？從網路、伺服器端到用戶端的分層定位步驟

即時通訊延遲高，先不要急著重啟服務或切換網路。延遲發生在不同階段，對應的排查對象完全不同。把使用者回饋的「慢」拆成四個現象：連線建立慢、第一個位元組回傳慢、傳送到送達慢、訊息顯示慢；再比對用戶端和伺服器端日誌時間戳記，基本能定位到網路層、伺服器端或用戶端。本文按分層順序給出可執行步驟和判斷標準。如果使用者回饋的是訊息傳不出去，排查方向不同，可參考訊息傳送失敗的系統化排查。

先定位層級：用時間戳記和現象分流

關鍵時間戳記有四個：用戶端傳送時間 t1、伺服器端接收時間 t2、伺服器端投遞時間 t3、用戶端接收時間 t4。如果 t2-t1 明顯偏大，優先查網路層；t3-t2 偏大，問題在伺服器端訊息處理；t4-t3 偏大，回程網路或用戶端接收緩衝有問題；用戶端真正顯示時間 t5 與 t4 間隔大，說明是 UI 執行緒渲染卡頓。不能只看一端日誌，至少取傳送端和接收端兩側日誌比對，否則很容易把伺服器端處理慢誤判成網路封包遺失。

使用者回饋的「慢」最好也按現象歸類：連線建立慢通常發生在 DNS、TCP/TLS 階段；第一個位元組回傳慢是伺服器端處理慢；傳送到送達慢可能是伺服器端推播鏈路或長連線問題；訊息顯示慢則多為用戶端渲染。先花一分鐘把現象綁到時間戳記上，後面的排查才不會跑偏。

網路層排查：連線建立與長連線狀態

1. DNS 解析：使用 mtr 或 dig 查看解析耗時。如果網域解析超過 200ms，先更換公用 DNS 或檢查本機快取與 hosts 設定。
2. TCP/TLS 握手：透過 ss -ti 查看連線狀態和 RTT，或使用 tcpdump 抓封包查看 SYN/ACK 時間差。握手耗時超過 300ms 通常表示鏈路品質或伺服器端 accept 佇列有問題。
3. 丟包與重傳：在測試環境使用 tc 模擬弱網，觀察 retrans 欄位。重傳率持續高於 1% 會直接放大訊息延遲，需要排查鏈路或調整重傳策略。
4. 長連線心跳：WebSocket 或私有長連線的心跳間隔建議不超過 30 秒。心跳過大會遭 NAT 設備提前回收，表現為間歇性延遲或假死連線。

伺服器端排查：從接取層到推播鏈路

• 接取層連線數：檢查長連線閘道或接取層的連線數是否觸頂、accept 佇列是否積壓。netstat -s 裡的 listen overflow 是常見訊號。
• 訊息路由耗時：查看伺服器端收到訊息到投遞的耗時，P95 如果超過 200ms，需要追蹤訊息佇列、路由邏輯和執行緒集區飽和度。
• 儲存與快取：慢查詢、訊息落庫、群組成員擴散都可能成為瓶頸。大型群組一次寫擴散容易造成延遲尖刺，應改為批次或非同步處理。
• 離線推播：離線訊息透過推送通道下發，推送服務本身的延遲經常被算進 IM 延遲裡。需要單獨對推送鏈路計時。離線訊息收不到通常是另一類問題，可參考離線訊息總是遺失的常見原因與修復。

伺服器端需要重點觀察的指標包括：訊息處理耗時 P95、佇列積壓數量、GC 停頓時間、CPU 突刺。CPU 偶發 100% 不一定有問題，但若與延遲尖刺同時出現，就要繼續往下拆。

用戶端排查：區分網路等待與渲染卡頓

1. 比對用戶端日誌中收到訊息的時間 t4 和真正上螢幕時間 t5。如果 t5-t4 超過 100ms，優先懷疑 UI 執行緒卡頓，而不是網路或伺服器端。
2. 暫時關閉動畫、清單重用、大圖載入等模組，觀察是否改善。如果改善，表示渲染或主執行緒任務過多，需要最佳化佈局和圖片解碼。
3. 在弱網模擬下比對同一訊息在多個用戶端上的表現。如果只有單一裝置延遲，基本可排除伺服器端問題。

用戶端顯示延遲但伺服器端日誌正常時，繼續向前追用戶端接收緩衝和 UI 排程，不要反過來把網路撥測結果當成結論。

驗證與回退：單一變數修改和基線記錄

每次只改一個變數。變更前記錄 P50/P95 延遲基線，變更後至少觀察一個完整業務週期。如果 P95 沒有下降超過 10%，或者 P50 反而變差，立即回退該變更。不要同時調整網路、伺服器端和用戶端參數，否則即使恢復了，也無法確定真正有效的動作。回退條件要預先寫好，避免在壓力下繼續疊加修改。