網絡層協議
網絡層協議
前言
在好久之前的章節，已經介紹了應用層， 運輸層相關的東西。已經大概對數據到底是如何從一臺主機到另外一臺主機有所瞭解，即端到端。html
瞭解了在TCP中數據收發兩端到底是如何保證數據的有序性，可靠性等特性。又是如何進行流量控制， 如何控制應對網絡擁塞，其中又包括，網絡擁塞的定義。同時還知道了，如何創建起一條TCP鏈接，通話雙方又是怎樣斷開鏈接的。而相應的，天然也是明白了 UDP究竟是一種不負責任的傳輸方式。算法
而且咱們也發現一點，將數據從傳輸層丟進網絡層以後就無論不顧了，維護數據的有序性，可靠性等等其餘的特性大都由傳輸層自身來實現。windows
那麼這一篇章就是來看，當數據進入網絡層以後怎樣經過重重管道到達另外一端的。緩存
數據報格式
當數據從運輸層傳輸到網絡層的時候， 此時對於網絡層而言並不區分上層到底是TCP或是UDP，在發送到網絡層的時候被做爲一個總體來看待。安全
而IP數據報格式以下：服務器
4bit的版本號，與大多數數據格式同樣，一開始指定的都是版本號，決定接下來的數據究竟該以怎樣的方式被解讀。而IP協議，目前有IPv4， IPv6兩種版本。網絡
4bit的首部長度，與TCP協議相似，在其首部有 可選項部分， 是以，IP首部長度不定，須要經過這個字段指示數據究竟從哪裏開始。架構
8bit的服務類型，將不一樣類型的IP區分開來。工具
16bit的數據報長度，IP首部 + 數據 因此理論上最大支持度數據報長度是65535字節，但因爲計算機網絡中的MTU限制，最大長度通常爲1500字節。數據超出這個長度就要進行分片處理。至於更多則在本節下的補充中進行說明。性能
16bit標識， 13bit片偏移， 3bit標誌， 這部分是爲IP分片而服務的。
8bit壽命（Time-to-live TTL）， 保證數據不會永遠在網絡環路中循環，當數據通過一臺路由器時， TTL - 1， 當爲0，則數據被丟棄。
8bit協議號， 在應用層與運輸層之間，經過端口號將二者粘合，而在運輸層與網絡層之間則是協議號， 僅當到達目的地才起做用，指定運輸層協議到底是什麼。
16bit校驗和 將IP首部每兩個字節當作一個數，用反碼運算對這些數求和。當不一致須要丟棄數據， 而路由器須要從新計算校驗和放回原處，由於可能TTL值會發生變化。 而之因此IP與運輸層都要進行校驗和計算，是運輸層校驗首部及數據不一樣， IP校驗和僅計算IP首部。另外一點則是，IP層並不必定必須與運輸層同時使用。
32bit源IP地址
32bit目的IP地址
選項， 可選項， 因爲選項的存在使得路由器處理IP數據有了額外開銷，在Ipv6中已經去掉這一點。
數據， IP數據報的核心部分。
須要注意到的一個地方是，IP首部長度爲20字節，若是在運輸層採用的是TCP協議，則每條數據報須要承載的首部有40字節。
IP數據報分片
須要注意到的是， 不一樣的鏈路協議對數據的承載能力是不一樣的， 以太網中最大承載的能力不超過1500字節，一個鏈路層幀所能承載的最大數據量就被稱做是MTU。
可是咱們知道， 對於IP數據報，其長度最大爲65535字節，遠遠超過MTU數值，須要作的就是將數據報進行分片，切分紅更小的數據發送，這些較小的數據報就被稱爲片。
但分片以後，又是怎樣保證數據報可以被恰當的還原呢？這就須要相應的標識，偏移量， 標誌位，來肯定當前數據流是否結束，以及片在原始數據中所處的位置，以便進行正確的還原。同時須要注意到一點的是， 在從一個個網絡節點向下一節點發送的過程當中，可能對上一節點適用的數據片大小對下一節點就再也不適用，須要在當前節點再次進行數據分片處理。 這無疑加大了網絡層的負擔。 同時，不得不考慮到安全性問題， 畢竟須要按照必定規則進行數據的重組， 若是惡意發送的數據
因此在IPV6中廢棄掉了這一點，禁止在IPV6的網絡層進行分片處理，對於太大的數據直接讓在源端中進行分組，網絡層的中間節點再也不負責處理這件事情。可是依然會有上一節點的MTU與當前節點的MTU不一致的狀況出現。對待這樣的現象有兩點做爲保障，一是要求支持IPV6的節點，其鏈路層都要提供1280MTU的容量。 而不免依然會出現小於1280的狀況出現，那麼IPV6對於本地始發的數據報則進行分片， 並不違背原則， 而非本地始發的分片則會被丟棄！！！而且給源端發ICMPv6 'Too Big'消息。
IPV4編址
而對於一臺主機而言，到底是怎樣連接進入網絡的？
一臺主機一般只有一條鏈路鏈接到網絡，當想要發送數據時，則在該鏈路上進行發送，主機與物理鏈路之間的連接則被稱爲接口。對於PC而言，功能較爲單一，而對於路由器來講，它須要從一條鏈路上接收數據並向另外一條鏈路發送數據，所以至少有兩條鏈路。 IP要求每一個接口都有本身的IP地址，所以IP並不是與主機， 路由器， 而是與接口相關。
也所以， 一臺路由器必然會存在多個IP。 對於IPv4而言，其地址長度爲32位，所以最多可以擁有40億地址，而IPv6的長度爲128位，沒必要擔憂。 那麼僅僅40億地址，對於全球來講夠用嗎？在如今這個時代來講是顯然不夠用的，畢竟可以接入網絡的設備是這樣多，每臺設備分配一個IP地址的話， 怎麼夠用呢？
這個問題暫時留在這裏，稍後再提。
先來看一下IP編址規則。
IPV4長度爲32位， 對於咱們平常生活中所見到每每是這樣一種地址 192.168.0.9 大概相似於這樣的數字， 每3位對應8bit，不難發現， 最大值必然是
1111 1111 1111 1111 1111 11111 1111 1111
32位均爲1， 最大值也就是 255.255.255.255.
如今咱們已經有了屬於本身的IP地址，在發送數據的時候終於有了本身的名字，那麼接下來呢？ 該怎樣讓全世界聽到個人聲音呢？
路由 轉發
當咱們向外界發送一條消息時，主機中的網絡層會將對應的數據封裝成 IP層數據報，即網絡分組， 而後經過鏈路向路由器發送，路由器拿到發送的數據，知道了你的目的IP，而後經過路由規則在轉發表裏查找，決定了須要將數據發送的下一個節點是誰。
和快遞比較相似，當收到一批貨物，根據貨物的不一樣地址發送到相關的省市，根據更詳細的地址進一步分揀，層層處理，最終發送到目的地。
轉發：就是在路由器內部，從入鏈路到出鏈路之間的一個過程。
路由：在整個網絡中，根據每一個路由器中的轉發表， 選擇發送的路線。
作分組交換的有兩種， 一種是根據鏈路層關鍵字肯定的， 另外一種則是根據網絡層首部字段肯定的， 分別被稱做鏈路層網絡交換機， 路由器。 在這裏提到的都是路由器。
對於一個路由器而言，可能有多個出鏈路接口，以便將目的地不一樣的數據報發送到不一樣的路由器中去。而轉發時，使用的時目的地址的前綴進行匹配。假定以 111.222.111.開始的目的地址須要被髮送到1號接口， 111.222.112.開始的須要被髮送到2號接口，路由器所須要的就是根據前綴去進行匹配，完成端口的選擇轉發。
可是會存在這樣一種可能性，多個轉發項均可以匹配成功，如對於 IP地址 111.222.111.111而言， 既能夠匹配111.222.. 也能夠匹配111.222.111.*，當有多個匹配項時，路由器採起的是最長匹配前綴原則，即與轉發表中最長的匹配項進行匹配。 合適的就轉發。
而這種規則，也並非沒有原因的。
每一個人都都有屬於本身的IP地址，若是分配混亂的話尋址就是一件很不方便的事情，這樣每臺路由器必須知道對方的精確地址才能進行導航。 是按照必定的規則進行分組的， 將整個地址空間劃分爲一個個子網，經過子網層層鏈接，將整個網絡家庭關聯起來：
A.B.C.D/n, 表示32位IP地址的前n位與A.B.C.D的前n位相同。好比192.168.1.0/24，全部前24位與192.168.1.0相同的都是這個網段的IP，因爲IP地址8位一分組，24位就是前三段，也就是192.168.1.x。符合規範的這段連續的IP段就叫作一個子網。這種子網的表示方法叫作CIDR。
對於咱們來講經過192.168.1.0/24的方式來理解比較方便，可是對於計算機而言，有一種更快的方式來 判斷 當前IP是否屬於當前分組。 則是將32位地址與某個特殊值 進行與 運算， 若是運算結果 與 192.168.1.0/24 和特殊值進行與運算的結果一致， 則表示屬於當前子網。
對於192.168.1.0/24 而言， 這個特殊值就是 後八位均爲0的數值， 即 255.255.255.0與192.168.1.109進行與運算結果與 192.168.1.0結果一致， 這個255.255.255.0就被稱做是子網掩碼。
正是在子網中，層層遞進，最終才能將數據送到咱們的目的地。
路由器工做原理
路由器由這樣幾個部分構成：
輸入端口：這部分負責輸入鏈路與路由器之間的物理鏈路，同時也要負責與遠端輸入鏈路的交互功能， 同時還須要在這裏完成分組查找， 即經過輸入信息，查詢究竟應該發送到哪個輸出端口，這裏的端口指的是物理端口。 而另外必需要作的事情是， 檢查分組版本號， 檢驗和， 壽命， 同時更新後兩個屬性。 更新用於網絡管理的計數器。
交換結構：將路由器的輸入端口， 輸出端口相鏈接。 完成數據的轉發工做。
輸出端口： 主要有存儲， 發送。 存儲從交換結構轉發來的分組，按順序發送到鏈路層。
路由選擇處理器：執行路由選擇協議， 幫助輸入端口查詢到應該交由哪個輸出端口處理。同時也須要維護路由表，以及網絡管理功能。
在這裏並不窮究細節到底是怎樣的， 僅在功能上來講， 輸入端口， 交換結構， 輸出端口三者之間， 有從輸入鏈路流入輸入端口的數據Rin， 數據通過交換結構進入輸出端口Rc， 經過輸出端口到達輸出鏈路Ro，三者之間的處理速度須要有一個均衡， 當Rin的速度過快， Rc或Ro的速度過慢，都會引發擁塞，數據沒法被及時且恰當的處理，都會在持續時間內不斷累積，最終使得 數據超出緩存， 致使被丟棄。 丟包產生的源頭也正是在這裏。
地址分配
已經大體知道數據到底是以怎樣的方式在網絡中進行流通的。那麼一臺主機究竟如何獲取它自身的IP地址？進而完成數據發送的第一步。
先來看一個組織究竟如何獲取到屬於它的IP地址，它會首先從它的上層ISP中已經擁有的大塊IP地址中獲取到其中的一部分IP地址。
對於一個組織而言， 如上層ISP已經被劃分了一個地址範圍 111.111.16.0/20， 它可能會將本身的IP地址範圍進行八等份， 它的可支配範圍只在後12位，可支配範圍就在 111.111.16.0 ~ 111.111.30.255之間，由於此時可支配的最大IP是 0110 1111 0110 1111 0001 1111 1111 1111。 經過這種方式， 這個組織就可以拿到該屬於本身的IP地址。
層層向上，最頂級的ISP依然要獲取到屬於本身的IP地址， 能夠由 因特網名字和編號分配機構進行直接分配。
DHCP
而當組織獲取到自身的IP地址範圍以後，咱們固然能夠經過手動的方式爲每一臺主機分配相應的IP地址，也就不得不在有新的主機離開加入的時候更改其IP地址。但幸運的是， 咱們有更簡單的方式分配IP地址。
動態主機設置協議（Dynamic Host Configuration Protocol，DHCP）是一個局域網的網絡協議，使用UDP協議工做，主要有兩個用途：用於內部網或網絡服務供應商自動分配IP地址；給用戶用於內部網管理員做爲對全部計算機做中央管理的手段。
DHCP分配IP的方式有這樣幾種：
自動分配方式（Automatic Allocation），DHCP服務器爲主機指定一個永久性的IP地址，一旦DHCP客戶端第一次成功從DHCP服務器端租用到IP地址後，就能夠永久性的使用該地址。
動態分配方式（Dynamic Allocation），DHCP服務器給主機指定一個具備時間限制的IP地址，時間到期或主機明確表示放棄該地址時，該地址能夠被其餘主機使用。
手工分配方式（Manual Allocation），客戶端的IP地址是由網絡管理員指定的，DHCP服務器只是將指定的IP地址告訴客戶端主機。
在家庭網絡日常使用路由器的時候， 正是經過動態分配的方式，
三種地址分配方式中，只有動態分配能夠重複使用客戶端再也不須要的地址。
特殊的IP
在下一步以前，有這樣兩個特殊的IP地址。
255.255.255.255 廣播地址，即目的IP是這個地址的消息會被全部主機接收到，而其傳播範圍很是有限，到了廣播域的邊界（網關）會自動終結。 至於網關是什麼，稍後再說。
0.0.0.0 表示的就是未知地址， 當主機剛剛開機，尚未加入網絡時，所用的就是這個地址。
DHCP地址分配
DHCP爲主機分配地址經過如下幾個步驟：
DHCP服務器發現（DHCP discover）：當主機須要加入一個網絡時首先經過UDP的方式在端口67發送DHCP發現報文， 經過廣播的方式發送出去， 此時源IP爲0.0.0.0 目的Ip爲 255.255.255.255， 鏈路層將該數據報廣播到全部與該子網相鏈接的子網。
DHCP服務器提供（DHCP Offer）： 在響應時，依然採起廣播的方式。 但在這裏又有所爭議，我的理解偏向於，當客戶請求時，已經指定了究竟應該選擇廣播仍是單播的方式。 因爲有這樣一種狀況存在， 當客戶請求時已經攜帶了本身須要的IP地址，DHCP服務器發現這個IP地址在本身的鏈接池內，且沒有被佔用，就會將IP分配給當前主機。 而當響應時， 主要根據Chaddr：客戶端的mac地址 進行識別。 DHCP的詳細數據格式就再也不說明。 而若是有多個DHCP服務器進行響應， 能夠擇優選取。
DHCP請求（DHCP Request）：客戶端從一個或多個DHCP服務器中選擇一個，並向所選擇的服務器提供 DHCP請求報文，回顯配置參數。
DHCP ACK：DHCP服務器向客戶發送ACK，對客戶端的請求進行響應， 證明其所請求的參數。
NAT
如今咱們經過種種方式拿到了本身想要的IP地址，如今該回頭看以前提到的問題了， 全世界只有那麼多的IP地址，每人一個根本不夠分配的。
同時咱們用IpConfig命令會意識到， IP地址老是 192.168.0.xxx， 不管咱們在哪一個辦公室辦公大都如此。
是的，答案是局域網。
經過將一部分主機限制在局域網內， 對外界而言， 這一批主機具備統一的IP， 這並不稀奇， 咱們將數據發送到統一的路由器中， 由它向外發送。
路由器不難識別數據到底是誰發送出去的， 可是問題來了， 數臺主機統一發送數據， 不一樣的服務器也會進行響應， 那麼究竟該怎樣識別響應回來的數據到底是發送給誰的？
答案是端口。咱們知道， 不管是UDP， 仍是TCP都須要肯定發送方與接收雙方的端口是什麼， 當局域網內的數據發送到路由器時， 此時保存一個映射表。即：
192.168.0.100 6666 -> 111.111.111.111 8888
192.168.0.101 7777 -> 111.111.111.111 7777
正是經過這樣的方式， 完成了相關的轉換過程。 而身處於局域網中的IP地址 是經過： 路由器經過ISP DHCP獲取其地址， 同時路由器自身也擁有DHCP用於向內部分發地址。
而上面的映射表則被稱爲： NAT轉換表。
咱們會注意到的地方是， 這是將IP層面所該處理的 問題， 轉嫁到了應用層的相關端口去進行處理， 雖然以爲不合理， 但NAT已是目前而言不可或缺的版塊。
內網穿透簡述
既然理解的上面所說的核心部分， 也就不難理解另外一個概念， 內網穿透。 而這裏的原理可能並不許確，大都是我的理解。等之後學會了 wireshark相關再來看一下這個問題。
當咱們使用內網穿透工具時， 大都會精確到某一個端口， 告知對方， 咱們本身的端口是什麼， 須要訪問的端口是什麼， 由局域網內部的本機發起請求，經過這種方式就在咱們與公網之間的IP + 端口創建起了有效連接，當有外界對 公網的IP：端口發起請求時， 則會經過他間接地與 自身創建起相應連接。
因特網控制報文協議
因特網的網絡層具備三個主要組件，一是IP協議，二是路由選擇協議， 三是 因特網控制報文協議（ICMP）。
ICMP是在主機與路由器溝通彼此的網絡信息時使用，而其最經典的用途，是用在差錯報告。
ICMP一般被認爲是IP的一部分，但從體系上來講是它是位於IP之上的，由於ICMP的報文是承載在IP的分組裏面的， 做爲數據的一部分而呈現的。
所以對於網絡層而言，區別數據到底是否是ICMP報文的方式是經過， IP數據報的協議類型字段，一如區別 TCP與UDP同樣。 當主機收到指明協議類型爲ICMP的報文時， 會將數據分解出來給ICMP處理， 一如 分解出來 TCP 的數據部分 給TCP處理同樣。
ICMP報文有一個類型字段 和 編碼字段， 同時包含 引發該ICMP首次生成的IP數據報首部 以及前8字節， 以肯定到底是由於什麼引發的。
ICMP數據類型
ICMP類型 編碼 描述 0 0 顯示回答（對ping的回答） 3 0 目的網絡不可達 3 1 目的主機不可達 3 2 目的協議不可達 3 3 目的端口不可達 3 6 目的網絡未知 3 7 目的主機未知 4 0 源抑制 8 0 回顯請求 9 0 路由器通告 10 0 路由器發現 11 0 TTL過時 12 0 IP首部損壞
而ping 程序就是發送一個 8 類型 編碼0的數據到目的主機， 目的主機返回 類型0 編碼 0的數據作以響應。
而能夠看路由跟蹤的小功能也是借用了相關的東西來實現的， 在 windows是：
tracert ip/域名 //響應結果 C:\Users\admin>tracert www.baidu.com 經過最多 30 個躍點跟蹤 到 www.a.shifen.com [183.232.231.172] 的路由: 1 10 ms 7 ms 8 ms 10.61.4.1 2 9 ms 5 ms 12 ms 10.61.0.1 3 15 ms 11 ms 18 ms 111.21.43.117 4 7 ms 8 ms 6 ms 120.192.202.253 5 7 ms * * 120.192.202.5 6 15 ms 9 ms 8 ms 221.183.47.149 7 35 ms 30 ms 30 ms 221.183.40.221 8 * * * 請求超時。 9 34 ms 34 ms 33 ms 120.241.49.206 10 * * * 請求超時。 11 40 ms 39 ms 34 ms 183.232.231.172 跟蹤完成。
源主機會向目的主機發送一系列端口不可達的數據報， 而初始的TTL設爲 1 2 3 4 ...
每當到達一臺主機， 因爲其TTL過時， 則會由相應的路由器向源主機發送 ICMP協議， 類型爲11， 編碼爲0， 並會附帶上本身的一部分信息。
而當到達真正的主機以後， 因爲端口不可達， 則會響應類型， 編碼均爲3的ICMP報文， 此時， 中止發送數據報。
至於更多的版塊， IPV6 等其餘暫時就忽略跳過。
路由選擇
雖然路由選擇纔是網絡協議的難點所在，也是其最精彩的部分之一， 但在這裏， 我只打算簡要描述， 而後跳過。畢竟瞭解是關鍵的， 可是掌握路由算法對我而言，意義卻並非顯得有那麼重要。
但仍然有幾點關鍵的地方須要作出一點了解， 在整個網絡中的路由器茫茫多， 有這樣幾種選擇能夠完善， 定義 路由器轉發表。
靜態的方式： 經過管理員手動配置路由器轉發表，依然能夠完成相應的功能。
動態方式又有這樣兩種：
一是在路由器中保存有整個網絡中每個節點的相關信息， 以及從當前到對應節點的開銷，經過算法爲每一臺路由器都計算出到每個節點最優路線。
二是從當前路由節點出發，計算出到周圍相關節點的最優路線， 並將本身的相關信息， 通知給其餘相連節點。層層遞進，每當有最優路線被更新時，就會向周圍發送相關信息， 你們不斷更新迭代，直到趨於穩定。
第二種描述比較抽象， 舉例來講， 是這樣的一個過程：
對於路由器A，知道本身能夠到達路由器 A1 A2 A3這幾個網絡節點， 而且有相關開銷， 就會有以下信息。
g(x, y) = n; 其中x，y各表明一個節點， 而n是從 x 到 y的開銷。 須要注意的一點是 x -> y, y -> x二者之間並不等價。 有 g(A,A1) = 2; g(A, A2) = 3; g(A, A3) = 2;
對於節點A會將相關信息發送給相鄰節點如 B， A1， A2， A3
假設B並不存在其餘路徑能夠到 A1， A2， A3 則會更新本身的轉發表爲 g(B, A) = 1; g(B, A1) = 2 + 1; g(B, A2) = 3 + 1; g(B, A3) = 2 + 1;
再度將信息發送給相鄰節點， 經過這種方式就可以不斷更新完善， 假設未來在 B與A2之間創建了直連， 會更新信息爲 g(B, A2) = 1;
當A收到對應信息時， 它會發現經過B到達A2會比當前路線更快， 則更新本身的 g(A, A2) = 2;
須要注意到這裏的開銷並不必定非得是指跳過， 通過多少個路由器， 可能網絡擁塞， 鏈路速率等等都在考慮範圍內。
在其中涉及到路由選擇算法的坑， 暫時忽略無論。 可是有關於路由轉發表所會必然帶來的弊端就不得不提：
當規模逐漸增大， 不管經過哪一種方式， 爲數億臺路由器更新並維護轉發表無疑是一件並不那麼現實的事情。
因爲全局採起了相同的算法， 局部地區想要自治處理，個性化處理，也就是一件比較難的事情， 好比對某一部分路徑封鎖，不容許從這裏經過。 因爲採起了全局方式， 並不支持自由配置。
解決這個問題的方式，是將路由器的架構加入層次化處理。
路由自治系統（Autonomous System AS）
將一批路由器組成一個集合， 叫作AS， 在內外能夠採起不一樣的路由選擇算法，在一個AS內部， 相互擁有彼此的信息， 能夠實現轉發表配置， 而在兩個AS之間也須要進行相互的溝通。 因此在AS內就須要一臺或幾臺路由器來作這個工做， 這些路由器就被稱爲網關路由器。
一個AS所在的範圍就是一個子網的範圍， 網絡中的轉發表也正是用 CIDR的方式配置的，也即：
A.B.C.D/n : xxx;
一樣的， 跳過了AS內的 RIP， OSPF 以及路由器間的 BGP4 路由選擇協議。
問題是，爲何須要在AS內與AS間採起兩套不一樣的路由選擇協議呢？
策略 在AS之間策略問題起到了主導做用，一個給定的AS產生的流量不能穿過另外一個AS是一件很重要的事情，而在AS內部， 是被統一管理的， 傳輸性能反卻是最大的關注點。
在以前所提到的規模問題， 當規模太大時， 可以順利切分， 而且依然運做良好。
性能， AS間路由選擇是面向策略的， 所以性能的關注度反卻是最低的。而這也是 AS內路由選擇協議的優點所在。
廣播路由選擇
參考：【計算機網絡】廣播和多播
主機對信道傳過來的幀作這樣的處理：
首先，網卡查看由信道傳送過來的幀，肯定是否接收該幀，若接收後就將它傳往設備驅動程序。一般網卡僅接收那些目的地址爲網卡物理地址或廣播地址的幀。另外，多數接口均被設爲混雜模式，這種模式能接收每一個幀的一個複製。
目前，大多數的網卡通過配置都能接收目的地址爲多播地址或某些子網多播地址的幀。對於以太網，當地址中以最高字節的最低位設置爲1時表示該地址是一個多播地址，用十六進制表示爲01:00:00:00:00:00(以太網廣播地址 ff:ff:ff:ff:ff:ff可看做是以太網多播地址的特例）。
若是網卡收到一個幀，這個幀將被傳送給設備驅動程序（若是幀檢驗和錯誤，網卡就丟棄該幀）。設備驅動程序將進行另外的幀過濾。首先，幀類型中必須制定要用的協議（IP、ARP等等）。其次，進行多播過濾來檢測該主機是否屬於多播地址說明的多播組）。
設備驅動程序隨後將該數據幀傳送給下一層，好比，當幀類型指定爲IP數據報時，就傳往IP層。IP根據IP地址中的源地址和目的地址進行更多的過濾。若是正常，就將數據報傳送給下一層（如TCP或UDP）。
每次UDP收到由IP傳來的數據報，就根據目的端口號，還有源端口號進行數據報過濾。若是當前沒有進程使用該目的端口號，就丟棄該數據報併產生一個ICMP不可達報文（TCP根據它的端口號作類似的過濾）.若是UDP數據報存在檢驗和錯誤，將被丟棄。
使用廣播的問題在於它增長了對廣播數據不感興趣主機的處理負荷。拿一個使用UDP廣播報文應用做爲例子。若是網內有50個主機，但僅僅有20個參與該應用，每次這20個主機中的一個發送UDP廣播數據時，其他30個主機不得不處理這些廣播數據報。一直到UDP層，收到的UDP廣播數據報纔會被丟棄。這30個主機丟棄UDP廣播數據報是由於這些主機沒有使用這個目的端口。
多播的出現減小了對應用不感興趣主機的處理負荷。使用多播，主機可加入一個或多個多播組。這樣，網卡將獲悉該主機屬於哪一個多播組，而後僅接收主機躲在多播組的多播幀。
廣播和多播路由協議
廣播類型
廣播有四種類型：受限的廣播，指向網絡的廣播，指向子網的廣播，指向全部子網的廣播。
受限的廣播
受限的廣播地址是255.255.255.255。該地址用於主機配置過程當中IP數據報的目的地址，此時，主機可能還不知道它所在的網絡的網絡掩碼，甚至連它的IP地址也不知道。
在任何狀況下，路由器都不轉發目的地址爲受限的廣播地址的數據報，這樣的數據僅僅出如今本地網絡中。這就是爲何稱爲受限的網絡地址。這種廣播類型接收對象爲局域網中包括髮送主機在內的全部主機。
指向網絡的廣播
指向網絡的廣播地址是主機號全1的地址。A類網絡廣播地址爲netid.255.255.255，其中netid爲A類網絡的網絡號。
一個路由器必須轉發指向網絡的廣播，但它也必須有一個不進行轉發的選擇。
指向子網的廣播
指向子網的廣播地址爲主機號全1且有特定子網號的地址。做爲子網直接廣播地址的IP地址須要瞭解子網的掩碼。例如，若是路由器接到發往128.1.2.255的數據報，當B類網絡128.1的子網掩碼爲255.255.255.0時，該地址就是指向子網的廣播地址；但若是該子網的掩碼爲255.255.254.0,該地址就不是指向子網的廣播地址。
指向全部子網的廣播
指向全部子網的廣播也須要了解目的網絡的子網掩碼，以便與指向網絡的廣播地址區分開。指向全部子網的廣播地址的子網號及主機號爲全1.例如，若是目的子網掩碼爲255.255.255.0.那麼IP地址128.1.255.255是一個指向全部子網的廣播地址。然而，若是網絡沒有劃分子網，這就是一個指向網絡的廣播。
而在上面的介紹中有幾個名字沒有接觸到，在這裏補充下：
簡單來講， 咱們已經知道了子網掩碼是如何根據子網的 前綴生成的， 而這個所謂前綴， 術語上來講就被稱做是網絡號， 也即 111.111.111.0/24 中的前24位爲1後8位爲0的二進制數。
固然網絡號也能夠由 IP地址和子網掩碼作與運算生成， 畢竟子網掩碼最初的目的也正是這樣。
當兩個網絡具備相同的網絡號就被稱爲 在同一個子網中。 而在32位地址中， 前8位相同叫作A類網， 前十六位相同就叫B類網， 前24位相同被稱做C類網。
而主機地址就是 111.111.111.0/24 的後八位可變地址。 那麼廣播地址呢？
就是將網絡地址中的主機地址 均置爲1， 便可。
這樣就可以多廣播類型有個較爲清晰的瞭解了。
廣播路由協議
咱們已經決定要發廣播了， 該怎麼發送呢？
最簡單的方式就是N次單播， 就是將源數據複製n份， 向N個地址發送， 固然， 問題很明顯，同一份數據要在同一個節點通過許屢次， 致使了沒必要要的開銷。
固然， 咱們有一種更優的處理策略， 則是在每一個路由節點對數據進行復制， 然後發送出去。但N次單播的前提條件是， 咱們將每次發送都視做一次單播， 須要知道源IP及每次單播的目的IP，可是這些信息又怎樣存儲呢？須要相關的協議進行配置，這使得咱們的協議變得更復雜。
另外就是 在路由選擇協議中，單播路由的鏈路狀態也正是由廣播所發送的， 所以採起這種N次單播的方式可行性並不高。
無控制洪泛
這種方式是須要每一個節點向其周圍節點發送信息副本， 這樣網絡中的全部主機都可以收到消息。可是帶來的缺點是， 若是在網絡拓撲中存在環路， 則會使得數據無休止的發送下去。 同時一個節點至少會收到N次數據，N等於與其直接相連的節點數。
受控洪泛
有幾種方式， 一是序號控制洪泛，對發出的每個副本都留存有其序號，當收到消息時，與當前收到轉發的序號列表進行比對， 已發送則丟棄便可。
第二種方式叫反向路徑轉發
思路至關簡單， 當一個節點收到數據時， 僅當發送數據的源節點 在 從當前節點到源節點的最短單播路徑上時，才進行發送。 而在收到分組以後， 會向全部附近節點 除了 發送節點給他的那個節點 發送數據。這麼讀起來可能比較拗口 難以理解。 舉例說明：
數據由A節點發送出來，發往B節點， C節點， 此時A節點在 B節點到A節點的最短單播路徑內， 所以B接收來自A節點的數據， 同時會向C發送數據， 當C收到來自B的數據， 由於數據源爲A， C發現它本身到A的最短單播路徑並不須要通過B， 所以拒絕接收來自B的數據。
其餘節點也是同理， 而如何知道最短單播路徑呢？ 就是在以前提到過的
在節點 A2 -> A1 -> A 在A的轉發表中有， 到達A2的最短單播路徑 所須要通過的下一個節點是 A1 而不須要關心更多。
第三種方式爲生成樹方式：
上述兩種方式依然有不可避免的問題， 就是依然須要重複發送數據， 當數據到達以後，再由接收節點進行判斷是否留存， 轉發。 但依然避免不了須要解析到IP首部， 接收數據的問題。
在發送以前子網中的全部節點都已經根據算法計算出來了須要在當前生成樹內， 本身的下一個子節點是誰， 生成樹的特色是到達每一個點都是連同的， 且不包含環， 這樣就可使得數據不會被無效發送。
多播
而多播有所不一樣， 它帶來的問題會更多， 但也有這樣幾個優點， 咱們不難發現有這樣兩個問題，存在於廣播中， 一是全部的子節點都會無條件的收到相應的消息， 當廣播通信持續多久，就要被這樣一直騷擾下去。 另外一點是 廣播都侷限在一個子網內部發送， 固然， 廣播必然不可以無限制的發送， 不然在整個互聯網世界都會收到對應的廣播消息， 是一件多可怕的事情。 可是對於同時須要多個接收點， 流行於今天的直播， 視頻會議， 等等其餘，須要被多人共享的功能 又該怎樣實現呢？
可是廣播中咱們並不須要存儲目的地址， 而在多播中， 就須要存儲這部分數據了。在因特網體系中，多播數據地址用間接地址來編址。 也就是用一個標識符來標識一組接收方，且該組使用這個單一標識符。
而與多播相關的地址爲 D類地址， D類地址比較特別， 第一個字節以「1110」開始， 它的範圍從224.0.0.0到239.255.255.255，或，等同的，在224.0.0.0/4。在IPv6，多播地址都有前綴ff00::/8。可是注意，224.0.0.0被保留，不能賦給任何多播組。 與多播相關的協議是IGMP。
多播是第一個字節的最低位爲1的全部地址，例如01-12-0f-00-00-02。廣播地址是全1的32位地址，也屬於多播地址。可是廣播又是多播中的特例。