本申請(qǐng)涉及用于將媒體數(shù)據(jù)從流傳輸服務(wù)器傳送到一個(gè)或多個(gè)客戶端的數(shù)據(jù)傳輸協(xié)議。更具體地，本發(fā)明提供了可以與諸如TCP/IP的現(xiàn)有協(xié)議結(jié)合使用的增強(qiáng)型數(shù)據(jù)流控制方法。根據(jù)本發(fā)明的數(shù)據(jù)流控制方法考慮了網(wǎng)絡(luò)條件以及接收節(jié)點(diǎn)或客戶端設(shè)備條件(例如客戶端播放器的數(shù)據(jù)緩沖器)，以提高互聯(lián)網(wǎng)協(xié)議電視(IPTV)應(yīng)用的媒體數(shù)據(jù)傳輸?shù)乃俣群唾|(zhì)量。

背景技術(shù)：

視頻業(yè)務(wù)目前占了通信網(wǎng)絡(luò)(例如互聯(lián)網(wǎng)或現(xiàn)今任何類似的無(wú)線通信網(wǎng)絡(luò)，如LAN、WLAN等)上的超過(guò)60％的世界帶寬使用。如何將這些數(shù)據(jù)注入到網(wǎng)絡(luò)中對(duì)通過(guò)網(wǎng)絡(luò)的整個(gè)數(shù)據(jù)流具有重要影響。對(duì)網(wǎng)絡(luò)的不受控?cái)?shù)據(jù)注入可能導(dǎo)致?lián)砣绊懀缇徛恼w業(yè)務(wù)流、分組延遲、分組丟失、分組亂序、分組重傳、網(wǎng)絡(luò)設(shè)備(路由器、交換機(jī)等)泛濫/崩潰、以及不可控業(yè)務(wù)的泛濫。這些類型的事件導(dǎo)致網(wǎng)絡(luò)流量變慢，并且如果使用中的交換機(jī)和路由網(wǎng)絡(luò)設(shè)備無(wú)法處理流量需求，則有時(shí)會(huì)完全停止。此外，無(wú)管理數(shù)據(jù)注入將對(duì)依賴于實(shí)時(shí)通信的應(yīng)用(例如VoIP(IP語(yǔ)音)、媒體事件的實(shí)況廣播、實(shí)時(shí)視頻會(huì)議和其他時(shí)間敏感應(yīng)用)具有負(fù)面影響。

傳輸控制協(xié)議(TCP)是互聯(lián)網(wǎng)協(xié)議組(IP)(即，用于互聯(lián)網(wǎng)的網(wǎng)絡(luò)協(xié)議集合)的核心協(xié)議之一。TCP在運(yùn)行于連接到局域網(wǎng)(LANO、內(nèi)聯(lián)網(wǎng)或互聯(lián)網(wǎng))的計(jì)算機(jī)的程序之間提供可靠、有序、校錯(cuò)的八位字節(jié)流傳輸。它駐留在傳輸層。互聯(lián)網(wǎng)協(xié)議電視(IPTV)是這樣一種系統(tǒng)，通過(guò)該系統(tǒng)使用互聯(lián)網(wǎng)協(xié)議組在諸如LAN或互聯(lián)網(wǎng)的分組交換網(wǎng)絡(luò)上傳送電視服務(wù)，而不是通過(guò)傳統(tǒng)的地面、衛(wèi)星信號(hào)和有線電視格式來(lái)傳送電視服務(wù)。TCP是互聯(lián)網(wǎng)上最常用的協(xié)議。其原因是因?yàn)門(mén)CP提供了糾錯(cuò)。當(dāng)使用TCP協(xié)議時(shí)，存在“受保障傳送”。原因在于TCP中被稱為“流控制”的方法。流控制確定何時(shí)需要重新發(fā)送數(shù)據(jù)，并且在先前數(shù)據(jù)分組已成功傳輸之前何時(shí)停止數(shù)據(jù)流。這產(chǎn)生效果，其原因在于如果發(fā)送數(shù)據(jù)分組，則可能發(fā)生沖突。當(dāng)發(fā)生沖突時(shí)，接收客戶端系統(tǒng)或端點(diǎn)可以向發(fā)送數(shù)據(jù)的服務(wù)器重新請(qǐng)求分組，直到整個(gè)分組完成并且與所發(fā)送的原始分組相同為止。因此，TCP是一種高級(jí)傳輸協(xié)議，其具有100％的數(shù)據(jù)傳輸成功率、內(nèi)置流控制和糾錯(cuò)，從而在無(wú)管理網(wǎng)絡(luò)上有效運(yùn)行。對(duì)于一個(gè)或多個(gè)網(wǎng)絡(luò)段不被IPTV服務(wù)運(yùn)營(yíng)商管理的所有開(kāi)放網(wǎng)絡(luò)IPTV部署來(lái)說(shuō)，目前需要使用TCP。

然而，在IPTV流傳輸應(yīng)用中采用TCP具有許多缺點(diǎn)，并且由于該協(xié)議的結(jié)構(gòu)，可能導(dǎo)致網(wǎng)絡(luò)流量問(wèn)題。由于標(biāo)準(zhǔn)TCP的默認(rèn)數(shù)據(jù)幀結(jié)構(gòu)，因此標(biāo)準(zhǔn)TCP的數(shù)據(jù)傳輸?shù)拈_(kāi)銷大。報(bào)頭指的是數(shù)據(jù)信元或分組的第一部分，其包含諸如源地址和目的地地址的信息以及關(guān)于電信網(wǎng)絡(luò)如何處理數(shù)據(jù)的指令。報(bào)頭是數(shù)據(jù)傳輸協(xié)議中的開(kāi)銷的一部分。對(duì)于典型的TCP/IP傳輸，即大多數(shù)互聯(lián)網(wǎng)業(yè)務(wù)，報(bào)頭通常是每個(gè)分組的40個(gè)字節(jié)(20個(gè)字節(jié)的TCP和20個(gè)字節(jié)的IP報(bào)頭)。如果在所傳輸?shù)臄?shù)據(jù)中啟用了“選項(xiàng)”，則TCP和IP報(bào)頭可以大于20個(gè)字節(jié)?；ヂ?lián)網(wǎng)控制消息協(xié)議(ICMP)，即用于發(fā)送測(cè)試和控制消息的協(xié)議，具有28個(gè)字節(jié)的報(bào)頭。報(bào)頭造成的這種開(kāi)銷可能影響IPTV用戶體驗(yàn)，尤其是當(dāng)網(wǎng)絡(luò)條件異常時(shí)，即由于繁忙業(yè)務(wù)流量造成擁塞。TCP不提供切斷傳輸流以改善網(wǎng)絡(luò)擁塞的能力。另外，TCP無(wú)法在不產(chǎn)生不必要的數(shù)據(jù)浪費(fèi)的情況下管理到IPTV客戶端播放器的帶寬發(fā)送速率。

用戶數(shù)據(jù)報(bào)協(xié)議(UDP)也是互聯(lián)網(wǎng)協(xié)議組的核心成員之一。使用UDP，計(jì)算機(jī)應(yīng)用可以向互聯(lián)網(wǎng)協(xié)議(IP)網(wǎng)絡(luò)上的其他主機(jī)發(fā)送消息(在這種情況下稱為數(shù)據(jù)報(bào))，而無(wú)需預(yù)先通信來(lái)建立特殊傳輸信道或數(shù)據(jù)路徑。UDP使用具有最小協(xié)議機(jī)制的簡(jiǎn)單傳輸模型。它沒(méi)有握手對(duì)話，并且因此將底層網(wǎng)絡(luò)協(xié)議的任何不可靠性都暴露給用戶程序。UDP提供針對(duì)數(shù)據(jù)完整性的校驗(yàn)和以及用于在數(shù)據(jù)報(bào)的源和目的地處尋址不同功能的端口號(hào)。然而，在UDP中沒(méi)有傳送保障、有序性或重復(fù)保護(hù)。

UDP適合于校錯(cuò)和糾錯(cuò)不是必需或者在傳輸之前已在應(yīng)用處執(zhí)行的目的，從而避免這種在網(wǎng)絡(luò)接口級(jí)的處理開(kāi)銷。時(shí)間敏感的應(yīng)用往往使用UDP，因?yàn)閮?yōu)選丟棄數(shù)據(jù)分組，而不是等待延遲的分組，等待延遲的分組在實(shí)時(shí)系統(tǒng)中并不是一個(gè)可行的選擇。如果在網(wǎng)絡(luò)接口級(jí)需要糾錯(cuò)設(shè)施，則駐留在主機(jī)或用于發(fā)送該數(shù)據(jù)的系統(tǒng)上的應(yīng)用將需要使用傳輸控制協(xié)議(TCP)或流控制傳輸協(xié)議(SCTP)，其被設(shè)計(jì)用于此目的。

UDP具有優(yōu)于TCP的一些獨(dú)特優(yōu)點(diǎn)，但也有缺點(diǎn)。例如，當(dāng)傳輸要求將單播方法和多播方法組合時(shí)，需要UDP。多播的使用允許以固定數(shù)據(jù)速率占用可用帶寬，而不面對(duì)用戶增長(zhǎng)容量問(wèn)題。然而，UDP不能用于發(fā)送諸如網(wǎng)頁(yè)、數(shù)據(jù)庫(kù)信息等重要數(shù)據(jù)，并且其目前的用途主要限于流傳輸音頻和流傳輸視頻。UDP可以提供速度并且與TCP相比數(shù)據(jù)傳輸?shù)酶?，因?yàn)樵赨DP中沒(méi)有流控制或糾錯(cuò)的形式。因此，使用UDP在互聯(lián)網(wǎng)上發(fā)送的數(shù)據(jù)受到?jīng)_突的影響，并且會(huì)出現(xiàn)錯(cuò)誤。因此，UDP僅被推薦用于在受管理網(wǎng)絡(luò)(即，服務(wù)質(zhì)量(QoS)由服務(wù)提供商管理的網(wǎng)絡(luò))上或者當(dāng)數(shù)據(jù)丟失不是傳輸?shù)目紤]因素時(shí)流傳輸媒體。由于其簡(jiǎn)單和輕量級(jí)設(shè)計(jì)，當(dāng)在不太可能發(fā)生分組沖突的QoS管理網(wǎng)絡(luò)上傳輸數(shù)據(jù)時(shí)，UDP是一種理想的傳輸協(xié)議。與TCP相比，UDP提供了快速數(shù)據(jù)注入、更低的分組開(kāi)銷和更快的響應(yīng)時(shí)間。對(duì)于IPTV，上述益處可以改善電視等的體驗(yàn)，尤其是快速頻道切換、即時(shí)電影回放等，并且還減輕了服務(wù)器和網(wǎng)絡(luò)設(shè)備的壓力。然而，使用UDP，業(yè)務(wù)沖突和分組丟失不可避免，因?yàn)樵搮f(xié)議沒(méi)有任何內(nèi)置的流控制機(jī)制。

Nagle算法(以John Nagle命名)提出了通過(guò)減少需要在網(wǎng)絡(luò)上發(fā)送的數(shù)據(jù)分組的數(shù)量來(lái)提高TCP/IP網(wǎng)絡(luò)的效率。在該技術(shù)中，在IP/TCP網(wǎng)絡(luò)(RFC 896)中的擁塞控制中，描述了應(yīng)用以小數(shù)據(jù)塊(通常大小僅為1個(gè)字節(jié))重復(fù)發(fā)射數(shù)據(jù)的“小分組問(wèn)題”。由于TCP分組具有40個(gè)字節(jié)的報(bào)頭(20個(gè)字節(jié)用于TCP，20個(gè)字節(jié)用于IPv4)，因此對(duì)于僅1個(gè)字節(jié)的有用信息，將產(chǎn)生41個(gè)字節(jié)的分組，這是一個(gè)巨大的開(kāi)銷。這種情況經(jīng)常發(fā)生在Telnet會(huì)話中，其中大多數(shù)按鍵按壓產(chǎn)生即刻傳輸?shù)膯巫止?jié)數(shù)據(jù)。在緩慢的網(wǎng)絡(luò)鏈路上，可能有許多這樣的分組正在同時(shí)傳輸，這可能導(dǎo)致?lián)砣罎?。Nagle的算法通過(guò)組合多個(gè)小的外發(fā)消息并將它們一次性發(fā)送來(lái)工作。具體地，發(fā)送方系統(tǒng)或應(yīng)用應(yīng)該對(duì)其輸出保持緩沖，直到其具有值得輸出的完整分組，使得可以一次性發(fā)送該輸出。下面說(shuō)明使用Nagle算法的現(xiàn)有技術(shù)。

A.對(duì)于任何TCP連接來(lái)說(shuō)，最多有一個(gè)小分組未被接收機(jī)應(yīng)用或設(shè)備確認(rèn)。除非其被確認(rèn)，否則發(fā)送機(jī)不發(fā)送任何其他小分組(具有很少數(shù)據(jù)字節(jié)的有用信息)。

