TWI467968B

TWI467968B - Ｈｔｔｐ最佳化、多歸屬、行動性和優先順序

Info

Publication number: TWI467968B
Application number: TW99144798A
Authority: TW
Inventors: Mark Watson; Lorenzo Vicisano
Original assignee: Qualcomm Inc
Priority date: 2009-12-18
Filing date: 2010-12-20
Publication date: 2015-01-01
Also published as: US8964757B2; WO2011075738A1; JP2013515399A; EP2514164A1; TW201141134A; EP2514164B1; JP5795327B2; CN102656863A; US20110222404A1; KR101450293B1; JP2015164330A; KR20120098894A; CN102656863B

Description

HTTP最佳化、多歸屬、行動性和優先順序

基於專利法主張優先權

本專利申請案主張2009年12月18日提出申請的標題名稱為「HTTP Optimization,Multi-Homing,Mobility and Priority」的臨時申請案第61/288,119號的優先權，該臨時申請案被轉讓給本案的受讓人並且在此以引用方式明確地併入本文。

對同在申請中專利申請的引用

本專利申請案與如下同在申請中美國專利申請案有關：Ramin Rezaiifar等人的「BINDING/AGGREGATING MULTIPLE INTERFACES AT APPLICATION LAYER」，該申請案的代理案號為第100528U2號，該申請案與本案同時提出申請，已轉讓給本案的受讓人並且以引用方式明確地併入本文。

本案大體而言係關於通訊，並且更特定言之係關於用於在無線通訊網路中取得超文字封包資料內容的技術。

超文字傳輸協定(HTTP)是網頁瀏覽器和網頁應用程式所使用的主要的通訊協定。大型基礎設施已經在網際網路內建立起來，以便以內容傳遞網路的形式支援HTTP協定的高效操作。因此，數量不斷增加的應用程式正在被遷移到HTTP協定。儘管此種遷移有其他的原因(例如，網路位址轉換(NAT)和防火牆遍歷)，但是利用網路基礎設施大規模的可擴展性的能力是主要的驅動力。

當今，網站通常是非常複雜的，其包括了數十或數百個物件，其中每個物件必須使用HTTP來單獨請求。已經在HTTP內定義了各種最佳化，以提高能夠將物件從伺服器傳輸到客戶端的速度。在有線網路內，已經對該等最佳化應用程式進行了大量的工作；然而，對於理解該等特徵如何在具有高往返時間(RTT)和高可變頻寬的更具挑戰性的行動環境中起作用並進行組合而言，亦遺留有未解決的問題。特定言之，應當注意到，很多HTTP工作是在一些年前完成的，在當時，行動網路的特性是與現在顯著不同的。

下文提供了簡要概述，以便提供對所揭示態樣中的一些態樣的基本理解。該概述不是廣泛的綜述，而是意欲既不辨識關鍵或重要元素，亦不限定該等態樣的範疇。其目的是以簡化形式提供所述特徵的一些概念，來作為稍後提供的更詳細描述的序言。

在一個態樣中，提供了一種用於藉由以下操作進行封包資料通訊的方法：建立數個並行連接用於封包資料通訊；經由該數個並行連接發送複數個管線請求，以用於取得由分別儲存在複數個伺服器上的封包資料部分構成的超文字物件；及動態地改變並行連接和經由該等並行連接的管線請求的數目，以減少未處理請求，同時維持完全的鏈路利用。

在另一態樣中，提供了用於封包資料通訊的至少一個處理器。第一模組建立數個並行連接用於封包資料通訊。第二模組經由該數個並行連接發送複數個管線請求，以用於取得由分別儲存在複數個伺服器上的封包資料部分構成的超文字物件。第三模組動態地改變並行連接和經由該等並行連接的管線請求的數目，以減少未處理請求，同時維持完全的鏈路利用。

在一額外態樣中，提供了一種用於封包資料通訊的電腦程式產品。非暫態電腦可讀取媒體儲存了代碼集。第一代碼集使電腦建立數個並行連接用於封包資料通訊。第二代碼集使該電腦經由該數個並行連接發送複數個管線請求，以用於取得由分別儲存在複數個伺服器上的封包資料部分構成的超文字物件。第三代碼集使該電腦動態地改變並行連接和經由該等並行連接的管線請求的數目，以減少未處理請求，同時維持完全的鏈路利用。

在另一態樣中，提供了一種用於封包資料通訊的裝置。該裝置包括用於建立數個並行連接以用於封包資料通訊的構件。該裝置包括用於經由該數個並行連接發送複數個管線請求，以用於取得由分別儲存在複數個伺服器上的封包資料部分構成的超文字物件的構件。該裝置包括用於動態地改變並行連接和經由該等並行連接的管線請求的數目，以減少未處理請求，同時維持完全的鏈路利用的構件。

在另一態樣中，提供了一種用於封包資料通訊的裝置。收發機建立數個並行連接以用於封包資料通訊。該收發機進一步經由該數個並行連接發送複數個管線請求，以用於取得由分別儲存在複數個伺服器上的封包資料部分構成的超文字物件。計算平臺動態地改變並行連接和經由該等並行連接的管線請求的數目，以減少未處理請求，同時維持完全的鏈路利用。

為了實現前述及相關目標，一或多個態樣包括下文中充分描述的並在請求項中特定指出的特徵。以下描述和附圖詳細闡述了某些說明性態樣，並且指示了可以運用該等態樣的原理的各種方式中的一小部分。根據下文結合附圖考慮的詳細描述，其他優點和新穎性特徵將變得顯而易見，並且所揭示的態樣意欲包括所有該等態樣及其均等物。

將並行HTTP連接和管線操作進行組合具有益處，亦即，克服了增加往返時間(RTT)的影響。通常，已知的瀏覽器運用固定數目的並行連接和固定數目的未處理請求，儘管並行連接的數目是受必須聯絡的不同伺服器組的影響的。

本發明的一個態樣是即時地改變並行連接和管線請求的數目，使得未處理請求的數目是最小的，並且鏈路保持被完全利用。

例如，可以基於請求的資料的總量來改變該等數目，以確保鏈路保持被完全利用；然而，尚未接收的資料的總量不能超過頻寬和RTT的乘積。該等數量皆是連續變化的。此外，因為在物件的標頭到達之前，該物件的大小是未知的，所以未處理資料的總量不是精確已知的。

一種可能是建構所有該等變數的機率模型，並且試圖將鏈路變為閒置的整體機率保持在某個閾值以下。例如，物件大小的機率模型可以使用關於物件類型(圖像、HTML、JavaScript語言、CSS等)與物件大小分佈的對應關係的歷史資料。尤其是若有該物件的先前快取的版本，則因為該物件沒有變化，所以將要返回的資料是零(或者僅僅是HTTP標頭)，或者將要返回的資料是新的版本，其中該新的版本很可能與舊的版本具有類似的大小。

因此，基於最近量測的頻寬和往返時間，可以持續對更多的物件進行管線操作，直到存在如下可能，亦即，已請求但亦未接收的資料超過頻寬與RTT的乘積。只要更多的資料到達或者觀測到頻寬或往返時間的變化，就可以重複該計算。藉此，如在下文更詳細描述的，在連接的生命期期間，在HTTP連接上的管線請求的目標數目可以改變。

現在將參照附圖描述各個態樣。在下文的描述中，為了闡釋的目的，闡述了大量的特定細節，以便提供對一或多個態樣的透徹理解。然而，顯然，可以在沒有該等特定細節的情況下實施各個態樣。在其他實例中，以方塊圖形式圖示熟知的結構和設備，以便促進描述該等態樣。

