詹昱辰，馮巍巍，譚小彬

中國科學(xué)技術(shù)大學(xué)信息科學(xué)技術(shù)學(xué)院自動化系，安徽 合肥 230022

引 言

在信息量爆炸式增長的互聯(lián)網(wǎng)時(shí)代，人們幾乎每天都在瀏覽網(wǎng)絡(luò)且基本上是通過瀏覽器?；ヂ?lián)網(wǎng)用戶每天都會瀏覽大量的網(wǎng)頁信息和視頻信息，而目前大約80%的互聯(lián)網(wǎng)流量都是視頻。當(dāng)瀏覽者在網(wǎng)絡(luò)上觀看視頻時(shí)，大量的流量都是以HTTP 流量的形式流動的。因此每天，都有巨量的網(wǎng)頁信息或視頻數(shù)據(jù)通過HTTP 傳輸，這就促使多數(shù)網(wǎng)站都要投入大量的工作來優(yōu)化HTTP 流量的傳輸，以防止網(wǎng)站宕機(jī)。因此，優(yōu)化當(dāng)前的HTTP 傳輸通信，從公司的盈利能力或是用戶的瀏覽體驗(yàn)來看，是十分必要的。

HTTP（超文本傳輸協(xié)議）[1]是一種廣泛使用的應(yīng)用層協(xié)議，且針對它已經(jīng)做了很多優(yōu)化。例如，各種HTTP 設(shè)施（例如CDN，HTTP 代理和WEB 緩存）早已部署在因特網(wǎng)之中[2]，使現(xiàn)有的問題得到部分緩解。但是，盡管現(xiàn)在已經(jīng)有許多公司提供了大量的基礎(chǔ)設(shè)施，在一定程度上改善了HTTP 的使用體驗(yàn)，當(dāng)前的HTTP 工作上仍然存在著許多瓶頸：

（1）HTTP 依賴于基礎(chǔ)的TCP / IP 體系結(jié)構(gòu)，這導(dǎo)致HTTP 具有TCP / IP 體系結(jié)構(gòu)的窄腰特性。TCP / IP 體系結(jié)構(gòu)中的通訊基本單位，是由IP 地址所標(biāo)識的兩個(gè)端點(diǎn)之間的端到端信道。也就是說，TCP / IP 體系結(jié)構(gòu)的窄腰正是IP 地址，而且這樣的窄腰仍會限制住解決當(dāng)前網(wǎng)絡(luò)問題的能力[3]。

（2）HTTP 是應(yīng)用層協(xié)議，傳輸層需要由TCP協(xié)議來完成，這就需要端到端的網(wǎng)頁數(shù)據(jù)傳輸。但是，對于靜態(tài)數(shù)據(jù)例如網(wǎng)頁，更改頻率并不是特別快，因此這種端到端傳輸在內(nèi)容分發(fā)網(wǎng)絡(luò)的概念被提出之后，在該類型情景下的適用性不強(qiáng)。因?yàn)檫@勢必導(dǎo)致相同的內(nèi)容在網(wǎng)絡(luò)中被反復(fù)傳輸。

（3）盡管HTTP 傳輸模式與ICN 傳輸類似，用興趣包來檢索數(shù)據(jù)，但是在傳輸?shù)膶?shí)現(xiàn)細(xì)節(jié)上，仍存在很多差異。例如，HTTP 的下層傳輸協(xié)議是TCP，而TCP 協(xié)議使用PUSH 模式來傳輸數(shù)據(jù)。相反，在ICN 網(wǎng)絡(luò)中，興趣包被用于發(fā)送以檢索相應(yīng)的數(shù)據(jù)，這稱為GET 模式。理所當(dāng)然地，HTTP 的請求和響應(yīng)方法很容易地為我們帶來一個(gè)優(yōu)化想法：移植ICN 傳輸模式到HTTP，允許網(wǎng)絡(luò)中的轉(zhuǎn)發(fā)路由器緩存數(shù)據(jù)并匯總請求[4]。然而TCP 的PUSH 模式給這個(gè)想法增添了不少麻煩。

用戶對他們訪問網(wǎng)頁時(shí)的體驗(yàn)的需求，驅(qū)使我們利用ICN 網(wǎng)絡(luò)傳輸?shù)乃枷雭砀纳艸TTP 請求過程。由于網(wǎng)內(nèi)緩存和請求聚合通信特性的存在，ICN 傳輸特別適合部署在HTTP 請求過程中用于提升網(wǎng)絡(luò)性能。同時(shí)，根據(jù)P4 語言[5]的能力，用戶可以在可編程交換機(jī)設(shè)備上自定義轉(zhuǎn)發(fā)操作；根據(jù)P4 語言的特性，用戶可以產(chǎn)生具有ICN 和IP 包特征的數(shù)據(jù)包，并且可在同一交換設(shè)備上兼容地工作[6]。另外，交換設(shè)備可以根據(jù)不同的傳入數(shù)據(jù)包類型采用不同的轉(zhuǎn)發(fā)操作。

盡管上面提到了很多優(yōu)勢，但是想要在HTTP 請求方案中使用P4 語言實(shí)現(xiàn)ICN 傳輸，由于TCP / IP體系結(jié)構(gòu)和ICN 之間的差距，仍具有挑戰(zhàn)性。首先，由于協(xié)議的不同，兩者所使用的數(shù)據(jù)包是不兼容的，需要尋求數(shù)據(jù)包的轉(zhuǎn)換方法。其次，如何利用P4 語言編寫簡單快捷的轉(zhuǎn)發(fā)過程算法也是一個(gè)需要思考的問題。

