顯示具有 基礎概念 標籤的文章。 顯示所有文章
顯示具有 基礎概念 標籤的文章。 顯示所有文章

2010年1月4日 星期一

FTP 主動 & 被動

在網路上看到一篇寫得很好的文章

借轉~~來源處於此:http://matisse.wordpress.com/


FTP 是所有通訊協定裡最特殊的,其他的通訊協定例如 HTTP、SMTP、POP3…都只需要一條連線、一個通訊埠,然而 FTP 卻需要兩條連線、兩個通訊埠。FTP的連線包括兩種不同用途,一個是傳遞客戶端與伺服器之間的Command的,也就是一般我們在設定的FTP通訊埠(預設21)。另一個是資料傳送的連線,FTP資料傳送的模式又分二種:PORT、PASV。兩者主要分別在於它們會向FTP伺服器發出不同的FTP Command。

為了釐清者兩者的差別,以及其工作原理,特別撰寫這篇文章加以說明。
以下的文章,將由 FTP 的工作原理開始介紹,希望能清楚的描述兩者的差別以及正確的設定方式。文章中,我們也將透過實際連線,了解不同模式所傳遞的訊息,這將有助於您未來的故障排除能力。

基本原理
FTP 是屬於 TCP 服務的一種, FTP 是所有通訊協定裡最特殊的,其他的通訊協定例如 HTTP、SMTP、POP3…都只需要一個通訊埠,然而 FTP 卻需要兩個通訊埠,一個用來傳遞客戶端與伺服器之間的命令,一般設在 port 21,稱之為命令通訊埠(Command Port);另一個是真正用來傳遞資料的,一般都設在 port 20,稱之為資料通訊埠(Data Port)。

而問題就出在 Data Port !

因為初期定義 FTP 通訊定的時候,並沒有考慮到後來防火牆的發展,使得傳統的 FTP 的工作原理無法完全適用在網際網路環境,因此就發展出了另外一種替代模式的 FTP 連線方式,在這種模式底下,Data Port 不再只是 20,也因此造成很多讀到舊資料的人,認為只要將 20, 21 兩個通訊不打開,FTP Server 就能正常運作這樣的錯誤觀念。以下就由傳統模式開始介紹。

主動模式
傳統式 FTP 連線方式是採用主動模式,由用戶端隨機使用一個大於 1023 (也就是1024以上)的通訊埠(為了方便說明我們以 port N 來代表),與 FTP 伺服器的命令通訊埠(port 21) 建立連線,同時用戶端自己開啟一個 N+1 的通訊埠等待伺服器連線。伺服器接到用戶端的命令之後,便使用資料通訊埠(port 20)主動與用戶端的 port N+1 建立資料連線。
這樣的模式有點像我們開車去加油的溝通方式,駕駛打開窗戶(port N)對著服務人員(port 21)要求加油命令,同時打開油箱蓋、露出加油孔(port N+1),服務人員及拿著油槍(port 20)對著加油孔(port N+1)加油。
所謂的主動式,是以伺服器的觀點來看。要完成一個主動式連線,伺服器必須提供以下幾個溝通管道:

FTP 伺服器開啟 port 21 接受來自外部任意通訊埠的連線(由用戶端要求建立連線)
FTP 伺服器使用 port 21 連線到外部任一大於 1023 的通訊埠(回應用戶端的命令埠)
FTP 伺服器使用 port 20 連線到外部任一大於 1023 的通訊埠(伺服器主動建立資料連線)
FTP 伺服器開啟 port 20 接受來自外部任一大於 1023 的通訊埠連線 (用戶端回覆伺服器資料連線)

以下我們利用一張圖來做說明:


步驟一、用戶端使用 port 1024 與伺服器建立連線,並提供 port 1025 的資訊給伺服器。
步驟二、伺服器回應用戶端的連線。
步驟三、伺服器主動與用戶端的 port 1025 建立連線。
步驟四、用戶端回覆伺服器。