在圖1 中，在通訊系統100 中，行動設備、存取終端或使用者裝備(UE)102 針對超文字內容104 進行管線請求103 ，其中超文字內容104 包含儲存在複數個伺服器112-114 上的物件106 、108 、110 。在一個示例性態樣中，行動設備102 經由空中鏈路116 獲得存取，其中該空中鏈路116 使用於接收物件106-110 且因此顯現超文字內容104 所需要的往返時間(RTT)加重。在一個態樣中，行動設備102 具有用於與節點(例如，巨集細胞服務區、毫微微細胞服務區、中繼)119 進行通訊的無線電收發機118 ，其中節點119 用作無線廣域網路(WWAN)120 到網際網路協定多媒體子系統(IMS)122 到位於核心網(CN)(例如，網際網路)124 中的伺服器112-114 的一部分。

替代或另外地，行動設備102 具有用於與節點128 進行通訊的收發機126 ，其中節點128 用作用於經由CN124 存取伺服器112-114 的無線局部存取網路(WLAN)130 。

替代或另外地，行動設備102 具有用於與節點134 進行通訊的收發機132 ，其中節點134 用作個人存取網路(PAN)136 ，並且耦合到如在138 處圖示的WWAN120 或者如在140 處圖示的WLAN130 ，以用於經由CN124 到達伺服器112-114 。

在一個態樣中，收發機118 、126 、132 建立數個並行連接用於封包資料通訊。收發機118 、126 、132 進一步經由該數個並行連接發送複數個管線請求，以用於取得由分別儲存在複數個伺服器上的封包資料部分構成的超文字物件。

行動設備102 的計算系統124 具有HTTP最佳化部件144 ，其動態地改變並行連接和經由該等並行連接的管線請求的數目，以減少未處理請求，同時維持完全的鏈路利用。

在圖2 (圖2A 和圖2B )中，針對HTTP最佳化、多歸屬、行動性和優先順序圖示了示例性方法200 或操作順序。方塊204 圖示了建立數個並行連接以用於封包資料通訊。在特定的態樣中，建立數個並行連接是藉由使到該複數個伺服器中的每個伺服器的連接的數目最小化來完成的(方塊206 )。使用該數個並行連接來減少對於延遲的或損失的所請求封包資料的整體壅塞回應(方塊208 )。

經由該數個並行連接發送複數個管線請求，以用於取得由分別儲存在複數個伺服器上的封包資料部分構成的超文字物件(方塊210 )。

動態地改變並行連接的數目，以用於經由並行連接發送額外的管線請求，以減少未處理請求，同時維持完全的鏈路利用(方塊212 )。例如，完全的鏈路利用可能需要貪婪(greedy)資源利用或剛好及時(JiT)資源利用。

在示例性態樣中，該動態改變是藉由估計頻寬和往返時間來達成的(方塊214 )。持續發送管線請求，直到存在已請求但亦未接收的封包資料超過了估計的頻寬和往返時間的乘積的可能情況(方塊216 )。

在示例性態樣中，包括了一或多個進一步的最佳化，尤其是若網路支援的話，其中該等最佳化促進HTTP取得。

例如，決定漸進順序以用於顯現封包資料部分，並且針對該漸進順序來對該複數個管線請求的順序進行優先順序排序(方塊218 )。若在取得期間發生變化(方塊220 )，則重新對該漸進順序進行優先順序排序，並且更新該過程(方塊222 )。

對於另一個實例，請求採用標頭壓縮的該複數個管線請求(方塊224 )。

對於一個額外實例，網路可以辨識(預料)到行動設備可能需要額外的資源。在此種情況下，可以接收未被請求的、伺服器辨識的資源(方塊226 )。若不需要，則以取消伺服器辨識的資源來進行回應能夠避免不必要地消耗空中傳輸資源(方塊228 )。

對於另一個實例，可以使用標頭範圍特徵將該複數個管線請求作為複數個部分管線請求來進行發送(方塊230 )。

對於另一個實例，可以藉由利用連接循環來聚合多歸屬主機的鏈路，來發送該複數個管線請求(方塊232 )。藉由偵測到介面已經變成不可用或者已經變成可用(方塊234 )，辨識使用該介面的開啟的連接(方塊236 )，建構已經在該等開啟的連接上發出但未完成的管線請求的列表(方塊238 )，以及部分地基於所辨識的開啟的連接、介面和未完成的管線請求列表來利用連接循環動態地改變並行連接和經由該等並行連接的管線請求的數目(方塊240 )，則可以解決考慮到該多歸屬能力的行動性。

在示例性態樣中，行動設備可以針對每個介面維護單獨的網域名稱服務(DNS)快取，並且在缺少作業系統和網頁瀏覽器支援的情況下，可以使用網路代理、靜態定義的路由和代理自動配置(PAC)腳本。

圖3 在圖表300 中圖示使用Firefox網頁瀏覽器在針對nytimes.com啟用並行連接和管線操作的情況下，更長的RTT對於頁面載入時間的影響(以秒為單位)。測試的頁面包括大約一百(100)個物件，總計約1.3 MB的資料。在固定頻寬1.5 Mb/s鏈路上進行該測試，並且以不同的額外延遲量重複該測試，以模擬更高的RTT鏈路。在完全鏈路利用的情況下，可能需要佔用大約七(7)秒來下載頁面，並且事實上其是以非常低的往返時間來達成的，正如可能在有線網路上所觀測到的。然而，顯然，隨著RTT增加，鏈路利用與RTT成反比地急劇下降。

該實驗結果表明，若RTT大於通常在有線網路上發現的值，即使現代化網頁瀏覽器亦不能完全利用中等頻寬的鏈路。此外，造成的增加的頁面載入時間完全在影響使用者體驗的範圍內(因為頁面載入時間從7 s到21 s增加200%是非常顯著的，但是從100 ms到300 ms增加200%可能就不顯著)。

如本文所使用的，鏈路利用代表客戶端利用網路準備分配的所有資源的能力。在EV-DO或HSPA情況中，當一個使用者在此種意義上「未充分利用」鏈路時，將未使用的容量分配給其他使用者，所以從整體上看，不存在未充分利用無線電資源。但是，在吾人看來，差的鏈路利用確實造成了差的使用者體驗，正如在較長的頁面載入時間方面所觀測到的。

作為具體的實例，若十(10)個使用者各自請求1 MB的檔案(不必所有皆在同一時間)並且網路具有8 Mb/s的共享容量，則將佔用10 s來將資料傳遞到所有的使用者。在平均等待時間方面，「順序地」處理資料比「並行地」向所有使用者傳遞資料更好，其中「順序地」處理資料對每個使用者佔用1 s，「並行地」向所有使用者傳遞資料對每個使用者佔用差不多10 s。

可以使用在HTTP協定中可用的各種技術來最佳化物件傳遞：持久連接：HTTP 1.0規範要求針對每個HTTP請求建立新的傳輸控制協定(TCP)連接。因為每個TCP連接建立意味著SYN/ACK(同步/確認)交換和由於TCP壅塞控制的慢啟動階段而導致的慢傳輸時段，該需求在物件傳遞時間方面需要高昂的代價。

