專利名稱:用于管理隧道的傳輸信道上的數(shù)據(jù)流的傳送的方法、相應的隧道端點和計算機可讀存儲介質(zhì)的制作方法
技術領域:
本發(fā)明的領域是通信網(wǎng)絡領域。
更具體而言,本發(fā)明涉及管理由主通信網(wǎng)絡支持的隧道(tunnel) 的傳輸4言道(transport channel)上的數(shù)據(jù)流的傳送的4支術。
背景技術:
一方面的高比特率因特網(wǎng)的民主化(democratization)和另一方 面的具有網(wǎng)絡連接性的消費者視聽設備的出現(xiàn)將要創(chuàng)造出新形式的用 戶行為。這些新形式的行為無疑將伴隨屬于可被稱為"永久鏈接"組的 共同興趣組(即,諸如休閑、家庭等的共同興趣)的個體的出現(xiàn)。這 些組將與具有相同的興趣領域的其它個體建立幾乎永久的連接,從而 建立音頻和/或視頻通信并共享所有類型的信息(音頻、視頻、照片、 文本等)。
虛擬專用網(wǎng)絡(Virtual Private Network, VPN)的4支術對于此需 求提供了值得嘗試的方案。該技術使得能夠在共享同一興趣領域并且 同時使用可靠性低但不昂貴的因特網(wǎng)基礎結構的個體之間實現(xiàn)實時、 透明和安全的通信。
為了透明地通信并克服對于不可路由的地址的需要,VPN使用一 種特定類型的被稱為隧穿的封裝,所述隧穿創(chuàng)建所謂的隧道。該操作 包括利用封裝協(xié)議C將A級協(xié)議(嵌入或被運送或乘客協(xié)議)封裝在 B級協(xié)議(傳輸或運送協(xié)議)中。因此,傳輸協(xié)議B處理乘客協(xié)議A, 就好像它是有效負載數(shù)據(jù)。
以下詳細描述的圖3呈現(xiàn)出第2級VPN中的數(shù)據(jù)包封裝即第2 級隧道(第2級隧道意味著該乘客協(xié)議是ISO模型的第2層的協(xié)議,其中ISO模型描述由這些層中的每一個和它們的交互作用所提供的服
務)中的封裝的示例。
隧穿可被用于在不支持某個網(wǎng)絡協(xié)議的網(wǎng)絡上傳輸該網(wǎng)絡協(xié)議。
它還可,皮用于提供諸如例如私有尋址(private addressing)之類的不 同類型的VPN功能。
隧穿技術現(xiàn)在正越來越多地被需要遠程客戶訪問和家庭局域網(wǎng) (LAN)的功能使用。
在以下的描述中,僅以舉例方式考慮OSI模型中的傳輸協(xié)議B的 級別等于傳輸層(ISO模型中的第4級傳輸層)的級別的第2級或第 3級隧道。很明顯,本發(fā)明的上下文決不是詳盡的,并且,OSI模型
或更高(在某些時候以及具有HTTP載體的情況下)。
隧穿技術頻繁掉支用于使兩個LAN互連,以^更創(chuàng)建由兩個原始LAN 的聯(lián)合(union)形成的虛擬專用網(wǎng)絡(VPN)。安全的VPN包含密 碼和驗證(authentication)算法,以保證傳輸數(shù)據(jù)的秘密性。在圖1 (以下詳細描述)中示出基于隧穿技術的典型的VPN配置。在該示例 中,隧道端點(TEP)沒有被集成到網(wǎng)關中。在兩個隧道端點之間建 立隧道,并且,向與遠程LAN連接的裝置發(fā)送的各數(shù)據(jù)包(也稱為 幀)被局域隧道端點封裝然后被發(fā)送到遠程隧道端點,該遠程隧道端 點將對其進行解封然后將其發(fā)送到遠程LAN。從通過隧道互連的LAN 的各裝置的觀點來看,它們虛擬地與同一 LAN連接。由于隧道的使 用對于所連接的LAN的裝置是透明的,因此通過隧道在兩個裝置之 間進行的通信被稱為端對端通信。
在現(xiàn)有技術中,使用的主要是IP或因特網(wǎng)協(xié)議(第3層)或TCP (傳輸控制協(xié)議)/UDP (用戶數(shù)據(jù)報協(xié)議)(第4層)。由于基于IP 的隧穿技術不能考慮網(wǎng)絡地址轉(zhuǎn)換(NAT)機構,并且由于它們并不 完全與圖1的典型的隧穿配置兼容,因此以下的其余描述考慮(僅作 為示例)基于第4層(傳輸層)即TCP或UDP的方案。
如在呈現(xiàn)出TCP協(xié)議的操作原理的附錄中說明的那樣,TCP協(xié)議(由IETF標準RFC793定義)是基于擁塞控制和重新傳送機構的 ARQ (自動重復請求)類型的協(xié)議,并因此確保各數(shù)據(jù)包向其目的地 的傳送。
UDP協(xié)議是簡單得多且快得多的協(xié)議,它不考慮幀的次序并且不 管理確認。
如上所述,TCP協(xié)議祐 沒計為靈活的,并且在包括具有高等待時 間的慢鏈路和快鏈路或具有可變錯誤率的鏈路的寬范圍的網(wǎng)絡通信環(huán) 境中工作。雖然TCP協(xié)議工作用于不同的環(huán)境,但是這些性能水平(特 別是帶寬)受所使用的各通信鏈路的特性的影響。在具有很長的路由 時間且/或具有高錯誤率的環(huán)境中,TCP協(xié)議在帶寬方面的性能受損。
可以使用高級的代理概念或基于RFC 3135標準的PEP (代理增 強協(xié)議)類型的概念來提高基礎結構的性能。RFC 3135標準描述用于 改善數(shù)據(jù)流傳送的不同類型的機構(以下稱為PEP機構),這些機構 被嵌入到服務器和客戶機之間的TCP流的路由路徑上的網(wǎng)絡裝置中。 如后面將描述的那樣,對于每個環(huán)境個別地對待PEP系統(tǒng),以便因此 作用于TCP流擁塞的控制。
在因特網(wǎng)的情況下,連接一般為"盡最大努力(best effort )"類型, 即,這些連接盡一切可能將信息運送到它們的目的地,但是在執(zhí)行這 一點時不保證一定水平的服務質(zhì)量(QoS)。因此,在VPN通信的背 景下,隧道的傳輸層在傳輸容量方面經(jīng)受高的波動。
在常規(guī)上,此隧道的乘客TCP流執(zhí)行端對端擁塞控制,即,在確 定從服務器設備(以下也稱為發(fā)送器設備)向客戶機設備(以下也稱 為接收器設備)發(fā)送數(shù)據(jù)所必須的比特率時,兩個通信設備一起工作。 但是,發(fā)送器設備具有在隧道中傳輸流的條件下可得到的信息,從發(fā) 送器設備和接收器設備的觀點看,此隧道是透明的。于是,通過與接 收器設備建立的端對端擁塞控制獲得的信息可導致由發(fā)送器設備采取 的這樣的決定該決定不適于隧道上的傳輸條件,并且通過不必要的 重新傳送或可用帶寬的利用不足而導致帶寬消耗增大。
可以建立PEP機構,以便在給定的時間點上根據(jù)該隧道的固有限制來影響對于來自隧道的乘客TCP流的擁塞控制。 對問題的描述
在諸如例如因特網(wǎng)之類的廣域網(wǎng)(以下稱為WAN)中的VPN隧 道的暫時擁塞期間,使用可靠的、基于確認的通信協(xié)議的該隧道的載 體(即,例如根據(jù)TCP協(xié)議的該隧道的傳輸信道)將進入自動重新傳 送。這將具有暫停在該隧道的該傳輸信道中運送的所有的流(即使是 不直接與隧道載體的封裝、數(shù)據(jù)包即嵌入數(shù)據(jù)包的損失相關的那些流) 的效果。事實上,可以通過隧道的同一傳輸信道(即,同一通信會話) 運送若干個乘客流。此外,通過構建,TCP協(xié)議保證數(shù)據(jù)包的到達次 序,并且不事先將跟隨該隧道的損失數(shù)據(jù)包的隧道的數(shù)據(jù)包給予接收 器實體(在這種情況下為遠程隧道端點)。換句話說,將不把載體的
給遠程LAN。僅當損失數(shù)據(jù)包已被發(fā)送器隧道端點重新傳送并且被接 收器隧道端點接收時,才對這些存儲的數(shù)據(jù)包進行解除阻塞
可以看出,損失數(shù)據(jù)包的重新傳送的階段使得隧道上的往返時間 或RTT成為必需,其是對數(shù)據(jù)包的經(jīng)典數(shù)據(jù)/確認(DATA/ACK)傳 送階段的補充。 ,
由于因特網(wǎng)隧道上的RTT非常高(為LAN的10-100倍),因 此很明顯,該RTT非常顯著地調(diào)整通過在遠程客戶機和服務器之間的 隧道運送的連接(即,作為隧道的乘客的連接)的行為。
因此,在VPN的暫時擁塞期間,所有的乘客連接經(jīng)受隧道的RTT 的兩倍的延遲,即,接近這些連接的重新傳送超時(以下稱為RTO) 的臨界值的延遲。
取決于WAN的波動,可以看出,在VPN隧道段上進行廣播的 TCP服務器遭受它們的RTO的期滿,從而產(chǎn)生它們的傳送比特率的 崩潰??梢曰叵?,這些服務器的比特率的增大直接依賴于運送到接收 方所花費的時間(RTT),這是因為延遲越大則在崩潰之前恢復初始傳送比特率所花費的時間將越多。此外,不管隧道中對于損失的封裝 數(shù)據(jù)包的重新傳送的接管情況如何,重新傳送也由發(fā)送隧道的乘客流
的TCP服務器進行。
總之,TCP隧道上的最小損失對于嵌入在該隧道中的TCP連接 的端對端性能具有破壞性的影響。
PEP才幾構主要纟皮應用于擁塞控制,以及^皮應用于由TCP類型的 連接采用的不同的網(wǎng)絡段上的重新傳送的問題。為了克服隧道的載體 (TCP傳輸信道)上的封裝數(shù)據(jù)包(WAN數(shù)據(jù)包)的損失的上述問 題,基于數(shù)據(jù)包的暫時存儲或緩存的PEP機構可在它們的高速緩沖存 儲器中存儲更多的數(shù)據(jù)。但是,這在時間上具有有限的效果。
至多,這些PEP機構可延遲由隧道承載的連接的超時現(xiàn)象,但這 是不足夠的。
因此,必須克服在暫時擁塞的TCP隧道中運送的連接的RTO超 時的這個問題,并因而提出用于控制從本地LAN向遠程LAN運送穿 過該隧道的數(shù)字內(nèi)容的TCP服務器的傳送比特率的有效方法,并且, 這是本發(fā)明的基本要務。
現(xiàn)有技術
對于不穩(wěn)定環(huán)境(諸如因特網(wǎng)或無線鏈路)中的TCP性能的改善, 存在兩種類別的原理端對端協(xié)i義和分裂連接協(xié)議(split-connection protocol)。由于后一種類別的協(xié)議違反支持端對端客戶機TCP連接 的隧穿的固有原理,因此我們的問題不考慮該后一種類別的協(xié)議該 后一種類別的協(xié)i義的原理在于,它對于異質(zhì)網(wǎng)絡(heterogeneous network)的各部分具有其自身的特征連接。
大多數(shù)的端對端連接協(xié)議原理依賴于在異質(zhì)型網(wǎng)絡(典型為WAN 的隧道端點或無線網(wǎng)絡的基站)之間的基礎結構設備中添加PEP (性 能增強代理)型專門代理(specialized agent)。
現(xiàn)在將討論使得能夠克服TCP隧穿上的TCP的某些影響的兩種 現(xiàn)有技術。
ii在專利文獻 US2006/0002301 Al ( INTEL CORP. US, "Transferring TCP Packets")中描述了第一種現(xiàn)有技術。該專利文獻 涉及連接兩個遠程LAN的TCP隧道的情形,通過該隧道在這兩個 LAN的裝置之間建立TCP連接。
為了當在隧道中存在損失時避免數(shù)據(jù)的雙重重新傳送(對應于通 過隧道載體進行的一個重新傳送以及通過乘客TCP流進行的另一個 重新傳送),提出在各隧道端點上實現(xiàn)PEP暫時存儲機構,進一步使 得能夠在兩個隧道端點之間交換與在任一側有效接收的數(shù)據(jù)包有關的 信息。在第一種現(xiàn)有技術交換中,通過組合以下的效果對LAN的裝 置隱藏隧道上的損失首先,對于損失的各條數(shù)據(jù)在隧道中發(fā)生自動 重新傳送,第二,暫時存儲器部分掩蔽該重新傳送所需要的延遲。
這就消除了端對端重新傳送(乘客TCP流),實現(xiàn)了通過隧道載 體的單一重新傳送的益處??捎玫母咚倬彌_存儲器因而提供在各網(wǎng)絡 段(本地LAN、 WAN、遠程LAN)上的對重新傳送的本地管理。該 機構應對以下情況時的隧道的性能問題即,當在該隧道上存在損失 時(僅以必要的重新傳送有效使用隧道的帶寬),以及當在遠程網(wǎng)絡 上存在損失時(本地重新傳送)。
但是,所提出的機構沒有解決本地LAN等待遠程客戶機(與遠 程LAN連接)對其數(shù)據(jù)的確認的RTO超時的影響。
期望在如第一現(xiàn)有技術中所實現(xiàn)的那樣的暫時存儲區(qū)域也掩蔽 WAN上在傳送時間方面的損失是徒勞的。至多,運送來自(各隧道 端點中的)暫時存儲區(qū)域的數(shù)據(jù)包所耗費的時間的波動會加長TCP服
務器對RTO的感知(在上述的專利文獻中沒有評述)。
在以下的IEEE文章中描述了第二現(xiàn)有4支術Elaoud, M.; Ramanathan, P, "TCP-SMART: a technique for improving TCP performance in a spotty wide band environment", ( IEEE Communications, 2000. ICC 2000; Page(s): 1783-1787 vol. 3; Digital Object Identifier 10.1109/ICC.2000.853814 )。
該文章描述了負責實施本地重新傳送的窺探(snoop )型機構和對重復確認或重復ACK的過濾,以便提高穿過不穩(wěn)定環(huán)境(在鏈路經(jīng) 常損壞的無線鏈路中)的端對端TCP連接的性能。
該第二現(xiàn)有技術針對減少在無線鏈路損壞期間的服務器的RTO 的期滿的數(shù)量,這些損壞妨礙來自遠程TCP客戶機的確認到達。
無線基站處的PEP代理分析各TCP連接,并且暫時存儲要在無 線鏈路上被送出的數(shù)據(jù)。當此數(shù)據(jù)的確認從遠程TCP客戶機被代理接 收時,從高速緩存中除去這些數(shù)據(jù)包。如果在某時間段期間沒有接收 到確認,或者如果接收到出錯指示(重復確認或重復ACK),那么這 些數(shù)據(jù)被重新傳送到客戶機。這是經(jīng)典PEP存儲機構的行為。
該第二現(xiàn)有技術還添加用于產(chǎn)生意圖用于"確認窗口"或"告知窗 口"字段為0的有線網(wǎng)絡的TCP服務器的重復確認(重復ACK)的功 能,以便停止從TCP傳送。然后,TCP服務器處于暫停模式,對來 自客戶機(具有嚴格大于0的告知窗口字段)的新的確認懸而不決, 以從該模式釋放它。
該笫二現(xiàn)有技術針對在不連續(xù)的無線鏈路上的通信呼叫的情形下 解決與本發(fā)明相同的問題(即,針對防止TCP服務器的RTO的期滿 的現(xiàn)象),然而,該第二現(xiàn)有技術不適于RTT大得多的WAN環(huán)境。 事實上,在無線載體的或多或少較長的物理斷開期間停止服務器傳送 以防止緩沖器的擁塞的原理似乎在不連續(xù)的無線鏈路上的通信的情況 下是值得的,但是在限于一個數(shù)據(jù)包的損失決不意味著該隧道的停止 (此外,由于該隧道重新傳送損失的數(shù)據(jù),因此它是保持活動的)的 VPN隧道的情況下是不值得的??梢曰叵耄?建立了隧道的)WAN 上的運送速度遠小于處于LAN或WLAN (無線LAN)上的速度,并 且WAN的容量的利用不足在運送時間方面是昂貴的。
如上所呈現(xiàn)的,現(xiàn)有技術PEP機構主要是基于暫時數(shù)據(jù)存儲的原 理而準備的。由于必須對至少2個RTT的持續(xù)時間存儲數(shù)據(jù),因此在 (建立了該隧道的)WAN上進行傳送的情形下這意味著大量的存儲 器資源。由于隧道的載體肯定將自動負責重新傳送建立了該隧道的 WAN上的雜散數(shù)據(jù)包,因此這更加損害TCP VPN隧道。由第二現(xiàn)有技術提出的設備更加精巧,但不適于從因特網(wǎng)上的TCP隧道的傳送容 量得到最佳的可能的益處。
因此,現(xiàn)有技術沒有任何以下這樣的技術即,該技術在資源方 面的成本低,并使得對服務器和客戶機透明(符合端對端TCP連接的 上述原理)的TCP服務器能夠掌握內(nèi)部TCP管理控制,并適于VPN 隧道中的零星損失。
本發(fā)明的目的
至少 一 個實施例中的本發(fā)明特別針對于克服現(xiàn)有技術的這些不同 的缺點。
更具體而言,本發(fā)明的至少一個實施例的目標是,提供用于管理 隧道的傳輸信道上的數(shù)據(jù)流傳送的技術,通過該技術,在檢測到對于 該隧道的擁塞(在數(shù)據(jù)損失之后和/或在該隧道的等待時間一次增大期 間,隧道進入重新傳送階段)時,能夠控制對一個或更多個傳送器設 備(例如,TCP服務器)的傳送比特率的管理,使得能夠?qū)碜赃@些 服務器的傳送流的帶寬的限制最小。
本發(fā)明的至少一個實施例的目的還在于,提供一種不要求例如發(fā) 送器(服務器)設備和接收器(客戶機)設備的TCP/IP堆棧的任何 修改的技術。
本發(fā)明的至少一個實施例的另 一 目標是,提供一種對于發(fā)送器(服 務器)設備和接收器(客戶機)設備完全透明的技術。
本發(fā)明的至少一個實施例的另 一 目標是,提供要求有限的存儲器 資源的技術。
本發(fā)明的至少一個實施例的再一 目標是,提供一種實現(xiàn)簡單并且 成本低的技術。
發(fā)明內(nèi)容
本發(fā)明的一個特定實施例提出一種用于管理隧道的傳輸信道上的 數(shù)據(jù)流的傳送的方法,各流的傳送是根據(jù)由數(shù)據(jù)包調(diào)度并具有確認的傳輸協(xié)議在所述傳輸信道上執(zhí)行的,隧道是在分別與第 一和第二子網(wǎng) 連接的第一和第二隧道端點之間實現(xiàn)的,各流從發(fā)送器設備向接收器 設備傳送,所述發(fā)送器設備和所述接收器設備中的一個設備與第一子 網(wǎng)連接,并且另一個與第二子網(wǎng)連接,所述方法通過所述第一隧道端
點執(zhí)行,并且,該方法包括以下步驟
-檢測隧道的傳輸信道上的數(shù)據(jù)包的損失;
-識別具有由于所述損失而在隧道的傳輸信道上被阻塞的至少一 個數(shù)據(jù)包的至少一個流;
-對于至少 一個被識別的流,產(chǎn)生至少 一個確認并將其傳送給在 隧道上傳送了由于所述損失而被阻塞的數(shù)據(jù)包的發(fā)送器設備。
因此,在該特定的實施例中,本發(fā)明依賴于一種完全具有新穎性 和創(chuàng)造性的方法,在該方法中,施加預防性的校正(通過隧道輸入隧 道端點產(chǎn)生"假想的,,確認)以防止發(fā)送器設備(服務器)的RTO的 期滿現(xiàn)象。
因此,并非如在第二現(xiàn)有技術中那樣停止發(fā)送器設備,而是允許 發(fā)送器設備相信發(fā)送的數(shù)據(jù)的運送處于控制之下,并且它們可繼續(xù)傳 送其余的數(shù)據(jù)。
對于有效栽荷數(shù)據(jù)節(jié)省了隧道的帶寬消除了隧道的乘客流的自 動重新傳送(而且常常以突發(fā)形式)。
該技術對于發(fā)送器設備(服務器)和接收器設備(客戶機)是完 全透明的。不存在對發(fā)送器設備(服務器)和接收器設備(客戶機) 的例如TCP/IP協(xié)議堆棧的協(xié)議堆棧的修改。
由于沒有(由于PEP存儲機構引起的)可能的存儲器溢出,因此 該技術使得有限存儲器資源成為必須。
有利地,對于至少一個給定的被識別的流,所述至少一個產(chǎn)生的 確認是對所述被識別的流中在由于所述損失而被阻塞的第一個數(shù)據(jù)包 之前的數(shù)據(jù)包的確認。對于已檢測到其損失的數(shù)據(jù)包所屬的被識別的 流,由于所述損失而被阻塞的第 一個數(shù)據(jù)包被視為是在檢測到該損失 之后在隧道的傳輸信道上重新傳送的數(shù)據(jù)包。
15因此,對由第一隧道端點產(chǎn)生的確認的傳送通知接收它們的發(fā)送
器設備連接仍然有效,并且對于各有關的流不存在數(shù)據(jù)包的運送延 遲以外的其他特定問題。
有利地,對于至少一個給定的被識別的流,所述產(chǎn)生并傳送至少 一個確認的步驟包含以下的步驟
-根據(jù)與傳送所述給定的被識別的流的發(fā)送器設備相關聯(lián)的重新 傳送超時的持續(xù)時間的估計,并且,根據(jù)由所述隧道端點處理由于所 述損失而被阻塞的所述被識別的流的第 一個數(shù)據(jù)包之前的所述數(shù)據(jù)包 的處理時刻,確定發(fā)送第一確認的第一發(fā)送時刻tl;
-在所述第一發(fā)送時刻tl傳送所述第一確認。
因此,使校正對于各發(fā)送器設備是特定的。事實上,它取決于有 關的流的特性及其在隧道中的活動性。
有利地,所迷第一發(fā)送時刻tl由tl = tO+RTO'-A定義,其中,
-to是在所述第一隧道端點中處理由于所述損失而被阻塞的所述
被識別的流的第 一個數(shù)據(jù)包之前的所述數(shù)據(jù)包的所述處理時刻;
-RTO'是與傳送所述給定的被識別的流的發(fā)送器設備相關聯(lián)的
重新傳送超時的持續(xù)時間的所述估計; -A是預定的安全裕度。 因而,第一發(fā)送時刻tl確定起來很簡單。
有利地,對于至少一個給定的被識別的流,所述產(chǎn)生并傳送至少 一個確認的步驟包含以下步驟的至少一次迭代
-確定發(fā)送新的確認的新的發(fā)送時刻t2,該新的發(fā)送時刻t2由t2 =tl+RTO' - A定義,這里,tl對于第一次迭代是所述的第一發(fā)送時刻, 或者,對于從第二次迭代開始的每次迭代,tl是在前一次迭代確定的 新的發(fā)送時刻t2;
-在所述新的發(fā)送時刻t2傳送所述新的確i人。
因此,作為預防,對于給定的被識別的流,在第一隧道端點中尋 求產(chǎn)生另一確認。由第一隧道端點產(chǎn)生的第一確認減輕隧道上的數(shù)據(jù) 包的簡單損失的影響,但是,必需設想隧道為了得到恢復而必須具有大于一個RTT的持續(xù)時間的情況。
因此,可以很容易地確定每個新的發(fā)送時刻t2。同樣,使校正對 于各發(fā)送器設備是特定的。
有利地RTO' = 2*RTT, RTT為隧道上的往返持續(xù)時間的測量結果。
因此,計算^^簡化。應注意,由于隧道的RTT遠大于LAN的 RTT,因此,用隧道的RTT的持續(xù)時間來近似發(fā)送器設備和接收器 設備之間的RTT的持續(xù)時間。
有利地,對于至少一個給定的被識別的流,在產(chǎn)生并傳送至少一 個確認的所述步驟中,僅當驗證以下的第一條件時產(chǎn)生并傳送確認 在隧道的傳輸信道上運送并由于所述損失而被阻塞的所述給定的被識 別的流的數(shù)據(jù)包的數(shù)量大于對于所述給定的被識別的流由所述第一隧 道端點產(chǎn)生和傳送的確認的數(shù)量。
由于發(fā)送器設備不接收任何比它已發(fā)送的數(shù)據(jù)包多的確認(例如, 在TCP中,僅可響應通過服務器傳送的數(shù)據(jù)包通過客戶機產(chǎn)生確認), 因此該第一條件確保了發(fā)送器設備(服務器)在保證與按數(shù)據(jù)包排序 并具有確認的傳輸協(xié)議(例如,TCP協(xié)議)的 一致性的方面的透明性。
有利地,對于至少一個給定的被識別的流,在產(chǎn)生并傳送至少一 個確認的所述步驟中,僅當驗證以下的第二條件時產(chǎn)生并傳送確認 對于所述給定的被識別的流由所述第一隧道端點產(chǎn)生并傳送的確認的 數(shù)量小于或等于對于傳送所述給定的被識別的流的發(fā)送器設備指示數(shù) 據(jù)包損失的預定的閾值。
因此,本發(fā)明防止發(fā)送器設備(服務器)將通過第一隧道端點產(chǎn) 生的連續(xù)確認的產(chǎn)生解釋為數(shù)據(jù)包損失,并因此防止發(fā)送器設備重新 傳送被假定為損失的數(shù)據(jù)包。
根據(jù)一個有利的特征,對于至少一個給定的被識別的流,該方法 包括過濾所述笫一隧道端點已對其產(chǎn)生并傳送了確認的所述給定的被 識別的流的經(jīng)由隧道從接收器設備到來的確認的步驟。
因此,在發(fā)送器設備(服務器)上管理通過第一隧道端點產(chǎn)生假想確認而引起的二次效果,以便不干擾進行中的連接的狀態(tài)機。例如,
如果遠程接收器設似客戶機)由于遠程LAN上的輕微亂序而發(fā)出"真 實的"重復確認(重復ACK),并且如果第一隧道端點已產(chǎn)生并發(fā)出 一個或兩個"假想的"重復確i人,則必須過濾(即,檢測并破壞)該"真 實的"重復確認,使得發(fā)送器設備(服務器)不接收會導致其處于重新 傳送模式的第三重復確認(使得TCP發(fā)送器窗口功能下降,這是要避 免的)。
在另 一實施例中,本發(fā)明涉及可從通信網(wǎng)絡下載和/或記錄在計算 機可讀載體上和/或可由處理器執(zhí)行的計算機程序產(chǎn)品。該計算機程序 產(chǎn)品包含用當在計算機上執(zhí)行所述程序時實現(xiàn)上述的方法(其不同的 實施例中的一個中的方法)的程序代碼指令。
在另 一實施例中,本發(fā)明涉及存儲計算機程序的計算機可讀存儲 介質(zhì),該計算機程序包含可由計算機執(zhí)行以便實現(xiàn)上述方法(其不同 的實施例中的任一個中的方法)的一組指令。
在一個特定的實施例中,本發(fā)明提出一種第一隧道端點,該第一 隧道端點使得能夠管理隧道的傳輸信道上的數(shù)據(jù)流的傳送,各流的傳 送是根據(jù)由數(shù)據(jù)包調(diào)度并具有確認的傳輸協(xié)議而在所述傳輸信道上執(zhí) 行的,該隧道是在分別與第一和笫二子網(wǎng)連接的所述第一隧道端點和 第二隧道端點之間實現(xiàn)的,各流是從發(fā)送器設備向接收器設備傳送的, 所述發(fā)送器設備和所述接收器設備中的一個設備與第一子網(wǎng)連接,并 且另一個與第二子網(wǎng)連接。所述第一隧道端點包含
-用于檢測隧道的傳輸信道上的數(shù)據(jù)包的損失的裝置; -用于識別具有由于所述損失而在隧道的傳輸信道上被阻塞的至
少一個數(shù)據(jù)包的至少一個流的裝置;
-用于對于至少一個被識別的流產(chǎn)生至少一個確認,并將其傳送 給在隧道上傳送了由于所述損失而被阻塞的數(shù)據(jù)包的發(fā)送器設備的裝 置。
有利地,對于至少一個給定的被識別的流,所述至少一個產(chǎn)生的 確認是對所述被識別的流的由于所述損失而被阻塞的第 一 個數(shù)據(jù)包之前的數(shù)據(jù)包的確認。對于已檢測到其損失的數(shù)據(jù)包所屬的被識別的流,由于所述損失而被阻塞的第 一個數(shù)據(jù)包被視為是在檢測到損失之后在隧道的傳輸信道上重新傳送的數(shù)據(jù)包。
有利地,所述用于產(chǎn)生并傳送至少一個確認的裝置包含-用于對于至少一個給定的被識別的流,根據(jù)與傳送所述給定的被識別的流的發(fā)送器設備相關聯(lián)的重新傳送超時的持續(xù)時間的估計,并且,根據(jù)由所述隧道端點處理由于所述損失而被阻塞的所述被識別的流的第一個數(shù)據(jù)包之前的所述數(shù)據(jù)包的處理時刻,確定發(fā)送第一確認的第一發(fā)送時刻tl的裝置;
-用于在所述第一發(fā)送時刻tl傳送所述第一確認的裝置。因此,使校正對于各發(fā)送器設備是特定的。事實上,它取決于有關的流的特性及其在隧道中的活動性。
有利地,所述第一發(fā)送時刻tl由tl - t0+RTO' - A定義,其中,-t0是在所述第一隧道端點中處理由于所述損失而被阻塞的所述被識別的流的第 一 個數(shù)據(jù)包之前的所述數(shù)據(jù)包的所述處理時刻;
- RTO'是與傳送所述給定的被識別的流的發(fā)送器設備相關聯(lián)的重新傳送超時的持續(xù)時間的所述估計;
- A是預定的安全裕度。
有利地,用于產(chǎn)生并傳送至少一個確認的所述裝置包含被激活至少一次的以下裝置
-用于對于至少一個被識別的流確定發(fā)送新的確認的新的發(fā)送時刻t2的裝置,該新的發(fā)送時刻t2由t2-tl+RTO'-A定義,其中,tl對于第一次迭代是所述的第一發(fā)送時刻,或者,對于從第二次迭代開始的每次迭代,tl是在前一次迭代確定的新的發(fā)送時刻t2;-用于在所述新的發(fā)送時刻t2傳送所述新的確認的裝置。有利地RTO'-2.RTT, RTT為隧道上的往返持緣時間的測量結果。
有利地,所述第一隧道端點包括
-第一驗證裝置,該第一驗證裝置用于對于至少一個給定的被識別的流驗證以下的第一條件在隧道的傳輸信道上運送并由于所述損失而被阻塞的所述給定的被識別的流的數(shù)據(jù)包的數(shù)量大于對于所述給定的被識別的流由所述第一隧道端點產(chǎn)生和傳送的確認的數(shù)量;
-用于如果所述第一驗證裝置做出肯定的驗證則對于所述至少一個給定的被識別的流激活用于產(chǎn)生并傳送至少一個確認的所述裝置的裝置。
有利地,所述第一隧道端點包括
-第二驗證裝置,該第二驗證裝置用于對于至少一個給定的被識別的流驗證以下的第二條件對于所述給定的#>識別的流由所述第一隧道端點產(chǎn)生并傳送的確認的數(shù)量小于或等于對于傳送所述給定的被識別的流的發(fā)送器設備指示數(shù)據(jù)包損失的預定的閾值;
-用于如果所述第二驗證裝置做出肯定的驗證則對于所述至少一個給定的被識別的流激活用于產(chǎn)生并傳送至少 一 個確認的所述裝置的裝置。
根據(jù)一個有利的特征,所述第一隧道端點包括,對于至少一個給定的被識別的流,過濾所述第一隧道端點已對其產(chǎn)生并傳送了確認的所述給定的被識別的流的經(jīng)由隧道從接收器設備到來的確認的裝置。
從通過指示性而非詳盡的例子給出的以下說明和附圖,本發(fā)明的實施例的其它特征和優(yōu)點將顯現(xiàn),其中,
圖l示出實現(xiàn)隧道的虛擬專用網(wǎng)絡(VPN)的典型配置;
圖2示出可實現(xiàn)本發(fā)明的方法的隧道端點的經(jīng)典分層模型的示
例;
圖3示出運送第2級隧道數(shù)據(jù)包的以太網(wǎng)幀的經(jīng)典格式的示例;圖4是參照在圖1中描述的環(huán)境應用本發(fā)明的特定實施例的情景的示意圖5示出根據(jù)本發(fā)明的特定實施例的數(shù)據(jù)結構的不同表格;
圖6呈現(xiàn)出在檢測隧道的傳送錯誤時執(zhí)行的算法,該算法被包含于本發(fā)明的校正方法的特定實施例中;
圖7示出在接收來自該隧道的、對于該隧道的乘客TCP流的確認
時執(zhí)行的算法,該算法被包含于本發(fā)明的校正方法的特定實施例中;圖8示出用于產(chǎn)生確認消息并將其發(fā)送給服務器的算法,該算法
被包含于本發(fā)明的校正方法的特定實施例中;
圖9提供實現(xiàn)本發(fā)明的特定實施例的算法的隧道端點101的PEP
系統(tǒng)的功能體系結構的示意圖10示出適于實現(xiàn)本發(fā)明的特定實施例的一般通信設備的示意
性配置。
具體實施例方式
在本發(fā)明的所有附圖中,相同的元件和步驟由相同的附圖標記表示。
圖1示出通過通信網(wǎng)絡107 (例如因特網(wǎng))在本地隧道端點101和遠程隧道端點102之間實現(xiàn)隧道100的虛擬專用網(wǎng)絡(VPN)的典型配置。該隧道100連接兩個局域網(wǎng)LAN A 103和LAN B 104。 LAN103和104中的每一個具有高比特率因特網(wǎng)訪問裝置(能夠集成防火墻的家用網(wǎng)關)105和106、 PC型裝置109和111、用于存儲和分配數(shù)字媒體(音頻、視頻和照片類型)的服務器110和113、以及數(shù)字媒體呈現(xiàn)裝置108和112。隧道端點可被集成到諸如數(shù)字電視機之類的視聽裝置中。它還可以以執(zhí)行與其相關的功能的程序的形式存在于PC型裝置中。
一旦隧道100被構建,連接到LAN A 103的裝置108、 109和110就能夠與連接到LANB 104的裝置111、 112和113進行通信。例如,連接到LAN A 103的客戶機108可以與連接到網(wǎng)絡LANB 104的服務
器113進行通信。
該圖1示出僅具有一個隧道的簡單通信網(wǎng)絡,但是應該理解,同一隧道端點可能必須管理若干個隧道(一直到隧道端點的等同數(shù)量)以使第一LAN與若干個其它的LAN互連。此外,為了簡化,附圖沒有示出諸如因特網(wǎng)路由器之類的因特網(wǎng)中的基礎結構裝置。
參照圖2,現(xiàn)在將描述來自裝置108、 109和110中的一個(與 LAN A103連接)并將進入隧道100的以太網(wǎng)幀的路由。為此,將使 用分層模型。該分層模型描述實現(xiàn)該隧道100所需要的協(xié)議層。在該 模型中,未表現(xiàn)隧道的使用以外的功能所需要的協(xié)議元素。例如,當 隧道端點IOI被集成到UPnP裝置中時與UpnP體系結構相關聯(lián)的協(xié)
i義元素; 殳有^皮示出o
隧道端點101具有以太網(wǎng)物理接口 208,所述以太網(wǎng)物理接口 208 將來自裝置108、109和110的以太網(wǎng)幀移交到用于路由的鏈路層207: 對于意圖用于包含隧道端點的裝置的以太網(wǎng)幀,該路由是朝向網(wǎng)絡層 206進行的,或者,對于其它的以太網(wǎng)幀,該路由是朝向橋接層209 進行的。橋接層209實施以太網(wǎng)橋的經(jīng)典操作,諸如過濾以太網(wǎng)幀和 將這些幀中繼到一個或多個適當?shù)囊蕴W(wǎng)輸出端口。該橋具有以太網(wǎng) 接口 207和連附到其上的模擬以太網(wǎng)控制器的至少一個虛擬接口 210。 對于由應用200實例化的每個隧道創(chuàng)建虛擬接口 210,將必須在分別 實例化的隧道上運送行進的以太網(wǎng)幀給予所述虛擬接口。 一般地,用 于由應用200表示的隧道的封裝的協(xié)議執(zhí)行實現(xiàn)每個隧道所必需的操 作,其中特別是配置、過濾和封裝(隧道數(shù)據(jù)包的形成)以及幀的提 取的操作。 —
被應用200處理之后從虛擬接口 210被接收的幀通過應用接口或 套接層201以數(shù)據(jù)包的形式被移交給分別由SSL協(xié)議202和DTLS協(xié) 議204確保的可靠的TCP傳輸協(xié)議203或不可靠的UDP傳輸協(xié)議 205。
術語"可靠的傳輸模式,,或"可靠的傳輸協(xié)議,,被理解為指的是這樣 的傳輸模式或協(xié)議,對于該傳輸模式或協(xié)議,發(fā)送幀或數(shù)據(jù)包的設備 在向接收器設備傳送幀或數(shù)據(jù)包時獲得 一 條信息。這種模式的主要特 征是,確保幀或各條數(shù)據(jù)的傳輸而不是發(fā)送器設備和接收器設備之間 的傳送的等待時間。以下,術語"可靠的信道"將被理解為指的是,用
、S隧道的數(shù)據(jù)的信道(該數(shù)據(jù)自身可根據(jù)確定的傳輸協(xié)議而采取數(shù)據(jù)包 或幀的形式)。
在通過傳輸協(xié)議進行處理以形成隧道數(shù)據(jù)包250 (圖3)之后,該 數(shù)據(jù)包被轉(zhuǎn)到網(wǎng)絡層126?,F(xiàn)在可通過鏈路層207和物理層208在LAN 上傳輸這樣用當前的數(shù)據(jù)包形成的IP數(shù)據(jù)報。
對來自隧道100的幀的接收將遵循與以上呈現(xiàn)出的路徑相反的隧 道端點中的路徑。
圖3示出例如在圖1的LAN A 103上運送的以太網(wǎng)幀(附圖標記 260)的經(jīng)典格式的示例,該以太網(wǎng)幀包含
-以太網(wǎng)標題字段(附圖標記261);
-第一IP數(shù)據(jù)報(附圖標記262 )自身,其傳送第2級隧道數(shù)據(jù) 包(附圖標i己250 );和
-FCS (幀檢查序列)字段(附圖標記263)。 隧道數(shù)據(jù)包250具有四個部分
-傳輸協(xié)議標題字段251 (即,本示例中的TCP或UDP字段); -封裝協(xié)議252的標題字段(即,特別是在以下的文獻"IETF
RFC3931, "Layer two tunneling protocol - version 3 (L2TPv3)", J.
Lau and all, March 2005"和"IETF RFC2246,"The TLS Protocol
Version l.O"中描述的本示例中的L2TP或TLS );
-乘客協(xié)議253的標題字段(即,本示例中的以太網(wǎng));最后是 -用戶數(shù)據(jù)字段254,如果在從源裝置運送的過程中沒有發(fā)生破
碎(fragmentation ),那么該用戶數(shù)據(jù)字段254自身包含第二完全IP
數(shù)據(jù)報。
圖4是參照在圖1中描述的環(huán)境應用本發(fā)明的特定實施例的情景 的示意圖。
以下根據(jù)在隧道端點101上的定位來描述本發(fā)明的本特定實施例 的算法。事實上,任何隧道端點都能夠執(zhí)行本發(fā)明。但是,建立本發(fā) 明的算法的隧道入口隧道端點將僅僅關注于通過TCP隧道從本地 LAN接收的意圖用于遠程LAN的TCP數(shù)據(jù)。在圖4所示的情況下,隧道端點TEP 101分析從LAN(本地LAN) 103發(fā)送以便進入隧道中的、意圖用于(遠程)LAN 104的TCP數(shù)據(jù) 以及對于該TCP數(shù)據(jù)從LAN 104接收的確認。
在該示例中,兩個媒體服務器110-A和110-B位于LAN 103中, 并且,這些服務器的兩個客戶機設備112-A和112-B位于局域網(wǎng)104 中。為了澄清本示例的說明,應注意,數(shù)據(jù)包的索引(index)的概念 與發(fā)送數(shù)據(jù)包的發(fā)送次序?qū)?數(shù)據(jù)包的索引i表示數(shù)據(jù)包是第i個 數(shù)據(jù)包),并且不具有通信協(xié)議中的任何實際意義(與集成到各TCP 數(shù)據(jù)包中的序號不同)。
對于TCP數(shù)據(jù)包將使用以下的符號
-標注"i"的數(shù)據(jù)包410:索引為i的數(shù)據(jù)段TCP (即,對于數(shù)據(jù) 序號n由LAN 103的服務器110-A和110-B中的一個發(fā)送的第i個數(shù) 據(jù)包);
-標注"Ri"的數(shù)據(jù)包413:與具有相同的索引"i"的數(shù)據(jù)包410相 同但是已通過相同的數(shù)據(jù)序號n被重新傳送的TCP數(shù)據(jù)段;
-標注"Ai"的數(shù)據(jù)包411:對于數(shù)據(jù)序號n的數(shù)據(jù)包"i"或"Ri"的 TCP確認(因此,根據(jù)TCP協(xié)議,該數(shù)據(jù)包411包含確認序號n+l); 該確認411被LAN 104的客戶機發(fā)出到LAN 103的服務器;
-標注"Di"的數(shù)據(jù)包412:對于數(shù)據(jù)序號n的數(shù)據(jù)包"i"或"Ri"的 TCP確認(因此,根據(jù)TCP協(xié)議,該數(shù)據(jù)包411包含確認序號n+1); 該確認412被TEP隧道端點101 (根據(jù)本發(fā)明的機構,參見圖6和8) 發(fā)送到LAN 103的服務器。確認412是經(jīng)典的確認(可被復制然后被 服務器視為"重復ACK")或選擇性的確認SACK (在附錄中詳細描述 這兩種類型的確認)。
通過由數(shù)據(jù)包"Ai"411確認的數(shù)據(jù)包"i"410形成經(jīng)典的TCP連接。
在圖4的例子中,因此,隧道對于兩個不同的TCP連接,從LAN 103向LAN 104發(fā)送數(shù)據(jù)的數(shù)據(jù)包410,并且從LAN 104向LAN 103 發(fā)送確認數(shù)據(jù)包411:-在服務器110-A和接收器112-A之間建立的連接A (該連接A 的數(shù)據(jù)包由包含上述的符號"i"、 "Ri"、 "Ai,,和"Di"的方形表示);
-在服務器110-B和接收器112-B之間建立的連接B (該連接B 的數(shù)據(jù)包由包含上述的符號"i"、 "Ri"、 "Ai"和"Di"的圓形表示)。
隧道端點TEP 101被認為能夠利用用于知曉隧道上的傳送的調(diào)度 和日期的時間指示來保留在隧道上運送的數(shù)據(jù)包410和411的序號(在 實際中,索引i的段410的蹤跡被一直被保留,直到接收到與其對應 的確認411)。此外,在隧道的載體的數(shù)據(jù)包和乘客流的數(shù)據(jù)包之間 進行數(shù)據(jù)序號的關聯(lián)(以下規(guī)定),以便容易地識別隧道栽體的各數(shù) 據(jù)包(載體數(shù)據(jù)包)的內(nèi)容。
對于信息,隧道端點TEP 101管理在隧道上發(fā)送的TCP段的表 格501 (以下參照圖5描述該表格501)。
階段4-l:對隧道上的錯誤的檢測
該階段與隧道上檢測錯誤的時間對應。例如,三個重復確認(重 復ACK)420已被隧道端點TEP102發(fā)送以指示隧道的數(shù)據(jù)包的損失。 自動地,在接收到同一數(shù)據(jù)序號k的三個重復ACK之后(因此根據(jù) 具有確認序號k+l的TCP協(xié)議),隧道的TCP協(xié)議層將重新傳送丟 失的載體數(shù)據(jù)包。同時,在隧道端點TEP101上觸發(fā)報警,以便確定 由具有數(shù)據(jù)序號k的栽體數(shù)據(jù)包傳輸?shù)臄?shù)據(jù)的性質(zhì)。
在圖4的示例中,具有數(shù)據(jù)序號k數(shù)據(jù)包的載體數(shù)據(jù)包與流110-A 到112-A (連接A)的索引3的數(shù)據(jù)包410對應。該隧道因此進入重 新傳送,以運送該數(shù)據(jù)(數(shù)據(jù)包"R3")。
然后,隧道端點TEP 101確定在遠程隧道端點102的TCP協(xié)議 層中被阻塞的那些數(shù)據(jù)段410:這是在連接A的索引3的數(shù)據(jù)包410 之后已在隧道上被發(fā)送的局域網(wǎng)103的所有數(shù)據(jù)包410。
在該示例中,確定的數(shù)據(jù)包410如下
-對于連接A,索引大于3的所有數(shù)據(jù)包;
-對于連接B,索引大于2的所有數(shù)據(jù)包(連接B的索引2先于 連接A的索引3的數(shù)據(jù)包的發(fā)送)。在接收到三個重復ACK之后,即,在隧道端點TEP 101和隧道 端點TEP102之間的一個隧道往返時間(RTT)之后,進行隧道中的 錯誤的檢測。這是為何可在圖4中看到,對于由遠程客戶機接收的非 阻塞數(shù)據(jù)包,隧道上的索引R3的數(shù)據(jù)包413的傳送(損失的那條數(shù) 據(jù)的重新傳送)大致與對于確認411的與LAN 103相反的傳送一致的 原因。
因此,這意味著連接A和B的隨后的序列的將來的確認將僅在服 務器和客戶機之間的一個往返時間之后在LAN 103上被接收(由于隧 道的RTT遠大于LAN103和104中的每一個的RTT,因此這近似于 隧道上的另一往返時間)。
這就是為何下一階段4-2的目標是施加防止性校正(通過隧道端 點TEP 101產(chǎn)生確認412 )以防止服務器TCP lll-A和110-B的超時 RTO的期滿的現(xiàn)象的原因,并且,將使該4交正對LAN 103的各服務 器IIO-A和IIO-B特定。
階段4-2:對于超時RTO的期滿的問題施加校正
該階段可被細分成兩個步驟4-2a和4-2b: —個階段(4-2a )用于 計算用于發(fā)送確認消息412的超時,另一階段(4-2b)在該超時時段 期滿時產(chǎn)生確認消息412的發(fā)送。
因此,對于隧道的各乘客流,該方法確定隧道端點TEP101處理 第一個阻塞數(shù)據(jù)包410的日期TO(對于與信道上的重新傳送有關的流, 在重新傳送中,第一個阻塞數(shù)據(jù)包被視為數(shù)據(jù)包410)。
在隧道的RTT的連續(xù)測量之后,對于各流,該方法確定對確認消 息412的傳送進行規(guī)劃的日期tl。該日期tl與(tO+2'RTT-A)對應, 其中,A是若干毫秒的安全裕度。可以回想,與各服務器110-A、 110-B 的RTO對應的時段的持續(xù)時間基本上等于2 隧道的RTT,并且, 本發(fā)明的防止性校正包含在各服務器的RTO期滿之前向各服務器發(fā) 送確i人消息412,以將該RTO復位為零并由此防止其期滿。
因此,在超時表格510 (參見圖5)中記錄輸入,該輸入包含產(chǎn)生 對于服務器IIO-A和110-B的確認消息412所需要的信息。
26如果阻塞在隧道中持續(xù),那么還優(yōu)選確定一個或更多個第二超時
時段,以確定用于向有關的服務器TCP IIO-A、 110-B發(fā)送其它確認 消息412的一個或更多個日期t2。 一旦接收到由客戶機112-A、 112-B 發(fā)起的、來自遠程LAN104并被隧道運送的真實確認410,隨后的超 時周期就被消除(不存在由隧道端點TEP 101產(chǎn)生的確認消息412的 隨后的發(fā)送)。
此外,與產(chǎn)生的確認消息412對應的、由客戶機112-A、 112-B 發(fā)起的真實確認411被過濾,以便不發(fā)送太多的確認消息。事實上, 例如,三個重復確認("重復ACK")的累積會導致服務器通過分析斷 定在網(wǎng)絡中出現(xiàn)了錯誤,這是要避免的。
現(xiàn)在參照圖5,呈現(xiàn)出數(shù)據(jù)結構的各種表格550、 501、 510和520。 各數(shù)據(jù)流由其源IP地址、其源TCP端口以及其目的地IP地址及其目 的地TCP端口表征。必須注意,由于TCP通信是雙向通信,因此同 一 TCP會話可運送兩個數(shù)據(jù)流。以下通過非詳盡的示例描述各表格。
表格550是隧道端點上的活動流的表格。術語"活動流"在這里被 理解為是指與建立的未關閉的TCP會話相關的流。該表格550包含
-字段551,該字段551對于每個流4戈表纟皮分配給該流的唯一標 識符,并用作相對于流的其它數(shù)據(jù)結構的參考;
-字段552和554,其分別表示TCP會話的源和目的地IP地址;
-字段553和555,其分別表示TCP會話的源和目的地端口 ;
-字段556,其與由連接支持的確認消息的類型對應。例如,經(jīng) 典類型的確認(ACK)或選擇型確認(SACK)。
表格501表示在隧道上傳送的、與表格550的各活動流的TCP數(shù) 據(jù)包410有關的各條數(shù)據(jù)。在該表格中,對于在隧道上被傳送并且還 沒有被確認的乘客流的每個TCP數(shù)據(jù)包,存在一個輸入。該表格501 包含
-字段502,其表示由隧道端點101處理TCP段/數(shù)據(jù)包的日期 t0,諸如例如在隧道中發(fā)送TCP段/數(shù)據(jù)包的日期(近似地,當忽略 封裝數(shù)據(jù)包410所需要的時間時,可以用通過隧道端點接收來自本地LAN的數(shù)據(jù)包410的日期標識該值); -字段503,其表示流標識符551;
-字段504,其表示乘客流數(shù)據(jù)包的數(shù)據(jù)序號n,即對于有關的流 551、來自LAN的、由隧道端點IOI接收的TCP數(shù)據(jù)序號(TCP數(shù) 據(jù)包410,即,乘客段);
-字段505,其表示隧道的載體的載體數(shù)據(jù)包的數(shù)據(jù)序號k,即運 送以504表示的乘客段(TCP數(shù)據(jù)包410)的數(shù)據(jù)包的載體(載體數(shù) 據(jù)包)的TCP數(shù)據(jù)序號。
表格510表示用于隨后產(chǎn)生確認消息412的超時值存儲表格。在 該表格中,對于每個規(guī)劃的傳送,存在一個輸入。該表格510包含
-字段512,其表示必須產(chǎn)生確認消息412的期滿的日期(例如,
tl);
-字段513,其表示流標識符551;
-字段514,其表示對于同一流標識符(字段503 (表格501)和 551 (表格550 )),確認記錄在表格501 (字段504 )中的數(shù)據(jù)序號"n,, (n=j-l)的確認序號"j"。因此,根據(jù)TCP協(xié)議,字段514包含確認 序號"j"(表示確實已接收到數(shù)據(jù)序號"j-l"并且等待數(shù)據(jù)序號"j")。
表格520是用于為對于各流產(chǎn)生的確認消息412進行計數(shù)的表格。 該表格520包含
-字段522,其表示流標識符513;
-字段523,其表示確認序號514。在實際中,表格520對于每個 流513僅保持與所產(chǎn)生的最后的確認412對應的一個條目(起初對于 之前的段產(chǎn)生的確認412不再具有任何重要性,這是因為它們確認更 小的數(shù)據(jù)序號,并且,當前的所產(chǎn)生的最后的確認根據(jù)TCP協(xié)議的調(diào) 度的確認協(xié)議固有地確認所有之前的段);
-字段524,其表示對于有關的流522的上述確認序號523,由隧 道端點產(chǎn)生的確認消息412的數(shù)量;
-字段525,其表示對于有關的流522的上述確認序號523,通過 隧道由隧道端點接收并來自遠程客戶機112-A或112-B的確認消息411的數(shù)量。
圖6示出在檢測在隧道端點TEP (例如101)上實現(xiàn)的隧道的傳 送錯誤時執(zhí)行的算法,該算法被包含于本發(fā)明的校正方法的特定實施 例中。
隧道端點TEP 101監(jiān)管穿過隧道的活動連接的數(shù)據(jù)流。 優(yōu)選地,在管理隧道100上的乘客TCP流的路由的隧道端點TEP 的情境下進行描述,即,隧道端點TEP101能夠識別將在隧道中行進 的、其輸入端口上的TCP流。例如,可合理地考慮兩種類型的TCP 流與主要的(且特別持久的)傳送對應的那些TCP流以及控制流(少 數(shù)往返消息)。因此,本發(fā)明的特定實施例僅考慮第一種類型的TCP 流這使得能夠?qū)崿F(xiàn)可從中受益的流的帶寬的分配。可例如通過隧道 端點TEP接收i者如UPnP、 QoS或SBM詢問之類的業(yè)務QoS詢問或 與在其中一個LAN中上活動的任何其它QoS協(xié)議有關的詢問的質(zhì)量, 檢測這些流。關于流的優(yōu)先級詢問使得能夠知曉這些流的性質(zhì)在 IEEE802.1Q標準中,優(yōu)先級4 6分別與流式傳送、視頻傳送和音頻 傳送對應。這些QoS詢問順序地攜帶對TCP流的識別所需要的所有 參考(源和目的地地址、端口、協(xié)議)。很顯然,在提出的示例中, 僅考慮TCP傳送協(xié)議流。
此外,在對打開TCP連接(具有SYN標記的TCP數(shù)據(jù)包,參見 附錄)進行檢測時,應用協(xié)議的更深的分析提供傳送特性的知識例 如,攜帶http應用協(xié)議(253 )的TCP流包含表示所請求的媒體的類
型的信息(對于具有MIME型"video/mpeg"的視頻為h ttp GET消息)。 作為非詳盡的示例給出這些示例。
在本發(fā)明的一個特定實施例中,被視為這樣的情況其中,在沒 有隧道端點TEP 101的任何管理控制的情況下在隧道中運送以上指定 的沒有被識別的任何其它TCP流。這具有這樣的優(yōu)點為非常重要的 流保持隧道端點TEP101的可用處理器和存儲器資源。很顯然,在一 個變型例中,本發(fā)明的方法適用于穿過隧道的所有TCP流。
在另一特定實施例中,由各TCP連接使用的確認的類型也被確定。SACK擴展(符合文件RFC2018)在TCP消息中使用兩個任選 的字段。第一字段是當啟動連接時在TCP SYN段中生效或不生效的 "SACK容許,,激活選項,其表示隨后使用SACK機構的可能性。第二 選項是SACK選項,如果當建立TCP連接時被授權,則該SACK選 項在對于選擇性確認的傳送期間生效。
在新TCP連接的各打開/關閉時定期更新流的表格550 (參見圖 5)。此外,表格501 (參見圖5)在參照圖l描述的環(huán)境情境中管理 例如由TCP客戶機-服務器對(110-A和112-A)接收的數(shù)據(jù)段和確認。
本發(fā)明的目的不是對填寫表格550的方式要求權利。存在針對此 目的的若干個現(xiàn)有技術。
對于所考慮的流,隧道端點TEP 101保持(表格501)穿過隧道 端點TEP101的數(shù)據(jù)(DATA)的數(shù)據(jù)段(數(shù)據(jù)包)的TCP序號。這 意味著,在任何時間,隧道端點TEP101均知曉在隧道中^皮發(fā)送并且 沒有被確認的數(shù)據(jù)包的數(shù)量(飛行尺寸(flightsize))。
此外,隧道端點獲得對隧道的TCP信道開放的網(wǎng)絡連接器或套接 層的特性(例如,通過使用使得能夠使其知曉隧道中的錯誤的 API"Unix Socket Interface" ) 。 API意味著"應用編程界面"。
優(yōu)選地,為了填寫表格501,由隧道端點TEP 101>使用#~改的TCP 協(xié)議堆棧?;蛘呤菂f(xié)議堆棧,直接在通過隧道端點TEP 101的路由功能 接收用于在隧道上發(fā)送乘客流的數(shù)據(jù)的命令期間更新表格501,或者 是反過來對于通過API"Unix Socket Interface"發(fā)送數(shù)據(jù)的命令指示 隧道的TCP數(shù)據(jù)序號的一條附加信息,并且,由隧道端點TEP自身 來更新表格501。
當在隧道中檢測到錯誤時,API"Unix Socket Interface"能夠警告 本發(fā)明的算法,特別是能夠重新激活圖6的步驟600。應注意,隧道 TCP自身管理損失數(shù)據(jù)包的重新傳送。
步驟601包含從表格501以及從隧道的TCP載體的損失數(shù)據(jù)包的 數(shù)據(jù)序號(標識符505 )的知識確定有關的乘客流(標識符503 )和通 過TCP栽體的損失數(shù)據(jù)包傳輸?shù)倪\送的數(shù)據(jù)包410的數(shù)據(jù)序號(號碼504)。
在步驟602中,再次基于表格501,對于在隧道上運送的各其它 流,本發(fā)明確定在步驟601中確定的數(shù)據(jù)包410之后發(fā)送的第一個數(shù) 據(jù)序號。其為這樣的數(shù)據(jù)序號,將對所述數(shù)據(jù)序號應用產(chǎn)生朝向它們 的相對TCP服務器的本發(fā)明的消息的原理。
在步驟603中,可對以上指定的那些合格的乘客TCP流中的乘客 TCP流進行選擇性調(diào)度,并且,對于步驟604和605的執(zhí)行,僅逐一 地考慮所選擇的流。如果不是,那么對于步驟604和605的執(zhí)行,逐 一地考慮所有先前確定的流。
幾個選項對于調(diào)度是可能的
-較慢的開始階段中的TCP流(參見附錄)被認為具有優(yōu)先級, 這是由于它們的擁塞窗口在限制(SSTHRESH)先驗未知的該階段中 更加明顯地增加;
-優(yōu)選地,本發(fā)明避免TCP流在穩(wěn)定化的階段(這是擁塞避免階 段,參見附錄)中經(jīng)受小窗口尺寸。窗口的小型化將具有效果,但僅 是一點點效果;
-可以使用由客戶機發(fā)送的設備窗口 (或告知窗口,參見附錄) 的值以知曉提出用于增加比特率的最寬裕度的流;
-被認為具有優(yōu)先級的流是已在非常接近在601確定的乘客滇的 時間跨度中已發(fā)送數(shù)據(jù)(即,已在隧道上經(jīng)受重新傳送)的那些流。 應注意,在601確定的流是將被應用本發(fā)明的校正算法的第一個流。
步驟604被用于確定朝向TCP服務器發(fā)送根據(jù)本發(fā)明產(chǎn)生的確認 消息412的第一發(fā)送日期tl (第一超時)。
在步驟605中,在規(guī)劃派遣表格510中規(guī)劃確f人消息412的發(fā)送。
我們會注意確定第一傳送日期tl的特定方面。如參照圖8的步驟 807詳細描述的那樣,隨后可能規(guī)劃第二傳送日期t2 (第二超時)。
對于應用步驟604和605的隧道的各乘客流,確i人消息412的第 一傳送日期tl大大取決于隧道的RTT的連續(xù)測量的值(所有的乘客 流共用的參數(shù))以及隧道端點101處理所考慮的乘客流的第一個阻塞數(shù)據(jù)包的日期to (對每個流有一個特有的日期to)。因此,使第一超
時的激活對于每個流是特定的,并與流的激活協(xié)調(diào),以盡可能具有最 小的侵擾性。
可以回想,對于確認消息412的產(chǎn)生(圖8的算法的激活)進行 規(guī)劃的第一傳送日期tl被獲得如下tl=tO+2.RTT-A,其中,A是若干 毫秒的安全裕度(例如,隧道RTT的10%)。
圖7示出在例如隧道端點TEP ( 101)中實現(xiàn)的、接收來自該隧 道的、對于該隧道的乘客TCP流的確認時執(zhí)行的算法,該算法被包含 于本發(fā)明的校正方法的特定實施例中。
在步驟700中,隧道端點TEP 101 ;故警告從乘客連接接收TCP 確認消息(例如,關于圖4,在由服務器110-A派遣段410之后來自 客戶機112-A的確認411)。
在步驟701中,在接收到與通過隧道發(fā)送的一個或更多個段數(shù)據(jù) 序號(數(shù)據(jù)包)410對應的來自客戶機112-A的確認411之后,對于 該確i人411進4于分沖斤。該確認411也可以是經(jīng)典的確i人(符合文件 RFC793)或是SACK型(符合文件RFC2018)。在兩種情況下,對 于有關的流,在表格501中確定輸入,所述輸入的數(shù)據(jù)序號504具有 小于或等于在確認411中指示的確認序號的值。然后,從表格501消 除這樣確定的所有條目。即使確認411是SACK型,并且表示對于某 些序號發(fā)生了傳送錯誤,也考慮由SACK型消息報告的確認序號;這 意味著直到該(最大)確認序號的所有數(shù)據(jù)包410已被局域網(wǎng)上的隧 道端點TEP102傳送,但顯然具有損失。
在步驟702中,在表格510中進行搜索,所述搜索表示是否對于 有關的流遵循了本發(fā)明的校正過程(即,是否已執(zhí)行圖6的步驟605)。 在確定具有字段513的該表格的條目與運送確認411的當前連接的標 識符對應的情況下,則屬于遵循了本發(fā)明的校正過程的情況。
如果檢驗702是否定的,那么操作直接轉(zhuǎn)到步驟705。如果檢驗 702是肯定的,則在步驟703中提煉搜索,驗證確認411的確認序號 與所應用的校正措施具有一個比率。如果存在與由確認411確認的序列對應的還滿足字段準則514的表格510的條目,那么執(zhí)行步驟704。 如果采取SACK選項,那么必須相當平等地在確認411的確認的序列 的SACK消息列表中(肯定的確認與不使用SACK選項的經(jīng)典情況對 應)或在錯誤序列的(SACK消息的)列表中包含字段514 (在這種 情況下, 一段已損失并且必須通知服務器)。
步驟704包含擦除在超時的列表510中規(guī)劃的條目,以便停止檢 測到隧道上的損失之后的校正測量。然后,操作轉(zhuǎn)到步驟705。
步驟705的檢驗被用于求證是否過去對當前的乘客流采取了校正 措施,以便不使產(chǎn)生確認消息412之后的該TCP連接不穩(wěn)定(對于產(chǎn) 生,參照圖8)。進行搜索以求證是否在用于對由本發(fā)明產(chǎn)生的確認 消息412進行計數(shù)的表格520中識別該流。
如果檢驗705是否定的,那么不對將在LAN 103上正常發(fā)送的確 認411執(zhí)行過濾(步驟708 )。
如果檢驗705是肯定的,那么執(zhí)行步驟706的檢驗,以求證確認 411是否確i人已在LAN 103上對其產(chǎn)生確認412的段。
如果檢驗706的結果是否定的,那么進行檢查(步驟707的檢驗), 以求證確i人消息411是否確認比由記錄在表格520中的確認序號確^人 的數(shù)據(jù)序號大的數(shù)據(jù)序號。換句話說,進行檢查,以求證確認411是 否確認包括表格520中所考慮的數(shù)據(jù)段的若干個數(shù)據(jù)段410。如果檢 驗707的結果是肯定的,那么表格520中的當前輸入被消除(步驟 711),并且,將在LAN103上正常發(fā)送確認411 (步驟708)。如果 步驟707是否定的,那么操作直接轉(zhuǎn)到步驟708。
如果檢驗706的結果是肯定的,那么當前確認411正好與由本發(fā) 明產(chǎn)生的確認412對應(參見圖8)。確認411的接收的統(tǒng)計數(shù)據(jù)#皮 更新(在步驟709中使字段525遞增),并且進行檢查以求證是否可 以在LAN103上沒有問題地中繼當前確認411 (步驟710的檢驗)。
因此,只要它還沒有接收到比產(chǎn)生的確認412更多的確認411(檢 驗710是否定的),確認411就被破壞(用步驟712的過濾)。如果 接收到更多的確認411 (檢驗710的結果是肯定的),那么意味著本
33發(fā)明已在TCP服務器110將接收的確認的數(shù)量上恢復平衡,并且,可 以采取消除由產(chǎn)生"假想的"確認412引起的二次效果的措施本發(fā)明 轉(zhuǎn)到以上已描述的步驟711。
優(yōu)選地(在圖7中沒有示出),如果確認411為SACK型確認, 則對于在確認411中參照的數(shù)據(jù)序列中的每一個,本發(fā)明以迭代的方 式前進到上述的其余步驟705 708 (確認為主動的或不為主動的)。
圖8呈現(xiàn)出在隧道端點TEP (例如101)上實現(xiàn)的在表示用于產(chǎn) 生確認消息412并將其發(fā)送給本地TCP服務器的第一日期tl (參見 圖6的步驟604和605)的超時期滿時執(zhí)行的算法,該算法被包含于 本發(fā)明的校正方法的特定實施例中。
在步驟801中,確定需要確認412產(chǎn)生動作的編程表510的條目。
對于每個確定的條目(步驟802的檢驗),執(zhí)行步驟803 809的 序列。
在步驟803中,從不同的表格找回對于產(chǎn)生確認消息412所需要 的參數(shù)
-表格510表示有關的流(字段513)和必須對其產(chǎn)生確認412 的確認序號(字段514);
-從流513的標識符和表格550開始,字段552-555使得能夠形 成消息的IP頭部,并且,字段556表示所支持的確認的類型。作為默 認情況,可以恒定地使用根據(jù)標準RFC793的經(jīng)典類型,但是,當服 務器支持時,推薦優(yōu)選使用SACK支持。
步驟804創(chuàng)建確認消息412 (根據(jù)現(xiàn)有技術)并將其發(fā)送到局域 網(wǎng)103上。
然后,可從表格510消除當前條目(步驟805),并且,在表格 520中將確認消息產(chǎn)生統(tǒng)計數(shù)據(jù)412遞增(步驟806 )。如果需要的話, 在表格510中創(chuàng)建新的條目,其中字段524為1并且字段525為0。
作為預防措施,盡量隨后創(chuàng)建確認消息412的新的產(chǎn)生是重要的。 事實上,步驟804的這種產(chǎn)生克服隧道中的簡單損失,但是希望設想 隧道花費多于一個的RTT來進行恢復的情況。因此,步驟807的檢驗驗證新產(chǎn)生確認消息412的可能性,并且,步驟808然后計算對于在 LAN 103上發(fā)送新的確i^消息412所推薦的日期t2。
首先,進行檢查,以求證是否可以通過組合以下的兩個條件產(chǎn)生 消息
條件1: N必須大于或等于l
N = Nb_packet_410 - Nb_packet_412;其中
"NLpacket—410"是在隧道上運送的數(shù)據(jù)包410的數(shù)量(比由表 格520的當前條目的字段523的確認序號確認的數(shù)據(jù)序號大的數(shù)據(jù)序 號),因此在表格501中被參照;并且,
"Nb—packet—412"是所產(chǎn)生的確認數(shù)據(jù)包412的數(shù)量(表格520 的當前條目的字段524的值)。
換句話說,條件1也可^皮表示如下
Nb一packet一410〉Nb一packet 412。
條件2: "Nb—packet—412,,必須小于等于3。
事實上,如果要產(chǎn)生多于3個的相同的確認消息412,那么這些 相同的確認消息的第四個確認消息會被視為第三個重復確認消息("重 復ACK"),并且服務器會將其解釋為傳送錯誤(這是要避免的)。
如果上述的兩個條件沒有得到驗證,那么對于當前條目完成該過 程(返回到步驟802 )。
如果上述的兩個條件得到驗證,那么實現(xiàn)步驟808。為確認消息 412的產(chǎn)生而規(guī)劃的新日期t2被獲得如下
t2 = current data+2'RTT - A
其中,A是若千毫秒的安全裕度(例如,隧道RTT的10。/。),并 且,"currenLdata,,是前一確認產(chǎn)生日期412 (即tl)。
一旦發(fā)送日期t2被確定,就在步驟809中規(guī)劃新的發(fā)送操作。 與第一發(fā)送日期tl類似,對于應用步驟808和809的隧道的各乘 客流,用于發(fā)送確認消息412的第二日期t2嚴重取決于隧道的RTT 的連續(xù)測量的值(所有的乘客流共用的參數(shù))以及日期tl (為每個流 所特定)。因此,使第二超時的激活(確定t2)對于每個流是特定的,并使其與該流的活動性協(xié)調(diào),以盡可能不具有侵擾性。
很顯然,對于由本發(fā)明的算法選擇的流、對于服務器IIO-A、 110B 和客戶機112-A、 112-B之間的TCP連接的任何傳送(檢測到TCP SYN-END消息,參見附錄)停止自動地停止圖8的算法的建立。為 此,(在圖中沒有示出),只要TCP連接一停止,表格550、 501、 510和520就擺脫參照關閉的TCP連接的條目。
圖9提供實現(xiàn)本發(fā)明的算法的隧道端點101的PEP系統(tǒng)的功能體 系結構的示意圖。
隧道端點TEP 101主要通過具有LAN 103的兩個通信端口即輸入 端口 910和輸出端口 920形成。在實際中,這兩個端口具有相同的以 太網(wǎng)型雙向物理接口 (根據(jù)圖10的網(wǎng)絡端口 1020)。
這兩個端口連接到隧道的TCP信道930,所述TCP信道930連 接兩個LAN 103和104,并且通過具有封裝隧道幀中的乘客流的任務 的多路復用器931和具有對由隧道的TCP載體運送的幀進行解封的任 務的解多路復用器932進行通信。
在以太網(wǎng)幀從LAN 103到達時,流選擇器TCP 911負責應用參 照圖6的步驟600詳細描述的選擇措施。
如果進入的幀與未選擇的TCP流有關,那么該以太網(wǎng)幀被提供給 多路復用器931,以便被封裝且在隧道中被發(fā)送。
如果進入的幀與所選擇的TCP流有關,那么代理912分析運送的 TCP段的類型(DATA或ACK)并更新表格550和501的統(tǒng)計數(shù)據(jù)。
在發(fā)生來自隧道的控制器940的傳送錯誤報警時,用于產(chǎn)生確認 消息412的PEP系統(tǒng)913實現(xiàn)在圖6中描述的算法。該PEP系統(tǒng)913 內(nèi)部的超時機構(表格510)的設定將在適當?shù)臅r刻重新激活圖8的 算法的過程。
相反,在從隧道接收到幀時,解多路復用器932將原始以太網(wǎng)幀 給予流開關933。流開關933然后負責檢查以證實該幀是否涉及TCP 連接。如果該檢查是肯定的,那么它負責檢查以證實該TCP連接是否 被監(jiān)視(搜索與TCP流選擇器911相同的準則)。如果情況不是如此,那么通過輸出接口模塊936在局域網(wǎng)103上傳送以太網(wǎng)幀。
否則,它被傳送給負責更新連接的統(tǒng)計數(shù)據(jù)的模塊934 (圖7的
算法的步驟701)。模塊935然后執(zhí)行圖7的算法,特別是用過濾掉 (消除)消息411的能力的算法。將通過輸出接口模塊936在LAN 103
上發(fā)送不與已對其傳送確認消息412的確認消息411對應的任何以太
網(wǎng)幀。模塊935還將所接收的確認消息411的超時機構的激活/禁用通
知給PEP系統(tǒng)913 (如參照圖7,描述的那樣)。
圖10示出適于實現(xiàn)本發(fā)明的技術的特定實施例的一般通信設備
1000的示意性配置。例如,上面參照圖1提到的隧道端點101或102
與一般設備1000相同。
該一般設備1000尤其可與連接到圖形卡并向一般設備1000傳遞
多^(某體信息的用于存儲圖像、視頻或聲音的任何裝置連接。 該一般設備1000具有連接有以下部件的通信總線1002: -中央處理單元1003 (例如,標記為CPU的微處理器); -標記為ROM的只讀存儲器1004,其能夠包含上述的一個或多
個軟件程序;
-隨機存取存儲器1006 (標記為RAM的高速緩沖存儲器),其 包含適于記錄在上述的一個或多個軟件程序的執(zhí)行過程中創(chuàng)建和修改 的變量和參數(shù)的寄存器;
-通信*接口 1018,其與例如(在圖l的情況下)LAN 103/104和 因特網(wǎng)107的至少兩個分布式通信網(wǎng)絡1020鏈接,該接口能夠用這些 網(wǎng)絡傳送和接收數(shù)據(jù)。
該一般設備1000還具有(但這是任選的)
-屏幕1008,其用于觀察數(shù)據(jù)和/或用作與網(wǎng)絡管理員的圖形用戶 界面,該網(wǎng)絡管理員可通過使用鍵盤1010或諸如例如鼠標1011或光 筆的指示裝置之類的任何其它裝置與根據(jù)本發(fā)明的一個或多個程序交 互作用;
-硬盤驅(qū)動器1012,其能夠包含上述的程序;
-外部盤驅(qū)動器1014,其使得能夠讀取USB存儲棒。通信總線1002使得能夠在包括在一般設備1000中或與該設備連接的不同裝置之間實現(xiàn)通信和相互協(xié)作性。更一般地,通過通信總1002,中央處理單元1003可直接地或通過另——般設備將指令傳送到包含在該一般設備1000中的任何設備。
以上提到的、使得一般設備1000能夠?qū)崿F(xiàn)根據(jù)本發(fā)明的一個實施例的方法(用于管理PEP機構的方法)的各程序的可執(zhí)行代碼可被存儲在例如硬盤驅(qū)動器1012、只讀存儲器1004或USB棒1016的非易失性存儲器中。
中央處理單元1003控制并指導根據(jù)本發(fā)明的一個實施例的一個或多個程序(用于管理PEP機構的方法)的軟件代碼的指令或部分的執(zhí)行。當設備被加電時,存儲在上述的非易失性存儲器(1012、 1004或1016)中的一個或多個程序被傳送到隨機存取存儲器1006,該隨機存取存儲器1006于是將包含本發(fā)明的一個或多個程序的可執(zhí)行代碼,以及所述一個或多個程序被傳送到寄存器以記憶實現(xiàn)本發(fā)明的方法的該實施例所需要的變量和參數(shù)。
必須注意,包含根據(jù)本發(fā)明的設備的通信裝置也可以是被編程的設備。該設備于是包含例如硬件接線到專用集成電路(ASIC)中的一個或多個計算機程序的代碼。
附錄關于TCP協(xié)議的提醒
TCP協(xié)議(由RFC793標準定義的傳送控制協(xié)議)是為了根據(jù)主要的速度和質(zhì)量準則在因特網(wǎng)上提供數(shù)據(jù)傳送而創(chuàng)建的ARQ型協(xié)議。使用至少兩個機構來管理到達接收器的過剩通信量第一個機構使用緩沖接收存儲器,第二個機構建立流的控制。
TCP協(xié)議被用于可靠地傳送數(shù)據(jù),盡管它使用不包含數(shù)據(jù)報傳遞控制的IP協(xié)議。事實上,TCP協(xié)議具有接收確認系統(tǒng),也稱為確認系統(tǒng)或ACK,該接收確認系統(tǒng)被客戶機(也稱為客戶機設備或接收機)和服務器(也稱為服務器設備或發(fā)送機)使用以確保數(shù)據(jù)的有效相互
38接收。當發(fā)送數(shù)據(jù)段(也稱為數(shù)據(jù)的數(shù)據(jù)包)時,次序號(也稱為數(shù)據(jù)序號)與該數(shù)據(jù)段相關聯(lián)。在接收到數(shù)據(jù)段時,接收機將返回標記
ACK為1的數(shù)據(jù)段(為了報告這是接收的確認),其伴隨等于所接收的段的數(shù)據(jù)序號加1的接收號碼(也稱為確認序號)的確認。事實上,確認序號與等待的下一段的數(shù)據(jù)序號(而并非所接收的最后一段的數(shù)據(jù)序號)相對應。
由于通過數(shù)據(jù)傳送和對接收的確認所實施的通信處理基于數(shù)據(jù)次序號(或序號),因此發(fā)送機和接收機(分別為服務器和客戶機)必須知曉其它機器的初始次序號(稱為初始序號或ISN)。
建立連接
以三個階段建立TCP連接
-在第一階段中,客戶機發(fā)送包含SYN標記(或SYN消息)的數(shù)據(jù)段以報告它是具有其初始數(shù)據(jù)序號(lSN-x)的同步段。
-在第二階段中,服務器接收來自客戶機的同步段,然后向其發(fā)送對接收的確認,即包含其自身的序號(ISN-y)的、標記ACK為1并且標記SYN為1的數(shù)據(jù)段,但是,它還必須確認前一數(shù)據(jù)包,它用包含客戶機的初始序號加1 (ack-x+l)的接收號碼(確認序號)的確i^來完成這一點。
-在第三階段中,客戶機向服務器發(fā)送對接收的確認,即,由于不再是同步段因此其是標記ACK為1并且標記SYN為0的段。其次序號(數(shù)據(jù)序號)加1 (seq = x+l),并且,確認接收號碼(確認序號)表示服務器的初始序號(數(shù)據(jù)序號)加l (ack-y+l)。
一旦完成稱為"三次握手,,的該階段,兩個應用就能夠交換保證建立連接的字節(jié)。
; 流控制在預期的接收方的級上管理諸如存儲器和進程之類的資源的分配。 一般地,與流控制相符,目的地對由向目的地發(fā)送數(shù)據(jù)的所有的源實現(xiàn)的傳送吞吐率設定限制。源和目的地通過交換包含詢問和對接收的確認的消息來協(xié)調(diào)數(shù)據(jù)的傳送。在源開始發(fā)送數(shù)據(jù)包之前,它向要獲得開始傳送的許可的目的地發(fā)送請求。響應該詢問,目的地發(fā)送這樣的消息,所述消息包含源在沒有附加的授權的情況下可向目的地傳送的數(shù)據(jù)包的數(shù)量的標識。該數(shù)量一般被稱為"窗口尺寸"。然后,源向目的地發(fā)送授權的數(shù)據(jù)包的數(shù)量,并等待目的地驗證它們的接收。在目的地成功接收到數(shù)據(jù)包之后,它向源發(fā)送返回消息,所述返回消息包含接收確認(確認),所述接收確認指示已成功接收數(shù)據(jù)包,并且在一些情況下允許源發(fā)送另一數(shù)據(jù)包。因此,網(wǎng)絡上的從源向目的地行進的數(shù)據(jù)包的數(shù)量決不超過授權的窗口尺寸。
以下,應注意TCP窗口的不同名稱
-TCP窗口在建立連接期間生效的初始值,該初始值是在連接的整個持續(xù)過程中容許的最大值;
-擁塞窗口 (CWND):在尋址到客戶機的TCP數(shù)據(jù)包中從服務器發(fā)送的當前窗口的值;
-確認窗口 (確認窗口或告知窗口)在ACKTCP數(shù)據(jù)包中向服務器發(fā)送的窗口的值,該值表示客戶機的一部分上的存儲器占用;
-滑動窗口服務器內(nèi)部的窗口的值,該值使其能夠知曉自從最后的確認TCP段到達起要傳送的數(shù)據(jù)的條數(shù)。
大的TCP窗口尺寸鼓勵發(fā)送。如果所接收的數(shù)據(jù)的條數(shù)比窗口所指示的大,那么窗口外數(shù)據(jù)被拒絕。該損失導致大量的重新傳送并且不必要地對網(wǎng)絡和TCP帶來過重的負擔。使用小尺寸窗口通過添加對于往返時間或RTT的某些附加延遲而破壞吞吐率,但是這樣做限制由于重新傳送導致的網(wǎng)絡的過載。非常小的窗口的打開還通過增大頭部相對于數(shù)據(jù)的權重降低性能。
甚至在建立了這些機構的情況下,在繁忙的網(wǎng)絡中,若干個源也同時在網(wǎng)絡中向多于一個的目的地發(fā)送流。如果在非常短的時間段中太多的這種流聚集在單一的路由器上,那么該路由器的緩沖存儲器中的有限容量使得該流的量不能被處理,并且,該路由器將拒絕或破壞數(shù)據(jù)包的一部分。當出現(xiàn)這種情況時,認為網(wǎng)絡是擁塞的」當出現(xiàn)這種情況時,網(wǎng)絡中的傳送顯著放慢,并且網(wǎng)絡的吞吐率下降。由于網(wǎng)絡的某些資源專用于重新傳送,因此,當網(wǎng)絡承受過重的負擔時,發(fā)生擁塞傳播和整個網(wǎng)絡阻塞的風險很大。
TCP MSS (最大段尺寸)字段的值表示本地系統(tǒng)可接受的每個IP數(shù)據(jù)報的TCP數(shù)據(jù)的最大量。當發(fā)送時,IP數(shù)據(jù)報可被分成若千個數(shù)據(jù)包。在理論上,該值可達到值65495。但是,這種大的值從不被實施。 一般地,終端系統(tǒng)使用MTU接口 (外出接口最大傳送單元),從中扣除值40作為其TCP MSS字段值。例如,用于以太網(wǎng)協(xié)議的TCP MSS字段值為1460 ( 1500 - 40 = 1460 )。
使TCP MSS字段的值進入被用于建立連接的、作為包含信號SYN的數(shù)據(jù)包的數(shù)據(jù)包中。各方發(fā)送其自身的TCP MSS字段值。不要求各方使用相同TCP MSS字段值,但是,各方不能發(fā)送比遠程站授權的數(shù)據(jù)更多的數(shù)據(jù)。以TCP頭部選項的最大段尺寸(MSS)發(fā)送TCP MSS字段的值。
應注意,連接接口的緩沖存儲器的尺寸的缺省值隨實現(xiàn)而大大不同。對于TCP接收和發(fā)送緩沖存儲器,從Berkeley得到的較早的實現(xiàn)指示4Kb的缺省值,而更新的系統(tǒng)實現(xiàn)更大的值(例如,達64Kb)。例如,在Windows XP (注冊商標)中,接收時的窗口尺寸的當前值根據(jù)當建立TCP連接時協(xié)商的最大段尺寸(MSS )的對增量而得到自動調(diào)整。
流的控制 廣 -
TCP協(xié)議使用幾種算法來管理其擁塞,更具體而言,使用慢開始和擁塞避免算法。這些算法中的每一個通過操作限制在給定的時間點運送的未確認的字節(jié)的數(shù)量的擁塞窗口 (CWND),管理服務器的發(fā)送吞吐率。通過接收確認的速度來確定對于給定的擁塞窗口值的可能的TCP吞吐率。在發(fā)送一條數(shù)據(jù)之后接收確認所花的時間稱為TCP往返時間(RTT)。
當開始連接時,為了盡可能快地獲得帶寬的值,建立慢開始算法以迅速增大擁塞窗口 (CWND)。服務器維持可變SSTHRESH(穩(wěn)態(tài)閾值),以便區(qū)分這兩個階段。當發(fā)送器推斷存在段的損失時,它將該信息作為網(wǎng)絡過載的隱含信號進行處理,并迅速減小擁塞窗口。在大致推斷了擁塞閾值SSTHRESH之后,TCP建立更慢地增大擁塞窗口的值的擁塞避免算法,以便占有可用的附加帶寬。
在慢開始階段期間(當開始連接時或在已超過超時之后),起動器以1MSS的CWND窗口設定操作開始,并且在確認的每個接收之后,CWND增加1*MSS。擁塞窗口 CWND在每個RTT大致加倍(指數(shù)增長)。在擁塞避免階段(擁塞避免)期間,CWND的增大限于PMSS乘以RTT (加性增長)。
在存在長的傳播時間的因特網(wǎng)中,性能的下降是顯著的。這防止傳送窗口迅速發(fā)送新的段(確認確定傳送窗口的尺寸的增大,并且它們在長的時間段之后到達)。
擁塞和重復確認(重復ACK)的檢測
對于TCP連接,如果服務器裝置接收到具有相同的確認序號的若干個ACK,那么使用的術語是"重復確認,,(或重復ACK)。于是,服務器重新傳送與規(guī)定的數(shù)據(jù)序號對應的數(shù)據(jù)段。在發(fā)送數(shù)據(jù)段之后確定的時間段期間,即使在服務器未接收到其它的ACK(具有另一確認序號)的情況下,服務器未接收到重復ACK,服務器也重新傳送該未確認的數(shù)據(jù)段。
一般地,在無序地接收到數(shù)據(jù)段時(即,當它接收具有比期望的數(shù)據(jù)序號大的數(shù)據(jù)序號的數(shù)據(jù)段時),TCP客戶機發(fā)出重復確認或零復ACK。重復ACK的目的是通知服務器數(shù)據(jù)段被無序接收,并告訴它所期望的數(shù)據(jù)序號。重復ACK的突發(fā)是傳送路徑上的損失數(shù)據(jù)段和/或數(shù)據(jù)段的重新調(diào)度的結果。
快重新傳送和快恢復算法
對于對由重復ACK的接收識別的數(shù)據(jù)包損失的快速檢測和反應,TCP協(xié)議使用在IEFT RFC2581因特網(wǎng)標準中描述的快重新傳送算法(機制)??熘匦聜魉退惴▽⑷齻€重復ACK的到達(事實上是四個相同的確認或ACK,且沒有表示假定的問題已回到正常的任何其它確認)視為已損失數(shù)據(jù)段的指示。如果接收到少于三個的重復ACK,那么認為是這樣的情況它是已解決的數(shù)據(jù)包的解調(diào)度的簡短問題,并且其后跟隨對有關的數(shù)據(jù)段的確認。在接收到這三個重復ACK時,服務器將不等待其RTO的期滿或重新傳送超時,而重新傳送丟失的數(shù)據(jù)段。
然后,啟動快恢復算法以管理新數(shù)據(jù)的傳送,直到非重復ACK的接收。由于TCP客戶機僅在另一數(shù)據(jù)段到達時才可發(fā)送重復ACK,因此,這意味著,盡管如此, 一個數(shù)據(jù)段(但不是所預期的數(shù)據(jù)段)仍然被接收并且不再使用網(wǎng)絡中的任何資源。因此,在網(wǎng)絡上總是存在一些活動性,并且TCP服務器可繼續(xù)傳送新的數(shù)據(jù)段(在擁塞窗口CWND減小的情況下繼續(xù)傳送)。
在TCP服務器上聯(lián)合建立上述的兩個算法(快重新傳送算法和快恢復算法)如下
1. 在接收到第三個重復ACK時,值SSTHRESH被修改以不超過以下的最大值
SSTHRESH = max ( FlightSize/2, 2*MSS )
其中,
-值"FlightSize,,(飛行尺寸)給出服務器還沒有從客戶機接收確認的運送中的數(shù)據(jù)包的估計;
-值MSS指示本地系統(tǒng)可在傳送路徑上接受的每個IP數(shù)據(jù)報的TCP數(shù)據(jù)的最大量。,
2. 被認為損失的段的重新傳送和在(SSTHRESH+3*MSS)時的擁塞窗口的更新。這以已在網(wǎng)絡上出去并且被客戶機正確接收的段(3 )的數(shù)量增大擁塞窗口。
3. 對于由服務器接收的每個新的重復ACK,擁塞窗口 CWND增大1*MSS。
4. 如果允許傳送數(shù)據(jù)段的話,則以擁塞窗口 CWND的新值且以由客戶機表示的確認窗口 ("告知窗口")的值傳送數(shù)據(jù)段。
5. 在接收到確認客戶機在重新傳送的起點接收到數(shù)據(jù)段的下一ACK時,擁塞窗口 CWND減小到在步驟1中計算的值SSTHRESH。該ACK消息當然已在重新傳送之后的1個RTT之前達到(或者,如果問題的原因為數(shù)據(jù)段向客戶機的無序傳遞,那么甚至更早)。從而,
43由于TCP比特率下降到當發(fā)生損失時施行的比特率的一半,因此存在 擁塞避免的階段。
最普遍的TCP選項
選擇性確認(SACK)
SACK選項是用于實現(xiàn)選擇性重新傳送的策略的TCP協(xié)議選項 [RFC2018。該選項針對為損失的恢復提供更深入的信息。事實上, 累積的主動的ACK給予有限的信息,并且,TCP源了解每個RTT僅 存在一個數(shù)據(jù)包損失。SACK擴展給予超出該限制的TCP協(xié)議手段。
只要接收器(客戶機)一覺察到TCP流的次序破壞,就實現(xiàn)SACK 機構。然后,接收器向發(fā)送器發(fā)送回選擇性確認(選擇性ACK),所 述選擇性確認(選擇性ACK)包含依次接收的最后的字節(jié)數(shù)(TCP 實體的常規(guī)ACK字段)和被用于表示在當前的窗口中觀察的最后的 次序破壞的位置的正確接收的鄰近字節(jié)范圍的列表。
選擇性確認[根據(jù)RFC2018被用于克服每個窗口若干段的損失, 而不需要對每個損失執(zhí)行一個或更多個往返。
"有限傳送"算法
如上所述,在接收到三個重復ACK之后執(zhí)行對于給定的段的重 新傳送。如果對于以下的段存在其它的損失,那么它將在接收到最后 的鄰近的序號的情況下在接收到正確的ACK之前采取又一個RTT。 要認識到識別的段已損失*需要三個另外的重復ACK。
取決于當前的CWND窗口,可能發(fā)生這樣的情況不允許服務 器發(fā)送用于產(chǎn)生所有必需的重復ACK的足夠數(shù)量的數(shù)據(jù)段。
RTO因此將期滿,并且服務器將進入慢開始模式。
標準RFC3042 ( Enhancing TCP's Loss Recovery Using Limited Transmit,通過使用有限傳送增強TCP的損失恢復)目的是減少這些 超時的數(shù)量。有限傳送算法因此推薦服務器對于所接收的最后兩個重 復ACK中的每一個發(fā)送數(shù)據(jù)段。該方法增大客戶機將能夠發(fā)送通知 錯誤所需要的三個重復ACK的概率。
可以以與SACK機構結合或分開的方式使用有限傳送才幾構。
權利要求
1.一種用于管理隧道的傳輸信道上的數(shù)據(jù)流的傳送的方法,各流的傳送是根據(jù)以數(shù)據(jù)包調(diào)度并具有確認的傳輸協(xié)議在所述傳輸信道上執(zhí)行的,隧道是在分別與第一和第二子網(wǎng)連接的第一和第二隧道端點之間實現(xiàn)的,各流從發(fā)送器設備向接收器設備傳送,所述發(fā)送器設備和所述接收器設備中的一個設備與第一子網(wǎng)連接,并且另一個與第二子網(wǎng)連接,所述方法通過所述第一隧道端點執(zhí)行,并且,該方法包括以下步驟-檢測隧道的傳輸信道上的數(shù)據(jù)包的損失;-識別具有由于所述損失而在隧道的傳輸信道上被阻塞的至少一個數(shù)據(jù)包的至少一個流;-對于至少一個被識別的流,產(chǎn)生至少一個確認并將其傳送給在隧道上傳送了由于所述損失而被阻塞的數(shù)據(jù)包的發(fā)送器設備。
2. 根據(jù)權利要求l的方法,其中,對于至少一個給定的被識別的 流,所述至少一個產(chǎn)生的確認是對所述被識別的流中在由于所述損失 而被阻塞的第一個數(shù)據(jù)包之前的數(shù)據(jù)包的確認,并且其中,對于已檢 測到其損失的數(shù)據(jù)包所屬的#皮識別的流,由于所述損失而被阻塞的第 一個數(shù)據(jù)包被視為是在檢測到該損失之后在隧道的傳輸信道上重新傳 送的數(shù)據(jù)包。
3. 根據(jù)權利要求l的方法,其中,對于至少一個給定的被識別的 流,產(chǎn)生并傳送至少一個確認的所述步驟包含以下的步驟—根據(jù)與傳送所述給定的被識別的流的發(fā)送器設備相關聯(lián)的重新 傳送超時的持續(xù)時間的估計,并且,根據(jù)由所述隧道端點處理由于所 述損失而被阻塞的所述被識別的流的第 一 個數(shù)據(jù)包之前的所述數(shù)據(jù)包 的處理時刻,確定發(fā)送第一確認的第一發(fā)送時刻tl;-在所述第一發(fā)送時刻tl傳送所述第一確認。
4. 根據(jù)權利要求l的方法,其中,所述第一發(fā)送時刻tl由tl-t0+RTO'-A定義,其中,-to是在所述第一隧道端點中處理由于所述損失而被阻塞的所述 被識別的流的第 一個數(shù)據(jù)包之前的所述數(shù)據(jù)包的所述處理時刻;-RTO'是與傳送所述給定的被識別的流的發(fā)送器設備相關聯(lián)的 重新傳送超時的持續(xù)時間的所述估計;- A是預定的安全裕度。
5. 根據(jù)權利要求4的方法,其中,對于至少一個給定的被識別的 流,產(chǎn)生并傳送至少一個確認的所述步驟包含以下步驟的至少一次迭 代-確定發(fā)送新的確認的新的發(fā)送時刻t2,該新的發(fā)送時刻t2由t2 - tl+RTO' 一 A定義,其中,tl對于笫一次迭代是所述的第一發(fā)送時刻, 或者,對于從第二次迭代開始的每次迭代,tl是在前一次迭代確定的 新的發(fā)送時刻t2;-在所述新的發(fā)送時刻t2傳送所述新的確認。
6. 根據(jù)權利要求4的方法,其中RTO'-2.RTT, RTT為隧道 上的往返持續(xù)時間的測量結果。
7. 根據(jù)權利要求l的方法,其中,對于至少一個給定的被識別的 流,在產(chǎn)生并傳送至少一個確認的所述步驟中,僅當以下的第一條件 得到驗證時產(chǎn)生并傳送確認在隧道的傳輸信道上運送并由于所述損 失而被阻塞的所述給定的襪識別的流的數(shù)據(jù)包的數(shù)量大于對于所述給 定的被識別的流由所述第一隧道端點產(chǎn)生和傳送的確認的數(shù)量。
8. 根據(jù)權利要求l的方法,其中,對于至少一個給定的被識別的 流,在產(chǎn)生并傳送至少一個確認的所述步驟中,僅當以下的第二條件 得到驗證時產(chǎn)生并傳送確認對于所述給定的被識別的流由所述第一 隧道端點產(chǎn)生并傳送的確認的數(shù)量小于或等于對于傳送所述給定的被 識別的流的發(fā)送器設備指示數(shù)據(jù)包損失的預定的閾值。
9. 根據(jù)權利要求l的方法,其中,對于至少一個給定的被識別的 流,該方法包括過濾所述第一隧道端點已對其產(chǎn)生并傳送了確認的所 述給定的被識別的流的經(jīng)由隧道從接收器設備到來的確認的步驟。
10. —種存儲計算機程序的計算機可讀存儲介質(zhì),該計算機程序包含可由計算機執(zhí)行以便實現(xiàn)用于管理隧道的傳輸信道上的數(shù)據(jù)流的 傳送的方法的一組指令,各流的傳送是根據(jù)以數(shù)據(jù)包調(diào)度并具有確認 的傳輸協(xié)議在所述傳輸信道上執(zhí)行的,隧道是在分別與第 一和第二子 網(wǎng)連接的第一和第二隧道端點之間實現(xiàn)的,各流從發(fā)送器設備向接收 器設備傳送,所述發(fā)送器設備和所述接收器設備中的一個設備與第一 子網(wǎng)連接,并且另一個與第二子網(wǎng)連接,所述方法通過所述第一隧道端點執(zhí)行,并且,該方法包括以下步驟-檢測隧道的傳輸信道上的數(shù)據(jù)包的損失;-識別具有由于所述損失而在隧道的傳輸信道上被阻塞的至少一 個數(shù)據(jù)包的至少一個流;-對于至少一個被識別的流,產(chǎn)生至少一個確認并將其傳送給在 隧道上傳送了由于所述損失而被阻塞的數(shù)據(jù)包的發(fā)送器設備。
11. 一種第一隧道端點,該第一隧道端點使得能夠管理隧道的傳 輸信道上的數(shù)據(jù)流的傳送,各流的傳送是根據(jù)以數(shù)據(jù)包調(diào)度并具有確 認的傳輸協(xié)議而在所述傳輸信道上執(zhí)行的,該隧道是在分別與第一和 第二子網(wǎng)連接的所述第一隧道端點和第二隧道端點之間實現(xiàn)的,各流 是從發(fā)送器設備向接收器設備傳送的,所述發(fā)送器設備和所述接收器 設備中的一個設備與第一子網(wǎng)連接,并且另一個與第二子網(wǎng)連接,其 中,所述第一隧道端點包含-用于檢測隧道的傳輸信道上的數(shù)據(jù)包的損失的裝置; -用于識別具有由于所述損失而在隧道的傳輸信道上被阻塞的至少一個數(shù)據(jù)包的至少一個流的裝置;-用于對于至少 一個被識別的流產(chǎn)生至少 一個確認,并將其傳送給在隧道上傳送了由于所述損失而被阻塞的數(shù)據(jù)包的發(fā)送器設備的裝置。
12. 根據(jù)權利要求11的第一隧道端點,其中,對于至少一個給定 的被識別的流,所述至少 一個產(chǎn)生的確認是對所述被識別的流的由于 所述損失而被阻塞的第一個數(shù)據(jù)包之前的數(shù)據(jù)包的確認,并且其中,對于已檢測到其損失的數(shù)據(jù)包所屬的被識別的流,由于所述損失而被阻塞的第 一個數(shù)據(jù)包被視為是在檢測到損失之后在隧 道的傳輸信道上重新傳送的數(shù)據(jù)包。
13. 根據(jù)權利要求ll的第一隧道端點,其中,用于產(chǎn)生并傳送至 少一個確認的所述裝置包含-用于對于至少一個給定的被識別的流,根據(jù)與傳送所述給定的 被識別的流的發(fā)送器設備相關聯(lián)的重新傳送超時的持續(xù)時間的估計, 并且,根據(jù)由所述隧道端點處理由于所述損失而被阻塞的所述被識別 的流的第一個數(shù)據(jù)包之前的所述數(shù)據(jù)包的處理時刻,確定發(fā)送第一確 認的第一發(fā)送時刻tl的裝置;-用于在所述第一發(fā)送時刻tl傳送所述第一確認的裝置。
14. 根據(jù)權利要求11的第一隧道端點,其中,所述第一發(fā)送時刻 tl由tl-t0+RTO'-A定義,其中-to是在所述第一隧道端點中處理由于所述損失而被阻塞的所述 被識別的流的笫 一 個數(shù)據(jù)包之前的所述數(shù)據(jù)包的所述處理時刻;-RTO'是與傳送所述給定的被識別的流的發(fā)送器設備相關聯(lián)的 重新傳送超時的持續(xù)時間的所述估計;- A是預定的安全裕度。
15. 根據(jù)權利要求14的第一隧道端點,其中,用于產(chǎn)生并傳送至 少 一 個確認的所述裝置包含被激活至少一次的以下裝置-用于對于至少一個被識別的流確定發(fā)送新的確認的新的發(fā)送時 刻t2的裝置,該新的發(fā)送時刻t2由t2-tl+RTO'-A定義,其中,tl 對于第一次迭代是所迷的第一發(fā)送時刻,或者,對于從第二次迭代開 始的每次迭代,tl是在前一次迭代確定的新的發(fā)送時刻t2;-用于在所述新的發(fā)送時刻t2傳送所述新的確認的裝置。
16. 根據(jù)權利要求14的第一隧道端點,其中,RTO'-2.RTT, RTT為隧道上的往返持續(xù)時間的測量結果。
17. 根據(jù)權利要求11的第一隧道端點,還包括 -第一驗證裝置,該第一驗證裝置用于對于至少一個給定的被識別的流驗證以下的第 一條件在隧道的傳輸信道上運送并由于所述損失而被阻塞的所述給定的被識別的流的數(shù)據(jù)包的數(shù)量大于對于所述給定的被識別的流由所述第一隧道端點產(chǎn)生和傳送的確認的數(shù)量;-用于如果所述第一驗證裝置做出肯定的驗證則對于所述至少一 個給定的被識別的流激活用于產(chǎn)生并傳送至少一個確認的所述裝置的 裝置。
18. 根據(jù)權利要求11的第一隧道端點,還包括 -第二驗證裝置,該第二驗證裝置用于對于至少一個給定的被識別的流驗證以下的第二條件對于所述給定的^C識別的流由所述第一 隧道端點產(chǎn)生并傳送的確認的數(shù)量小于或等于對于傳送所述給定的被 識別的流的發(fā)送器設備指示數(shù)據(jù)包損失的預定的閾值;-用于如果所述第二驗證裝置做出肯定的驗證則對于所述至少一 個給定的被識別的流激活用于產(chǎn)生并傳送至少一個確認的所述裝置的 裝置。
19. 根據(jù)權利要求11的第一隧道端點,還包括對于至少一個給定 的被識別的流,過濾所述第 一 隧道端點已對其產(chǎn)生并傳送了確認的所 述給定的被識別的流的經(jīng)由隧道從接收器設備到來的確認的裝置。
全文摘要
提出一種用于管理隧道的傳輸信道上的數(shù)據(jù)流的傳送的方法,各流的傳送是根據(jù)由數(shù)據(jù)包調(diào)度并具有確認的傳輸協(xié)議在所述傳輸信道上執(zhí)行的,隧道是在分別與第一和第二子網(wǎng)連接的第一和第二隧道端點之間實現(xiàn)的,各流從發(fā)送器設備向接收器設備傳送,所述發(fā)送器設備和所述接收器設備中的一個設備與第一子網(wǎng)連接,并且另一個與第二子網(wǎng)連接。所述方法通過所述第一隧道端點執(zhí)行,并且,該方法包括以下步驟檢測隧道的傳輸信道上的數(shù)據(jù)包的損失;識別具有由于所述損失而在隧道的傳輸信道上被阻塞的至少一個數(shù)據(jù)包的至少一個流;對于至少一個被識別的流,產(chǎn)生至少一個確認并將其傳送給在隧道上傳送了由于所述損失而被阻塞的數(shù)據(jù)包的發(fā)送器設備。
文檔編號H04L12/46GK101635665SQ20091014019
公開日2010年1月27日 申請日期2009年7月10日 優(yōu)先權日2008年7月11日
發(fā)明者P·維熱, S·巴龍 申請人:佳能株式會社