通訊延遲注入如何量測系統的逾時與重試反應

先說清楚延遲加在哪一段

把網路延遲設定成一百毫秒後，系統沒有逾時，不一定是逾時功能失效。延遲可能只加在請求方向，也可能沒有涵蓋實際連線。先畫出客戶、注入點、伺服器與回覆路徑，再量測真正的請求到回覆時間，才能判斷系統反應。

選擇測試邊界：應用程式延後回覆、網路模擬器延後封包，或通訊設備實際變慢。三者能測的現象不同。應用程式睡眠不會完整模擬網路分段與重傳，網路封包延遲也不等於RS485位元時序變化，報告要寫明範圍。

本文適用於隔離環境的資料通訊測試，以Linux netem官方手冊說明延遲注入概念，不提供直接修改正式網卡的命令。工具版本、方向、流量範圍與移除方式先確認，避免測試流量以外的工程連線也被拖慢。

先定義逾時從哪一刻開始：請求排入佇列、實際送出、連線建立或等待回覆。不同層可能各有計時器。若上位總逾時先到，底層仍在重試，就可能出現畫面失敗而設備稍後完成，不能只看其中一個設定值。

無注入時先量請求回覆基準，教學假設單次約二十毫秒。若在單次簡化請求回覆的兩個方向各增加四十毫秒，總時間約一百毫秒；若只加一個方向，約六十毫秒。這只是路徑算例，實際分段、排程與處理可能增加額外時間。

假設應用逾時二百毫秒，先測明顯低於、接近與高於門檻的延遲。接近門檻時允許觀察競爭與抖動，但通過標準要事先定義，不能把剛好二百毫秒全部硬判成同一結果。用實際單調經過時間判斷，不只讀工具設定。

每次記錄命令識別、送出時間、回覆到達、逾時觸發、重試開始與最終結果。回覆可能已到主機但尚未被應用處理，網路擷取時間與應用完成時間不完全相同，兩層都保留才能分辨是網路或程式排程延遲。

完成後應能畫出每次嘗試的時間線，看到逾時是否在契約時間範圍內發生、是否只發生一次，以及遲到回覆如何處理。只統計最後成功率，會看不到中間重試風暴與錯誤的重複動作。

測試中持續確認注入確實命中指定流量。若流量改走備援路由或本機快取，表面上設定仍在，實際請求可能完全沒被延後。用獨立觀測與版本紀錄證明注入位置，不以工具視窗顯示啟用就當成已生效。

教學策略為首次加兩次重試，共三次嘗試，每次最多等待二百毫秒，兩次重試之間各等五十毫秒。若每次都完整逾時，簡化等待總量為七百毫秒，尚未加排程與其他處理。不要把「重試兩次」誤算成總共兩次。

若還有連線逾時、佇列等待與上位期限，總時間要逐層列出。有些重試策略在同一總期限內分配時間，有些每次重置期限，行為不同。先確認實作與需求，再用案例檢查，不能只把所有設定數字相加就宣稱最長耗時。

多個來源同時逾時時，重試可能同步擠向伺服器。測試固定延遲後，再測變動延遲與不同起始時點，觀察佇列、請求率與恢復速度。退避與隨機分散可作策略，但須依系統需求驗證，不以無限等待取代失敗處理。

讀取與寫入分開。讀取重試通常不應有業務副作用，但寫入可能已接受只是回覆晚到。對設定、累加與啟動命令分別定義確認與防重複方式，不能因網路延遲測試需要就對真實設備連續送動作命令。

同一命令重試沿用業務識別，每次傳輸有各自嘗試紀錄。收到第一個嘗試的遲到回覆時，應能匹配原命令而不干擾下一筆。若工具只看目前等待的請求，延遲案例很容易暴露回覆配錯的問題。

Linux netem可模擬延遲與變動，但精度受核心計時、排程與佇列等條件影響。封包層的設定不一定等於每次業務交易相同的增加量；要量實際分布，並記錄工具、核心、拓撲與流量特徵。

先只注入延遲，保留其他條件不變，再另做丟包或重排案例。若一開始全部混合，難以判斷逾時是延遲超標、重傳還是工具佇列滿。組合故障可以後續測，但每一項單獨基準要先建立。

失敗時先查逾時計時起點與單位，再查注入方向、實際路由、快取與遲到回覆。若逾時遠超設定，查前置佇列與多層重試；若沒有逾時卻資料變舊，查應用是否每次重試都錯誤更新資料確認時間。

案例結束後移除測試配置，量測延遲回到基準，檢查待處理請求、重試排程與暫存命令。只關閉工具視窗不保證核心或閘道設定已恢復。若恢復不完全，保留未完成狀態並按流程處理，不進行下一個混雜案例。

練習：首次加一次重試，每次等待三百毫秒，中間退避一百毫秒，兩次都逾時時簡化總等待七百毫秒。若上位總期限五百毫秒先到，應記錄上位已結束但底層是否仍在運行，並核對是否有明確取消或結果追蹤。

另測同一筆請求在期限前與期限後到達，確認結果不重複發布、遲到回覆不配給下一筆。具體時差應大於量測解析度並符合案例目的，避免用無法觀測的一微秒差異聲稱完成邊界驗證。

問：注入一百毫秒就代表往返多一百嗎？答：先看方向、路徑與請求組成，再量實際時間。

問：逾時後重送一定安全嗎？答：寫入可能已執行，需依命令語意確認。

問：應用延後回覆等於網路延遲嗎？答：注入層不同，可驗證的行為也不同。

問：最後成功就算通過嗎？答：還需核對重試數、時間、品質與是否產生重複副作用。