網絡分層概述

時間 2019-11-10

標籤網絡分層概述欄目系統網絡简体版

原文原文鏈接

市面上有不少介紹網絡是怎麼分層的，及每層負責些什麼的書，但不多看到有書介紹爲何要這麼多分層。緩存

本篇將試着從分層是怎麼來的這個角度分析一下網絡是如何一步一步發展到今天這樣的，但願對網絡初學者有所幫助。安全

注意：內容是根據本身已有的網絡知識構思出來的，可能跟實際狀況有出入，僅供參考。服務器

本文采用TCP/IP詳解裏的5層結構，即物理層、鏈路層、網絡層、傳輸層和應用層，而且只討論以太網和常見的組網方式，不考慮特殊場合的應用。網絡

物理層

物理層就是如何將多臺設備連起來，無論是有線仍是無線的方式，都是讓設備之間能交換數據，因此物理上的連通是必不可少的，否則就無法通訊了。性能

若是隻有一臺設備，就不須要和別人通訊；兩臺呢？直接弄根線連上就能夠通訊了。操作系統

三臺呢，怎麼連？能夠像下面這樣，三根網線搞定設計

+-------+
    +--------->| Node2 |<---------+
    |          +-------+          |
    |                             |
    ↓                             ↓
+-------+                     +-------+
| Node1 |<------------------->| Node3 |
+-------+                     +-------+

四臺呢，這麼連？code

+-------+
    +---------->| Node2 |<----------+
    |           +-------+           |
    |                               |
    ↓                               ↓
+-------+                       +-------+
| Node1 |                       | Node3 |
+-------+                       +-------+
    ↑                               ↑
    |                               |
    |           +-------+           |
    +---------->| Node4 |<----------+
                +-------+

雖然四根網線搞定，但帶來至少兩個問題：dns

Node2和Node4之間怎麼通訊？首先確定得通過Node1或者Node3，就算能根據網絡繁忙程度進行智能的選擇，Node1和Node3也須要把部分精力用在幫忙轉發數據包上，就算轉發消耗的系統資源能夠忽略不計，但Node1和Node3之間的通訊呢？因爲帶寬有限，Node1和Node3之間的通訊確定會受Node1或者Node3之間通訊的影響。想象一下，寢室裏面有四我的，A和C之間傳一個電影，致使B和D之間打局域網遊戲卡的要死，你說B和D惱火不？遊戲
Node2和Node4關機以後，Node1或者Node3之間就無法通訊了，也就是說若是這個環裏面有兩臺設備下線，那麼就會變成兩個單獨的網絡

改進成這樣呢？

+-------+
    +---------->| Node2 |<----------+
    |           +-------+           |
    |               ↑               |
    ↓               |               ↓
+-------+           |           +-------+
| Node1 |<----------+---------->| Node3 |
+-------+           |           +-------+
    ↑               |               ↑
    |               ↓               |
    |           +-------+           |
    +---------->| Node4 |<----------+
                +-------+

確實解決了上面的那兩個問題，新的問題出現了：一臺電腦要連三根網線，總共是3+2+1=6根網線，看起來還好，但想象一下有10臺機器，那就是10+9+8+7+6+5+4+3+2+1=55根，根本無法想象應該怎麼佈線。

很明顯這種只靠網線的辦法在局域網中就行不通，更別說將世界上全部設備互聯了。

因而人們想到引入一種新的設備，用來負責鏈接各個機器，機器只要和這個新的設備打交道就能夠了，因而有了下面這樣的鏈接方式：

+-------+
                | Node2 |
                +-------+
                    ↑
                    |
                    ↓
               +--------+
+-------+      |        |      +-------+
| Node1 |<---->| Device |<---->| Node3 |
+-------+      |        |      +-------+
               +--------+
                    ↑
                    |
                    ↓
                +-------+
                | Node4 |
                +-------+

這樣看起來就簡潔多了，而且往這個網絡中添加機器也很是簡單，牽一根線到中心的那個設備就能夠了。固然這樣的組網也有缺點，那就是中心的那個設備掛了後，整個網絡就不通了，因此中心設備的功能必定要越簡單越好，這樣就能保證其穩定性。

