一種網絡擁塞處理方法及裝置與流程

本發明實施例涉及計算機網絡技術，尤其涉及一種網絡擁塞處理方法及裝置。

背景技術：

隨著網絡大數據的不斷發展，由于網絡擁塞導致系統服務器卡死的情況時常出現。

當路由器中存在大量數據流時，頻繁網絡軟中斷的系統CPU(Central Processing Unit，中央處理器)的占用率可能會達到100％，由于軟中斷的級別比普通應用進程的級別高，導致路由器本地房屋得不到執行。

針對上述問題，目前常用的解決方式有：一、以太網驅動支持NAPI調度的方式。該方法在網絡數據量大時，可縮短輪詢處理包的頻率或者每次輪詢處理包的個數，避免軟中斷耗盡CPU資源。但是，該方法在網絡擁塞時不能選擇性丟包，導致關鍵業務數據包丟失，同時，網絡數據量適中時，會出現軟中斷與輪詢兩種調度方式的頻繁切換，影響系統性能。二、應用QOS(Quality of Service，服務質量)限定接口帶寬的方式。該方法可限定總帶寬的大小，也可根據業務需要進行選擇性丟包，但是TC流量控制方式本身耗費大量CPU，且在當CPU緊張時會導致隊列運算不準確，并失去對數據流的控制，當不能壓制總帶寬時，會加劇CPU的負載。三、縮小以太網接收和發送的緩存區的大小。但是該方式不能實現丟包率的動態調整，不能對數據包的選擇性丟包。

技術實現要素：

本發明提供一種網絡擁塞處理方法及裝置，以實現可動態調整的選擇性丟包，保證系統的正常運行。

第一方面，本發明實施例提供了一種網絡擁塞處理方法，該方法包括：

獲取軟中斷的當前中央處理器CPU占用率，根據所述當前CPU占用率判斷是否進行丟包處理；

當確定進行丟包處理時，根據所述當前CPU占用率確定當前丟包率；

根據預設數據包選擇標準確定滿足丟包條件的數據包數量；

根據所述當前丟包率和所述滿足丟包條件的數據包數量進行選擇性丟包。

進一步的，根據所述當前CPU占用率確定當前丟包率，包括：

根據所述當前CPU占用率確定當前丟包權值；

根據所述當前丟包權值確定所述當前丟包率。

進一步的，根據所述當前CPU占用率確定當前丟包權值，包括：

判斷所述當前CPU占用率是否大于第一閾值；

若所述當前CPU占用率大于所述第一閾值，則確定所述當前丟包權值加1，若所述當前CPU占用率小于或等于所述第一閾值，則判斷所述CPU占用率是否小于第二閾值；

若所述當前CPU占用率小于所述第二閾值，則進一步判斷所述當前丟包權值是否為零，若是，則確定所述當前丟包權值不變，若不是，則確定所述當前丟包權值減1；

若所述當前CPU占用率大于或等于所述第二閾值，則在預設時間間隔后循環獲取新的CPU占用率。

進一步的，根據預設數據包選擇標準確定滿足丟包條件的數據包數量，包括：

獲取數據包信息，其中，所述數據包信息包括數據包的協議類型、數據包長度、源端口和目的端口；

檢測所述數據包的所述協議類型是否是預設協議類型，若不是預設協議類型，則確定所述數據包不滿足丟包條件，若是預設協議類型，對數據包進行預設協議類型標記，并檢測所述數據包的所述數據包長度是否大于預設長度；

若所述數據包的數據包長度小于或等于所述預設長度，則確定所述數據包不滿足丟包條件，若所述數據包的數據包長度大于所述預設長度，則確定滿足丟包條件的數據包數量加1。

進一步的，在檢測所述數據包的協議類型是否是預設協議類型之前，所述方法包括：

檢測所述數據包是否含有預設協議類型標記，若是，則確定所述數據包不滿足丟包條件，若否，則檢測所述數據包的所述協議類型是否是預設協議類型。

進一步的，在確定滿足丟包條件的數據包數量之后，所述方法還包括：

檢測所述數據包的源端口和/或目的端口是否是預放開端口，若是，則確定所述數據包不滿足丟包條件，若否，則確定所述數據包滿足所述丟包條件。

進一步的，根據所述當前丟包率和所述滿足丟包條件的數據包數量進行選擇性丟包，包括：

