翁 創(chuàng)

（上海船舶運(yùn)輸科學(xué)研究所有限公司 艦船自動(dòng)化系統(tǒng)事業(yè)部，上海 200135）

0 引言

隨著互聯(lián)網(wǎng)和大數(shù)據(jù)技術(shù)的蓬勃發(fā)展，云計(jì)算逐漸成為現(xiàn)代計(jì)算領(lǐng)域的核心技術(shù)之一。眾多企業(yè)和個(gè)人紛紛將數(shù)據(jù)和應(yīng)用部署在云服務(wù)器上，以便利用強(qiáng)大的云計(jì)算能力降低本地硬件和軟件成本。云計(jì)算技術(shù)的迅速普及催生了計(jì)算資源、存儲(chǔ)資源和網(wǎng)絡(luò)資源的集中化管理。虛擬化技術(shù)作為云計(jì)算的關(guān)鍵組成部分，為用戶提供了靈活、安全、易用的計(jì)算環(huán)境［1］。在云環(huán)境和大數(shù)據(jù)環(huán)境下，例如HDFS［2］和分布式文件系統(tǒng)［3］以及HTTP 靜態(tài)資源訪問等場景中，服務(wù)器經(jīng)常采用虛擬機(jī)的方式進(jìn)行部署。該方式有助于提高數(shù)據(jù)的可靠性和安全性，同時(shí)便于備份［4］。

然而，在虛擬化環(huán)境中，由于虛擬機(jī)資源的隔離性和數(shù)據(jù)傳輸過程的復(fù)雜性，云服務(wù)器的性能受到了顯著影響［5］。在應(yīng)對大量并發(fā)請求和大規(guī)模數(shù)據(jù)處理時(shí)，性能瓶頸問題尤為明顯［6］。例如在圖1 所示的KVM（Kernelbased Virtual Machine）虛擬化環(huán)境下，一個(gè)宿主機(jī)安裝著多個(gè)虛擬機(jī)，不同類型的資源分別被存放在不同虛擬機(jī)里［7］。當(dāng)請求資源時(shí)，請求報(bào)文首先被宿主機(jī)系統(tǒng)內(nèi)核接收，然后宿主機(jī)解析報(bào)文并將報(bào)文發(fā)往指定的虛擬機(jī)，最后虛擬機(jī)將資源按原路返送回去。在整個(gè)過程中，TCP/IP協(xié)議經(jīng)歷了多層解析，每一層解析都會(huì)消耗CPU 資源［8］。同時(shí)，用戶態(tài)和內(nèi)核態(tài)的頻繁切換也進(jìn)一步增加了性能開銷，可能導(dǎo)致CPU 利用率上升、系統(tǒng)響應(yīng)速度降低。

Fig.1 KVM virtualization infrastructure圖1 KVM虛擬化基礎(chǔ)架構(gòu)

為了解決上述問題，本文提出一種基于Linux 內(nèi)核的優(yōu)化方 法（Kernel-Oriented TCP/IP Optimization Method，KOTOM）。該方法利用宿主機(jī)內(nèi)核態(tài)netfilter 的掛鉤函數(shù)監(jiān)控發(fā)往目標(biāo)服務(wù)器的TCP 請求和服務(wù)器響應(yīng)，并建立被請求資源的緩存，通過LRU 算法實(shí)現(xiàn)熱點(diǎn)資源的緩存替換，從而降低TCP/IP 協(xié)議處理過程中資源在內(nèi)核態(tài)與用戶態(tài)之間傳遞帶來的性能開銷。實(shí)驗(yàn)結(jié)果表明，該方法成功地節(jié)省了服務(wù)器計(jì)算資源，并縮短了請求時(shí)間，降低了服務(wù)器在虛擬化環(huán)境中的CPU 資源利用率。本文的主要?jiǎng)?chuàng)新點(diǎn)如下：

（1）優(yōu)化了Linux TCP/IP 解析流程，實(shí)現(xiàn)了直接在內(nèi)核態(tài)進(jìn)行TCP 報(bào)文解析。

（2）建立了內(nèi)核態(tài)緩存機(jī)制，減少了用戶態(tài)與內(nèi)核態(tài)之間的切換次數(shù)，提高了系統(tǒng)整體效率。

（3）提出一種根據(jù)請求熱點(diǎn)數(shù)據(jù)變化的動(dòng)態(tài)自適應(yīng)緩存替換策略，實(shí)現(xiàn)更高效的緩存利用。

1 相關(guān)工作

本文關(guān)注的是虛擬化環(huán)境中云服務(wù)器的數(shù)據(jù)傳輸效率和計(jì)算資源利用效率，為介紹該領(lǐng)域的研究現(xiàn)狀，以下對一些與本文主題相關(guān)的工作進(jìn)行了回顧。

Yasukata 等［9］為解決操作系統(tǒng)內(nèi)核棧和專用網(wǎng)卡（NICs）之間交互性能的問題，提出了StackMap 方法。該方法通過優(yōu)化操作系統(tǒng)內(nèi)核棧和專用網(wǎng)卡（NICs）之間的交互來降低網(wǎng)絡(luò)延遲。其分析了現(xiàn)有內(nèi)核棧和網(wǎng)卡的通信過程，發(fā)現(xiàn)了一系列可以優(yōu)化的點(diǎn)。這項(xiàng)工作對于理解內(nèi)核棧和網(wǎng)卡之間通信過程的優(yōu)化具有重要意義。本文提出的KOTOM 方法優(yōu)化了面向虛擬環(huán)境的Linux TCP/IP 解析流程，并實(shí)現(xiàn)了直接在內(nèi)核態(tài)進(jìn)行TCP 協(xié)議解析。此外，其采用了一種新型的內(nèi)核態(tài)緩存機(jī)制，通過降低用戶態(tài)和內(nèi)核態(tài)之間的切換次數(shù)，提高了系統(tǒng)整體效率。與本文方法相比，StackMap 方法主要關(guān)注操作系統(tǒng)內(nèi)核棧和專用網(wǎng)卡之間的交互優(yōu)化，而本文方法更著重于內(nèi)核態(tài)緩存機(jī)制和動(dòng)態(tài)自適應(yīng)緩存替換策略設(shè)計(jì)。

