一種面向虛擬化環(huán)境的Linux TCP/IP流程優(yōu)化方法

翁 創(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èn)等場(chǎng)景中，服務(wù)器經(jīng)常采用虛擬機(jī)的方式進(jìn)行部署。該方式有助于提高數(shù)據(jù)的可靠性和安全性，同時(shí)便于備份［4］。

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

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

為了解決上述問(wèn)題，本文提出一種基于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 請(qǐng)求和服務(wù)器響應(yīng)，并建立被請(qǐng)求資源的緩存，通過(guò)LRU 算法實(shí)現(xiàn)熱點(diǎn)資源的緩存替換，從而降低TCP/IP 協(xié)議處理過(guò)程中資源在內(nèi)核態(tài)與用戶態(tài)之間傳遞帶來(lái)的性能開(kāi)銷。實(shí)驗(yàn)結(jié)果表明，該方法成功地節(jié)省了服務(wù)器計(jì)算資源，并縮短了請(qǐng)求時(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ù)請(qǐng)求熱點(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)狀，以下對(duì)一些與本文主題相關(guān)的工作進(jìn)行了回顧。

Yasukata 等［9］為解決操作系統(tǒng)內(nèi)核棧和專用網(wǎng)卡（NICs）之間交互性能的問(wèn)題，提出了StackMap 方法。該方法通過(guò)優(yōu)化操作系統(tǒng)內(nèi)核棧和專用網(wǎng)卡（NICs）之間的交互來(lái)降低網(wǎng)絡(luò)延遲。其分析了現(xiàn)有內(nèi)核棧和網(wǎng)卡的通信過(guò)程，發(fā)現(xiàn)了一系列可以優(yōu)化的點(diǎn)。這項(xiàng)工作對(duì)于理解內(nèi)核棧和網(wǎng)卡之間通信過(guò)程的優(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ī)制，通過(guò)降低用戶態(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)過(guò)虛擬機(jī)監(jiān)控器。與本文的研究相比，其主要是通過(guò)Direct IRQ 技術(shù)達(dá)到優(yōu)化效果。該方法將網(wǎng)卡直接分配給虛擬機(jī)，本文方法不將網(wǎng)卡直接分配給虛擬機(jī)，而是通過(guò)虛擬機(jī)監(jiān)控器緩存靜態(tài)數(shù)據(jù)實(shí)現(xiàn)優(yōu)化效果。KOTOM 方法針對(duì)性地解決了用戶態(tài)和內(nèi)核態(tài)之間頻繁切換帶來(lái)的資源開(kāi)銷問(wèn)題，并且引入了紅黑樹(shù)和LRU 策略，進(jìn)一步提高了緩存查找和使用效率，從而使性能得到顯著提升。

劉禹燕等［11］詳細(xì)介紹了Virtio 框架的基本原理，闡述了該框架如何實(shí)現(xiàn)半虛擬化環(huán)境下的高性能網(wǎng)絡(luò)通信。通過(guò)對(duì)Virtio 框架中的數(shù)據(jù)傳輸和緩存策略進(jìn)行優(yōu)化，實(shí)現(xiàn)了在半虛擬化環(huán)境下更高效的網(wǎng)絡(luò)請(qǐng)求處理。該項(xiàng)工作為提高虛擬化環(huán)境中的網(wǎng)絡(luò)性能提供了實(shí)際的解決方案。與本文方法相比，該研究主要關(guān)注半虛擬化環(huán)境下的網(wǎng)絡(luò)通信性能優(yōu)化，而本文方法適用于全虛擬化環(huán)境，通過(guò)優(yōu)化內(nèi)核態(tài)TCP/IP 數(shù)據(jù)處理和緩存策略，提高云服務(wù)器在虛擬化環(huán)境中的性能。本文方法不僅針對(duì)性地解決了用戶態(tài)和內(nèi)核態(tài)之間頻繁切換帶來(lái)的資源開(kāi)銷問(wèn)題，而且提出一種根據(jù)請(qǐng)求熱點(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é)議層次對(duì)報(bào)文進(jìn)行逐層解析。具體來(lái)說(shuō)，報(bào)文從物理層開(kāi)始，逐級(jí)經(jīng)過(guò)數(shù)據(jù)鏈路層、網(wǎng)絡(luò)層、傳輸層，最終達(dá)到應(yīng)用層［12］。如圖2 所示，實(shí)線代表服務(wù)器內(nèi)核在解析請(qǐng)求和發(fā)送數(shù)據(jù)時(shí)的傳統(tǒng)模式。在該模式下，當(dāng)服務(wù)器收到一個(gè)TCP 請(qǐng)求時(shí)，請(qǐng)求報(bào)文首先在內(nèi)核態(tài)被各個(gè)協(xié)議層進(jìn)行處理，之后傳輸層（例如TCP 層）處理完的報(bào)文會(huì)傳遞給用戶態(tài)的socket進(jìn)行深入分析。在應(yīng)用層處理完請(qǐng)求后，其會(huì)將響應(yīng)報(bào)文再次傳遞給內(nèi)核態(tài)，以便進(jìn)行下行傳輸。在此過(guò)程中，內(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í)間開(kāi)銷。此外，報(bào)文在逐層解析時(shí)需多次進(jìn)行封裝與解封裝，增大了處理過(guò)程的復(fù)雜性和附加開(kāi)銷［13］。因此，在傳統(tǒng)的數(shù)據(jù)傳輸模式下，服務(wù)器性能往往受到用戶態(tài)與內(nèi)核態(tài)頻繁切換以及報(bào)文逐層解析所帶來(lái)的資源與時(shí)間消耗的影響。

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

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

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

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

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