由以上的說明可以理解,主動式連線的真正問題不在於伺服器,而是在於用戶端的防火牆。由於用戶端程式並不是自行建立資料連線,而是自己開啟一個通訊埠,要求伺服器連線進來,這對用戶端的防火牆來說是一個危險的安全警訊,大部分的網路環境,都不允許防火牆外部的系統連線到內部的用戶端電腦。
以下為實際的主動式 FTP 連線範例,我們以Rainbow FTP Server 與 ezFTP 用戶端程式為例,觀察其連線的訊息。

圖中出現的 PORT 192,168,1,100,6,160 代表用戶端 IP 192.168.1.100, 通訊埠 256*6 + 160,也就是有用戶端只定通訊埠。這和後面要介紹的被動模式完全不同。
被動模式

為了解決由伺服器連線到用戶端所產生的安全疑慮,因此發展出了另一種不同的連線模式,稱之為被動模式(Passive Mode, PASV)。讓用戶端程式可以在連線的時候,通知伺服器使用動模式連線。

使用被動模式 FTP ,不論命令連線或是資料連線都是由用戶端建立,以解決防火牆以及相關資安問題。當用戶端開啟 FTP 連線時,用戶端程式先在本機開兩個大於1023的通訊埠(N, N+1),利用 port N 與伺服器的 port 21 建立連線。不同於主動模式的連線方式,用戶端這次不再提供 N+1 port 與 IP 位址給伺服器,而是送出 PASV 的命令。伺服器收到 PASV 的命令之後,即開啟一個大於 1023 的通訊埠(P),並將這個通訊埠連同伺服器 IP 回覆給用戶端,被動等待用戶端連線,用戶端即利用 port N+1與伺服器所提供的 port P 建立資料連線。

以伺服器的觀點來看,要完成一個被動式連線,伺服器必須提供以下幾個溝通管道:
FTP 伺服器開啟 port 21 接受來自外部任意通訊埠的連線(由用戶端要求建立連線)
FTP 伺服器使用 port 21 連線到外部任一大於 1023 的通訊埠(回應用戶端的命令埠)
FTP 伺服器開啟一個大於 1023 的通訊埠,接受來自外部任一大於 1023 的通訊埠連線 (用戶端與伺服器建立資料連線)
FTP 伺服器使用一個大於 1023 的通訊埠,連線到外部任一大於 1023 的通訊埠(伺服器回復資料給用戶端)
以下我們利用一張圖來做說明:

步驟一、用戶端使用 port 1024 與伺服器建立連線,並發出 PASV 的要求。
步驟二、伺服器回應用戶端的連線,並通知用戶端,伺服器已開啟 port 1120 等待資料連線。
步驟三、用戶端使用 port 1025 與伺服器的 port 1120 建立資料連線。
步驟四、伺服器回覆用戶端。

使用被動模式雖然解決了用戶端的問題,卻也為伺服器帶來了一些問題,最大的問題在於伺服器必須開啟一定範圍的通訊埠供用戶端連線,好在目前絕大部分的 FTP 伺服器軟體,皆可以由管理者決定開啟哪些範圍的通訊埠。
另一個問題則是部分作業系統提供的的FTP命令列,不支援被動模式,因此必須使用其他的用戶端程式。
以下為實際的被動式 FTP 連線範例,我們以Rainbow FTP Server 與 ezFTP 用戶端程式為例,觀察其連線的訊息。

請注意紅色箭頭標式的部份,前一行用戶端程式發出 PASV 的命令,伺服器則回應 210,202,94,228,8,0,也就是由伺服器開啟 256*8 +0 這個通訊埠,等待用戶端連線。
以下做個簡單的總結:

【主動模式】
命令連線: 用戶端 port N –> 伺服器 port 21
資料連線: 伺服器 port 20 –> 用戶端 N+1

【被動模式】
命令連線: 用戶端 port N –> 伺服器 port 21
資料連線: 用戶端 port N+1 –> 伺服器 port P
其中 N、P 都必須大於 1023