在文獻(xiàn)[19]和[20]中，是用OpenFlow 嘗試在TCP/IP 上實(shí)現(xiàn)了ICN 思路的緩存與負(fù)載均衡操作，但方案與操作細(xì)節(jié)較為復(fù)雜，所用到的幾個(gè)流表參數(shù)很多。而P4 作為正在發(fā)展中的一種優(yōu)秀的語言，相比OpenFlow 的協(xié)議對數(shù)據(jù)面的控制與操作更為便捷，尤其是在數(shù)據(jù)包的轉(zhuǎn)發(fā)方面。這正是本文選用P4 作為實(shí)現(xiàn)工具的原因。

數(shù)據(jù)傳輸過程，網(wǎng)絡(luò)中的數(shù)據(jù)包的處理和轉(zhuǎn)發(fā)設(shè)備的操作是三個(gè)主要的研究方向。在本文中，我們采用P4 語言在轉(zhuǎn)發(fā)交換機(jī)上實(shí)現(xiàn)ICN 轉(zhuǎn)發(fā)操作，并提出一種用于將HTTP 數(shù)據(jù)包和ICN.p4 數(shù)據(jù)包相互轉(zhuǎn)換的數(shù)據(jù)包轉(zhuǎn)換規(guī)則。本文的主要貢獻(xiàn)如下：

（1）提出了一個(gè)數(shù)據(jù)包轉(zhuǎn)換規(guī)則，該規(guī)則可以部署在HTTP 客戶端和HTTP 服務(wù)器上，并通過代理應(yīng)用程序來保障該規(guī)則順利工作。代理應(yīng)用程序添加ICN 特征的字段到要發(fā)送的數(shù)據(jù)包包頭，將其轉(zhuǎn)換為ICN.p4 數(shù)據(jù)包；相反地，它也會刪除其中ICN 特性的字段（如有必要），使數(shù)據(jù)包轉(zhuǎn)換回到TCP / IP 數(shù)據(jù)包。

（2）在本文的方案中，通過使用P4 語言，在可編程的轉(zhuǎn)發(fā)交換機(jī)上實(shí)現(xiàn)了ICN 轉(zhuǎn)發(fā)操作。該可編程交換機(jī)可以實(shí)現(xiàn)PIT，CS 和其他僅存在于ICN 網(wǎng)絡(luò)轉(zhuǎn)發(fā)設(shè)備中的模塊。在P4 交換機(jī)加載P4 程序之后，就可以完成PIT 檢查，數(shù)據(jù)包緩存等過程，然后將數(shù)據(jù)包轉(zhuǎn)發(fā)到下一跳。以上所描述的整個(gè)處理流程就是ICN 網(wǎng)絡(luò)轉(zhuǎn)發(fā)設(shè)備的轉(zhuǎn)發(fā)過程。

（3）為驗(yàn)證提出的方案，我們在虛擬機(jī)上搭建了一個(gè)簡單的網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)。在測試中使用HTTP協(xié)議瀏覽網(wǎng)頁，同時(shí)收集流量信息以及網(wǎng)絡(luò)中的其他實(shí)驗(yàn)數(shù)據(jù)，以量化展示網(wǎng)絡(luò)性能的提高。

1 相關(guān)工作

在本節(jié)中，我們簡要介紹ICN 和P4 語言和HTTP協(xié)議的現(xiàn)狀。

1.1 ICN 和HTTP 概述

ICN（Information Centric Network，信息中心網(wǎng)絡(luò)）被認(rèn)為是可以取代IP 架構(gòu)的下一代網(wǎng)絡(luò)架構(gòu)，對于信息中心網(wǎng)絡(luò)的實(shí)例，已有的例如NDN （Named Data Network，命名數(shù)據(jù)網(wǎng)絡(luò)）/ CCN (Content Centric Network，內(nèi)容中心網(wǎng)絡(luò))/ PURSUIT(Publish-Subscribe Internet Technologies)等。雖然他們實(shí)施細(xì)節(jié)不同，但設(shè)計(jì)概念是類似的，NDN 就是其中一個(gè)典型的案例。在NDN 中，數(shù)據(jù)傳輸是通過兩種數(shù)據(jù)包來完成的：興趣包和數(shù)據(jù)包[7]。興趣包攜帶著請求內(nèi)容的名稱，同時(shí)數(shù)據(jù)包攜帶的是與興趣請求相對應(yīng)的內(nèi)容。在這個(gè)過程中有三個(gè)主要的狀態(tài)表：CS (Content Store，數(shù)據(jù)緩存)，PIT (Pending Interest Table，待處理表)，F(xiàn)IB（Forwarding Information Base，轉(zhuǎn)發(fā)路由表）。CS 可以緩存經(jīng)過的數(shù)據(jù)包[8]；PIT 的作用是留下標(biāo)記來幫助數(shù)據(jù)包返回到消費(fèi)者方；FIB用于路由興趣包，同時(shí)FIB 條目是由路由協(xié)議所生成的。要注意的是上面三個(gè)狀態(tài)表的表項(xiàng)都是名稱。

HTTP 是一個(gè)簡單的請求-響應(yīng)協(xié)議，通常在TCP（一種應(yīng)用程序?qū)訁f(xié)議）上運(yùn)行。當(dāng)一位Web用戶打開其Web 瀏覽器時(shí)，該用戶將間接地使用到HTTP。到目前為止，最新版本的HTTP 是HTTP / 2，是于2015年5月發(fā)布的。HTTP 指定了消息的格式，它們都在TCP 協(xié)議的有效載荷之內(nèi)。在圖1中，展示了HTTP 的請求和響應(yīng)格式。

1.2 P4 語言現(xiàn)狀

圖1 HTTP 請求格式和響應(yīng)格式Fig.1 HTTP request and response packet format

