淺談UDP

UDP數據包長度

UDP數據包的理論長度

udp數據包的理論長度是多少,合適的udp數據包應該是多少呢?從TCP-IP詳解卷一第11章的udp數據包的包頭可以看出,udp的最大包長度是2^16-1的個字節。由于udp包頭占8個字節,而在ip層進行封裝后的ip包頭占去20字節,所以這個是udp數據包的最大理論長度是2^16-1-8-20=65507。

然而這個只是udp數據包的最大理論長度。首先,我們知道,TCP/IP通常被認為是一個四層協議系統,包括鏈路層、網絡層、運輸層、應用層。UDP屬于運輸層,在傳輸過程中,udp包的整體是作為下層協議的數據字段進行傳輸的,它的長度大小受到下層ip層和數據鏈路層協議的制約。

MTU相關概念

以太網(Ethernet)數據幀的長度必須在46-1500字節之間,這是由以太網的物理特性決定的。這個1500字節被稱為鏈路層的MTU(最大傳輸單元)。因特網協議允許IP分片,這樣就可以將數據包分成足夠小的片段以通過那些最大傳輸單元小于該數據包原始大小的鏈路了。這一分片過程發生在網絡層,它使用的是將分組發送到鏈路上的網絡接口的最大傳輸單元的值。這個最大傳輸單元的值就是MTU(Maximum Transmission Unit)。它是指一種通信協議的某一層上面所能通過的最大數據包大小(以字節為單位)。最大傳輸單元這個參數通常與通信接口有關(網絡接口卡、串口等)。

在因特網協議中,一條因特網傳輸路徑的“路徑最大傳輸單元”被定義為從源地址到目的地址所經過“路徑”上的所有IP跳的最大傳輸單元的最小值。

需要注意的是,loopback的MTU不受上述限制,查看loopback MTU值:

[root@bogon ~]# cat /sys/class/net/lo/mtu

65536

IP分包udp數據包長度的影響

如上所述,由于網絡接口卡的制約,mtu的長度被限制在1500字節,這個長度指的是鏈路層的數據區。對于大于這個數值的分組可能被分片,否則無法發送,而分組交換的網絡是不可靠的,存在著丟包。IP 協議的發送方不做重傳。接收方只有在收到全部的分片后才能 reassemble并送至上層協議處理代碼,否則在應用程序看來這些分組已經被丟棄。

假定同一時刻網絡丟包的概率是均等的,那么較大的IP datagram必然有更大的概率被丟棄,因為只要丟失了一個fragment,就導致整個IP datagram接收不到。不超過MTU的分組是不存在分片問題的。

MTU的值并不包括鏈路層的首部和尾部的18個字節。所以,這個1500字節就是網絡層IP數據報的長度限制。因為IP數據報的首部為20字節,所以IP數據報的數據區長度最大為1480字節。而這個1480字節就是用來放TCP傳來的TCP報文段或UDP傳來的UDP數據報的。又因為UDP數據報的首部8字節,所以UDP數據報的數據區最大長度為1472字節。這個1472字節就是我們可以使用的字節數。

當我們發送的UDP數據大于1472的時候會怎樣呢?這也就是說IP數據報大于1500字節,大于MTU。這個時候發送方IP層就需要分片(fragmentation)。把數據報分成若干片,使每一片都小于MTU。而接收方IP層則需要進行數據報的重組。而更嚴重的是,由于UDP的特性,當某一片數據傳送中丟失時,接收方便無法重組數據報。將導致丟棄整個UDP數據報。因此,在普通的局域網環境下,將UDP的數據控制在1472字節以下為好。

進行Internet編程時則不同,因為Internet上的路由器可能會將MTU設為不同的值。如果我們假定MTU為1500來發送數據的,而途經的某個網絡的MTU值小于1500字節,那么系統將會使用一系列的機制來調整MTU值,使數據報能夠順利到達目的地。鑒于Internet上的標準MTU值為576字節,所以在進行Internet的UDP編程時,最好將UDP的數據長度控件在548字節(576-8-20)以內。

UDP丟包

udp丟包是指網卡接收到數據包后,linux內核的tcp/ip協議棧在udp數據包處理過程中的丟包,主要原因有兩個:

1、udp數據包格式錯誤或校驗和檢查失敗。

2、應用程序來不及處理udp數據包。

對于原因1,udp數據包本身的錯誤很少見,應用程序也不可控,本文不討論。

首先介紹通用的udp丟包檢測方法,使用netstat命令,加-su參數。

# netstat -su

Udp:

2495354 packets received

2100876 packets to unknown port received.

3596307 packet receive errors

14412863 packets sent

RcvbufErrors: 3596307