兩種模式各有優缺點,主動模式對伺服器來說比較安全,但對用戶端來說卻是可能帶來危險,因此很可能被用戶端的防火牆所阻擋了。使用被動模式雖然解決了用戶端的問題,但相對的伺服器必須開啟一定範圍的通訊埠供用戶端連線,好在目前絕大部分的 FTP 伺服器軟體,皆可以由管理者決定開啟哪些範圍的通訊埠。
特別注意的是,要使用那種模式連線是由用戶端決定(發出 PORT 或是 PASV 命令),但是伺服器卻可決定要不要支援這種模式的連線。

2009年3月22日 星期日

WINS 登錄名稱

WINS 登錄名稱

Registering names

名稱登錄是一個在網路上要求使用 NetBIOS 名稱的 WINS 用戶端。要求可能是唯一的 (獨占的) 或群組 (共用的) 名稱。NetBIOS 應用程式也可以登錄一個或多個名稱。

照下列圖形所示,WINS 用戶端 (HOST-C) 直接將「名稱登錄要求」傳送到它所設定的 WINS 伺服器 (WINS-A)。

用戶端在 WINS 中的登錄方式

WINS-A 可以藉由發行 HOST-C 正或負名稱登錄回應來接受或拒絕名稱登錄要求。WINS-A 所發生的動作依照幾個因素:

  • 不論名稱是否已經在 WINS-A 上的伺服器資料庫中存在了。
  • 如果名稱記錄存在,WINS-A 上的記錄所在的伺服器資料庫中的狀態可能有所不同。還有,如果記錄的 IP 位址名稱,與要求用戶端 (HOST-C) 的 IP 位址名稱相同或不同時。
  • 不論要求是否是唯一的或是群組名稱項目。

如果名稱不存在於資料庫中,就當作新增登錄來處理,並會發生下列步驟:

  1. 輸入 HOST-C 的名稱,同時輸入新的版本識別碼、指定時間郵戳,以及標上 WINS 伺服器的擁有者識別碼的標記。 
    時間戳記的計算,是根據 WINS 伺服器上對目前伺服器日期及時間所設定之 [更新間隔] (預設值為 6 天) 而新增的值。
  2. 將正登錄回應送回到 HOST-C,「存活時間 (TTL)」值等於 WINS-A 上名稱記錄的時間郵戳。

Name registered for same IP address

如果已經在資料庫中輸入與要求的 IP 位址相同的 HOST-C 名稱,就會依據現存名稱的狀態及擁有權來採取動作。

  1. 如果將項目標記為使用中,而且伺服器 (WINS-A) 擁有此項目時,則伺服器會更新記錄的時間郵戳,並且將正面「回應」送回到用戶端。
  2. 如果將項目標記為釋放刪除標記,或如果其他 WINS 伺服器擁有該項目,則會將此登錄視為新的登錄。更新所有時間郵戳、版本識別碼,及擁有權以及送回正回應。

Name registered for different IP address

當存在於 WINS 資料庫中的名稱與要求的 IP 位址不同的狀況下,需要 WINS 伺服器以避免名稱重覆。如果資料庫項目是釋放或刪除標記狀態,將 WINS 伺服器釋放出來以指派該名稱。

如果項目是使用中狀態,則保留名稱的節點被質疑以判定它是否仍然存在於網路上。在此狀況下,WINS 伺服器 (WINS-A) 可以執行名稱的更正以及下列動作:

  1. WINS-A 將「等候認可 (WACK)」回應傳送到要求的用戶端 (HOST-C),在用戶端應該在準備等候回應的 TTL 欄位中指定時間。
  2. WINS-A 將給伺服器資料庫中為此名稱登錄的當前節點提出名稱查詢要求。
  3. 如果節點仍存在,它會將正回應傳回 WINS-A。
  4. 依次,WINS-A 傳送名稱登錄的負回應到要求回應的用戶端 (HOST-C),拒絕名稱登錄。
  5. 從 WINS-A 進行的第一個回合的查詢中,如果沒有收到正回應,則產生二個後續名稱查詢要求。如果 3 次嘗試都沒有回應,更正程序已完成且正登錄回應返回到要求用戶端 (HOST-C),而為新用戶端登錄的名稱已在伺服器資料庫中更新。