呂梅桂［10］詳細(xì)闡述了在KVM 虛擬化環(huán)境下虛擬機(jī)網(wǎng)絡(luò)性能優(yōu)化的一般方法，特別是基于Direct IRQ 技術(shù)的優(yōu)化方案。Direct IRQ 是指將網(wǎng)卡產(chǎn)生的中斷直接發(fā)送到虛擬機(jī)，而不經(jīng)過虛擬機(jī)監(jiān)控器。與本文的研究相比，其主要是通過Direct IRQ 技術(shù)達(dá)到優(yōu)化效果。該方法將網(wǎng)卡直接分配給虛擬機(jī)，本文方法不將網(wǎng)卡直接分配給虛擬機(jī)，而是通過虛擬機(jī)監(jiān)控器緩存靜態(tài)數(shù)據(jù)實(shí)現(xiàn)優(yōu)化效果。KOTOM 方法針對性地解決了用戶態(tài)和內(nèi)核態(tài)之間頻繁切換帶來的資源開銷問題，并且引入了紅黑樹和LRU 策略，進(jìn)一步提高了緩存查找和使用效率，從而使性能得到顯著提升。

劉禹燕等［11］詳細(xì)介紹了Virtio 框架的基本原理，闡述了該框架如何實(shí)現(xiàn)半虛擬化環(huán)境下的高性能網(wǎng)絡(luò)通信。通過對Virtio 框架中的數(shù)據(jù)傳輸和緩存策略進(jìn)行優(yōu)化，實(shí)現(xiàn)了在半虛擬化環(huán)境下更高效的網(wǎng)絡(luò)請求處理。該項(xiàng)工作為提高虛擬化環(huán)境中的網(wǎng)絡(luò)性能提供了實(shí)際的解決方案。與本文方法相比，該研究主要關(guān)注半虛擬化環(huán)境下的網(wǎng)絡(luò)通信性能優(yōu)化，而本文方法適用于全虛擬化環(huán)境，通過優(yōu)化內(nèi)核態(tài)TCP/IP 數(shù)據(jù)處理和緩存策略，提高云服務(wù)器在虛擬化環(huán)境中的性能。本文方法不僅針對性地解決了用戶態(tài)和內(nèi)核態(tài)之間頻繁切換帶來的資源開銷問題，而且提出一種根據(jù)請求熱點(diǎn)數(shù)據(jù)變化的動(dòng)態(tài)自適應(yīng)緩存替換策略，實(shí)現(xiàn)更高效的緩存利用和性能提升。

1.1 TCP/IP優(yōu)化

在傳統(tǒng)的數(shù)據(jù)傳輸模式中，服務(wù)器遵循協(xié)議層次對報(bào)文進(jìn)行逐層解析。具體來說，報(bào)文從物理層開始，逐級經(jīng)過數(shù)據(jù)鏈路層、網(wǎng)絡(luò)層、傳輸層，最終達(dá)到應(yīng)用層［12］。如圖2 所示，實(shí)線代表服務(wù)器內(nèi)核在解析請求和發(fā)送數(shù)據(jù)時(shí)的傳統(tǒng)模式。在該模式下，當(dāng)服務(wù)器收到一個(gè)TCP 請求時(shí)，請求報(bào)文首先在內(nèi)核態(tài)被各個(gè)協(xié)議層進(jìn)行處理，之后傳輸層（例如TCP 層）處理完的報(bào)文會(huì)傳遞給用戶態(tài)的socket進(jìn)行深入分析。在應(yīng)用層處理完請求后，其會(huì)將響應(yīng)報(bào)文再次傳遞給內(nèi)核態(tài)，以便進(jìn)行下行傳輸。在此過程中，內(nèi)核態(tài)與用戶態(tài)需要頻繁切換。

Fig.2 TCP/IP protocol parsing process in Linux圖2 Linux下TCP/IP協(xié)議解析流程

內(nèi)核態(tài)與用戶態(tài)之間的切換涉及上下文切換、內(nèi)存映射及資源調(diào)度等操作，會(huì)導(dǎo)致顯著的資源與時(shí)間開銷。此外，報(bào)文在逐層解析時(shí)需多次進(jìn)行封裝與解封裝，增大了處理過程的復(fù)雜性和附加開銷［13］。因此，在傳統(tǒng)的數(shù)據(jù)傳輸模式下，服務(wù)器性能往往受到用戶態(tài)與內(nèi)核態(tài)頻繁切換以及報(bào)文逐層解析所帶來的資源與時(shí)間消耗的影響。

本文提出的KOTOM 方法致力于在虛擬化環(huán)境中基于內(nèi)核態(tài)進(jìn)行請求報(bào)文的解析與數(shù)據(jù)傳輸。與傳統(tǒng)方法相比，該方法規(guī)避了報(bào)文的逐層解析和用戶態(tài)與內(nèi)核態(tài)間的頻繁切換問題。圖2 的虛線部分揭示了KOTOM 方法對數(shù)據(jù)包的另一種處理模式。首先，內(nèi)核在網(wǎng)絡(luò)層對請求進(jìn)行解析，進(jìn)而確定請求報(bào)文中應(yīng)用層協(xié)議的起始地址；然后，內(nèi)核對應(yīng)用層協(xié)議進(jìn)行解析，獲取請求路徑，并根據(jù)此定位緩存內(nèi)容；最后，系統(tǒng)開始構(gòu)建內(nèi)容報(bào)文new_skb。new_skb的構(gòu)建遵循以下指定順序：

（1）數(shù)據(jù)區(qū)。從緩存中提取請求內(nèi)容，并填入new_skb的數(shù)據(jù)區(qū)。緩存包含用戶態(tài)協(xié)議以及請求內(nèi)容本身，使得KOTOM 方法省去了用戶態(tài)協(xié)議首部的構(gòu)建。

