利用NS2軟體模擬各種TCP版本_實作篇(二)

2.環境建置

A.安裝好Linux環境


這一步的話我就不多贅述了，網路上頗多教學的，例如什麼，如何安裝Ubuntu. Fedora. centos......等，

B.安裝好NS2

之前就先拍好影片了，就不多說什麼

C.測試環境安裝正確

其實影片後半段就有了啦...
敝人龜毛了點又多講這段
打開terminal
輸入ns
前面出現%之後 輸入nam
都安裝正確的話會出現這個畫面喔>.=

D.本次實驗基本指令

到指定資料夾底下編譯要的檔案與TCP版本
EX:ns filename.tcl tcp_version

編譯沒有問題會出現此圖

開啟新的terminal 輸入gnuplot
在方才編譯好的資料夾底下輸入圖中指令
輸入正確指令且繪製成功的圖表

3.結果圖與分析

A.觀察TCP Tahoe congestion windows的變化

圖 A-1 Tahoe的CWND變化圖

從A-1圖中我們可以看到TCP的Congestion window的值會呈現週期性的重複變化。TCP Tahoe 開始執行時，先由slow-start（SS）開始，CWND超過ssthresh時進入擁塞避免（CA）階段。由於傳送到網路上的丟包不斷增加，當超出允許能傳送到網路上的個數時，路由器開始使用Drop-Tail演算法將資料包丟掉。當封包遺失時，TCP Tahoe會將ssthresh設為發現封包遺失時的一半，接著將CWND的值設為1。Tahoe重新進入slow-start階段。

B.觀察TCP Reno congestion windows的變化

圖 B-1 Reno的CWND變化圖

如圖B-1所示，當偵測到封包遺失時，Reno會將ssthresh和CWND的值設為先前CWND值的一半。因此在重送遺失的封包後，TCP Reno會由CA階段開始。由於結束Fast recovery後，Reno的CWND由先前CWND值得1/2開始增加，所以得到的平均吞吐量較Tahoe佳，可由下圖得知。
圖 B-2 Tahoe 與Reno平均吞吐量比較圖

C.TCP Reno

圖 C-1 Reno的平均吞吐量與路徑上封包數
在這次的例子中，我們將佇列的大小設為15個封包。粗略估計，當路徑上的封包超過16.4個時應該就會開始掉封包(參見上圖)。現在傳送端很容易會因為宋得太快而產生Multiple packet loss，這種情形在TCP Tahoe/Reno很容易導致Timeout發生。

圖 C-2 Reno的CWND變化圖
從圖C-2可以觀察到CWND的變化情形。在途中我們可以看到，大約在0.5~0.6秒時，有一個Timeout發生。
圖 C-3 佇列長度變化圖
為了更能了解path上封包的使用情況，我們將佇列長度給繪圖出來(參見圖C-3)，大約在0.5~0.7秒這段期間，由於傳送端沒有再繼續送出新的資料(在等待Timeout)，所以queue length是空的。

D.TCP NewReno

圖 D-1 NewReno的CWND變化圖

C.與D.的模擬網路環境是相同的，而我們可以從圖D-1模擬的結果我們看到，NewReno修改了Reno中快速重傳的演算法的改善結果，這使得NewReno的傳送端在網路有大量封包遺失時不需等待Timeout就能更正錯誤，減少大量封包遺失對傳輸效能所造成的影響。

圖 D-2 佇列長度變化圖

在大約t=0.5~0.79秒時，NewReno一下傳出了很多的封包，這種急劇傳出封包的行為有時候在網路壅塞時很容易造成調封包的情形出現，若想消除這種瞬間急劇送出封包的現象可使用TCP的maxburst參數限制每次收到ACK最多能傳出的封包數量。

E.SACK

圖 E-1 SACK的CWND變化圖

由於SACK是Reno的一個衍生版本，在這版本當中，加入一個SACK選項(Option)允許目的端在回傳Duplicate ACK時，將已經收到的資料區段回傳給傳送端，資料區段與資料區段之間的間隔就是目的端沒有收到的資料。因此SACK的傳送端可以在一個RTT時間之內重送一個以上的封包。
圖 3-5-2 佇列長度變化圖
圖 3-5-2 佇列長度變化圖