根據所述當前丟包率和所述滿足丟包條件的數據包數量確定丟包數量；

在滿足丟包條件的數據包中隨機選擇所述丟包數量的數據包進行丟包處理。

第二方面，本發明實施例還提供了一種網絡擁塞處理裝置，該裝置包括：

丟包處理判斷模塊，用于獲取軟中斷的當前中央處理器CPU占用率，根據所述當前CPU占用率判斷是否進行丟包處理；

丟包率確定模塊，用于當確定進行丟包處理時，根據所述當前CPU占用率確定當前丟包率；

數據包數量確定模塊，用于根據預設數據包選擇標準確定滿足丟包條件的數據包數量；

丟包控制模塊，用于根據所述當前丟包率和所述滿足丟包條件的數據包數量進行選擇性丟包。

進一步的，所述丟包率確定模塊包括：

丟包權值確定單元，用于根據所述當前CPU占用率確定當前丟包權值；

丟包率確定單元，用于根據所述當前丟包權值確定所述當前丟包率。

進一步的，所述丟包權值確定單元包括：

第一閾值判斷子單元，用于判斷所述當前CPU占用率是否大于第一閾值；

第一丟包權值確定子單元，用于若所述當前CPU占用率大于所述第一閾值，則確定所述當前丟包權值加1；；

第二閾值判斷子單元，用于若所述當前CPU占用率小于或等于所述第一閾值，則判斷所述CPU占用率是否小于第二閾值；

第二丟包權值確定子單元，用于若所述當前CPU占用率小于所述第二閾值，則進一步判斷所述當前丟包權值是否為零，若是，則確定所述當前丟包權值不變，若不是，則確定所述當前丟包權值減1；

CPU占用率循環獲取子單元，用于若所述當前CPU占用率大于或等于所述第二閾值，則在預設時間間隔后循環獲取新的CPU占用率。

進一步的，所述數據包數量確定模塊包括：

數據包信息獲取單元，用于獲取數據包信息，其中，所述數據包信息包括數據包的協議類型、數據包長度、源端口和目的端口；

協議類型判斷單元，用于檢測所述數據包的所述協議類型是否是預設協議類型，若不是預設協議類型，則確定所述數據包不滿足丟包條件；

數據包長度判斷單元，用于若所述數據包的協議類型是預設協議類型，對數據包進行預設協議類型標記，并檢測所述數據包的所述數據包長度是否大于預設長度；

數據包數量確定單元，用于若所述數據包的數據包長度小于或等于所述預設長度，則確定所述數據包不滿足丟包條件，若所述數據包的數據包長度大于所述預設長度，則確定滿足丟包條件的數據包數量加1。

進一步的，所述數據包數量確定模塊包括：

標記檢測單元，在檢測所述數據包的協議類型是否是預設協議類型之前，檢測所述數據包是否含有預設協議類型標記，若是，則確定所述數據包不滿足丟包條件，若否，則檢測所述數據包的所述協議類型是否是預設協議類型。

進一步的，所述數據包數量確定模塊還包括：

端口檢測單元，用于在確定滿足丟包條件的數據包數量之后，檢測所述數據包的源端口和/或目的端口是否是預放開端口，若是，則確定所述數據包不滿足丟包條件，若否，則確定所述數據包滿足所述丟包條件。

進一步的，所述丟包控制模塊包括：

丟包數量確定單元，用于根據所述當前丟包率和所述滿足丟包條件的數據包數量確定丟包數量；

丟包控制單元，用于在滿足丟包條件的數據包中隨機選擇所述丟包數量的數據包進行丟包處理。

本發明實施例通過根據可動態調節的當前丟包率和滿足丟包條件的數據包數量進行選擇性丟包，解決了現有技術中軟中斷導致網絡擁塞時，無法選擇性丟包處理或者選擇性丟包處理增大CPU負載的問題，實現了可動態調整的選擇性丟包，保證系統的正常運行。

附圖說明

圖1是本發明實施例一提供的網絡擁塞處理方法的流程圖；

圖2是本發明實施例二提供的網絡擁塞處理方法的流程圖；

圖3是本發明實施例三提供的網絡擁塞處理方法的流程圖；

圖4是本發明實施例四提供的網絡擁塞處理方法的流程圖；

圖5是本發明實施例五提供的網絡擁塞處理裝置的結構示意圖。

具體實施方式

