第三章 系統架構
3.1.3 Split 程序
3.1.2 節中我們就『當總流量超過安全值，調節頻寬時可最小化視訊品質之降 低』的原則發展出 Merge 程序，此程序不但可以在系統頻寬不足時有效釋出頻寬，
讓系統容納更多的使用者，同時在釋出之頻寬與損失的視訊品質上也取得平衡。
在 Merge 程序中，我們會把高視訊品質群組合併到低視訊品質群組裡，此作 法會犧牲掉當初選擇高視訊品質群組使用者的視訊品質。
在這邊我們考慮一個情境，剛開始時使用者大量湧入，系統流量漸增，接著 超出流量安全範圍，此時系統將會啟用 Merge 程序，有些高視訊品質群組的使用 者將會被併入低視訊品質群組裡，並且釋出頻寬。過了一段時間後，使用者開始 離開串流伺服器，系統的流量漸漸下降，接著到達頻寬餘裕的狀況，在這種狀況 下我們是希望讓每位使用者都可以獲得他所要求的視訊品質，如此不只可以善用 我們所租用之頻寬，也可以讓使用者獲得較好的服務。
在本節中我們使用前述之群組架構，以及在 Merge 程序過程當中，群組群組 之間的合併資料，發展出調整串流視訊品質之方法─Split 程序。
Split 程序概念在於紀錄下在 Merge 程序時，從高視訊品質群組併入低視訊品
質群組的使用者，當系統察覺到流量到達餘裕的狀況時，將計算頻寬─視訊品質 比回復某些當初被影響到的高品質視訊使用者，以求在提高這些使用者的視訊品 質的同時也可以兼顧到調節頻寬，在頻寬調節與視訊品質中取的最大利益。
第三章 系統架構
Split 程序步驟如下：
(1) 察覺系統總流量低於安全流量值，啟動 Split 程序。
(2) 檢查系統資訊中是否有被Merge的群組。[檢查S
merge
集合中是否有被Merge 的群組]第三章 系統架構
圖 3-5 為 Split 程序的流程圖：
No
Every △T check B
total
( G n i G n j ) S merge
Cost
find max , , , ∈
split G
n,i
from Gn,j
Check B
total
is still under boundary?End
No Yes
B
total
is under boundary?Yes Is there any group
been merged?
Yes
圖 3-5 Split 程序流程圖
從系統流量使用量角度來看，我們可以將這些程序以圖 3-6 的有限狀態機 (Finite State Machine)來表示，其中各種狀態表示系統流量的狀況，一開始的系統 為 Under Boundary 狀態，大量的使用者加入後系統會跳到 Normal 狀態之後再跳 到 Over Boundary 狀態，此時使用 Merge 程序後將會回到 Normal 狀態，當使用者
第三章 系統架構
大量離開後會跳到 Under Boundary 狀態。我們此時使用 Split 程序回復某些使用 者的視訊品質。
Over Boundary
Split Procedure, Users Join Users Leave
Users Join
Normal B
total
Merge Procedure, Users Leave
Users Leave Under
Boundary Users Join
圖 3-6 串流系統之有限狀態機
第三章 系統架構
3.2 實現法則之視訊串流伺服器架構
此節中將介紹本研究所建置的視訊串流伺服器，視訊串流伺服器端主要由
『視訊串流模組』、『控制模組』以及『頻寬管理模組』幾個部份所構成。使用者 端則由『使用者行為模擬模組』、『觀看介面』等兩部分所組成。
其中『虛擬使用者模組』是為了測試視訊串流伺服器的實際運作而特別開 發，此虛擬使用者模組可以模擬使用者行為，讓我們在測試串流伺服器時可以自 動化測試，此虛擬使用者模組支援本論文開發的模擬程式之情境劇本(scenario)。
3.2.1 模組介紹
本系統的實作選用 Linux 為作業系統，各模組透過修改以及整合 Linux 上的 開放原始碼專案(Open Source Project)來達到主要功能。
選用 Linux 為作業系統有幾點好處：
(1) Linux 開放原始碼較方便修改在開發上彈性高，開發成本也較低。
(2) 開放原始碼專案支援度較高，許多的開放原始碼專案都以 Linux 平台所發 展，因此透過整合開放原始碼的專案可以縮短開發時間也可以節省成本。
以下將介紹各模組的功能以及所使用的軟體：
伺服器端(Server)：
視訊串流模組：採用 2.2 節所介紹的 VLC (VideoLAN Client)專案做為多
第三章 系統架構
媒體串流伺服器。此專案擁有多樣化的輸出及輸入格式，且整合了包含
FF MPEG、x264 等的多種開放原始碼函式庫，可以支援多樣化的的多媒 體格式。
控制模組：主要由資料庫伺服器以及網頁伺服器兩部分所組成，資料庫 伺服器方面使用 MySQL Server[12]，網頁伺服器方面使用 Apache
Server[11]。管理者藉由網頁介面來管理串流資訊、播放內容以及使用者 資訊，而儲存資料方面則由資料庫處理。
頻寬管理模組：主要以我們所發展的演算法為核心，依靠控制模組所儲 存的數據，透過 Ajax 語法變更使用者所接收到的串流，來達成頻寬管理。
使用者端(Client)：
觀看介面：觀看介面我們選擇使用 windows media player 元件，因為微 軟的 windows 作業系統為最普遍使用的作業系統，因此使用者只需瀏覽 內嵌 windows media player 元件的網頁便可觀賞頻道，不需另外安裝軟 體，減少使用者的進入門檻。
虛擬使用者模組：本論文使用 Ajax 語法寫了一個內嵌在使用者端的行為 模擬模組，其運作內容主要是從伺服器取得操作行為，然後透過我們所 設計的 API 操作觀看介面，以此來模擬使用者觀看影音串流之狀況。舉 例來說，我們可以設定好一個情境劇本其內容為，使用者在頻道二的第
第三章 系統架構
一個群組觀看一段時間後，大多數會跳轉到頻道二的第一個群組，用此 來模擬使用者轉台的行為。而使用者端的模擬運作為(1)取得行為連結到 頻道二 (2)取得行為跳轉到頻道三。這中間的轉台或是斷線都由我們所 設計的 API 來操作。
圖 3-7 虛擬使用者程式的運作流程：
圖 3-7 行為模擬模組運作流程
第三章 系統架構
3.2.2 串流伺服器架構
本系統的使用者只需要瀏覽我們內嵌 windows media player 元件[8]的網頁便 可觀賞頻道，因此我們藉由網頁伺服器透過伺服器端的動態語法，管理以及存取 串流伺服器，圖 3-8 為本系統架構圖。
圖 3-8 系統架構圖 系統運作流程：
(1) 使用者透過瀏覽器連結到我們所設計的網頁，選擇欲觀看的頻道群組。
(2) 使用者資訊透過網頁伺服器存到資料庫。
(3) 透過網頁伺服器解析使用者的要求，同時設定串流伺服器。
(4) 回傳串流伺服器位置給使用者。
第三章 系統架構
(5) 使用者透過內嵌的 windows media player 元件連結串流伺服器，然後向串 流伺服器要求串流資料。
(6) 串流伺服器傳送串流資料，使用者使用 windows media player 元件播放串 流多媒體。
圖 3-9 為本系統運作流程。
圖 3-9 系統運作流程
第四章 研究與實做方法
第四章 實驗數據與系統效能分析
在上一章中，我們介紹了動態頻寬管理視訊串流法則以及視訊串流伺服器的 基本架構。為了驗證我們所提出的動態頻寬管理視訊串流法則，以及觀察串流伺 服器實際運作情形，我們在本章中將提出數種不同的情境，接著以模擬程式以及 本論文所實際架設的串流伺服器去測試這些情境，然後獲得各種數據。最後藉由 分析這些數據，討論本論文所提出的法則是否可以有效的運作。
4.1 模擬情境說明
在呈現我們的數據之前，首先必須先說明整個模擬情境。我們總共有三個模 擬情境，其設定分別如下：
(1) 模 擬 情 境 一 ： 在 模 擬 情 境 一 ， 我 們 設 定 串 流 系 統 擁 有 3 個 頻 道 (Channel)，每個頻道擁有高畫質、中畫質、低畫質三個群組(Group)，系統 頻寬的安全區域(Normal B
total
)在租用頻寬的 80% ~ 85%。系統使用者設定在100 位，每個使用者有 4 種狀態，分別是閒置、觀看頻道一、觀看頻道二、
觀看頻道三，各頻道之數據列於圖 4-1。系統情境設定分為兩段，前半段使 用者隨意選擇加入頻道及群組，後半段使用者漸漸跳到頻道二。
(2) 模 擬 情 境 二 ： 在 模 擬 情 境 二 ， 我 們 設 定 串 流 系 統 擁 有 3 個 頻 道 (Channel)，每個頻道擁有高畫質、中畫質、低畫質三個群組(Group)，系統 頻寬的安全區域(Normal B
total
)在租用頻寬的 80% ~ 85%。系統使用者設定在第四章 研究與實做方法
100 位，每個使用者有 4 種狀態，分別是閒置、觀看頻道一、觀看頻道二、
觀看頻道三。系統情境設定分為三階段，第一階段使用者隨意選擇加入頻 道及群組，第二階段使用者漸漸跳到頻道二，第三階段使用者漸漸離開串 流系統。
圖 4-1 情境一、二之頻道數據
(3) 模 擬 情 境 三 ： 在 模 擬 情 境 三 ， 我 們 設 定 串 流 系 統 擁 有 9 個 頻 道 (Channel)，每個頻道擁有高畫質、中畫質、低畫質三個群組(Group)，系統 頻寬的安全區域(Normal B
total
)在租用頻寬的 80% ~ 85%。系統使用者設定在1000 位，每個使用者有 10 種狀態，分別是閒置、觀看頻道一、觀看頻道 二、…、觀看頻道九。系統情境設定分為三階段，第一階段使用者隨意選 擇加入頻道及群組，第二階段使用者漸漸跳到頻道二與頻道五，第三階段 使用者漸漸離開串流系統。
在實驗過程中，前兩個情境我們會應用在串流系統以及模擬程式上，
接著收集相關數據，然後比較、分析所收集到的數據。而情境三會應用在
第四章 研究與實做方法 模擬程式上，接著分析其數據，用來預測在 1000 位使用者的狀況下，實際 的串流系統會如何運作。
4.2 串流系統測試說明
本章的實驗數據分為兩部分，第一部份為模擬程式所測得的數據，第二部份 為實際架設的串流系統所測得的數據。在本節中將簡介我們如何測試串流系統，
在測試系統時遇到最大的問題在需要足夠的使用者以及機器。本論文的系統測試 環境使用本系的電腦教室，其配備有 50 台左右的電腦供測試使用，圖 4-2 為測 試系統時電腦教室一隅。
圖 4-2 串流系統測試畫面(一)
除了電腦的問題外，測試時遇到的另一個問題為使用者人數，因為本次測試 需要用到 100 位使用者以上，這對於要常常做測試的本實驗是很麻煩的一件事，
第四章 研究與實做方法 因此我們特別開發了內嵌於觀看網頁上的虛擬使用者程式，在測試時先連到我們 的網頁介面，如圖 4-3 所示，接著透過內嵌的虛擬使用者程式來模擬一個使用者，
此程式會隨著伺服器端的劇本行為去操縱觀看介面，如此可以把一個連到觀看介 面並且開啟虛擬使用者程式的瀏覽器模擬成一位使用者，如圖 4-4 及圖 4-5 所
此程式會隨著伺服器端的劇本行為去操縱觀看介面，如此可以把一個連到觀看介 面並且開啟虛擬使用者程式的瀏覽器模擬成一位使用者，如圖 4-4 及圖 4-5 所