其實上面的這兩種鏈接方式就是咱們常說的環形網絡和星形網絡，環形網絡不常見，只在某些特殊場合使用，而星形網絡就是咱們如今常見的組網方式。

有了星形網絡後，物理鏈接上沒問題了，那麼接下來的問題就是怎麼通訊，Node1要發數據給Node4，確定要先發給中間的Device，那麼Device怎麼知道要發給Node4，而不是Node3呢？ Node1和Node3都給Node4發數據，Node4怎麼區分數據是誰發過來的呢？這時候鏈路層就登場了。

鏈路層

爲了解決上面物理層遇到的問題，聰明的人們設計了一種鏈路層協議，叫以太網協議。

由於機器之間要經過網線通訊，那麼每臺機器上都有一個處理數據傳輸的硬件，這個硬件就是網卡，在以太網協議中，要求每一個網卡都要有一個地址，就是咱們常說的網卡（mac）地址，而且這個地址必須惟一，不能衝突。

爲了解決網卡地址惟一這個問題，人們將網卡地址拆成兩個部分，第一部分是廠商的ID，另外一部分由廠商本身控制，因爲廠商的ID是惟一的，因此只要廠商本身不生產一樣mac地址的網卡，那麼全部廠商的網卡地址都將惟一。

有了mac地址後，Node1給Node4發的數據包中就能夠帶上各自的mac地址，這樣就能惟一的標識這個包是由誰發給誰的了，這樣的數據包就是以太網數據包，固然以太網協議還有其它的字段，但這兩個字段是最重要的。

如今知道數據包是由誰發給誰的了，另外一個問題來了，中心的那個Device收到Node1發給Node4的包以後，怎麼知道Node4是鏈接到哪一個端口上的呢？

最開始人們採用了一種簡單粗暴的方法，那就是羣發，因爲中心的那個Device不知道Node4鏈接到哪一個端口的，那麼它就會將數據複製多份，向全部端口都發一份（Node1所在的端口除外，由於Device知道數據包是從這個端口發進來的），這樣Node4就收到了Node1發過來的數據，固然其它兩個Node也會收到相應的數據包，但網卡很老實，發現不是發給本身的數據包，就不看包裏面的內容，直接把數據包丟棄了。

上面這種簡單粗暴的設備就是咱們常說的集線器（Hub），從它的工做方式咱們能夠看出它有兩個缺點：

數據不安全： Node1發給Node4的數據會被髮送到Node2和Node3上去，雖然網卡默認狀況下會丟棄該數據包，可是也能夠設置網卡爲混雜模式，從而能夠接收並處理這些數據包。
性能差： Node1跟Node4通訊的全部數據包都要發給Node2和Node3一份，一方面增長Device的壓力，而且還要佔用和Node2及Node3之間的帶寬

爲了解決集線器的問題，人們發明了交換機，跟集線器相比，交換機裏面多了一張轉發表，裏面包含了mac地址和端口的對應關係，大概以下：

mac地址	端口
02:42:83:06:75:13	2
08:00:27:03:d0:e7	2
ee:35:41:bb:a4:60	3
02:42:34:8F:0E:FE	4

上表中，02:42:83:06:75:13和08:00:27:03:d0:e7鏈接在交換機的2號端口，ee:35:41:bb:a4:60鏈接到3號端口，02:42:34:8F:0E:FE鏈接到4號端口。

這裏02:42:83:06:75:13和08:00:27:03:d0:e7都與端口2相連，表示與端口2鏈接的是一個交換機或者有多個虛擬網卡的主機。

有了這張表以後，交換機收到數據包以後，就知道要從哪一個端口發出去了，因而解決了集線器的那兩個問題，那麼這裏又有一個問題，這張表示從哪裏來的？？

交換機在剛啓動時，這張表是空的，當收到第一個數據包的時候，它也不知道要從哪一個端口轉發出去，因而它採用和集線器同樣的方式廣播出去。當交換機每次從一個端口收到數據包時，都會提取數據包裏面的源mac地址，而後將這個mac地址和端口的對應關係添加到（或者更新）轉發表，這樣很快就會將轉發表構造起來，就算有網線換了端口，也會及時的更新轉發表。