B.TCP收集這些小分組，并僅當(dāng)接收到該確認(rèn)之后將它們作為一個(gè)整體分組發(fā)送出去。因此，隨著更多確認(rèn)到達(dá)，發(fā)送更多的數(shù)據(jù)分組。在WAN/MAN/LAN之一上，TCP連接的往返時(shí)間(RTT)值的范圍通常為100ms至300ms。該延遲允許TCP有足夠的時(shí)間在下一個(gè)確認(rèn)到達(dá)之前收集小分組。

盡管使用TCP以及Nagle算法有利于使用TCP的一些類型的數(shù)據(jù)通信和傳輸，但是該益處并沒(méi)有擴(kuò)展到IPTV數(shù)據(jù)和服務(wù)，在IPTV數(shù)據(jù)和服務(wù)中，300ms的倍數(shù)的延遲對(duì)于確定好或差的用戶體驗(yàn)來(lái)說(shuō)可能至關(guān)重要。對(duì)于許多應(yīng)用來(lái)說(shuō)，這樣的延時(shí)不可接受。

因此，需要用于通信網(wǎng)絡(luò)上的數(shù)據(jù)分組傳輸?shù)男路椒ɑ蛐聟f(xié)議，其克服了TCP和UDP的缺點(diǎn)，并且以最小的網(wǎng)絡(luò)流量開(kāi)銷來(lái)提供速度、流控制和糾錯(cuò)。

技術(shù)實(shí)現(xiàn)要素：

在一個(gè)方面中，本發(fā)明提供一種用于通過(guò)通信網(wǎng)絡(luò)從發(fā)送節(jié)點(diǎn)向接收節(jié)點(diǎn)發(fā)送媒體數(shù)據(jù)的數(shù)據(jù)流控制方法，所述接收節(jié)點(diǎn)能夠播放所述媒體數(shù)據(jù)，所述方法包括：識(shí)別所述發(fā)送節(jié)點(diǎn)和接收節(jié)點(diǎn)之間的通信網(wǎng)絡(luò)的條件；識(shí)別所述接收節(jié)點(diǎn)的條件；以及基于所識(shí)別的所述通信網(wǎng)絡(luò)的條件和所識(shí)別的所述接收節(jié)點(diǎn)的條件來(lái)調(diào)整通過(guò)所述通信網(wǎng)絡(luò)的媒體數(shù)據(jù)流。

在另一方面中，所述發(fā)送節(jié)點(diǎn)被配置為：基于來(lái)自所述接收節(jié)點(diǎn)的對(duì)媒體數(shù)據(jù)的請(qǐng)求，對(duì)所述媒體數(shù)據(jù)進(jìn)行編碼并將編碼后的媒體數(shù)據(jù)流傳輸?shù)剿鼋邮展?jié)點(diǎn)，并且所述接收節(jié)點(diǎn)能夠?qū)λ雒襟w數(shù)據(jù)進(jìn)行解碼和回放。

在另一方面中，識(shí)別網(wǎng)絡(luò)的條件的步驟包括：檢測(cè)網(wǎng)絡(luò)流量的水平并基于檢測(cè)到的網(wǎng)絡(luò)業(yè)務(wù)的水平來(lái)確定所述發(fā)送節(jié)點(diǎn)和所述接收節(jié)點(diǎn)之間的網(wǎng)絡(luò)處于正常狀態(tài)還是處于擁塞狀態(tài)；以及

-其中，識(shí)別所述接收節(jié)點(diǎn)的條件的步驟包括：確定所述接收節(jié)點(diǎn)處的數(shù)據(jù)緩沖器處于安全水平、不安全水平還是臨界水平，所述緩沖器在安全水平是80％滿載或更多，在不安全水平是20％-80％滿載，并且在臨界水平是0％-20％滿載；其中，周期性地監(jiān)視所述網(wǎng)絡(luò)條件和所述接收節(jié)點(diǎn)條件，并以定義的間隔在所述發(fā)送節(jié)點(diǎn)和所述接收節(jié)點(diǎn)之間傳送所述網(wǎng)絡(luò)條件和所述接收節(jié)點(diǎn)條件。

在另一方面中，響應(yīng)于來(lái)自所述接收節(jié)點(diǎn)的對(duì)媒體數(shù)據(jù)的請(qǐng)求，本發(fā)明包括：

-以初始數(shù)據(jù)流傳輸速率流傳輸所請(qǐng)求的媒體數(shù)據(jù)；

-識(shí)別所述接收機(jī)節(jié)點(diǎn)支持的最大數(shù)據(jù)流傳輸速率；

-識(shí)別網(wǎng)絡(luò)的條件；

-識(shí)別接收節(jié)點(diǎn)的條件；-如果網(wǎng)絡(luò)條件被識(shí)別為正常且緩沖器的條件處于臨界或不安全水平，則連續(xù)增加數(shù)據(jù)流傳輸?shù)乃俾?，直到達(dá)到所述最大速率為止，或直到緩沖器達(dá)到安全水平為止，或直到網(wǎng)絡(luò)條件變?yōu)閾砣麨橹埂?/p>

在另一方面中，如果在連續(xù)增加數(shù)據(jù)流傳輸速率的步驟期間接收節(jié)點(diǎn)處的緩沖器達(dá)到安全水平，則所述方法包括：將數(shù)據(jù)流傳輸?shù)乃俾收{(diào)整為等于回放期間的緩沖器的消耗速率的速率。

在另一方面中，如果在連續(xù)增加數(shù)據(jù)流傳輸?shù)乃俾实牟襟E期間網(wǎng)絡(luò)條件變?yōu)椤皳砣辈⒃诘谝欢x時(shí)間段內(nèi)保持擁塞，則所述方法包括：

-識(shí)別接收節(jié)點(diǎn)處的數(shù)據(jù)緩沖器中的剩余數(shù)據(jù)的剩余回放時(shí)間；

-將數(shù)據(jù)流傳輸?shù)乃俾式档偷浇咏慊蛴?jì)算出的低流傳輸速率，或者完全暫停來(lái)自服務(wù)器的數(shù)據(jù)的流傳輸，直到網(wǎng)絡(luò)條件變?yōu)檎；蛘咚R(shí)別的剩余回放時(shí)間減少到15秒或更少為止。

在另一方面中，如果剩余回放時(shí)間減少到15秒或更少，則所述方法包括：

-請(qǐng)求所述發(fā)送節(jié)點(diǎn)接受在所述發(fā)送節(jié)點(diǎn)和所述接收節(jié)點(diǎn)之間的附加網(wǎng)絡(luò)通信鏈路；

-確定在所述接收節(jié)點(diǎn)處維持實(shí)時(shí)回放所需的附加鏈路的總數(shù)；

-由所述發(fā)送節(jié)點(diǎn)建立附加鏈路；

-從所述發(fā)送節(jié)點(diǎn)在建立的所有鏈路上均勻地流傳輸媒體數(shù)據(jù)，使得如果網(wǎng)絡(luò)條件被識(shí)別為在所述多個(gè)鏈路中的第一鏈路上擁塞，則經(jīng)由下一個(gè)可用的通信鏈路發(fā)送媒體數(shù)據(jù)。

在另一方面中，所述方法包括：通過(guò)使用每個(gè)媒體數(shù)據(jù)幀的報(bào)頭部分中的順序標(biāo)識(shí)符對(duì)無(wú)序地到達(dá)所述接收節(jié)點(diǎn)的媒體數(shù)據(jù)分組進(jìn)行重新排序。在另一方面中，所述方法還包括：

-識(shí)別能夠?qū)⑺?qǐng)求的媒體數(shù)據(jù)流傳輸?shù)剿鼋邮展?jié)點(diǎn)的一個(gè)或多個(gè)附加發(fā)送節(jié)點(diǎn)；

-由所述發(fā)送節(jié)點(diǎn)中的每一個(gè)發(fā)送節(jié)點(diǎn)建立到所述接收節(jié)點(diǎn)的附加通信鏈路，使得每個(gè)發(fā)送節(jié)點(diǎn)能夠在附加鏈路上發(fā)送媒體數(shù)據(jù)事件。

在另一方面中，所述發(fā)送節(jié)點(diǎn)處的流傳輸應(yīng)用能夠根據(jù)適合于所識(shí)別的接收節(jié)點(diǎn)的緩沖器的緩沖器條件的比特率，對(duì)要從所述發(fā)送節(jié)點(diǎn)流傳輸?shù)拿襟w數(shù)據(jù)進(jìn)行自適應(yīng)編碼。

在另一方面中，本發(fā)明提供了一種用于通過(guò)通信網(wǎng)絡(luò)從發(fā)送節(jié)點(diǎn)向接收節(jié)點(diǎn)發(fā)送媒體數(shù)據(jù)的數(shù)據(jù)流控制方法，所述接收節(jié)點(diǎn)能夠播放所述媒體數(shù)據(jù)，所述方法包括：

響應(yīng)于所述接收節(jié)點(diǎn)對(duì)媒體數(shù)據(jù)的請(qǐng)求，確定所述媒體數(shù)據(jù)的副本是本地存儲(chǔ)在所述接收節(jié)點(diǎn)處還是存儲(chǔ)在所述接收節(jié)點(diǎn)可訪問(wèn)的存儲(chǔ)器設(shè)備上；其中，如果數(shù)據(jù)請(qǐng)求的整個(gè)文件或部分的本地副本存儲(chǔ)在本地可用，則訪問(wèn)該副本并請(qǐng)求所述發(fā)送節(jié)點(diǎn)僅流傳輸缺少的部分。

在另一方面中，如果所請(qǐng)求的媒體數(shù)據(jù)的本地副本在所述接收節(jié)點(diǎn)處不可用，則所述方法包括以下步驟：

識(shí)別接收節(jié)點(diǎn)的條件，所述條件包括連接到所述節(jié)點(diǎn)的顯示屏幕的屏幕大小、分辨率和能力；

根據(jù)所識(shí)別的所述顯示屏幕支持的屏幕大小、視頻分辨率和能力，選擇用于流傳輸媒體數(shù)據(jù)的比特率；

在開(kāi)始所述流傳輸時(shí)，使用所選擇的比特率或更高比特率從所述發(fā)送節(jié)點(diǎn)流傳輸所請(qǐng)求的媒體數(shù)據(jù)，而不是以最低可用比特率開(kāi)始所述流傳輸。

在另一方面中，如果網(wǎng)絡(luò)條件被識(shí)別為擁塞，則通過(guò)僅將媒體數(shù)據(jù)分組的I幀流傳輸?shù)剿鼋邮展?jié)點(diǎn)而不將所述媒體數(shù)據(jù)的B幀和P幀流傳輸?shù)剿鼋邮展?jié)點(diǎn)，以當(dāng)前流傳輸速率繼續(xù)所述流傳輸，直到網(wǎng)絡(luò)條件變?yōu)檎橹?，以確保持續(xù)流傳輸所述媒體數(shù)據(jù)以便在接收節(jié)點(diǎn)處回放。

在另一方面中，當(dāng)緩沖器處于安全水平時(shí)，所述方法包括：

-識(shí)別存儲(chǔ)在數(shù)據(jù)緩沖器中的具有低視頻比特率的先前流傳輸?shù)亩位蚓彌_器隊(duì)列中的部分GOP；

-識(shí)別接收節(jié)點(diǎn)處的數(shù)據(jù)緩沖器中的剩余數(shù)據(jù)的剩余回放時(shí)間；

-如果剩余回放時(shí)間大于10秒，則識(shí)別從所述發(fā)送節(jié)點(diǎn)流傳輸媒體數(shù)據(jù)的當(dāng)前速率；

-如果當(dāng)前流傳輸?shù)乃俾蚀笥诮邮展?jié)點(diǎn)所支持的平均速率，則所述方法還包括：請(qǐng)求發(fā)送節(jié)點(diǎn)重新發(fā)送具有低視頻比特率的現(xiàn)有幀或具有更高視頻比特率的部分GOP。

在另一方面中，本發(fā)明提供了一種用于通過(guò)通信網(wǎng)絡(luò)從發(fā)送節(jié)點(diǎn)向接收節(jié)點(diǎn)發(fā)送媒體數(shù)據(jù)的數(shù)據(jù)流控制方法，所述接收節(jié)點(diǎn)能夠播放所述媒體數(shù)據(jù)，所述方法包括：

響應(yīng)于所述接收節(jié)點(diǎn)對(duì)媒體數(shù)據(jù)的請(qǐng)求，識(shí)別多個(gè)中間數(shù)據(jù)提供者節(jié)點(diǎn)，每個(gè)中間數(shù)據(jù)提供者節(jié)點(diǎn)存儲(chǔ)所請(qǐng)求的媒體數(shù)據(jù)的本地副本；

