網絡 vs 應用程式：如何還網絡一個清白

眾所周知，網絡存在的意義之一在於支援應用程式所需功能、為企業創造商業價值。因此，每當應用程式變慢、數據傳輸不暢或網絡通話斷線時，總有用戶抱怨「一定是網絡出了問題！」
網絡管理員從未否認這一點，因為他們深知影響應用程式效能的網絡因素包括 WAN 頻寬不足、非業務流量頻寬佔用、高延遲、服務質素優先次序不當或缺乏、連線不穩定、網絡裝置運行健康狀況或設定錯誤等。然而，應用程式效能欠佳的主要原因還可能是其本身設計不當所致：應用程式元素過多或內容過大、繁瑣且每個用戶要求建立多項連接、緩慢而耗時的查詢、記憶體流失、執行需鎖定或可能減慢擷取的數據庫結構損壞等等。若向應用程式開發者反映情況，他們大多會指摘數據庫管理員（索引問題、SAN 共享輸入/輸出、多應用程式的潛在儲存空間、數據庫損壞等）。此外，也不應忽略硬件及操作系統的因素。伺服器負荷過重、缺乏可用磁碟空間、磁碟效能欠佳、TCP 視窗尺寸設定錯誤、多項背景工作以及操作系統陳舊等硬件問題亦可能拖慢應用程式的速度。

網絡是否應承擔影響應用程式效能的一半責任？除非能證明網絡的清白，否則仍然勝負未分。那麼應如何還網絡一個清白？

「網絡慢過蝸牛。」

面對抱怨，網絡管理員應利用 SNMP 為網絡討回公道。啟動網絡監控工具，然後檢查網絡裝置的健康狀況及運行狀態。SNMP 工具能提供大量實用資訊。使用 SNMP 監控路由器及交換器，檢查是否存在連線不穩定、封包遺失、RTT 及延遲增加，並檢查裝置 CPU 或記憶體使用率是否過高。

「WAN 連結無法處理應用程式？」

Cisco IPSLA 會發送綜合封包，報告使用 TCP 及 UDP 協議處理 IP 流量的網絡連結的功能或準備狀態，或報告具體的網絡電話效能及 RTT等。因此，如果 Cisco IPSLA 產生的綜合封包與應用程式協議相符，那麼何不從實際應用程式流量身上尋找原因？
「頻寬夠用嗎？」透過專門的頻寬檢測工具，路由及交換裝置上的 NetFlow 數據可以報告頻寬的使用情況，從而顯示WAN 連結的當前使用量、使用頻寬的應用程式以及所涉及的端點，甚至報告每段 IP 交談的服務類型 (ToS) 的優先次序。

「是否與服務質素優先次序有關？」

採用支援 Cisco CBQoS 報告的監控工具驗證服務質素政策的效能、政策前後數據、是否緩衝過多，或每個服務質素政策及類別所耗費的流量。如果服務質素政策正常運作，那還有什麼原因呢？

「下一步？」

對於有興趣深入研究的管理員，不妨進行深度封包檢查 (DPI)。DPI 可提供幾乎無限的透明度：輸送量資訊、故障區段詳情、訊號交換詳情、重新傳輸以及證明並非網絡問題及尋找應用程式效能欠佳實際原因的一切所需資訊。

使用適當的技術及工具，網絡管理員可以還網絡一個清白。但同樣重要的是應主動保證重要網絡節點已採用適當的監控工具進行監控，並且保證關鍵的應用程式享有優先網絡使用權。實施監控有助發現問題及防患於未然；優先次序則能確保應用程式數據傳送順暢。

鳴謝：Don Thomas Jacob

Don Thomas Jacob 為 SolarWinds（總部位於德克薩斯州奧斯丁市的 IT 管理軟件供應商）極客達人。加入 SolarWinds 之前，曾擔任技術支援工程師、產品網誌寫手、產品推廣員以及技術市場主管，擁有近 8 年工作經驗。Don 的興趣方向是網絡效能監控、網絡安全、DPI 和封包分析、NetFlow、sFlow 及 IPFIX 等基於流的科技，以及 QoS、NBAR、IPSLA、Cisco Medianet 及 MediaTrace 等科技，並在這些領域擁有豐富的經驗。