下面結合附圖和實施例對本發明作進一步的詳細說明。可以理解的是，此處所描述的具體實施例僅僅用于解釋本發明，而非對本發明的限定。另外還需要說明的是，為了便于描述，附圖中僅示出了與本發明相關的部分而非全部結構。

實施例一

圖1為本發明實施例一提供的網絡擁塞處理方法的流程圖，本實施例可適用于路由器中存在大量數據流，軟終端占用大量CPU導致網絡擁塞情況，該方法可以由本實施例提供的網絡擁塞處理裝置來執行，該裝置可采用軟件和/或硬件的方式實現，該方法具體包括：

S110、獲取軟中斷的當前中央處理器CPU占用率，根據當前CPU占用率判斷是否進行丟包處理。若是，則執行步驟S120，若否，則在預設時間后循環執行步驟S110。

其中，中斷指的是在程序運行過程中，系統出現一個必須由CPU立即處理的情況，CPU暫停終止正在執行的程序轉而處理新情況的過程，中斷包括軟中斷與硬中斷。其中，硬中斷由硬件產生，例如可以是磁盤、網卡或者時鐘等，軟中斷是由當前正在運行的進程產生的。CPU占用率指的是正在運行的程序占用的CPU資源，CPU占用率越高說明當前運行了很多程序。當CPU占用率達到100％時，影響智能終端的基礎功能的正常運行。

本實施例中，當路由器中存在大量數據流時，頻繁的網絡軟中斷的CPU占用率可能達到100％，影響智能終端的基礎功能的正常運行。針對上述問題，采用選擇性丟包的方式解決。

示例性的，檢測當前軟中斷的CPU占用率，若當前軟中斷的CPU占用率大于或者等于91％，則確定進行丟包處理，若當前軟中斷的CPU占用率小于91％，則確定不進行丟包處理。

S120、根據當前CPU占用率確定當前丟包率。

其中，丟包率指的是丟棄數據包的數量與發送數據包數量的比值。示例性的，丟包率可以是10％，即在當前發送的每10個數據包中丟棄1個數據包。

本實施例中，根據當前CPU占用率確定當前丟包率，丟包率可動態調整，在網絡擁塞時增大丟包率，提高CPU資源釋放效率，在數據量不大時，減小丟包率，避免大量數據包丟失。

S130、根據預設數據包選擇標準確定滿足丟包條件的數據包數量。

其中，預設數據包選擇標準指的是系統中預設的選擇性丟包的數據包選擇條件，為了保證智能終端的基本功能，示例性的，丟棄的數據包不包括交互性的小數據包，上網常用的數據包，例如HTTPS、HTTP或者DNS等。

需要說明的是，滿足丟包條件的數據包在以太網接收和發送數據包的緩存區中緩存數據包中進行選擇。

S140、根據當前丟包率和滿足丟包條件的數據包數量進行選擇性丟包。

本實施例中，在滿足丟包條件的數據包中根據當前丟包率和滿足丟包條件的數據包數量確定可丟棄的數據包，并進行丟包處理。其中，在不減小以太網接收和發送數據包的緩存區大小的情況下，對緩存區內的數據包進行選擇性丟包處理，實現在進行丟包處理，為引進新的CPU負載。

本實施例的技術方案，通過根據可動態調節的當前丟包率和滿足丟包條件的數據包數量進行選擇性丟包，解決了現有技術中軟中斷導致網絡擁塞時，無法選擇性丟包處理或者選擇性丟包處理增大CPU負載的問題，實現了可動態調整的選擇性丟包，保證系統的正常運行。

在上述實施例的基礎上，步驟S140還可以是：

根據當前丟包率和滿足丟包條件的數據包數量確定丟包數量；

在滿足丟包條件的數據包中隨機選擇丟包數量的數據包進行丟包處理。

示例性的，當前丟包率可以是10％，滿足丟包條件的數據包數量可以是50，可確定丟包數量為5，在滿足丟包條件的50個數據包中系統隨機的選擇5個數據包進行丟包處理。

實施例二

圖2是本發明實施例二提供的網絡擁塞處理方法的流程圖，在上述實施例的基礎上，進一步的將根據當前CPU占用率確定當前丟包率優化為：根據當前CPU占用率確定當前丟包權值；根據當前丟包權值確定當前丟包率。相應的，該方法具體包括：