-如果被識(shí)別為所述接收節(jié)點(diǎn)的鄰居的數(shù)據(jù)提供者節(jié)點(diǎn)是所識(shí)別的中間節(jié)點(diǎn)之一，則從該鄰居數(shù)據(jù)提供者節(jié)點(diǎn)獲得媒體數(shù)據(jù)的副本，所述鄰居節(jié)點(diǎn)是所述接收節(jié)點(diǎn)的對(duì)等節(jié)點(diǎn)；

-如果沒(méi)有數(shù)據(jù)提供者被識(shí)別為所述接收節(jié)點(diǎn)的鄰居，則從所述發(fā)送節(jié)點(diǎn)流傳輸所請(qǐng)求的媒體數(shù)據(jù)。在另一方面中，本發(fā)明提供一種用于通過(guò)通信網(wǎng)絡(luò)從發(fā)送節(jié)點(diǎn)向接收節(jié)點(diǎn)發(fā)送媒體數(shù)據(jù)的數(shù)據(jù)流控制方法，所述接收節(jié)點(diǎn)能夠播放所述媒體數(shù)據(jù)，所述方法包括：響應(yīng)于所述接收節(jié)點(diǎn)對(duì)媒體數(shù)據(jù)的請(qǐng)求，在定義的時(shí)間段以當(dāng)前可用比特率從所述發(fā)送節(jié)點(diǎn)流傳輸所述媒體數(shù)據(jù)，以檢測(cè)網(wǎng)絡(luò)帶寬；

-如果所述帶寬能夠支持比當(dāng)前速率更高的視頻比特率，則對(duì)網(wǎng)絡(luò)進(jìn)行比較以切換為所述更高的視頻比特率以用于連續(xù)的流傳輸。

在另一方面中，本發(fā)明提供了一種用于通過(guò)通信網(wǎng)絡(luò)從發(fā)送節(jié)點(diǎn)向接收節(jié)點(diǎn)發(fā)送媒體數(shù)據(jù)的數(shù)據(jù)流控制方法，所述接收節(jié)點(diǎn)能夠播放所述媒體數(shù)據(jù)，所述方法包括：

響應(yīng)于所述接收節(jié)點(diǎn)對(duì)媒體數(shù)據(jù)的請(qǐng)求，在定義的時(shí)間段以當(dāng)前可用比特率從所述發(fā)送節(jié)點(diǎn)流傳輸所述媒體數(shù)據(jù)，以檢測(cè)網(wǎng)絡(luò)帶寬；

-在所述流傳輸之前，識(shí)別要被流傳輸?shù)母邉?dòng)態(tài)視頻數(shù)據(jù)的多個(gè)畫(huà)面組(GOP)并且檢查每個(gè)GOP的大小和平均比特率以及網(wǎng)絡(luò)條件；

-如果GOP的平均比特率比當(dāng)前流傳輸?shù)拿襟w的平均比特率小30％，則所述方法包括：將所述GOP識(shí)別為低動(dòng)態(tài)畫(huà)面GOP，并將當(dāng)前流傳輸比特率切換為更低比特率從而以當(dāng)前比特率流傳輸GOP；

-如果GOP的平均比特率比平均比特率大30％，則所述方法包括：將所述GOP識(shí)別為高動(dòng)態(tài)畫(huà)面GOP，并將當(dāng)前流傳輸比特率切換為最高可用比特率從而以最高比特率流傳輸GOP。

在另一方面中，所述發(fā)送節(jié)點(diǎn)是IPTV流傳輸服務(wù)器，并且所述接收節(jié)點(diǎn)是包括多媒體播放器的客戶端設(shè)備。在另一方面中，本發(fā)明提供了一種用于實(shí)現(xiàn)根據(jù)前述權(quán)利要求中任一項(xiàng)所述的方法的系統(tǒng)，包括能夠經(jīng)由通信網(wǎng)絡(luò)進(jìn)行通信的發(fā)送節(jié)點(diǎn)和接收節(jié)點(diǎn)，所述發(fā)送節(jié)點(diǎn)具有能夠流傳輸存儲(chǔ)在所述發(fā)送節(jié)點(diǎn)的存儲(chǔ)裝置中的多媒體數(shù)據(jù)的流傳輸模塊，并且所述接收節(jié)點(diǎn)能夠請(qǐng)求從所述發(fā)送節(jié)點(diǎn)流傳輸多媒體數(shù)據(jù)以在所述接收節(jié)點(diǎn)包括的多媒體播放器上回放。

附圖說(shuō)明

圖1和圖2分別示出了TCP和UDP的幀結(jié)構(gòu)。

圖3示出了描繪根據(jù)第一實(shí)施例的數(shù)據(jù)流控制方法的指數(shù)加速模式的流程圖。

圖4示出了描繪根據(jù)第一實(shí)施例的數(shù)據(jù)流控制方法的指數(shù)回退模式的流程圖。

圖5示出了描繪根據(jù)第一實(shí)施例的數(shù)據(jù)流控制方法的線性涓退(trickle off)模式的流程圖。

圖6示出了根據(jù)第二實(shí)施例的數(shù)據(jù)流控制方法的數(shù)據(jù)共享模式的比特率選擇方法。

圖7示出了根據(jù)第三實(shí)施例的數(shù)據(jù)流控制方法的高質(zhì)量視頻數(shù)據(jù)回放的自適應(yīng)比特率選擇方法。

圖8示出了根據(jù)第三實(shí)施例的數(shù)據(jù)流控制方法的基于分辨率的比特率選擇方法。

圖9示出了描繪根據(jù)第三實(shí)施例的數(shù)據(jù)流控制方法的選擇性幀丟棄的方法的流程圖。

圖10a和10b分別示出了描繪具有和不具有圖9的選擇性幀丟棄的觀看體驗(yàn)的圖表。

圖11示出了描繪根據(jù)第三實(shí)施例的數(shù)據(jù)流控制方法的用于對(duì)高動(dòng)態(tài)視頻幀進(jìn)行帶寬分配的方法的流程圖。

圖12示出了描繪根據(jù)第三實(shí)施例的數(shù)據(jù)流控制方法的緩沖器修復(fù)模式的流程圖。

圖13示出了描繪第一、第二和第三實(shí)施例的模式之間的交互的流程圖。

圖14示出了描繪根據(jù)本發(fā)明的自適應(yīng)地啟用或禁用Nagle算法的方法的流程圖。

圖15a和15b分別示出了描繪使用和不使用圖14的方法的性能測(cè)試結(jié)果的表格和曲線圖。

具體實(shí)施方式

當(dāng)數(shù)據(jù)沿著網(wǎng)絡(luò)移動(dòng)時(shí)，各種屬性被添加到數(shù)據(jù)文件以創(chuàng)建幀。這一過(guò)程被稱為封裝。根據(jù)所使用的協(xié)議和拓?fù)?，存在不同的封裝方法。因此，數(shù)據(jù)幀的幀結(jié)構(gòu)不同。圖1示出了TCP幀結(jié)構(gòu)，圖2示出了UDP幀結(jié)構(gòu)。所示幀中的有效載荷字段包含實(shí)際數(shù)據(jù)。TCP具有比UDP更復(fù)雜的幀結(jié)構(gòu)。這主要是因?yàn)門(mén)CP是可靠的面向連接的協(xié)議，如背景部分中所解釋的。圖1所示的附加字段(當(dāng)與圖2所示的UDP幀相比時(shí))是確保由TCP提供的“受保障傳送”所需的字段。因此，當(dāng)與UDP比較時(shí)，TCP是一個(gè)慢得多的數(shù)據(jù)傳輸協(xié)議，并且具有大得多的開(kāi)銷。如果TCP與背景部分描述的Nagle算法的使用相結(jié)合時(shí)，尤其如此。

本發(fā)明提供了一種在互聯(lián)網(wǎng)協(xié)議組中使用的新的數(shù)據(jù)傳輸協(xié)議或數(shù)據(jù)流控制方法。具體地，本發(fā)明提供了用于媒體數(shù)據(jù)分組傳輸(優(yōu)選地，通信網(wǎng)絡(luò)上的視頻數(shù)據(jù)傳輸)的多個(gè)流機(jī)制或模式，其克服了TCP和UDP的缺點(diǎn)，并在最小網(wǎng)絡(luò)流量開(kāi)銷的情況下提供了速度、流控制和糾錯(cuò)機(jī)制。

在一個(gè)方面，本發(fā)明提供了一種對(duì)OSI模型的應(yīng)用層上的數(shù)據(jù)流管理進(jìn)行處理的數(shù)據(jù)流控制方法。盡管本發(fā)明涉及媒體數(shù)據(jù)，尤其涉及IPTV服務(wù)的視頻數(shù)據(jù)，但是本領(lǐng)域技術(shù)人員將容易理解，本發(fā)明可以用于管理可以在通信網(wǎng)絡(luò)(例如互聯(lián)網(wǎng))上傳輸?shù)娜魏晤愋偷臄?shù)據(jù)和信息的流。

根據(jù)本發(fā)明第一實(shí)施例的數(shù)據(jù)流控制方法基于監(jiān)視一個(gè)或多個(gè)發(fā)送節(jié)點(diǎn)或服務(wù)器側(cè)條件(例如，用于發(fā)送數(shù)據(jù)的IPTV提供商服務(wù)器)以及一個(gè)或多個(gè)接收節(jié)點(diǎn)或客戶端側(cè)條件(用于接收數(shù)據(jù)的客戶端設(shè)備，例如播放器或機(jī)頂盒)。本發(fā)明促進(jìn)發(fā)送服務(wù)器和接收客戶端之間的信息通信和數(shù)據(jù)交換，以便傳送每一端的本地網(wǎng)絡(luò)條件?；趶目蛻舳嗽O(shè)備和服務(wù)器設(shè)備兩者檢測(cè)到的條件，根據(jù)第一實(shí)施例的數(shù)據(jù)流控制方法能夠計(jì)算和預(yù)測(cè)網(wǎng)絡(luò)環(huán)境。

當(dāng)網(wǎng)絡(luò)條件被檢測(cè)到或被通知給服務(wù)器或客戶端時(shí)，根據(jù)本發(fā)明的流控制方法能夠應(yīng)用一種或多種數(shù)據(jù)傳輸模式或技術(shù)(這些模式在下文中詳細(xì)解釋)，以確?？梢栽跓o(wú)管理和/或波動(dòng)的網(wǎng)絡(luò)上流傳輸高質(zhì)量視頻數(shù)據(jù)。在另一方面，本發(fā)明的數(shù)據(jù)流控制方法能夠通過(guò)數(shù)據(jù)共享、本地緩存和數(shù)據(jù)再循環(huán)來(lái)消耗網(wǎng)絡(luò)中的未使用的帶寬(剩余或浪費(fèi)的帶寬)，以進(jìn)行更有效的數(shù)據(jù)傳輸。

在另一方面，本發(fā)明的數(shù)據(jù)流控制提供高視頻質(zhì)量傳送并且保持在任何網(wǎng)絡(luò)上的視頻回放的流暢性。

數(shù)據(jù)流控制方法或協(xié)議結(jié)合了通過(guò)HTTP(超文本傳輸協(xié)議)封裝的RTSP(實(shí)時(shí)流傳輸協(xié)議)的組合。在應(yīng)用層中處理根據(jù)本發(fā)明的數(shù)據(jù)流控制方法。該方法能夠?qū)崿F(xiàn)駐留在服務(wù)器側(cè)或客戶端終端或者這兩者上的一個(gè)或多個(gè)模塊。配備有用于實(shí)現(xiàn)這樣的流控制的模塊的客戶端和服務(wù)器節(jié)點(diǎn)一直共同協(xié)作，以預(yù)測(cè)網(wǎng)絡(luò)流、調(diào)整數(shù)據(jù)流、增強(qiáng)視頻質(zhì)量、通過(guò)各種網(wǎng)絡(luò)路由進(jìn)行導(dǎo)航，維持常規(guī)數(shù)據(jù)傳輸協(xié)議(如TCP和UDP)不能提供的良好IPTV用戶體驗(yàn)。

本申請(qǐng)的一些目標(biāo)是在快速響應(yīng)、流暢數(shù)據(jù)流和數(shù)據(jù)質(zhì)量之間進(jìn)行平衡。下面提供根據(jù)本發(fā)明的數(shù)據(jù)流控制方法的一些優(yōu)點(diǎn)的概述。針對(duì)單個(gè)傳輸實(shí)現(xiàn)所有這些優(yōu)點(diǎn)不是必要的，因?yàn)閷?duì)特定傳輸來(lái)說(shuō)一個(gè)效果可能比其他有利效果更重要。A.盡可能快地向終端用戶發(fā)送媒體數(shù)據(jù)，以確保用戶設(shè)備(即客戶端系統(tǒng))處的緩沖器保持滿載并保持流暢回放。