從圖E-2就可以明顯看出SACK的路徑使用率明顯比圖圖C-3與圖D-2高的許多，只要小小改變壅塞機制的一些東西，就能對效能有大大的影響。

F.同質性環境(Homogeneos environment)

圖F-1 模擬實驗網路架構圖
在這個實驗裡，我們假設一個單純的網路環境，網路上的傳輸層都使用相同的TCP版本，我們把這個環境稱之為”同質性環境”。

圖 F-2 Vegas的CWND變化圖

從圖F-2中可以看到，在Slow-start階段，CWND的值大約兩個RTT才增加一倍。和Reno不同的是，當Diff的值介於alpha與beta之間時，Vegas的CWND會維持在一個穩定的狀態，值得注意的是即使有兩條以上的連線存袃網路上時，Vegas還是能維持在穩定的壯再且不會因宋的太快而造成封包遺失。

圖 F-3 佇列長度變化圖
從圖F-3看來，這兩條TCP連線在第6秒之後，對於頻寬的使用情形顯然有些差距，這種不公平的現象是Vegas這類演算法可能會遇到問題之一。一是因為當網路上有其他流量存在時，較晚進網路的TCP連線量到的RTT不見得準確，二是Diff的值介於alpha與beta之間，CWND值便不再變動。

G.TCP Reno vs. TCP Vegas-在異質性環境下

事實上，TCP Reno是目前使用最為廣泛的版本，因此我們用一個簡單的例子來實實作，當網路傳輸的協定是Vegas與Reno的運作情況，也就是模擬在異質性的環境下。

圖 G-1 模擬實驗網路架構圖

我們改變Vegas中alpha與beta得值，分別為1-3(參見圖G-2)，2-4(參見圖G-3)，3-5(參見圖G-4)，4-6(參見圖G-5)，來觀察Vegas與Reno平均吞吐量的變化。

圖 G-2 Vegas與Reno的CWND變化量(alpha=1 beta=3)
圖 G-3 Vegas與Reno的CWND變化量(alpha=2 beta=4)
圖 G-4 Vegas與Reno的CWND變化量(alpha=3 beta=5)
圖 G-5 Vegas與Reno的CWND變化量(alpha=4 beta=6)

從圖 G-2中可以看到，Reno的位置總是高於Vegas，當網路的通訊皆使用TCP Vegas時，整體執行效能會優於TCP Reno，這是因為TCP Vegas採取較為保守的作法，避免封包遺失並藉此提高網路的執行效能。但不幸的，當TCP Vegas和Reno共存時Vegas沒法與Reno公平競爭頻寬，原因是Reno使用較具有Aggressive的壅塞控制方法，Reno傳送端會持續地將封包送到網路上值到發生壅塞；相較之下，Vegas傳送端在網路開始壅塞時就將傳送端的傳送速度降慢以避免壅塞的情形發生；因此當Vegas與Reno共存時，Vegas在效能上的表現總是會比較差。

圖 G-6 Vegas與Reno的平均吞吐量比較圖
從圖G-6中我們可以看到，當提高Vegas中的alpha與Beta時，Vegas的平均吞吐量就會逐漸上升，而Reno的平均吞吐量就會逐漸下降，從Vegas的壅塞控制演算法了解到，當alpha與beta的值越大，所能夠吞吐的封包量越大，這恰與實驗出來的情況吻合，但依舊無法改善Vegas在競爭頻寬上的弱勢。


4.參考文獻

[1] “Newreno-百度百科,” [線上]. Available: http://baike.baidu.com/view/4521733.htm.

[2] “各种TCP版本之NewReno与Sack,” [線上]. Available: http://blog.sina.com.cn/s/blog_5d2054d90100s9tj.html.

[3] “TCP/IP 名稱,” [線上]. Available: http://blog.xuite.net/u870q217/blog/42931039-TCP%2FIP%E7%AD%86%E8%A8%98.