S210、獲取軟中斷的當前中央處理器CPU占用率，根據當前CPU占用率判斷是否進行丟包處理。若是，則執行步驟S220，若否，則在預設時間后循環執行步驟S210。

S220、根據當前CPU占用率確定當前丟包權值。

其中，丟包權值指的是用于表示當前CPU占用率的標識，示例性的，當前丟包權值可以是0、1或者2。

S230、根據當前丟包權值確定當前丟包率。

本實施例中，當系統確定當前丟包權值時，生成預設丟包率的指令，并根據該指令進行選擇性丟包處理，例如預設丟包率可以是10％。示例性的，若當前丟包權值為1時，確定當前丟包率為10％，若當前丟包權值為2時，確定當前丟包率為20％。

S240、根據預設數據包選擇標準確定滿足丟包條件的數據包數量。

S250、根據當前丟包率和滿足丟包條件的數據包數量進行選擇性丟包。

本實施例的技術方案，通過根據可動態調節的當前丟包率和滿足丟包條件的數據包數量進行選擇性丟包，解決了現有技術中軟中斷導致網絡擁塞時，無法選擇性丟包處理或者選擇性丟包處理增大CPU負載的問題，實現了可動態調整的選擇性丟包，保證系統的正常運行。

實施例三

圖3是本發明實施例三提供的網絡擁塞處理方法，在上述實施例的基礎上，進一步的提供了根據當前CPU占用率確定當前丟包權值的方法，相應的，該方法具體包括：

S310、獲取軟中斷的當前中央處理器CPU占用率，根據當前CPU占用率判斷是否進行丟包處理。若是，則執行步驟S320，若否，則在預設時間后循環執行步驟S310。

S320、判斷當前CPU占用率是否大于第一閾值。若當前CPU占用率大于第一閾值，則確定當前丟包權值加1，并執行步驟S350，若當前CPU占用率小于或等于第一閾值，則執行步驟S330。

其中，第一閾值可以是90％。

S330、判斷CPU占用率是否小于第二閾值。若當前CPU占用率小于第二閾值，則執行步驟S340，若當前CPU占用率大于或等于第二閾值，則在預設時間間隔后返回執行步驟S310。

示例性的，第二閾值可以是68％，預設時間間隔可以是3分鐘。

S340、判斷當前丟包權值是否為零。若是，則確定當前丟包權值不變，若不是，則確定當前丟包權值減1，同時執行步驟S350。

示例性的，獲取當前CPU占用率，若當前CPU占用率大于第一閾值(例如可以是90％)，例如當前CPU占用率可以是92％，確定當前丟包權值加1；若當前CPU占用率小于第二閾值(例如可以是68％)，例如當前CPU占用率可以是50％，由于當前丟包權值為大于等于0的正整數，若當前丟包權值為零時，確定當前丟包權值保持不變，若當前丟包權值為大于零的正整數時，確定當前丟包權值減1；若當前CPU占用率小于等于第一閾值，同時大于等于第二閾值時，例如當前CPU占用率可以是78％，確定當前丟包權值保持不變。

S350、根據當前丟包權值確定當前丟包率。

示例性的，若當前丟包權值增大，對應的當前丟包率增大，若當前丟包權值減小，對應的當前丟包率減小，實現了丟包率的動態調整，避免了固定大小的丟包率在網絡嚴重擁塞時不能快速降低軟中斷的CPU占用率，或者在CPU占用率不高時，丟棄大量數據包，導致系統進行數據包重傳的情況。

需要說明的是，根據預設時間間隔獲取不同時刻的CPU占用率，可確定不同時刻的丟包權值和丟包率，實現了丟包率的動態調整。

S360、根據預設數據包選擇標準確定滿足丟包條件的數據包數量。

S370、根據當前丟包率和滿足丟包條件的數據包數量進行選擇性丟包。

本實施例的技術方案，通過當前CPU占用率與預設閾值進行比較，根據比較結果確定當前丟包權值與丟包率，由于在預設時間間隔獲取不同時刻的CPU占用率，實現了丟包率的動態調整。

實施例四

圖4是本發明實施例四提供的網絡擁塞處理方法的流程圖，在上述實施例的基礎上，進一步的提供了滿足丟包條件的數據包數量的確定方法，相應的，該方法具體可以包括：

S410、獲取軟中斷的當前中央處理器CPU占用率，根據當前CPU占用率判斷是否進行丟包處理。若是，則執行步驟S420，若否，則在預設時間后循環執行步驟S410。

