linux網(wǎng)絡(luò)堆棧的排隊機制

《linux網(wǎng)絡(luò)堆棧的排隊機制》由會員上傳分享，免費在線閱讀，更多相關(guān)內(nèi)容在學(xué)術(shù)論文-天天文庫。

1、Linux網(wǎng)絡(luò)堆棧的排隊機制在任何網(wǎng)絡(luò)堆?；蛟O(shè)備屮，數(shù)據(jù)包的隊列都是非常重要。這些隊列使得不在同一時刻加載的模塊能夠相互通信，并且能提高網(wǎng)絡(luò)性能，同時也會間接影響到網(wǎng)絡(luò)延時的長短。本文章通過闡述IP數(shù)據(jù)包在Linux網(wǎng)絡(luò)中的排隊機制，來解釋兩個問題：>BQL—類新特性是如何減小網(wǎng)絡(luò)延時的。>如何控制已減小延時后的緩存。下面這張圖（和它的變形）將會在文屮不斷的出現(xiàn)，用以說明具體的概念。IPStackQueueingDisciplineDriverQueue-niiiiiiiiiinPJeMJO/驅(qū)動隊列（環(huán)形緩存區(qū)）驅(qū)動隊列位于IP數(shù)據(jù)棧和網(wǎng)卡之間。驅(qū)動隊列

2、使用先進先出算法，并通過環(huán)形緩存區(qū)實現(xiàn)一可以哲時把環(huán)形緩存區(qū)當(dāng)做一個固定大小的緩存器。這個隊列屮不含任何來自包（分組）的數(shù)據(jù)，直接參與排隊的是描述符（descriptor）。這些描述符指向“內(nèi)核套接字緩存”（socketkernelbuffers,簡寫為SKBs），SKB中含有在整個內(nèi)核處理過程中都要使用的數(shù)據(jù)包。Q.IlitIPStackQueueingDiscipline?nniniiBBDriverQueuePJeMJssslated進入驅(qū)動隊列的數(shù)據(jù)，來自IP數(shù)據(jù)棧，在IP數(shù)據(jù)桟里所有的IP數(shù)據(jù)包都要進行排隊。這S數(shù)據(jù)包可以從本地獲得，當(dāng)某個網(wǎng)卡在

3、網(wǎng)絡(luò)中充當(dāng)路由器時，數(shù)據(jù)包也可以從網(wǎng)卡上接收，找到路巾后再發(fā)出去。從IP數(shù)據(jù)棧中進入驅(qū)動隊列的數(shù)據(jù)包，先由硬件使之出列，再通過數(shù)據(jù)總線發(fā)送到網(wǎng)卡上，以進行傳輸。驅(qū)動隊列的用處在于，只要系統(tǒng)有數(shù)據(jù)需要傳輸時，數(shù)據(jù)能夠馬上被傳送到網(wǎng)卡進行及吋傳輸。大致意思就是，驅(qū)動隊列給ZIP數(shù)據(jù)棧?-個排隊的地方，通過硬件來對數(shù)據(jù)進行不同時的排隊。實現(xiàn)這個功能的另一種做法是，只要當(dāng)物理傳輸媒介準備好傳輸數(shù)裾時，網(wǎng)卞?便馬上向IP數(shù)據(jù)棧申請數(shù)據(jù)。但是因為對IP數(shù)據(jù)找的數(shù)據(jù)申請，不可能馬上得到相應(yīng)，所以這種辦法會浪費掉大量寶貴的傳輸資源，使吞吐量相應(yīng)地降低。還有另-?種正好相反