HTTP 1.1引入了持久連接，以更好地支援向相同的伺服器發出多個請求的情況。在該情況中，在完成對先前回應的接收之後，藉由在相同連接上發送新的HTTP請求，來重用TCP連接。在該方法中，在發送請求與接收回應的第一個封包之間的時間(一個往返時間)中，下行鏈路是閒置的。

從圖4 中可以看到單個持久連接的鏈路使用模式400 ，其中上行鏈路請求402 和下行鏈路回應404 之間的間隙指示了未充分利用鏈路(以間隙的形式表示)和若RTT越高則未充分利用越嚴重的事實。

應當瞭解，本案的益處是僅僅增加了鏈路頻寬而沒有處理RTT，該益處本身並沒有提高鏈路利用方面的效能。進一步參照圖4 ，增加頻寬將會根據時間使每個上行鏈路和下行鏈路區塊更窄(亦即，在較少時間內傳輸相同的資料)，但是不會減小間隙的大小。實際上，間隙將佔據總下載時間的較大部分，因此在此種情況下，增加頻寬減小了鏈路利用。

並行連接：現代瀏覽器以並行方式開啟到相同或不同伺服器(或該兩種情況)的多個TCP連接。該技術的效果是兩方面的：第一，對於多個有效發送TCP連接的聚合的壅塞控制行為可以認為是等同於單個TCP連接，但是在慢啟動期間壅塞訊窗更快速地開啟，並且對每個丟棄封包的壅塞回應更少。第二，在一個連接上的傳輸斷斷續續的情況下(如上文針對持久連接所示)，傳輸之間的閒置時段可以由其他連接使用，藉此提高了鏈路利用。

管線操作：實際上，HTTP 1.1允許發送多個請求，而不需等待對第一請求的回應的完成。此舉使得伺服器能夠緊連著地發送回應，而不需鏈路在回應之間變成閒置。因為HTTP沒有提供其他的機制來匹配請求和回應，所以必須按照與接收請求相同的順序來發送回應。

在圖5 中，針對持久連接的鏈路使用模式500 圖示管線操作的效果，其中該持久連接具有第一上行鏈路請求502 和第二上行鏈路請求503 和下行鏈路回應504 。

現代的網頁瀏覽器基本上皆是使用上文的前兩種技術。然而，儘管在HTTP 1.1規範中進行了強制，但是對管線操作的支援在伺服器處以及有時在代理處不是普遍的，並且尤其是在透通代理的情況中存在一些罕見的失效模式的跡象。因此，在實施管線操作時需要進行注意，例如，注意偵測失效模式並且適當地後饋到非管線操作，以及藉由保持該技術在其中已經成功的伺服器的白列表。Opera瀏覽器預設啟用管線操作(並且顯然實施了此類技術)。在Firefox中支援管線操作，但是預設禁用了管線操作。Safari和Chrome(當前)不支援管線操作。

從圖3 中，在瀏覽器中沒有廣泛支援管線操作的原因是清楚的，且上文提及了該等問題：經由單獨使用持久連接和並行連接，瀏覽器對鏈路的利用在低RTT連接上是非常高的。在近些年中，內容傳遞網路已經顯著地降低了典型的網路RTT，從而改良了瀏覽器的執行(其是主要的有價值的CDN建議)，並且由於大多數是有線和無線局部存取網路(WLAN)網頁瀏覽器，所以發現的問題很少。

可能希望在支援管線操作時，在單個連接的情況下，鏈路利用應當是100%的，因為在回應之間不應該有間隙。然而，在一些情況中，儘管伺服器可以按照管線的形式接受請求，但是其可能不對每個請求進行處理，直到前一個已經完成。此舉導致回應之間的間隙等於伺服器處理所佔用的時間。若伺服器是重負載，並且必須執行複雜的功能(諸如，執行用於產生回應的腳本)及/或必須參考外部伺服器(例如，資料庫)，則該時間可能是顯著的。

若存在中間代理，該中間代理在輸入側接受管線請求而在輸出側發出串列請求，則可以觀測到相同的效果。即使在伺服器並行地處理管線請求的情況下，在發送給定回應的時間到來時，該處理的結果亦可能是不可用的。

初始實驗：以上資料使吾人相信在高RTT鏈路上，諸如，在無線廣域網路(WWAN)上，存在網頁瀏覽效能提高的空間。進一步的證據來自在客戶端和中間代理之間應用管線操作，以及額外地引入亂序返回回應的可能性(亦即，經由客戶端和代理所支援的新的HTTP擴展)。在該方法中，因為客戶端和代理之間的低RTT允許單個TCP連接完全利用WWAN鏈路，並且代理被設計為在輸出側發出並行請求，所以提高了鏈路利用。亦可以併入對所請求的資源的早期辨識。

應當注意，若目標HTTP伺服器直接支援用於亂序回應的HTTP擴展(並且假設彼等伺服器並行地處理請求)，則此種HTTP擴展可以提供益處。應當相信，除了下文針對Google SPDY所描述的範圍，實驗尚未涉及此種方法。

在本發明中進一步執行的實驗針對不需要部署代理的情況(亦即，僅客戶端側的技術)。為了清楚起見，最初聚焦在「理想瀏覽器」上，在該「理想瀏覽器」中，已經消除了除網路連接之外的所有瓶頸。特定言之，「理想瀏覽器」：對於用來顯現頁面所需要的完整的請求集合具有先驗知識；及在接收到時，立即顯現內容。

因此，對於頁面載入時間的僅有貢獻是使用HTTP協定在網路上傳輸資料所需要的時間。該「理想瀏覽器」被實施為Python腳本，其中該腳本是與物件列表一起預先提供的(其是從對實際網頁下載的追蹤得到的)，並且該腳本實施了使用HTTP持久連接、並行連接和管線操作來下載物件的演算法。對下載所有物件所佔用的時間進行量測。

為了更好地理解並行連接、管線操作以及網路頻寬和RTT之間的相互影響，對於在一(1)個和十(10)個並行連接之間以及在每個連接上有一(1)個和十(10)個未處理請求之間進行實驗。(一(1)個未處理請求對應於標準的非管線操作方法，「n」個未處理請求意味著最初發送了「n」個請求，且隨後每次完全接收到一個回應時發送一個新的請求)。

在表1-表6中圖示針對不同網路頻寬和RTT的結果。特定言之，在實際網路伺服器追蹤上，多個連接和管線操作的不同配置的效能被理想化了。該網路請求追蹤是使用Wireshark從風行的網站收集的。隨後，對倒出檔案進行處理以產生請求追蹤檔案。對於初始實驗，假設所有請求是預先已知的並且是按順序執行的。僅從主伺服器，亦即，不按比例共享構成所涉及的網站的物件的伺服器，請求物件。主伺服器現象亦是針對風行網站來表徵的。

下文的表1圖示針對多個連接和管線操作的每個配置觀測到的平均下載時間：

下文的表2-表7圖示針對多個連接和管線操作的每個配置觀測到的平均下載時間：

在該等實驗中，在進行實驗的同時，在後臺下載一些內容。

概括地說，圖6 提供了在固定的1.5 Mb/s頻寬情況下針對不同RTT以及在3G連接上和具有後臺訊務的3G連接上(其中該兩個3G連接皆具有高於1.5 Mb/s的頻寬)達成的最佳頁面下載時間。對每種情況的註解提供了達成最佳結果時的並行連接數目和管線操作的總量。

應當注意，為了清楚起見，該等實驗局限於頁面物件的90%位於單個伺服器上，但是本發明的態樣可以擴展到多個伺服器結果。