[4] “TCP 緩啟動 (slow start),” [線上]. Available: http://blog.cwke.org/2010/12/tcp-slow-start.html.

[5] “擁塞控制,” [線上]. Available: http://wiki.mbalib.com/zh-tw/%E6%8B%A5%E5%A1%9E%E6%8E%A7%E5%88%B6.

[6] “柯老师的awk讲解,” [線上]. Available: http://blog.sina.com.cn/s/blog_3fc8554b0100qgay.html.

[7] “NS2 簡單模擬範例,” [線上]. Available: http://netlab.cse.yzu.edu.tw/ns2/netlab/ns2_website/ns_example.xml.

[8] “How to install ns2 on Ubuntu 12.04,” [線上]. Available: https://www.youtube.com/watch?v=kvu9OADH_Bg.

[9] "咻咻的筆記小站", [線上]. Available: http://hengxiuxu.blogspot.tw/.

[10]柯志亨，程榮祥，鄧德雋，丁建文, NS2網路模擬實現, 台北市: 學貫, 2012. 



留言

張貼留言

這個網誌中的熱門文章

Raspberry pi 樹莓派系列 :安裝瀏覽器

圖片
(首圖與內文無關) 前言     小魯一開始在使用RPI的時候,實在是還不太習慣內建的瀏覽器,所以就先從習慣的軟體下手 而下方就是各種瀏覽器的安裝筆記了 目錄 epiphany-browser Firefox Chrome epiphany-browser 介紹 這是款由RPI基金會所提供的新型瀏覽器,基於   Epiphany 所製作,以下是瀏覽器的使用情況 根據官方部落的的介紹,這款瀏覽器擁有以下特色 對於HTML5的支持性大幅提升 附有 JavaScript JIT 支持硬體解碼 針對ARMv6 blitting 函式優化 讀取頁面時擁有更好的互動 能夠快速滾動 安裝步驟 sudo apt-get update sudo apt-get dist-upgrade sudo apt-get install epiphany-browser Firefox 介紹 Iceweasel 是一個 網路瀏覽器 ，是 Mozilla Firefox 瀏覽器的 Debian 再發布版。<取自WIKI> 安裝步驟 $ sudo apt-get install iceweasel   Chromium 介紹 Chromium 是一款由Google 所主導的輕量瀏覽器 ，為 Google發展自家的瀏覽器 Google Chrome 而開啟的計畫，所以Chromium相當於Google Chrome的工程版或稱實驗版 安裝步驟 $ sudo apt-get install chromium 如果遇過error ，請先嘗試以下動作 $ sudo apt-get update 參考資料 http://www.raspberrypi.org/web-browser-released/ http://www.raspberrypi.org/forums/viewtopic.php?f=30&t=39725 http://theurbanpenguin.com/wp/?p=3249
繼續閱讀

『如何說出好故事｜故事架構介紹｜輕鬆做出大師級故事架構』