完成這些步驟后，new_skb 被發(fā)送至原先發(fā)出數(shù)據(jù)請(qǐng)求的主機(jī)。值得注意的是，在整個(gè)請(qǐng)求流程中，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ù)請(qǐng)求發(fā)生時(shí)，相關(guān)內(nèi)容能直接從內(nèi)存中提取。為了合理使用服務(wù)器內(nèi)存并確保其穩(wěn)定性，必須對(duì)緩存區(qū)的大小進(jìn)行限制。首先，確定緩存區(qū)的最大容量。當(dāng)緩存區(qū)的總?cè)萘窟_(dá)到此上限時(shí)，低頻訪問(wèn)的內(nèi)容將被新數(shù)據(jù)所替代。為此，基于實(shí)驗(yàn)，本文選擇了一個(gè)適宜的緩存替換策略。其次，為簡(jiǎn)化內(nèi)容管理，緩存區(qū)采用一個(gè)稱為obj 的內(nèi)容存儲(chǔ)對(duì)象，該對(duì)象包含內(nèi)容名稱、大小、實(shí)體、請(qǐng)求路徑以及訪問(wèn)時(shí)間等信息。最終，為緩存區(qū)設(shè)計(jì)了一套API，實(shí)現(xiàn)存儲(chǔ)對(duì)象插入和基于路徑的對(duì)象檢索等功能。

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

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

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

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

為了高效地管理緩存區(qū)，本文需要提供API 以實(shí)現(xiàn)對(duì)象的插入、刪除和查找功能。以插入功能為例，每當(dāng)新的存儲(chǔ)對(duì)象被創(chuàng)建，內(nèi)核必須為其各成員（例如“對(duì)象名稱”、“數(shù)據(jù)”和“路徑”）以及對(duì)象本體動(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)緩存對(duì)象的動(dòng)態(tài)創(chuàng)建，本文引入名為obj_create 的API，并借助kmalloc 來(lái)申請(qǐng)必要的內(nèi)存。圖4 詳細(xì)展示了obj_create 的工作流程。首先，任何超過(guò)緩存區(qū)容量的數(shù)據(jù)都不能被保存；其次，如果當(dāng)前的緩存空間不足，LRU_search 會(huì)遍歷紅黑樹(shù)，定位到最近最少被使用的對(duì)象并通過(guò)node_delete 進(jìn)行刪除，此過(guò)程會(huì)重復(fù)，直至釋放足夠的空間給新對(duì)象；最后，obj_insert 會(huì)將新對(duì)象加入緩存區(qū)。

Fig.4 obj_create process flow圖4 obj_create流程

