tinyos編程

⑴ 推薦學習zigbee和tinyos的經典書籍~~~

TinyOS相關：

官方文檔：TinyOS-1.x Documentation TinyOS-2.x Documentaion

快速入門的8個Lesson：TinyOS Tutorial 模擬： TOSSIM Note

TinyOS編程經典資料：tinyos-programming(PDF)

TinyOS可以在這些platform上跑：Tinyos Hardware Page

TinyOS FAQ

NesC語言相關：

The nesC Language_ A Holistic Approach to Networked Embedded Systems(PDF)

nesC Language Reference Manual(PDF) (可以在doc/nesc里找到)

NCC Manual Page

nesC Source Documentation

nesC的PPT資料

學習筆記：

Fang Wei-wei版

視頻網站：

http://www.youtube.com/watch?v=j6hRsue5b30
http://vimeo.com/channels/tinyos#3264574

關於zigbee，請參考

http://..com/question/70364117.html?si=1&wtp=wk

⑵ 無線感測器網路中常用的網路模擬軟體平台有

無線感測器網路中常用的網路模擬軟體平台有OPNET、OMNET++、NS2、TOSSIM等。OPNET是一個強大的、面向對象的、離散事件驅動的通用網路模擬環境。作為一個全面的集成開發環境，在無線傳輸方面的建模能力涉及模擬研究的各階段，包括模型設計、模擬、數據搜集和數據分析，所有的無線特性與高層協議模型無縫連接。TinyOS是一種面向WSN的新型操作系統。TinyOS採用了輕量級線程技術、主動消息通信技術、組件化編程技術，它是一個基於事件驅動的深度嵌入式操作系統。TOSSIM是一種基於嵌入式TinyOS操作系統的WSN節點模擬環境的實現代表，源碼公開，主要應用於MICA系列的WSN節點。其模擬應用隨同TinyOS被編譯進事件驅動的模擬模擬器。OMNET++是一種開源的基於組件的模塊化的開放網路模擬平台，近年來在科學和工業領域逐漸流行。作為離散事件模擬器，其具備強大完善的圖形界面介面和可嵌入式模擬內核，運行於多個操作系統平台，可以簡便定義網路拓撲結構，具備編程、調試和跟蹤支持等功能，主要用於通信網路和分布式系統的模擬。

⑶ 物聯網工程是研究什麼的

物聯網工程是交叉學科，是多個學科的融合，即計算機科學與技術、信息與通信工程、微電子學科、檢測與自動化和儀器科學與技術。物聯網工程是復合專業，涉及控制理論與控制工程、微電子檢測、通信工程和計算機與信息專業，對應物聯網的控制、感知、傳輸和信息處理技術。
物聯網網路架構由感知層、網路層、應用層組成。計算機學院在物聯網技術的網路層和應用層領域具有很好的研究基礎，而感知層更多依賴的是軟硬體結合的嵌入式系統技術。物聯網的感測器介面、RFID讀寫都涉及嵌入式技術，但實際上新技術含量很少，可看作是一個新袋子。
物聯網主要涵蓋RFID（>5.5）、無線感測器網路（>8.5）、M2M智能手機（<4.5）等技術領域。其中括弧里表達的是難度系數，可以看出無線感測器網路是最難的。
專業基礎課：物聯網技術導論、計算機科學導論、程序設計基礎（C語言）、離散數學、數字電子技術基礎、電路分析基礎、模擬電子技術基礎、數值分析。
專業必修課：無線感測器網路、數據結構與演算法設計、面向對象程序設計、計算理論與演算法分析設計、資料庫原理與設計、計算機組成原理、匯編語言程序設計、操作系統、編譯原理與設計、軟體工程基礎、計算機體系結構、計算機網路、微機介面技術、信號與系統、自動控制原理。
專業選修課：微控制器介面技術、計算機圖形學、人工智慧基礎、嵌入式系統、多媒體技術、網路信息安全、軟體體系結構、分布式計算原理與應用、Web軟體技術、硬體描述語言與計算機硬體模塊設計。
專業實踐課：數字電子技術實驗、模擬電子技術實驗、操作系統課程設計、程序設計方法與實踐、Web開發基礎、軟體基礎實習、資料庫系統開發、匯編與介面課程設計、計算機組成原理硬體實驗、軟體工程綜合訓練、Visual
C++數據通信編程實踐。

以上信息來自於5聯網，僅供參考，更多信息請訪問5聯網。

⑷ 物聯網應用技術應該要學習哪些課程

物聯網應用技術應該要學習課程：計算機應用基礎、計算機組裝調試技術、計算機網路英語、程序設計基礎、網頁設計基礎、數字電路、微機原理與介面技術、計算機網路、物聯網技術基礎、信息安全技術等;