附註

  • 不像啟用 WINS 的用戶端可以直接聯絡 WINS 伺服器,非 WINS 用戶端 (如 NetBT B-Node 用戶端) 必須登錄,然後在區域網路中藉由傳送及回覆廣播名稱查詢,持續維護他們的名稱。
  • NetBIOS 名稱已在 Windows Internet Name Service (WINS) 上登錄,且在電腦正確關機時正常釋放。如果電腦不是正確關機,或在關機期間電腦不能與 WINS 伺服器聯絡,nbtstat 命令可以在 WINS 中更新此電腦的本機名稱。對可在網路上不同位置間移動的可動或筆記型電腦是有用的。 
    如需相關資訊,請參閱 驗證用戶端 NetBIOS 名稱的 WINS 登錄

2009年3月21日 星期六

WINS 解析概觀

WINS 解析概觀

Resolution overview

雖然 WINS 的作用是解析 NetBIOS 名稱,但為了有效地解析名稱,用戶端需能夠動態地新增、移除或更新它們在 WINS 中的名稱。以下提供了這些處理功能上的描述,特別是 WINS 網路上的用戶端名稱要如何登錄、更新、釋放及解析。

此 WINS 用戶端/伺服器通訊的處理概述於下圖:

WINS 解析概觀

在 WINS 系統中,所有名稱都登錄在 WINS 伺服器上。這些名稱均存放在 WINS 伺服器的資料庫中,此資料庫就會依據其中的項目來回應名稱對 IP 位址的對應解析要求。

數台網路 WINS 伺服器會負責檢查這些項目是否多餘,以及負載平衡的狀況。每隔一段時間,這些伺服器就會相互地將本身的資料庫項目複寫到其他伺服器上,以維護 NetBIOS 名稱區的一致性。

每個名稱在資料庫中都有一個項目。各項目是由其所登錄的 WINS 伺服器來管理,且是所有其他 WINS 伺服器的複本。每個項目均有相關聯的狀態--如使用中、釋放或廢止 (也稱為刪除標記) 等狀態。各項目也會有版本識別碼。此數字是用於在複寫處理中,在「WINS 複寫」中會有更詳細的討論。如需相關資訊,請參閱 推入協力電腦

WINS 也允許靜態名稱登錄。如果伺服器上的作業系統無法處理動態名稱登錄,則此項功能便可讓這些伺服器的管理員進行名稱登錄。WINS 可以分辨動態及靜態的資料項目。在有些方面,靜態名稱與動態名稱的處理方式並不相同。如需相關資訊,請參閱 使用靜態對應

2009年3月17日 星期二

WINS 複寫概觀

WINS 複寫概觀

Replication overview

如果在您網路上使用了多重 WINS 伺服器,可以設定將記錄從它們的資料庫複寫到其他伺服器。處理程序如下圖顯示。WINS-A 及 WINS-B 二台 WINS 伺服器,可以設定為相互完全複寫對方的記錄。

WINS 複寫概觀

藉由在這些 WINS 伺服器之間使用複寫,可以維護並由網路發佈一致的 WINS 資訊設定。例如在上圖中,子網路 1 的 WINS 用戶端 (HOST-1) 使用它的主要 WINS 伺服器 (WINS-A) 登錄它的名稱。子網路 3 的其他 WINS 用戶端 (HOST-2) 使用它的主要 WINS 伺服器 (WINS-B) 登錄它的名稱。如果這些主機的其中一個稍後嘗試尋找其他主機,如範例 WINS,HOST-1 為介於 WINS 伺服器 (WINS-A 及 WINS-B) 之間的 HOST-2--replication 查詢尋找一個 IP 位址,該設定提供了解析此查詢的可能性。

為了執行複寫,每台 WINS 伺服器,至少必須與一台其他的 WINS 伺服器設定在一起,作為其複寫協力電腦。這可確保使用一台 WINS 伺服器登錄的名稱,最後會複寫到網路上所有其他的 WINS 伺服器中。可以新增及設定複寫協力電腦為提取協力電腦、推入協力電腦二者之一,或使用二種類型的複寫作為提取/推入協力電腦。提取/推入協力電腦類型是預先設定的,且是在大多數情況下建議使用的類型。