B.先于TCP檢測(cè)擁塞并立即(而不像TCP那樣逐漸)回退(減少或停止發(fā)送分組)，這將有助于快速緩解擁塞。C.在建立會(huì)話之前通過(guò)使用動(dòng)態(tài)多鏈路策略(多個(gè)網(wǎng)絡(luò)路徑和路由)來(lái)有效地使用帶寬。

D.檢測(cè)并區(qū)分物理網(wǎng)絡(luò)擁塞與常規(guī)網(wǎng)絡(luò)擁塞，并應(yīng)用適當(dāng)?shù)目刂颇Ｊ?，避免自我?jìng)爭(zhēng)。

E.支持基于網(wǎng)絡(luò)條件的自適應(yīng)比特率流傳輸。

F.通過(guò)充分利用網(wǎng)絡(luò)信道并優(yōu)先考慮高比特率視頻GOP(畫(huà)面組)來(lái)提供高視頻體驗(yàn)。

G.提供緩沖器修復(fù)，使得當(dāng)客戶端緩沖器處于健康階段時(shí)，數(shù)據(jù)流控制方法被配置為重新評(píng)估緩沖器上的視頻比特率，并用較高的視頻質(zhì)量替換較低/較差質(zhì)量的段。這種修復(fù)僅當(dāng)網(wǎng)絡(luò)條件允許時(shí)才安全有效地進(jìn)行。

H.流控制方法被配置為通過(guò)在本地存儲(chǔ)設(shè)備上緩存熱門(mén)數(shù)據(jù)來(lái)再循環(huán)數(shù)據(jù)以防止來(lái)自服務(wù)器的重復(fù)流傳輸，并且還被配置為與對(duì)端共享本地緩存的數(shù)據(jù)。

I.當(dāng)條件允許時(shí)切換到P2P類型的通信。這主要用于VOD和電視重播場(chǎng)景

J.與其他類型的服務(wù)數(shù)據(jù)流(例如VoIP)和平共存，即沒(méi)有分組沖突。

根據(jù)本發(fā)明的應(yīng)用層數(shù)據(jù)流控制方法包括數(shù)據(jù)流控制方法和視頻質(zhì)量控制方法。

根據(jù)本發(fā)明的第一實(shí)施例，基于網(wǎng)絡(luò)條件和緩沖器條件來(lái)應(yīng)用的數(shù)據(jù)流控制方法或模式是：

A.指數(shù)加速(以速率遞增的方式發(fā)送數(shù)據(jù))

B.指數(shù)回退(將數(shù)據(jù)發(fā)送速率降低至接近零)

C.線性或流暢的涓流模式(發(fā)送數(shù)據(jù)速率等于視頻播放速率)

D.動(dòng)態(tài)的多個(gè)鏈接(在多個(gè)TCP連接中發(fā)送數(shù)據(jù))

E.考慮網(wǎng)絡(luò)和播放器緩沖器條件的自適應(yīng)流傳輸。根據(jù)本發(fā)明的第二實(shí)施例，用于實(shí)現(xiàn)數(shù)據(jù)共享以改善整體網(wǎng)絡(luò)和流傳輸效率并減少網(wǎng)絡(luò)資源的數(shù)據(jù)流控制方法是：

A.數(shù)據(jù)再循環(huán)(盡可能地保留和重用緩存的數(shù)據(jù))

B.混合型點(diǎn)對(duì)點(diǎn)(P2P)流傳輸(在條件允許時(shí)以受控方式接收并與其他客戶端共享數(shù)據(jù))

根據(jù)本發(fā)明的第三實(shí)施例，視頻質(zhì)量流控制方法是：

A.基于質(zhì)量貪婪條件的自適應(yīng)比特率流傳輸(確保以最高優(yōu)先級(jí)發(fā)送高質(zhì)量視頻數(shù)據(jù))。

B.智能開(kāi)始視頻比特率選擇(基于設(shè)備分辨率動(dòng)態(tài)選擇視頻最佳比特率，以改善用戶體驗(yàn))

C.視頻幀選擇性丟棄或幀忽略(在網(wǎng)絡(luò)條件改善前，通過(guò)忽略非I幀來(lái)維持視頻連續(xù)性)

D.動(dòng)態(tài)畫(huà)面優(yōu)先(對(duì)高動(dòng)態(tài)視頻幀的帶寬分配)

E.低視頻質(zhì)量緩沖器修復(fù)/用較高比特率替換差的視頻(如果出現(xiàn)正確的條件，則回到緩沖器用較高視頻質(zhì)量替換在先的還未播放的低質(zhì)量視頻(GOP))

5.1第一實(shí)施例

基于網(wǎng)絡(luò)條件以及客戶端或接收節(jié)點(diǎn)的緩沖器條件的數(shù)據(jù)流控制機(jī)制。

雖然TCP對(duì)視頻流傳輸來(lái)說(shuō)是夠用且可靠的，但是良好的IPTV體驗(yàn)是指與傳統(tǒng)數(shù)字有線電視、衛(wèi)星電視和地面電視差不多的體驗(yàn)。期望達(dá)到良好的視頻質(zhì)量、快速的頻道變更、即時(shí)的視頻獲取以及連續(xù)的流傳輸。為了實(shí)現(xiàn)這一水平，本發(fā)明提出了多個(gè)數(shù)據(jù)流控制機(jī)制，其可以與TCP、公共網(wǎng)絡(luò)一起工作并在擁塞的網(wǎng)絡(luò)段周圍進(jìn)行導(dǎo)航。以下機(jī)制或數(shù)據(jù)流控制模式不同于傳統(tǒng)TCP或UDP所應(yīng)用的技術(shù)，因?yàn)樗鼈兓趶陌l(fā)送節(jié)點(diǎn)流傳輸數(shù)據(jù)時(shí)的網(wǎng)絡(luò)條件與播放器或客戶端緩沖器的條件的協(xié)作。以前和現(xiàn)有的系統(tǒng)沒(méi)有這種協(xié)作，并且依賴于報(bào)告網(wǎng)絡(luò)中的異常。在本發(fā)明中，可以從服務(wù)器(發(fā)送節(jié)點(diǎn)，其不必僅是數(shù)據(jù)的唯一或原始源，還可以是存儲(chǔ)數(shù)據(jù)文件的中間節(jié)點(diǎn))、客戶端或端用戶接收節(jié)點(diǎn)/播放器、或者這兩個(gè)節(jié)點(diǎn)(通過(guò)利用它們之間的信息交換)獲得網(wǎng)絡(luò)條件和緩沖器條件。

5.1.1指數(shù)加速(盡可能快地前推)：

圖3示出了第一實(shí)施例的指數(shù)加速數(shù)據(jù)流控制機(jī)制。以下說(shuō)明該機(jī)制的優(yōu)選步驟：

3a.將初始發(fā)送速率init_rate設(shè)置為1.6xVOD(視頻點(diǎn)播)文件的“實(shí)時(shí)回放”比特率(表示為rt_bitrate)。

3b.將最大推送速率max_rate設(shè)置為0.625x(1/1.6x)從播放器報(bào)告的下行鏈路帶寬。

3c.如果max_rate小于init_rate，則流控制方法將max_rate設(shè)置為init_rate。

3d.嘗試以init_rate前推媒體數(shù)據(jù)。如果網(wǎng)絡(luò)正常(無(wú)擁塞)，則嘗試以速度1.6x當(dāng)前速度(即1.6*init_rate，其等于1.6*1.6*rt_bitrate)進(jìn)行推送。

3e.以指數(shù)方式繼續(xù)提高推送速度，直到播放器側(cè)的高速緩存緩沖器為80％、達(dá)到max_rate、或網(wǎng)絡(luò)變得擁塞為止。

上述步驟3a-3e闡述了指數(shù)加速數(shù)據(jù)流控制模式的主要特征。以下步驟說(shuō)明了基于附加的異常緩沖器條件和網(wǎng)絡(luò)條件而采用的機(jī)制，并且闡述了通過(guò)與第一實(shí)施例的其他數(shù)據(jù)流控制機(jī)制交互來(lái)實(shí)現(xiàn)在指數(shù)加速模式之后的有效數(shù)據(jù)流的過(guò)程。3f.如果緩存水平大于95％，則立即進(jìn)入指數(shù)回退過(guò)程(這將在下面的5.1.2中說(shuō)明)。

3g.否則，如果高速緩存緩沖器大于80％，則進(jìn)入線性涓流模式(參見(jiàn)下面的5.1.3)，從而以1x rt_bitrate前推媒體數(shù)據(jù)。

3h.如果達(dá)到max_rate，則保持該速率，直到高速緩存緩沖器為80％或網(wǎng)絡(luò)變得擁塞為止。3i.當(dāng)網(wǎng)絡(luò)變得擁塞時(shí)，如果高速緩存緩沖器達(dá)到臨界水平，則數(shù)據(jù)流控制方法前進(jìn)到動(dòng)態(tài)多鏈路處理(參見(jiàn)5.1.4)。否則，推送(流傳輸)速度可以降低到當(dāng)前速度的0.625x(1/1.6x)。如果普遍存在網(wǎng)絡(luò)擁塞，則推送速度可以降低到當(dāng)前速度的0.625x(1/1.6x)，但不小于1x rt_bitrate。當(dāng)在播放器側(cè)(即客戶端設(shè)備)上進(jìn)行緩沖時(shí)，可以發(fā)起多路徑/并發(fā)多路由處理(參見(jiàn)5.1.5項(xiàng))。

3j.當(dāng)網(wǎng)絡(luò)從擁塞中恢復(fù)時(shí)，數(shù)據(jù)流控制機(jī)制試圖以最近的推送速度發(fā)送，然后前進(jìn)到重復(fù)上述步驟3e-3j。

3k.在流控制方法從指數(shù)回退返回(參見(jiàn)5.1.2)之后，可以重復(fù)上述步驟3d-3j。

5.1.2指數(shù)回退

第一實(shí)施例的流控制方法的該回退機(jī)制可以在檢測(cè)到與預(yù)設(shè)回退標(biāo)準(zhǔn)相匹配的網(wǎng)絡(luò)或播放器緩沖器的擁塞/條件時(shí)觸發(fā)。緩解IPTV分組數(shù)據(jù)傳輸?shù)膿砣淖罴呀鉀Q方案是使用一個(gè)或多個(gè)不同的路徑進(jìn)行回退或?qū)Ш?，以避免加?contribute)現(xiàn)有的網(wǎng)絡(luò)擁塞和業(yè)務(wù)。當(dāng)檢測(cè)到擁塞時(shí)，觸發(fā)根據(jù)本發(fā)明的數(shù)據(jù)流控制方法的指數(shù)回退模式或機(jī)制(也稱為友好回退模式)。該模式將暫停所有其他流控制模式，并將數(shù)據(jù)發(fā)送速率降至接近零或“0.05x rt_birate”，以為其他應(yīng)用產(chǎn)生帶寬。圖4中示出了第一實(shí)施例的指數(shù)回退數(shù)據(jù)流控制機(jī)制。以下說(shuō)明該機(jī)制的優(yōu)選步驟：

4a.在回放會(huì)話期間，具有流傳輸應(yīng)用或模塊的服務(wù)器或系統(tǒng)將嘗試根據(jù)第5.1.1項(xiàng)所述的“指數(shù)加速”機(jī)制來(lái)前推媒體數(shù)據(jù)。

4b.在回放會(huì)話期間，客戶端設(shè)備或播放器將周期性地向流傳輸應(yīng)用報(bào)告其緩存/緩沖的媒體數(shù)據(jù)大小和“實(shí)時(shí)回放”持續(xù)時(shí)間，即在緩沖器中剩余的播放時(shí)間量。根據(jù)所使用的RTP/RTCP(實(shí)時(shí)控制協(xié)議)計(jì)算，每隔2至5秒發(fā)送一次更新。服務(wù)器或流傳輸應(yīng)用可以記錄此信息供以后使用。4c.如果通過(guò)指數(shù)加速機(jī)制在網(wǎng)絡(luò)路徑中檢測(cè)到連續(xù)的網(wǎng)絡(luò)擁塞，則流傳輸服務(wù)器將在一段時(shí)間(例如，等于步驟4b中播放器報(bào)告的時(shí)間(實(shí)時(shí)回放)的1/3)內(nèi)停止向TCP層發(fā)送數(shù)據(jù)。提供以下步驟以示出該機(jī)制與本申請(qǐng)的其他機(jī)制和數(shù)據(jù)流控制模式組合的工作。

4d.在步驟c的延遲時(shí)間到期之后，流傳輸應(yīng)用或模塊將嘗試按照指數(shù)加速機(jī)制(上面的5.1.1)記錄的最近推送速度來(lái)推送數(shù)據(jù)，以補(bǔ)償早先在步驟4c中的延遲損失。

