報文控制的方法和裝置與流程

本申請涉及通信技術(shù)領(lǐng)域，尤其涉及報文控制的方法和裝置。

背景技術(shù)：

防火墻是一種常用的網(wǎng)絡(luò)安全設(shè)備，為了達到防治攻擊、保護網(wǎng)關(guān)的目的，防火墻入口流量一般都需要送到CPU(Central Processing Unit，中央處理器)進行分析處理，但由于PCI(Peripheral Component Interconnect，外設(shè)部件互連標準)接口帶寬的限制，通常設(shè)計HIGig接口來滿足大流量數(shù)據(jù)的收發(fā)，同時會關(guān)閉PCI接口的收發(fā)使能，可參考圖1a，業(yè)務(wù)報文和管理報文從MAC(Media Access Control，交換芯片)的不同端口進入，通過ACL(Access Control List，訪問控制列表)規(guī)則引流到HIGig接口并發(fā)送CPU，HIGig接口有7個用于發(fā)送報文的隊列，cos0至cos7，在處理過程中，業(yè)務(wù)報文和管理報文默認從同一隊列cos0轉(zhuǎn)出，會導致以下問題：

當流量過大時，管理報文會被丟棄，造成設(shè)備無法管理。

技術(shù)實現(xiàn)要素：

為克服相關(guān)技術(shù)中存在的問題，本申請?zhí)峁┝藞笪目刂频姆椒ê脱b置。

根據(jù)本申請實施例的第一方面，提供一種報文控制的方法，所述方法包括：

接收報文，所述報文攜帶接收所述報文的端口的標識；所述端口包括用于接收管理報文的管理端口和用于接收業(yè)務(wù)報文的業(yè)務(wù)端口；

基于所述標識判斷所述報文的類型；

如果所述報文為管理報文，則從第一隊列發(fā)送所述管理報文至CPU；如果所述報文為業(yè)務(wù)報文，則從第二隊列發(fā)送所述業(yè)務(wù)報文至CPU；所述第一隊列的優(yōu)先級高于第二隊列的優(yōu)先級。

根據(jù)本申請實施例的第二方面，提供一種報文控制的裝置，所述裝置包括：

接收模塊，被配置為接收報文，所述報文攜帶接收所述報文的端口的標識；所述端口包括用于接收管理報文的管理端口和用于接收業(yè)務(wù)報文的業(yè)務(wù)端口；

判斷模塊，被配置為基于所述標識判斷所述報文的類型；

發(fā)送模塊，被配置為如果所述報文為管理報文，則從第一隊列發(fā)送所述管理報文至CPU；如果所述報文為業(yè)務(wù)報文，則從第二隊列發(fā)送所述業(yè)務(wù)報文至CPU；所述第一隊列的優(yōu)先級高于第二隊列的優(yōu)先級。

本申請的實施例提供的技術(shù)方案可以包括以下有益效果：

將管理報文和業(yè)務(wù)報文分別從不同隊列發(fā)送，可以避免流量過大、隊列出口擁塞導致的管理報文被隨機丟棄的現(xiàn)象，并且優(yōu)先發(fā)送管理報文，保證管理報文被優(yōu)先處理，確保設(shè)備可以管理。

應(yīng)當理解的是，以上的一般描述和后文的細節(jié)描述僅是示例性和解釋性的，并不能限制本申請。

附圖說明

圖1a是相關(guān)技術(shù)中一種報文發(fā)送的場景圖。

圖1b是本申請實施例一種報文被丟棄的場景圖。

圖2是本申請根據(jù)一示例性實施例示出的一種報文控制的方法的部分流程圖。

圖3是本申請根據(jù)一示例性實施例示出的另一種報文控制的方法的部分流程圖。

圖4是本申請根據(jù)一示例性實施例示出的一種報文控制的流程圖。

圖5a是本申請根據(jù)一示例性實施例示出的一種報文控制的裝置的框圖。

圖5b是本申請根據(jù)一示例性實施例示出的另一種報文控制的裝置的框圖。