SndbufErrors: 0

從上面的輸出中,可以看到有一行輸出包含了"packet receive errors",如果每隔一段時間執行netstat -su,發現行首的數字不斷變大,表明發生了udp丟包。

下面介紹一下應用程序來不及處理而導致udp丟包的常見原因:

1、linux內核socket緩沖區設的太小# cat /proc/sys/net/core/rmem_default

# cat /proc/sys/net/core/rmem_max

可以查看socket緩沖區的缺省值和最大值。

rmem_default和rmem_max設置為多大合適呢?如果服務器的性能壓力不大,對處理時延也沒有很嚴格的要求,設置為1M左右即可。如果服務器的性能壓力較大,或者對處理時延有很嚴格的要求,則必須謹慎設置rmem_default 和rmem_max,如果設得過小,會導致丟包,如果設得過大,會出現滾雪球。

2、服務器負載過高,占用了大量cpu資源,無法及時處理linux內核socket緩沖區中的udp數據包,導致丟包。

一般來說,服務器負載過高有兩個原因:收到的udp包過多;服務器進程存在性能瓶頸。如果收到的udp包過多,就要考慮擴容了。服務器進程存在性能瓶頸屬于性能優化的范疇,這里不作過多討論。

3、磁盤IO忙

服務器有大量IO操作,會導致進程阻塞,cpu都在等待磁盤IO,不能及時處理內核socket緩沖區中的udp數據包。如果業務本身就是IO密集型的,要考慮在架構上進行優化,合理使用緩存降低磁盤IO。

這里有一個容易忽視的問題:很多服務器都有在本地磁盤記錄日志的功能,由于運維誤操作導致日志記錄的級別過高,或者某些錯誤突然大量出現,使得往磁盤寫日志的IO請求量很大,磁盤IO忙,導致udp丟包。

對于運維誤操作,可以加強運營環境的管理,防止出錯。如果業務確實需要記錄大量的日志,可以使用內存log或者遠程log。

4、物理內存不夠用,出現swap交換

swap交換本質上也是一種磁盤IO忙,因為比較特殊,容易被忽視,所以單列出來。

只要規劃好物理內存的使用,并且合理設置系統參數,可以避免這個問題。

5)磁盤滿導致無法IO

沒有規劃好磁盤的使用,監控不到位,導致磁盤被寫滿后服務器進程無法IO,處于阻塞狀態。最根本的辦法是規劃好磁盤的使用,防止業務數據或日志文件把磁盤塞滿,同時加強監控,例如開發一個通用的工具,當磁盤使用率達到80%時就持續告警,留出充足的反應時間。

UDP收包能力測試

測試環境

處理器:Intel(R) Xeon(R) CPU X3440 @ 2.53GHz,4核,8超線程,千兆以太網卡,8G內存

模型1

單機,單線程異步UDP服務,無業務邏輯,只有收包操作,除UDP包頭外,一個字節數據。

測試結果

現象:

1、單機UDP收包處理能力可以每秒達到150w左右。

2、處理能力隨著進程個數的增加而增強。

3、在處理達到峰值時,CPU資源并未耗盡。

結論:

1、UDP的處理能力還是非?？捎^的。

2、對于現象2和現象3,可以看出,性能的瓶頸在網卡,而不在CPU,CPU的增加,處理能力的上升,來源于丟包(UDP_ERROR)個數的減少。

模型2

其他測試條件同模型1,除UDP包頭外,一百個字節數據。

測試結果

現象:

1、100個字節的包大小,比較符合平常的業務情形。

2、UDP的處理能力還是非?？捎^,單機峰值可以到達每秒75w。

3、在4,8個進程時,沒有記錄CPU的占用情況(網卡流量耗盡),不過可以肯定的是,CPU未耗盡。

4、隨著進程個數的上升,處理能力沒有明顯提升,但是,丟包(UDP_ERROR)的個數大幅下降。

模型3

單機,單進程,多線程異步UDP服務,多線程共用一個fd,無業務邏輯,除UDP包頭外,一個字節數據。

測試結果:

現象:

1、隨著線程個數的增加,處理能力不升反降。

結論:

1、多線程共用一個fd,會造成相當大的鎖爭用。

2、多線程共用一個fd,當有包來時,會激活所有的線程,導致頻繁的上下文切換。

最終結論:

1、UDP處理能力非?？捎^,在日常的業務情形中,UDP一般不會成為性能瓶頸。

2、隨著進程個數的增加,處理能力未明顯上升,但是丟包個數明顯下降。

3、本次測試過程中,瓶頸在網卡,而不在CPU。

4、采用多進程監聽不同端口的模型,而不是多進程或多線程監聽同一個端口。

總結