➤ Flowmon-因應網路效能下降的三項指標

在我20多年的職業生涯中,我與二種技術人員合作過。 一種是使用各種行銷手法來傳達其價值而未能實現其價值的人,以及在一天內迅速證明自己的技術能力的。 使用流量數據來進行網路效能監控就是第二種類型。 在這篇文章中,我將分享我對網路效能監控(NPM)技術的經驗,如何實際應用以及網路流量效能瓶頸的主因為何。

作為網路工程師,我個人KPI的總是以MTTR(平均修復時間)來衡量。 每當用戶遇到與網路相關的問題時,我需要能幫助我快速找出事件的根本原因的技術。 經驗告訴我,想要有效完成,只能透過清楚了解L2-L7層的流量特性才能做到。 流量數據(NetFlow / IPFIX)透過訊號往返時間(Round Trip Time ,RTT)、伺服器回應時間(Server Response Time ,SRT)和基時誤差(Jitter)這些網路效能監控指標,來提供對於網路狀況的理解。 讓我們來看看他們在低效能和網路停擺的困境中是多麼有益和互補。

網路性能監控基礎

網路效能監控是一種透過測量效能指標,來釐清網路流量效能問題根本原因的方法。 這些指標可區分數據傳輸問題(網路延遲)和應用程序問題,而確切的影響範圍及證據,讓我們知道可以聯絡哪個團隊或同事並要求他們解決事件。