（2）TCP 層。為new_skb 構(gòu)建TCP 首部，需準(zhǔn)確設(shè)定源端口、目標(biāo)端口、序列號、確認(rèn)號等TCP 首部字段。事實(shí)上，源端口、目標(biāo)端口及序列號對應(yīng)于請求報(bào)文的目標(biāo)端口、源端口及確認(rèn)號與內(nèi)容長度之和。

（3）IP 層。為new_skb 構(gòu)建IP 首部，需準(zhǔn)確設(shè)定源IP地址、目標(biāo)IP 地址、協(xié)議類型（TCP）以及首部長度等IP 首部字段。源和目標(biāo)IP 地址分別與請求報(bào)文中的目標(biāo)和源IP地址相對應(yīng)。

（4）MAC 層。為new_skb 構(gòu)建以太網(wǎng)首部，需準(zhǔn)確設(shè)定源MAC 地址、目標(biāo)MAC 地址及協(xié)議類型（IPv4）等以太網(wǎng)首部字段。目標(biāo)MAC 地址與請求報(bào)文的源MAC 地址相同，而源MAC 地址是發(fā)送端網(wǎng)卡的地址。

完成這些步驟后，new_skb 被發(fā)送至原先發(fā)出數(shù)據(jù)請求的主機(jī)。值得注意的是，在整個(gè)請求流程中，TCP 連接的建立與釋放均遵循3 次握手和4 次揮手的原則。盡管使用KOTOM 方法傳輸內(nèi)容，但3 次握手和4 次揮手仍按照傳統(tǒng)模式執(zhí)行，該方法僅影響內(nèi)容報(bào)文的傳輸流程。

1.2 基于LRU的內(nèi)核緩存

KOTOM 緩存區(qū)允許熱點(diǎn)內(nèi)容在內(nèi)存中進(jìn)行短暫存儲(chǔ)。當(dāng)后續(xù)請求發(fā)生時(shí)，相關(guān)內(nèi)容能直接從內(nèi)存中提取。為了合理使用服務(wù)器內(nèi)存并確保其穩(wěn)定性，必須對緩存區(qū)的大小進(jìn)行限制。首先，確定緩存區(qū)的最大容量。當(dāng)緩存區(qū)的總?cè)萘窟_(dá)到此上限時(shí)，低頻訪問的內(nèi)容將被新數(shù)據(jù)所替代。為此，基于實(shí)驗(yàn)，本文選擇了一個(gè)適宜的緩存替換策略。其次，為簡化內(nèi)容管理，緩存區(qū)采用一個(gè)稱為obj 的內(nèi)容存儲(chǔ)對象，該對象包含內(nèi)容名稱、大小、實(shí)體、請求路徑以及訪問時(shí)間等信息。最終，為緩存區(qū)設(shè)計(jì)了一套API，實(shí)現(xiàn)存儲(chǔ)對象插入和基于路徑的對象檢索等功能。

當(dāng)API 執(zhí)行對象插入或刪除操作時(shí)，內(nèi)核會(huì)即時(shí)更新內(nèi)容緩存區(qū)的可用空間、已占用空間及當(dāng)前對象數(shù)。內(nèi)容緩存區(qū)采用紅黑樹作為其對象的存儲(chǔ)結(jié)構(gòu)。與鏈表或其他具有O（n）搜索時(shí)間復(fù)雜度的數(shù)據(jù)結(jié)構(gòu)相比，紅黑樹具有O（logn）的搜索時(shí)間復(fù)雜度，是一種更加高效的搜索結(jié)構(gòu)。

LRU（Least Recently Used）緩存替換算法是一種廣泛應(yīng)用的高效的緩存管理策略［14］。其核心思想在于：每當(dāng)對象被創(chuàng)建或已存在于緩存中的對象被訪問時(shí)，其最近訪問的時(shí)間戳?xí)桓?。?dāng)緩存容量達(dá)到上限時(shí)，緩存中最久未被訪問的對象將被新對象替代。例如，在圖3 中，新創(chuàng)建的對象7 嘗試進(jìn)入一個(gè)已滿的緩存，因此最久未被訪問的對象5 被移除，使得對象7 得以存入［15］。因?yàn)長RU 策略將最近最少使用的數(shù)據(jù)置于緩存替換的較低優(yōu)先級［16］，所以與其他緩存替換策略相比，LRU 策略往往能夠在多數(shù)場景下提高緩存命中率。

Fig.3 LRU cache replacement algorithm schematic diagram圖3 LRU緩存替換算法原理圖

為了有效實(shí)施LRU 策略，本文采納了Linux 內(nèi)核中的標(biāo)準(zhǔn)定時(shí)器jiffies［17］作為對象屬性中“訪問時(shí)間”的時(shí)間來源。jiffies 是Linux 操作系統(tǒng)的一個(gè)核心全局變量，記錄了從系統(tǒng)啟動(dòng)到當(dāng)前的時(shí)間單位數(shù)，常用于跟蹤內(nèi)核中各種定時(shí)器和計(jì)時(shí)器任務(wù)的執(zhí)行時(shí)長。借助jiffies，本文能夠精確地為LRU 算法記錄訪問時(shí)間，確保在緩存容量達(dá)到極限時(shí)，能夠優(yōu)先替換掉最近最少訪問的對象。

為了高效地管理緩存區(qū)，本文需要提供API 以實(shí)現(xiàn)對象的插入、刪除和查找功能。以插入功能為例，每當(dāng)新的存儲(chǔ)對象被創(chuàng)建，內(nèi)核必須為其各成員（例如“對象名稱”、“數(shù)據(jù)”和“路徑”）以及對象本體動(dòng)態(tài)分配內(nèi)存。Linux 內(nèi)核中的kmalloc 函數(shù)能夠滿足此需求，其允許動(dòng)態(tài)分配連續(xù)的內(nèi)存塊。但值得注意的是，kmalloc 可分配的最大內(nèi)存容量受到當(dāng)前內(nèi)核可用內(nèi)存和連續(xù)內(nèi)存塊大小的限制，一般最大為128k 字節(jié)。為了實(shí)現(xiàn)緩存對象的動(dòng)態(tài)創(chuàng)建，本文引入名為obj_create 的API，并借助kmalloc 來申請必要的內(nèi)存。圖4 詳細(xì)展示了obj_create 的工作流程。首先，任何超過緩存區(qū)容量的數(shù)據(jù)都不能被保存；其次，如果當(dāng)前的緩存空間不足，LRU_search 會(huì)遍歷紅黑樹，定位到最近最少被使用的對象并通過node_delete 進(jìn)行刪除，此過程會(huì)重復(fù)，直至釋放足夠的空間給新對象；最后，obj_insert 會(huì)將新對象加入緩存區(qū)。