4e.如果步驟d由于網(wǎng)絡(luò)吞吐量、擁塞而失敗，或者如果播放器未在正常時(shí)間軸內(nèi)接收到所有分組，則流傳輸應(yīng)用將停止發(fā)送，并基于從播放器報(bào)告的新的“實(shí)時(shí)回放”重新編譯新的計(jì)算。該過(guò)程將持續(xù)以產(chǎn)生或釋放網(wǎng)絡(luò)帶寬，直到“實(shí)時(shí)回放”小于15秒(或定義的臨界水平)或者如果網(wǎng)絡(luò)條件變得正常，即在預(yù)測(cè)或預(yù)期時(shí)間內(nèi)以及預(yù)期的QoS水平上沒(méi)有擁塞并且傳輸發(fā)生。4f.如果由于我們的回退過(guò)程，在播放器中留下的高速緩存數(shù)據(jù)小于15秒(臨界水平)，則可以應(yīng)用5.1.4中闡述的“動(dòng)態(tài)多鏈路”機(jī)制，從而以快速有效的方式來(lái)補(bǔ)償早期的延遲/丟失。4g.如果網(wǎng)絡(luò)恢復(fù)到正常條件，則可以退出指數(shù)回退模式，并且可以恢復(fù)指數(shù)加速模式5.1.1。

5.1.3線性涓流模式

當(dāng)播放器側(cè)或客戶端終端上的高速緩存緩沖器處于安全水平(緩沖器的80％或更多)時(shí)，觸發(fā)或應(yīng)用根據(jù)第一實(shí)施例的數(shù)據(jù)流控制方法的線性或流暢涓流模式。服務(wù)器節(jié)點(diǎn)處的IPTV流傳輸模塊或應(yīng)用將在安全水平進(jìn)入線性涓流模式。在該機(jī)制中，流傳輸應(yīng)用將以1x rt_bitrate的速度發(fā)送媒體數(shù)據(jù)，該速度等于當(dāng)使用來(lái)自緩沖器的數(shù)據(jù)時(shí)播放器側(cè)的高速緩存緩沖器的消耗速度。這確保緩沖器可以保持在安全水平(即80％)以確保流暢的視頻數(shù)據(jù)回放。

圖5中示出了描繪線性涓流模式的流程圖。在該圖中，數(shù)據(jù)流最初被示為處于5a的指數(shù)加速模式。在步驟5b，確定數(shù)據(jù)高速緩存水平是否大于95％，如是，則在步驟5c中發(fā)起指數(shù)回退模式(參見(jiàn)5.1.2)。如果在步驟5d確定高速緩存水平為80％，則在5f發(fā)起線性涓流模式。步驟5d的該確定也可以在步驟5e的檢查網(wǎng)絡(luò)條件之后進(jìn)行，如圖5所示。

5.1.4動(dòng)態(tài)多鏈路機(jī)制

傳統(tǒng)和現(xiàn)有的數(shù)據(jù)傳輸被建立為一個(gè)TCP鏈路上的位于一個(gè)客戶端和一個(gè)服務(wù)器之間的單播會(huì)話。當(dāng)客戶端和服務(wù)器之間的這條路徑被阻塞或擁塞時(shí)，常規(guī)技術(shù)將開(kāi)始緩沖數(shù)據(jù)或完全放棄。此外，即使經(jīng)由多個(gè)TCP鏈路從多個(gè)源獲取數(shù)據(jù)，也會(huì)遇到以下問(wèn)題：

A.在一個(gè)數(shù)據(jù)無(wú)序到達(dá)并且必須被丟棄的情況下進(jìn)行分組重新排序。此效果由于所使用的TCP鏈接的總數(shù)而成倍地增加，問(wèn)題變得更糟。B.分組被延遲并且在多個(gè)源之間以錯(cuò)誤的順序排序

C.在播放器側(cè)重裝配之后，數(shù)據(jù)可能不連續(xù)。

D.防止數(shù)據(jù)傳輸?shù)闹貜?fù)并重組經(jīng)由多個(gè)源獲取的分組。

在第一實(shí)施例的數(shù)據(jù)流控制方法中使用動(dòng)態(tài)多鏈路(DML)作為連接管理機(jī)制用于基于網(wǎng)絡(luò)條件和客戶環(huán)境中的條件來(lái)建立和維護(hù)服務(wù)器側(cè)系統(tǒng)與客戶端播放器或系統(tǒng)之間的多個(gè)連接。DML機(jī)制動(dòng)態(tài)地建立服務(wù)器和客戶端之間的多個(gè)TCP連接，以實(shí)現(xiàn)更高的網(wǎng)絡(luò)吞吐量。同時(shí)，該機(jī)制還利用這些多個(gè)網(wǎng)絡(luò)路徑來(lái)幫助緩解擁塞，并允許播放器在不中斷的情況下持續(xù)保持視頻會(huì)話。當(dāng)迫切需要數(shù)據(jù)以防止IPTV的視頻緩沖效果時(shí)，這是有用的。該DML機(jī)制基于客戶端側(cè)和服務(wù)器之間的信息交換和協(xié)作工作，使得當(dāng)迫切需要數(shù)據(jù)時(shí)，模塊(其可以是專用DML模塊或與其他設(shè)備集成)能夠計(jì)算所需的總連接，并請(qǐng)求服務(wù)器側(cè)接受新的連接。服務(wù)器側(cè)根據(jù)其他因素和網(wǎng)絡(luò)條件確定其將使用多少連接。

在流傳輸會(huì)話期間，服務(wù)器中的流傳輸應(yīng)用將嘗試以平均方式(即均勻地)在所有可用TCP鏈路上發(fā)送數(shù)據(jù)。當(dāng)一個(gè)數(shù)據(jù)段由于網(wǎng)絡(luò)擁塞而不能在一個(gè)鏈路上發(fā)送時(shí)，服務(wù)器將嘗試下一個(gè)可用鏈路。這種非選擇性發(fā)送策略將增加服務(wù)器和客戶端之間的整體吞吐量。當(dāng)我們需要與其他交叉業(yè)務(wù)競(jìng)爭(zhēng)帶寬資源以保持流暢回放時(shí)，它也可以用作緊急緩沖救援武器。

這種動(dòng)態(tài)發(fā)送策略將增加服務(wù)器和客戶端之間的整體吞吐量。經(jīng)由多個(gè)鏈路到達(dá)客戶端側(cè)的媒體分組通常被打亂并且無(wú)序地到達(dá)。因此，在客戶端處需要進(jìn)行重新排序，優(yōu)選地，這可以基于位于RTP報(bào)頭中的順序號(hào)。優(yōu)選地，客戶端配備有模塊或應(yīng)用，該模塊或應(yīng)用用于對(duì)從不同鏈路無(wú)序到達(dá)的RTP分組進(jìn)行重新排序并且給無(wú)序分組賦予優(yōu)先級(jí)，以確保緩沖器被整齊地布置用于所接收的數(shù)據(jù)的連續(xù)回放。必須在IPTV服務(wù)提供商和監(jiān)管部門(mén)的管理和支配下應(yīng)用多個(gè)路徑或鏈路的使用，使得其對(duì)于現(xiàn)今的網(wǎng)絡(luò)而言是公平和友好的策略，尤其是在許多媒體服務(wù)提供商和其他類型的數(shù)據(jù)傳輸在相同的信道上競(jìng)爭(zhēng)帶寬的情況下。第一實(shí)施例的DML機(jī)制的公平使用可以產(chǎn)生許多益處，例如：

1.與客戶端/接收機(jī)設(shè)備建立多個(gè)鏈路，以測(cè)量到流傳輸視頻數(shù)據(jù)的單個(gè)服務(wù)器的可能備用網(wǎng)絡(luò)路徑。在正常條件下(即在正常業(yè)務(wù)條件的情況下)使用一個(gè)主TCP鏈路(即主鏈路)。如果網(wǎng)絡(luò)吞吐量在流傳輸會(huì)話期間降低，則DML機(jī)制被配置為通過(guò)在會(huì)話開(kāi)始時(shí)已建立的其他TCP鏈路(從鏈路)發(fā)送業(yè)務(wù)。因此，在基于網(wǎng)絡(luò)和客戶端條件進(jìn)行數(shù)據(jù)傳輸之前，建立了多個(gè)鏈路，并且當(dāng)業(yè)務(wù)沿著網(wǎng)絡(luò)信道改變時(shí)，以動(dòng)態(tài)方式使用這些鏈路。

2.如果在使用多個(gè)數(shù)據(jù)鏈路的情況下數(shù)據(jù)流條件繼續(xù)惡化，這表示以下之一：A、網(wǎng)絡(luò)擁塞由其他業(yè)務(wù)引起，或者B、網(wǎng)絡(luò)擁塞由物理網(wǎng)絡(luò)路徑引起。播放器/客戶端側(cè)將無(wú)法確定原因是A還是B，并且即使確定了，也將無(wú)法對(duì)該情況做出反應(yīng)。因此，通過(guò)使用DML機(jī)制，客戶端可以與服務(wù)器協(xié)作以試圖使用DML來(lái)實(shí)現(xiàn)更好的吞吐量。如果數(shù)據(jù)流條件沒(méi)有表現(xiàn)出改善，則可以假定發(fā)生了條件B，并且數(shù)據(jù)流方法可以選擇切換到用于處理異常條件的不同機(jī)制或模式。例如，流控制可以應(yīng)用如第5.1.5項(xiàng)所述的自適應(yīng)流傳輸策略。第一實(shí)施例的DML機(jī)制允許充分利用帶寬資源，并且還公平地處理其他網(wǎng)絡(luò)流量。

3.在預(yù)定條件下動(dòng)態(tài)地調(diào)整DML機(jī)制的使用或不使用。例如，在上述條件“A”的情況下，本發(fā)明的數(shù)據(jù)流控制方法的可能反應(yīng)是使用更多的鏈路，即，使用DML機(jī)制，以實(shí)現(xiàn)額外的TCP資源以快速填充IPTV播放器緩沖器并退出網(wǎng)絡(luò)擁擠，因?yàn)橥ㄟ^(guò)不加入現(xiàn)有業(yè)務(wù)可以緩解擁塞。

這種機(jī)制基于客戶端和服務(wù)器二者之間的協(xié)作。在優(yōu)選模型中，基于網(wǎng)絡(luò)和客戶端條件，客戶端負(fù)責(zé)建立新的鏈路，之后，服務(wù)器可以在一些或所有可用TCP鏈路上發(fā)送媒體數(shù)據(jù)。

以上討論涉及一個(gè)服務(wù)器和一個(gè)客戶端之間的鏈路。以下描述與能夠流傳輸所需視頻數(shù)據(jù)文件的一個(gè)以上服務(wù)器一起使用的動(dòng)態(tài)多鏈路機(jī)制的另一方面。當(dāng)一個(gè)或多個(gè)用戶(向客戶端播放器或設(shè)備，例如，連接到顯示設(shè)備(即電視屏幕)的機(jī)頂盒)請(qǐng)求視頻數(shù)據(jù)流時(shí)，這些請(qǐng)求被路由到最健康的流傳輸服務(wù)器，即最適合傳輸所請(qǐng)求的文件的多個(gè)服務(wù)器?；谥T如服務(wù)器負(fù)載和訪問(wèn)這些數(shù)據(jù)的便利性等條件來(lái)評(píng)估服務(wù)器健康。一旦視頻從服務(wù)器的流傳輸應(yīng)用開(kāi)始流傳輸，DML機(jī)制就被用于建立客戶端到特定數(shù)量的流傳輸服務(wù)器的所有可能的路由路徑。當(dāng)滿足某些條件時(shí)，根據(jù)本發(fā)明的數(shù)據(jù)流控制方法基于上述DML機(jī)制來(lái)應(yīng)用多個(gè)并發(fā)路由機(jī)制。這些條件的示例如下：

1.當(dāng)即使已應(yīng)用DML策略后播放器還遭受緩沖并且仍然不能獲得更多數(shù)據(jù)時(shí)，預(yù)測(cè)該問(wèn)題是路由擁塞問(wèn)題，并且本發(fā)明的數(shù)據(jù)流控制方法將在改變流控制模式前檢查可以更有效地向播放器發(fā)送的數(shù)據(jù)的其他源。a.播放器(客戶端)將基于可使用的多個(gè)可用服務(wù)器的信息來(lái)建立到備選的建議流傳輸服務(wù)器的另一連接。該信息可以在索引文件或數(shù)據(jù)結(jié)構(gòu)中可用，并且包括基于每個(gè)服務(wù)器的地理位置、可用性和可用容量的信息。b.如果播放器可以從這個(gè)備選服務(wù)器獲得流暢回放，則不需要識(shí)別其他服務(wù)器。

c.否則，播放器將嘗試識(shí)別另外的流傳輸服務(wù)器，并且將繼續(xù)向保存相同數(shù)據(jù)的所有識(shí)別的流傳輸服務(wù)器請(qǐng)求并發(fā)數(shù)據(jù)傳輸。