4、的辦法一在IP數(shù)據(jù)棧準各好要傳輸?shù)臄?shù)據(jù)包后，進行等待，直到物理傳輸媒介做好傳輸數(shù)據(jù)的準備為止。但是這種做法同樣也不理想，因為在等待時IP數(shù)據(jù)棧被閑置，沒有辦法做別的工作。棧中的超大數(shù)據(jù)包多數(shù)網(wǎng)卡都有最大傳輸單位(MTU)，川來表示能夠被物理媒介傳輸?shù)淖畲髱瑪?shù)。以太網(wǎng)的默認MTU為1500字節(jié)，也有一些支持JumboFrames的以太網(wǎng)MTU能夠達至U9000多字節(jié)的。在IP數(shù)據(jù)棧中，MTU同時也是數(shù)據(jù)包傳輸?shù)臉O限大小。比如，有個應(yīng)用需要向TCP接口傳送2000字節(jié)的數(shù)據(jù)，這時，IP數(shù)據(jù)棧就必須創(chuàng)建兩個數(shù)據(jù)包來傳送它，因為單個MTU小于2000字節(jié)。所以在進

5、行較大數(shù)據(jù)的傳輸時，MTU如果相對較小，那么大量數(shù)據(jù)包就會被創(chuàng)建出來，并且它們都要在物理媒介上傳輸?shù)津?qū)動隊列屮。為了避免因為MTU大小限制而出現(xiàn)的大量數(shù)據(jù)包，Linux內(nèi)核對傳輸大小進行了多項優(yōu)化：TCP段裝卸(TCPsegmentationoffload,簡稱TSO),UDP碎片裝卸⑴DPfragmentationoffload,簡稱UFO)和類型化段裝卸(genericsegmentationoffload,簡稱GSO)。這些優(yōu)化辦法，使得IP數(shù)據(jù)棧能夠創(chuàng)建比MTU更大的數(shù)據(jù)包。對于IPv4來說，優(yōu)化后能夠創(chuàng)建出S大含65536的數(shù)據(jù)包，并且這些數(shù)據(jù)包

6、和MTU大小的數(shù)據(jù)包一樣能夠進入驅(qū)動隊列排隊。在使用TSO和UFO優(yōu)化時，由網(wǎng)卡將較大的數(shù)據(jù)包拆分成能夠傳輸?shù)男?shù)據(jù)包。對于沒有該硬件拆分功能的網(wǎng)卡，GSO優(yōu)化能夠通過軟件來實現(xiàn)相同的功能，在數(shù)據(jù)包進入驅(qū)動隊列前迅速完成數(shù)據(jù)包拆分。我在前面提過，驅(qū)動隊列中能包含描述符的數(shù)量是一定的(但描述符可以指向不同大小的數(shù)據(jù)包)。所以，TSO,UFO和GSO等優(yōu)化措施將數(shù)據(jù)包增大，也不完全是件好事，因力這些優(yōu)化也會使驅(qū)動隊列中進行排隊的字節(jié)數(shù)增大了許多。圖像3是一個與圖像2的對比圖。SKBSKBIPStackQueueingDiscipline?OHiinnBDriv

7、erQueueNICPJeMJOjsSWMd雖然接下來我要將重點放在傳輸路徑(transmitpath)上了，但是這里還是要再強調(diào)一下，Linux在數(shù)據(jù)接收端同樣有類似TSO、UFO和GSO的優(yōu)化措施。這些接收端優(yōu)化措施同樣也能將每個數(shù)據(jù)包的大小限制增大。具體來說，類型接收裝卸(genericreceiveoffload,簡稱GRO)使網(wǎng)卡能夠?qū)⒔邮盏降娜舾蓴?shù)據(jù)包合并成一個大數(shù)據(jù)包后，再傳給IP數(shù)據(jù)棧。在傳送數(shù)據(jù)包吋，GRO能將原始數(shù)據(jù)包重組，使之符合IP數(shù)據(jù)包首尾連接的屬性。GRO同樣也會帶來副作用：較大的數(shù)據(jù)包在傳送時，可能會被拆分成了若干較小的數(shù)據(jù)包

8、，這時，就會有多個數(shù)據(jù)包在同-?數(shù)據(jù)流中同吋進行排隊。較大的數(shù)據(jù)包