第二章 背景說明
2.1 線上即時傳呼系統的背景
線上即時傳呼系統中,使用者都可以擁有屬於自己的一份好友名 單,當使用者 A 上線時,伺服器便會通知 A 的好友 A 上線的訊息,也 會告知 A 有哪些好友正在線上,當雙方都在線上,便可以開啟一個視 窗來進行傳送與接收訊息的動作。
2.2 線上即時傳呼系統的使用情境
而系統為了要達到讓使用者知道好友是否在線上以及傳送訊息 給線上的好友,需要實作三種功能[3][4]:
一、 訂閱好友的狀態:
當使用者連上伺服器的時候,可以訂閱自己想知道狀態的對象,
伺服器便會通知使用者這些人的狀態。如圖 2-1,A 向伺服器訂閱 B、
C、D、E、F 的狀態。
圖 2-1 訂閱好友的狀態
二、 通知訂閱者所需要的資訊:
當被訂閱者狀態改變的時候,伺服器會主動通知訂閱者。如圖 2-2,B、C、D、E、F 有訂閱 A 的狀態,當 A 狀態改變時,伺服器便 會通知 B、C、D、E、F。
圖 2-2 通知訂閱者所需要的資訊 三、 傳送訊息:
使用者可以透過伺服器傳送即時訊息給其他線上使用者,其他人 也同樣能傳送即時訊息給自己。
而對使用者來說,基本上會有四種行為:
一、 登入:
當 A 使用者進入系統時,系統會將 A 所訂閱的使用者資訊傳給 A,
而將 A 的上線資訊傳送給有訂閱 A 資訊的使用者。如圖 2-3,A 有訂 閱 B、C、D、E、F 的狀態,E、F 有訂閱 A 的狀態,當 A 進入系統的 時候,系統會傳送給 A 他所訂閱的 B、C、D、E、F 使用者資訊,並且 將 A 的上線資訊傳送給有訂閱 A 狀態的 E、F 使用者。
圖 2-3 使用者登入 二、 登出:
當 A 使用者離開系統的時候,系統會將 A 的離線資訊傳送給有訂 閱 A 狀態的使用者。如圖 2-4,E、F 有訂閱 A 的狀態,當 A 離開系統 的時候,系統便會通知 E、F。
圖 2-4 使用者登出
三、 傳送訊息:
使用者透過伺服器傳送訊息。如圖 2-5,A 透過伺服器傳送訊息給 E。
圖 2-5 傳送訊息 四、 改變狀態:
當使用者改變自己的狀態(線上、離線、忙碌、離開),伺服器會 通知訂閱者。如圖 2-6,E、F 有訂閱 A 的資料,當 A 將狀態改成離開,
伺服器便會通知 E、F。
圖 2-6 改變狀態
2.3 線上即時傳呼系統的發展狀況
目前關於線上即時傳呼系統的研究[19],多半都是關於使用者行 為的分析。這些研究是使用訊息的記錄來分析,調查上班族等對象使 用線上即時傳呼系統的行為模式 [10]。
當今較著名的線上即時傳呼系統有 MSN Messenger、ICQ、Yahoo Messenger、YamQQ、Skype 等軟體,表 2-1 是 2001 年美國的線上即 時傳呼系統使用情形的調查結果[22],可以看到較多人使用的是 AOL[1][20],其次是 MSN Messenger、Yahoo Messenger、ICQ,這些 系統功能已經相當完善,傳輸檔案,語音視訊交談等功能都可透過線 上即時傳呼系統做到。但是由於考量到市場的競爭,較少做公開的線 上即時傳呼系統的系統效能分析。
AOL 46%
MSN Messenger 20%
ICQ Chat 8%
Yahoo Messenger 13%
Other Protocols 13%
表 2-1 2001 年美國線上即時傳呼系統使用情形
2.3.1 ICQ
根據 ICQ 所公布的資料[18],可推測出 ICQ 的系統構造如圖 2-7。
圖 2-7 ICQ 系統架構
主要的通訊方法有兩類:Client-Server 間通訊及 Client-Client 間通訊。
一、 Client-Server
Client 與 Server 間的通訊協定為 UDP,每個 UDP 封包加密後從 Client 端送到 Server,而 Server 回傳的訊息則不作加密動作。由於 是用 UDP 在傳輸封包,又要能確保封包能送達,因此需要實作 reliable 機制,一端接收到封包之後,需回傳 ACK 回去。另外 ICQ 封包需加入自己的 Header,包含了 SEQ_NUM、COMMAND、SESSION_ID 等欄位,以便 Server 辨別封包是由哪個使用者所送出來的。
二、 Client-Client
Client 與 Client 間的通訊協定主要為 TCP,系統在使用者上線 的時候,會告知其好友的狀態、IP、Port 等資料,當使用者需要傳 送訊息時,便會先以 UDP 傳輸自己的 IP 及所開啟的 port 給對方,對 方再根據資料連線過來建立 TCP 連線,之後便用 TCP 傳輸,進行聊天 的動作,當使用者無法直接連線的時候,所要傳送的訊息便轉由 Server 轉送。
ICQ 系統架構的優點在於:高效率及伺服器不需要額外佔用連線數 目。但其缺點有:需實作偵測斷線機制、程式開發的成本相當高、訊 息易被攔截攻擊。
2.3.2 AOL
AOL 的系統構造圖如圖 2-8。
圖 2-8 AOL 系統架構
Oscar(Open System for Communication in Realtime)是 AOL 所 發展出來的 IM 系統通訊協定。AOL 是多 Server 架構,主要分為兩種 Server : Authorization Server 及 BOS (Basic Oscar Service) Server。Authorization Server 負責認證的動作,以及回傳給使用 者 Cookie,以便使用者連線至 BOS Server 時確認身份。BOS Server 主要是提供線上狀態及即時訊息服務。Server 與 Client 間的通訊是 以 TCP 來傳輸。
系統運作的流程主要分為兩個大步驟:
一、 連線至 Authorization Server
連 線 至 Authorization Server , Server 會 回 傳 Connection Acknowledge 的訊息。使用者再發出 Authorization Request,Server 所 回傳的 Authorization Response 中會帶有 Cookie 以及 Client 所要連線 的 BOS Server 位置,此時 BOS Server 由 Cookie 便可辨認身份,不需 要再作認證的動作。
二、 連線至 Authorization Server 所建議的 BOS Server
連線至 Authorization Server 所建議的 BOS Server ,Server 會回 傳 Connection Acknowledge 的訊息。使用者再送出 BOS Sign On 的指 令,Server 回傳 BOS Host-Ready 訊息告訴使用者已經準備好能開始 服務。使用者詢問 Server 他所能傳輸的最大速率為何,當超過此值 時,連線將自動中斷。使用者向 Server 要求好友的資訊,Server 回傳 便將資訊儲存下來。使用者送出 Client Ready 的指令,告知 Server 已 經準備好能開始服務。
AOL 架構的優點在於:無須實作偵測斷線機制、減少被攻擊的 可能性。但其缺點是 BOS Server 間的通訊量極大,人數多時會影響 其可延展性。
2.3.3 MSN Messenger
MSN Messenger 是微軟公司在 Windows 平台上所提供的,在 linux 上也有實作一套功能較少的版本,也由於程式不需再另外安裝,故使 用者人數增加十分快速,2000 至 2001 的使用者人數就由九百萬人增 加到一千八百萬人。
MSN Messenger 所提供的功能如下:
z 傳送訊息
z 支援多國語言
z 傳送檔案
z 影音交談
z 邀請好友玩遊戲
z 封鎖使用者訊息
z 遠端協助
z 共用白板
比前面所提到的線上即時系統功能更多,因此要支援如此多的 能,便需要更有效能的系統。MSN Messenger 的系統構造如圖 2-9。
圖 2-9 MSN 系統架構
由於 MSN Messenger 有網站公布其通訊協定,因此我們可以知道 更確切的資訊,它彼此間都是用 TCP 連線來傳送訊息,主要的通訊 都是在 Client 與 Server 間,只有部分功能會使用 Client 與 Client 間互 連,如檔案傳輸。
它主要分成三種 Server:Dispatch Server、Notification Server、
Switchboard Server。Dispatch Server 負責認證及分配使用者到適當 Notification Server。Notification Server 負責線上狀態服務,記錄使用 者的線上狀態及所在位置等資訊。Switchboard Server 負責即時訊息 服務,轉送使用者的聊天訊息,與其他 Server 間的通訊量極少。
1. 使用者連線至 Dispatch Server。
2. Dispatch Server 回傳一台可用的 Notification Servers 給使用者。
3. 使用者連線至 Dispatch Server 所分配的 Notification Server,並取 得好友的線上狀態及位置等資訊。
4. 當使用者狀態改變或是要與好友聊天時,會發出 Request 告知 Notification Server。
5. 若使用者要與好友聊天,Notification 會回傳一適當的 Switchboard Server,並告知對方的 Notification Server 也通知對方需連線至此 Switchboard Server。
6. 使用者便透過 Switchboard Server 傳送訊息。
另外我們還對 MSN Messenger 的 log 做分析,得到了兩點發現:
當一使用者短時間重複登入,所分配到的 Notification Server 都不相 同,可知 MSN 並未考量 Locality 的性質,並沒有將彼此有好友關係 的人集中起來。另外在分配 Switchboard Server 的部分同樣也是會被 分配到不同的 Server,因此聊天視窗一增加,連線數也會跟著增加。
原則上,MSN 架構保有 AOL 架構的優點,此外 Switchboard Server 影響增加可延展性。
3. MSN Messenger 中 Switchboard Server 的設計,也會納入我們的實 驗中。
第三章 線上即時傳呼系統的設計
在這一章中,主要介紹我們所設計的線上即時傳呼系統的架構第 3.1 節介紹我的設計目標,第 3.2 節介紹我的設計內容,第 3.3 節說 明 Login Server 的設計,第 3.4 節說明使用者資訊的維護方式,第 3.5 節介紹即時訊息服務的運作方式,第 3.6 節介紹伺服器之間的通 訊方式。
3.1 設計目標
希望能讓系統盡可能支援越多使用者越好。因此,實驗主要分成 兩步驟:
1. 找出單一伺服器的極限,能支援到多少人。
2. 測試多種架構,得出多台伺服器架構的極限,並盡可能的提升最 大支援人數。
3.2 設計
多台伺服器主要需要考量的因素如下:
1. 延展性
最大連線數、記憶體、CPU 及網路傳輸都會是單一伺服器的問 題,因此需要增加伺服器。
2. 平衡伺服器的 CPU 負載量,可增加延展性。
3. 容錯
單一伺服器容易因為被攻擊就造成整個系統當機,增加多台 伺服器可避免此情形。
而多台伺服器對於架構上的差異,經分析之後有四種考量因素:
一、依照功能來分離伺服器
1. Login Server(LS)負責認證及分配使用者。
2. Messaging Server(MS)負責線上狀態服務。
3. Talk Server(TS)負責即時訊息服務。
二、維護使用者資訊
1. 集中型維護,由一台伺服器來維護所有使用者的資訊。
2. 分散型維護,由多台伺服器利用廣播的方式來維護使用者資訊。
三、即時訊息服務的運作方式
1. 由傳送訊息的使用者所在的伺服器轉送訊息給接收訊息的使用 者所在的伺服器,再轉送給接收訊息的使用者。
2. 使用者雙方共同連線至另外的聊天專用伺服器進行聊天。
3. 傳送訊息的使用者額外建立連線至接收訊息的使用者所在的伺 服器進行聊天。
四、伺服器之間的通訊方法
1. 伺服器之間是使用 TCP 或是 UDP 來溝通。
2. 伺服器之間是否使用額外的內部區域網路來連接。
3.3 Login Server
若只是單純的將伺服器加多,必定會出現問題,例如在登入的時 候,使用者並不知道該連線到哪台伺服器,而且也需考量到伺服器負 載的平衡性。
這個問題的解決方法需要一台 Login Server,來分配使用者到適 當的伺服器。如圖 3-1,A 先連線到 Login Server,接收到要連線到 MS1 的訊息,便連線到 MS1。
圖 3-1 Login Server 分配使用者
3.4 維護使用者資訊
在傳送訊息的時候,伺服器並不知道其他伺服器上面有哪些使用 者,當被傳訊的對象不在此伺服器時,便不知道如何轉送訊息。如圖 3-2,使用者 A 要送訊息給使用者 E,但是 MS1 並不知道 E 位在 MS3,
便無法轉送訊息。
圖 3-2 多伺服器架構轉送訊息的問題
圖 3-2 多伺服器架構轉送訊息的問題