Fig.4 obj_create process flow圖4 obj_create流程

在KOTOM 方法中，多個(gè)API 包括obj_create，都依賴于node_search 來查找特定的存儲(chǔ)對象。node_search 能夠僅憑請求路徑高效定位和訪問整個(gè)存儲(chǔ)對象，主要?dú)w功于其使用的container_of 宏來識別存儲(chǔ)對象的起始地址。在Linux 內(nèi)核中，container_of 是一個(gè)特別設(shè)計(jì)的宏，其允許通過已知結(jié)構(gòu)體中某個(gè)成員的指針以及該成員類型和名稱迅速定位到該結(jié)構(gòu)體的首地址。在本文的內(nèi)核模塊設(shè)計(jì)中，container_of 發(fā)揮了至關(guān)重要的作用，確保了高效的緩存管理和內(nèi)容查詢。

1.3 基于sysfs的緩存監(jiān)控與配置

KOTOM 方法在內(nèi)核態(tài)下處理數(shù)據(jù)，可避免冗余的內(nèi)容拷貝和CPU 的額外開銷，提供了一種效率極高的數(shù)據(jù)處理模式。但在實(shí)踐中，實(shí)時(shí)的緩存區(qū)域管理和模塊參數(shù)監(jiān)視是不可或缺的。頻繁地加載、卸載或調(diào)試內(nèi)核模塊不僅繁瑣，而且可能帶來潛在的系統(tǒng)風(fēng)險(xiǎn)。為此，本文采用sysfs 接口，以實(shí)現(xiàn)用戶態(tài)與內(nèi)核態(tài)之間順暢的數(shù)據(jù)交互。sysfs 不僅便于對緩存區(qū)域和參數(shù)的管理監(jiān)控，而且能確保所有內(nèi)容處理始終在內(nèi)核態(tài)下進(jìn)行。這一設(shè)計(jì)平衡了實(shí)時(shí)監(jiān)控與高效處理的需求，對系統(tǒng)的穩(wěn)定性和可維護(hù)性都帶來了積極影響，成為實(shí)施KOTOM 方法的關(guān)鍵策略。

sysfs 位于Linux 內(nèi)核中，作為一種虛擬文件系統(tǒng)［18］，其構(gòu)建了一個(gè)統(tǒng)一通道，便于用戶訪問和控制設(shè)備樹、內(nèi)核對象、設(shè)備驅(qū)動(dòng)以及其他核心組件。因此，利用其在用戶空間中展示的分層目錄，用戶可以輕易地瀏覽和調(diào)整系統(tǒng)的各類參數(shù)。該設(shè)計(jì)巧妙地優(yōu)化了Linux 內(nèi)核與用戶空間的互動(dòng)方式，確立了其作為內(nèi)核與用戶交互的核心途徑。

在模塊的執(zhí)行階段，本文寄望于對緩存區(qū)的幾個(gè)關(guān)鍵參數(shù)進(jìn)行實(shí)時(shí)管理和監(jiān)控：容量上限（cache_size）、剩余容量（free_space）、對象總數(shù)（obj_count）和已占用空間（used_space）。為實(shí)現(xiàn)這一目標(biāo)，KOTOM 的內(nèi)核模塊設(shè)計(jì)了一個(gè)名為attr_group 的屬性組。該屬性組關(guān)聯(lián)了4 個(gè)主要屬性：cache_size_attr、free_space_attr、obj_count_attr 以及used_space_attr，且每一個(gè)屬性都有相應(yīng)函數(shù)來完成數(shù)據(jù)的讀寫操作。內(nèi)核將此4 個(gè)關(guān)鍵參數(shù)以文件的形式傳至用戶態(tài)，使得用戶可以直接通過這些文件來管理和調(diào)整參數(shù)。該設(shè)計(jì)巧妙地建立了內(nèi)核與用戶間的通信橋梁，大大簡化了對緩存區(qū)的管理和監(jiān)控。因此，用戶能夠便捷地訪問和調(diào)整這些關(guān)鍵參數(shù)，從而實(shí)時(shí)了解并控制緩存區(qū)狀態(tài)。

1.4 整體架構(gòu)

Netfilter 是嵌入在Linux 內(nèi)核中的網(wǎng)絡(luò)過濾機(jī)制，其提供了一套靈活的工具，使得內(nèi)核模塊能夠在網(wǎng)絡(luò)棧的各個(gè)環(huán)節(jié)注冊并對數(shù)據(jù)包進(jìn)行實(shí)時(shí)攔截［19］。當(dāng)請求報(bào)文在服務(wù)器內(nèi)核中流動(dòng)時(shí)，Netfilter 會(huì)對其進(jìn)行路由調(diào)整，確保其正確地轉(zhuǎn)發(fā)到虛擬機(jī)中。同樣地，從虛擬機(jī)返回的數(shù)據(jù)包會(huì)被Netfilter 進(jìn)行處理［20］。通過這一機(jī)制，本文得以深入地對數(shù)據(jù)包進(jìn)行審查、修改或攔截，進(jìn)而實(shí)現(xiàn)對進(jìn)出請求和響應(yīng)數(shù)據(jù)的精準(zhǔn)處理。