應當瞭解，根據圖6 ，在具有本案的益處的情況下，原則上，下載時間不必像在圖3 中對RTT非常敏感。

HTTP最佳化、多歸屬、行動性和優先順序：本發明解決了在HTTP堆疊中對請求和連接的最佳構造和排程的問題，從而改良了頁面載入時間並且亦提供了對於物件優先順序變化的更大的回應性，例如，在滾動網頁使得部分下載的圖像不再可見時。

本發明亦考慮了對於在HTTP的應用層上的多歸屬和行動性的解決方案。多歸屬提供了對多個介面(例如，WWAN和WLAN介面)的同時使用，此舉改良了下載時間，尤其是在介面的可用頻寬處於相同的數量級的情況下(因為WLAN是回載受限的，所以通常是此種情況)。行動性提供了隨著設備移動而切換連接。多歸屬和行動性結合起來提供了更平滑的行動性。相比諸如分別需要伺服器或網路支援的多徑傳輸控制協定(MPTCP)或行動IP之類的傳輸層或網路層解決方案而言，以此方式可以在沒有伺服器或網路支援的情況下提供行動性。

相信本文描述的技術是具有新穎性的，該等技術支援多歸屬和行動性，並且使用多部分請求，以提高對優先順序改變的回應性，並且提高多歸屬和行動性支援。此外，相信用於針對每個介面維護單獨的網域名稱服務(DNS)快取的技術是具有新穎性的。

最後，吾人亦描述了用於在儘管使用了網路代理、靜態定義的路由和代理自動配置(PAC)腳本，但缺少作業系統和網頁瀏覽器支援的情況下，實施本文描述的技術的一部分的新穎技術。

下文描述了一般性的問題：HTTP堆疊是藉由具有一組統一資源定位符(URLs)形式的一組需要的資源的應用程式(例如，網頁瀏覽器)來提供的。該等URL可以在一個時間或者一個時間段中提供。HTTP堆疊關於何時以及如何對該等資源發出請求來做出若干決策。特定言之：若在同一個伺服器上多個資源可用，則可以在單個TCP連接上對該等請求進行管線操作。

若此已經完成，則需要決定請求的順序。

對管線操作的支援不是普遍或者連續的，所以可能期望限制未處理請求的數目，或者以某種方式偵測伺服器對於管線操作的支援。

伺服器可以針對亂序回應支援QC HTTP擴展，在此種情況下，對於對請求的排序和未處理請求的數目存在不同的準則。

對於在任何一個時間應當啟開的並行TCP連接的數目存在限制，且此導致需要選擇用於建立到不同伺服器的連接的順序。

因此，基本問題是以使鏈路利用最大化的方式來排程TCP連接和在彼等連接上的HTTP請求。此被稱為問題1。

應當注意，本文圍繞著在某些伺服器處可用的資源描述了該問題。該等伺服器是擁有內容的原始網路伺服器(原始伺服器)或在客戶端和原始伺服器之間的路徑上的(非透通)代理伺服器。代理伺服器可以專用特定的一或多個資源(在CDN代理的情況下)，或者可以適用於任何資源(在配置式的或學習式的本端代理的情況下)。本文描述的問題和演算法與客戶端為了取得資源而存取的「伺服器」的種類無關：吾人假設任何可選的伺服器能力可以存在於任何類型的伺服器上。

下文可以實施對該問題的數個增強：一般而言，對於所需的資源存在某種優先順序排序。例如，對於網路伺服器而言，通常希望在圖像、廣告和視訊之前，以及在引動追蹤器(tracker)或其他附屬功能之前，接收佈局、樣式、腳本和文字資源。此舉允許在下載了所有資源之前就開始顯現頁面。所以，增強的問題是問題1加上關於資源的優先順序排序的額外資訊以及按照或接近該順序來傳遞資源的額外目標。此被稱為問題2。

另一種可能是，資源的優先順序排序可能在完全接收到所有資源之前改變(此外，記住問題1包括了在下載過程期間可能向需求列表中添加新的資源的可能)。例如，若在完全下載了網頁之前使用者滾動該網頁，並且因此資源排序改變以使可以看到的彼等資源的優先順序優先，則會發生此種情況。在該情況中，額外目標是考慮該改變或優先順序，並且確保在該改變之後，可用資源保持對最高優先順序資源而言是專用的。此被稱為問題3。

另一種情況是，在該情況中，客戶端具有到多個介面的存取，並且從而具有到擁有該等資源的伺服器的多個路徑。此處應當考慮，由於CDN的普通操作──相信在現有系統中不支援的操作，對於網域名稱的DNS解析可能隨著介面而變化。在該情況中，由於利用所有的多個介面上的可用頻寬的額外目標，而使問題增強。此被稱為問題4。

最後，可能可用介面組會變化。在該情況中，需要以最小的資料損失，並且在維持可用頻寬應當對最高優先順序資源專用的原則的情況下，高效地處理該變化。此被稱為問題5。

綜上所述，問題1關注對管線操作的最佳使用和對一組URL的請求排程。該目標是最佳化頻寬使用，並且從而減小頁面下載時間。

問題2加入了對URL的優先順序排序和要考慮該優先順序的目的。該目標是使得能夠逐漸地顯現網頁，並且從而提高察覺的頁面下載速度。

問題3允許優先順序可以改變。該目標是確保快速地將頻寬重新指派給高優先順序物件，並且從而提高對於使用者焦點變化(點擊鏈結、改變標籤、滾動等)的回應性。

問題4考慮了對多個介面的高效使用，且因此目標是經由對多歸屬主機的鏈路聚合來改良頁面下載時間。

問題5考慮了可用介面的變化，且因此目標是支援行動性。

此處，將基於HTTP協定的該等問題的解決方案集中在HTTP應用層，而不是傳輸層上。

現有方案：現有網頁瀏覽器試圖解決問題1以及在某種程度上解決問題2。然而，當前的實施具有若干缺陷。第一，在下載頁面時逐漸地辨識所需的資源(URLs)，此意謂在沒有考慮關於客戶端已經知道的未來所需資源的資訊的情況下，對於開啟和關閉連接做出決定。

第二，現有瀏覽器普遍對於並行連接的數目具有隨意的限制。不預期大量的並行連接提供優勢。一般的經驗法則似乎是在六(6)個並行連接以上具有減少的返回。但是應當注意，WWAN網路通常配置有大的網路側下行鏈路緩衝器。當鏈路被完全利用時，此可以對高RTT產生貢獻。因此，若另一個連接已經在利用該鏈路，則並行連接的TCP慢啟動會非常慢。

第三，現有瀏覽器不總是良好地使用管線操作。此是因為沒有連續地在HTTP代理中支援管線操作。此外，在由於要發送的下一個物件在代理處尚不可用而使TCP連接變為閒置的情況下，利用代理來使用管線操作會造成「阻塞」的問題。若在相同連接上請求的另一個物件在該代理處可用，則期望以與「亂序回應」相同的方式發送該物件。

