TCP/IP 的迷思﹖


> "戒了愛爾蘭咖啡"  撰寫於郵件
> news:3iEEjY$Wzf@bbs.ncku.edu.tw...
> > 同一區網下如果要讓 兩個C class ip 的電腦 網芳互通!
> >
> >  是否一定要用 NetBEUI通訊協定呢?
> >
> >  windows 作業系統預設並不會安裝此協定!
> >
> >  每一台都設好麻煩! 好像也會影響頻寬???
> >
> >  是否有其它解決的方式呢?
> >


> "老盡少年心"  撰寫於郵件
> news:3iEJdk$Wbf@bbs.cis.nctu.edu.tw...
> > ==> 在 "網中人"  的文章中提到:
> > > 假如實體連線是不通的話﹐不用理會這篇回復﹕
> > > 同一 LAN 裡面﹐裝 NetBEUI 是最簡單的。如果您有一千零一個理由不裝這個協
> > > 定﹐那就架設 WINS server  吧﹐最好用 NT﹐如果不想花錢﹐Linux SAMBA 也可以。
> > > 如果連 WINS 也不想架﹐那就將所有機器的 IP 和 NetBIOS Name 的對應﹐寫在
> > > 每一台機器的 \windows\LMHOSTS 檔裡面吧。
> > > 不過﹐無論是 WINS 還是 LMHOSTS﹐都是 NetBIOS over TCP/IP 而已﹐反正都
> > >是 NetBIOS﹐不見得比 NetBIOS Extended User Interface (NetBEUI) 要好。鑒於您
> > > 所說的“同一個 LAN”(假設是實體網路是相通的)的前提之下﹐我有一千個理
> > > 由建議您裝 NetBEUI﹐不過﹐倒樂意聽聽您第一千零一個理由是什麼﹖
> >
> >   一千零一個理由，兩個class c的電腦...估個兩百台
> >   broadcast會很嚴重..
> >
>

"網中人"  撰寫於郵件 news:9n4gcg$fah$1@news.seed.net.tw...
>
> 這個理由不接受  :-)
>
> 就算用 NetBIOS over TCP/IP, 難道就沒有 Broadcast? 除非您是乾脆連網路芳鄰
> (netBIOS) 都不要了。
>
> 我已經提出了討論前提﹕“假如實體連線是不通的話﹐不用理會這篇回復。”
>
> 如果兩個 C class 彼此都分開物理連線﹐用 router 來連接的話﹐那單純裝NetBEUI
> 沒什麼意義﹐因為它不能路由。既然要路由﹐那 NetBIOS 封包必須 Encapsulated
> 在IP 封包進行路由。
>
> 但如果前提條件符合的話(同一物理連線)﹐拿掉 Router﹐拿掉 TCP/IP﹐用 NetBUIE
> 不就好了﹖(如果您說要上 Internet 那我沒話說。)
>
> 不論是 NetBUIE 或 NetBIOS over IP﹐netbios 本身需要的廣播﹐例如 master
> browser election､m/b discovery､netbios registration､m/b listing､ 這
>些﹐同樣都會發生。不見得在前提條件下(同一物理連線)﹐分開兩個兩個邏輯 Subnet 會
> 將 broadcast 降低。而相反﹐本來是單一的 broadcast﹐而現在卻變成了 subnet 1 ->
> router(同一物理連線也要) -> subnet 2 的雙重廣播﹐幸好現在都用 switch﹐如果
> 用400 台電腦都用 hub 的話﹐死得更難看...
>
> 所以﹐請舉其它理由...
>