斯坦福大學(xué)的Nick McKeown 教授首先在2014年設(shè)計(jì)并提出了數(shù)據(jù)平面特定領(lǐng)域編程語言——P4[5]，以充分解放數(shù)據(jù)平面的編程能力，現(xiàn)在已經(jīng)在學(xué)術(shù)界和工業(yè)界被廣泛認(rèn)知。一方面，基于可編程設(shè)備的可定制功能，它可以快速實(shí)施和驗(yàn)證一些新的網(wǎng)絡(luò)架構(gòu)，功能和協(xié)議，極大地加速了網(wǎng)絡(luò)的進(jìn)化與創(chuàng)新；另一方面，基于可編程設(shè)備的高性能特征，傳統(tǒng)上靈活但性能低下的中間件工具，例如防火墻，負(fù)載平衡以及其它一些更簡單的網(wǎng)絡(luò)功能，就可以被轉(zhuǎn)移到到可編程數(shù)據(jù)面上，從而實(shí)現(xiàn)顯著的性能提升。

自2014年提出P4 的概念以來，P4 語言一直在蓬勃發(fā)展。同年，就提出了P4_14，隨后P4_16 版本在2016年被發(fā)布。根據(jù)P4 官方網(wǎng)站，大多數(shù)開發(fā)中的新協(xié)議的小演示，現(xiàn)在都在軟件交換機(jī)上完成。只要軟件交換機(jī)bmv2 被安裝在所有Linux 接口的機(jī)器上，這臺計(jì)算機(jī)就可以用作可編程交換機(jī)。盡管有許多公司已經(jīng)開發(fā)了支持P4 語言的可編程硬件交換機(jī)[9]，但本文中之后提到的所有環(huán)境，都是搭建在Linux 之上的軟件交換機(jī)。

在P4 語言的提出之后，相關(guān)研究非常活躍，許多小型演示的嘗試旨在快速實(shí)現(xiàn)一些非常創(chuàng)新的協(xié)議和轉(zhuǎn)發(fā)策略。在文獻(xiàn)[10]中，實(shí)現(xiàn)了網(wǎng)絡(luò)內(nèi)緩存的想法，這使得轉(zhuǎn)發(fā)交換機(jī)可以緩存數(shù)據(jù)包內(nèi)容。只要重新設(shè)計(jì)數(shù)據(jù)包的格式，在P4 交換機(jī)上設(shè)計(jì)轉(zhuǎn)發(fā)過程，緩存，獲取，更新數(shù)據(jù)內(nèi)容或其他一些操作，都可以根據(jù)數(shù)據(jù)包中的某些特定字段來實(shí)現(xiàn)。另外，根據(jù)交換機(jī)上數(shù)據(jù)包的統(tǒng)計(jì)信息，還可以提出一種新的緩存策略。

使用P4 語言，許多復(fù)雜的轉(zhuǎn)發(fā)協(xié)議可以在數(shù)據(jù)平面上輕松實(shí)現(xiàn)。在文獻(xiàn)[11]和[12]中，ICN 在轉(zhuǎn)發(fā)方面的一些優(yōu)勢正在逐漸由P4 語言實(shí)現(xiàn)，但由于要求所有轉(zhuǎn)發(fā)節(jié)點(diǎn)都是P4 交換機(jī)，所以大多數(shù)還無法與當(dāng)前的網(wǎng)絡(luò)協(xié)議或應(yīng)用相結(jié)合。在分階段部署轉(zhuǎn)發(fā)設(shè)備的前提下，是無法保證所有設(shè)備都是P4 交換機(jī)的，因此仍然需要改進(jìn)。盡管ICN 傳輸?shù)乃枷朐谖墨I(xiàn)[11]中已經(jīng)基本實(shí)現(xiàn)了，但該文章仍明確指出：緩存模塊功能尚未完成，并且文中的實(shí)現(xiàn)僅適用于完全配置了P4 路由器的鏈路。

1.3 HTTP 的網(wǎng)內(nèi)緩存

如果能在HTTP 傳輸過程中，存在中間節(jié)點(diǎn)的數(shù)據(jù)緩存，就能夠大大減少傳輸?shù)牧髁?，提高訪問效率。這就是HTTP 的網(wǎng)內(nèi)緩存。

現(xiàn)有的緩存方案主要分為緩存整個(gè)文件與記錄文件放置位置兩種。直接緩存整個(gè)文件開銷太大，又需要占用大量存儲資源，并非合適的選擇。記錄文件位置可以方便內(nèi)容的集中管理，提供控制和管理網(wǎng)絡(luò)資源的機(jī)會。更新內(nèi)容位置數(shù)據(jù)庫的開銷相對于存儲文件低了很多，但就存儲位置來說靈活性不如就地緩存高。

2 架構(gòu)描述

本節(jié)描述了我們提出的解決方案：受ICN 的思想啟發(fā)，通過P4 在路由器轉(zhuǎn)發(fā)過程中實(shí)現(xiàn)網(wǎng)絡(luò)內(nèi)緩存，實(shí)現(xiàn)對HTTP 的訪問效果提升，減少網(wǎng)絡(luò)冗余流量。

2.1 動機(jī)和概述

如上一節(jié)所述，研究HTTP 協(xié)議的優(yōu)化是很有意義的，但是解決方案的方向受到了端到端通信這一基礎(chǔ)機(jī)制的限制。端到端的通信會導(dǎo)致許多相似的內(nèi)容在復(fù)數(shù)鏈接中被反復(fù)傳輸，這產(chǎn)生了很多冗余的網(wǎng)絡(luò)流量，提高了網(wǎng)絡(luò)的負(fù)擔(dān)，而為優(yōu)化網(wǎng)站的瀏覽而設(shè)置的代理服務(wù)器相對來說可是很昂貴的。盡管ICN 網(wǎng)絡(luò)架構(gòu)中“網(wǎng)內(nèi)緩存”的提出為優(yōu)化的研究思路帶來了一些好的想法，但由于ICN 和TCP/ IP 之間的差異，仍然很難在實(shí)際部署中與以前網(wǎng)絡(luò)的體系結(jié)構(gòu)相兼容。但是，P4 語言的發(fā)展應(yīng)用拓寬了解決問題的思路視野，使ICN 的特性在HTTP 協(xié)議中運(yùn)轉(zhuǎn)不再那么困難。所以，依然借助ICN，我們提出了一個(gè)使用P4 語言來幫助實(shí)現(xiàn)ICN 的網(wǎng)內(nèi)緩存以優(yōu)化HTTP 請求過程的想法。有了網(wǎng)內(nèi)緩存的存在，就能夠大大降低網(wǎng)絡(luò)中的冗余流量。