d.播放器將繼續(xù)監(jiān)視來(lái)自所有活動(dòng)源的數(shù)據(jù)有效性，并且如果一個(gè)特定源不按要求執(zhí)行，則它將停止來(lái)自該服務(wù)器的連接，并請(qǐng)求其他并發(fā)流傳輸服務(wù)器改變數(shù)據(jù)流模式。

e.當(dāng)?shù)竭_(dá)播放器的所有路徑上的網(wǎng)絡(luò)都無(wú)效時(shí)，則在所有路由上使用動(dòng)態(tài)鏈接機(jī)制以確保緩沖器達(dá)到適用于上面5.1.3中說(shuō)明的流暢涓流模式的水平。

2.當(dāng)數(shù)據(jù)達(dá)到40％緩沖水平并且具有高視頻質(zhì)量時(shí)，本發(fā)明的流控制方法可以應(yīng)用混合型服務(wù)器到客戶端和客戶端到客戶端數(shù)據(jù)傳輸方法。在涉及數(shù)據(jù)共享技術(shù)的第二實(shí)施例中對(duì)此進(jìn)行更詳細(xì)的說(shuō)明。將選擇具有更快響應(yīng)時(shí)間和更好網(wǎng)絡(luò)路徑的數(shù)據(jù)提供者(服務(wù)器或其他客戶端設(shè)備)作為數(shù)據(jù)分發(fā)的路由。

利用本發(fā)明的數(shù)據(jù)流控制機(jī)制的DML機(jī)制的多個(gè)并發(fā)路由機(jī)制為本發(fā)明的流控制方法提供了經(jīng)由多個(gè)業(yè)務(wù)路由進(jìn)行導(dǎo)航以及基于檢測(cè)到的網(wǎng)絡(luò)和客戶端緩沖器條件來(lái)動(dòng)態(tài)避免擁塞段的能力。

5.1.5自適應(yīng)流傳輸

自適應(yīng)比特率流傳輸是在計(jì)算機(jī)網(wǎng)絡(luò)上流傳輸多媒體所使用的技術(shù)。它通過(guò)實(shí)時(shí)檢測(cè)用戶的帶寬和CPU能力并相應(yīng)地調(diào)整視頻流的質(zhì)量來(lái)工作。它需要使用能夠以多個(gè)比特率對(duì)單個(gè)源視頻進(jìn)行編碼的編碼器。播放器客戶端根據(jù)可用資源在流傳輸?shù)牟煌幋a之間切換。因此，可以為IPTV應(yīng)用獲得極少的緩沖、快速啟動(dòng)時(shí)間以及高端連接和低端連接二者的良好體驗(yàn)。自適應(yīng)流傳輸如今用于HLS或DASH視頻流傳輸服務(wù)。這些標(biāo)準(zhǔn)漸進(jìn)式下載和切換流是基于網(wǎng)絡(luò)流實(shí)時(shí)決定的。然而，現(xiàn)有的自適應(yīng)流傳輸技術(shù)不考慮客戶端播放器能力、緩沖器條件或在客戶端處回放的視頻質(zhì)量。

本發(fā)明的數(shù)據(jù)流控制方法提出了一種自適應(yīng)流傳輸機(jī)制，其基于網(wǎng)絡(luò)條件同時(shí)還考慮最高視頻傳送來(lái)切換視頻流。這通過(guò)服務(wù)器側(cè)和客戶端之間的協(xié)作以接收與客戶端側(cè)(播放器)條件相關(guān)的信息(例如緩沖水平、回放剩余時(shí)間和當(dāng)前發(fā)送速度)來(lái)實(shí)現(xiàn)。這實(shí)現(xiàn)了更好的“流切換”決定。因此，通過(guò)考慮網(wǎng)絡(luò)條件以及緩沖器條件，根據(jù)本發(fā)明的第一實(shí)施例的自適應(yīng)流傳輸可以傳送高視頻質(zhì)量輸出。

5.2.第二實(shí)施例

根據(jù)本申請(qǐng)第二實(shí)施例的數(shù)據(jù)流控制方法涉及用于數(shù)據(jù)共享、本地?cái)?shù)據(jù)高速緩存和重用該數(shù)據(jù)以減少網(wǎng)絡(luò)開(kāi)銷的模式和機(jī)制。以下對(duì)其進(jìn)行詳細(xì)說(shuō)明：

5.2.1數(shù)據(jù)再循環(huán)模式

用戶有時(shí)向一個(gè)或多個(gè)服務(wù)器多次請(qǐng)求相同的媒體數(shù)據(jù)。例如，用戶向流服務(wù)器請(qǐng)求他們喜歡的歌曲或他們經(jīng)常觀看很多次的喜歡的視頻。這種行為導(dǎo)致不必要的帶寬使用，并影響整個(gè)互聯(lián)網(wǎng)生態(tài)系統(tǒng)。一些專家預(yù)測(cè)，這種不必要的重復(fù)消耗占每天消耗的帶寬的30％。當(dāng)一個(gè)家庭或全家購(gòu)買新發(fā)行的電影但不能花時(shí)間一起觀看時(shí)，也會(huì)出現(xiàn)同樣的情況。這導(dǎo)致多個(gè)觀看和流傳輸同一電影，并且消耗不必要的帶寬和其他網(wǎng)絡(luò)資源。

第二實(shí)施例中的本發(fā)明的數(shù)據(jù)流控制機(jī)制通過(guò)基于客戶端設(shè)備中的預(yù)設(shè)存儲(chǔ)空間在客戶端/本地設(shè)備處自動(dòng)緩存近期觀看的熱門(mén)內(nèi)容來(lái)克服這一點(diǎn)?？梢曰谒鼈兊臒衢T(mén)分?jǐn)?shù)來(lái)緩存或從存儲(chǔ)設(shè)備中移除內(nèi)容。通過(guò)這樣做，熱門(mén)觀看內(nèi)容駐留在設(shè)備上，并且即使設(shè)備未連接到互聯(lián)網(wǎng)也可以重看。這防止不必要的重傳以節(jié)省總能量。

第二實(shí)施例的流控制方法的數(shù)據(jù)再循環(huán)機(jī)制可用于視頻點(diǎn)播(VOD)或電視重放。為了實(shí)現(xiàn)這種模式，例如，在RAM緩沖器大小為20Megs且本地存儲(chǔ)預(yù)留為2GB(HDD)的客戶端處實(shí)現(xiàn)數(shù)據(jù)緩存策略模塊。數(shù)據(jù)再循環(huán)機(jī)制包括規(guī)則和策略，以指定傳送到客戶端設(shè)備的數(shù)據(jù)將被編寫(xiě)索引、組織和記錄以供將來(lái)使用。

圖6示出了描繪具有數(shù)據(jù)再循環(huán)使得在從服務(wù)器拉取數(shù)據(jù)之前查閱本地高速緩存的數(shù)據(jù)流控制機(jī)制的流程圖。在開(kāi)始回放會(huì)話之前，本發(fā)明的數(shù)據(jù)流控制方法首先檢查本地RAM和HDD存儲(chǔ)器處的內(nèi)容。如果本地有副本，則立即播放。在一些實(shí)例中，可能僅在本地緩存了部分熱門(mén)內(nèi)容。在這種情況下，數(shù)據(jù)再循環(huán)機(jī)制還被配置為在回放時(shí)請(qǐng)求流傳輸服務(wù)器開(kāi)始流傳輸視頻文件的任何缺失部分。將以相同的比特率水平請(qǐng)求數(shù)據(jù)的接續(xù)部分，并且在最前面的幾個(gè)畫(huà)面組GOP之后，針對(duì)會(huì)話的其余部分恢復(fù)流傳輸。該方法允許僅在必要時(shí)有效地利用帶寬，并且可以實(shí)現(xiàn)即時(shí)回放，這也提高了用戶體驗(yàn)。

5.2.2混合型P2P流傳輸

服務(wù)器或客戶端設(shè)備之間的點(diǎn)對(duì)點(diǎn)通信(通常稱為P2P)并非一個(gè)新概念，并且已經(jīng)在互聯(lián)網(wǎng)上的許多應(yīng)用中廣泛使用。然而，P2P策略不適用于IPTV應(yīng)用的高質(zhì)量視頻流傳輸。本發(fā)明的數(shù)據(jù)流控制方法提出了一種“混合型P2P”流傳輸機(jī)制，其作為客戶端到服務(wù)器以及客戶端到客戶端P2P的組合基礎(chǔ)來(lái)工作。在不影響流暢視頻回放的情況下，當(dāng)網(wǎng)絡(luò)與其他對(duì)等端安全地共享數(shù)據(jù)時(shí)，確定使用這些P2P方法中的一種。

第二實(shí)施例的混合型P2P機(jī)制首先包括正常地向流傳輸服務(wù)器請(qǐng)求數(shù)據(jù)。一旦播放器緩沖器處于安全水平，混合型P2P機(jī)制就考慮從最近的相鄰客戶端設(shè)備(對(duì)等端)獲取數(shù)據(jù)，而不是向服務(wù)器請(qǐng)求數(shù)據(jù)。為了與自適應(yīng)流傳輸策略共存并提供最佳質(zhì)量(見(jiàn)5.1.5)，在P2P系統(tǒng)中交換高視頻比特率。當(dāng)緩沖器健康時(shí)，通常觸發(fā)這種混合型P2P流傳輸模式，并且當(dāng)緩沖器小于15％時(shí)，數(shù)據(jù)流控制方法退出混合型P2P模式。

就視頻質(zhì)量而言，如今的IPTV用戶所期待的要遠(yuǎn)高于標(biāo)準(zhǔn)清晰度(SD)(480個(gè)像素)。如今制作的大多數(shù)內(nèi)容是高清晰度(HD)(720、1080個(gè)像素)質(zhì)量，并且需要一批新的流傳輸要求。這些要求包括更高的服務(wù)器規(guī)格、多個(gè)處理內(nèi)核、更大的帶寬骨干和網(wǎng)絡(luò)設(shè)備的廣泛I/O性能。還要求使用SD和其他ISP的現(xiàn)有服務(wù)提供商更多地投資于網(wǎng)絡(luò)升級(jí)。服務(wù)器主機(jī)運(yùn)營(yíng)和傳送成本也隨著高質(zhì)量視頻對(duì)更多數(shù)據(jù)使用的需求而增加。本發(fā)明的數(shù)據(jù)流控制方法的混合型P2P機(jī)制處理這些問(wèn)題。

數(shù)據(jù)流控制的混合型P2P機(jī)制是一種數(shù)據(jù)共享概念，其涉及向服務(wù)器向客戶端發(fā)送數(shù)據(jù)、客戶端向其他客戶端共享數(shù)據(jù)以及客戶端向許多客戶端共享數(shù)據(jù)的組合。這可以被視為層次樹(shù)結(jié)構(gòu)，其中服務(wù)器A是數(shù)據(jù)的原始源，其將數(shù)據(jù)提供給客戶端A，然后客戶端A將該數(shù)據(jù)提供給客戶端節(jié)點(diǎn)B、C、D等。因此，葉節(jié)點(diǎn)X的源可以是流傳輸服務(wù)器或者具有相同數(shù)據(jù)并且能夠?qū)⒃摂?shù)據(jù)提供給葉節(jié)點(diǎn)X的另一個(gè)葉節(jié)點(diǎn)。

在正常網(wǎng)絡(luò)條件下利用混合型P2P將最終以最高視頻比特率達(dá)到峰值流傳輸。當(dāng)網(wǎng)絡(luò)資源和速度良好并且在預(yù)定義時(shí)間時(shí)且如果條件保持良好，第二實(shí)施例的數(shù)據(jù)流控制機(jī)制將播放器切換到混合型P2P。參與P2P的客戶端設(shè)備將需要被配置為使得它們可以充當(dāng)“數(shù)據(jù)提供者”或“數(shù)據(jù)消費(fèi)者”或兩者，并且該信息可以存儲(chǔ)在后臺(tái)系統(tǒng)中，當(dāng)另一個(gè)客戶端請(qǐng)求數(shù)據(jù)提供者的設(shè)備中同樣可用的數(shù)據(jù)文件時(shí)被訪問(wèn)。當(dāng)客戶端設(shè)備最初將電影流傳輸?shù)皆O(shè)備時(shí)，電影信息和數(shù)據(jù)塊被記錄到中央數(shù)據(jù)庫(kù)中，用于未來(lái)分發(fā)引導(dǎo)。如果另一客戶端參與混合型P2P模式并請(qǐng)求特定內(nèi)容，則數(shù)據(jù)庫(kù)中的信息將該客戶端引導(dǎo)到具有該內(nèi)容且被許可為“數(shù)據(jù)提供者”的那些對(duì)等端。如果發(fā)現(xiàn)新客戶端的請(qǐng)求不匹配，則播放器將自動(dòng)退出混合型P2P，并基于本發(fā)明的上述實(shí)施例中所述的本發(fā)明的其他數(shù)據(jù)共享模式來(lái)恢復(fù)數(shù)據(jù)流。