圖5 詳細(xì)展示了Linux 內(nèi)核中Netfilter 的核心架構(gòu)［21］。在請求報(bào)文到達(dá)服務(wù)器時(shí)，服務(wù)器的網(wǎng)卡首先捕獲這一報(bào)文，并迅速將其交付給Netfilter 進(jìn)行處理。隨后，Netfilter的ip_rcv 函數(shù)會(huì)介入，并對請求報(bào)文執(zhí)行系列操作，如校驗(yàn)報(bào)文的完整性、對其進(jìn)行解碼，并進(jìn)行必要的前期處理等。接下來，處理后的請求報(bào)文被傳遞給第一個(gè)路由節(jié)點(diǎn)（路由1）。該路由節(jié)點(diǎn)基于報(bào)文的目標(biāo)地址信息進(jìn)一步將報(bào)文導(dǎo)向第二路由節(jié)點(diǎn)（路由2），由其負(fù)責(zé)將請求報(bào)文準(zhǔn)確地投遞到預(yù)定的虛擬機(jī)中。值得注意的是，報(bào)文在傳輸過程中會(huì)依序經(jīng)過Netfilter 的兩個(gè)關(guān)鍵掛鉤點(diǎn)，即NF_INET_PRE_ROUTING 和NF_INET_FORWARD。

Fig.5 Netfilter architecture圖5 Netfilter架構(gòu)

一旦目標(biāo)虛擬機(jī)接收到請求報(bào)文，其立即生成并返回相應(yīng)的內(nèi)容報(bào)文。該報(bào)文首先被傳遞給路由2，接著路由2 將其交由ip_output 作進(jìn)一步的處理和轉(zhuǎn)發(fā)。完成對ip_output 及其他相關(guān)IP 層函數(shù)的處理后，內(nèi)容報(bào)文進(jìn)入物理層，并由dev_queue_xmit 負(fù)責(zé)進(jìn)行物理封裝。經(jīng)過這一系列操作，內(nèi)容報(bào)文最終通過服務(wù)器的網(wǎng)卡發(fā)送，直達(dá)客戶端。值得注意的是，在整個(gè)傳輸和處理過程中，內(nèi)容報(bào)文必然會(huì)經(jīng)過Netfilter 的關(guān)鍵掛鉤點(diǎn)NF_INET_POST_ROUTING。

當(dāng)需要攔截請求數(shù)據(jù)包時(shí)，雖然有兩個(gè)可能的掛鉤點(diǎn)：NF_INET_PRE_ROUTING 和NF_INET_FORWARD，但本文優(yōu)先選擇NF_INET_FORWARD。這是因?yàn)镹F_INET_PRE_ROUTING 掛鉤處理的數(shù)據(jù)包的目的地也可能是本地服務(wù)器，而NF_INET_FORWARD 掛鉤只關(guān)心那些需要轉(zhuǎn)發(fā)至其他虛擬機(jī)的數(shù)據(jù)包。如果本文選擇在NF_INET_PRE_ROUTING 位置設(shè)立掛鉤，那么其將不得不處理額外、非目標(biāo)性的數(shù)據(jù)包，因而可能會(huì)拖慢處理速度。所以，KOTOM 內(nèi)核模塊選擇在NF_INET_FORWARD 位置設(shè)立了一個(gè)掛鉤函數(shù)watch_in［22］，專門用于捕獲和轉(zhuǎn)發(fā)數(shù)據(jù)包。該設(shè)計(jì)策略巧妙地避開了不必要的數(shù)據(jù)包處理過程，從而大大提升了整體的處理效率。

為了確保請求和響應(yīng)的完整捕獲與高效處理，本文還在NF_INET_POST_ROUTING 掛鉤點(diǎn)設(shè)置了另一個(gè)掛鉤函數(shù)，名為watch_out。該函數(shù)的主要任務(wù)是對內(nèi)容進(jìn)行緩存操作。具體的架構(gòu)和流程可參考圖6。圖6 明確展示了請求和響應(yīng)數(shù)據(jù)包如何被相應(yīng)的掛鉤函數(shù)watch_in 和watch_out 進(jìn)行處理，并描述了其在整個(gè)Netfilter 框架中的位置和角色。

Fig.6 KOTOM architecture圖6 KOTOM 架構(gòu)

當(dāng)客戶端發(fā)出的請求報(bào)文通過路由1 并到達(dá)轉(zhuǎn)發(fā)的掛鉤點(diǎn)時(shí)，掛鉤函數(shù)watch_in 立即捕獲該報(bào)文。其首先解析報(bào)文，提取請求路徑，并在緩存區(qū)查找是否存在與請求路徑匹配的內(nèi)容。根據(jù)查找結(jié)果，會(huì)有以下兩種可能的情況：①緩存命中：如果緩存區(qū)中已有與請求路徑匹配的內(nèi)容，這些內(nèi)容將被直接提取出來，繞過目標(biāo)虛擬機(jī)，直接傳遞給函數(shù)dev_queue_xmit 進(jìn)行打包，并快速轉(zhuǎn)發(fā)給客戶端。這期間原先被捕獲的請求報(bào)文因?yàn)橐呀?jīng)得到了響應(yīng)，會(huì)被直接丟棄；②緩存未命中：當(dāng)緩存區(qū)中沒有與請求路徑匹配的內(nèi)容時(shí)，watch_in 不會(huì)立即作出反應(yīng)，而是允許該請求報(bào)文繼續(xù)通過路由2 被轉(zhuǎn)發(fā)到目標(biāo)虛擬機(jī)。當(dāng)目標(biāo)虛擬機(jī)生成響應(yīng)并通過函數(shù)ip_output 處理完畢后，掛鉤函數(shù)watch_out 會(huì)捕獲該響應(yīng)內(nèi)容。在dev_queue_xmit 將響應(yīng)報(bào)文轉(zhuǎn)發(fā)給客戶端之前，watch_out 首先將其保存到緩存區(qū)中，從而為未來的相同請求提供快速響應(yīng)。需要注意的是，無論緩存是否命中，報(bào)文最后都要交給內(nèi)核函數(shù)dev_queue_xmit進(jìn)行處理。

圖7 展示了函數(shù)watch_in 在實(shí)驗(yàn)環(huán)境下的詳細(xì)工作流程。