網中人"  撰寫於郵件 news:9n5bul$a1m$1@news.seed.net.tw...
> "滿足現況"  撰寫於郵件
> news:3iFH5O$W9i@bbs.cis.nctu.edu.tw...
> >
> > 我是站在TCP/IP這邊的，因為一般來說TCP/IP是一定會裝的協定
> > 即然裝了TCP/IP，那其它的協定如果沒有必要，就不需要再安裝了
>
> 怎麼老是掉入 TCP/IP 的迷思中呢﹖
>
> 我們不妨先將討論環境設定下來好不好﹖
>
> 條件﹕
> 1) 在同一物理連線的 LAN 中﹔
> 2) 需要使用 TCP/IP 連接外部網路(或同一網路)﹔
> 3) 在 TCP/IP 上切分了兩個 subnet ﹐彼此分享著同一物理連線。
> 4) 節點之間使用 switch (可以接受我在這裡限定為 layer 2 吧﹖)
>
> 目標﹕
> 建立 windows 機器上的網路芳鄰連線。
>
> 方案﹕
> 1) 單純使用 TCP/IP 協定﹐然後以 NetBIOS over TCP/IP 運用 WINS 或 LMHOSTS
> 解決路由問題。
> 2) 加裝 NetBEUI 協定﹐略過 WINS 或 LMHOSTS 直接點對點的連線。
>
> 命題﹕
> 究竟採用方案 1 還是方案 2 更加有效﹖
>
> 如何﹖如果接受這些假設﹐再繼續討論﹐否則算了。
> (我只單純想討論技術﹐任何人身攻擊或族群對立﹐均不感興趣)
>
>
> > 1.WinNT以前只提供netbios，我想是因為要拿下Netware的市場
> >   況且當時的網路架構而言，若是要一般管理員在安裝時還要設
> >   定一堆數字，那市場一定吃不下來... 我想netbios為預設值
> >   應該是方便考量，而不是速度考量
>
> 當初 IBM 之所以要發展出 netbios (其後很快又發展出 NetBEUI﹐但大家還是習慣
> 稱為 netbios )﹐就是因為想要在小型的網路中開發簡單的通訊協定。技術而言﹐它
> 只是開發 18 個網路命令讓同一物理連線的機器進行連線的建立､維護､結束而已。
> 用過LAN Manager 或是 net command 的朋友都知道如何使用。
>
> 當初 NT v4 的推出﹐其主要目標還是 LAN 為主﹐所以 TCP/IP 被列為 optional。
> 並非是因為網路管理員不會設 IP/Subnet/Routing 這些東西(我個人覺得 IPX 比
> TCP/IP還難設﹐指修改設定檔啦 :)。如果網管不會這些﹐那就不叫網管;而讓這樣的
> 網管所主導的市場﹐也不會很大。我認為以 Microsoft 的眼光而言﹐不會因為這些
> 網管而取消TCP/IP。
>
>
> > 2.就安全性而言，多開Serice會造成電腦受到入侵的威脅越大，所
> >   在目前已有TCP/IP的協定前提下，當然建議是不要再安裝netbios
> >   或是netbuit
>
> 由於 netbios 是不能路由的協定﹐如果說構成安全問題﹐那多是內鬼﹔或是 TCP/IP
> 本身的連線遭到入侵﹐再從內部建立跳板。在一個信任的 LAN 環境中﹐netbios 不
> 是罪魁禍首﹐而是教育､修養､以及公司管理規程和企業文化。
>

補充﹕事實上﹐在 TCP/IP 上面開放 port 137,138,139 就是要讓 NetBIOS 能夠在
TCP/IP 上面跑。如果您的用 TCP/IP 連接外部網路﹐最好在防火牆上將這幾個 port
攔下來。您會發現﹐在開放的環境中﹐真正構成安全威脅的﹐正是 TCP/IP 而非
Netbios 。

>
> > 3.一台電腦上裝多個協定也會造成管理上的不便
>
> 這太武斷了。為什麼要用 protocol stack ﹖ 就是因應不同的環境和工作目的採用
> 相應有效的方案。我們從事資訊的﹐不是為了協定而工作﹐而是讓協定為工作服務。
> 若是將某一協定置於 stack 當中﹐其實正是管理的考量。
>
> 您要連上 Unix/Linux 或 Internet/Intranet﹐那就要用 TCP/IP﹔要連接
> netware﹐就用 IPX﹔要連接網路芳鄰(同一網段)﹐那就用 NetBEUI ...
>