當 WINS 伺服器複寫時,在任何指定伺服器對應的用戶端名稱位址傳播到網路上的其他所有 WINS 伺服器之前,會有一段潛伏期。此潛伏期又稱為整個 WINS 系統的交集時間。例如,用戶端要求名稱釋放的傳送速度就慢於名稱登錄要求。這是因為用戶端名稱會先釋出,然後在電腦重新啟動或每隔一段時間關機時,又使用相同的對應重新使用。複寫每一個釋出的名稱將增加無謂的網路複寫負擔。

而且,當 WINS 用戶端電腦不正常關機時 (如意外停電),電腦的登錄名稱就無法像在正常情況下,藉由將釋放名稱要求傳送到 WINS 伺服器以釋放名稱。因此,雖然 WINS 資料庫中有名稱與位址對應的記錄,卻不表示用戶端電腦仍在使用登錄名稱或它相關的 IP 位址。它僅表示最近的某段時間內,已有登錄的名稱電腦曾要求使用對應的 IP 位址。

附註

  • 任何用戶端的主要及次要 WINS 伺服器,基本上應有相互的推入及提取關係。不過,您倒可不必設定直接的推入/提取,只要在正常的複寫週期中,系統能間接地獲得相同結果即可。
  • WINS 的複寫功能是遞增性的,這表示每次複寫時僅複寫資料庫中變更的部分,而不是整個資料庫。

2009年3月12日 星期四

WINS 資料庫

WINS 資料庫

The WINS database

WINS 資料庫存放及複寫網路上 NetBIOS 名稱對應到 IP 位址對應資訊。在 Windows Server 2003 系列中,WINS 資料庫會使用 Extensible Storage Engine (ESE)。

Compacting the database

沒有內建限制 WINS 伺服器複寫或存放的記錄數。資料庫的大小視網路上的 WINS 用戶端數目而定。WINS 資料庫變更超時用作用戶端登入及登出網路。

不過,WINS 資料庫的大小不是與使用中用戶端資料項目的數目直接成比例的。隨著時間推移,有些 WINS 用戶端資料項目變成老舊及已刪除時,不斷增大的 WINS 資料庫會超過目前使用中的實際空間。這是因為一旦存放老舊記錄的磁碟空間已不再存有資料時,伺服器不會自動收回空間。

壓縮 WINS 資料庫來收回未使用空間。在資料庫更新之後的閒置時間,WINS 伺服器會自動背景處理動態資料庫壓縮。壓縮也可以手動離線完成。WWindows NT Server 4.0、Windows 2000 及 Windows Server 2003 系列支援動態及手動壓縮。Windows NT Server 3.51 (或更早版本) 只支援 WINS 伺服器資料庫的手動壓縮。

儘管動態壓縮大幅降低了離線壓縮的需要,因離線壓縮能夠較完整地收回空間所以應該每隔一段時間做一次。應該多久做手動壓縮 WINS 資料庫一次視您的網路而定。對於大型的,有 1,000 個或以上的 WINS 用戶端的網路而言,您每月都應該做離線壓縮。較小的網路通常不需要經常手動壓縮。

因為動態資料庫壓縮都是進行於資料庫使用時,所以在處理期間不需要停止 WINS 伺服器。不過,對於手動壓縮,您必須停止 WINS 伺服器及離線。

Backing up the WINS database

WINS 主控台提供維護、檢視、備份及還原 WINS 伺服器資料庫時所需要的工具。當您在 WINS 伺服器上備份其他檔案時,應該備份此資料庫。

WINS database files

WINS 使用 Jet 資料庫格式存放其資料。Jet 會產生 J<n>.log 以及其他在 systemroot\System32\Wins 資料夾的檔案,來增加資料存放的速度及效率。

下列表格討論每台 WINS 伺服器中,由 Jet 資料庫建立及使用的檔案。

 

檔案描述

J50.log 與 J50#####.log

運用 WINS 資料庫的所有異動記錄檔。必要時,WINS 會使用此檔案以回復資料。