Fig.7 watch_in process flow圖7 watch_in流程

（1）報(bào)文過濾。watch_in 的第一步是區(qū)分并過濾掉那些非HTTP 請求的數(shù)據(jù)包，以確保只處理對緩存有意義的請求報(bào)文。在真實(shí)的網(wǎng)絡(luò)場景下，watch_in 可以通過IP 目的地址、端口號和統(tǒng)一資源標(biāo)識符（Uniform Resource Identifier，URI）過濾掉非HTTP 請求的數(shù)據(jù)包。

（2）路徑提取。接下來watch_in 從HTTP 請求報(bào)文中提取請求路徑，該路徑是后續(xù)查找緩存的關(guān)鍵，所以會(huì)被保存在全局變量temp_path 中。需要注意的是，當(dāng)Linux 內(nèi)核創(chuàng)建數(shù)據(jù)包時(shí)，會(huì)經(jīng)歷組裝多個(gè)數(shù)據(jù)片段的過程。該組裝過程包含了大量數(shù)據(jù)拷貝工作。為了減少拷貝次數(shù)，網(wǎng)絡(luò)接口利用分散/聚集 I/O 的方法將網(wǎng)絡(luò)數(shù)據(jù)直接從用戶空間緩沖區(qū)傳輸出來，實(shí)現(xiàn)“零拷貝”。因?yàn)镵OTOM 模塊在內(nèi)核態(tài)執(zhí)行，而內(nèi)核態(tài)的數(shù)據(jù)片段存放地址是分散的，所以KOTOM 模塊在提取請求的路徑之前，需要利用skb_linearize 將多個(gè)數(shù)據(jù)片段合并在一起，實(shí)現(xiàn)數(shù)據(jù)線性化。否則，KOTOM 模塊無法提取請求路徑。

（3）緩存查找。通過調(diào)用函數(shù)node_path_search 并遍歷紅黑樹，watch_in 嘗試在緩存區(qū)中找到對應(yīng)內(nèi)容。如果在緩存中找到了匹配的內(nèi)容，watch_in 首先會(huì)重置temp_path 為NULL，清除之前保存的路徑。接下來，為了直接從內(nèi)核態(tài)中將已緩存的數(shù)據(jù)快速返回給客戶端，避免不必要的用戶態(tài)和內(nèi)核態(tài)之間的切換，watch_in 會(huì)構(gòu)造一個(gè)新的數(shù)據(jù)包new_skb，new_skb 會(huì)將內(nèi)容發(fā)送回客戶端。除內(nèi)容本身外，new_skb 的其他字段（如源地址、目的地址等）會(huì)根據(jù)實(shí)際需求進(jìn)行填充。數(shù)據(jù)包構(gòu)建完成后，使用dev_queue_xmit 函數(shù)將new_skb 從服務(wù)器的網(wǎng)卡發(fā)送至客戶端。如果未在緩存中找到請求的數(shù)據(jù)，watch_in 直接返回NF_ACCEPT，將請求數(shù)據(jù)包交給目標(biāo)虛擬機(jī)處理。

圖8 描述了函數(shù)watch_out 的執(zhí)行邏輯：①報(bào)文過濾：watch_out 開始時(shí)會(huì)通過條件判斷來過濾掉非內(nèi)容的報(bào)文；②內(nèi)容保存：當(dāng)確定接收到的是一個(gè)內(nèi)容報(bào)文后，watch_out 會(huì)檢查“temp_path”是否為空。非空狀態(tài)表示當(dāng)前報(bào)文與之前在watch_in 中捕獲的請求報(bào)文有關(guān)。在此情況下，watch_out 會(huì)調(diào)用函數(shù)obj_create 將數(shù)據(jù)報(bào)文中的數(shù)據(jù)部分保存至緩存區(qū)，并為未來的相同請求提供快速響應(yīng)。最后“temp_path”會(huì)被重新設(shè)為NULL，為處理下一個(gè)請求作好準(zhǔn)備。

Fig.8 watch_out process flow圖8 watch_out 流程

2 實(shí)驗(yàn)與分析

2.1 實(shí)驗(yàn)環(huán)境

如圖9 所示，實(shí)驗(yàn)使用了一臺Windows 主機(jī)A 作為請求客戶端，一臺安裝了KVM 虛擬機(jī)的主機(jī)B 作為部署KOTOM 的云服務(wù)器。主機(jī)A 負(fù)責(zé)發(fā)送HTTP 請求。主機(jī)B安裝一臺虛擬機(jī)，使用Apache httpd 作為HTTP 服務(wù)器，負(fù)責(zé)接收客戶端發(fā)出的HTTP 請求并返回相應(yīng)內(nèi)容。

Fig.9 Experiment environment圖9 實(shí)驗(yàn)環(huán)境

具體配置如下：

（1）客戶端（TPC-W Client 端）：物理機(jī)。操作系統(tǒng)：Windows 7；處理器：i5-6300U，2.40GHz。

（2）服務(wù)器（TPC-W Server 端）：物理機(jī)。操作系統(tǒng)：CentOS 7.9；內(nèi)核版本：5.9。

（3）虛擬機(jī)：KVM。操作系統(tǒng)：CentOS 7.9；內(nèi)核版本：3.10。

當(dāng)需要使用KOTOM 方法時(shí)，將KOTOM 內(nèi)核模塊加載到主機(jī)B 的Linux 內(nèi)核中。當(dāng)HTTP 請求報(bào)文到達(dá)主機(jī)B時(shí)，內(nèi)核會(huì)攔截并解析報(bào)文，獲取請求路徑并在緩存區(qū)中進(jìn)行搜索。如果緩存區(qū)中已存在對應(yīng)內(nèi)容，內(nèi)核會(huì)直接創(chuàng)建一個(gè)包含所需內(nèi)容的報(bào)文，并將其返回給客戶端，而不再繼續(xù)發(fā)送攔截的請求報(bào)文至KVM 虛擬機(jī)。

