[發明專利]用于可重構一體化內容流的系統和方法

有效

• 申請號: 201510466916.0
• 申請日: 2015-08-03
• 公開（公告）號: CN105373574B
• 公開（公告）日: 2020-10-30
• 發明（設計）人: M·E·莫斯科;I·索利斯
• 申請（專利權）人: 思科技術公司
• 主分類號: G06F16/953
• 分類號: G06F16/953
• 代理公司: 北京東方億思知識產權代理有限責任公司 11258
• 代理人: 林強

一個實施例提供一種用于組合可重構內容流的系統。所述系統獲得包括多個內容組成的內容集合并生成清單。所述清單中的表項對應于內容組成。所述系統獲得流構造規則集合；通過將所述流構造規則集合附帶到所述清單來生成流構造清單；并基于所述流構造規則構造流對象集合。相應的流對象可以包括內容組成的嵌入塊。所述系統對流對象集合簽名；以及通過包括之后跟隨所述流對象集合的所述流構造清單來可重構內容流，從而使中間節點能夠提取并存儲一個或多個內容組成的嵌入塊，并在稍后時間基于所述流構造清單和存儲的組成重構所述一個或多個內容組成的流對象。

技術領域

本申請一般涉及內容中心網絡(CCN)。更具體地，本申請涉及在內容中心網絡(CCN)中使用單個命名流來下載內容對象集合的系統和方法。

背景技術

互聯網和電子商務的繁榮繼續引發網絡行業的革命性變化。當今，從在線觀看電影到每日新聞發送、零售和即時消息的相當大量的信息交互是在線進行的。日益增長的互聯網應用也變成移動的。然而，當前的互聯網基于大型的基于位置的尋址方案工作。兩個最普遍存在的協議即互聯網協議(IP)和以太網協議都以終端主機地址為基礎。即，內容的消費者可以只接收通過從通常與物理對象或位置關聯的地址(例如IP地址或以太網介質訪問控制(MAC)地址)顯式請求內容的內容。此限制性的尋址方案越來越不足以滿足不斷變化的網絡需求。

最近，行業中已經提出信息中心網絡(ICN)架構，其中，內容是直接命名和尋址的。內容中心網絡(CCN)是一種示例性ICN架構，它將新方法引入到內容傳輸。代替在應用等級以內容得以通過的端對端對話查看網絡流量，內容是基于其唯一的名稱請求或返回的，網絡負責將內容從提供者路由到消費者。注意，內容包括可以在通信系統中傳輸的數據，包括任何形式的數據，諸如文本、圖像、視頻和/或音頻。消費者和提供者可以是計算機處的個人或CCN內部或外部的自動化過程。一項內容可以指整個內容或內容的相應部分。例如，新聞文章可以由體現為數據包的多項內容表示。一項內容還可以與元數據關聯，所述元數據描述或用諸如認證數據、創建日期、內容所有者等的信息加強該項內容。

在CCN中，名稱扮演重要角色。更具體地，內容對象和興趣是由其名稱標識的，名稱通常是分層結構的可變長度標識符(HSVLI)。興趣和內容對象基于其名稱在網絡中流動。在下載命名內容(可以是文件庫或網頁)時，請求者通常需要發布興趣消息的初始集合來獲得庫的目錄或網頁的標記文檔。在網頁情況下，一旦接收標記文檔，請求者需要解析標記文檔，然后開始下載由標記文檔引用的嵌入式對象。這種過程通常需要超過一個往返時間(RTT)，因此給內容下載過程帶來大量的延遲。這個問題類似于IP網絡遇到的下載延遲問題。

在IP世界里，人們還不滿足超文本傳輸協議(HTTP)的性能，原因是盡管在傳輸個別文件時非常高效，但HTTP不能有效地傳輸大量的小文件。然而，今天的網絡目的地通常包括數十個或更多的嵌入式對象，諸如圖像、級聯樣式表(CSS)文件和外部JavaScript文件的頁面。加載所有這些個別文件占用時間，原因是單獨請求這些文件并等待TCP(傳輸控制協議)會話以探測網絡能力和上升到其傳輸速度的所有這些開銷。例如，在使用HTTP通過TCP請求網站內容時，請求者通常必須等待三次TCP握手完成來發送GET請求，之后開始下載期望的HTTP和HTML標記文檔。然后，在解析標記文檔之后，請求者可以請求個別嵌入式對象。為了降低這些下載延遲，在IP設置時已經開發出某些“零往返時間”協議，諸如由Google開發的SPTY^TM(加利福尼亞門洛帕克市Google公司的注冊商標)。然而，在CCN設置中不存在這種解決方案。

發明內容