在混合型P2P網(wǎng)絡(luò)機(jī)制中，一個(gè)客戶端設(shè)備可以與網(wǎng)絡(luò)內(nèi)的一個(gè)或多個(gè)客戶端共享緩存的數(shù)據(jù)，反之亦然。通過(guò)使用混合型P2P，服務(wù)器端可以節(jié)省高達(dá)90％的帶寬和I/O資源。在P2P網(wǎng)絡(luò)中，被注冊(cè)為數(shù)據(jù)提供者的客戶端設(shè)備越多，服務(wù)器側(cè)所需的負(fù)載越小。這允許IPTV服務(wù)運(yùn)營(yíng)商顯著降低服務(wù)器主機(jī)運(yùn)營(yíng)成本。

5.3第三實(shí)施例

本發(fā)明的數(shù)據(jù)流控制方法的第三實(shí)施例包括用于視頻質(zhì)量控制的模式和機(jī)制，以確保向IPTV終端用戶提供最高質(zhì)量的視頻數(shù)據(jù)。這些機(jī)制說(shuō)明如下：

5.3.1高質(zhì)量視頻的自適應(yīng)比特率流傳輸

這是從與第一實(shí)施例相關(guān)的第5.1.5項(xiàng)所述的自適應(yīng)比特率流傳輸導(dǎo)出的。第三實(shí)施例中的自適應(yīng)流傳輸基于視頻質(zhì)量貪婪策略。自適應(yīng)流傳輸是一種在計(jì)算機(jī)網(wǎng)絡(luò)上流傳輸多媒體的技術(shù)，通過(guò)實(shí)時(shí)檢測(cè)用戶的帶寬和CPU能力并相應(yīng)地調(diào)整視頻流的質(zhì)量來(lái)工作。這種機(jī)制需要使用能夠以多個(gè)比特率對(duì)單個(gè)源視頻進(jìn)行編碼的編碼器。播放器客戶端能夠根據(jù)可用資源在流傳輸不同編碼之間切換。這導(dǎo)致極少的緩沖、快速啟動(dòng)時(shí)間和高端和低端連接二者的良好體驗(yàn)。圖7中示出了用于實(shí)現(xiàn)高質(zhì)量視頻數(shù)據(jù)的自適應(yīng)數(shù)據(jù)流傳輸?shù)膬?yōu)選機(jī)制，下文對(duì)其進(jìn)行說(shuō)明：以下常數(shù)值基于可用視頻流的數(shù)量來(lái)定義。假設(shè)我們有streamNr視頻流，提供以下控制參數(shù)：

QualityGreedyThreshSec 12 streamNr*2

QualityGreedyDurSec streamNr*2.5

NoLimitUpThreshSec 12 streamNr*8

NoLimitUpThreshSec表示服務(wù)器可以在沒(méi)有任何限制的情況下切換到較高的比特率水平質(zhì)量。

QualityGreedyDurSec表示保持質(zhì)量貪婪切換策略的時(shí)長(zhǎng)。此策略將保持或切換到較高的比特率水平質(zhì)量。

QualityGreedyThreshSec定義何時(shí)開(kāi)始質(zhì)量貪婪切換策略。

利用這些定義，以下結(jié)合圖7來(lái)描述自適應(yīng)切換處理：

7a.在回放期間，如果播放器側(cè)的緩存時(shí)間小于12秒，那么服務(wù)器將切換到最低比特率。

7b.否則，如果緩存時(shí)間小于QualityGreedyThreshSec，那么我們需要檢查附加條件。如果當(dāng)前發(fā)送操作由于網(wǎng)絡(luò)問(wèn)題而被阻止，并且如果服務(wù)器發(fā)送速度大于1.6x rt_bitrate，則服務(wù)器將保持其當(dāng)前比特率水平，并且令

5.1.1中的“指數(shù)加速模式”來(lái)控制速度調(diào)節(jié)。但是如果服務(wù)器發(fā)送速度不超過(guò)1.6x rt_bitrate，則服務(wù)器將切換到較低的比特率水平質(zhì)量。

7c.當(dāng)緩存時(shí)間小于QualityGreedyThreshSec且發(fā)送操作未被阻止時(shí)，如果服務(wù)器發(fā)送速度大于1.0x rt_bitrate，服務(wù)器將切換到較高的比特率質(zhì)量水平。如果服務(wù)器發(fā)送速度不大于1.0x rt_bitrate，則保持當(dāng)前視頻質(zhì)量。

7d.如果當(dāng)緩存時(shí)間大于QualityGreedyThreshSec并小于NoLimitUpThreshSec時(shí)，服務(wù)器發(fā)送操作由于網(wǎng)絡(luò)問(wèn)題而被阻止，則自適應(yīng)流傳輸機(jī)制保持當(dāng)前視頻質(zhì)量。如果發(fā)送操作未被阻止，則將其切換到較高的比特率水平質(zhì)量。

7e.當(dāng)緩存時(shí)間大于NoLimitUpThreshSec時(shí)，服務(wù)器將切換到較高的比特率水平質(zhì)量，直到最高水平為止。

7f.每當(dāng)未達(dá)到最高比特率質(zhì)量水平時(shí)，將最大發(fā)送速度設(shè)置為1.6x rt_bitrate。當(dāng)網(wǎng)絡(luò)未來(lái)再次變好/正常時(shí)，這將限制低質(zhì)量視頻的時(shí)隙。

5.3.2高質(zhì)量視頻數(shù)據(jù)的起始比特率選擇

提出起始比特率選擇機(jī)制，作為本發(fā)明的數(shù)據(jù)流控制機(jī)制的一部分。在回放之前，檢查本地存儲(chǔ)器或緩存。如果本地有副本，則不請(qǐng)求流傳輸服務(wù)器，替代地，播放器立即播放本地?cái)?shù)據(jù)(類似于5.2.1的數(shù)據(jù)再循環(huán))。當(dāng)所有本地?cái)?shù)據(jù)都已被消耗時(shí)，根據(jù)本發(fā)明第三實(shí)施例的比特率選擇機(jī)制提出了以與本地文件相同的比特率進(jìn)行流傳輸?shù)姆椒?。播放器?cè)向服務(wù)器請(qǐng)求適當(dāng)?shù)奈募㈤_(kāi)始播放。初始比特率不必是最低視頻比特率。存在確定應(yīng)以什么比特率播放的許多因素。在該實(shí)施例中，其取決于回放設(shè)備屏幕的分辨率。理想情況下，如果是一個(gè)大屏幕電視，則最低視頻比特率不合適，并且可能具有非常差的視頻質(zhì)量。因此，在本發(fā)明的數(shù)據(jù)流控制方法的比特率選擇機(jī)制中，存在要在快速啟動(dòng)和視頻質(zhì)量之間做出的平衡。

圖8中可以看出根據(jù)第三實(shí)施例的用于實(shí)現(xiàn)起始比特率選擇機(jī)制的優(yōu)選方法。現(xiàn)在，存在許多不同類型的設(shè)備和能夠顯示流傳輸視頻的屏幕尺寸。每個(gè)設(shè)備唯一地支持不同的視頻分辨率，并且發(fā)送不正確的分辨率大小可能導(dǎo)致不可觀看的視頻或相關(guān)聯(lián)硬件的崩潰。因此，在向服務(wù)器請(qǐng)求視頻之前需要識(shí)別分辨率。在本發(fā)明中，這可以通過(guò)在播放器軟件中實(shí)現(xiàn)播放器類型ID來(lái)實(shí)現(xiàn)。當(dāng)播放器請(qǐng)求視頻文件時(shí)，數(shù)據(jù)流控制方法被配置為檢查設(shè)備類型ID并確定要發(fā)送哪個(gè)視頻文件，而不是始終以最低視頻比特率開(kāi)始發(fā)送。起始比特率選擇機(jī)制可以提供顯著的結(jié)果。例如，當(dāng)在大屏幕電視上播放電影時(shí)，較低的視頻比特率通常會(huì)表現(xiàn)出許多瑕疵。因此，當(dāng)播放器類型被識(shí)別為電視時(shí)，數(shù)據(jù)流控制裝置一開(kāi)始就可以以第二高或第三高水平的比特率而不是最低比特率來(lái)開(kāi)始發(fā)送。

5.3.3選擇性幀丟棄模式

在直播IPTV流傳輸會(huì)話期間，互聯(lián)網(wǎng)連接有時(shí)可能下降到最低視頻比特率以下，并且所應(yīng)用的所有視頻流傳輸機(jī)制和模式可能無(wú)法處理?yè)砣?。這種情況很少見(jiàn)，但可能導(dǎo)致緩沖器被清空，并且視頻回放可能中斷。有時(shí)，幾kbps的數(shù)據(jù)造成了流暢回放和視頻緩沖之間的區(qū)別。當(dāng)這種情況發(fā)生時(shí)，數(shù)據(jù)流控制裝置要從接受視頻緩沖效果或提供其他選項(xiàng)以保持流暢回放中做出選擇。

圖9中示出了本發(fā)明的選擇性幀丟棄模式。該機(jī)制是一個(gè)“不”流傳輸視頻GOP內(nèi)的非I幀(也稱為B/P幀)的動(dòng)態(tài)過(guò)程。這將產(chǎn)生視頻跳躍效果，但其同時(shí)允許在所需帶寬的僅20％可用時(shí)持續(xù)地進(jìn)行流傳輸。這可能是帶寬不足期間的一種可接受的效果形式。音頻不變差或中斷，這在大多數(shù)情況下對(duì)于用戶是可以接受的。例如，可以通過(guò)設(shè)置兩個(gè)丟棄水平來(lái)確保流暢回放：A.丟棄一個(gè)GOP(畫(huà)面組)中的50％的B/P幀，B.丟棄一個(gè)GOP(畫(huà)面組)中的100％的B/P幀。這將暫時(shí)減少30％-80％的所需帶寬，并且節(jié)省下的帶寬用于將剩余的視頻幀和音頻發(fā)送到播放器。在該時(shí)間窗期間，視頻可能呈現(xiàn)出一定的跳躍效果，并且可能保持這種方式直到網(wǎng)絡(luò)可以從嚴(yán)重的暫時(shí)擁塞恢復(fù)為止。如果上述任何模式都失敗了，則將該幀丟棄方法用作最終嘗試，并且可以確保連續(xù)流傳輸不被中斷。這確保流控制機(jī)制仍然可以提供質(zhì)量連續(xù)的視頻數(shù)據(jù)，并且可以短時(shí)間在100kbps的互聯(lián)網(wǎng)管道上流傳輸200kbps的視頻文件以保持流暢回放。圖10a是當(dāng)應(yīng)用選擇性幀丟棄機(jī)制時(shí)IPTV終端用戶觀看體驗(yàn)的指示，圖10b是在沒(méi)有這種機(jī)制的情況下的觀看體驗(yàn)的指示。如圖所示，圖10b中的緩沖效果不可避免。

5.3.4高動(dòng)態(tài)畫(huà)面優(yōu)先策略

視頻編碼可以具有用于增強(qiáng)視頻質(zhì)量的不同模式和濾波器。根據(jù)本發(fā)明的數(shù)據(jù)流控制方法提供了用于處理高動(dòng)態(tài)圖像幀以增強(qiáng)觀看體驗(yàn)、提供最高觀看質(zhì)量和有效管理網(wǎng)絡(luò)資源的機(jī)制或策略。在H.264編解碼器中，VBR(可變比特率)編碼是可以產(chǎn)生良好的視頻質(zhì)量輸出的模式。該編碼對(duì)那些快速動(dòng)態(tài)移動(dòng)場(chǎng)景生成較大的GOP并對(duì)較少動(dòng)態(tài)的場(chǎng)景生成較小的GOP，并且生成大的GOP(畫(huà)面組)，反之亦然。每當(dāng)流控制方法處理大GOP時(shí)，其消耗更多的網(wǎng)絡(luò)資源，這將產(chǎn)生網(wǎng)絡(luò)尖峰或抖動(dòng)。如果不考慮這一因素，則“快速動(dòng)態(tài)畫(huà)面”場(chǎng)景可能欺騙數(shù)據(jù)流協(xié)議，其被用于錯(cuò)誤地從當(dāng)前視頻質(zhì)量切換到下一個(gè)較低的質(zhì)量水平。這是因?yàn)榇驡OP可能錯(cuò)誤地警告數(shù)據(jù)流控制的自適應(yīng)流傳輸機(jī)制(在5.3.1中列出)以切換到較低的比特率。這種錯(cuò)誤觸發(fā)顯著地影響了觀看體驗(yàn)。為了避免這種錯(cuò)誤警報(bào)，本發(fā)明在第三實(shí)施例中提出了一種數(shù)據(jù)流控制機(jī)制，其實(shí)現(xiàn)下面描述的、被稱為“高動(dòng)態(tài)畫(huà)面優(yōu)先”或高動(dòng)態(tài)畫(huà)面優(yōu)選考慮策略的策略，以在有限的網(wǎng)絡(luò)條件下獲得更好的觀看體驗(yàn)。