最近在Google發佈的SPDY專案(http://dev.chromium.org/spdy)目標在於藉由在TCP和HTTP之間插入薄薄的多工層來解決問題1和問題2。此舉允許在指派了優先順序的情況下在單個TCP連接上並行地發生多個HTTP異動。發起人將問題3辨識為未來的工作。SPDY專案亦將HTTP標頭壓縮辨識為重要的部分。儘管沒有特別提到WWAN，但是特定言之，HTTP請求壓縮對於WWAN網路而言可能是有價值的。

本案分析了基於HTTP 1.1標準逐步解決問題1-問題5的示例性方法。此外，描述了能夠進一步提高效能的一些最小的、可選的伺服器增強。

問題1：基本連接和請求排程：該部分的基本思想是單獨地看待資源辨識、TCP連接建立和排程實際請求。第一，假設辨識到所需的資源並且因此需要聯絡的完整的伺服器組是已知的。第二，建立到該等伺服器的TCP連接，但是不必一次性全部建立且亦不必每個伺服器一個連接。第三，將請求映射到所建立的連接。

決定開啟連接有兩個原則：

第一，使到每個伺服器的連接的數目最小化，並且隨後利用管線操作。此是因為每次建立新的連接時付出了高昂的代價(SYN/ACK和慢啟動)。若其他有效連接意謂存在大的佇列延遲並從而存在大的RTT，則尤為如此。

第二，當封包損失或延遲時，利用多個並行連接來減少整體壅塞回應。若有「n」個TCP連接，則對單個損失的回應將組合的壅塞訊窗減小1/2n。

此等兩個目標明顯是衝突的，因此引入了參數來控制此種權衡：令P_max 為並行TCP連接的最大數目，並且令P_min 為並行TCP連接的最小數目的目標。目的是每個伺服器建立一(1)個連接，並滿足P_min 。

給定由n個URL構成的集合U，U={U₀ ,……,U_n-1 }，可以從該集合中辨識由m個唯一的伺服器構成的集合S，S={S₀ ,……,S_m-1 }，其中m≦n。應當注意，對於現有網路伺服器立即有幫助的增強是盡可能快地針對頁面辨識盡可能多的所需URL。當前，該過程與下載和顯現過程混在一起，此是不需要的。

因為多個全合格網域名稱(FQDN)可以映射到相同的IP位址，所以藉由IP位址而不是FQDN來辨識伺服器S_j 。(下文進一步描述單個FQDN映射到多個位址的可能性。)令s(i)為URL U_i 所需的伺服器的索引(亦即，U_i 可以從S_s(i) 獲得)，並且令U(j)為能夠從伺服器S_j 獲得的URL的集合。

提供了用於建立連接並向連接分配請求的過程。在該過程中，請求時機是發出新請求的時機。如何對此進行定義是在如下兩者之間的權衡：請求/連接匹配之前提交，以及允許因為在發出新的請求之前所有請求完成而使連接變為閒置。下文提供了一些實例。

演算法1：

該過程的操作取決於如何定義請求時機。下文定義了兩種極端：貪婪請求時機：只要開啟到伺服器的連接，此就發生。

遲緩請求時機：只要在連接上完全接收到回應，此就發生。

在貪婪請求時機的情況中，在滿足最大連接數目P_max 的情況下立即發出所有請求。亦可以在多個連接上將請求分發到同一個伺服器，以便遵守P_min 。然而，一旦發出了所有的請求，就沒有機會進行改變。可能發生因為在一個連接上的請求相比在另一個連接上的請求佔用更長的時間來完成，所以有少於P_min 個連接。

在遲緩請求時機的情況中，在整個過程中遵守P_min 。然而，對於在一個回應結束和下一個回應開始之間的時間，每個連接是閒置的，其中該時間相當於一個往返時間加上伺服器回應時間。此是不支援管線操作的HTTP 1.1客戶端的標準行為。

在理想情況中，對請求時機的定義在某種程度上將在該兩個極端之間。例如，當估計將要接收到回應的剩餘時間為一個往返時間加上伺服器處理時間時，請求時機就出現。然而，伺服器處理時間是未知的，RTT僅僅是估計出的，並且無論如何該時間可能是長於前一個回應的總接收時間的。在下文的描述中，「剛好及時」(JiT)請求時機意謂最佳化的版本，其中在充足的時間中發出請求，以避免鏈路變為閒置，或者盡可能晚地變為閒置。

伺服器對管線操作的支援：傳聞代理伺服器不對管線操作提供連續的支援。HTTP 1.1伺服器(包括代理)需要處理或者忽略管線請求(亦即，為了不失敗)。因此，若已經發出大於一個的請求，則可能在已經完全接收到第一回應之後(藉由決定後面是否有第二回應)決定伺服器是否支援管線操作。在伺服器不支援管線操作的情況下，除了第一個之外，應當將已經從該伺服器請求的URL返回到伺服器集合u_i ，並且注意到不支援管線操作。到該伺服器的隨後的連接應當最多接收一個請求。

亂序回應：標準的伺服器按照接收請求的順序來返回對管線請求的回應。定義了HTTP擴展，其允許伺服器按照不同的順序返回請求。因為尤其是在代理伺服器的情況下，物件可能按照與其被請求的順序不同的順序在伺服器處變為可用，所以該HTTP擴展是有價值的。因此，按順序的物件傳遞可能造成線頭阻塞的問題。但是為了利用該特徵，需要在連接上對多個請求進行管線操作：若更多的請求被佇列，則減小了線頭阻塞的可能性，但是已經做出了更大的投入：因此，當存在該特徵時，可以期望相比不存在該特徵而言在連接上發出更多的請求。

亂序擴展包括被添加到請求中的「異動ID」標頭欄位。亂序回應返回相應的請求的異動ID的值。在回應中不存在異動ID欄位指示伺服器不支援亂序回應。

HTTP標頭壓縮：HTTP支援對實體主體而不是對請求進行gzip壓縮。Google SPDY專案辨識HTTP標頭壓縮提供了顯著的優勢，並且對於WWAN網路而言，可以預期請求壓縮將是尤其有幫助的。

按照下文的方式，可以容易地將標頭壓縮定義為反向相容的HTTP擴展：支援標頭壓縮的客戶端利用第一請求中的、與現有內容-編碼標頭(例如，標頭-編碼：gzip)類似的新的可選標頭來對此進行指示。

支援標頭壓縮的伺服器辨識出該新標頭並且返回具有壓縮標頭的回應。

可以藉由出現在串流中的標準的gzip標頭來指示標頭壓縮的開始，其中在該串流中預期有新的請求或回應。

應當將連接上的請求或回應序列壓縮為一個連續的串流。由對請求或回應的串聯來構成未壓縮的串流(包括每個請求或回應的終止換行符(terminating newline))。在每個請求或回應的結尾必須有刷新(flush)點，所以可以對此進行完全解碼，而無需接收後續資訊。

應當使用在開始壓縮之前發送的未壓縮的請求或回應，作為用於壓縮的靜態字典。

伺服器辨識的資源：Google SPDY辨識在伺服器知道將需要該資源的情況下，伺服器向客戶端返回客戶端尚未請求的資源的可能性。伺服器亦可能提供關於客戶端想要請求的資源的建議。

前一個選項需要客戶端有取消請求的能力，而後者在不需要該能力的情況下達成了大部分相同的目標。

若支援亂序回應，則所建議的方法的簡單的實施是由伺服器針對伺服器辨識的資源發送回應標頭，該回應標頭具有特定的異動ID和請求URL。此舉允許包括與快取相關的資訊(資料、電子標籤、快取控制指示)，使得客戶端能夠查詢其快取，並且決定是否請求該物件。

取消請求：若支援上文描述的亂序擴展，則可以藉由參考具有該異動ID的請求來一般性地添加用於取消請求的新的方法。此對於在管線上佇列更多請求(從而減小了線頭阻塞的可能性)可以是有幫助的，同時若必要仍舊能夠撤銷該承諾。

問題2：請求優先順序排序：問題2引入了添加的可能性，亦即，URL集合U具有優先順序。在沒有損失一般性的情況下，假設列表U₀ ,……,U_n-1 是按照優先順序的，其中第一個優先順序最高。亦添加了在較低優先順序物件之前傳遞更高優先順序物件的目標。

應當注意，該新的目標是次於使可用頻寬使用最大化的目標的：亦即，若為了使頻寬使用最大化必須不按優先順序傳遞物件，則此是可以接受的(否則，將藉由嚴格按照優先順序、在發出另一個請求之前等待在每個請求完成之後發出請求來滿足要求)。

為了支援優先順序排序，對演算法1進行了如下修改：

演算法2

1)藉由按照在伺服器上可用的最高優先順序資源的順序來置放伺服器，對U的排序導致了對S的排序。隨後，同樣以此種明顯的方式對每個集合u_i 進行排序。

