上一小節，我們以兩臺主機為例，討論了一個理想化的物理層模型。 現在，我們將問題進一步延伸：多臺主機如何實現兩兩通訊呢？我們以三臺主機為例進行討論：  如上圖，有 _3_ 臺主機，名字分別是： _ant_ 、 _bee_ 以及 _cicada_ 。 為了實現主機間通訊，我們將三者連線到一根共用導線。每臺主機都可以改變導線電平，也可以檢測導線電平。 與此同時，假設在硬體層面，多方通訊衝突仲裁機制已經實現並且可用。 這樣，是否就解決了多主機通訊問題呢？ # 定址 假設， _ant_ 向 _bee_ 傳送一個數據 `11110000` (粗體)。由於導線是共享的，所有主機都可以檢測到電平訊號。換句話講， _bee_ 和 _cicada_ 都會收到這個資料 `11110000` ，而 _cicada_ 本不應該接收這個資料！另一方面， _bee_ 收到資料後，也不知道資料到底是誰發給它的。  > 為了簡化接下來的討論，我們省略了物理層起止控制位元 `1010` 和 `0101` 。 資料不禁產生困惑：_我從哪來？去往何方？_ 為此，我們需要引入一些位元，用來標識資料的 **來源** 以及 **目的地** 。例子中只有 _3_ 臺主機，兩個位元就足以唯一確定一臺主機： | **機器** | **位元** | | -------- | -------- | | ant | 00 | | bee | 01 | | cicada | 10 | 那麼，傳送資料時，再加上兩個位元用於表示來源主機，兩個位元表示目標主機，問題不就解決了嗎？ 如圖，主機下方的灰色位元唯一標識一臺主機：  _ant_ 傳送資料時，在最前面加上兩個位元(紅色)用於標識來源機器， `00` 表示 _ant_ ；另外兩個位元(綠色)用於標識目標機器， `01` 表示 _bee_ 。 當 _bee_ 收到資料後，檢查前兩個位元(紅色)，值為 `00` ，便知道它是 _ant_ 發出來的；檢查緊接著的兩個位元(綠色)，值為 `01` ，與自己匹配上，便愉快地收下了。相反， _cicada_ 收到資料後，發現 `01` 和自己 `10` 匹配不上，便丟棄這個資料。 新引入位元所起的作用，在計算機網路中稱為 **定址** 。 這兩個位元也就稱為 **地址** ，其中，紅色為源地址，綠色為目的地址。 引入定址機制後，我們完美地解答了資料從哪來，到哪去的困惑。 # 複用與分用 通道只有一個，但是通訊需求是無窮無盡的——傳輸研究數值、檔案列印、即時通訊，不一而足。 如何解決這個矛盾呢？套路還是一樣的——引入新的位元標識資料型別。 假設，總的通訊需求就上面這 _3_ 個。那麼， _2_ 個額外的位元即可解決問題。 | **型別** | **位元** | | -------- | -------- | | 研究資料 | 00 | | 檔案列印 | 01 | | 即時通訊 | 10 | 舉個例子，假設 _ant_ 向 _bee_ 上報研究資料並列印一個檔案：  _bee_ 接收到資料後，根據紫色位元，決定資料如何處理。通過新引入的紫色位元，我們在同個通道上實現了不同的通訊！ 接下來，從理論的視角來審視這個場景：  通道只有一個，卻要承載多樣的通訊任務。在傳送端，通過加入紫色位元，將不同的資料通過一個共用通道傳送出去，這個過程叫做 **複用** ( _Multiplexing_ )；在接收端，從共用通道上接收資料，然後檢查紫色位元決定資料如何處理，這個過程叫做 **分用** ( _Demultiplexing_ )。 在接下來的章節，我們將看到 **複用分用** 的思想貫徹計算機網路的始終。 到目前為止，我們引入了 _3_ 種不同的位元，分別是 **源地址** 、 **目的地址** 以及 **資料型別** 。 對於這些位元的位數以及含義的約定，便構成 **網路協議** 。 至此，我們解決了多臺共用通道主機間的通訊問題，這相當於網路分層結構中的 **資料鏈路層** 。資料鏈路層負責為上層提供鏈路通訊能力，主要作用是： - 定址 - 資料複用/分用 資料鏈路層的協議有很多，下節我們將介紹其中最常用的 **乙太網協議** 。 【小菜學網路】系列文章首發於公眾號【小菜學程式設計】，敬請關注： ![](https://cdn.fasionchan.com/coding-fan-wechat-soso.png?x-oss-process=image/resize