兩種適合從旁觀察網路流量的主要指標:

  • 訊號往返時間(Round Trip Time ,RTT數據封包由客戶端傳輸到伺服器並返回的數據傳輸時間。 也稱為網路延遲。 它是通過觀察建立TCP對話(Session)所需的時間(監視TCP Handshake)來計算的。 此度量標準僅適用於TCP流量。
  • 伺服器回應時間(Server Response Time ,SRT) – 應用程序伺服器在接收的客戶端請求封包,並將回應封包發送到客戶端所產生的時間。 簡單地說,此度量標準是計算TCP ACK(確認封包)與回應第一個數據封包之間的時間差。 同樣,此度量標準(有一些例外)僅適用於TCP流量。
Fig1 Network Performance Metrics measurement principle

1.ROUND TRIP TIME

對比網路效能的數值。 企業在一個地點當地網路的基本數值會小於1ms(甚至幾十微秒)。例如, 在數據中心中,封包不需要長途旅行(和/或)網路設備造成額外的延遲。 那麼,如果您體驗到數百毫秒的RTT,這意味著什麼呢? 在這種情況下,根本原因始終是網路。 應用程序對TCP Handshake沒有影響,因為這是操作系統本身進行TCP / IP堆疊的一部分。在實際狀況中, 它無法要求操作系統停止服務來影響此測量指標。 以下是此類情況下的一些典型案例。
網路設備過載,尤其是路由器​

高數據封包流動率會讓需要等待分派的封包,影響網路設備中的緩衝區。 QoS可以在一定程度上幫助確定關鍵服務的優先順序,但若遇到DDoS攻擊可能仍會導致網路擁塞和RTT值增加。

客戶由遠端進行工作

抱怨緩慢的應用程序回應可能並非都是此問題。 當從家裡通過VPN連接到公司數據中心時,RTT為500ms意味著只需傳輸封包需要半秒鐘,不過從用戶的角度來看,任何應用程序都會看起來很慢。

雲端應用程序

這種情況非常類似於客戶在家工作的情況。 對於託管在公司數據中心的應用程序,RTT為10毫秒,當我們遷移到雲端後卻無法預料的。 在標準情況下,應用程序的流量通過Internet,產生100毫秒的RTT是合理的結果。 這就是為什麼SaaS(軟體即服務)供應商使用內容傳遞網路(CDN)和代理伺服器,儘可能靠近客戶託管應用程序以減少網路延遲的原因。 出於同樣的原因,大型企業購買專線將其基礎設施直接連接到雲端提供商。 在對雲端應用程序流量進行基準化時,我們可以觀察到RTT中的偏差,這通常意味著網路效能下降超出了應用程序供應商的規範.

Ethernet vs. WiFi

很多人可能都會說連接WiFi導致比連接有線更多的網路延遲。 但這是真的嗎? 真正的區別是什麼? 根據我的實際經驗,有線乙太網連接和WiFi之間通常的性能差異大約是10ms。 所以10ms是使用WiFi而不是使用有線網路連接時獲得的平均延遲。這是在談論理想的條件。 實際上,當WiFi與環境條件劣化時,我們可以觀察到更高的值和顯著的偏差,例如:WiFi環境中有其他相同頻率的熱點干擾。

異質端口(heterogeneous port)

速率導致的效能瓶頸這種情況有點特別。 想像一下10G主幹,而伺服器通過1G port連接,特別是當多個伺服器共享這樣的1G上行鏈路時。 許多客戶端可以輕鬆生成高於1G port 容量的流量,使Switch緩衝區飽和,進而導致數據封包丟失。 造成需要重傳遺失的封包,並且連續地讓用戶經歷網路延遲。

Fig 2 Round Trip Time peak in network traffic visualisation (Flowmon GUI)

2.SERVER RESPONSE TIME

此度量標準表示伺服器端的請求處理時間,因此表示應用程序本身引起的延遲。測量的伺服器回應時間表示伺服器ACK封包的預測觀察時間(基於預測客戶端請求的觀察時間和先前測量的RTT值)與伺服器回應的實際觀察時間之間的時間差。此度量標準不能僅依賴觀察來自伺服器的ACK封包,因為ACK封包可能與伺服器的回應合併。將ACK封包與第一回應封包一起發送,而導致SRT為0值時,這也不是我們想要測量的值。 SRT度量標準不限於TCP流量,也可以測量一些UDP流量。 Flowmon提供DNS流量的SRT量測。不論port 53是來源端口(伺服器)還是目標端口(客戶端)。測量的伺服器回應時間表示客戶端請求的觀察時間與伺服器回應之間的時間差。

SRT能對應整個應用程序、每個應用程序伺服器、每個客戶端網路範圍甚至單個客戶端的效能量測。這樣可以找出應用程序效能狀況與客戶端或一天中特定時間之間的相關性。將此指標與RTT一起使用可以找到最終解答。這是網路問題還是應用程序問題?

Fig 3 Server Response Time peak visualisation (Flowmon GUI)

3.JITTER – 數據封包之間延遲的變化

Jitter可以通過計算封包之間各個延遲的差異來顯示封包流的不規則性。 在理想情況下,各個封包之間的延遲是一個常數值,這意味著Jitter為0.測量的延遲值沒有變化。 但實際上,由於各種參數可能會影響數據流,因此不會出現Jitter值為0的情況。 我們為什麼要測量Jitter呢? Jitter至關重要,對評估實際應用的真實狀況具有重要價值,例如電話會議和視頻流。 在檔案下載時,例如 從鏡像下載Linux發行版ISO文件,基時誤差可能表示網路連接不穩定。

Fig 4 Jitter peak visualisation (Flowmon GUI)

SUMMARY

根據我的經驗,那些使用網路效能監控指標的網路管理員可以顯著提高網路效能,並有助於改進應用程序。他們的用戶以及公司管理層已經注意到這樣的網路管理員並感受更好的用戶體驗。網路效能監控指標的持續監控和基準可幫助網路管理員識別網路本身、特定連接或應用程序中的問題。在用戶作業之前告知問題並避免對效能下降所產生的抱怨,這是很有價值的。長期監控網路效能指標(RTT,SRT,Jitter)有助於預測未來需求(容量規劃)和事件,例如,數週內公司資訊系統的SRT升高,意味著應該在SLA被破壞之前解決應用伺服器過載的問題。像是我們可以為應用程序增加額外的資源,或引入具有負載平衡的多伺服器體系結構。

理解RTT、SRT以及JItter,絕對值得每個負責任的網路專業人士使用。這三者是不可或缺的,但這不是唯一需要注意的。另一個有趣的性能指標稱為重傳,我將在下次解釋。如果您想了解網路性能指標在Flowmon中的工作方式,請與台灣代理商聯絡。