為了增加資料存放的速度及效率,Jet 資料庫將目前的異動寫入記錄檔,而不是直接寫入資料庫。因此,最新的資料檢視既包含資料庫又包含記錄檔的任何異動。如果 WINS 服務突然或意外地停止,這二個檔案都會用來修復它。如果服務以意外的方式停止,會自動使用記錄檔來重新建立 WINS 資料庫的正確狀態。

記錄檔維持指定的大小;不過,在 WINS 伺服器忙線時它們的大小可能會快速增長。WINS 無法避免將過多的異動寫入記錄檔可容納的數量。填入記錄檔時,系統重新命名此記錄檔,指出它是未使用中的較舊的記錄檔。建立以 J<n>.log 為檔名的新增異動記錄,其中 <n> 是十進位數字,如 J50.log。前述記錄檔的命名格式是 JetXXXXX.log,其中每個 X 表示從 0 到 F 的十六進位數字。前述記錄檔與目前記錄檔維護在同一資料夾中。

這些記錄檔會每 3 小時進行處理 (所有項目會寫入到資料庫) 及刪除。在成功的 WINS 資料庫備份或是當 WINS 伺服器適當地關機時,也會執行處理及刪除。如果累積許多 J<n>.log 檔案,則您應該排定經常性備份以維護這些記錄。

處理資料項目後,您可以手動刪除記錄檔;不過,如果需要修復,這會妨礙資料庫成功的修復。因為此重要理由,不要手動從系統刪除或移除記錄檔,除非已執行備份。

J50.chk

檢查點檔案指出上次成功地將資訊從異動記錄寫入資料庫的位置。在資料修復情況中,檢查點檔案指出修復或重播資料應該從何處開始。此檢查點檔案在每次將資料寫入資料庫檔案 (Wins.mdb) 時都會更新。

Wins.mdb

WINS 伺服器資料庫檔案包含二個表格:從 IP 位址到「擁有者」識別碼對應表格及從名稱到 IP 位址對應表格。

Winstmp.mdb

在 WINS 伺服器的服務中留下的暫存檔。此檔案在索引維護操作時作為交換檔案及可以在系統不正常結束後還留在systemroot\System32\Wins 目錄中。

Res#.log

這些是保留的記錄檔,它在伺服器用完磁碟空間時的緊急狀況下起作用。如果伺服器嘗試建立其他異動記錄檔,但是磁碟空間不足時,則伺服器會將任何正在處理的異動清除到這些保留記錄檔中。服務關閉及將事件記錄到 [事件檢視器]。

重要事項

  • 不應該移除或變更 J50.log、J50#####.log、Wins.mdb、Winstmp.mdb 及 Res#.log 記錄檔。

2009年3月10日 星期二

DNS 與 WINS 的整合

DNS 與 WINS 的整合

DNS的Clinet向DNS查詢時,DNS找不到相關的資料就去問WINS,讓Client端以為DNS知道該名稱的位址。

另外有可能遇到Client的電腦不會去DNS註冊資料,則有兩種情況需要做整合:

  1. 舊版Windows(95、98)是不會跑去DNS登記的,不也不能支援DNS的動態更新
  2. Stand Alone的電腦無法向DNS註冊,原因是DNS可能有設定安全性驗證,只能接受加入網域的電腦

因此WINS需要幫忙回答這些Client端的電腦所在的位址。

2009年3月6日 星期五

WINS 的運作方式

WINS 的運作方式

當執行 Microsoft 作業系統的電腦已設定 WINS 伺服器位址(手動或透過 DHCP)來進行其名稱解析時,則預設會使用互動式節點 (h-node) 作為 NetBIOS 名稱登錄的節點類型,除非已設定另一種 NetBIOS 節點類型。若是 NetBIOS 名稱查詢及解析,它也會使用 h-node 操作,但會稍有不同。