補充﹕在某些 Gateway 架構下面﹐protocol 是可以分開的。例如在 netbios 網路上
面連接 SNA (IBM mainframe) 網路﹐您可以在每一台機器上面裝 xDLC 協定﹐直接連
接 SNA﹔也可以只在 SNA Gateway 上面裝 xDLC﹐這樣﹐client 和 gateway 之間保留
netbios 就可以了。

>
> > 4.在LAN中如果用switch hub，我想在邏輯上switch都會為兩種
> >   協定建立單獨的連線，但因協定本身處理的方式不同而在效能
> >   上會有影響
>
> 如果我們這裡談的 layer 2 switch 居然可以根據不同的協定建立單獨連線﹖我還是
> 頭一次聽到﹐抱歉﹐恕我孤陋寡聞﹐可以告訴到哪裡找這個論據嗎﹖如果是 layer 3
> 或以上的 switch﹐也願意聽閣下解釋一下 switch 如何以‘協定’為依據來建立邏
> 輯連線﹖我只單純的知道 layer 2 只以 MAC 位址為依據而已﹐而它採用的連線和檢
> 測也是datalink 這層所定義的﹐而非上層協定所定義的。
>
> 假如我們這裡使用 NetBEUI﹐那當 netbios_name_1 要送一個封包給
> netbios_name_2 的話(這裡﹐讓我們集中在 switch 上面好了)﹕
> 1) netbios_name_1 透過廣播查詢這個 netbios_name2 的 MAC﹔
> 2) netbios_name_2 回應這個 netbios 查詢﹔
> 3) netbios_name_1 就可以直接交由 switch 遞送了。
>
> 如果採用 NetBIOS over IP﹐那傳送過程將變為﹕
> 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﹔若失敗就結束。
>
> 我們不難發現﹐無論是 NetBEUI 或 NetBIOS over TCP/IP﹐都會產生廣播﹐但如果
> 用Wins 的話﹐則在一定程度上將廣播減少(這要視乎 TTL 和連線週期而定)﹐無論如
> 何﹐用 NetBIOS 協定就要面臨大量的廣播。
>
> 但在我們這樣環境中﹐如果有 WINS 的話﹐您會發現單一的傳送過程需要的步驟﹕
> 1) netbios_name_1 以 ARP 廣播查詢 WINS 的 MAC﹐這會讓 switch 對所有連接主
> 機送出封包﹔
> 2) WINS 回應 arp_reply 告知其 MAC 位址﹔
> 3) netbios_name_1 根據 MAC 將帶 netbios 註冊的 TCP/IP 封包送給 WINS﹐完成
> 註冊﹔
> 4) netbios_name_2 也必須重複上述 3 個步驟﹔
> 5) netbios_name_1 向 wins 查詢 netbios_name_2 的 TCP/IP 封包(如果 ARP
> cache 關於 WINS 的 MAC 記錄已經逾期﹐則重複 1 和 2 步驟)﹔
> 6) wins 回應這個查詢﹐送回 TCP/IP 封包﹔
> 7) netbios_name_1 根據回應結果進行路由判斷﹔發現在不同的 subnet 之內﹔ 將
> netbios 封包封裝進 TCP/IP 裡面﹐傳送給 router ﹔
> 8) router 檢查目的端 IP 位址﹐進行 ip forwarding 動作﹐將封包送給
> netbios_name_2;
> 9) netbios_name_2 對 TCP/IP 封包進行 decapsulate 動作﹔最後讀取到
> netbios_name_1 送來到 netbios 封包。

補充﹕如果 router 的 MAC 位址已經在 arp cache 中逾期﹐那也必須重複第 1 和第
2 步驟。