我們的基本思路是，通過部署一些可編程的路由設(shè)備，實(shí)現(xiàn)ICN 網(wǎng)絡(luò)內(nèi)緩存[13]與請求聚合等等功能，更進(jìn)一步，實(shí)現(xiàn)ICN 傳輸?shù)哪Ｊ?，而其中最關(guān)鍵的部分正是網(wǎng)內(nèi)緩存。并且，希望可以與現(xiàn)有的路由設(shè)備和網(wǎng)絡(luò)協(xié)議相兼容。為了實(shí)現(xiàn)這個(gè)想法，在這里首先要提出一個(gè)數(shù)據(jù)包轉(zhuǎn)換代理的模塊，它一方面具有代理服務(wù)器的功能，另一方面實(shí)現(xiàn)數(shù)據(jù)包的轉(zhuǎn)換。

這樣的數(shù)據(jù)包轉(zhuǎn)換代理分別部署在HTTP 客戶端與服務(wù)器端的接口處，使每個(gè)進(jìn)入網(wǎng)絡(luò)傳輸?shù)臄?shù)據(jù)包接受轉(zhuǎn)換，每個(gè)離開網(wǎng)絡(luò)到達(dá)客戶端或服務(wù)端的數(shù)據(jù)包也會接受轉(zhuǎn)換。

具體來說，HTTP 客戶端發(fā)送的每個(gè)請求均由代理轉(zhuǎn)換，代理將轉(zhuǎn)換后的數(shù)據(jù)包轉(zhuǎn)發(fā)給路由尋找答復(fù)；反之，響應(yīng)也通過這樣的代理應(yīng)用程序進(jìn)行傳遞。服務(wù)器上的代理應(yīng)用程序會轉(zhuǎn)換整個(gè)HTTP響應(yīng)。由于轉(zhuǎn)換前后的數(shù)據(jù)包結(jié)構(gòu)不同，在傳輸時(shí)需要重新切片。

路徑上在代理應(yīng)用程序之后的每個(gè)響應(yīng)數(shù)據(jù)包都包含名稱，即HTTP 響應(yīng)的URL 和相應(yīng)的段號。因?yàn)檗D(zhuǎn)換后的數(shù)據(jù)包包含附加字段，可以輕松地利用可編程轉(zhuǎn)發(fā)設(shè)備上的P4 語言程序，設(shè)計(jì)ICN 傳輸中的轉(zhuǎn)發(fā)操作，包括但不限于緩存與聚合。每當(dāng)一個(gè)數(shù)據(jù)包到達(dá)時(shí)，可編程轉(zhuǎn)發(fā)設(shè)備需要將其與PIT，CS，F(xiàn)IB 等匹配比對，這些表需要執(zhí)行的常規(guī)操作是與ICN 類似的。存在不同的操作例如有在PIT 中存在聚合時(shí)的多播分發(fā)，由于某些中間轉(zhuǎn)發(fā)節(jié)點(diǎn)可能不是經(jīng)P4 編程的轉(zhuǎn)發(fā)設(shè)備，此處需要添加目標(biāo)IP地址的信息。另一個(gè)是我們使用IP 表而不是FIB，并且表項(xiàng)由控制面來發(fā)送。

根據(jù)以上描述，代理應(yīng)用程序?qū)⑥D(zhuǎn)換后的數(shù)據(jù)包發(fā)送到網(wǎng)絡(luò)進(jìn)行路由，這些數(shù)據(jù)包可以根據(jù)名稱在可編程交換機(jī)上進(jìn)行緩存和聚合。該設(shè)計(jì)中的代理應(yīng)用程序和數(shù)據(jù)包傳輸過程如圖2所示。

另一方面，在圖2中可以看到，網(wǎng)絡(luò)中存在著一部分P4 路由器，正是在網(wǎng)絡(luò)中部署好的可編程路由器。相對于原來的網(wǎng)絡(luò)，也就是將普通路由器進(jìn)行了替換，使之可以執(zhí)行更多的功能。要部署在實(shí)際的網(wǎng)絡(luò)中的話，可以采用安裝了P4 環(huán)境的樹莓派或其他可配置環(huán)境的智能路由器來擔(dān)當(dāng)可編程路由器的角色。

2.2 包轉(zhuǎn)換

圖2 結(jié)合代理應(yīng)用程序的HTTP 請求體系結(jié)構(gòu)Fig.2 HTTP request architecture with Proxy Application

圖3 HTTP 和ICN.p4 數(shù)據(jù)包格式Fig.3 HTTP and ICN.p4 Packet Format

圖4 代理應(yīng)用程序轉(zhuǎn)換數(shù)據(jù)包Fig.4 Proxy Application converts packets