具體實施方式

這里將詳細地對示例性實施例進行說明，其示例表示在附圖中。下面的描述涉及附圖時，除非另有表示，不同附圖中的相同數(shù)字表示相同或相似的要素。以下示例性實施例中所描述的實施方式并不代表與本申請相一致的所有實施方式。相反，它們僅是與如所附權(quán)利要求書中所詳述的、本申請的一些方面相一致的裝置和方法的例子。

在本申請使用的術(shù)語是僅僅出于描述特定實施例的目的，而非旨在限制本申請。在本申請和所附權(quán)利要求書中所使用的單數(shù)形式的“一種”、“所述”和“該”也旨在包括多數(shù)形式，除非上下文清楚地表示其他含義。還應(yīng)當理解，本文中使用的術(shù)語“和/或”是指并包含一個或多個相關(guān)聯(lián)的列出項目的任何或所有可能組合。

應(yīng)當理解，盡管在本申請可能采用術(shù)語第一、第二、第三等來描述各種信息，但這些信息不應(yīng)限于這些術(shù)語。這些術(shù)語僅用來將同一類型的信息彼此區(qū)分開。例如，在不脫離本申請范圍的情況下，第一信息也可以被稱為第二信息，類似地，第二信息也可以被稱為第一信息。取決于語境，如在此所使用的詞語“如果”可以被解釋成為“在……時”或“當……時”或“響應(yīng)于確定”。

如圖1a所示，圖1a是本申請實施例一種報文發(fā)送的場景圖。防火墻10包括交換芯片(MAC)101和中央處理器(CPU)102。交換芯片101的一側(cè)包括業(yè)務(wù)端口1011和管理端口1012，用于分別接收不同類型的報文，其中，業(yè)務(wù)端口1011用于接收交換機20發(fā)送的業(yè)務(wù)報文，管理端口1012用于接收管理設(shè)備(或監(jiān)控設(shè)備)30發(fā)送的管理報文，其中，業(yè)務(wù)報文和管理報文分別攜帶業(yè)務(wù)端口1011和掛你端口1012的端口號。為滿足大流量的需求，相關(guān)技術(shù)中設(shè)計HIGig接口1013來發(fā)送業(yè)務(wù)報文和管理報文，同時關(guān)閉PCI接口1014的收發(fā)使能。業(yè)務(wù)報文和管理報文在進入交換芯片101后，通過ACL規(guī)則引流到HIGig接口1013，并通過HIGig接口1013的某一隊列發(fā)送至中央處理器102。HIGig接口1013有7個可以發(fā)送報文的隊列，cos0至cos7，通常，管理報文和業(yè)務(wù)報文默認是從同一隊列cos0發(fā)送。如圖1b所示，業(yè)務(wù)報文和管理報文在經(jīng)過隊列cos0時，可能會由于數(shù)據(jù)量大造成隊列出口擁塞，導致管理報文被MAC硬件隨機丟棄；當報文進入CPU時，由于流量過大，CPU使用率達到上限，處理能力不足，也會導致報文被CPU硬件或軟件丟棄，經(jīng)過多個環(huán)節(jié)后，管理報文大部分被丟棄，導致設(shè)備無法管理。

本申請將管理報文和業(yè)務(wù)報文分別從不同隊列發(fā)送，可以避免流量過大、隊列出口擁塞導致的管理報文被隨機丟棄的現(xiàn)象；并且設(shè)置管理報文的優(yōu)先級高于業(yè)務(wù)報文的優(yōu)先級，可以優(yōu)先發(fā)送管理報文，使得管理報文被優(yōu)先處理，確保設(shè)備可以管理。接下來對本申請進行詳細說明。

如圖2所示，圖2是本申請根據(jù)一示例性實施例示出的一種報文控制的方法，可以應(yīng)用在MAC上，所述方法可以包括以下步驟S201至S203：

在步驟S201中，接收報文，所述報文攜帶接收所述報文的端口的標識；所述端口包括用于接收管理報文的管理端口和用于接收業(yè)務(wù)報文的業(yè)務(wù)端口。

