P-L-P 小站

網路芳鄰要使用的底層協定﹐沒錯﹐就是 NetBIOS 沒錯﹐但在實作上﹐還要透過 NetBEUI才能完成﹐但這是個‘非路由’協定。如果遇到路由環境的時候﹐NetBEUI 就派不上用場了﹐這時候就必須借助 NetBIOS over TCP/IP(後文簡稱 NoT) 的技術才能做到。(相對於 NoT﹐您甚至可以想象前者為 NetBIOS over NetBEUI﹐但這並非準確的描述﹐因為 NetBEUI 已經包含 NetBIOS 在裡面了。)

在更進一步了解 NoT 之前﹐先讓我們了解 NetBIOS 和 NetBEUI 的分別及其發展歷史。

NetBEUI

讓我們回到 IBM 最初進軍個人電腦網路的時代﹐他們當時的確需要一個很基本的網路通訊協定﹐但他們並不打算用此來建構大型網路﹐僅僅供數十台電腦甚至更小的網路而已。基於這個訴求﹐就誕生了 Network Basic Input/Output System﹐或稱 NetBIOS。

NetBIOS 其實只有 18 個命令(command)來讓網路的電腦能夠建立﹑維持﹑和使用連接服務。不過 IBM 在不久後又再推出了 NetBIOS 的延伸版本﹕NetBIOS Extened User Interface﹐或稱 NetBEUI﹐基本上是 NetBIOS 的改良版本而已。然而﹐NetBIOS 和 NetBEUI終究是不同的﹕NetBEUI 事實上可以說是一個傳輸協定﹐而 NetBIOS 充其量只是一組命令來讓系統可以使用網路而已﹐在技術角度來看﹐它是一個 Application Program Interface (API)。

NetBEUI 可以算是您能夠用到的最快通訊協定了。這個“最快”是指它可以將格式化資料放進封包裡面﹐而接收節點又可以迅速的解讀到內容。然而﹐NetBEUI 卻有一個最致命的弱點﹕它不是可路由(routable)協定﹐也就是不能夠和其它網路的機器對講。NetBEUI 在本地網路裡面是非常優秀的協定﹐但如果您想和設在其它網路的機器溝通﹐NetBEUI 就不是您所需要的了。如果您想實現和其它網路的電腦溝通﹐您極有可能必需通過路由設備或路由軟體來實現﹐但無論用哪一樣﹐很遺憾﹐NetBEUI 都做不到。

不過﹐Microsoft 網路則運用一種叫 NetBIOS over IP 的技術﹐來連接不同網路的NetBEUI 客戶。但歸根結底﹐用來達成路由的不是 NetBIOS 而是 TCP/IP﹐也就是下一個要介紹的協定。

TCP/IP

(略 ...)


