2014年6月20日 星期五

七樓的介紹 (Application Layer)

七樓實在太豐富了,而且許多房客來來去去,介紹不完。

這裡只簡單介紹兩種基本的架構,不管是什麼樣的網路應用協定,大致上都可將架構分為兩種:
  • Server-Client 架構
  • Peer-to-Peer (P2P) 架構

原則上所有的網路應用協定,都是這兩種在變化組合。

從 OSI 的模型來看,這一層主要是應用的協定,雖然跟應用軟體常常直接相關,但是卻並非指軟體本身,而是軟體背後所使用的協定,例如瀏覽器連上網站背後所使用的是 HTTP/HTTPS,瀏覽器是軟體,而 HTTP/HTTPS 就是應用層的協定。

Server-Client 架構基本上,會有 Server 扮演提供服務的角色,還會有 Client 來向 Server 要求服務,例如 WWW 網頁就是 Server-Client 的架構。許多分散式架構可能也是以 Server-Client 架構為骨幹,不管是階層式的分散,透過一些特別的 Servers 在中間扮演領導者,或者是完全的分散各自為政,Servers 彼此之間透過互動來實踐演算法。

P2P 架構比較複雜,它和 Server-Client 架構主要的差異在於 Client 是否也可以同時當 Server接受別的 Client 的連線,如果 Client 和 Server 的角色可以換來換去,那這種架構通常就是 P2P 架構。

P2P 架構中,主要困難的問題在於原本集中於 Server 的檔案或資料,該如何分散到每一個 Client 身上?另一個困難的問題在於原本 Server 負責協調控制的角色,現在該如何讓大家平權的自主管理呢?也就是說,一個是資料如何流動,另一個是管理如何實踐

除了以上兩個難題之外,P2P 還有以下其他的弱點:
1. ISP 的抱怨:因為 Client 一般是使用類似 ADSL 這種雙向頻寬不同的上網方式,下載的頻寬通常比上傳要大得多,透過 P2P 會使得上傳的流量激增,ISP 會不爽。
2. 網路安全:以往的 Server-Client 架構可以將安全保護集中在少數的 Servers 處,但是 P2P 架構,人人都是 Servers,要如何預防或偵測惡意攻擊者,針對防禦薄弱的 Peers 所帶來的威脅呢?
3. 薄弱的動機:P2P 需要 Client 也來分擔 Server 的角色,提供頻寬與硬碟空間,也必須保持在線上,許多 Peers 在抓取到自己所要的資料後,就立刻離開了,這樣的 Peer 常被稱作 Leech。的確,要在滿足需求後仍然無私的給予自己的資源,這需要夠強的動機。

以 BitTorrent 協定來介紹,我們可以如何面對資料流動管理實踐的困難。

BitTorrent 定義一個特殊的 Server 叫做 Tracker,負責管理針對某些特定檔案分享的 Peers 清單,如果有人要加入那些特定檔案的分享圈圈裡,就要跟 Tracker 註冊。Tracker 和特定檔案的資訊,通常包裝在一筆資料裡,我們稱那筆資料叫 Torrent。

你可能使用過 P2P 下載檔案,通常都需要先取得 Torrent,Torrent 裡面會有 Tracker 資訊,以及定義這個 Torrent 中,Peers 彼此會分享哪些特定的檔案。

檔案上傳或下載都以 Chunk 形式散佈,也就是將檔案切割成許多小單位,每個單位叫做一個 Chunk,所以不同的 Peer 可能會擁有檔案不同的部位。

當我們加入一個 Torrent 所定義的小圈圈裡頭,我們就可以和圈圈內的其他 Peers 連線,取得它們所擁有的 Chunks,每個 Peer 所擁有的可能是檔案的不同部份,下載過程採用一種 rarest first 的作法,也就是會優先下載最少 Peers 擁有的檔案部份,藉此讓稀有的檔案部份在這個小圈圈中擴散的快一點。

檔案的上傳和下載採用一種盡量公平的交換制度,你如果上傳給我許多我想要的檔案資料,你在我眼裡就會等級比較高,以後你向我要資料,我也會盡量滿足你,類似這樣的互惠邏輯,盡可能讓分享者的等級高一些,常常分享的人,未來要下載資料也會容易一點。

還有一個名詞叫做 Seed,也就是一個可分享的完整檔案。當你取得了某個檔案的全部 Chunks,意思是你已經不需要再下載了,這個時候我們就說你已經擁有了那個檔案的 Seed,你之後能做的就是純分享 (Seeding),貢獻給其他人。如果一個 Torrent 所定義的小圈圈裡都沒有人分享 Seed,大家也就不可能取得完整的檔案。

原本在 Server-Client 架構中,資料庫的資料可以存放在 Server 內,Client 在做查詢或搜索的時候,只要透過 Server 就可以。但是在 P2P 的架構下,查詢或搜索的功能,是透過每一個 Peer 通力合作來完成,因此需要將資料分散儲存於 Peers 中。

資料庫查詢的資料通常是 {key, value} 這樣的抽象形式,透過 key 查詢可以得到 value 的值。

作法就是將每個 Peer 命名一個 ID,然後不管 key 是什麼,讓 key 通過雜湊運算,得到 hash key,設法讓 ID 和 hash key 是在同一個定義域裡面,例如同樣都是 32 位元整數,這樣就可以實現 P2P 的資料庫分散功能,這樣的技術我們稱為 Distributed Hash Table (DHT)。

關鍵在於把 Peer 的 ID,和 key 的 hash 數值對應到同一個定義域

往後,我們要存資料,就把該 key 做 hash,然後把資料 {hash key, value} 存在 ID 最接近的那個 Peer 那裡,以後要查資料,也只要將 key 做 hash,然後去 ID 最接近的那個 Peer 那裡查就知道了。

另外,我也不需要隨時保留所有 Peers 的資訊,才能夠與任何一個 Peer 做連線,只要照著 ID 大家排成一個圈,我只要記得我的下家,然後要連到誰,就透過下家一個一個去問,就會問到某 Peer 的連線資訊了。

這種排成一個圈的作法,排出來的那個圈叫做 Overlay Network,代表這並非實際的地理位址或者網路拓樸是一個圈,而是抽象概念上我把它看作一個圈。Overlay Network 當然不一定要是圈,任何抽象概念的網路模型都可以叫做 Overlay Network。

實作上,通常還會加上 Shortcut 機制,也就是除了下家以外,再多連幾家,讓問的速度加快,也減少問的人數。另外,為了怕有人隨機離開圈圈,除了下家外,也還會記下下家,這樣下家或下下家其中一個忽然走了,我還可以問另一個家,以取得新下家或新下下家的資訊。

以上,就是 P2P 通常如何解決資料分享機制,以及控制管理的一些概念介紹。P2P 架構通常比 Server-Client 架構要複雜一些。

我這裡的介紹超級簡短的,實際的運作還是要回到特定協定的規格上面,協定規格不同,實作方法就會不一樣,但是大多跨越不出 Server-Client 以及 P2P 兩種架構,或者是它們的組合變形。

沒有留言:

張貼留言