核心課程：計算機網路技術、路由與交換技術、移動通信技術、無線感測器技術、嵌入式技術、智能家居技術、入侵檢測與防禦技術、網路資料庫、Linux操作系統、Windows Server操作系統等;

拓展課程：智能蔬菜大棚技術、信息安全法規、應用文寫作、網路營銷、數據恢復技術、語音網路技術、無線網路技術、Ipv6技術等。

拓展資料

物聯網最為明顯的特徵是網路智慧化，通過信息化的手段實現物物相連，提高不同行業的自動化管理水平，減少人為干預，從而極大程度地提升效率，同時降低人工帶來的不穩定性。因此，物聯網在許多行業應用中將發揮巨大的潛力。

例如未來通過感應設備將電網、鐵路、橋梁、隧道、公路、建築、供水系統、大壩、油氣管道等數據信息化，並通過網路傳輸方式實現信息的採集及管理，將物聯網與現有的互聯網整合起來，實現人類社會與物理系統的整合。

⑸ 無線感測器網路操作系統TinyOS的目錄

第1章 緒論 1
1．1 無線感測器網路概述 1
1．1．1 無線感測器網路的研究進展 2
1．1．2 無線感測器網路的體系特徵 3
1．2 無線感測器網路操作系統 8
1．2．1 無線感測器網路對操作系統的需求 8
1．2．2 現有的無線感測器網路操作系統 10
1．3 TinyOS操作系統概述 13
1．3．1 設計理念 14
1．3．2 技術特點 15
1．3．3 體系結構 16
1．3．4 版本說明 17
1．4 與其他WSN操作系統的比較 20
1．5 本書章節安排 24
第2章 開發環境 26
2．1 TinyOS 2.1在Windows中的安裝 26
2．1．1 搭建Java環境 27
2．1．2 安裝Cygwin平台 30
2．1．3 安裝平台交叉編譯器 34
2．1．4 安裝TinyOS源碼與工具包 36
2．1．5 安裝Graphviz圖形工具 38
2．2 其他安裝方法 39
2．2．1 在Ubuntu 9.10中的安裝 39
2．2．2 使用RPM包的手動安裝 41
2．2．3 TinyOS 1.x升級到TinyOS 2.x 42
2．2．4 使用CVS更新TinyOS 2.x文件 46
2．3 TinyOS安裝後的測試 47
2．3．1 TinyOS文件概覽 47
2．3．2 檢查運行環境 48
2．3．3 模擬測試 49
2．4 程序的編譯和下載 50
2．4．1 代碼編輯工具 50
2．4．2 編譯程序 52
2．4．3 USB串口驅動 53
2．4．4 下載程序 54
2．5 本章小結 57
第3章 nesC編程語言 58
3．1 nesC語言簡介 58
3．2 nesC語言規范 59
3．2．1 介面 61
3.2.2 組件 62
3.2.3 模塊及其組成 65
3.2.4 配件及其組成 68
3.3 基於nesC語言的應用程序 73
3.3.1 nesC應用程序簡介 73
3.3.2 Blink實例 77
3.3.3 BlinkSingle實例 82
3.3.4 移植TinyOS 1.x代碼到2.x 86
3.4 nesC程序運行模型 88
3.4.1 任務 88
3.4.2 內部函數 91
3.4.3 分階段作業 92
3.4.4 同步與非同步 94
3.4.5 原子性代碼 95
3.4.6 無線模塊的開啟過程 96
3.5 編程約定 98
3.5.1 通用約定 98
3.5.2 軟體包 98
3.5.3 語法約定 99
3.5.4 TinyOS約定 101
3.6 可視化組件關系圖 103
3.7 本章小結 104
第4章 基本操作 106
4.1 點對點的無線通信 106
4.1.1 主動消息概述 106
4.1.2 通信介面和組件 107
4.1.3 消息緩存抽象 109
4.1.4 通過無線電發送消息 110
4.1.5 通過無線電接收消息 117
4.2 節點與PC的串口通信 119
4.2.1 信息源和埠測試 119
4.2.2 基站和監聽工具 121
4.2.3 MIG消息介面生成工具 123
4.2.4 SerialForwarder和其他信息源 126
4.2.5 發送信息包到串口 129
4.2.6 基於printf庫的列印調試 130
4.2.7 常見的串口通信故障 133
4.3 感測 134
4.3.1 感測簡介 134
4.3.2 Sense實例 135
4.3.3 Oscilloscope實例 138
4.4 存儲 140
4.4.1 存儲簡介 140
4.4.2 配置數據的存儲 141
4.4.3 日誌數據的存儲 146
4.4.4 大數據塊的存儲 148
4.5 本章小結 149
第5章 系統內核 151
5.1 硬體抽象架構 151
5.1.1 架構簡介 151
5.1.2 不同層次抽象的結合 154
5.1.3 橫向分解 155
5.1.4 微處理器抽象 156
5.1.5 HIL抽象級別 156
5.2 任務和調度 157
5.2.1 任務簡介 157
5.2.2 TinyOS 1.x的任務和調度器 157
5.2.3 TinyOS 2.x的任務 159
5.2.4 TinyOS 2.x的調度器 160
5.2.5 調度器的替換 162
5.2.6 調度器的具體實現 165
5.3 系統啟動順序 168
5.3.1 啟動順序簡介 168
5.3.2 TinyOS 1.x的啟動順序 168
5.3.3 TinyOS 2.x的啟動介面 169
5.3.4 TinyOS 2.x的啟動順序 170
5.3.5 系統啟動和軟體初始化 174
5.4 資源仲裁 175
5.4.1 資源簡介 175
5.4.2 資源類型 176
5.4.3 資源仲裁 178
5.4.4 共享資源的應用實例 183
5.5 微控制器的電源管理 187
5.5.1 微控制器電源管理簡介 187
5.5.2 TinyOS 1.x的電源管理 188
5.5.3 TinyOS 2.x的電源管理 189
5.5.4 外圍設備和子系統 191
5.6 外圍設備的電源管理 191
5.6.1 外圍設備電源管理簡介 191
5.6.2 電源管理模型 192
5.6.3 顯式電源管理 193
5.6.4 隱式電源管理 196
5.7 串口通信 199
5.7.1 串口通信協議簡介 199
5.7.2 串口協議棧的實現 200
5.7.3 串口協議棧的抽象 207
5.8 本章小結 207
第6章 平台與模擬 210
6.1 平台 210
6.1.1 平台簡介 210
6.1.2 底層I/O口 211
6.1.3 新平台的建立 215
6.1.4 CC2430平台的移植 223
6.2 編譯系統 226
6.2.1 編譯系統簡介 226
6.2.2 自定義編譯系統 227
6.2.3 makefile入門 228
6.2.4 編寫Makefile文件 230
6.2.5 編譯工具 232
6.3 TOSSIM模擬 233
6.3.1 TOSSIM簡介 233
6.3.2 模擬編譯 234
6.3.3 基於Python的模擬 237
6.3.4 調試語句 239
6.3.5 網路配置 242
6.3.6 變數的觀察 250
6.3.7 注入消息包 253
6.3.8 C++介面 256
6.3.9 gdb調試 258
6.4 本章小結 261
第7章 網路協議 262
7.1 分發協議 262
7.1.1 分發協議簡介 262
7.1.2 相關介面和組件 263
7.1.3 EasyDissemination實例 265
7.1.4 Drip庫和DIP庫 269
7.2 匯聚協議 276
7.2.1 匯聚協議簡介 276
7.2.2 相關介面和組件 277
7.2.3 CTP協議 279
7.2.4 CTP實現 281
7.2.5 EasyCollection實例 287
7.3 本章小結 291
第8章 高級應用技術 293
8.1 低功耗應用程序 293
8.1.1 能耗管理簡介 293
8.1.2 外圍設備的電源管理 294
8.1.3 無線模塊的電源管理 297
8.1.4 微處理器的電源管理 300
8.1.5 低功耗感測的應用實例 300
8.2 低功耗監聽 300
8.2.1 低功耗監聽簡介 300
8.2.2 相關介面 302
8.2.3 message_t元數據 304
8.2.4 HAL層的改進建議 305
8.3 TOSThreads線程 305
8.3.1 TOSThreads線程簡介 305
8.3.2 nesC語言的API介面 306
8.3.3 C語言的API介面 309
8.3.4 支持新的系統服務 310
8.4 CC2420聯網安全功能 312
8.4.1 CC2420安全模式簡介 313
8.4.2 發送端的配置 313
8.4.3 接收端的配置 314
8.4.4 RadioCountToLeds實例 315
8.5 本章小結 319
第9章 基於TinyOS的應用開發實例 320
9.1 基於TSL2550感測器的光照檢測 320
9.1.1 TSL2550簡介 320
9.1.2 驅動實現 323
9.1.3 感測測試 330
9.2 基於GSM簡訊的遠程數據傳輸 334
9.2.1 系統簡介 334
9.2.2 功能實現 338
9.2.3 簡訊測試 348
9.3 基於簡單蟻群演算法的路由協議 350
9.3.1 演算法簡介 350
9.3.2 協議實現 353
9.3.3 模擬測試 366
9.4 本章小結 370
附錄A nesC語言基本語法 371
附錄B TinyOS編程技巧 374
附錄C 英漢對照術語表 375
參考文獻與網址 378