由此可見﹐在 Microsoft 網路中﹐假如在同一個網路中﹐您可以直接用 NetBEUI 協定來提供網芳服務﹔如果在不同的網路中﹐則使用 NoT 來達成。當然﹐就算在同一個物理網段中﹐您也可以不使用 NetBEUI 而採用 NoT﹐不過執行效率上或不如 NetBEUI (暫時撇開網路體積的影響而言﹐這點以前辯論過了﹐不再重複﹐有興趣請參考 http://www.study-area.org/tips/nbh.htm )。

這裡讓我們集中在 Server Message Block (SMB) protocol (也稱為 Session Message Block﹑NetBIOS 或 LanManager protocol)﹐ 以及網路芳鄰的溝通建立過程。

SMB 協定主要提供一套機制給主機獲取網路中的機器列表﹐也就是所謂的 Browse List(後文簡稱 BL)。當使用 SMB 協定的 client 在連上網路的時候﹐或是說在啟動 SMB 服務的時候﹐會首先向網路進行廣播﹐查詢管理 BL 的主機﹐也就是所謂的 Local Master Browser(後文簡稱 LMB)﹐以了解網路上到底有哪些主機存在﹐同時向 LMB 進行自己的註冊﹐這樣﹐就可以讓其它主機透過更新後的 BL 得知其存在。

假如在第一輪查詢的時候沒得到 LMB 的回應﹐那機器就會提出 LMB 競選(Master Browser Election)請求﹐然後所有收到這個請求的機器﹐也都參與競選﹐競選的規則其中一個很重要的依據是它的 OS Level。通常來說﹐WfWG﹑Win9x 這些機器﹐其 OS Level 都為 2 ﹐而domain controller 則為 32 。

假如 OS Level 越高﹐則越容易勝出競選﹐這也是為什麼 NT 的 PDC 老會搶贏的原因﹐就是因為它的 OS Level 最高的緣故(DC 在加入網路的時候﹐不管網路是否已經有 LMB 存在﹐都會提出競選要求。在 domain 層級的 Domain Master Browser (DMB) 競選﹐通常每5 分鐘進行一次)。

如果在 OS Level 平等的情況下﹐就是誰先搶誰先贏。因為﹐如果該機器是第一個加入網路的﹐當然是沒有別人來跟他競選﹐可以肯定是由這台機器來擔當 LMB 的角色。而後來加入的﹐因為已經有 LMB 的存在﹐也無需進行競選﹐而只需向 LMB 查詢網路上的機器名單﹐以及向 LMB 進行註冊。根據自己的角色和提供的服務類別﹐每台機器都使用相應的Registration Code﹐例如 UNIQUE 之 00 是機器名稱﹑03 是 WINS﹑1B 是 DMB ﹔GROUP 之 1E 是 group 名稱﹑01 是 Master Browser .... 諸如此類的﹐大家可以用 nbtstat 命令查詢得到。當然﹐機器的註冊是有一定時效的﹐必須有一套機制來確保註冊的準確性﹐同時維持 LMB 的存在。具體細節這裡不再描述了﹐但您要知道﹐如果原本的 LMB 退出網路之
後﹐會導致新的一輪競選﹐從而繼續向網路提供 BL 服務﹐但過程可能需要一點時間。

無論如何﹐要記住一點﹕在 BL 上並沒有說明哪台機器有哪些分享提供﹐而是告訴您在哪個GROUP 裡面有哪些機器且他們的角色是什麼而已。假如機器有進行檔案分享的話﹐那它的UNIQUE 就會有一個 20 的註冊﹐但究竟上面有哪些分享呢﹖就需要直接向該註冊機器查詢了﹐這時候開始﹐就不再需要 LMB 的參與。但只要您能順利從 LMB 上獲得 BL﹐那您可以在網路芳鄰上看到對方的機器存在﹐但當您用滑鼠點那台機器的時候﹐就開始轉為直接查詢模式了。(這裡﹐您應該知道為什麼有時候機器關掉了﹐還會在網路芳鄰上看到那台機器好一陣子﹐是因為 BL 上面還沒更新的緣故。)

接下來﹐當直接向機器進行查詢的時候﹐對方會首先根據它的分享模式進行判斷﹐看看需要採用哪種驗證模式(Authentication)﹐這也因作業系統的不同而有所差別﹐假如是 Win9x機器﹐預設上是採用 share 模式﹐其分享驗證以資源本身的密碼為依據﹐只要對方能符合資源規定的密碼﹐就可以了(根據某些資料顯示﹐這個密碼非常容易破解﹐最多進行 96 次嘗試就可以)﹔假如資源分享修改為 user 層級﹐則需要為該 user 建立相應的帳號﹐只有通過帳號的密碼驗證才可以。如果當前 login 的名稱﹐並沒有在對方上有相應的帳號﹐那會嘗試轉為 guest 身份進行瀏覽﹐如果 guest 也沒提供﹐那就不能通過驗證﹐結果會拒絕您的分享請求﹔假如資源分享以 domain 為依據﹐那登錄的帳號﹐必須已經通過 domain 的
驗證﹐並獲得合法的 token 才能使用資源(這就有點複雜了﹐有興趣參考 NT 的書籍吧)。

Okay﹐相信到這裡﹐大家已經明白到網路芳鄰是怎麼工作的了吧﹖不過﹐上面是假設在local 上以 workgroup 形式組成的 Microsoft Network 環境之上﹐而且是使用 NetBEUI 協定。

如果不採用 NetBEUI 而是 NetBIOS over TCP/IP 又如何呢﹖

在 NoT 技術上﹐非常關鍵的一個條件是 NetBIOS Name 和 IP 位址的對應。在 NetBIOS 協定中﹐所有主機必須獲得一個唯一的 NetBIOS Name 才能加入這個家庭﹐如果採用的名稱已經被別的機器先行註冊了﹐就會出現名稱衝突現像﹐那麼後來加入的機器就不能進入網路﹐當然也不能使用網路上的資源。在 IP 協定上﹐也同樣存在 IP 唯一性的問題﹐在 Win9x的系統上﹐IP 也是誰先搶誰先贏。

您必須同時確定 NetBIOS Name 和 IP 都是唯一的﹐而且必須要有一套機制進行對應﹐也就所謂的 X-Node 模式﹐在前面所給的聯結中﹐已經說明過﹕

1) 沒有 WINS 的情形﹕
netbios_name_1 先會採用預設的 b-node 方式送出廣播﹐查詢netbios_name_2 所對應的 IP 位址(注意﹕不是 MAC 位址)﹐但如果物理連線不一樣的話﹐廣播則無法到達。假如得不到回應﹐轉而查詢 LMHOSTS﹐如果 LMHOSTS 也沒有﹐那就查詢失敗。
2) 有 WINS 的情形﹕
netbios_name_1 以 h-node 方式向 WINS 查詢 netbios_name_2 的 IP 位址﹔若失敗則改用 b-node 的廣播﹔若還是失敗﹐則查詢 LMHOSTS﹔若失敗就結束。