S420、根據當前CPU占用率確定當前丟包率。

S430、獲取數據包信息，其中，數據包信息包括數據包的協議類型、數據包長度、源端口和目的端口。

其中，數據包的協議類型指的是四層協議類型，包括應用程、傳輸層、網絡互聯層和主機到網絡層；數據包長度指的是數據包中包含的字節數；源端口指的是本地終端數據包發送端口，目的端口指的是目的終端的數據包接收端口。

需要說明的是，數據包信息可通過解包的方法獲取。在解包過程中，首先獲取數據包的二層包類型，根據二層包類型決定解包方式。示例性的，若數據包為PPPOE(Point-to-Point Protocol over Ethernet，以太網上的點對點協議)類型的數據包，需要先剝去數據包的包頭，sk_buf相關指針向下移動8個字節，獲取數據包的四層協議類型、目的端口和源端口等數據包信息，在獲取信息后需對數據包及時還原。數據包為IP(Internet Protocol，網絡之間互連的協議)類型的數據包，在剝去數據包的包頭后，sk_buf相關指針無需進行移位可直接獲取數據包信息。

S440、檢測數據包的協議類型是否是預設協議類型。若數據包的協議類型不是預設協議類型，則確定數據包不滿足丟包條件，若數據包的協議類型是預設協議類型，則執行步驟S460。

本實施例中，預設協議類型可以是傳輸層的UDP(User Datagram Protocol，用戶數據報協議)和TCP(Transmission Control Protocol，傳輸控制協議)，若數據包的協議類型不屬于UDP或者TCP，則確定該數據包不滿足丟包條件，不屬于丟包范圍內的數據包。

本實施例中，丟包處理只丟棄預設協議類型(UDP和TCP)的數據包，保證了終端的基本業務不受影響。

S450、對數據包進行預設協議類型標記，并檢測數據包的數據包長度是否大于預設長度。若數據包的數據包長度小于或等于預設長度，則確定數據包不滿足丟包條件，若數據包的數據包長度大于預設長度，則執行步驟S470。

其中，預設長度可以是256字節，數據包長度小于或等于256字節，則確定該數據包不滿足丟包條件，不屬于丟包范圍內的數據包；若數據包長度大于256字節，則確定該數據包滿足丟包條件，屬于丟包范圍內的數據包。示例性的，滿足丟包條件的數據包可以是BT(Bit Torrent，比特流)下載數據包。

本實施例中，選擇數據包長度大于預設長度的數據包進行丟棄，能夠加快CPU占用率的調節效率。

S460、確定滿足丟包條件的數據包數量加1。同時返回執行步驟S430，獲取下一個數據包信息。

本實施例中，當確定數據包滿足丟包條件時，確定滿足丟包條件的數據包數量加1，當確定數據包不滿足丟包條件時，確定滿足丟包條件的數據包數量不變。

S470、根據當前丟包率和滿足丟包條件的數據包數量進行選擇性丟包。

本實施例的技術方案，通過根據數據包的協議類型和數據包長度選擇可丟棄的數據包，根據當前丟包率和滿足丟包條件的數據包數量在可丟棄的數據包中選擇數據包進行丟包處理，即在保證網絡正常運行的情況下，進行丟包處理，實現了選擇性丟包。

在上述實施例的基礎上，在步驟S440之前該方法還可以包括：

檢測數據包是否含有預設協議類型標記。若是，則確定數據包不滿足丟包條件，若否，則執行步驟S450。

本實施例中，在檢測到數據包的協議類型屬于預設協議類型時，對數據包進行預設協議類型標記，表明該數據包被檢測。由于根據丟包率隨機確定被丟棄的數據包，因此存在被標記但未被丟棄的數據包，又由于軟件中斷處理函數可能對同一數據包進行多次調用，為了避免同一數據包被反復檢測，在對數據包進行預設數據包選擇標準檢測之前，檢測據包是否含有預設協議類型標記，若存在，不在對該數據包進行檢測，減少了檢測次數，提高了處理效率。

在上述實施例的基礎上，在步驟S460之后該方法還可以包括：

檢測數據包的源端口和/或目的端口是否是預放開端口。若是，則確定數據包不滿足丟包條件，若否，則確定數據包滿足丟包條件。

