UDP traffic 对 NFS performance 的影响

了解一下 UDP

前言

由於UDP ( User Datagram Protocol ) 的傳輸量大及非連接傳輸 ( Connectionless)的便捷特性，UDP 已被廣泛應用在量大及快速資料存取程式所選定的傳輸協定。其中NFS over UDP 即是最常見的一種。雖然UDP 有非連接傳輸的便捷特性但也因此在傳輸上不如 TCP ( Transmission Control Protocol ) 來的穩定，尤其是當線路不穩定或是駭客入侵時很容易讓 NFS的 Performance 大幅降低甚而癱瘓網路。本文以實例來說明UDP traffic 對 NFS Performance 的影響及偵測方法。

封包切割 ( IP Fragmentation )

在TCP/IP 中， UDP 是架構在IP上層的傳輸協定而 IP層是負責將封包經由網際網路傳至對方主機，IP傳送封包大小是決定於封包的 MTU ( Maximum Transfer Unit ) size。因此UDP 如要傳送的資料要大於 MTU size 則必須進行封包的切割(Fragmentation) 同時會在每個切割封包 ( Fragmented IP ) 註記必要的重組資料後再行傳送。接收端收到這些切割封包時會暫存於 IP input Queue， 待切割封包收齊重組後才能上傳到上層的 UDP layer。

如下圖所示，IP 的MTU size = 1500，5K 的 UDP datagram 會被切割成 4個切割封包傳送。

javascript:window.open(this.src);" style="CURSOR: pointer" onload="return imgzoom(this,550)">

對網路的Performance而言，切割封包的重組 ( IP Reassemble ) 是很耗費系統的資源， 尤其是當這些 切割封包量大而次序 ( IP order ) 錯誤或丟失時，切割封包即無法重組。這些殘缺的切割封包會佔據IP input queue的空間直到Time out 之後才會被清理丟棄 ( Fragments dropped after timeout ) 。如果這些切割封包堆積的速度超越被清理的速度時，IP input queue 的可用空間會相對減少，對網路而言無疑是壓縮了網路入口的孔道， 因此網路Performance會大幅降低。一般駭客攻擊的手法就是利用這種特性連續送出大量錯誤而無法重組的切割封包，最後讓IP input queue塞暴以達到癱瘓系統的目的。
如何偵測異常的切割封包 ?

1.首先用hp-ux 指令檢查 “fragments dropped after timeout” 的數量。 i.e.

# netstat –p ip

ip:
1226940 total packets received
0 bad header checksums
0 with size smaller than minimum
0 with data size < data length
0 with header length < data size
0 with data length < header length
0 illegal ip a address
0 ip version unsupported
513068 fragments received
0 fragments dropped (dup or out of space)
10070 fragments dropped after timeout
0 packets forwarded
0 packets not forwardable
0 redirects sent

從此例可看出 timeout 後無法重組而被清理丟棄切割封包有 10070個，此數字最好是0。如切割封包 (fragments received) 佔種總封包 ( total packets received )的20% 以上時，此數值有異常增長就要注意了。

2. 找出來源

一旦發現 fragments dropped after timeout 的數量異常增長時，可借助網路軟體找出連續送出大量錯誤而無法重組的切割封包。 例如用sniffer 軟體， 開啟收錄的檔案後點選 Decode，畫面會顯示每個 IP frame 的詳細資料然後檢視IP Summary重是否有不正常的訊息出現如:

IP: Continuation of missing frame; XXXX Bytes of data
IP: D=[ HP-2 ] S= [ PC-1] LEN=1480

這訊息表示 PC-1重複傳送 IP frame 到 HP-2。

3. 檢查切割封包的結構是否正常

確定來源後可檢查切割封包的ID， offset， flags 及protocol 等是否正確。 例如一個 UDP 要送出6968 bytes 的data時，在IP 層會被切成5 個切割封包。每個切割封包都有共同的ID。offset 是以切割封包的最後一個Byte的位址而定，因此offset 表示了切割封包的相對位置。IP 在傳送的次序是依offset 的大小由小而大依序送出。Flags為MF ( More Frame ) 表示後面還有 Fragment。 Flags為LF ( Last Fragment ) 表示是最後一筆切割封包。下例是正常的切割封包傳送。

Source Dest ID Time Length offset Flags Protocol
***** ***** ******* *********** ******* ****** ****** *******
PC-2 HP-1 46064 14:11:17:856 1480 1480 MF UDP
PC-2 HP-1 46064 14:11:17:856 1480 2960 MF UDP
PC-2 HP-1 46064 14:11:17:856 1480 4440 MF UDP
PC-2 HP-1 46064 14:11:17:857 1480 5920 MF UDP
PC-2 HP-1 46064 14:11:17:857 948 6968 LF UDP

以下是有問題的例子。IP Fragment ( ID 62297 ) 被切割成16 個切割封包， 由PC-1 傳送到HP-1。PC-1送出次序是錯誤的，前後正好顛倒。這個錯誤並不是致命的，頂多讓HP-1花費多一點Resources 重組，但重組次數多時網路Performance還是有影響。

最致命的應該是 offset 的錯誤，當 HP-1收到第一筆切割封包時，檢視它的 Flag 為LF，0ffset = 32560。表示這是最尾段的切割封包，這一組切割封包 共有32560 Bytes，但實際上HP-1僅收到 10360 Bytes – 32560 bytes 這一段資料。 因此HP-1 無法重組這些殘缺的切割封包直到Time out 之後才會被清理丟棄。但從此刻起，Dropped IP 大量增加，sniffer tools 也顯示有大量 IP frame 從 PC-1 重複傳送到 HP-2而NFS Performance 降低30% 以上。

Source Dest ID Time Length offset Flags Protocol
***** ***** ******* *********** ******* ****** ****** *******
PC-1 HP-1 62297 15:18:43:005 378 32560 LF UDP
PC-1 HP-1 62297 15:18:43:005 1480 31080 MF UDP
PC-1 HP-1 62297 15:18:43:005 1480 29600 MF UDP
PC-1 HP-1 62297 15:18:43:005 1480 28120 MF UDP
PC-1 HP-1 62297 15:18:43:006 1480 26640 MF UDP
PC-1 HP-1 62297 15:18:43:006 1480 25160 MF UDP
PC-1 HP-1 62297 15:18:43:006 1480 23680 MF UDP
PC-1 HP-1 62297 15:18:43:006 1480 22220 MF UDP
PC-1 HP-1 62297 15:18:43:006 1480 20720 MF UDP
PC-1 HP-1 62297 15:18:43:006 1480 19240 MF UDP
PC-1 HP-1 62297 15:18:43:006 1480 17760 MF UDP
PC-1 HP-1 62297 15:18:43:006 1480 16280 MF UDP
PC-1 HP-1 62297 15:18:43:006 1480 14800 MF UDP
PC-1 HP-1 62297 15:18:43:007 1480 13320 MF UDP
PC-1 HP-1 62297 15:18:43:007 1480 11840 MF UDP
PC-1 HP-1 62297 15:18:43:007 1480 10360 MF UDP

4. 排除問題

確定問題的原因後應立即對PC-1的相關程式進行問題排除或隔離。 由上例可看出這是PC-1 在切割封包 時offset 的Assignment 出現錯誤，第一筆的切割封包offset 應該從頭開始 ( offset = 1480 ) assign而非 offset = 10360。

結語

影響 NFS performance 因素很多，切割封包的錯亂只是其中的造成NFS performance降低的因素之一。本文主要以常見的駭客攻擊及網路程式所導致的網路Performance問題分享經驗。

原文转自：http://www.ltesting.net