有了交換機後，局域網是搭建起來了，可是能夠經過N個交換機將世界上的全部機器都連起來嗎？就像下面這樣：

+---------+
                                |         |        +-------+
                +-------+       | Switch3 |------->| Node5 |
                | Node2 |       |         |        +-------+
                +-------+       +---------+
                    ↑                ↑
                    |                |
                    ↓                ↓
               +---------+      +---------+      +---------+      +----------+
+-------+      |         |      |         |      |         |      |          |        +--------+
| Node1 |<---->| Switch1 |<---->| Switch2 |<---->| ....... |<---->| Switch N |------->| Node N |
+-------+      |         |      |         |      |         |      |          |        +--------+
               +---------+      +---------+      +---------+      +----------+
                    ↑                ↑
                    |                |
                    ↓                ↓
                +-------+        +-------+
                | Node3 |        | Node4 |
                +-------+        +-------+

答案是否認的。雖然每一個Node都有一個惟一mac地址（UUID），但這個UUID裏不包含任何其它信息，這給數據的全網傳輸帶來了很大的問題。

想象一下咱們每家每戶都用一個UUID來標識，沒有咱們如今用的地址和郵編，那麼把我家的地址給你，叫「912FAD50-07B2-4FBA-8F65-4537ABEF5670」，請問你要怎麼找到我家？若是咱們是一個村的人，那還不是特別難，村委會把全部住戶的UUID都收集起來，找人的話去村委會問就好了，若是咱們不在一個國家呢？這下很差辦了，要不你家村委會特別強大，知道世界上全部住戶的UUID，而後告訴你下一步再去哪裏問，要不村委會沒這能耐，只能告訴你去鎮上問，鎮上再讓你去市裏問，最終問到一個可能相似叫國家信息中心的地方，它告訴你地址是在美國（假設目的地是美國），因而你得去美國的國家信息中心去問，把相關的人問了個遍終於知道了我在哪裏。

上面的方法看起來最終也能找到，那問題在哪裏呢？簡單的列幾條

如今世界上聯網的設備大概有幾十億，而且每一年還在瘋狂的增加。要有一個機制來管理全部的這些UUID，而且能高效的在裏面找到想要的數據，這幾乎是不可能的，交換機的轉發表都會很是大，性能確定跟不上
如今移動設備已經佔據了很大的份額，位置老變來變去，意味着由UUID構成的網絡拓撲結構老在發生變化，那怎麼能保證及時的將地址變化狀況更新到那些管理機構呢？估計光更新的請求就把網絡給撐爆了
沒隱私，走到哪裏都是那個UUID，都有人知道你在哪裏，恐怖不？

因此在實際操做中這種辦法根本不可行，就像郵局沒法根據你提供的UUID找到你家地址同樣。這個時候就須要一種相似於「湖南省長沙市嶽麓區xxx路xxx號」的東西，因而網絡層的IP登場了。

網絡層

網絡層的IP地址就是咱們想要的相似於「湖南省長沙市嶽麓區xxx路xxx號」的東西。

IP從哪裏來

對於生活中的地址，好比說湖南，爲何要叫這個名字，爲何管理的範圍是如今這樣？國家層面說了算（固然不是瞎說，根據歷史狀況來定），湖南下面要分幾個市呢？湖南省本身進行劃分。地址一旦規劃好，就很穩定，不多變，變化的時候就是合併行政村、撤縣設市、設置直轄市啊之類的。

IP地址也差很少，一旦分配好了就不會常常變化，好比給湖南分了那麼多的IP段，那麼就不會頻繁的變化，一直都是湖南的；惟一不一樣的是生活中的地址沒有長度限制，而IP地址有長度限制，IPv4的地址範圍只有40億左右（當時設計的時候以爲夠用了，結果如今悲劇了...）。