2)在演算法1之後，除了在步驟2(a)、2(b)和4(c)(i)中之外，所選擇的i值應當是最小的該值。

問題3：優先順序變化：Google SPDY協定目的在於藉由在TCP和HTTP之間提供薄薄的多工層並且使用該多工層將多個請求/回應異動多工在同一個連接上，來解決該需求。如下可以看出與現有技術的區別：管線操作允許多個請求/回應異動共享TCP連接，但是要求相繼地並按照順序返回回應。

具有亂序回應的管線操作(one-shot-web)允許按照不同的順序返回回應，但是其仍舊是相繼的(每個回應必須在下一個開始之前完成)。

並行TCP連接允許並行地發送回應(多工在IP層上)，但是異動獨立地進行：沒有辦法來協調異動之間的優先順序排序。

因此，SPDY協定目標在於獲得管線操作的益處，而不要求回應相繼的完成。

首先，應當注意，在演算法2中，若使用了遲緩或剛好及時請求時機，則總是能夠在任何時間對每個集合u_i 中的未請求資源的優先順序進行重新排序。該簡單的方法可以提供顯著的益處(此被稱為演算法2a)。

現在來描述一種可替代的方案，用於基於對HTTP部分請求(亦即，具有範圍標頭的HTTP請求)的使用來以更精細的粒度處理優先順序變化。

首先，令R為最大請求大小，以位元組為單位。針對大小為R或更小的所需資源區塊發出請求。在演算法2中，用一對(URL，位元組範圍)來替代每個URL u_i 。利用由應用程式和位元組範圍[0,R-1]提供的URL來初始化該等對。

隨後，加入下文的程序，以構成演算法3：當接收到URL的第一回應標頭後，獲得物件大小F。隨後，若F>R，則利用相同的URL和位元組範圍[R,2R-1]，[2R,3R-1]，……，[rR,F-1]在u_i 中建構r:=ceil(F/R)-1個額外的項。應當注意，u_i 中的項的順序應當基於之前的URL的優先順序順序。

在該方案中，當發生優先順序變化時，已經請求的並且在連接上沒有接收到的未處理資料的總量最多是R，且因此減小了資源專用於較低優先順序資源的時間段。

為了高效地支援剛好及時(JiT)請求時機，希望R應當大於在一個往返時間中能夠發送的資料總量。可以是R根據所量測的往返時間和資料速率而改變。

問題4：支援多歸屬：多歸屬主機是具有多個已連接介面並且從而具有到網際網路的多個路由的主機。在多歸屬主機的情況中的目標是同時利用多個介面，以提高下載速度。

首先，假設HTTP堆疊已知可用的介面並且能夠指引TCP連接使用特定的介面。在現有的主機作業系統(OS)實施中不是此種情況，所以需要一些工作來達成該假設。在此種OS改良之前，可能的替代方案是提供經由獨立的介面能夠到達的HTTP代理伺服器，並且在客戶端路由表中定義針對彼等伺服器的明確的路由，其中該等路由在不同的介面上指引每個伺服器的封包。以此方式，選擇代理伺服器的操作決定了將要使用的介面，並且可以藉由將連接指引到與介面相關聯的代理來將連接指引到該介面。

在很多現有網頁瀏覽器實施中，經由使用代理自配置腳本可以控制對代理伺服器的選擇，其中代理自配置腳本允許使用者指定Java腳本功能，該Java腳本功能決定了針對給定URL使用的代理。該方法允許請求靜態地分佈在介面上，例如，一定百分比的請求分佈在一個介面上，且剩餘的請求分佈在另一個介面上。

下文圖示一個適當的腳本，其將1/N個請求指引到proxy_a並將剩餘的請求指引到proxy_b：

在該腳本中，使用URL的長度作為醢序函數。亦可以使用替代的醢序函數。

假定了用於將TCP連接指引到特定介面的基於OS的能力，一種簡單的多歸屬方法是遵循演算法2並且以循環形式將TCP連接分佈在可用介面上，其中該方法在本文中被稱為演算法4。

可以對演算法3進行相同的增強，以得到演算法5。與演算法4相比，優勢在於針對物件的部分請求分佈在連接上，所以大的物件可以分離在多個介面上。

在該等情況中，期望將P_min 設置為至少是介面的數目。

多歸屬和DNS：由於CDN的正常操作，DNS解析的結果可能取決於主機的到網際網路的連接點以及請求首先被發送到的DNS伺服器而不同。據吾人瞭解，現有的主機OS沒有考慮到該點。

在HTTP和CDN的特定情況中，不同解析結果的原因在於CDN辨識「緊鄰」連接點的適當代理。非常期望針對每個介面使用正確的代理。

問題5：行動性：假定了對問題4(多歸屬)的解決方案，則對行動性的支援被簡化為對在傳輸期間介面關閉的情況和新的介面變為可用的情況進行處理的問題。

如下，對演算法4進行增強以得到支援行動性的演算法6：當介面關閉時，辨識使用該介面的開啟的連接並且建構在彼等連接上已經發出的未完成的請求的列表。將該等資源添加回到適當的u_i 集合，並且繼續處理。

當介面開啟時，使該介面可用於在下一次必須建立連接時進行選擇。

在該兩種情況中，若P_min 是基於介面的數目來設置的，則考慮修改P_min 。

如下，可以對演算法5進行類似的增強以得到演算法7：當介面關閉時，辨識使用該介面的開啟的連接並且建構在彼等連接上已經發出的未完成的請求的列表。將該等請求添加回到適當的集合u_i ，並且繼續處理。對於正在進行中的對位元組範圍[a,b]的任何請求，辨識所接收的最後的位元組c，並且將對位元組範圍[c+1,b]的請求添加到適當的集合u_i 。

圖7 ，圖式700 圖示了前述七(7)個演算法的示例性關係。關於本案的益處，應當瞭解，在演算法1708 中從一開始應用了將資源辨識702 、連接建立704 和請求排程706 分離的基本概念，其中演算法1708 可以運用貪婪或JIT請求操作710 。演算法1708 可以最佳地利用任何可用的可選伺服器能力(例如，管線操作712 、亂序回應714 、標頭壓縮716 、伺服器辨識資源718 以及HTTP取消能力720 )，但是若該等能力不皆是可用的，仍舊提供了改良。