若是 NetBIOS 名稱解析,WINS 用戶端通常會執行下列一般操作步驟來解析名稱:

  1. 用戶端會檢查受查詢的名稱是否是它所擁有的本機 NetBIOS 電腦名稱,若查詢遠端名稱的在本機 NetBIOS名稱快取。遠端用戶端的任何已解析的名稱都放置在此快取中,並在其中保留 10 分鐘。
  2. 用戶端將 NetBIOS 查詢轉寄到其已設定的主要 WINS 伺服器中。如果主要 WINS 伺服器--無法使用或是沒有名稱的資料項目--而無法回答此查:詢,用戶端就會依照所列出及設定的順序嘗試連絡其他已設定的 WINS 伺服器。
  3. 用戶端將 NetBIOS 查詢廣播到本機子網路中。
  4. 如果設定使用 Lmhost 檔案,用戶端就會檢查該 Lmhost 檔案以對應此查詢。
  5. 用戶端會嘗試到本機的 Hosts 檔案尋找
  6. 接著到DNS的Cache中的查詢
  7. 最後在到 DNS 伺服器

附註:如果欲解析的電腦名稱字元數超過15個字元,或是電腦名稱之中有句點存在,則會自動改用DNS主機名稱解析方法。步驟2和3動作決定,使用何種(Node Type)。

2009年3月5日 星期四

使用 WINS 的好處

使用 WINS 的好處

為管理 TCP/IP 型網路,WINS 提供了下列好處:

  1. 支援電腦名稱登錄及解析的動態名稱至IP位址的資料庫,進而有效降低NETBIOS的廣播風暴。
  2. 名稱及IP位址的資料集中管理減輕對管理 Lmhost 檔案的需求。
  3. 藉由許可用戶端查詢 WINS 伺服器以直接尋找遠端系統,可以降低子網路上的 NetBIOS 造成的廣播流量。
  4. 支援網路上早期的 Microsoft Windows 及 NetBIOS 用戶端,即使到今天,只要網路上還有舊版本的 Windows 或使用 NetBIOS 的應用程式在,WINS 就有存在的必要允許此類型用戶端在每個子網路上,不需本機網域控制站的存在即可瀏覽遠端 Windows 網域的清單。
  5. 當執行 WINS 對應整合 時,可藉由啟用 DNS 用戶端尋找 NetBIOS 資源,以支援 DNS 用戶端

2009年3月4日 星期三

WINS 與DNS的差異

WINS 與DNS的差異

Wins的作用跟DNS的作用有相似的地方,都在做名稱解析,但也有不同之處我將它整理成下的列表中:

Feature \ ServiceWINSDNS
使用的網路協定NETBEUI、TCP/IPTCP/IP
常見的網路環境較常適用於LAN較常跨WAN
解析名稱類型解NetBIOS名稱(網芳名稱轉換IP)解 FQDN名稱(網域名稱轉換IP)
Windows系統路徑指定方式UNC路徑 \\Server1FQDN路徑Server1.domain.com
與同類型伺服之間的關係無階層式階層式導向
Client端 關機前動作將名稱Release釋放出不會Release
  • 事實上Windows NT系統上既有的WINS就是設計用來支援DHCP的運作的,且已成為Microsoft 企業網路整體架構中的一個重要的部份。WINS的作用與DNS類似,都是用來提供多種管理名稱的系統服務,例如:將名稱轉換成IP位址,但是WINS只負責管理NetBIOS所使用的命名空間,而此命名空間與一般DNS所管理的階層式領域名稱並不相同。
  • 此外WINS還能夠與DHCP配合在一起使用,也就是說我們可以先用DHCP指定系統所需要的IP位址,然後再自動地在WINS伺服中註冊一個機動的NetBIOS名稱。由於WINS的架構並非階層式的,因此若某一個NetBIOS名稱未在WINS伺服中註冊,則我們就可以將之視為在網路上根本不存在。由此可知:在所有採用NetBIOS over TCP的網路上WINS可以算是一項必備的工具

2009年3月3日 星期二

WINS 伺服器

WINS 伺服器

WINS servers

WINS 包含兩個主要元件:WINS 伺服器及 WINS 用戶端