為了使轉(zhuǎn)發(fā)設(shè)備能夠依照ICN 轉(zhuǎn)發(fā)過程和諧地工作，將數(shù)據(jù)包中的相關(guān)操作歸檔是很有必要的，例如名稱、序列號、操作等。圖3顯示，ICN-TCP /IP 協(xié)議的數(shù)據(jù)包格式，同時(shí)包含著TCP / IP 和ICN的特性，也就是說，數(shù)據(jù)包格式為TCP / IP 和ICN的集成。雖然本質(zhì)上是IP 數(shù)據(jù)包，但是它也擁有一些ICN 字段，并且是通過使用P4 語言來實(shí)現(xiàn)ICN協(xié)議的，因此我們將其稱為ICN.p4 數(shù)據(jù)包。由于此數(shù)據(jù)包的獨(dú)特結(jié)構(gòu)，在可編程交換機(jī)上，可以輕松地使用P4 語言實(shí)現(xiàn)ICN 轉(zhuǎn)發(fā)過程和TCP / IP 轉(zhuǎn)發(fā)過程。ICN.p4 數(shù)據(jù)包中的主要標(biāo)頭字段是OP，URL，Segment，Seq 和isCache。OP 代表操作，表示它是一個(gè)Get 包還是Push 包，它等同于ICN 中的數(shù)據(jù)包類型，例如興趣包和數(shù)據(jù)包。所以我們稱OP 字段為Push 的是ICN.p4 內(nèi)容數(shù)據(jù)包，OP 字段為Get 的是ICN.p4 興趣包。由URL 和Segment 字段組成的名稱部分類似于ICN.p4 名稱，但是區(qū)別是，在此方案中并不使用名稱進(jìn)行路由，而是用于匹配判斷。isCache 字段用于決定是否要緩存數(shù)據(jù)包數(shù)據(jù)。

ICN 協(xié)議字段位于TCP 有效負(fù)載之內(nèi)，并且有一個(gè)為此數(shù)據(jù)包保留的專用的TCP 端口。P4 交換機(jī)使用該特殊端口來調(diào)用ICN 數(shù)據(jù)包處理邏輯，其他端口的數(shù)據(jù)包則由 P4 交換機(jī)視為普通 IP 數(shù)據(jù)包進(jìn)行轉(zhuǎn)發(fā)，這樣其他的交換機(jī)就不需要理解ICN.P4 數(shù)據(jù)包的格式，P4 交換機(jī)也不需要將所有進(jìn)入的數(shù)據(jù)包視為普通 IP 數(shù)據(jù)包。這樣一個(gè)保留的TCP 端口正是被用于確定數(shù)據(jù)包是TCP / IP 包還是ICN.p4 數(shù)據(jù)包，這同樣會應(yīng)用在代理應(yīng)用程序當(dāng)中。在客戶端和服務(wù)器端均設(shè)置了應(yīng)用程序代理[14]，使用此代理，可以將HTTP 數(shù)據(jù)包轉(zhuǎn)換為ICN 數(shù)據(jù)包，也可以將其轉(zhuǎn)換回去。一旦 HTTP 客戶端和服務(wù)器都使用代理應(yīng)用程序，對于客戶端，代理應(yīng)用程序?qū)⒈灰暈镠TTP 服務(wù)器，反之，對于服務(wù)器端，代理應(yīng)用程序被認(rèn)為是 HTTP 客戶端。對于代理應(yīng)用程序，它扮演的角色以及它在通信過程中所達(dá)成的功能如圖4所示。因此，當(dāng)ICN 數(shù)據(jù)包在網(wǎng)絡(luò)中流動時(shí)，只要使用了代理應(yīng)用程序，就會由代理應(yīng)用程序完成TCP和ICN 數(shù)據(jù)包的轉(zhuǎn)換。這奠定了實(shí)現(xiàn)網(wǎng)內(nèi)緩存，請求聚合以及ICN 的其他特性的基礎(chǔ)。

2.3 轉(zhuǎn)發(fā)過程

從代理應(yīng)用程序發(fā)出的數(shù)據(jù)包會進(jìn)入網(wǎng)絡(luò)，并且開始傳輸，剩下的工作就是逐跳進(jìn)行數(shù)據(jù)包轉(zhuǎn)發(fā)。而順利進(jìn)入網(wǎng)絡(luò)的數(shù)據(jù)包均是轉(zhuǎn)換后的數(shù)據(jù)包，即ICN.p4 數(shù)據(jù)包。P4 交換機(jī)上的轉(zhuǎn)發(fā)操作與數(shù)據(jù)包的處理流程都與ICN 是類似的，完整的HTTP 請求流程如圖5所示。

當(dāng)數(shù)據(jù)包傳輸?shù)穆窂缴洗嬖谝粋€(gè)P4 交換機(jī)時(shí)，就有必要檢查P4 交換機(jī)中的狀態(tài)表，例如CS 和PIT。如果CS 表命中了（根據(jù)數(shù)據(jù)包的名稱進(jìn)行匹配），則P4 交換機(jī)會直接使用網(wǎng)絡(luò)內(nèi)緩存進(jìn)行響應(yīng)。另一方面，P4 交換機(jī)檢查PIT，來判斷是否要匯總請求。如果名稱已經(jīng)存在于PIT 中，P4 交換機(jī)就更新PIT，然后丟棄數(shù)據(jù)包；如果沒有，那么就比對IP 表并轉(zhuǎn)發(fā)數(shù)據(jù)包。因?yàn)镻4 交換機(jī)是分階段部署的，所以并不能保證所有鏈路上都是P4 交換機(jī)。也就是說，并非所有中間轉(zhuǎn)發(fā)節(jié)點(diǎn)都是有狀態(tài)的，是記錄了狀態(tài)表的。因此，根據(jù)IP 地址來進(jìn)行路由才是可靠的。