在步驟S202中，基于所述標識判斷所述報文的類型。

在步驟S203中，如果所述報文為管理報文，則從第一隊列發(fā)送所述管理報文至CPU；如果所述報文為業(yè)務(wù)報文，則從第二隊列發(fā)送所述業(yè)務(wù)報文至CPU；所述第一隊列的優(yōu)先級高于第二隊列的優(yōu)先級。

MAC用于接收報文的端口包括業(yè)務(wù)端口和管理端口，其中，業(yè)務(wù)端口用于接收業(yè)務(wù)報文，管理端口用于接收管理報文。業(yè)務(wù)報文的報頭和管理報文的報頭分別攜帶業(yè)務(wù)端口和管理端口的端口號，該端口號作為端口的標識，也可以用來區(qū)分報文的類型。在本申請的實施例中，通過報文的報頭所攜帶的端口號將報文區(qū)分為管理報文和業(yè)務(wù)報文，并將管理報文和業(yè)務(wù)報文分別從HIGig接口的不同隊列發(fā)送至CPU。

HIGig接口包括7個隊列，cos0至cos7。從cos0到cos7，隊列的優(yōu)先級逐漸升高，優(yōu)先級高則相應(yīng)隊列的報文會優(yōu)先發(fā)送。本申請的實施例中，將管理報文從第一隊列發(fā)送，業(yè)務(wù)報文從第二隊列發(fā)送，且第一隊列的優(yōu)先級高于第二隊列的優(yōu)先級，可以保證管理報文被優(yōu)先發(fā)送、優(yōu)先處理。作為一個例子，第一隊列可以是cos7，第二隊列可以是默認隊列cos0，或者其他隊列，比如cos1。

其中，發(fā)送管理報文和業(yè)務(wù)報文的隊列可以通過ACL規(guī)則或QOS預先配置。比如，配置管理報文從cos7發(fā)送，業(yè)務(wù)報文從cos1發(fā)送，用戶可以通過ACL規(guī)則配置管理報文的優(yōu)先級為7(其中報文的優(yōu)先級與隊列的優(yōu)先級一一對應(yīng)，配置報文的優(yōu)先級即配置該報文從相應(yīng)優(yōu)先級的隊列發(fā)送)，配置業(yè)務(wù)報文的優(yōu)先級為1即可。當然用戶也可以通過QOS分別配置管理報文和業(yè)務(wù)報文的優(yōu)先級。ACL規(guī)則和QOS的具體配置方法相關(guān)領(lǐng)域的技術(shù)人員可以參考相關(guān)技術(shù)得知。

如圖3所示，圖3是本申請根據(jù)一示例性實施例示出的另一種報文控制方法的部分流程圖，所述方法在圖2所示方法的基礎(chǔ)上還可以包括步驟S204至S205：

在步驟S204中，檢測是否有軟件丟包或硬件丟包；所述軟件丟包為CPU軟件處理過程中丟棄業(yè)務(wù)報文，所述硬件丟包為交換芯片MAC硬件處理過程中丟棄業(yè)務(wù)報文。

在步驟S205中，基于檢測結(jié)果調(diào)節(jié)第二隊列的帶寬。

相關(guān)技術(shù)中，發(fā)送報文的帶寬固定，無法滿足大流量的需求，也不能保證CPU的使用率。本申請的實施例在將管理報文和業(yè)務(wù)報文分別從不同隊列發(fā)送后，基于業(yè)務(wù)報文發(fā)送過程中是否有軟件丟包或硬件丟包來調(diào)節(jié)發(fā)送業(yè)務(wù)報文的隊列的帶寬，可以滿足大流量收發(fā)的情況下，在不丟包的同時提高CPU的使用率。其中，硬件丟包是指流量過大時，受發(fā)送業(yè)務(wù)報文的隊列的帶寬限制，導致出口擁塞，業(yè)務(wù)報文被MAC硬件丟棄。軟件丟包是指CPU軟件在處理業(yè)務(wù)報文的時候，由于CPU軟件處理能力不足(CPU使用率達到上限)，導致業(yè)務(wù)報文被丟棄。其中，是否有硬件丟包可以通過MAC中的寄存器統(tǒng)計丟包數(shù)據(jù)獲得，是否有軟件丟包可以通過CPU統(tǒng)計丟包數(shù)據(jù)獲得。