圖11中示出了高動(dòng)態(tài)畫(huà)面優(yōu)先機(jī)制。在視頻會(huì)話開(kāi)始時(shí)，數(shù)據(jù)流控制方法利用大約第一分鐘來(lái)測(cè)量和檢測(cè)網(wǎng)絡(luò)帶寬。如果確定帶寬足以維持最高視頻比特率，則停止遞增式比特率切換，并且流控制直接跳轉(zhuǎn)到最高級(jí)。選擇性GOP也是增強(qiáng)本發(fā)明的數(shù)據(jù)流控制機(jī)制的視頻觀看體驗(yàn)的重要因素。檢查每個(gè)GOP并考慮它們的大小。如果GOP大小遠(yuǎn)大于視頻比特率，則這轉(zhuǎn)換為高動(dòng)態(tài)事件。低網(wǎng)絡(luò)環(huán)境下的這些大GOP可能導(dǎo)致緩沖，并且低編碼比特率暴露實(shí)體動(dòng)畫(huà)(pixilation)下的大GOP也導(dǎo)致差的視頻質(zhì)量。

在發(fā)送一個(gè)GOP中的運(yùn)動(dòng)畫(huà)面的第一分組之前，通過(guò)數(shù)據(jù)流控制機(jī)制來(lái)計(jì)算GOP大小。如果該GOP中的平均比特率比當(dāng)前影片剪輯的平均比特率小30％，則該GOP被標(biāo)記為“低動(dòng)態(tài)畫(huà)面GOP”。如果一個(gè)GOP中的平均比特率比當(dāng)前影片剪輯的平均比特率大30％，則該GOP被標(biāo)記為“快速動(dòng)態(tài)畫(huà)面GOP”。

數(shù)據(jù)流控制機(jī)制通過(guò)檢查是否正在流傳輸最高視頻比特率來(lái)繼續(xù)監(jiān)視網(wǎng)絡(luò)吞吐量。如果流傳輸?shù)碾A段不處于最高比特率，則認(rèn)為網(wǎng)絡(luò)條件較差，并且數(shù)據(jù)流控制方法將不能始終使用較高比特率來(lái)發(fā)送數(shù)據(jù)。這種狀況會(huì)顯著影響回放視頻質(zhì)量，因?yàn)閹挼妮p微變化會(huì)錯(cuò)誤地告訴播放器去請(qǐng)求較低的比特率。為了克服這個(gè)問(wèn)題，識(shí)別本地緩沖器的條件以及正在發(fā)送的GOP的類型。如果緩沖器處于安全閾值，并且如果發(fā)送GOP被標(biāo)記為“低動(dòng)態(tài)畫(huà)面GOP”，則數(shù)據(jù)流控制方法切換到較低的比特率，以產(chǎn)生用于“快速動(dòng)態(tài)畫(huà)面GOP”的附加帶寬。因此，數(shù)據(jù)流控制機(jī)制針對(duì)那些靜態(tài)或低動(dòng)態(tài)畫(huà)面GOP時(shí)鐘控制下降(clock down)到較低的比特率，以預(yù)留在較高比特率用于較高GOP的帶寬。由此，保持了恒定的視頻質(zhì)量以及流暢的流傳輸效果。

高動(dòng)態(tài)畫(huà)面優(yōu)先策略允許數(shù)據(jù)流控制方法在擁塞時(shí)間窗期間繼續(xù)發(fā)送較高比特率，以始終為那些高動(dòng)態(tài)畫(huà)面GOP分配更多帶寬。

5.3.5緩沖器增強(qiáng)和修復(fù)

動(dòng)態(tài)自適應(yīng)流傳輸(5.3.1中)和選擇幀丟棄(5.3.1)用于保持流暢的流傳輸，以對(duì)抗互聯(lián)網(wǎng)帶寬波動(dòng)和不穩(wěn)定性。然而，這些機(jī)制有時(shí)可能導(dǎo)致負(fù)面影響，例如，隨著網(wǎng)絡(luò)條件產(chǎn)生的可見(jiàn)視頻變差或?qū)崟r(shí)幀跳變。這些負(fù)面影響被認(rèn)為是不可避免的，目前的技術(shù)不能解決它們。本發(fā)明的數(shù)據(jù)流方法提出了一種緩沖器修復(fù)或增強(qiáng)機(jī)制，用于監(jiān)視網(wǎng)絡(luò)條件和緩沖器填充率，然后預(yù)測(cè)有多少時(shí)間和速度可用于允許流控制方法用高質(zhì)量GOP替換緩沖器中的較低質(zhì)量GOP。

這種緩沖器修復(fù)機(jī)制提高了視頻回放質(zhì)量。隨著流傳輸?shù)倪M(jìn)行，網(wǎng)絡(luò)波動(dòng)并且及視頻質(zhì)量也波動(dòng)。在自適應(yīng)比特率流傳輸中，緩沖器被分段成多個(gè)段，所述多個(gè)段由形成連續(xù)回放時(shí)間軸的各個(gè)視頻比特率組成。一些視頻段具有低比特率，這對(duì)觀看體驗(yàn)具有負(fù)面影響。為了解決這個(gè)問(wèn)題，當(dāng)緩沖器達(dá)到安全水平，即80％滿載時(shí)，應(yīng)用數(shù)據(jù)流控制的緩沖器修復(fù)機(jī)制。在該模式期間，流控制方法被配置為檢查緩沖器中具有低視頻比特率且仍然排隊(duì)等待播放的先前流傳輸?shù)亩?。然后，緩沖器修復(fù)機(jī)制被配置為在轉(zhuǎn)到回放前請(qǐng)求用較高視頻比特率替換這些段。這確保緩沖器的第一部分始終具有最高視頻比特率并以最高視頻質(zhì)量進(jìn)行回放。

圖12中示出了緩沖器修復(fù)或增強(qiáng)機(jī)制，并且詳細(xì)說(shuō)明如下：

12a.在回放會(huì)話期間，流控制機(jī)制確保播放器保持一個(gè)GOP隊(duì)列，所述GOP隊(duì)列存儲(chǔ)將被發(fā)送到視頻解碼器的所有GOP數(shù)據(jù)。

12b.播放器周期性地監(jiān)視GOP隊(duì)列。如果該隊(duì)列的時(shí)間跨度小于10秒，則不采取任何操作。否則，播放器將檢查隊(duì)列中是否存在僅有一部分B/P幀的任何GOP(部分GOP)。如果沒(méi)有要在10秒內(nèi)發(fā)送到解碼器的部分GOP，則該機(jī)制被配置為檢查當(dāng)前服務(wù)器發(fā)送速度。如果服務(wù)器發(fā)送速度小于或等于1.0x rt_bitrate，則不采取任何操作。否則，如果發(fā)送速度大于1.0x re_bitrate，則流控制機(jī)制請(qǐng)求服務(wù)器以相同質(zhì)量重新發(fā)送具有所有幀的該GOP。12c.在接收到由服務(wù)器重新發(fā)送的具有所有幀的GOP之后，播放器然后將使用該GOP來(lái)替換GOP隊(duì)列中的部分GOP。12d.如果隊(duì)列中沒(méi)有部分GOP，并且如果隊(duì)列時(shí)間跨度小于15秒，則不采取任何動(dòng)作。

12e.否則，在該隊(duì)列中識(shí)別最低質(zhì)量GOP，并將其與當(dāng)前接收GOP質(zhì)量進(jìn)行比較。如果最低質(zhì)量GOP高于當(dāng)前數(shù)據(jù)，則不采取動(dòng)作。否則，如果服務(wù)器當(dāng)前發(fā)送速度大于1.0x rt_bitrate，則播放器將請(qǐng)求服務(wù)器以高一級(jí)的質(zhì)量重新發(fā)送該GOP。

12f.在接收到由服務(wù)器重新發(fā)送的高一級(jí)的質(zhì)量的該GOP之后，數(shù)據(jù)流機(jī)制使用該GOP來(lái)替換GOP隊(duì)列中的舊GOP。

5.4第四實(shí)施例

以下機(jī)制提供了可應(yīng)用于現(xiàn)有TCP數(shù)據(jù)傳輸以提供根據(jù)本發(fā)明第四實(shí)施例的增強(qiáng)型數(shù)據(jù)流控制方法的流控制技術(shù)。

5.4.1動(dòng)態(tài)Nagle算法

在背景技術(shù)部分2中解釋的Nagle算法對(duì)IPTV服務(wù)具有默認(rèn)(200+ms時(shí)間延遲)的負(fù)面影響，尤其是當(dāng)用戶發(fā)起例如頻道改變、內(nèi)容查詢、計(jì)費(fèi)等交互式服務(wù)時(shí)。因此，本發(fā)明提出了一種基于動(dòng)作和請(qǐng)求的類型來(lái)動(dòng)態(tài)地啟用/禁用Nagle算法以確?？梢詫?shí)現(xiàn)最佳效果的方法。理想情況下，當(dāng)檢測(cè)到用戶設(shè)備和服務(wù)器之間的命令交換時(shí)，第四實(shí)施例的流控制方法禁用Nagle算法。這消除了TCP傳輸層上至少200ms的延遲。這樣做可以減少將被注入到網(wǎng)絡(luò)中的分組的數(shù)目，并且還可以改善用戶交互體驗(yàn)。

圖13中示出了用于應(yīng)用如上所述的動(dòng)態(tài)Nagle算法應(yīng)用的優(yōu)選過(guò)程。圖14a中示出了當(dāng)Nagle算法處于啟用、禁用和自適應(yīng)狀態(tài)時(shí)所進(jìn)行的測(cè)試的細(xì)節(jié)，圖14b中示出了每個(gè)上述狀態(tài)的不同的分組發(fā)送速率。在LAN環(huán)境中進(jìn)行這些測(cè)試。

5.4.2修改的Linux控制

以下Linux控制可以應(yīng)用于現(xiàn)有的TCP以提供根據(jù)本發(fā)明的增強(qiáng)型數(shù)據(jù)流控制。

A.net.ipv4.tcp_window_scaling＝1

此參數(shù)允許TCP在接收機(jī)和發(fā)送機(jī)上使用大的窗口尺寸。這將提高總吞吐量。

B.net.ipv4.tcp_timestamps＝1

此參數(shù)允許TCP在其報(bào)頭中使用時(shí)間戳選項(xiàng)。這將有助于TCP估計(jì)RTT值(往返時(shí)間)

C.net.ipv4.tcp_sack＝1

此參數(shù)允許TCP接收機(jī)發(fā)送選擇性確認(rèn)以報(bào)告多個(gè)分組丟失，而不是針對(duì)每個(gè)確認(rèn)僅報(bào)告一個(gè)分組。這將有助于發(fā)送機(jī)更快地重傳丟失的分組。

D.net.ipv4.tcp_congestion_control＝cubic

此參數(shù)僅對(duì)內(nèi)核2.6.13或以后的版本有效。它允許用戶改變擁塞控制算法以獲得特殊應(yīng)用的更好性能。

E.net.core.rmem_max/net.core.wmem_max

這些參數(shù)控制發(fā)送機(jī)和接收機(jī)通告的窗口大小。它們將通過(guò)限制網(wǎng)絡(luò)中的實(shí)時(shí)數(shù)據(jù)來(lái)影響TCP吞吐量。可以根據(jù)提供的不同網(wǎng)絡(luò)環(huán)境來(lái)放大該窗口大小。

F.新內(nèi)核

從Linux 2.6.17版本起，cwnd可以高達(dá)4MB。這將提高高速網(wǎng)絡(luò)上的TCP吞吐量。

5.5本發(fā)明的數(shù)據(jù)流控制技術(shù)的交互

圖13中示出了構(gòu)成所提出的本發(fā)明的第一、第二和第三實(shí)施例的數(shù)據(jù)流控制協(xié)議或方法的上述模式、策略、方法和機(jī)制的交互。

盡管描述了一些實(shí)施例，但是這些實(shí)施例僅以示例方式提出，而不是為了限制本發(fā)明的范圍。事實(shí)上，本文中描述的新設(shè)備、方法和產(chǎn)品可以以各種形式來(lái)體現(xiàn)；此外，可以在不脫離本發(fā)明的精神和范圍的情況下，對(duì)本文描述的方法和系統(tǒng)的形式進(jìn)行各種省略、替換和改變。所附權(quán)利要求及其等同物旨在涵蓋落入實(shí)施例的范圍內(nèi)的這些形式或修改。