除了貪婪或JiT請求操作726 之外，演算法2722 添加了簡單的請求優先順序排序724 。在基於演算法2722 的演算法2a728 中，提供了重新優先順序排序730 以與剛好及時請求時機732 一起使用。基於演算法2A728 的演算法4734 藉由以循環方式向介面分配連接而提供了多歸屬736 。基於演算法4734 的演算法6738 藉由以循環方式向介面分配連接而提供了即使利用該簡單模型亦能夠支援的行動性740 。

演算法3742 藉由與請求重新優先順序排序746 和JiT請求操作748 一起使用部分請求744 而提供了粒度更精細的重新優先順序排序。當擴展在演算法5750 中時該方法亦提供了針對多歸屬752 的益處，且當擴展在演算法7754 中時該方法亦提供了針對行動性756 的益處。

圖8 是能夠用於實施本文描述的功能性的各個態樣的另一系統800 的方塊圖。在一個實例中，系統800 包括行動終端802 。如所圖示的，行動終端802 可以經由一或多個天線808 從一或多個基地台804 接收信號並且向一或多個基地台804 進行發送。此外，行動終端802 可以包括接收機810 ，其從天線808 接收資訊。在一個實例中，接收機810 可以操作性關聯於解調器812 ，該解調器812 對接收的資訊進行解調。隨後，可以由處理器814 對已解調的符號進行分析。處理器814 可以耦合到記憶體816 ，其中記憶體816 可以儲存與行動終端802 相關的資料及/或程式碼。此外，行動終端802 可以運用處理器814 來執行本文描述的方法。行動終端802 亦可以包括調制器818 ，其可以對信號進行多工處理，以用於由發射機820 經由天線808 進行傳輸。

行動終端802 進一步經由數個並行連接向基地台804 發送複數個管線請求，以用於取得由分別儲存在複數個伺服器上的封包資料部分構成的超文字物件。在記憶體816 中的並且由處理器814 執行的HTTP最佳化部件822 動態地改變並行連接和經由該等並行連接的管線請求的數目，以減少未處理請求，同時保持完全的鏈路利用。

圖9 是能夠用於實施本文描述的功能性的各個態樣的系統900 的方塊圖。在一個實例中，系統900 包括基地台或節點B902 。如所圖示的，節點B902 可以經由一或多個接收(Rx)天線906 從一或多個UE904 接收信號，並且經由一或多個發送(Tx)天線908 向一或多個UE904 進行發送。此外，節點B902 可以包括接收機910 ，其從接收天線906 接收資訊。在一個實例中，接收機910 可以操作性關聯於解調器912 ，該解調器912 對接收的資訊進行解調。已解調的符號可以由處理器914 進行分析。處理器914 可以耦合到記憶體916 ，該記憶體916 可以儲存與代碼叢集、存取終端指派、與其相關的檢視表、唯一的擾頻序列相關的資訊及/或其他適當類型的資訊。在一個實例中，節點B902 亦可以包括調制器918 ，其可以對信號進行多工處理，以用於由發射機920 經由發送天線908 進行傳輸。

在記憶體916 中的並且由處理器914 執行的HTTP最佳化支援部件922 提供了能夠由UE904 請求的能力(例如，管線操作、亂序回應、標頭壓縮、伺服器辨識資源以及HTTP取消能力)，以最佳化HTTP通訊。

參照圖10 ，圖示用於封包資料通訊的系統1000 。例如，系統1000 可以至少部分地位於使用者裝備(UE)中。應當瞭解，系統1000 被表示為包括功能方塊，該等功能方塊可以是表示由計算平臺、處理器、軟體或其組合(例如，韌體)實施的功能的功能方塊。系統1000 包括能夠聯合操作的電子部件的邏輯群組1002 。例如，邏輯群組1002 可以包括用於建立數個並行連接以用於封包資料通訊的電子部件1004 。此外，邏輯群組1002 可以包括用於經由該數個並行連接發送複數個管線請求以用於取得由分別儲存在複數個伺服器上的封包資料部分構成的超文字物件的電子部件1006 。此外，邏輯群組1002 可以包括用於動態地改變並行連接和經由該等並行連接的管線請求的數目以減少未處理請求同時保持完全的鏈路利用的電子部件1008 。此外，系統1000 可以包括記憶體1020 ，其保存用於執行與電子部件1004-1008 相關聯的功能的指令。儘管被圖示為在記憶體1020 外部，但是應當理解電子部件1004-1008 中的一或多個可以位於記憶體1020 內部。

在圖11 中，圖示了用於封包資料傳輸的裝置1102 。裝置1102 包括用於建立數個並行連接以用於封包資料通訊的構件1104 。裝置1102 包括用於經由該數個並行連接發送複數個管線請求以用於取得由分別儲存在複數個伺服器上的封包資料部分構成的超文字物件的構件1106 。裝置1102 包括用於動態地改變並行連接和經由該等並行連接的管線請求的數目以減少未處理請求同時保持完全的鏈路利用的構件1108 。

本領域技藝人士將進一步瞭解，結合本文揭示的態樣所描述的各種說明性邏輯區塊、模組、電路和演算法步驟可以實施為電子硬體、電腦軟體，或者兩者的組合。為了清楚地說明硬體與軟體的此種可互換性，已經在各種說明性部件、方塊、模組、電路和步驟的功能性方面，對其進行了一般性的描述。此種功能性是實施為硬體還是實施為軟體，取決於特定應用以及施加到整體系統上的設計約束。本領域技藝人士可以針對每種特定應用以各種方式來實施所述功能性，但是此等實施判定不應被解釋為導致脫離本案內容的範疇。

如本案所使用的，術語「部件」、「模組」、「系統」等意欲代表電腦相關實體，其可以是硬體、硬體和軟體的組合、軟體或者執行中的軟體。例如，部件可以是，但不限於，在處理器上執行的過程、處理器、物件、可執行碼、執行線程、程式及/或電腦。舉例而言，在伺服器上執行的應用程式以及該伺服器皆可以是部件。一或多個部件可以常駐在執行過程及/或線程內，並且部件可以位於一個電腦上及/或分佈在兩個或兩個以上電腦之間。

本文使用用語「示例性」來意謂作為示例、實例或說明。本文中描述為「示例性」的任何態樣或設計不必被理解為比其他態樣或設計更佳或有利。

針對可以包括數個部件、模組等的系統提供了各個態樣。應當理解並瞭解，各種系統可以包括額外的部件、模組等，及/或可以不包括結合附圖論述的所有的部件、模組等。亦可以使用該等方法的組合。本文揭示的各個態樣可以在電子設備上執行，該等電子設備包括利用觸控螢幕顯示技術及/或滑鼠和鍵盤類型介面的設備。此等設備的實例係包括：電腦(桌上型和行動型)、智慧型電話、個人數位助理(PDAs)和其他的有線和無線電子設備。

此外，結合本文所揭示的態樣所描述的各種說明性邏輯區塊、模組和電路可以利用被設計成用於執行本文所述功能的下列部件來實施或執行：通用處理器、數位信號處理器(DSP)、特殊應用積體電路(ASIC)、現場可程式閘陣列(FPGA)或其他可程式邏輯設備、個別閘門或電晶體邏輯、個別的硬體部件或者該等部件的任何組合。通用處理器可以是微處理器，但是替代地，處理器可以是任何一般處理器、控制器、微控制器或狀態機。處理器亦可以實施為計算設備的組合，例如，DSP和微處理器的組合、複數個微處理器、一或多個微處理器結合DSP核心，或任何其他此種配置。