在一個可選的實施例中，所述基于檢測結(jié)果調(diào)節(jié)第二隊列的帶寬，可以包括以下任意一種：

如果有軟件丟包，則按照預設(shè)的時間間隔和調(diào)節(jié)粒度減小第二隊列的最大帶寬保證值；

如果有硬件丟包且無軟件丟包，則按照預設(shè)的時間間隔和調(diào)節(jié)粒度增大第二隊列的最大帶寬保證值；

如果沒有軟件丟包和硬件丟包，則不調(diào)節(jié)。

通常，正常處理業(yè)務(wù)報文的過程中不會出現(xiàn)丟棄數(shù)業(yè)務(wù)文的現(xiàn)象，但是，當流量過大時，會出現(xiàn)硬件丟包或軟件丟包。因此，可以根據(jù)丟包情況動態(tài)調(diào)節(jié)隊列帶寬，在減少丟包同時提高CPU的使用率。

如果沒有軟件丟包和硬件丟包，則說明CPU使用率未達到上限且隊列帶寬足夠，則不作調(diào)節(jié)。

如果有軟件丟包，則說明CPU使用率達到上限，需要按照預設(shè)的時間間隔和粒度減小第二隊列的最大帶寬保證值，減少上傳至CPU的業(yè)務(wù)報文，降低CPU的使用率，以減少軟件丟包。

如果有硬件丟包且無軟件丟包，則說明CPU使用率未達到上限，且業(yè)務(wù)報文受到出口隊列帶寬的限制，為了進一步提高CPU的使用率，可以增大最大帶寬保證值，以增大帶寬，直到開始出現(xiàn)少量軟件丟包。當出現(xiàn)軟件丟包時，再按照上一個步驟減小最大帶寬保證值，從而動態(tài)調(diào)節(jié)隊列的帶寬，保證在不丟包的情況下提高CPU的使用率。

在一個可選的實現(xiàn)方式中，時間間隔可以由用戶預先設(shè)置。時間間隔過大可能會調(diào)整不及時，導致CPU使用率達到上限，造成業(yè)務(wù)報文被丟棄；時間間隔過小會可能會由于頻繁檢測CPU使用率、調(diào)節(jié)帶寬而增加CPU的負擔。因此，時間間隔設(shè)置要合理，作為一個例子，該時間間隔可以是秒級，比如1秒。

在一個可多選的實現(xiàn)方式中，帶寬的調(diào)節(jié)粒度也可以預先設(shè)置。如果帶寬的調(diào)節(jié)粒度過大可能會導致流量突然增加，超過CPU的處理能力，比如，當CPU使用率已經(jīng)接近上限但未到達上限時，突然大幅度增加帶寬可能會導致CPU使用率超過上限，導致業(yè)務(wù)報文丟包；帶寬調(diào)節(jié)的粒度過小，可能會由于變化細微導致CPU無法感知。因此，調(diào)節(jié)粒度的設(shè)置也要合理，作為一個例子，調(diào)節(jié)粒度可以是1M。

通過動態(tài)調(diào)節(jié)發(fā)送業(yè)務(wù)報文的隊列的帶寬，可以使CPU保持最優(yōu)的報文處理能力，在不丟棄業(yè)務(wù)報文的情況下盡可能提高CPU的使用率。

圖4是本申請根據(jù)一示例性實施例示出的一種報文控制的流程圖，如圖4所示，首先通過ACL規(guī)則預先配置報文的發(fā)送隊列，MAC接收到報文后，區(qū)分報文類型，按照預先配置將管理報文和業(yè)務(wù)報分別cos7、cos0發(fā)送。在管理報文和業(yè)務(wù)報文發(fā)送至CPU后，根據(jù)軟件丟包和硬件丟包情況動態(tài)調(diào)節(jié)隊列cos0的帶寬，如下：