⑹ tinyos怎麼讀

你也在研究這個嗎？一起搞搞吧，我最近也在做相關方面的編程，主要是在micaz節點上，有時間一起交流交流！我是這樣讀的（太累哦愛死），呵呵``tiny是微型的意思吧，OS就是操作系統了```
有時間一起交流的哇``

⑺ 急 急 急 求一篇關於《通信網路模擬研究》的論文

幫您下了兩篇，希望對您有所幫助哦！祝您愉快！

1
題目：基於無線感測器網路模擬平台的研究
一、引言

感測器網路（WSN）日新月異,各種網路方案和協議日趨復雜,網路規模日趨龐大,對網路研究人員而言,掌握網路模擬的重要性是不言而喻的。WSN模擬能夠在一個可控制的環境里研究WSN應用,包括操作系統和網路協議棧,能夠模擬數量眾多的節點,能夠觀察由不可預測的干擾和雜訊引起的難以琢磨的節點間的相互作用,獲取節點間詳細的細節,從而提高節點投放後的網路成功率,減少投放後的網路維護工作。目前無線感測器網路使用的模擬工具主要有NS2、TinyOS、OPNET、OMNET++等等。其中TinyOS是專門針對無線感測器網路的特點而研究開發的。

二、無線感測器網路模擬簡介

在感測器網路中,單個感測器節點有兩個很突出的特點。一個特點是它的並發性很密集;另一個特點是感測器節點模塊化程度很高.上述這些特點使得無線感測器網路模擬需要解決可擴展性與模擬效率、分布與非同步特性、動態性、綜合模擬平台等等問題。

三、無線感測器網路常用模擬工具

無線感測器網路常用模擬工具有NS2、OPNET、OMNET++、TinyOS,下面我們簡要介紹它們各自的性能和特點。

3.1 NS2
NS是一種可擴展、以配置和可編程的時間驅動的模擬工具,它是由REAL模擬器發展而來.在NS的設計中,使用C++和OTCL兩種程序設計語言, C++是一種相對運行速度較快但是轉換比較慢的語言,所以C++語言被用來實現網路協議, 編寫NS底層的模擬引擎; OTCL是運行速度較慢,但可以快速轉換的腳本語言,正好和C++互補,所以OTCL語言被用來配置模擬中各種參數,建立模擬的整體結構, OTCL的腳本通過調用引擎中各類屬性、方法,定義網路的拓撲,配置源節點、目的節點建立鏈接,產生所有事件的時間表,運行並跟蹤模擬結果,還可以對結果進行相應的統計處理或制圖.NS可以提供有線網路、無線網路中鏈路層及其上層精確到數據包的一系列行為模擬。NS中的許多協議都和真實代碼十分接近,其真實性和可靠性是非常高的。

3.2 OPNET
OPNET是在MIT研究成果的基礎上由MIL3公司開發的網路模擬軟體產品。 OPNET的主要特點包括以下幾個方面:(1)採用面向對象的技術,對象的屬性可以任意配置,每一對象屬於相應行為和功能的類,可以通過定義新的類來滿足不同的系統要求; (2)OPNET提供了各種通信網路和信息系統的處理構件和模塊;(3) OPNET採用圖形化界面建模,為使用者提供三層(網路層、節點層、進程層)建模機制來描述現實的系統;(4) OPNET在過程層次中使用有限狀態機來對其它協議和過程進行建模,用戶模型及OPNET內置模型將會自動生成C語言實現可執行的高效、高離散事件的模擬流程;(5) OPNET內建了很多性能分析器,它會自動採集模擬過程的結果數據;(6)OPNET幾乎預定義了所有常用的業務模型,如均勻分布、泊松分布、歐蘭分等。

3.3 OMNET++
OMNET++是面向對象的離散事件模擬工具,為基於進程式和事件驅動兩種方式的模擬提供了支持。 OMNET++採用混合式的建模方式,同時使用了OMNET++特有的ned(Network Discription,網路描述)語言和C++進行建模。OMNET++主要由六個部分組成:模擬內核庫、網路描述語言的編譯器、圖形化的網路編譯器、模擬程序的圖形化用戶介面、模擬程序的命令行用戶介面和圖形化的向量輸出工具。OMNET++的主要模型拓撲描述語言NED,採用它可以完成一個網路模型的描述。 網路描述包括下列組件:輸入申明、信道定義、系統模塊定義、簡單模塊和復合模塊定義。使用NED描述網路,產生.NED文件,該文件不能直接被C++編譯器使用,需要首先採用OMNET++提供的編譯工具NEDC將.NED文件編譯成.cpp文件。最後,使用C++編譯器將這些文件與用戶和自己設計的簡單模塊程序連接成可執行程序。

3.4 TinyOS
TinyOS是專門針對感測器研發出的操作系統。在TinyOS上編程序使用的語言為nesC(C language for network embedded systems) 語言。

nesC語言是由C語言擴展而來的,意在把組件化/模塊化思想和TinyOS基於事件驅動的執行模型結合起來。 nesC 組件有Mole(模塊)和Configuration（連接配置文件）兩種。在模塊中主要實現代碼的編制,在連接配置文件中主要是將各個組件和模塊連接起來成為一個整體。

TinyOS程序採用的是模塊化設計,所以它的程序核心往往都很小,能夠突破感測器存儲資源少的限制,這能夠讓TinyOS很有效的運行在無線感測器網路上並去執行相應的管理工作等。TinyOS的特點主要體現在以下幾個方面:

(1)組件化編程(Componented-Based Architecture)。TinyOS的組件通常可以分為以下三類:硬體抽象組件、合成組件、高層次的軟體組件;硬體抽象組件將物理硬體映射到TinyOS組件模型.合成硬體組件模擬高級硬體的行為.高層次軟體模塊完成控制、路由以及數據傳輸等。}

(2)事件驅動模式(Event-Driven Architecture)。事件驅動分為硬體驅動和軟體事件驅動。硬體事件驅動也就是由一個硬體發出中斷,然後進入中斷處理函數。而軟體驅動則是通過singal關鍵字發出一個事件。

(3)任務和事件並發模式(Tasks And Events Concurrency Model)。任務用在對於時間要求不是很高的應用中,任務之間是平等的,即在執行時是按順序先後來的,而不能相互搶占,TinyOS對任務是按簡單的FIFO隊列進行處理的。事件用在對於時間的要求很嚴格的應用中,而且它可以佔先優於任務和其他事件執行。

(4)分段執行(Split-Phase Operations)。在TinyOS中由於tasks 之間不能互相佔先執行,所以TinyOS沒有提供任何阻塞操作,為了讓一個耗時較長的操作盡快完成,一般來說都是將對這個操作的需求和這個操作的完成分開來實現,以便獲得較高的執行效率。

(5) 輕量級線程(lightweight thread)。輕量級線程(task, 即TinyOS中的任務)按FIFO方式進行調度,輕量級線程之間不允許搶占;而硬體處理線程(在TinyOS中,稱為硬體處理器),即中斷處理線程可以打斷用戶的輕量級線程和低優先順序的中斷處理線程,對硬體中斷進行快速處理響應。

(6) 主動通信消息(active message)。每一個消息都維護一個應用層和處理器。當目標節點收到這個消息後,就會把消息中的數據作為參數,並傳遞給應用層的處理器進行處理。應用層的處理器一般完成消息數據的解包操作、計算處理或發送響應消息等工作。

TinyOS操作系統中常用的模擬平台主要是TOSSIM和Avrora

（1）TOSSIM(TinyOS simulation)是一個支持基於TinyOS的應用在PC機上運行的模擬器.TOSSIM運行和感測器硬體相同的代碼,模擬編譯器能直接從TinyOS應用的組件表中編譯生成模擬程序。

（2）Avrora是一種專門為Atmel和Mica2節點上以AVR單片機語言編寫的程序提供模擬分析的工具。它的主要特點如下：1) 為AVR單片機提供了cycle accurate級的模擬,使靜態程序可以准確的運行。它可以模擬片上(chip-on)設備驅動程序,並為片外(off-chip)程序提供了有規則的介面;2)可以添加監測代碼來報告模擬程序運行的性能,或者可以在模擬結束後收集統計數據,並產生報告;3)提供了一套基本的監控器來剖析程序,這有助於分析程序的執行模式和資源使用等等;4)Avrora可以用gdb調試程序;5) Avrora可以為程序提供一個程序流圖,通過這個流程圖可以清楚的表示機器代碼程序的結構和組織;6) Avrora中提供了分析能量消耗的工具,並且可以設置設備的帶電大小;7) Avrora可以用來限製程序的最大堆棧空間,它會提供一些關於目前程序中的最大的堆棧結構,和一些關於空間和時間消耗的信息報告。

3.5性能比較

TinyOS 用行為建模,可以模擬跨層協議;模擬程序移植到節點上,不需要二次編碼。
通過對上述幾種模擬軟體的分析比較,我們可以清楚的看到各個模擬軟體的特點、適用范圍,我們可以根據研究需要選擇適合的模擬軟體,使得我們的學習研究可以事半功倍。

結束語

網路模擬技術為通信網路規劃和優化提供了一種科學高效的方法。網路模擬在國內是近幾年才發展起來的,但在國外網路模擬技術已經相當成熟,我們應該大膽地借鑒國外先進技術,促進國內網路模擬技術迅速發展。

參考文獻
【1】於海斌,曾鵬等.智能無線感測器網路.科學出版社,2006,p283～p303,
【2】石懷偉,李明生,王少華,網路模擬技術與OPNET應用實踐,計算機系統應用2006.第3期
【3】李玥,吳辰文,基於OMNeT++地TCP/IP協議模擬,蘭州交通大學學報(自然科學版),2005年8月
【4】袁紅林,徐晨,章國安,TOSSIM:無線感測器網路模擬環境,感測器與儀表儀器 ,2006年第22卷第7-1期

2

集群虛擬伺服器的模擬建模研究

來源：電子技術應用 作者：楊建華 金笛 李燁 寧宇

摘要：闡述了集群虛擬伺服器的工作原理和三種負載均衡方式，通過實例討論了虛擬伺服器的模擬和建模方法，創建了測試和模擬系統性能的輸入和系統模型，並依據Q—Q圖和累積分布函數校驗了其概率分布。

關鍵詞：集群虛擬伺服器負載均衡模擬建模概率分布

隨著互聯網訪問量和數據流量的快速增長，新的應用層出不窮。盡管Intemel伺服器處理能力和計算強度相應增大，但業務量的發展超出了先前的估計，以至過去按最優配置建設的伺服器系統也無法承擔。在此情況下，如果放棄現有設備單純將硬體升級，會造成現有資源的浪費。因此，當前和未來的網路服務不僅要提供更豐富的內容、更好的交互性、更高的安全性，還要能承受更高的訪問量，這就需要網路服務具有更高性能、更大可用性、良好可擴展性和卓越的性價比。於是，集群虛擬伺服器技術和負載均衡機制應運而生。

集群虛擬伺服器可以將一些真實伺服器集中在一起，組成一個可擴展、高可用性和高可靠性的統一體。負載均衡建立在現有網路結構之上，提供了一種廉價、有效和透明的方法建立伺服器集群系統，擴展網路設備和伺服器的帶寬，增加吞吐量，加強網路數據處理能力。提高網路的靈活性和可用性。使用負載均衡機制．大量的並發訪問或數據流量就可以分配到多台節點設備上分別處理。系統處理能力得到大幅度提高，大大減少用戶等待應答的時間。

實際應用中，虛擬伺服器包含的真實伺服器越多，整體伺服器的性能指標(如應答延遲、吞吐率等)越高，但價格也越高。在集群中通道或其他部分也可能會進入飽和狀態。因此，有必要根據實際應用設計虛擬伺服器的模擬模型，依據實際系統的測量數據確定隨機變數的概率分布類型和參數，通過分位點一分位點圖即Q-Q圖(Quaantile-Quantile Plot)和累積分布函數(Cumulative Distribution Functions)等方法校驗應答或傳播延遲等性能指標的概率分布，通過模擬軟體和工具(如Automod)事先分析伺服器的運行狀態和性能特點，使得集群系統的整體性能穩定，提高虛擬伺服器設計的客觀性和設計的可靠性，降低伺服器建設的投資風險。

1 集群虛擬伺服器的體系結構

一般而言，首先需要在集群虛擬伺服器上建立互聯網協議偽裝(Internet Protocol Masquerading)機制，即IP偽裝，接下來創立IP埠轉發機制，然後給出在真實伺服器上的相關設置。圖1為集群虛擬伺服器的通用體系結構。集群虛擬伺服器通常包括：真實伺服器(RealServers)和負載均衡器(Load Balmlcer)。

由於虛擬伺服器的網路地址轉換方式是基於IP偽裝的，因此對後台真實伺服器的操作系統沒有特別要求，可以是windows操作系統，也可以是Lmux或其他操作系統。

負載均衡器是伺服器集群系統的惟一入口點。當客戶請求到達時，均衡器會根據真實伺服器負載情況和設定的調度演算法從真實伺服器中選出一個伺服器，再將該請求轉發到選出的伺服器，並記錄該調度。當這個請求的其他報文到達後，該報文也會被轉發到前面已經選出的伺服器。因為所有的操作都在操作系統核心空間中完成，調度開銷很小，所以負載均衡器具有很高的吞吐率。整個伺服器集群的結構對客戶是透明的，客戶看到的是單一的虛擬伺服器。

負載均衡集群的實現方案有多種，其中一種是Linux虛擬伺服器LVS(Linux Virtual Server)方案。LVS實現負載均衡的技術有三種：網路地址轉換(Network Address Translation)、直接路由(Direct Routing)和IP隧道(IP Yunneling)。

網路地址轉換按照IETF標准，允許一個整體機構以一個公用IP地址出現在Inlemet上。通過網路地址轉換，負載均衡器重寫請求報文的目標地址，根據預設的調度演算法，將請求分派給後端的真實伺服器；真實伺服器的應答報文通過均衡器時，報文的源地址被重寫，把內部私有網路地址翻譯成合法網路IP地址，再返回給客戶，完成整個負載調度過程。

直接路由的應答連接調度和管理與網路地址轉換的調度和管理相同，但它的報文是直接轉發給真實伺服器。在直接路由應答中，均衡器不修改、也不封裝IP報文．而是將數據幀的媒體接入控制MAC(Medium Aceess Control)地址改為選出伺服器的MAC地址，再將修改後的數據幀在區域網上發送。因為數據幀的MAC地址是選出的伺服器，所以伺服器肯定可以收到該數據幀，從中獲得該IP報文。當伺服器發現報文的目標地址在本地的網路設備時，伺服器處理該報文，然後根據路由表應答報文，直接返回給客戶。

IP隧道是將一個IP報文封裝在另一個IP報文中的技術。該技術可以使目標為某個口地址的數據報文被封裝和轉發到另一個IP地址。用戶利用IP隧道技術將請求報文封裝轉發給後端伺服器，應答報文能從後端伺服器直接返回給客戶。這樣做，負載均衡器只負責調度請求，而應答直接返回給客戶，不需要再處理應答包，將極大地提高整個集群系統的吞吐量並有效降低負載均衡器的負載。IP隧道技術要求所有的伺服器必須支持IP Yunnehng或lP.封裝(Encapsulation)協議。

2 集群虛擬伺服器報文延遲的確定

通過一個裝有5台真實伺服器並使用網路地址轉換技術實現Linux虛擬伺服器的實際系統，可以得到有關請求和應答報文的時戳(Time Stamp)文件n根據這些文件．能夠計算出集群虛擬伺服器的模擬和建模所需數據。

為了確定隨機變數分布類型和參數，應該統計下列延遲：(1)從客戶到負載均衡器的傳播延遲(Transport Delay)；(2)負載均衡器的應答延遲(Response Delay)；(3)從負載均衡器到真實伺服器的傳播延遲；(4)真實伺服器的應答延遲；(5)從真實伺服器到負載均衡器的傳播延遲；f61負載均衡器對真實伺服器的應答延遲；(7)從負載均衡器到客戶的傳播延遲。

在實際系統產生的時戳文件中，問接地描述了上述各延遲時間。文件包含的內容如下：

當一個服務請求到達集群虛擬伺服器系統時，即產生帶有惟一序列號的同步請求報文(Synchronized Request Package)，將該報文轉發到某一真實伺服器，同時建立該伺服器與客戶端的連接，每個這樣的連接都帶有惟一的埠號；該伺服器處理通過該連接的確認請求報文(Acknowledgement Request Package)，直到伺服器收到結束請求報文(Finished Request Package)。對每一種類型的請求報文，系統都給予一個相應的應答報文。因此，在不同的報文時戳文件中，如果兩條記錄具有相同的埠號、報文類型和序列號，則它們是同一個請求或應答報文，對相關的時戳相減即可得到集群虛擬伺服器系統的模擬和建模所需的延遲數據。通過所編寫的C++程序即可計算這些延遲。

3 系統模擬模型

上述的集群虛擬伺服器實際系統的模擬模型如圖2所示，在負載均衡器、各通道、5台真實伺服器中通過或處理的均為請求或應答報文。

4 隨機變數模型的確定

對具有隨機變數的集群虛擬伺服器進行模擬，必須確定其隨機變數的概率分布，以便在模擬模型中對這些分布進行取樣，得到所需的隨機變數。

4.1 實際虛擬伺服器的延遲數據概況

在實際虛擬伺服器的負載均衡器、各通道和5台真實伺服器中，對請求和應答報文都有一定的延遲。部分報文延遲的統計數據如表1所示。

由表l中的數據可見，報文延遲的中位數與均值差異較大，所以其概率分布不對稱；變異系數不等於l，導致概率分布不會是指數分布，而可能是γ分布或其他分布。

4．2 隨機變數的概率分布

圖3為第一台真實伺服器到負載均衡器之間的通道報文傳播延遲直方圖，其中t為報文延遲時間，h(t)為報文延遲區間數。由圖3可知，通道內的報文傳播延遲數據近似服從γ分布或對數正態分布。

描述γ分布需要兩個參數：形狀(Shape)參數α和比例(Scahj)參數口，這兩個參數與均值M、方差V之間的關系是非線性的：

描述對數正態分布也需要形狀參數σ和比例參數μ，這兩個參數與均值M、方差V之問的關系也是非線性的：

式(1)～(4)都可以通過最大似然估計MLE(Maximum Likelihood Estimator)方法或最速下降法(Steepest Descent Method)求出。表2給出了甩這兩種方法求出的從第一台真實伺服器到負載均衡器之間通道內的報文延遲概率分布參數。

使用累積分布函數和Q-Q圖可以校驗並進一步確定上述通道內報文傳播延遲的概率分布。取用表2中的參數，可以得到γ分布的累積分布函數，如圖4所示，其中t為報文延遲時間，F(t)為報文延遲的累積分布函數。為作比較，實驗分布也畫在該圖中。γ分布和對數正態分布的Q-Q圖如圖5所示。

由圖4和圖5可以看出，γ分布較好地擬合了該通道內的報文傳播延遲數據分布。其他通道報文延遲直方圖也有類似形狀。經計算和分析，這些通道的報文傳播延遲概率分布也近似服從γ分布。

根據表1中的數據以及相關的直方圖都難以確定在負載均衡器和真實伺服器中報文延遲的理論分布。因此，採用實驗分布作為其模型。

5 模型模擬

在建立了圖1所示的集群虛擬伺服器的系統模擬模型並確定了其隨機變數的分布特性後，可以採用由美國布魯克斯自動化公司(Brooks Automation)開發的模擬軟體Automod輸入該模型，並通過在Automod環境中編程進行集群虛擬伺服器的模擬和分析。

在Automod的模擬過程中，可以直接利用軟體提供的資源(Resource)作為各種報文數據處理的單元；系統各部分的報文排隊活動可以直接通過排隊(Queue)實現；建立一個負載產生器，等效為在Inlemtet上使用虛擬伺服器的客戶。

通過採用Automod的屬性變數(Attribute Variable)可以解決負載均衡器的雙方向報文處理功能的問題。負載均衡器使用輪轉調度演算法(Round Robin Scheling)，即假設所有真實伺服器的處理性能均相同，依次將請求調度到不同的伺服器。

驗證模擬模型可以分別在實際虛擬伺服器系統和Automod的模擬模型中從以下兩方面進行對比：(1)在負載均衡器、各個真實伺服器和通道中排隊的應答或傳播報文數量；(2)真實伺服器及負載均衡器的cPU利用率。例如，當使用實際的應答或傳播報文延遲數據時，在Automod的模擬模型中，如果設置一個較低的資源量，則在模擬過程中就會發現大部分的負載都被堵在真實伺服器的排隊中，即真實伺服器處理報文的能力過低，無法與實際系統的狀況相比；如果設置一個較高的資源量，則意味著伺服器的並行處理能力增加，真實伺服器的利用率提高，負載就很少或不會滯留在真實伺服器的排隊中。因此，在Automod中可以根據實際情況調整模擬模型的資源量大小。

如果在Automod中增加負載產生器的負載產生率，就等效為用戶訪問量增加，通過觀察排隊中的負載滯留比例，就可以發現系統的最大處理報文的能力以及系統各部分應答報文可能出現瓶頸之處。例如，將負載產生率增加一倍，雖然系統仍然可以處理所有的報文，但各台真實伺服器的平均利用率將達80％左右。顯然，這時系統應答報文的「瓶頸」為真實伺服器，有必要在系統中增添一台新的真實伺服器。

通過一個包括5台真實伺服器的實際虛擬伺服器系統。收集並計算了模擬和建模的樣板數據。依據系統報文延遲的中位數、均值、變異系數和直方圖等，確定了系統隨機變數的概率分布；採用最大似然估計方法和最速下降法，得到了通道概率分布的具體參數；根據Q-Q圖和累積分布函數進一步校驗並最終確定通道的概率分布形式。使用Automod軟體進行了模擬建模和編程，藉助模擬結果可以發現虛擬伺服器的最大處理能力和可能的「瓶頸」之處。通過及時定位系統「瓶頸」，可以有的放矢地進一步研究和改進系統，有效提高系統性能。所採用的模擬方法也可以用於其他領域的模擬建模或分析中。

在模擬模型中，負載均衡方式和調度演算法還需要進一步增加，以便於比較不同的虛擬伺服器系統。樣本數據也需要進一步擴充，以避免報文延遲的自相關性。