本實施例中，預放開端口例如可以是80端口、443端口、53端口或者22端口等，根據上述預放開端口建立哈希表，若數據包的源端口或目的端口任意端口屬于哈希表中的一個預放開端口，則確定數據包不滿足丟包條件，若數據包的源端口和目的端口均不屬于哈希表中的預放開端口，則確定數據包滿足丟包條件。

本實施例中，將源端口和/或目的端口屬于預放開端口的數據包確定為不滿足丟包條件的數據包，減少了數據包的丟失。

實施例五

圖5是本發明實施例五提供的網絡擁塞處理裝置，該裝置適用于執行本發明實施例提供的網絡擁塞處理方法，該裝置具體可以包括：

丟包處理判斷模塊510，用于獲取軟中斷的當前中央處理器CPU占用率，根據當前CPU占用率判斷是否進行丟包處理；

丟包率確定模塊520，用于當確定進行丟包處理時，根據當前CPU占用率確定當前丟包率；

數據包數量確定模塊530，用于根據預設數據包選擇標準確定滿足丟包條件的數據包數量；

丟包控制模塊540，用于根據當前丟包率和滿足丟包條件的數據包數量進行選擇性丟包。

優選的，丟包率確定模塊520包括：

丟包權值確定單元521，用于根據當前CPU占用率確定當前丟包權值；

丟包率確定單元522，用于根據當前丟包權值確定當前丟包率。

優選的，丟包權值確定單元521包括：

第一閾值判斷子單元5211，用于判斷當前CPU占用率是否大于第一閾值；

第一丟包權值確定子單元5212，用于若當前CPU占用率大于第一閾值，則確定當前丟包權值加1；；

第二閾值判斷子單元5213，用于若當前CPU占用率小于或等于第一閾值，則判斷CPU占用率是否小于第二閾值；

第二丟包權值確定子單元5214，用于若當前CPU占用率小于第二閾值，則進一步判斷當前丟包權值是否為零，若是，則確定當前丟包權值不變，若不是，則確定當前丟包權值減1；

CPU占用率循環獲取子單元5215，用于若當前CPU占用率大于或等于第二閾值，則在預設時間間隔后循環獲取新的CPU占用率。

優選的，數據包數量確定模塊530包括：

數據包信息獲取單元531，用于獲取數據包信息，其中，數據包信息包括數據包的協議類型、數據包長度、源端口和目的端口；

協議類型判斷單元532，用于檢測數據包的協議類型是否是預設協議類型，若不是預設協議類型，則確定數據包不滿足丟包條件；

數據包長度判斷單元533，用于若數據包的協議類型是預設協議類型，對數據包進行預設協議類型標記，并檢測數據包的數據包長度是否大于預設長度；

數據包數量確定單元534，用于若數據包的數據包長度小于或等于預設長度，則確定數據包不滿足丟包條件，若數據包的數據包長度大于預設長度，則確定滿足丟包條件的數據包數量加1。

優選的，數據包數量確定模塊530包括：

標記檢測單元535，在檢測數據包的協議類型是否是預設協議類型之前，檢測數據包是否含有預設協議類型標記，若是，則確定數據包不滿足丟包條件，若否，則檢測數據包的協議類型是否是預設協議類型。

優選的，數據包數量確定模塊530還包括：

端口檢測單元536，用于在確定滿足丟包條件的數據包數量之后，檢測數據包的源端口和/或目的端口是否是預放開端口，若是，則確定數據包不滿足丟包條件，若否，則確定數據包滿足丟包條件。

優選的，丟包控制模塊540包括：

丟包數量確定單元541，用于根據當前丟包率和滿足丟包條件的數據包數量確定丟包數量；

丟包控制單元542，用于在滿足丟包條件的數據包中隨機選擇丟包數量的數據包進行丟包處理。

本發明實施例提供的網絡擁塞處理裝置可執行本發明任意實施例所提供的網絡擁塞處理方法，具備執行方法相應的功能模塊和有益效果。

注意，上述僅為本發明的較佳實施例及所運用技術原理。本領域技術人員會理解，本發明不限于這里所述的特定實施例，對本領域技術人員來說能夠進行各種明顯的變化、重新調整和替代而不會脫離本發明的保護范圍。因此，雖然通過以上實施例對本發明進行了較為詳細的說明，但是本發明不僅僅限于以上實施例，在不脫離本發明構思的情況下，還可以包括更多其他等效實施例，而本發明的范圍由所附的權利要求范圍決定。