于是，當(dāng)ICN.p4 數(shù)據(jù)包在網(wǎng)絡(luò)上轉(zhuǎn)發(fā)時(shí)，存在有兩種可能性。第一種情況，數(shù)據(jù)包由P4 交換機(jī)來執(zhí)行轉(zhuǎn)發(fā)，P4 交換機(jī)會基于預(yù)留的TCP 接口來判斷傳入數(shù)據(jù)包是否是一個(gè)ICN.p4 數(shù)據(jù)包。接下來，如果它是一個(gè)ICN.p4 數(shù)據(jù)包，則該交換機(jī)將調(diào)用由P4語言書寫的ICN 數(shù)據(jù)包處理程序。如果不是，則交換機(jī)就將傳入數(shù)據(jù)包視為普通的IP 數(shù)據(jù)包，并將其轉(zhuǎn)發(fā)出去。而在另一種情況中，是由普通交換機(jī)來執(zhí)行ICN.p4 數(shù)據(jù)包的轉(zhuǎn)發(fā)。由于ICN.p4 協(xié)議字段位于TCP 有效負(fù)載內(nèi)，因此對于僅執(zhí)行L2 / L3 層轉(zhuǎn)發(fā)的的普通路由器來說，是不可見的。

2.4 P4 交換機(jī)的細(xì)節(jié)

經(jīng)過設(shè)計(jì)的整個(gè)HTTP 請求過程已經(jīng)在上面完成了討論，本節(jié)將介紹具體的操作以及每個(gè)P4 交換機(jī)的實(shí)現(xiàn)細(xì)節(jié)。對于一臺轉(zhuǎn)發(fā)設(shè)備，其轉(zhuǎn)發(fā)過程如算法1 所示。

算法1 中所使用到的參數(shù)，如2.2 節(jié)與圖3中所說的，是ICN.p4 數(shù)據(jù)包的特有字段，用于輔助ICN 轉(zhuǎn)發(fā)過程的執(zhí)行。而groupcast 操作代表了一種廣播分發(fā)操作，將數(shù)據(jù)包分發(fā)到可能存在的多個(gè)對其發(fā)出了請求的地方去。

圖5 數(shù)據(jù)包轉(zhuǎn)發(fā)過程Fig.5 Packet forwarding process

Algorithm 1: Packet forwarding process Input: pkt Output: Forwarding action Parse pkt header if pkt. TCP.dport != reserved port then 123456789 IPV forwarding else Hash(pkt.name)if pkt.op == Get then if CS_Register[Hash(pkt.name)] == 1 then Send back cached data Break 10 11 12 13 14 15 16 17 18 19 20 21 22 end if PIT_Register[Hash(pkt.name)]! == 0 then Update PIT_Register and drop pkt else IPV4 forwarding end end if pkt.op == Push then if pkt.isCache == 1 then Cache packet end if PIT_Register[Hash(pkt.name)]! == 0 then Update packet header, delete PIT entry and groupcast packet 23 24 25 26 27 else IPV4 forwarding end end end

就像ICN 網(wǎng)絡(luò)一樣，在交換機(jī)上需要構(gòu)建幾個(gè)有狀態(tài)表，例如用于包數(shù)據(jù)緩存的CS 和用于記錄請求的PIT，這些操作都需要上面提到的算法。有狀態(tài)表在算法中被抽象為每個(gè)交換機(jī)上的寄存器數(shù)組，例如PIT 表，就使用寄存器數(shù)組來記錄傳入的請求。由于同時(shí)可能會有復(fù)數(shù)待回復(fù)的請求被記錄在PIT中，這沒有辦法直接以P4 語言實(shí)現(xiàn)，因此我們使用多個(gè)一維數(shù)組來實(shí)現(xiàn)多維數(shù)組記錄。如圖6所示，首先使用一個(gè)數(shù)組記錄所有傳入的請求。索引是每個(gè)請求名稱的哈希值[15]，該值是記錄的請求信息的表項(xiàng)索引。如圖6的簡單示例上所說，索引為13 425 的請求，其值101 表示有兩個(gè)請求被記錄，并且兩個(gè)請求的信息均記錄在輔助陣列中。很容易知道，請求是來自IP 地址為10.0.0.1 和10.0.0.2 的計(jì)算機(jī)。如上所述，由于并不能保證整個(gè)路徑上的所有交換機(jī)設(shè)備都是P4交換機(jī)，所以需要在記錄請求的同時(shí)緩存請求的發(fā)送者，以便我們可以直接使用多播進(jìn)行回復(fù)。將目的IP地址放在數(shù)據(jù)包的IP 標(biāo)頭位置，以確保通過多播分發(fā)的數(shù)據(jù)包可以到達(dá)預(yù)期的目的地。

圖6 用寄存器數(shù)組實(shí)現(xiàn)的PITFig.6 PIT implemented with register array

除了PIT，還需要另一個(gè)有狀態(tài)表CS。為了重現(xiàn)ICN 中CS 表的緩存功能，這里選擇了一些小技巧來實(shí)現(xiàn)該模塊的功能。由于P4 語言只是一種數(shù)據(jù)平面上的網(wǎng)絡(luò)編程語言，許多繁瑣的文件存儲操作并沒有辦法直接完成。我們使用P4 語言在數(shù)據(jù)面上申請一個(gè)寄存器數(shù)組空間，來記錄本地緩存的狀態(tài)，而實(shí)際的緩存功能是由特定的應(yīng)用程序提供的。因此，從數(shù)據(jù)面的角度來看，交換機(jī)只記錄狀態(tài)，并沒有實(shí)際數(shù)據(jù)存儲，存儲的數(shù)據(jù)被轉(zhuǎn)發(fā)到提供緩存服務(wù)的應(yīng)用程序。當(dāng)接收到OP 字段為Get 的ICN.p4 數(shù)據(jù)包，如算法1 中所描述的，去查詢與數(shù)組索引相對應(yīng)的值，檢查該值是否等于 ICN.p4 數(shù)據(jù)包名稱的哈希散列值，以確定是否存在本地緩存。如果該值表示，存在一個(gè)本地?cái)?shù)據(jù)緩存，那么就將ICN.p4 數(shù)據(jù)包轉(zhuǎn)發(fā)到應(yīng)用層，同時(shí)交由提供緩存數(shù)據(jù)功能的應(yīng)用程序去檢索對應(yīng)的數(shù)據(jù)并構(gòu)造一個(gè)數(shù)據(jù)包發(fā)送回去。否則，就將直接轉(zhuǎn)發(fā)數(shù)據(jù)包到下一跳。另一方面，如果到達(dá)的數(shù)據(jù)包的OP 字段是Push，那么只需要解析isCache 字段值，來決定是否緩存數(shù)據(jù)包。圖7展示了P4 交換機(jī)的體系結(jié)構(gòu)，包括交換機(jī)內(nèi)各個(gè)模塊實(shí)現(xiàn)的角色和功能的細(xì)節(jié)。