如果既沒有軟件丟包，也沒有硬件丟包，則不調(diào)節(jié)；

如果有軟件丟包，則每隔1秒減小cos0的帶寬1M；

如果有硬件丟包，并且沒有軟件丟包，則每隔1秒增加cos0的帶寬1M。

與前述報文控制的方法的實施例相對應(yīng)，本申請還提供了報文控制的裝置的實施例。

請參考圖5a，圖5a是本申請根據(jù)一示例性實施例示出的一種報文控制的裝置50的框圖，所述報文控制的裝置50包括：

接收模塊51，被配置為接收報文，所述報文攜帶接收所述報文的端口的標識；所述端口包括用于接收管理報文的管理端口和用于接收業(yè)務(wù)報文的業(yè)務(wù)端口。

判斷模塊52，被配置為基于所述標識判斷所述報文的類型。

發(fā)送模塊53，被配置為如果所述報文為管理報文，則從第一隊列發(fā)送所述管理報文至CPU；如果所述報文為第業(yè)務(wù)報文，則從第二隊列發(fā)送所述業(yè)務(wù)報文至CPU；所述第一隊列的優(yōu)先級高于第二隊列的優(yōu)先級。

在一個實施例中，所述管理報文和業(yè)務(wù)報文的發(fā)送隊列通過以下任意一種方式預先配置：

通過訪問控制列表ACL規(guī)則配配置；或，

通過服務(wù)質(zhì)量QoS配置。

如圖5b所示，圖5b是本申請根據(jù)一示例性實施例示出的一種報文控制的裝置的框圖，在圖5a所述實施例的基礎(chǔ)上，所述裝置50還可以包括：

檢測模塊54，被配置為在發(fā)送所述管理報文和業(yè)務(wù)報文至CPU后，檢測是否有軟件丟包或硬件丟包；所述軟件丟包為CPU軟件處理過程中丟棄業(yè)務(wù)報文，所述硬件丟包為交換芯片MAC硬件處理過程中丟棄業(yè)務(wù)報文。

調(diào)節(jié)模塊55，被配置為基于檢測結(jié)果調(diào)節(jié)第二隊列的帶寬。

在一個可選的實現(xiàn)方式中，調(diào)節(jié)模塊55，具體用于：

如果有軟件丟包，則按照預設(shè)的時間間隔和調(diào)節(jié)粒度減小第二隊列的最大帶寬保證值；

如果有硬件丟包且無軟件丟包，則按照預設(shè)的時間間隔和調(diào)節(jié)粒度增大第二隊列的最大帶寬保證值；

如果沒有軟件丟包和硬件丟包，則不調(diào)節(jié)。

上述裝置中各個單元的功能和作用的實現(xiàn)過程具體詳見上述方法中對應(yīng)步驟的實現(xiàn)過程，在此不再贅述。

對于裝置實施例而言，由于其基本對應(yīng)于方法實施例，所以相關(guān)之處參見方法實施例的部分說明即可。以上所描述的裝置實施例僅僅是示意性的，其中所述作為分離部件說明的單元可以是或者也可以不是物理上分開的，作為單元顯示的部件可以是或者也可以不是物理單元，即可以位于一個地方，或者也可以分布到多個網(wǎng)絡(luò)單元上?？梢愿鶕?jù)實際的需要選擇其中的部分或者全部模塊來實現(xiàn)本申請方案的目的。本領(lǐng)域普通技術(shù)人員在不付出創(chuàng)造性勞動的情況下，即可以理解并實施。

以上所述僅為本申請的較佳實施例而已，并不用以限制本申請，凡在本申請的精神和原則之內(nèi)，所做的任何修改、等同替換、改進等，均應(yīng)包含在本申請保護的范圍之內(nèi)。