此外，可以使用用於產生軟體、韌體、硬體或其任何組合的標準程式編寫及/或工程技術，來將一或多個版本實施為方法、裝置或製品，以控制電腦實施所揭示的態樣。如本文所使用的，術語「製品」(或者可替代的「電腦程式產品」)意欲包括可以從任何電腦可讀取設備、載體或媒體來存取的電腦程式。例如，電腦可讀取媒體可以包括但不限於磁性儲存設備(例如，硬碟、軟碟、磁條等)、光碟(例如，壓縮光碟(CD)、數位多功能光碟(DVD)……)、智慧卡和快閃記憶體設備(例如，卡、棒)。此外，應瞭解可以運用載波來攜帶電腦可讀取電子資料，諸如，在發送和接收電子郵件時以及在存取諸如網際網路或區域網路(LAN)之類的網路時所使用的。當然，本領域技藝人士應認識到在不脫離所揭示態樣的範疇的情況下，可以對此種配置進行許多修改。

結合本文揭示的態樣所描述的方法或演算法的步驟可以直接實施為硬體、由處理器執行的軟體模組，或者兩者的組合。軟體模組可以常駐在RAM記憶體、快閃記憶體、ROM記憶體、EPROM記憶體、EEPROM記憶體、暫存器、硬碟、可移除磁碟、CD-ROM，或者本領域中已知的任何其他形式的儲存媒體中。一種示例性儲存媒體耦合到處理器，使得處理器能夠從該儲存媒體讀取資訊，以及向該儲存媒體寫入資訊。在替代方案中，儲存媒體可以整合到處理器中。處理器和儲存媒體可以常駐在ASIC中。ASIC可以常駐在使用者終端中。在替代方案中，處理器和儲存媒體可以作為個別部件常駐在使用者終端中。

提供對所揭示態樣的先前描述，以使得本領域一般技藝人士能夠實現或使用本案內容。針對該等態樣的各種修改對於本領域一般技藝人士而言將會是顯而易見的，並且在此定義的一般性原理可以應用於其他實施例，而不會脫離本案內容的精神或範疇。因此，本案內容並非意欲限制於本文中所示的實施例，而是要符合與本文中所揭示的原理和新穎性特徵相一致的最寬範疇。

在考慮到上文描述的示例性系統的情況下，已經結合若干流程圖描述了可以根據所揭示標的實施的方法。儘管為了簡化闡釋的目的，按照一系列方塊來圖示和描述了該等方法，但是應當理解並瞭解，所主張的標的不受限於方塊的順序，因為一些方塊可以按照不同的順序及/或與不同於本文圖示和描述的其他方塊同時發生。此外，可能不需要所有圖示的方塊來實施本文描述的方法。此外，應當進一步瞭解，本文揭示的方法能夠被儲存在製品上，以促進將此等方法傳輸或轉移到電腦。如本文所使用的術語製品意欲涵蓋能夠從任何電腦可讀取設備、載體或媒體中存取的電腦程式。

應當瞭解，所述以引用方式全部或部分地併入本文的任何專利、出版物或其他揭示材料，僅僅是在所併入的材料不與在本案中闡述的現有定義、陳述或其他揭示材料相衝突的程度上來併入本文的。因此，並且在必要的程度上，本文明確闡述的揭示內容取代了以引用方式併入本文的任何相衝突的材料。僅僅在所併入的材料與現有揭示材料不會產生衝突的程度上，來併入所述以引用方式併入本文但與在本案中闡述的現有定義、陳述或其他揭示材料相衝突的任何材料或該材料的一部分。

100．．．通訊系統

102．．．行動設備/存取終端/使用者裝備

103．．．管線請求

104．．．超文字內容

106．．．物件

108．．．物件

110．．．物件

112．．．伺服器

113．．．伺服器

114．．．伺服器

116．．．空中鏈路

118．．．收發機

119．．．節點

120．．．無線廣域網路(WWAN)

122．．．網際網路協定多媒體子系統(IMS)

124．．．核心網(CN)/計算系統

126．．．收發機

128．．．節點

130．．．無線局部存取網路(WLAN)

132．．．收發機

134．．．節點

136．．．個人存取網路(PAN)

144．．．HTTP最佳化部件

200．．．方法

204．．．方塊

206．．．方塊

208．．．方塊

210．．．方塊

212．．．方塊

214．．．方塊

216．．．方塊

218．．．方塊

220．．．方塊

222．．．方塊

224．．．方塊

226．．．方塊

228．．．方塊

230．．．方塊

232．．．方塊

234．．．方塊

236．．．方塊

238．．．方塊

240．．．方塊

300．．．圖表

400．．．鏈路使用模式

402．．．上行鏈路請求

404．．．下行鏈路回應

500．．．鏈路使用模式

502．．．第一上行鏈路請求

503．．．第二上行鏈路請求

504．．．下行鏈路回應

700．．．圖式

702．．．資源辨識

704．．．連接建立

706．．．請求排程

708．．．演算法1

710．．．貪婪或JIT請求操作

712．．．管線操作

714．．．亂序回應

716．．．標頭壓縮

718．．．伺服器辨識資源

720．．．HTTP取消能力

722．．．演算法2

724．．．請求優先順序排序

726．．．貪婪或JiT請求操作

728．．．演算法2a

730．．．重新優先順序排序

732．．．剛好及時請求時機

734．．．演算法4

736．．．多歸屬

738．．．演算法6

740．．．行動性

742．．．演算法3

744．．．部分請求

746．．．請求重新優先順序排序

748．．．JiT請求操作

750．．．演算法5

752．．．多歸屬

754．．．演算法7

756．．．行動性

800．．．系統

802．．．行動終端

808．．．天線

810．．．接收機

812．．．解調器

814．．．處理器

816．．．記憶體

818．．．調制器

820．．．發射機

822．．．HTTP最佳化部件

902．．．節點B

904．．．UE

906．．．天線

908．．．天線

910．．．接收機

912．．．解調器

914．．．處理器

916．．．記憶體

918．．．調制器

920．．．發射機

922．．．HTTP最佳化支援部件

1000．．．系統

1002．．．邏輯群組

1004．．．電子部件

1006．．．電子部件

1008．．．電子部件

1020．．．記憶體

1102．．．裝置

1104．．．構件

1106．．．構件

1108．．．構件

結合附圖並根據上文闡述的詳細描述，本案的特徵、性質和優點將變得更加顯而易見，在附圖中，相同的元件符號在全文中辨識一致，其中：

圖1圖示用於HTTP最佳化的通訊系統的示意圖。

圖2A-圖2B圖示用於HTTP最佳化的方法的流程圖。

圖3圖示根據往返時間(RTT)的頁面載入時間的圖表。

圖4圖示單個持久連接的鏈路使用模式的圖式。

圖5圖示第一和第二上行鏈路請求和下行鏈路回應的鏈路使用模式的圖式。

圖6圖示在固定頻寬情況下針對不同RTT達成的最佳頁面下載時間的圖表。

圖7圖示用於HTTP最佳化的複數個演算法的示例性關係的圖式。

圖8圖示執行HTTP最佳化的行動終端的方塊圖。

圖9圖示支援HTTP最佳化的節點的方塊圖。

圖10圖示至少部分地位於行動設備中的系統的方塊圖，該行動設備具有用於HTTP最佳化的電子部件的邏輯群組。

圖11圖示位於網路中的系統的方塊圖，該網路具有用於支援HTTP最佳化的電子部件的邏輯群組。