大概三四年前，在系站上轉錄這篇文章
（還不就為了吵架 \囧/）；前幾天又在 ptt 上頭看到類似的問題，所以挖出來重貼。今天胡亂翻到分散式系統課本的 network 章節，就想說那也順便把這篇給 web 化吧。
念 網路的東西很麻煩，因為東西很多很雜又很亂，當年看到 P 結尾的名詞就頭大，不是說用 TCP/IP 嗎？那為甚麼還有啥 ARP、ICMP、SMTP、SNMP、HTTP，萬一碰個 router 或是高階 switch，又是一堆 xxP....... [暈]，這些還不夠，還會扯到一堆 802.x 的東西...... [倒地]。單靠自己囫圇吞棗 + 週期性懶散，結論就是：還是寫程式好 \囧/。不過當網路的東西念通了、能把那些 P 分層別類安頓好，事情就會變得美妙。從 y2k 到現在，似乎也只有 RG-58 消失，RJ-45 的接頭依舊是「白橙橙白綠藍白藍綠白綜綜」，TCP/IP 還在、而且 IPV6 離一般人很遙遠。是多了一些東西，但是跟寫程式比起來，可少得多了.......
喔喔喔... 回歸主題 [毆飛]
----------------
資料來源：《Cisco 路由器設定 (Managing IP Network witch Cisco Routers)》 p.36-39，O'Reilly 1998.12 初版，ISBN：957-98213-7-2。
集線器、橋接器、Switch 與路由器在討論路由器的放置地點之前，先確定你是否需要一台路由器。能不能用 Switch（交換器）或 Bridge（橋接器）之類的設備代替？通常網路公司的業務員不會回答這類的問題，但每種設備在網路中都有獨特的地位。你必須了解它們各自的特性，尤其是他們的弱點。
最 簡單的網路設備就是集線器（Hub），應該也是網路上最常見的機器。一般網路如 Ethernet，Token Ring，或 FDDI 都會有 Hub，選購安裝都沒有什麼學問。我們就略過不談。Hub 的等級和價格沒太大差別，主要是有沒有操作界面。但 Switch，Bridge，和路由器就完全不是這麼回事了。
幾年之前，還有人在爭論網路是該透過 Bridge 還是該透過路由器連接。Bridge 陣營堅持路由器太複雜，速度太慢，設定維護太困難；路由器陣營則預測網路會大幅成長，Bridge 將無法應付。當然，路由器最後佔了上風，網路成長的規模出乎每個人的意外。路由器的可擴充性（Scalability）是 Internet 成長的動力。
為什麼 Bridge 的擴充性不夠？這牽涉到 Bridge 本身的運作原理。當一台Bridge 收到來自網路的框包（frame），會檢查框包內的目的地位址，和自己知道的地址比對；找到符合的位址之後，它會決定是否傳送這個框包到目的地所屬的網路 區段，或是轉送到目前目的地中途的區段。如果 Bridge 知道框包是來自和目的地同樣的區段，它會忽略這個封包，因為目的地自己會接收。
如果 Bridge 不知道目的地位址，它會假定目的地可能在任何地點，直接傳送框包。如果目的地傳回一個回應訊息，Bridge 會根據訊息中的位址加在自己的位址紀錄中。所以 Bridge 是根據收到的框包位址來判斷網路組成的架構。
這個程序就是 Bridge 運作的核心。但某些框包是 Bridge 必須送到每個地方的，就是 Multicast（多址傳送）與 Broadcast（廣播）框包。由於網路上每台機器都必須收到這些框包，意思是網路上會充斥（flooded）這些框包。
Broadcast 和 Multicast 類型的框包限制了 Bridge 網路的擴充規模。當網路上的機器數量增加時，需要廣播的框包也隨之增加。平均來說，一台機器每十秒送出一個廣播，如果網路上有 1000 台電腦，平均每秒就有 100個廣播在流竄。如果有十萬台機器，情況將難以想像！
佔據頻寬並非廣播的唯一問題。因為每台機器必須時時檢查廣播框包的內容，所以會透過中斷處理。如果一直造成中斷，機器效率會慢下來，網路協定堆疊也會難以運作。
難 道機器每十秒一定要送出廣播嗎？想想廣播與多址傳送的應用情況。在IP 協定裡面，廣播是應用在位址解析（ARP，Address Resolution Protocol），路由更新，以及 rwho 之類的服務。Multicast 的應用功能大致差不多，但相對 Bridge 構成的網路來說，Multicast 和 Broadcast 沒什麼差別，反正都是要充斥整個網路。有些 Multicast 和 Broadcast 封包是定時傳送的，以 rwho 和一些路由協定資訊來說，大約每 30 秒會送出一次。
但 rwho 在這個週期之下只能送出一個封包，某些路由協定如 RIP 可以送出許多封包。對一個大型網路來說，可能一次有 10 個封包。
其 他協定對 Broadcast 和 Multicast 傳輸也有一些影響。AppleTalk 這種協定在進行資源搜尋，位址指定，或路由等動作時，會大量使用 Multicast 和 Broadcast。Novell 的 IPX 協定在服務宣告與資源搜尋時也有類似的傾向。
看以上的敘述，你不得不相信，每台機器十秒一個框包算是相當保守的估算，如果加上其他稀奇古怪的協定，產生的框包傳輸絕對不只此數。
難道路由器就能擺脫這些問題嗎？路由器的擴充性是否比 Bridge 來得好？要回答這個問題，首先讓我們看看路由器的原理。
路由器採取的做法Bridge 在決定是否轉送框包時，是根據目的地的硬體位址。如果不知道目的地位址，或是確定框包前往的區段不在來源區段，就進行轉送。路由器傳送封包時的決定過程很類似，差別在於路由器根據的是網路層位址，而非硬體位址。但這不是唯一的差別。
真 正的差別在於網路位址是由人來指定的。原則上，具有共同 prefix 的位址都屬於同一個網路。相對上，硬體位址是製造廠商決定的，不管網路的實際配置。考慮實際的網路配置，可以增進資訊聚集（aggregation）的能 力。一個 1000 台主機的網路上的 Bridge 可能要追蹤 1000 個地點才能做出決定，但一台路由器只須追蹤 10 個以下的位址就夠了。這就是路由器高效率的主因。
資訊聚集的能力，使得路由器比 Bridge 具有更強的擴充性，但還有其他因素。Bridge 必須隨時注意網路區段的每個封包，因為它必須確定封包的目的地位址來決定是否傳送。路由器不需要隨時注意每個封包，因為封包傳送者已經決定了封包是否要轉送。如果傳送者知道目的地不在本身的區段，就利用路由器本身的硬體位址當作目的地位址，直接傳送給路由器。所以路由器只需要注意直接傳給它的封包，大大降低了路由器處理的流量。
Routing 的可擴充性還有更重要的因素。Bridge 必須傳送所有的Broadcast 和 Multicast 封包，但路由器採取不同的做法。因為路由器知道網路的實際配置，它會建立廣播網域（Broadcast domain），這只是網路的一部分，但網路上所有的機器都可以看到廣播封包。除非特別設定，否則路由器不會隨便傳送廣播封包。例如，你可以設定一台路由 器轉送 BOOTP 或 DHCP 的廣播給遠端伺服器，傳送 IP Multicast 封包給已登錄的主機。除了節省 Broadcast 和 Multicast 的傳輸之外，路由器在其他方面也可以減低頻寬的使用量。
除此之外，如果路由器收到一個無法傳送目的地的封包，它會丟棄（drop）這個封包，並回應一個訊息給寄出封包的主機，表示傳送失敗。
總結來說，路由器的擴充性是由於下列幾個因素：
- 由於網路位址是配合實際配置來指定的，它具有高度的資訊聚集能力。
- 它不必隨時注意區段上的每個封包。
- 它會建立廣播網域，減少不必要的 Broadcast 和 Multicast 封包傳送。
- 它會丟棄不明位址的封包，減少頻寬的浪費。
路由器與 Switch路由器顯然比 Bridge 優越，只是 Bridge 不需要複雜的設定程序，也沒有人會為 Bridge 設定特別寫一本書。由於電腦硬體的速度越來越快，反而網路的頻寬成為新的問題，這就是 Switch 出現的背景。
Switch 絕大部分都是應用在 Ethernet 上（目前 Token Ring 與 FDDI switch 也日漸普遍），它透過分散頻寬的方式增加頻寬的使用效率。你可以更換硬體增加頻寬，例如將 10Mbps Ethernet 換成 100Mbps Fast Ethernet，但你得同時需要更換新的集線器，網路纜線與網路卡，這是一筆不小的花費。
Switch 扮演了一個特殊的角色。在一個分享的網路區段上，每台主機都是碰撞網域（Collision Domain）的一部分，因為 Ethernet 的傳輸會互相爭奪頻寬導致碰撞。路由器有能力縮減碰撞網域的範圍，但成本太高，而且設定複雜。以一個連接 24 個 Ethernet 區段的高速路由器來說，大概需要 10 萬美金。但一台 24-Port 的同級 Switch 只需要 8 千美金左右。那為什麼不乾脆把路由器甩在一邊，全部都用 Switch 就好了？一旦你明瞭Switch 運作的原理，答案就很明顯了。讓我們先看看 Switch 工作的方式。
當 Switch 收到一個框包，它必須判斷目的地在網路上的位置。Switch 檢視框包內的目的地硬體位址，檢查轉送表，如果找到符合的資料，就將框包送往表上指定的埠。如果找不到，它就將框包送往除了來源之外的每一個埠，希望收到 的目的地會送出一個回應，讓 Switch 更新本身的轉送表。廣播與 Multicast 都送往每個埠。
----------------
另外 p.40 頁說，switch 說穿了，就是一個多 port 的 Bridge
其他的沒啥好提的，所以就省略不 post 了