在KOTOM 方法中，多個(gè)API 包括obj_create，都依賴于node_search 來(lái)查找特定的存儲(chǔ)對(duì)象。node_search 能夠僅憑請(qǐng)求路徑高效定位和訪問(wèn)整個(gè)存儲(chǔ)對(duì)象，主要?dú)w功于其使用的container_of 宏來(lái)識(shí)別存儲(chǔ)對(duì)象的起始地址。在Linux 內(nèi)核中，container_of 是一個(gè)特別設(shè)計(jì)的宏，其允許通過(guò)已知結(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 的額外開(kāi)銷，提供了一種效率極高的數(shù)據(jù)處理模式。但在實(shí)踐中，實(shí)時(shí)的緩存區(qū)域管理和模塊參數(shù)監(jiān)視是不可或缺的。頻繁地加載、卸載或調(diào)試內(nèi)核模塊不僅繁瑣，而且可能帶來(lái)潛在的系統(tǒng)風(fēng)險(xiǎn)。為此，本文采用sysfs 接口，以實(shí)現(xiàn)用戶態(tài)與內(nèi)核態(tài)之間順暢的數(shù)據(jù)交互。sysfs 不僅便于對(duì)緩存區(qū)域和參數(shù)的管理監(jiān)控，而且能確保所有內(nèi)容處理始終在內(nèi)核態(tài)下進(jìn)行。這一設(shè)計(jì)平衡了實(shí)時(shí)監(jiān)控與高效處理的需求，對(duì)系統(tǒng)的穩(wěn)定性和可維護(hù)性都帶來(lái)了積極影響，成為實(shí)施KOTOM 方法的關(guān)鍵策略。

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

在模塊的執(zhí)行階段，本文寄望于對(duì)緩存區(qū)的幾個(gè)關(guān)鍵參數(shù)進(jìn)行實(shí)時(shí)管理和監(jiān)控：容量上限（cache_size）、剩余容量（free_space）、對(duì)象總數(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ù)來(lái)完成數(shù)據(jù)的讀寫(xiě)操作。內(nèi)核將此4 個(gè)關(guān)鍵參數(shù)以文件的形式傳至用戶態(tài)，使得用戶可以直接通過(guò)這些文件來(lái)管理和調(diào)整參數(shù)。該設(shè)計(jì)巧妙地建立了內(nèi)核與用戶間的通信橋梁，大大簡(jiǎn)化了對(duì)緩存區(qū)的管理和監(jiān)控。因此，用戶能夠便捷地訪問(wèn)和調(diào)整這些關(guān)鍵參數(shù)，從而實(shí)時(shí)了解并控制緩存區(qū)狀態(tài)。

1.4 整體架構(gòu)

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

圖5 詳細(xì)展示了Linux 內(nèi)核中Netfilter 的核心架構(gòu)［21］。在請(qǐng)求報(bào)文到達(dá)服務(wù)器時(shí)，服務(wù)器的網(wǎng)卡首先捕獲這一報(bào)文，并迅速將其交付給Netfilter 進(jìn)行處理。隨后，Netfilter的ip_rcv 函數(shù)會(huì)介入，并對(duì)請(qǐng)求報(bào)文執(zhí)行系列操作，如校驗(yàn)報(bào)文的完整性、對(duì)其進(jìn)行解碼，并進(jìn)行必要的前期處理等。接下來(lái)，處理后的請(qǐng)求報(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é)將請(qǐng)求報(bào)文準(zhǔn)確地投遞到預(yù)定的虛擬機(jī)中。值得注意的是，報(bào)文在傳輸過(guò)程中會(huì)依序經(jīng)過(guò)Netfilter 的兩個(gè)關(guān)鍵掛鉤點(diǎn)，即NF_INET_PRE_ROUTING 和NF_INET_FORWARD。

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

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

當(dāng)需要攔截請(qǐ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ì)策略巧妙地避開(kāi)了不必要的數(shù)據(jù)包處理過(guò)程，從而大大提升了整體的處理效率。

為了確保請(qǐng)求和響應(yīng)的完整捕獲與高效處理，本文還在NF_INET_POST_ROUTING 掛鉤點(diǎn)設(shè)置了另一個(gè)掛鉤函數(shù)，名為watch_out。該函數(shù)的主要任務(wù)是對(duì)內(nèi)容進(jìn)行緩存操作。具體的架構(gòu)和流程可參考圖6。圖6 明確展示了請(qǐng)求和響應(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ā)出的請(qǐng)求報(bào)文通過(guò)路由1 并到達(dá)轉(zhuǎn)發(fā)的掛鉤點(diǎn)時(shí)，掛鉤函數(shù)watch_in 立即捕獲該報(bào)文。其首先解析報(bào)文，提取請(qǐng)求路徑，并在緩存區(qū)查找是否存在與請(qǐng)求路徑匹配的內(nèi)容。根據(jù)查找結(jié)果，會(huì)有以下兩種可能的情況：①緩存命中：如果緩存區(qū)中已有與請(qǐng)求路徑匹配的內(nèi)容，這些內(nèi)容將被直接提取出來(lái)，繞過(guò)目標(biāo)虛擬機(jī)，直接傳遞給函數(shù)dev_queue_xmit 進(jìn)行打包，并快速轉(zhuǎn)發(fā)給客戶端。這期間原先被捕獲的請(qǐng)求報(bào)文因?yàn)橐呀?jīng)得到了響應(yīng)，會(huì)被直接丟棄；②緩存未命中：當(dāng)緩存區(qū)中沒(méi)有與請(qǐng)求路徑匹配的內(nèi)容時(shí)，watch_in 不會(huì)立即作出反應(yīng)，而是允許該請(qǐng)求報(bào)文繼續(xù)通過(guò)路由2 被轉(zhuǎn)發(fā)到目標(biāo)虛擬機(jī)。當(dāng)目標(biāo)虛擬機(jī)生成響應(yīng)并通過(guò)函數(shù)ip_output 處理完畢后，掛鉤函數(shù)watch_out 會(huì)捕獲該響應(yīng)內(nèi)容。在dev_queue_xmit 將響應(yīng)報(bào)文轉(zhuǎn)發(fā)給客戶端之前，watch_out 首先將其保存到緩存區(qū)中，從而為未來(lái)的相同請(qǐng)求提供快速響應(yīng)。需要注意的是，無(wú)論緩存是否命中，報(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)文過(guò)濾。watch_in 的第一步是區(qū)分并過(guò)濾掉那些非HTTP 請(qǐng)求的數(shù)據(jù)包，以確保只處理對(duì)緩存有意義的請(qǐng)求報(bào)文。在真實(shí)的網(wǎng)絡(luò)場(chǎng)景下，watch_in 可以通過(guò)IP 目的地址、端口號(hào)和統(tǒng)一資源標(biāo)識(shí)符（Uniform Resource Identifier，URI）過(guò)濾掉非HTTP 請(qǐng)求的數(shù)據(jù)包。

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

