- 相關推薦
高速 IP 網(wǎng)絡的輕負荷和快速仿真(一)
高速 IP 網(wǎng)絡的輕負荷和快速仿真
摘要：
網(wǎng)絡路由實現(xiàn)模擬有兩個重要的因素，大小不一的文件和傳輸控制協(xié)議，他們分布于會話層。整合兩者的源操作面臨著兩個主要的可測量性問題，其中每個來源所必需的計算資源限制了可被模擬來源的數(shù)量，以大容量網(wǎng)絡為內容的離散事件數(shù)量導致了過長的模擬時間。我們介紹一種輕巧的路由來源。從統(tǒng)計上來看，它產(chǎn)生的路由類似實際來源產(chǎn)生的路由。與實際來源相類似，它產(chǎn)生很多分布在會話層的文件。然而，它的傳送操作建立于近似傳輸控制協(xié)議的假的傳輸控制協(xié)議上。P-TCP的稀疏編碼使LWTS相對于現(xiàn)實的路由來源少了50倍。為了解決第二個可量測性問題,我們在傳輸層介紹新奇的抽象化技術: 我們把小包送給一整窗戶傳輸控制協(xié)議包的當做一大包。這抽象化造成不連續(xù)事件的減少可達到28倍的更快速的模擬。
關鍵詞語：輕負荷業(yè)務源，可測量仿真方法論，大范圍可靠性
1介紹
計算機模擬的目標是盡可能的模仿現(xiàn)實。然而，很重要的是為了研究一些特定的系統(tǒng)特點，并且不僅要仔細考慮現(xiàn)實細節(jié)，還要用現(xiàn)有的計算資源，在合理的時間內完成模擬。在大多數(shù)情況下，兩個目標在相反的兩端。仿真模擬需要特殊的、昂貴的硬件，要求長時間提供穩(wěn)定的結果。另一方面，任何解決實際限制的承諾一般都要考慮犧牲一些模型的實際細節(jié)。
互聯(lián)網(wǎng)路由是大范圍的，這是由它自身性質決定的。LRD在路由工程和網(wǎng)絡計算的問題上有很深的影響，從數(shù)學的角度看，它意味著路由表明大范圍時間內的相關性，除此之外，特定協(xié)議機制和壅塞控制機制提高了在小范圍時間表內復雜結構道具的性能，這是不同于大時間縮放的行為，從觀察的表現(xiàn)要點來看，這些相關結構的最大反映是排隊行為，這巨大的不同于產(chǎn)生于Poisson貨物記憶處理的古典行為結果。因此，在通信網(wǎng)絡仿真的路由中實現(xiàn)大時間和小時間的相關性是很重要的。
LRD 主要地被歸因于會話特性, 或使用者-行為。每個使用者被模擬為開關源，那開狀態(tài)表現(xiàn)使用者的下載活動, 而且關狀態(tài)表現(xiàn)它的想-時間。開時間是冗長分布的，是因為冗長的網(wǎng)頁造成的。多個不規(guī)則碎片在小的時間刻度的結構主要地被歸因于傳輸控制協(xié)議記錄。作者介紹的HTTP-TCP的來源包括這些因素，它包括完全落實傳輸控制協(xié)議傳送冗長分布于會話層的文件。
然而以實用的方式模擬低速度網(wǎng)絡是有可能的，在高速網(wǎng)絡模擬方法學面對兩個主要可測量問題。如高速的網(wǎng)絡攜帶大量路由，因此,很多的路由來源必須模擬在這樣一個系統(tǒng)上。每個來源對計算機的資源都要求。因此,有限可得的計算機資源限制能被模擬的來源數(shù)量。其次，每個來源在模擬的過程中產(chǎn)生若干的不連續(xù)的事件。時間越多，模擬的時間越長。這些是與高速網(wǎng)絡的離散事件模擬學密切相關的兩個重要實際的限制。
可量測性議題對HTTP-TCP來源甚至是更嚴重的，它包括一個客戶–服務器的傳輸控制協(xié)議對為傳輸控制協(xié)議連接：兩者都占據(jù)存儲空間而且產(chǎn)生路由。事件被產(chǎn)生用于從服務器到客戶端的數(shù)據(jù)流同樣用于相反方向的路由確認．大量的不連續(xù)的事件減慢模擬。舉例來說,在一個４ＧＢ隨機存取儲存器和一個 1.5Ｇ赫茲處理器的機器上，一總共1.5 Gbps 的路由需要2 – 3個秒的現(xiàn)實路由。同樣，HTTP-TCP來源占據(jù)約２０kBytes的模擬器的內存空間�，F(xiàn)在的穩(wěn)定 Linux 核心能存取將近４ＧＢ的存儲器。1 GBytes的存儲空間被用于核心，組件等。因此，我們在剩余的 3 GBytes 存儲器上能最多模擬 150,000來源。當調諧的模擬一個典型的網(wǎng)路使用者，每個來源生產(chǎn)約12 kbps的路由。然后模擬器的能力不超越路由的1.8 Gbps 的模擬。提供這些實際的限制, 現(xiàn)實的小包級的高速網(wǎng)絡的模擬出現(xiàn)被當做一不可能的任務。因此, 一新類型的路由來源要求不僅產(chǎn)生現(xiàn)實的互聯(lián)網(wǎng)路由而且解決那有關的可量測性問題。
我們介紹一個新類型的路由來源，它在統(tǒng)計上來看類似被產(chǎn)生的路由被一真正的HTTP-TCP來源產(chǎn)生。我們叫它輕便路由源。就像HTTP-TCP來源，LWTS 是一個開關源。在會話層，它有和HTTP-TCP來源一樣準確相同的結構。因此，它生產(chǎn)和HTTP-TCP來源是完全相似的 LRD 路由。二個來源之間的不同是二個來源傳送數(shù)據(jù)的方法。我們?yōu)榫W(wǎng)絡模擬的范圍引進一新的傳送模型。我們叫他假- 傳輸控制協(xié)議.(P-傳輸控制協(xié)議)。這類似于包括真正的占優(yōu)勢特性TCP傳輸協(xié)議。舉例來說慢啟動行為，壅塞避免，快速重傳送和恢復，和一大約的指數(shù)背面行為也提到如 Karn's 的運算法則。它合并機制，估計來回時間 (RTT) 分配，這在路由特性中扮演重要角色。它的稀疏編碼的實現(xiàn)主要成份是兩存儲-當作數(shù)據(jù)庫使用的地圖。一個數(shù)據(jù)庫跟蹤包損失，每當他們失去一個它直接地被寫入緩沖。
另一個跟蹤端到端得抱延時。P-TCP閱讀這兩張圖而且因此反應, 也就是,它隨著網(wǎng)絡狀態(tài)改變自身狀態(tài)，形成彈性路由。我們將會在下面的部分解釋它的完整行為以及和真正的TCP顯著的不同。一些技術已經(jīng)用來加速模擬，他們被分成三組，計算能力，模擬技術和模擬模型。較快速的處理器產(chǎn)生跟強的計算能力。更好的和改良的模擬運算法則改善模擬速度等，重啟動系統(tǒng)裝置探究罕見事件。第三方式是使用較高的層抽象化, 舉例來說,包序列模擬技術模擬了一群緊密地排列得包作為一單獨的包序列，另一種方法是流暢的模擬方法。一個相等的不連續(xù)的包模擬器跟蹤所有路由源和網(wǎng)絡序列在物理層的變化，流暢的模擬器處理一組大塊流動包。網(wǎng)絡路由在連續(xù)不斷的流之間是被處理過的，一組平常的差別平衡數(shù)字的被解決，獲得依賴時間網(wǎng)絡行為的估計，流模擬器的過頭處理遠低于報水平的模擬器是很自然的，因此直接導致更快的模擬，然而，很明顯可以看到，加速模擬是以犧牲細節(jié)標準為代價的。
我們采用一個完全新的抽象化策略。我們在傳輸層作抽象，以便能更早修改將大塊數(shù)據(jù)當作一整窗包來傳送的P-TCP協(xié)議，將一整窗當作一小包降低了負載計劃引擎的負載，加速了模擬。這種在窗口水平的抽象世介于包水平和流水平之間的，它不僅合并了會話層的冗長分布文件特性，也保持了TCP協(xié)議的關鍵功能。不能推測在建立隊伍后跟著發(fā)生包丟失或延時。這種抽象的代價是我們要放棄包水平的細節(jié)，在窗水平上模擬，我們相信我們的抽象測率在保證模擬仿真的同時也想留模擬一樣取得了明顯增速。我們將在模擬的幫助下論證這種技術的效用。
我們做了兩項研究。在第一項研究中，我們比較LWTS的離散包版本來源和HTTP-TCP來源。我們將測量和顯示關鍵路由統(tǒng)計的好的匹配，如吞吐量，變化系數(shù)，獨立協(xié)方差，赫斯特參數(shù)。在第二項研究中，我們比較來源的抽象版本和現(xiàn)實來源的產(chǎn)生的路由，我們表示那主要部份路由特性和離散包水平路由的吞吐量，赫斯特參數(shù)和平均包延時的良好匹配。這種模擬是實際的到目前為止也是更快的，更輕巧的。
以HTTP-TCP路由為來源的用戶行為模式在第二部分和第三部分已經(jīng)給出，我們揭示了LWTS 的工作方式和如何處理以上提到的可測量性問題。在第四部分，我們討論模擬建立和結果。
2 HTTP-TCP的來源
我們簡要的討論了HTTP-TCP的來源的細節(jié)。讓我們描述網(wǎng)頁服務器上連貫的網(wǎng)頁用戶請求到搭建的時間，HTTP協(xié)議在會話層取得申請的網(wǎng)頁然后傳送到TCP上。讓 V代表網(wǎng)頁服務器產(chǎn)生的平?jīng)Q文件的大小，讓 Z代表梅耶對象的平均數(shù)目。如果 F 表示平均的網(wǎng)頁然后按規(guī)定尺寸制作 F= V Z. TCP 傳送網(wǎng)頁從服務器到用戶。平均網(wǎng)頁傳輸以平均的開時間在會話層被完成。網(wǎng)頁下載之后，用戶在下個申請之前，在平均關閉時間內保持不活動，每個網(wǎng)絡用戶循環(huán)經(jīng)歷著開和關的行為。
HTTP-1.1 被考慮在會議層是因為它的流行。他通過持久穩(wěn)固的連接傳送文件，這意味著一個單一連接用于傳送一個網(wǎng)頁的所有文件。類似連接的做法在這里不再舉例。在傳輸層，TCP首先通過三次握手建立服務器和客戶之間的連接，然后傳送實際數(shù)據(jù)，從一包開始，TCP保持在一窗中加倍，直到達到它的極限或有包丟失。前者他會轉到CA階段。對于TCP，接連的兩個創(chuàng)之間的時間是rtt。如果沒有包丟失，連接將會開啟最大壅塞窗，然后維持這窗直到整個的文件傳完。如果有損失傳輸控制協(xié)議將會轉變到其他的階段。
如果互聯(lián)網(wǎng)路由的主要成分主要由弱的tcp傳輸或“老鼠”， 公平的是只有傳輸控制協(xié)議的SS 極限狀態(tài)足夠搬運網(wǎng)絡路由的大部分。這是HTTP-TCP模型的基礎。這個模型將會更緊密地模擬現(xiàn)實。然而，模擬的結果表明，這種近四實際上不壞，我們發(fā)現(xiàn)中的大部分遵循互聯(lián)網(wǎng)絡路由中的現(xiàn)有統(tǒng)計資料。
可以推測，適當大小的網(wǎng)絡在極限狀態(tài)時有不可避免的包丟失，作者將在下面闡述HTTP-TCP路由得tp.
N 是必需傳送的一個大小為 F 的平均網(wǎng)頁 RTTs 的平均數(shù)字。清楚地來源準時到達
3輕負荷路由來源
為了保持LWTS和HTTP-TCP來源的密切性，在會話層我們準確使用用戶行為，兩種來源在傳輸方式上是不一致的。早些時候P-TCP已經(jīng)介紹了，它的細節(jié)將在下面給出。
象早些時候闡述的那樣，每個用戶請求造成tcp傳輸?shù)木W(wǎng)頁產(chǎn)生。Tcp是有確認鎖的。新的報文只有在得到確認響應后才發(fā)出。每個包引發(fā)一個向相反方向的確認包。這是tcp反饋環(huán)的一個主要功能。反饋環(huán)另一個主要功能是提供rtt的估計。兩功能都取決于網(wǎng)絡條件。
我們減少反饋環(huán)的包確認，用兩個基于軟件的反饋環(huán)代替補充相同功能，同時，語音多樣性對ASR系統(tǒng)的進展仍然有很大的影響。在以易變?yōu)樘卣鞯囊蛩刂�，詞性和口音是最重要的。前者已經(jīng)被AD模型所包含。然而，還是有相對較少的關于帶口音的語音識別的研究正在進行，尤其是對那些雖有同樣母語，但由于人們方言的不同而發(fā)生了區(qū)域性口音變化的語音的研究。
我們減少反饋環(huán)的包確認，用兩個基于軟件的反饋環(huán)代替來補充相同功能，我們用兩個存儲地圖做數(shù)據(jù)庫，一個跟蹤包丟失，它叫plm，另一個跟蹤e2e包延時，它叫e2e延時地圖。Plm在隊列丟失包時被直接寫入緩沖。E2EDM被客戶寫入接收包。
每個客戶計算E2E延遲并且把它寫入地圖。在接下來的部分我們將指出LWTS和HTTP-TCP來源的不同之處。
3.1 連接打開和結束
TCP經(jīng)過三次握手完成連接打開階段的兩個方面（1）40個位信號包（2）從客戶到服務器的網(wǎng)頁請求。第一方面差不多包括在模型中。一個40字節(jié)的信號包在連接開始時被送出，他的成功投遞被數(shù)據(jù)庫PLM確認，在完成一個rtt間隔后，如果包丟失，他將會在RTT間隔之后重新發(fā)送和重新檢查是否成功投遞。如果包成功投遞，連接將進入ss階段。
第二個方面我們只是從負指數(shù)級的網(wǎng)頁傳送間功能性的移到一個隨機關閉的服務器，這關閉時間的分布的平均價值設置以平均思考時間和關閉時間為準。
我們通過設置最后一個數(shù)據(jù)報的RST位模擬TCP連接關閉階段，通知客戶端數(shù)據(jù)傳輸?shù)慕Y束。
3.2暫停和三倍-副本
在P-TCP中沒有定時器，這極大的簡化了協(xié)議的執(zhí)行，這些定時器的基本功能使評估重傳延時，或協(xié)議推測包丟失以及將會采取的去處這種情況必須步驟所需的時間。對于P-TCP包丟失直接寫入PLM，信息被協(xié)議讀出。這也去除了告訴協(xié)議包丟失需重傳的三倍副本機制的需求。
3.3 P- TCP階段
P- TCP由SS,CA,FRR和Exp-BO階段，和TCP思想一致。從SS階段開始，在第一個RTT內傳送一獨立數(shù)據(jù)包，如果沒有損失，協(xié)議將在一個RTT內加倍壅塞窗，直到窗達到極限，這就是指數(shù)創(chuàng)增長。然后協(xié)議將轉向CA階段，在這一階段，CWND將在窗成功發(fā)送或丟失后被一部分填充。這是線性增長。這種增長將一直持續(xù)直到達到最大壅塞窗，通常是65,535個字節(jié)。如果沒有損失，將一直保持知道網(wǎng)頁傳送終止。
如果沒有包損失，失去包的緩沖將把丟失寫入PLM。在協(xié)議發(fā)送一窗新的信息包之前，他將讀取數(shù)據(jù)庫的于特定連接相關的損失。他的兩個操作基于這個信息：(1)一定傳送容量=傳送量+包丟失，網(wǎng)頁量將被重新傳送，(2) 決定下一階段。遵循集中出現(xiàn)的可能：如果再SS中由單一的損失，那下一狀態(tài)將是SS,這是個近似。實際的TCP，例如，如果丟失檢測TD機制允許FRR，TCP-RENO將可避免激烈的從SS重復開始的測量，因此將進入CA階段
如果在階段有包損失，Wssth 和 CWND將被減少到正在運轉的CWND的一半最小值是二，下一階段CA。這是FRR的近似。
如果在CA階段有多種損失，那下一階段是SS。這是嚴重擁堵的跡象，因此，P-tcp協(xié)議將會徹底降低從SS開始的幾率。
如果在SS階段有多種損失，下一階段是Exp-BO。這是幾種壅塞的跡象。
因為它在相關高損失條件下誘導偽自我模擬的重要性所以包括Exp- BO 階段是確定的。真正的傳輸控制協(xié)議把一包并在Karn's 的運算法則決定的RTO內等待確認。如果包傳送不成功，RTO將加倍然后再一次傳這包。協(xié)議保持加倍的RTO知道她達到64倍的第一個RTO。這又將包傳送丟失造成的偽自我迷你的幾率降低一半的作用。
我們的執(zhí)行用確定的RTO來近似。在P-tcp的Exp-BO中，以RTO= 5 * RTT 來計算。這是因為當取道平均rtt值的標準背離rtt.做一個簡單的假設rtt是負指數(shù)分布，我們將設
3.4 RTT估算
當客戶受到數(shù)據(jù)包，會用一種簡單的方法計算E2E延遲，即現(xiàn)有系統(tǒng)的時間與數(shù)據(jù)包被產(chǎn)生的時間差 ，將這個延遲加倍所以可以估計RTT將這個延遲寫入E2EDM。P-TCP將應用相同的 估計函數(shù)應用在真實的TCP-IP協(xié)議中。P-TCP讀取數(shù)據(jù)庫中的內容再調整下次發(fā)送的滑動窗口。
3.5 數(shù)據(jù)提取戰(zhàn)略
數(shù)據(jù)的提取在運輸層完成， 不是發(fā)送離散的數(shù)據(jù)包在每個時間周期，P-TCP將一整個數(shù)據(jù)包在一個滑動窗口中一起發(fā)送。優(yōu)點是明顯的：提取的數(shù)據(jù)會被清晰地在日程表上顯示，因為它將給每個數(shù)據(jù)包間日程表而不是一G包在每個數(shù)據(jù)周期。
然而我們將指出一個重要的細節(jié)：因為在傳輸層傳輸，因為擁塞，數(shù)據(jù)隊列會遺失整個滑動窗口，但離散的數(shù)據(jù)包不會！這樣看起來很極端，我們指出數(shù)據(jù)包的丟失是相關的。 在丟棄結尾數(shù)據(jù)類型的路由器中，當滑動窗口中以數(shù)據(jù)包丟失后，剩下的敞口中的數(shù)據(jù)包也會一起丟失。我們會進一步產(chǎn)生疑問多少個數(shù)據(jù)包在突發(fā)事件中丟失。基于純理論的解釋很難給出。然而我們將估計與模擬現(xiàn)實的情況截取數(shù)據(jù)包的數(shù)據(jù)段在有突發(fā)的遺失發(fā)生后。例如：只有完全窗口的一部分數(shù)據(jù)發(fā)生遺失將不會在寄存器中找到那部分數(shù)據(jù)。這種方法比較現(xiàn)實。詳細的情況可以被得到。我們發(fā)現(xiàn)后果并不是想象的那末嚴重。因為我們可以用基于少量的數(shù)據(jù)流失模式來觀察。所以這種估計并不是沒有事實依據(jù)的。然而我們指出，TCP所要做得在相關的數(shù)據(jù)包丟失以后。
基本的當tcp探測到數(shù)據(jù)丟失以后它有兩種選擇。如果數(shù)據(jù)包被成功的發(fā)送當一是數(shù)據(jù)包的意外發(fā)生以后，協(xié)議會收到兩個獲三個一樣的數(shù)據(jù)包。這就意味著會產(chǎn)生輕微壅塞，這時TCP會選擇FRR，然而如果兩個連續(xù)的數(shù)據(jù)窗口發(fā)生遺失協(xié)議會選擇SS。這個估計蘊含了TCP協(xié)議防壅塞的思想。
判斷數(shù)據(jù)傳輸?shù)哪康氖菢O其重要的，簡單一些說是解決可觀測性事件用一種模擬仿真的方法。我們主張不要重新設定TCP或獲取TCP的整個反饋循環(huán)。這用特性決定了用戶行為將其他傳輸特性整合在了一起。
3.6 LWTS 吞吐模式
我們將TCP的基于結構模式定義在基于段模式之中。協(xié)議傳輸平均每個W窗口實時的以R速率傳輸。協(xié)議停止傳輸在TCP OFF是間段中，MSS極為最大傳輸數(shù)據(jù)部分。N的公式如下：
為了估計ss段是否能傳輸平均每個網(wǎng)頁。一下是估計公式：
平均窗口長度W平均網(wǎng)頁傳輸量將為
將RTT定義為協(xié)議傳輸在下限之和有
LWTS具有開關結構在傳輸層，在一段內應用開關結構在部分層：直觀地來看有
N是平均的RTT值傳輸平均每個網(wǎng)頁時。現(xiàn)在公式可以寫為
再做一個微調
還有：
3.7預計的提速
在決定提速量時有三個主要因素。
在不提及現(xiàn)實的HTTP與TCP協(xié)議時，假設段到達時我們在服務器產(chǎn)生網(wǎng)頁但僅僅將其傳輸?shù)娇蛻舳�。HTTP打開或關閉時和TCP既不產(chǎn)生流量,我們也消除了繁瑣的TCP編碼過程而將其在客戶服務器簡單的編碼。每個客戶服務器將其丟失數(shù)據(jù)簡單編碼在下一個數(shù)據(jù)窗口返回。因為這種原因我們不能精確的估計加速量。然而這種估計會發(fā)生兩道三次。
去除了確認信息量：數(shù)據(jù)確認信息在數(shù)據(jù)包的傳輸中產(chǎn)生的流量和數(shù)據(jù)出書幾乎相等。所以數(shù)據(jù)的傳輸速率提高也直觀地展現(xiàn)為確認信息的去除
提�。簲�(shù)據(jù)傳輸?shù)奶崴倭颗c窗口壅塞的程度相關�？梢杂靡幌鹿接嬎�
一個典型的用戶行為如圖表1在給出MSS后平均網(wǎng)頁傳輸可提高到大約42數(shù)據(jù)包
所以，模擬時間加速了四倍在離散數(shù)據(jù)包傳輸時。在提取窗口級模擬式可望提速大約28倍。
3.8進一步提速
數(shù)據(jù)提取戰(zhàn)略將有現(xiàn)實的情況發(fā)生改變。因為會遇到光傳輸網(wǎng)絡所附加的傳輸限制。模擬系統(tǒng)的提速量將有防壅塞窗口所來主要決定。具體參數(shù)將由國家互聯(lián)網(wǎng)來決定。數(shù)據(jù)傳輸速度會提高100倍當數(shù)據(jù)流有足夠長和網(wǎng)絡傳輸?shù)膩G失足夠小。速度提高速度還取決于數(shù)據(jù)資源的集成度。
4 總體傳輸?shù)拿枋雠c仿真設置
或許精確的計算出因特網(wǎng)的隨機流量是不可能的。然而我們可以根據(jù)主要的參數(shù)做出判斷，來選區(qū)四個主要標志數(shù)據(jù)傳輸特性的標志，為了做到上述，我們應用了數(shù)據(jù)包內部到達時間過程。
第一個關鍵數(shù)據(jù)是TP ,TP描述了數(shù)據(jù)包的平均數(shù)據(jù)量與數(shù)據(jù)包的平均內到達時間。第二個關鍵參數(shù)為CV是一個隨機的變量，其定義為傳輸速率背離其應有值的程度。CV標志了平均傳輸過程的一些變化。ACV則可用來觀測相關量的變化 。赫氏參數(shù)冊為第四個主要參數(shù)。為了形象地描述我們用一些突來表示其概念：
4.1仿真設置及對比HTTP-TCP與LWTS的結果
為了進行仿真我們這部分應用了托勒米仿真器來延續(xù)網(wǎng)絡。如圖三為了http-tcp傳輸試驗，示范了仿真結構。我們跟隨表一給出的摘要，用這些數(shù)值，我們得到了典型的網(wǎng)絡用戶的tp，他的包延時是12kbps。除了傳輸裝置以外，p-tcp和lwts是相同的
我們推測這種連接不會被現(xiàn)有大容量高速網(wǎng)絡下載，因為tcp正遭受由于連接下載所帶來的壅塞坍塌超過了75%。作為一個最嚴重的例子想定核心連接的利用保持在65-70%，利用的邊緣是50%。將被模擬的源數(shù)量被三個網(wǎng)絡服務器均分。
圖2給出了設置TP傳出流量的一些細節(jié)。寄存器容量設置為550個數(shù)據(jù)包。數(shù)據(jù)包的內部到達時間過程在傳輸數(shù)列節(jié)點R1將被獲得。這將標志著隊列將數(shù)據(jù)從服務器傳輸?shù)娇蛻舳舜_認信息從客戶端到服務器將不從這對數(shù)據(jù)中傳輸。
冗長行分發(fā)數(shù)據(jù)在我們的模擬中是一個縮冪尾型（TPT）將形成參數(shù)1。5
TPT分布將需要大量樣本匯聚。例如:為了達到參數(shù)最少需要個樣本。我們的方針有足夠能力提供至少個文件。
4.1.1 吞吐量
如圖4 顯示了TP對比LWTS與HTTP-TCP的傳輸流量。TP隨數(shù)據(jù)的增加成線性增長模式。例如資源數(shù)為N時總的TP約為LWTS顯示了優(yōu)良的匹配隨著線性的增加。
4.1.2變化的有效性
圖5展示了cv和tp的關系，lwts顯示了cv的很好的匹配，它遵循了已論證的http-tcp路由相同的的趨勢。
4.1.3赫氏參數(shù)
在圖六赫氏參數(shù)也顯示優(yōu)良的匹配特性（除了288MBPS這個點，我們還沒有很好地解釋。）這也顯示了H值開始下降的到0。65載有2338個資源時開始穩(wěn)定。在28Mbps時，向前。為了高速傳輸時數(shù)據(jù)包的內部到達時間有所需的空間，只有這樣才能使傳輸更加順暢。這是一個比較有趣的結論在分析因特網(wǎng)傳輸路徑時。
4.1.4 自動協(xié)方差
選擇分析5682個資源的相關性，發(fā)現(xiàn)可以產(chǎn)生大約72mbps的傳輸速率，然后測試cv得知。但當Acv=1時 會誤使我們想象為沒有PLD.這是另外一個比較有趣的結果在我們的實驗中。
圖8 顯示了LWTS的相同的72mbps聚集傳輸結構 。除了在開始的一些微小變化 ，這種變化大概歸因于P-TCP。 這種新的資源產(chǎn)生了相同的PLD行為就像HTTP-TCP資源所產(chǎn)生的一樣。他將持續(xù)四個指令周期。LWTS產(chǎn)生與LRD極為匹配的行為。
4.1.5普通包延時
在我們所討論的最后部分我們謹簡單的提及一下。我們將PLD既看作一關也或對參數(shù)的匹配 ， 例如，在網(wǎng)關大概傳輸速率為72Mbps時，兩個資源節(jié)點產(chǎn)生了大概相同的39s的MPD
然而用另外一種描述方法，我們前面已經(jīng)討論過在測量因特網(wǎng)傳輸路徑時 ，已用我們的模式來加以說明。 我們用以上來解釋這些現(xiàn)象。
4.1.6模擬設置與對比HTTP-TCP LWTS的資源后的結果
為了這個實驗，我們使用了核心連接能力為C’=50mbps的器件。下載連接能力為，這個結果從表3可以看出。所有的數(shù)據(jù)顯示為優(yōu)良的匹配。PLD由赫氏參數(shù)給出，因為E2E所產(chǎn)生的冗長型網(wǎng)頁所產(chǎn)生的延遲發(fā)生在以上兩種情況。
LWTS的主要目的為解決HTTP-TCP資源畢環(huán)操作的可測量性。
速度提高的結果如圖4所示。對350秒的HTTP-TCP仿真 大約用了26分鐘。然而用LWTSs仿真用了56秒。這是大概28倍，這種提高在仿真中顯得很為可觀。這種速度的提高是對某個傳輸?shù)钠款i的設定改變。然而，很顯然得，相同的數(shù)據(jù)傳輸速率提高 也可以通過減少路由器中等待數(shù)據(jù)的長度取得。因為在多重的路由器的情況下離散數(shù)據(jù)包的傳輸速率被固定下來當離散數(shù)據(jù)包速率在仿真提高時。
這還將有一個重大的改變在LWTS應用內存時。如圖9給出了解決兩資源對內存需要的想法。HTTP-TCP遵循了一種線性曲線大概為當。就像先前所討論的一樣，我們可以用3GBytes的內存來做構架仿真。這樣就可以使最大1500000mbps 資源一起仿真。作為對比，新資源所需要的內存要遠遠的小，例如需要相同數(shù)目的資源僅僅需要60MB內存，遠離這些，對1500000HTTP-TCP的方針將不可能進行。但對新資源就變得可行。
5結論
在這篇論文中，我們展示了一種數(shù)據(jù)傳輸模式，它不僅應用了因特網(wǎng)傳輸速率的高可靠性，也解決了基于TCP的數(shù)據(jù)傳輸?shù)目蓽y量性。所有數(shù)據(jù)實測的結果全部基于現(xiàn)實的因特網(wǎng)。所以我們的仿真緊貼現(xiàn)實。為了顯示HTTP-TCP的傳輸特性，我們的數(shù)據(jù)都由真實的HTTP-TCP資源所測。我們提供了可代替現(xiàn)有HTTP-TCP的新型資源，我們有理由相信P-TCP從TCP攫取了精髓，可實現(xiàn)網(wǎng)絡輕巧，高速傳輸。這種簡潔的思想和容易的執(zhí)行方法將會使這個領域成為最具研究潛力的方向！
【高速 IP 網(wǎng)絡的輕負荷和快速仿真(一)】相關文章：
無線傳感網(wǎng)SCRP協(xié)議的設計和仿真05-11
提升高速公路養(yǎng)管水平 促進公路建設快速發(fā)展06-01
一種汽車用金鹵燈的快速點亮電路05-18
高速公路機電設備安全生產(chǎn)事故預防和處理論文11-03
OFDM技術研究及其系統(tǒng)仿真05-11
自制快速干手器05-11
網(wǎng)購快速發(fā)展的隱憂05-14