既然資源有限，那麼就有分配的問題，先到先得，因爲歐美髮達，上網的人多，因此申請比較積極，搶去了大部分的地址空間，像非洲這樣的，就只搶到不多的份額。地址分配機構也是一級一級的，好比我是中國電信公司，須要大批的IP，那麼我就去向負責亞太地區的機構去申請，若是機構發現如今有多餘的，就會直接分配地址給我，若是沒有那麼多，它會向它的上級要資源，因此這事和申請域名、通訊頻道是同樣的，申請必定要積極，否則就被別人搶去了，等拿到分配給個人IP地址段後，就能夠一級一級的往下再分配下去了，內部怎麼分就看本身怎麼管理了。

如今再去申請IPv4已經沒戲了，2011年IPv4地址就被分配完了，如今該搶IPv6了，不過IPv6地址空間大，不必那麼急着搶，而且也不是誰都能申請，想申請都少就能申請多少的，只能按需申請，再說也不是免費的。

IP如何路由

爲了簡化討論，這裏討論的IP地址都是IPv4公網地址，不考慮內網地址，不考慮NAT轉換的狀況。同時因爲網段的劃分和路由是個很複雜的過程，在這裏不討論路由表是如何構造並更新的。

有了IP地址以後，咱們就須要一個能轉發IP數據包的設備，那就是路由器，有了路由器以後，咱們的網絡就變成了這樣：

+---------+
                                |         |        +-------+
                +-------+       | Switch2 |<------>| Node4 |
                | Node2 |       |         |        +-------+
                +-------+       +---------+
                    ↑                ↑
                    |                |
                    ↓                ↓
               +---------+      +---------+      +---------+      +----------+        +---------+
+-------+      |         |      |         |      |         |      |          |        |         |       +--------+
| Node1 |<---->| Switch1 |<---->| Router1 |<---->| ....... |<---->| Router N |<------>| SwitchN |<----->| Node N |
+-------+      |         |      |         |      |         |      |          |        |         |       +--------+
               +---------+      +---------+      +---------+      +----------+        +---------+
                    ↑                                                                      ↑
                    |                                                                      |
                    ↓                                                                      ↓
                +-------+                                                              +----------+
                | Node3 |                                                              | Node N+1 |
                +-------+                                                              +----------+

有了IP地址後就很容易路由了，原理跟投遞郵件如出一轍，想象一下投遞郵件，假設你在上海，要寫一封信給北京的朋友，首先得找到最近的郵局，把信投進去，信封上會填上收件地址和發件地址，而後會有工做人員將信件發到下一站，下一站會有工做人員接手再發給下一站，通過幾回中轉到了上海總站，而後由上海總站再發往北京總站，北京總站再派工做人員一級一級的下發，最終將信件送到你朋友手上。

再來看看網絡中的數據包，假設上海的A要給北京的B發一個數據包，首先得根據他本身的路由表（由本身配置）和B的地址，找到最近的路由器（這就跟上面找郵局是同樣的，路由器就至關於郵局），路由器會根據它的路由表將數據包再往外發，多是先到上海的某個中心路由器，而後再由它發給北京的路由器，最後由北京的路由器一級一級的往下發，最終到B的手中。

咋一看好像也是一級一級的轉發，那跟前面被否決的鏈路層交換機的轉發有什麼不同呢？

路由器裏的路由表要小不少：IP是一段一段的有範圍的，整個中國的IP段可能也就幾百條，這幾百條再被各個省分紅不一樣的小的IP段，那麼全部省一級的IP段總共加起來也差很少萬條的級別，跟幾十億級的設備數量來比要小多了。而且IP範圍和生活中的地址是同樣的，不怎麼變化，不須要頻繁更新。
IP地址的位置是固定的，不須要頻繁更新：移動設備就像是城市裏的流動人口同樣，人會常常租不一樣的房子，但房子自己的地址不會發生變化，就是說移動設備換地方後會換IP地址，但IP地址所關聯的路由器是不會變化的，即IP地址在整個網絡拓撲中的位置不會變化，變化的是設備的位置。
更好的隱私：因爲你們都用IP通訊，而IP沒有和具體的設備綁定，給你一個IP地址，你只知道它大概位置在哪裏，但你不知道用這個IP上網的設備是什麼（固然能夠經過其它的手段知道，但根據IP無法知道）。