圖7 交換機(jī)架構(gòu)Fig.7 Switch architecture

如圖7所示，寄存器與轉(zhuǎn)發(fā)層都在交換機(jī)的數(shù)據(jù)面上，扮演著轉(zhuǎn)發(fā)算法的核心——控制器角色。另外交換機(jī)內(nèi)還有存儲模塊，用于交換機(jī)的本地存儲功能，可以直接在需要時(shí)與用戶進(jìn)行交互。

3 評估

為了演示我們?yōu)橥暾恼狭薎CN 傳輸?shù)膬?yōu)勢的HTTP 請求過程設(shè)計(jì)的場景，以多臺虛擬機(jī)，構(gòu)建了一個(gè)網(wǎng)絡(luò)拓?fù)?。每臺虛擬機(jī)上都安裝了Ubuntu16.04 操作系統(tǒng)，也預(yù)裝了P4 軟件交換機(jī)BMV2。這樣，每個(gè)虛擬機(jī)都可以看作一個(gè) P4交換機(jī)，交換機(jī)上的操作可以通過 P4 語言程序進(jìn)行配置，流表項(xiàng)可以通過控制面來發(fā)送。

據(jù)了解，在類似領(lǐng)域中，有一些大多采用Mininet 模擬器進(jìn)行實(shí)驗(yàn)的研究。而在這里使用虛擬機(jī)來完成實(shí)驗(yàn)，就相當(dāng)于使用每個(gè)交換設(shè)備作為一臺計(jì)算機(jī)或作為一個(gè) P4 交換機(jī)。因此，本文提出的網(wǎng)內(nèi)緩存可以使用虛擬機(jī)的本地內(nèi)存來實(shí)現(xiàn)。在實(shí)驗(yàn)中，可以使用每個(gè)虛擬機(jī)的Ubuntu16.04 終端作為控制平面來配置流表，發(fā)送表項(xiàng)。類似地，代理應(yīng)用程序的部署也是通過在 Ubuntu 上配置虛擬網(wǎng)絡(luò)適配器來完成的[17]，添加一個(gè)虛擬隧道，于是HTTP 請求由已部署的代理申請人完全代表，這等效于將請求轉(zhuǎn)發(fā)到應(yīng)用程序?qū)?。此功能也可以由單?dú)的代理網(wǎng)關(guān)來實(shí)現(xiàn)。

為了驗(yàn)證這一想法，我們構(gòu)建了如圖8中所示的拓?fù)鋪磉M(jìn)行實(shí)驗(yàn)。在測試過程中，主要關(guān)注對象是服務(wù)器的響應(yīng)負(fù)載。

如圖8所示，PC_1 和PC_2 是由SERVER 提供的有意愿去瀏覽網(wǎng)頁的消費(fèi)者，并且在鏈路中間有兩個(gè)轉(zhuǎn)發(fā)設(shè)備，S_1 和S_2。但是區(qū)別在于，S_2 是P4 交換機(jī)，而S_1 不是。因此，在S_2 上存在請求聚合和網(wǎng)絡(luò)內(nèi)緩存發(fā)生的可能性。在這里，將 CS 寄存記錄設(shè)置為10 秒內(nèi)有效，也就是說，只要同名的請求數(shù)據(jù)包在交換節(jié)點(diǎn)刷新緩存后10 秒內(nèi)到達(dá) P4交換機(jī)，交換機(jī)就可以將其直接轉(zhuǎn)發(fā)到應(yīng)用層，應(yīng)用程序使用本地緩存來響應(yīng)請求。同時(shí)，我們將PIT可以聚合兩個(gè)請求的時(shí)間間隔設(shè)定為10ms。那么，只有當(dāng)兩個(gè)同名的請求在10ms 內(nèi)到達(dá)同一交換機(jī)時(shí)，它們才會被聚合。

圖8 用于評估的拓?fù)渚W(wǎng)絡(luò)Fig.8 Topology for evaluation

我們讓PC_1 和PC_2 每5 秒發(fā)送一次請求，重復(fù)這個(gè)操作30 次。通過觀察的數(shù)據(jù)，可以知道兩個(gè)PC 請求的數(shù)量之和與圖9中的SERVER 的響應(yīng)之間的關(guān)系。從圖中清晰地發(fā)現(xiàn)，當(dāng)請求數(shù)相同時(shí)，對應(yīng)的ICN-HTTP 數(shù)方法比HTTP 小得多，可以看出，ICN-HTTP 的響應(yīng)負(fù)載僅為HTTP 的一半，這主要?dú)w功于S_2 節(jié)點(diǎn)的緩存和聚合。不過，由于聚合發(fā)生的條件十分嚴(yán)格，所以聚合的可能性很低，主要對網(wǎng)絡(luò)優(yōu)化起效的是網(wǎng)絡(luò)內(nèi)緩存功能。

圖9 服務(wù)器負(fù)載的小提琴圖Fig.9 Violin plot of server load