（3）緩存查找。通過(guò)調(diào)用函數(shù)node_path_search 并遍歷紅黑樹(shù)，watch_in 嘗試在緩存區(qū)中找到對(duì)應(yīng)內(nèi)容。如果在緩存中找到了匹配的內(nèi)容，watch_in 首先會(huì)重置temp_path 為NULL，清除之前保存的路徑。接下來(lái)，為了直接從內(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ā)送至客戶端。如果未在緩存中找到請(qǐng)求的數(shù)據(jù)，watch_in 直接返回NF_ACCEPT，將請(qǐng)求數(shù)據(jù)包交給目標(biāo)虛擬機(jī)處理。

圖8 描述了函數(shù)watch_out 的執(zhí)行邏輯：①報(bào)文過(guò)濾：watch_out 開(kāi)始時(shí)會(huì)通過(guò)條件判斷來(lái)過(guò)濾掉非內(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 中捕獲的請(qǐng)求報(bào)文有關(guān)。在此情況下，watch_out 會(huì)調(diào)用函數(shù)obj_create 將數(shù)據(jù)報(bào)文中的數(shù)據(jù)部分保存至緩存區(qū)，并為未來(lái)的相同請(qǐng)求提供快速響應(yīng)。最后“temp_path”會(huì)被重新設(shè)為NULL，為處理下一個(gè)請(qǐng)求作好準(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)使用了一臺(tái)Windows 主機(jī)A 作為請(qǐng)求客戶端，一臺(tái)安裝了KVM 虛擬機(jī)的主機(jī)B 作為部署KOTOM 的云服務(wù)器。主機(jī)A 負(fù)責(zé)發(fā)送HTTP 請(qǐng)求。主機(jī)B安裝一臺(tái)虛擬機(jī)，使用Apache httpd 作為HTTP 服務(wù)器，負(fù)責(zé)接收客戶端發(fā)出的HTTP 請(qǐng)求并返回相應(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 請(qǐng)求報(bào)文到達(dá)主機(jī)B時(shí)，內(nèi)核會(huì)攔截并解析報(bào)文，獲取請(qǐng)求路徑并在緩存區(qū)中進(jìn)行搜索。如果緩存區(qū)中已存在對(duì)應(yīng)內(nèi)容，內(nèi)核會(huì)直接創(chuàng)建一個(gè)包含所需內(nèi)容的報(bào)文，并將其返回給客戶端，而不再繼續(xù)發(fā)送攔截的請(qǐng)求報(bào)文至KVM 虛擬機(jī)。

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

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

為了評(píng)估高效緩存模塊在提高數(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ù)器性能評(píng)估的基準(zhǔn)測(cè)試。其通過(guò)模擬真實(shí)世界的Web 應(yīng)用負(fù)載來(lái)生成一系列典型的HTTP 請(qǐng)求，從而為服務(wù)器性能提供一個(gè)標(biāo)準(zhǔn)化的衡量標(biāo)準(zhǔn)。

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

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

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

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）可以看出，在請(qǐng)求次數(shù)小于500 次時(shí)，模塊加載前后的CPU 利用率都隨著請(qǐng)求次數(shù)的增加而上升，表明在請(qǐng)求次數(shù)較少時(shí)，CPU 利用率與請(qǐng)求次數(shù)呈正相關(guān)。同時(shí)，在相同的請(qǐng)求次數(shù)下，10 組數(shù)據(jù)中最高值和最低值的差異較大，說(shuō)明在請(qǐng)求次數(shù)較少時(shí)，CPU 利用率的不確定性較大。當(dāng)請(qǐng)求次數(shù)超過(guò)500 次后，模塊加載前的CPU利用率穩(wěn)定在約35%，而模塊加載后的CPU 利用率穩(wěn)定在約28%。總之，在不同請(qǐng)求次數(shù)下，模塊加載前的CPU 利用率都會(huì)比模塊加載后高約7%。

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

對(duì)應(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）可見(jiàn)，應(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ì)帶來(lái)較大的附加開(kāi)銷。StackMap 方法通過(guò)優(yōu)化操作系統(tǒng)內(nèi)核棧與專用網(wǎng)卡間的互動(dòng)，有效降低了網(wǎng)絡(luò)延遲，但在普通網(wǎng)卡上優(yōu)化效果并不顯著。KOTOM 方法針對(duì)性地解決了用戶態(tài)與內(nèi)核態(tài)之間頻繁切換造成的資源損耗問(wèn)題，因而具有相對(duì)較低的CPU 利用率。

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

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

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

（1）Linux TCP/IP 解析流程優(yōu)化。傳統(tǒng)的Linux TCP/IP解析流程在多個(gè)網(wǎng)絡(luò)協(xié)議層次之間需要進(jìn)行多次的解析和封裝操作，無(wú)疑增加了數(shù)據(jù)處理的復(fù)雜性和時(shí)間開(kāi)銷。KOTOM 方法對(duì)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)行切換，這種切換帶來(lái)的額外開(kāi)銷對(duì)系統(tǒng)性能有很大影響。為優(yōu)化這一流程，本文建立了內(nèi)核態(tài)緩存機(jī)制，將經(jīng)常訪問(wèn)的數(shù)據(jù)直接保存在內(nèi)核態(tài)，從而避免了數(shù)據(jù)在用戶態(tài)和內(nèi)核態(tài)之間的頻繁切換。該方法降低了CPU 利用率，提高了系統(tǒng)整體效率。此外，這也意味著對(duì)于某些高頻訪問(wèn)的數(shù)據(jù)，不需要再?gòu)挠脖P或其他存儲(chǔ)介質(zhì)中讀取，因而大大加快了數(shù)據(jù)訪問(wèn)速度。

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

3 結(jié)語(yǔ)

本文提出一種基于內(nèi)核態(tài)的TCP/IP 數(shù)據(jù)處理優(yōu)化方法（KOTOM），目的是提高面向虛擬化環(huán)境的Linux 服務(wù)器響應(yīng)速度，并降低服務(wù)器的CPU 利用率。通過(guò)對(duì)內(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)部分對(duì)比了模塊加載前后的響應(yīng)速度和CPU利用率，結(jié)果表明，模塊加載后的響應(yīng)速度明顯高于加載前。同時(shí)，無(wú)論請(qǐng)求次數(shù)多少，模塊加載后的CPU 利用率都較加載前有所降低，證實(shí)了本文設(shè)計(jì)的高效緩存模塊在提升服務(wù)器性能方面的有效性。

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