圖片
『前言』 這是一篇介紹如何寫出好的故事架構的方法，內容取材自 Dan Harmon(丹。哈蒙)，當代最強的（寫作家？），由他所提出的 Story circle，只要用八個步驟解構你的故事，就可以編織出一個充滿娛樂性且信服於人的故事，掌握好當中的原則，不管是之後想要寫腳本，或是進行內容行銷的撰寫，文案的產出，都可以使用，廢話不多說，讓我們開始吧。 『故事』 Story Circle 是 Dan Harmon 在精煉出千面英雄以及英雄之旅兩本經典的故事架構寫作書後的產物，每一個故事，都會需要一個主要開始進行冒險，接著在冒險中獲得成長，回到故鄉，這固然是很老套的劇情，但是卻十分受用，像是迪士尼的電影就很多都是這典型的故事流程，例如：阿拉丁、鋼鐵人等。下面將介紹主要是哪八個步驟，先是介紹主角在這步驟中的順序以及發展，接著也講述，這八個步驟在圓環當中的相關性。 『哪八個步驟？』 Dan Harmon 在介紹自己的 Story Circle 時，曾經簡化成以下口訣，『You Need GO! Search Find Take Return Change』，分表代表主角在整個旅程中所遇到的事件。下面我會使用 Coco(可可夜總會)來作為例子。 ㄧ、You: 認識主角，建立世界觀 當我們開始進行故事前，得先讓觀眾知道整個故事的世界觀為何，從而帶出主角所處在的環境，這裡最好是越快建立越好，通常這裡故事可能先由主角的家庭成員介紹起，帶到主角朋友，以及些日常生活狀況等。在可可夜總會中，故事開頭介紹，生長在墨西哥長大的 Miguel ，三代都從事著製鞋業，爸爸如此，其兒子 Miguel 也應該如此，然而 Miguel 的志向卻是在音樂上，而且嚮往過世已久的音樂家 de la Cruz (德古拉斯) 二、Need: 主角追求些什麼 世界觀建立好之後，接著放入主角不滿的現狀為何，也就是給予需求，誘發出主角開始旅途的契子。在可可夜總會中，我們了解 Miguel 所處的環境跟自己的不滿，家裡人不斷阻止 Miguel 的音樂之路，甚至在 Miguel 進行嗜好時，從而打斷並強烈威脅他，至此 Miguel 的目標跟動機已然開朗，成為音樂家。 三、GO! 前往未知世界 主角為了取得之前的需求，而開始踏入自己不
繼續閱讀

『目標管理｜SMART原則｜最有效的目標管理原則』

圖片
『前言』 這是一篇關於如何使用 SMART 原則來幫忙制定一個合理可量化的目標，這個不論是在個人年度計畫使用、社群短期目標建立、或是企業長期目標規劃上都是滿不錯的選擇，而且是由彼得杜拉克所提出的，我想這是滿好 follow 且已經被多數人使用的原則，而且用處可大可小，想跟大家分享下我最近讀下來的心得與感想。 『故事』 新的一年又即將到來，不論你處於人生哪個階段，我相信或多或少製作過個人年度願望清單，例如把減肥、發大財、找到新對象等，在今年沒有達成的遺憾，想要在新的一年間補回來，期望有更好的自己。但更多的是，每年因為現實壓力，不論是家庭因素、公司問題、或是出現意料之外的事件等，導致自己無法將願望清單上的東西逐一刪去，結果新的一年又到了，如此反反覆覆下，就會覺得沒有計畫也沒差。 其實這不是計畫的問題，而是在於你所記錄上去的東西有沒有被量化或者是被審視過，例如說想要減肥好了，結果你在願望清單上寫”我要減肥”，這個很好了，只是缺少許多細節，例如具體數字、打算在幾月之前完成、你要怎麼開始執行等，有許多細節需要被撰寫下來，而 SMART原則，正是用來處理這種問題，用來審視各種**目標**是否有辦法被有效地管理。 SMART原則是由五個英文單字的開頭縮寫組合而成，分別代表 Specific(具體的)、Measurable(可測量的)、Attainable(可達成的)、Relevant(相關性)、明確截止日期(Time-based)。我們回到剛剛“我要減肥”這個例子，來看看我們怎麼樣來改進我們的目標。先假設我說兩個月好了，從農曆新年開始算起大概是 2/1 號，時間限制在 8 週裡面來進行減重的行為，那麼要減多少呢？就先設定個十五公斤吧，因為我想回到年輕的樣貌，接下來是要怎麼減重，我應該開始減少每餐外食吃的量，然後每週抽個三天出來慢跑1.5小時好了，因為工作太忙，這樣應該就可以達到我所設定的目標。 好的，至此我想我們已經比一開始好上許多了，我們有具體時限跟執行策略，不是一句“我要減肥”而已。恭喜你，現在我們來用看 SMART 原則審視一下我們剛剛的規劃。首先很明顯的，Specific 已經鮮明許多，八週內減重15公斤，Time-based 也在其中體現出來，公斤本身可以使用 weight scale 進行量測，再來是
繼續閱讀