4 改進(jìn)方案

在上面介紹了的方案的基礎(chǔ)上，針對其兼容性，我們還可以進(jìn)行一些改進(jìn)。由于數(shù)據(jù)包的轉(zhuǎn)換由代理應(yīng)用程序執(zhí)行，所以在調(diào)整鏈路環(huán)境時(shí)，除了需要將普通路由器替換為P4 路由器，還需要在鏈路的起點(diǎn)與終點(diǎn)處配置代理應(yīng)用程序。這樣的情況，對現(xiàn)存網(wǎng)絡(luò)的兼容性來說是不方便的。于是在新方案中，假如讓數(shù)據(jù)包轉(zhuǎn)換的過程也集成到P4 交換機(jī)中，就能使得全部操作都由P4 交換機(jī)完成。在對鏈路進(jìn)行升級時(shí)，就只需要替換路由器，即可實(shí)現(xiàn)這一新方案的應(yīng)用。

在文獻(xiàn)[18]中提出了一種操作，它使用P4 修改了TCP/IP 包頭，隨后由Linux 內(nèi)核重新計(jì)算校驗(yàn)和進(jìn)行封包。這給了我們啟發(fā)，在P4 交換機(jī)中，是可以實(shí)現(xiàn)前面提出的數(shù)據(jù)包轉(zhuǎn)換操作的。根據(jù)這一思路，提出的改進(jìn)方案具體如下。

當(dāng)P4 交換機(jī)收到傳入數(shù)據(jù)包時(shí)，首先對數(shù)據(jù)包的TCP 頭進(jìn)行檢查，根據(jù)內(nèi)容獲取并計(jì)算ICN 轉(zhuǎn)發(fā)過程判斷所需要的字段，并放入TCP 負(fù)載當(dāng)中，將普通數(shù)據(jù)包在P4 路由器內(nèi)部轉(zhuǎn)換為ICN.p4 數(shù)據(jù)包。接下來，ICN.p4 數(shù)據(jù)包經(jīng)由P4 程序設(shè)計(jì)的轉(zhuǎn)發(fā)操作過程，判斷之后的去向與內(nèi)容操作，這與原方案中的P4 路由器的任務(wù)是相同的。假如該數(shù)據(jù)包需要被傳出P4 交換機(jī)，那么在傳出之前要將ICN.p4 數(shù)據(jù)包轉(zhuǎn)換回普通的數(shù)據(jù)包，使得進(jìn)入網(wǎng)絡(luò)傳輸?shù)臄?shù)據(jù)包都是一般格式的數(shù)據(jù)包，保證傳輸?shù)募嫒菪?。在去除ICN.p4特有的字段之后，交由內(nèi)核重新計(jì)算校驗(yàn)和，執(zhí)行重新封包，完成到普通TCP 包的轉(zhuǎn)換。這樣，在鏈路中不全是P4 路由器的情況下，也可以局部地實(shí)現(xiàn)優(yōu)化HTTP 傳輸，是一種可行的提高兼容性的改進(jìn)方案。

5 結(jié)語

HTTP 協(xié)議在網(wǎng)頁瀏覽中使用非常普遍，優(yōu)化請求過程就顯得尤為重要和有意義。本文提出了一種在 HTTP 請求過程的具體環(huán)境中采用ICN 的思想進(jìn)行通信的解決方案。由于網(wǎng)內(nèi)緩存和請求聚合是ICN 的固有特性，我們主張通過使用P4 語言對 HTTP 請求過程實(shí)現(xiàn)ICN 傳輸模式，也就是實(shí)現(xiàn)HTTP 的網(wǎng)內(nèi)緩存與請求聚合。主要的挑戰(zhàn)在于不同數(shù)據(jù)包的轉(zhuǎn)換和識別，以及在轉(zhuǎn)發(fā)節(jié)點(diǎn)上進(jìn)行的緩存和聚合。通過應(yīng)用一個(gè)代理應(yīng)用程序來代理 HTTP請求過程并實(shí)現(xiàn)數(shù)據(jù)包轉(zhuǎn)換，并且使用 P4 語言來配置轉(zhuǎn)發(fā)節(jié)點(diǎn)，使它們能夠緩存數(shù)據(jù)和聚合請求。

相比于其他網(wǎng)絡(luò)內(nèi)緩存的實(shí)現(xiàn)方案，如文獻(xiàn)[10]和[21]，本文所提出的方案由于使用了P4，算法更為輕便，相對于其他研究，本文提出的方法重點(diǎn)關(guān)注了對響應(yīng)速度的優(yōu)化提升，經(jīng)過驗(yàn)證，其改善的效果也比較顯著。

本文中的實(shí)驗(yàn)是在幾臺安裝了Ubuntu 操作系統(tǒng)的虛擬機(jī)上進(jìn)行的，為了評估在文中提出的方案的功能和性能而設(shè)計(jì)了一個(gè)網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)。實(shí)驗(yàn)結(jié)果表明，在HTTP 請求過程中采用ICN 傳輸?shù)乃悸?，?shí)現(xiàn)HTTP 的網(wǎng)內(nèi)緩存是合理的，該方案可以提高網(wǎng)絡(luò)的傳輸效率，減少網(wǎng)絡(luò)中的冗余流量。這些都有利于提高用戶瀏覽網(wǎng)頁的體驗(yàn)。

關(guān)于第四部分中所描述的改進(jìn)方案，計(jì)劃在未來對其進(jìn)行更深入的實(shí)現(xiàn)方式設(shè)計(jì)，實(shí)施測試實(shí)驗(yàn)與性能評估，可能的話，不僅在虛擬機(jī)上，也計(jì)劃在一些硬件設(shè)備上配置文中的方案進(jìn)行測試評估。

利益沖突聲明

所有作者聲明不存在利益沖突關(guān)系。