WINS 伺服器負責處理 WINS 用戶端所發出的名稱登錄要求、登錄它們的名稱及 IP 位址、回應用戶端提交的 NetBIOS 名稱查詢,然後傳回列在伺服器資料庫中該查詢名稱的 IP 位址 (如果存在)。

並且,如下圖所示,WINS 伺服器可以將它們資料庫 (包含 NetBIOS 電腦與 IP 位址的名稱對應) 的內容複寫到其他 WINS 伺服器。啟用 WINS 的用戶端電腦 (如在「子網路 1」或「子網路 2」上的工作站電腦) 在網路上啟動時,它會提交登錄要求,將它的電腦名稱及 IP 位址直接傳送到它的主要設定 WINS 伺服器 (WINS-A)。因為 WINS-A 是登錄這些用戶端的伺服器,所以又稱為 WINS 用戶端記錄的擁有者

WINS 伺服器

在此範例中,伺服器 WINS-A 有本機用戶端 (WINS-A 所在的「子網路 2」上的用戶端) 及遠端用戶端 (透過路由器,而位於「子網路 1」上的用戶端)。另一 WINS 伺服器 (WINS-B) 位於「子網路 3」上,且僅擁有從此子網路登錄的本地用戶端對應。WINS-A 及 WINS-B 稍後可以完成它們資料庫的複寫,以使所有在三個子網路上的用戶端記錄,可以出現於二台伺服器的 WINS 資料庫中。如需相關資訊,請參閱 WINS 複寫

Primary/Secondary WINS servers

用戶端以下列兩種方法的其中一個,使用 WINS 伺服器:當成主要或次要 WINS 伺服器。

主要及次要 WINS 伺服器的不同,絕對不是視伺服器而定 (在 WINS 中,其所有功能上的用途是相同的)。這兩者的差異是在用戶端,因為在具有多個 WINS 伺服器時,用戶端會分辨 WINS 伺服器清單中的伺服器,並加以排序。

在大多數情況下,用戶端會聯絡主要 WINS 伺服器,然後執行 NetBIOS 名稱服務的功能 (名稱登錄、名稱更新、名稱釋放、名稱查詢及名稱解析)。只有在主要 WINS 伺服器發生下列任何情形時,才會使用次要 WINS 伺服器:

  1. 在要求服務時,無法在網路上使用;或
  2. 無法解析用戶端的名稱 (在進行名稱查詢時)。

當主要 WINS 伺服器失敗時,用戶端就會像次要 WINS 伺服器要求執行相同的服務功能。如果用戶端上有兩台以上的 WINS 伺服器,則用戶端就會嘗試清單中其他的 WINS 伺服器,直到試完所有的 WINS 為止,或其中一台次要 WINS 伺服器處理成功且回應要求。在用戶端使用了次要 WINS 伺服器之後,就會每隔一段時間嘗試切換到它的主要 WINS 伺服器,以執行以後的服務要求。

若是最新的 WINS 用戶端 (Windows XP 及 Windows 2000),則可以設定多達 12 台次要 WINS 伺服器 (可透過 TCP/IP 內容手動地設定,或利用 DHCP 伺服器提供使用 DHCP 選項類型 44,以動態方式來進行設定)。如果您的環境中有許多行動式用戶端,而且經常用到 NetBIOS 資源及服務,此項功能便可帶給您相當多的助益。由於在這類環境中,WINS 資料庫可能因為交集問題,而無法在整個 WINS 伺服器網路內達成一致,所以這項功能可幫助用戶端得以查詢兩台以上的 WINS 伺服器。

不過,若沒有必要,請避免過度使用此選項,因為在列出額外 WINS 伺服器以新增容錯時,會減損所能得到的實際好處。此項功能的好處必須根據事實來衡量;這個事實是指,對清單上所列的每台額外 WINS 伺服器而言,要在 WINS 中完整地處理一項查詢需花費更長的處理時間才能完成。例如,如果在失敗之前,WINS 用戶端嘗試三台或更多的 WINS 伺服器,則此用戶端會延遲處理名稱查詢一段時間後,才嘗試其他解決方法,如搜尋本機主機檔案,或查詢 DNS 伺服器。