IP和鏈路層的關係

你們都經過IP地址來通訊，但交換機只知道鏈路層，不知道IP層的任何信息，因而設備在向另外一個設備經過IP地址發送數據以前（經過交換機直接相連的兩臺機器），須要知道對方的mac地址，這個時候就用到了ARP協議，利用該協議，能夠根據IP地址獲得mac地址，固然，該協議只在局域網內有效，網絡中的每臺設備只和當前局域網的另外一臺設備直接通訊，想要訪問其它網絡中的設備，須要當前網絡中的其它設備代爲轉發，具有轉發IP數據包功能的設備，咱們就說它具備路由功能，通常就是咱們常說的路由器。

IP網絡這麼好，那咱們還須要鏈路層的網絡嗎？直接經過IP進行通訊就行了，還要mac地址幹嗎？答案是不行，仍是得依賴鏈路層。由於IP地址是邏輯上的東西，因此就要考慮分配問題，一臺設備加入了當前網絡，給它分配個什麼IP好呢？機器數量少且不怎麼變化的狀況下，能夠人工管理，作到地址不衝突，但在公共場合呢？你去了機場，連了機場的網絡，IP怎麼辦？機場工做人員給你找一個空閒的填上？就算機場有那閒功夫，專門派我的或者設備顯示當前網絡還有哪些IP是空閒的，你也煩啊，須要找到這我的或者設備，而且還要本身手動配置網絡IP；再考慮一種狀況，你坐在地鐵上，從閔行區到楊浦區，中間要通過徐彙區，在閔行區的時候你手機是在閔行區的網絡裏，等地鐵通過徐彙區的時候，你連上了徐彙區的網絡，IP地址咋辦，到哪去找一個沒被人佔用的IP地址？那麼多的人，怎麼保證不衝突？到了楊浦區的時候，又得人工切換，估計你都要崩潰了。因此網絡層仍是離不開鏈路層來完成一些它的管理工做。

IP衝突和動態分配

有了ARP後，系統在手工設置本身的IP以前，能夠經過ARP請求來問問當前局域網裏面有沒有一樣IP的機器，這樣就能夠有效的避免IP衝突。

同時爲了動態的分配IP，人們想出了DHCP協議，大概過程就是，當一個機器連進網絡的時候，先廣播一下，問當前局域網有沒有人能夠分配一個IP給它，當前網絡中的DHCP服務器收到請求後就會分配一個空閒的IP給請求的機器，應答包中還包含了子網掩碼和默認網關。有幾個問題須要注意：

因爲當前機器沒有IP，因此只能依靠鏈路層的廣播機制，因此它的範圍侷限於當前局域網(固然局域網的其它設備也能夠轉發該DHCP請求出去，從而實現跨網段的DHCP)
當前局域網只能有一個DHCP服務器，不然兩個服務器管理的地址可能衝突
在有DHCP服務器的網絡中也能夠手動的給本身配置IP，只要不使用被DHCP服務器管理的IP範圍，而且不和別人衝突就能夠了

IP層解決了將一個包從一地址發到另外一個地址的問題，但這個數據包是給誰的呢？

傳輸層

在生活中，一個地址多是一個家庭住址，或者是一個公司，郵件中除了包含收件地址和發件地址以外，還須要收件人和寄件人的信息，由於只有有了收件人的名字，才知道把郵件交到誰的手上。

網絡世界中也同樣，網絡（IP）層負責將數據包發到目的地址，但這個數據包是給誰的呢？機器上運行那麼多的進程，哪個纔是接收者呢？就須要一個東西來區分這些進程，因而就有了端口的概念，若是進程須要網絡通訊，就向操做系統申請一個端口，經過這個端口來惟一標識這個進程。

注意：端口是個抽象的邏輯概念，並非說機器上有那麼多的硬件端口。

這個時候UDP就登場了，它在IP協議的基礎上增長了源端口和目的端口字段，這樣一個UDP包就能惟一的肯定是從哪臺設備的哪一個進程發給哪臺設備的哪一個進程。