若緩存區(qū)不存在對應(yīng)內(nèi)容，攔截的請求報(bào)文將被繼續(xù)發(fā)送至KVM 虛擬機(jī)。當(dāng)從KVM 虛擬機(jī)返回的內(nèi)容報(bào)文經(jīng)過內(nèi)核時(shí)，報(bào)文會(huì)被攔截和解析，解析得到的內(nèi)容將被保存在內(nèi)核的緩存區(qū)中。因此，當(dāng)下一次客戶端發(fā)送相同的HTTP 請求時(shí)，內(nèi)容將不再需要從KVM 虛擬機(jī)返回，而是直接從內(nèi)核返回。通過該實(shí)驗(yàn)環(huán)境，能夠直觀地展示與驗(yàn)證高效緩存模塊在提高數(shù)據(jù)響應(yīng)速度和降低CPU 利用率方面的有效性。

2.2 實(shí)驗(yàn)設(shè)置

為了評估高效緩存模塊在提高數(shù)據(jù)響應(yīng)速度和降低CPU 利用率方面的有效性，本文采用TPC-W［23］進(jìn)行實(shí)驗(yàn)。TPC-W（Transaction Processing Performance Council's Web Benchmark）是一個(gè)廣泛應(yīng)用于Web 服務(wù)器性能評估的基準(zhǔn)測試。其通過模擬真實(shí)世界的Web 應(yīng)用負(fù)載來生成一系列典型的HTTP 請求，從而為服務(wù)器性能提供一個(gè)標(biāo)準(zhǔn)化的衡量標(biāo)準(zhǔn)。

在實(shí)驗(yàn)中，本文分別部署了TPC-W Client 端和Server端，并采用靜態(tài)數(shù)據(jù)模擬真實(shí)的HTTP 請求。在實(shí)驗(yàn)過程中，Client 端向Server 端發(fā)送HTTP 請求，請求次數(shù)可根據(jù)實(shí)際需求進(jìn)行設(shè)定。首先，CPU 利用率可通過Linux 的top指令進(jìn)行觀測并記錄。然后，客戶端在發(fā)送請求的同時(shí)開始計(jì)時(shí)，請求結(jié)束后計(jì)時(shí)器停止計(jì)時(shí)并輸出響應(yīng)時(shí)間。最后通過數(shù)據(jù)量與響應(yīng)時(shí)間計(jì)算響應(yīng)速度，如式（1）所示。

本文在實(shí)驗(yàn)中測試了不同請求次數(shù)下，模塊加載前后的數(shù)據(jù)響應(yīng)時(shí)間和CPU 利用率。在相同的請求次數(shù)下，本文進(jìn)行了10 組數(shù)據(jù)測試，以計(jì)算平均值、最高值和最低值。最后，根據(jù)實(shí)驗(yàn)數(shù)據(jù)繪制了CPU 利用率和響應(yīng)速度的折線圖，并通過正負(fù)偏差表示10 組數(shù)據(jù)中的最高值和最低值。實(shí)驗(yàn)指標(biāo)包括數(shù)據(jù)響應(yīng)速度和CPU 利用率，以此評估KOTOM 方法在不同工作負(fù)載下的性能表現(xiàn)。通過對比模塊加載前后的實(shí)驗(yàn)結(jié)果，可以得出KOTOM 方法對服務(wù)器性能的影響。

此外，還對StackMap 方法、Direct IRQ 方法和本文的KOTOM 方法進(jìn)行了對比測試。

2.3 實(shí)驗(yàn)結(jié)果

KOTOM 模塊加載前后的CPU 利用率與響應(yīng)速度如圖10所示。

Fig.10 CPU utilization and response speed before and after KOTOM module loading圖10 KOTOM 模塊加載前后的CPU利用率與響應(yīng)速度

由圖10（a）可以看出，在請求次數(shù)小于500 次時(shí)，模塊加載前后的CPU 利用率都隨著請求次數(shù)的增加而上升，表明在請求次數(shù)較少時(shí)，CPU 利用率與請求次數(shù)呈正相關(guān)。同時(shí)，在相同的請求次數(shù)下，10 組數(shù)據(jù)中最高值和最低值的差異較大，說明在請求次數(shù)較少時(shí)，CPU 利用率的不確定性較大。當(dāng)請求次數(shù)超過500 次后，模塊加載前的CPU利用率穩(wěn)定在約35%，而模塊加載后的CPU 利用率穩(wěn)定在約28%?？傊诓煌埱蟠螖?shù)下，模塊加載前的CPU 利用率都會(huì)比模塊加載后高約7%。

由圖10（b）可以看出，模塊加載后的響應(yīng)速度在模塊加載前響應(yīng)速度的基礎(chǔ)上提升了約22%。在請求次數(shù)較少時(shí)，KOTOM 方法的響應(yīng)速度更快。另外，圖中的正負(fù)偏差揭示了在請求次數(shù)較少時(shí)，不論在模塊加載前還是加載后，響應(yīng)速度的不確定性都較大；而在請求次數(shù)較多時(shí)，響應(yīng)速度逐漸穩(wěn)定?？傮w而言，無論請求次數(shù)多少，模塊加載后的響應(yīng)速度都明顯高于加載前。

對應(yīng)用不同方法的CPU 利用率與響應(yīng)速度進(jìn)行比較，如圖11所示。

Fig.11 CPU utilization and response speed under different methods圖11 應(yīng)用不同方法的CPU利用率與響應(yīng)速度

由圖11（a）可見，應(yīng)用StackMap 方法與加載前的CPU利用率區(qū)別不大。應(yīng)用Direct IRQ 方法的CPU 利用率低于加載前，但當(dāng)負(fù)載增加時(shí)，該差異逐漸縮小。這是因?yàn)镈irect IRQ 要將網(wǎng)卡直接分配給虛擬機(jī)，當(dāng)存在大量虛擬機(jī)且網(wǎng)絡(luò)負(fù)載較高時(shí)，會(huì)帶來較大的附加開銷。StackMap 方法通過優(yōu)化操作系統(tǒng)內(nèi)核棧與專用網(wǎng)卡間的互動(dòng)，有效降低了網(wǎng)絡(luò)延遲，但在普通網(wǎng)卡上優(yōu)化效果并不顯著。KOTOM 方法針對性地解決了用戶態(tài)與內(nèi)核態(tài)之間頻繁切換造成的資源損耗問題，因而具有相對較低的CPU 利用率。