>
> 您覺得這樣的情況之下 NetBIOS over TCP/IP 會比單純的 NetBEUI 要更快﹖
>
> 我絕對不認同啦﹗
>
> 而且﹐稍有常識的 TCP/IP 網管﹐都會避免在同一個物理連線上切割不同的 subnet
> 或使用不同的子網聚集。因為如果在同一個 subnet 內﹐host_1 到 host_2 的封包
> 送一次就好了﹐如果切在不同的 subnet 內﹐封包最少要變雙倍﹕host_1 -->
> router -->host_2 ﹐越繁忙的網路越慘﹗
>
>
> > 5.NetBios與NetBuit都是採用Datagram的傳輸方式，相較
> >   於TCP/IP是建立Trust Connection而言，不論是傳輸的
> >   品質或速度上，當然是TCP/IP好。根據實際測試結果
> >   TCP/IP比DataGram好太多了，所以可能和另一位的說法不合
> >   主要還是在傳輸有問題時兩者協定的做法上有很大的不同吧.
>
> 什麼 datagram 或 stream 傳送啊﹖都是 TCP 裡面定義的﹐NetBIOS 是使用
> message block 進行傳送的好不好﹖您真的在同一 LAN 中測試過 NetBEUI 和
> TCP/IP 實際傳送的數據(程式用資料)的比較嗎(記得將 NetBEUI 設定為‘預設協
> 定’哦)﹖光是TCP/IP那一大串 header､不固定的封包長度､還有那極度不信任感
> 驅使的 error checking(不要忘記 TCP/IP 的研發是冷戰的產物哦)﹐在穩定高效
> 的 LAN 中跑這樣的笨重協定實在不是明智之舉。(聲明在先﹕我指在 LAN 中而已﹐
> 如果您工作使用的程式﹐如Email 系統﹐一定要用 TCP/IP﹐那是沒辦法。或許﹐
> 您沒見過許多倉庫或碼頭的鐵皮屋裡面還在跑 LAN Manager 吧﹖)
>
> 您不妨比較一下 NetBEUI 和 TCP/IP 的封包格式﹐以及它們的傳送確認再回來說
> “TCP/IP 比 DataGram 好多”的話吧(笑話啦﹕TCP 家族的 UDP 就是 datagram 格
> 式)。如果 TCP/IP 夠好﹐幹嘛還用 UDP﹖幹嘛還開發 Muticasting? 連 NFS 這個悠
> 久的 UNIX 網路檔案系統﹐到了 version 3 才提供 TCP 支援。
>
> >
> > 目前只想到4點，所以...我的結論是..
> > 1.如果您是自己的lan，不論您要用啥都可以，就安全考量而言，只要裝
> >   一種就好了...不過，回過頭來說，一家公司也會有自己的網站或FTP
> >   Directory Service等，都要用TCP/IP協定..呵呵...
>
> 安全考慮不是不對﹐但要對症下藥。我認為﹐對安全性損害最大的是‘人為’因素﹐
> 而非您用什麼協定﹐也不是您用什麼系統。
>
> > 2.如果您已有TCP/IP，那其它的就不要裝了...
>
> 採用不同的協定﹐是因應不同的環境﹐而不是改變環境遷就單一的協定。將公司的營
> 運和利益放在第一位置來設計就沒錯了。
>
> ---- p.s. ---
>
> 另外﹐想了想前面 Allen 所說的﹐反而有點道理﹕如果數目超過 400 台電腦﹐恐怕
> 也難以將所有主機建構於同一物理連線上吧﹖今天的單一 switch 有多少個 port (
> 包括stack﹐先不管 tucking 和 vlan)? 儘管 netbios 沒有單一 c class subnet
> 的254台電腦的限制﹐但物理的連線上恐怕也是一個難題﹐而且沒有 WINS 的參與﹐
> 的確會造成極大的廣播數量。不過﹐既然超出了我所設定的前提框架﹐所以﹐抱歉﹐
> 還是不接受這個一千零一的理由 :-)
>
> --
>
> ======= http://www.study-area.org =======
> 飛雪迎春到﹐風雨送春歸
> 已是寒崖百丈冰﹐尤有花枝俏
> 俏也不爭春﹐只把春來報
> 待得山花爛漫時﹐他在叢中笑﹗