有了UDP，就能將包發送給指定設備上的進程，目的進程也能經過收到數據包中的源地址和端口，發送應答包回去。那這樣是否是就搞定了呢？

想一想發郵件，是否是有郵件丟失的狀況，丟失了會怎麼樣？丟失後形成的狀況是接收方沒收到郵件，發送方也不知道郵件丟了。爲了應對這種狀況，郵局推出了掛號信，就是若是郵件丟失，會通知發送方。

UDP也有這樣的問題，當線路繁忙的時候，路由器若是處理不過來就會將收到的包丟棄，這時目的端收不到數據包，發送端也不知道數據包丟了，因而形成通訊故障。這個時候TCP就登場了，它在裏面增長了一些收包確認及超時重傳的機制，保證數據包能完整的發送到目的地。

就如同掛號信比平郵要貴同樣，TCP要比UDP的開銷大，因此對於能夠接受丟包的場合，UDP仍是有一席之地。

應用層

經過傳輸層，數據包已經完整的發送到了接收進程手中，那麼數據包裏面包含了什麼數據呢？應該怎麼解析它呢？

想一想郵件，收件人收到以後打開郵件會看到什麼？多是一封普通的問候信，也多是一首詩，有多是中文的，也有多是英文的。總之要有必定的格式，而且是收件人能看懂的格式，不然這封信就沒有任何意義。

一樣的，收到數據包的進程打開數據包以後也須要能看懂數據包的內容，否則該數據包就沒有任何意義，數據包的數據要能被看懂，那就得必須有固定的格式，這種格式就是咱們常說的應用層協議，如ftp、http、dns、snmp等。發送方必須發送接收方能識別的協議格式，好比向http服務器只能發送http請求，若是發ftp請求過去的話，http服務器就不認得，無法處理，只能返回錯誤。

數據發到目的進程手上了，目的進程也能看懂數據的內容，因而一個成功的通訊過程就完成了。

完整的通訊過程

這裏以一個dns請求爲例，描述一下數據包的傳輸過程，由於dns默認是udp協議，因此比較直觀。

假設dns服務器的IP是8.8.8.8，端口是53

應用層構造一個DNS包，而後告訴UDP層發到8.8.8.8的53端口
UDP層收到包後，構造一個UDP包，裏面的數據就是DNS包的內容，目的端口是53，源端口由操做系統分配一個（或者能夠經過綁定的方式本身指定一個），而後告訴IP層讓它把這個UDP包發給8.8.8.8
IP層收到請求後，就去查詢路由表，看這個包應該怎麼出去
在這種狀況下，因爲8.8.8.8跟本身不在一個子網，因而會找到默認網關的IP，同時獲得本身應該用哪一個IP及哪一個網卡發包出去；這裏假設咱們只有一個網卡eth0，IP爲192.160.64.12。
構造一個IP包，裏面的數據是UDP的內容，目的IP是8.8.8.8，源IP爲192.160.64.12
構造ARP數據包，源地址爲eth0的mac地址，目的地址爲鏈路層廣播地址，廣播局域網，得到網關IP對應的mac地址
通知鏈路層將這個IP包發給網關對應的mac地址
鏈路層收到請求後，構造以太網包，目的地址爲網關的mac地址，源地址爲eth0的mac地址，內容爲上面構造的IP包，而後發送給網關
網關收到數據包後，一看目的IP是8.8.8.8，跟本身不在一個子網，因而就查看本身的路由表，而後將數據包發給下一個路由器（發給下一個路由器的過程和上面的6~8步相同）
直到這個數據包到了最後一個路由器，該路由器發現8.8.8.8跟它其中的一塊網卡在同一個子網，因而經過那塊網卡直接發給8.8.8.8（發給8.8.8.8的過程和上面6~8步中發給網關的過程相同，只是目的地由網關變成了8.8.8.8）
8.8.8.8收到數據包一看，發給53端口的，因而就轉給了DNS服務器進程
DNS服務器進程讀取包的內容後，構造應答包，而後根據源IP和源端口，跟請求包同樣的流程，將應答包發給了請求方