所以﹐如果都在同一個 subnet 之中﹐就算不採用 NetBEUI﹐也沒有 LMHOSTS 和 WINS 也能夠透過廣播來找到對方的 IP﹐然後用 NoT 和對方進行溝通。但如果在不同 subnet 中﹐就不能採用廣播了。這時候﹐就必須借助 LMHOSTS 或 WINS 服務。

採用 LMHOSTS 是最簡單的辦法﹐如果雙方都有 NetBIOS Name 與 IP 的對應在檔案中﹐您只要直接在檔案總管的網址上輸入對方的 IP ﹐然後前面加上兩條反斜線 ( \\ )﹐以區分
其後的分享名稱(用單斜線分隔)﹐就能瀏覽對方的資源了(當然﹐前提條件是底層的路由必須設定正確)。這過程無需借助 LMB 的幫忙﹐所以﹐對方不一定要出現在網芳上﹐尤其是任一方的 LMHOSTS 裡面沒有 LMB 對應的時候。但在 OS Level 平等的情況下﹐您很難確定誰是下一個 LMB 吧﹖再來﹐如果大家都是 DHCP 獲得 IP 的﹐也很難確定這些對應。無論如何﹐要手工的維護 LMHOSTS 比較是累人的﹐尤其在機器越來越多的時候。為解決這個問題﹐那就是 WINS 的切入時機了。

在網路中有 WINS 的時候﹐您必須手工的(或透過 DHCP 指定)為每一台機器設定 WINS 機器的所在 IP 位址。當機器進入網路的時候﹐必須向 WINS 進行註冊﹐除了是將 NetBIOS Name 和 IP 的對應註冊之外﹐還有一個很重要的功能是﹕ WINS 會告訴機器關於 LMB 的資訊﹐這樣您就獲得 BL 的資料﹐從而知道網路上有哪些機器存在。但這裡有一點必須要分清楚的是﹕WINS 未必就是 Master Browser (當然也可以是同一台)﹐不過 MB 必須要向 WINS完成註冊﹐這樣才能讓後來的機器順利找到 LMB。所以﹐要確保所有機器都註冊到同一台 WINS 上是非常重要的﹐要不然就要用 pull 或 push 技術讓所有的 WINS partner 同步 WINS 資料。

假如在一個 Domain 環境中﹐並且跨越不同的網路又會怎樣呢﹖

所有 LMB 除了負責收集本地的 BL 之外﹐還必須有一台且唯一的 Domain Master Browser (DMB) 負責收集所有 LMB 上面的資訊﹐並同步到所有的 LMB 上面﹐從而讓 LMB 有一個整體 domain 的資源列表(BL)。然後﹐當 client 從 LMB 上的 BL 上獲得其它 subnet 的機器註冊資訊後﹐會先從 WINS 那邊查詢對方的 IP ﹐然後轉為與對方機器之間的直接溝通模式﹕查詢有哪些資源分享﹑提出分享請求﹑對方進行驗證﹑通過後獲得分享﹑使用分享﹑結束分享... 等等。

假如沒有 WINS 呢﹖

就算您能夠用 LMHOSTS 來解決 host to host 的連線問題﹐但 subnet to subnet 之間的聯係就斷開了。我忘記了 NT 上面是否可以使用 remote anouncement 和 remote syncronisation 以進行 subent 之間的 BL 同步﹐但在 Linux 的 SAMBA 上是可以做到的。