圖11（b）展示了應(yīng)用不同方法的響應(yīng)速度，可見應(yīng)用3 種方法的響應(yīng)速度相較于加載前都有不同程度的提升。然而，應(yīng)用StackMap 方法在普通網(wǎng)卡下的提升效果不明顯。應(yīng)用Direct IRQ 方法的CPU 資源開銷較大，會(huì)間接影響請求的響應(yīng)速度。在CPU 利用率較低的情況下，KOTOM 方法能夠使響應(yīng)速度明顯提升。

2.4 技術(shù)分析與討論

本文在引言部分提出了3 個(gè)主要的創(chuàng)新點(diǎn)，其對于提高Linux 服務(wù)器在虛擬化環(huán)境中的響應(yīng)速度及降低CPU 利用率起到了關(guān)鍵作用，在此總結(jié)這3 個(gè)創(chuàng)新點(diǎn)的技術(shù)內(nèi)涵以及對實(shí)驗(yàn)效果的影響。

（1）Linux TCP/IP 解析流程優(yōu)化。傳統(tǒng)的Linux TCP/IP解析流程在多個(gè)網(wǎng)絡(luò)協(xié)議層次之間需要進(jìn)行多次的解析和封裝操作，無疑增加了數(shù)據(jù)處理的復(fù)雜性和時(shí)間開銷。KOTOM 方法對TCP/IP 解析流程進(jìn)行了優(yōu)化，直接在內(nèi)核態(tài)實(shí)現(xiàn)報(bào)文的解析，從而避免了在不同協(xié)議層之間的頻繁轉(zhuǎn)換。這種直接的解析方式不僅加快了數(shù)據(jù)包的處理速度，而且減少了不必要的數(shù)據(jù)包復(fù)制和內(nèi)存使用。

（2）內(nèi)核態(tài)緩存機(jī)制。在傳統(tǒng)的數(shù)據(jù)處理流程中，數(shù)據(jù)經(jīng)常在用戶態(tài)和內(nèi)核態(tài)之間進(jìn)行切換，這種切換帶來的額外開銷對系統(tǒng)性能有很大影響。為優(yōu)化這一流程，本文建立了內(nèi)核態(tài)緩存機(jī)制，將經(jīng)常訪問的數(shù)據(jù)直接保存在內(nèi)核態(tài)，從而避免了數(shù)據(jù)在用戶態(tài)和內(nèi)核態(tài)之間的頻繁切換。該方法降低了CPU 利用率，提高了系統(tǒng)整體效率。此外，這也意味著對于某些高頻訪問的數(shù)據(jù)，不需要再從硬盤或其他存儲(chǔ)介質(zhì)中讀取，因而大大加快了數(shù)據(jù)訪問速度。

（3）動(dòng)態(tài)自適應(yīng)緩存替換策略。KOTOM 采用經(jīng)典的LRU（最近最少使用）算法作為其緩存替換策略。LRU 策略的核心是當(dāng)緩存空間不足時(shí)，優(yōu)先替換最長時(shí)間未被訪問的數(shù)據(jù)，從而確保經(jīng)常被訪問的數(shù)據(jù)始終保留在緩存中，提高了緩存利用效率。

3 結(jié)語

本文提出一種基于內(nèi)核態(tài)的TCP/IP 數(shù)據(jù)處理優(yōu)化方法（KOTOM），目的是提高面向虛擬化環(huán)境的Linux 服務(wù)器響應(yīng)速度，并降低服務(wù)器的CPU 利用率。通過對內(nèi)核模塊的設(shè)計(jì)與實(shí)現(xiàn)，以及在掛鉤NF_INET_FORWARD、NF_INET_POST_ROUTING 處建立掛鉤函數(shù)watch_in 和watch_out實(shí)現(xiàn)報(bào)文的捕獲與轉(zhuǎn)發(fā)，可實(shí)現(xiàn)在內(nèi)核態(tài)中高效地處理數(shù)據(jù)。在實(shí)驗(yàn)部分對比了模塊加載前后的響應(yīng)速度和CPU利用率，結(jié)果表明，模塊加載后的響應(yīng)速度明顯高于加載前。同時(shí)，無論請求次數(shù)多少，模塊加載后的CPU 利用率都較加載前有所降低，證實(shí)了本文設(shè)計(jì)的高效緩存模塊在提升服務(wù)器性能方面的有效性。

本文提出的基于Linux 內(nèi)核的KOTOM 方法在提高響應(yīng)速度和降低CPU 利用率方面取得了顯著成果。該方法適用于虛擬化環(huán)境下的HTTP 靜態(tài)資源訪問場景，在此場景下對讀取速度有要求時(shí)，該方法可以簡化協(xié)議解析流程，減少用戶態(tài)與內(nèi)核態(tài)之間的切換次數(shù)，提高數(shù)據(jù)請求效率。雖然KOTOM 方法目前尚不適用于動(dòng)態(tài)數(shù)據(jù)請求較多或數(shù)據(jù)寫請求較多的場景，但該方法具有擴(kuò)展性。通過對其進(jìn)行改進(jìn)和優(yōu)化，比如增加其他協(xié)議類型的支持，使其不僅能服務(wù)于HTTP 請求，而且能為諸如HDFS 等系統(tǒng)提供支持，或者采用針對動(dòng)態(tài)數(shù)據(jù)的緩存替換策略實(shí)時(shí)更新KOTOM 模塊在內(nèi)核保存的熱點(diǎn)數(shù)據(jù)，從而適應(yīng)動(dòng)態(tài)數(shù)據(jù)請求較多的場景。通過這些改進(jìn)和優(yōu)化，KOTOM 可以成為一個(gè)更加全面、高效的解決方案，在更廣泛的應(yīng)用場景中展現(xiàn)其價(jià)值。