前言：

1.網絡原理的理解

2.應用層

2.1自定義協議的約定

2.1.1確定要傳輸的信息

2.1.2確定數據的格式

3.傳輸層

3.1UDP

3.1.1UDP報文格式

3.2TCP

3.2.1確認應答

3.2.2超時重傳

3.2.3連接管理

3.2.3.1三次握手

3.2.3.2四次揮手

3.2.4滑動窗口

3.2.5流量控制

3.2.6擁塞控制

3.2.7延時應答

3.2.8捎帶應答

3.2.9面向字節流（粘包問題）

3.2.10異常處理（心跳包）

3.3TCP與UDP的差別

4.網絡層

4.1IP協議

4.1.1地址管理

4.1.1.1動態分配IP地址

4.1.1.2NAT機制

4.1.1.3IPv6

4.1.2路由選擇

4.2IP地址的組成

4.2.1IP地址分類（ABCDE）

4.2.2子網掩碼

4.3特殊的IP地址

5.數據鏈路層/物理層

5.1以太網

結束語：

前言：

在上一節中小編主要是與大家講述了有關于網絡編程方面的知識，如果沒有查看的同學請點擊這里?http://t.csdn.cn/zZ5wt?，接下來小編繼續帶著大家來看網絡編程中的一些更深層次的一些知識，大家快快來和小編一起學起來吧！

1.網絡原理的理解

我們之前學習了網絡初識，這里面我們對網絡有了大體的概念和認識，接下里學習了網絡編程，在這里面主要是給大家介紹了UDP和TCP，讓我們真正通過代碼來感受到了網絡通信程序，這里再給大家來介紹網絡原理，讓我們來進一步的了解網絡的工作過程。下面我們將通過對網絡協議分的這幾層來分別給大家一一介紹，從應用層->傳輸層->網絡層->數據鏈路層->物理層。這里主要的重點是應用層和傳輸層，其余的大家簡單了解即可。

2.應用層

這里的應用層是簡單給大家先介紹一下，在后期小編還會給大家出有關于HTTP的內容，這這塊小編在給大家詳細介紹一番。應用層和代碼是直接相關的一層，它決定了數據要傳輸什么，拿到數據之后又該怎么使用。在應用層這里雖然存在一些現有的協議（HTTP），但是也有很多情況是需要程序猿來自定制協議的。關于自定制協議就是說要約定好應用層數據報，和數據格式，此時就是在自定義協議。那么我們具體的該如何進行約定呢？詳細請看下面。

2.1自定義協議的約定

2.1.1確定要傳輸的信息

首先你要想傳輸數據就得先確定好你要傳輸的數據都有哪些，這里是根據需求文檔走的，比如我現在要點一份外賣那么可能就需要下面的這些信息。

2.1.2確定數據的格式

那么當上面確定好了要發送的數據之后，就要規定一下要發送的數據應該是以那種格式來進行發送。在網絡上傳輸本質上都是0101的二進制字符串，此時我們需要把上述這些信息都整合成一個字符串。

這里有一個簡單的方案就是直接使用分隔符來進行組織，當然也不是一定要使用分隔符，這里還是可以使用其他的符號來進行分隔的，我們可以讓屬性和屬性之間使用\n來進行分隔。那么只要接收方按照這套格式來組織數據，接收方按照這套格式來解析數據，兩者只要可以對的上，這樣的格式就是可以的。

在實際開發中也有一些現成的格式可以直接使用，比如XML里面就是使用標簽的形式來進行組織的，再比如現在比較流行的格式JSON，他是使用{}來進行組織的。

這些我們會在后面一一給大家講解。

3.傳輸層

3.1UDP

3.1.1UDP報文格式

如下圖所示：

端口

下面來區分一下這幾個概念：源IP、源端口、目的IP、目的端口。

這就幾個就像是西游記里唐僧經常說的一句話：“貧僧自東土大唐而來，到西天拜佛取經”。這幾個對應關系如下圖所示：

在UDP報頭中就會包含源端口，表明自己是從哪里來的數據，同時包含目的端口號，指明這些數據要到哪里去。

每個端口號在UDP中都占有兩個字節，它的取值范圍其實是0-65535。其中小于1024的稱之為“知名端口號”，是給一些名氣比較大的服務器預留的端口，這部分端口在咱們寫代碼的過程中不應該使用。就像是坐飛機的時候會分為頭等艙和經濟艙一樣的道理，但是這里注意0這個端口雖然是合法的端口，但是實際上是沒有人使用的。

報文長度

他也是占2個字節的，范圍是0-65535也就是64KB。所以一個UDP報文的最大長度就是64KB，這里我們可以看到64KB放在現在是一個很小的數字了，所以大家在使用UDP編程的時候一定要注意UDP的數據報不能夠太長，否則的話就會出現問題。

校驗和

在網絡的傳輸中并不是那么的穩定，可能會出現各種各樣的幺蛾子。通過網線傳輸的時候是電信號，電信號使用的是高低電頻，用0 1?表示。但是如果外部環境干擾，比如強磁場之類的就可能會導致高電頻變成了低電頻，低電頻變成了高電頻，這就會導致傳輸的數據出現錯誤，那么此時就需要一個判定，判斷一下傳輸的數據是不是正確的，這就是校驗和存在的意義，它就是用來判定當前傳輸的數據是否出錯。

舉個例子：

比如現在父母讓我們下樓買菜，要買西紅柿、雞蛋、茄子、芹菜。一共買四樣菜，這里的買四樣菜就是一種校驗和，我們買完之后如果是四樣，那么就說明這里是有可能是對的，但是如果是三樣或者是五樣菜，那么一定是買錯了，注意這里小編在說買四樣菜的時候為什么會說是可能是對的，因為數量首先是對的，但是可能買回來的菜的種類就不一樣了呀！?

所以說如果校驗和不對，此時你的數據一定不對，但是校驗和對，但是數據也是有可能是錯的。

所以為了讓校驗和能夠辨識率更高一些，計算的時候通常會以數據內容作為參數來進行計算，數據內容發生變化，校驗和也就會發生變化。?

3.2TCP

在上一節中小編給大家大體介紹了一下TCP，它是有連接、可靠傳輸、面向字節流、全雙工的。TCP對數據傳輸提供的管控機制，主要體現在兩個方面：安全和效率，這些機制和多線程的設計原則類似：保證數據傳輸安全的前提下，盡可能的提高傳輸效率。那么這里的可靠傳輸就是TCP存在的初心，也是最核心的機制。那么這里TCP是如何實現的可靠傳輸的呢？下面給大家介紹可靠傳輸的十個機制：確認應答、超時重傳、連接管理、滑動窗口、流量控制、擁塞控制、延時應答、捎帶應答、面向字節流、異常處理。下面就來展開一一給大家敘述一下這十個機制。

3.2.1確認應答

確認應答是實現可靠傳輸最核心的機制。比如下面的傳輸機制。

?當A主機給B主機發送了數據1000，然后此時B主機就給A主機返回一個應答報文，并告訴下一個要傳輸的數據是從1001開始的，此時A主機就會繼續發送1001-2000的數據，B主機又會返回一個應答，并告訴下一個數據的開始時2001。

那么在網絡上經常會出現后發先至的情況，比如A主機發送完0-1000數據之后，在發送1001-2000，此時B主機先返回了2001，再返回1001，此時就會出現問題，那么為了解決上述的問題，就需要針對消息進行編號，給發送消息分配一個“序號”，同時應答報文，給出“確認序號”。

這里確認應答發送的叫做ACK，每一個ACK都會帶有確認列號，意思是告訴發送者，我已經收到了哪些數據，下一次你從哪里開始發送。

注意：
確認序號的規則：不是說發送方的序號是啥，確認序號就是啥，而是取的是發送方發過來的所有數據最后一個字節的下一個字節的序號。比如確認序號1001的含義：1.表示小于1001的數據我都已經收到了?。2.我接下來想向發送方索要從1001開始的數據。

3.2.2超時重傳

在網絡中會經常出現一種現象叫“丟包”。

情況一：數據直接丟了，接收方沒有收到，自然就不會發送ACK。

主機A發送數據給B之后，可能因為網絡擁堵等原因，數據無法到達主機B。
如果主機A在特定時間間隔內沒有收到B發來的確認應答，就會重發。

情況二：接收方收到數據了，返回的ACK丟了。

主機A未收到B發來的確認應答，也可能是因為ACK丟失了。

對于上述兩種丟包情況，發送方式判斷不了的，所以只能重傳。

那么什么會出現丟包問題呢？

在A主機和B主機之間還存在著很多中間的路由器...每個設備都在承擔著很多的轉發任務，每個設備的轉發能力都是有上限的，某個時刻，某個設備，上面的流量達到峰值，就可能會引起部分數據包被丟失。如果包丟了，接收方就收不到了，自然就不會返回ACK了，發送方就會遲遲收不到應答報文，發送方就視為剛才的數據包丟了，就會重新再發一遍。

發送方對于丟包的判斷是一定時間內沒有收到ACK。

注意：

對于上是的情況二，B就會收到重復的數據，那么這里也不用我們擔心，TCP這里會幫我們做好處理，他會在接收緩沖區中根據收到的數據的序號自動去重，這樣就保證了應用程序讀到的數據仍然只有一份。

解決丟包問題：

TCP針對于多個丟包的處理思路就是繼續超時重傳，但是每丟包一次，超時等待時間就會變長，（降低了重傳的頻率）。
如果多次重傳，都無法得到ACK，此時TCP就會嘗試重置連接（相當于嘗試重連）。
如果重置連接也失敗了，TCP就會關閉連接，放棄網絡通信了。?

3.2.3連接管理

TCP建立連接是通過三次握手，TCP斷開連接是通過四次揮手。那么下面我們就來具體看一下三次握手和四次揮手究竟是怎么一回事吧。

3.2.3.1三次握手

三次握手是TCP建立連接的一個過程。握手（handshake）是指通信雙方，進行一次網絡交互，相當于客戶端和服務器之間，通過三次交互，建立了連接關系。

首先來明確兩個概念：

SYN：稱為同步報文。意思就是一方要向另一方申請建立連接。
ACK：稱為應答報文。意思就是確認已經收到了另一方發送的申請了。

下面我們來給大家畫圖來演示一下整個握手的過程：

這里又有同學好奇了，為什么在上述中明明客戶端和服務器之間進行了四次交互，為什么要叫三次握手呢？因為這里的SYN和ACK是可以同時打包發送給客戶端的。如果是打包同時發送給客戶端的話就會變成三次交互，也就是三從握手了，如下圖所示：

TCP三次握手具體流程如下所示：

客戶端發送SYN包：客戶端向服務器發送一個SYN包，其中SYN標識為1，表示客戶端請求建立連接，并指定一個隨機的序列號x。
服務器發送SYN +?ACK包：服務器收到客戶端的SYN包之后，向客戶端發送一個SYN +?ACK包，其中SYN?和?ACK標識位均為1，表示服務器接收到了客戶端的請求，并同意建立連接。同時服務器也會指定一個隨機的序號y，并將確認號設置為x + 1。
客戶端發送ACK包：客戶端收到服務器的SYN +?ACK包后，向服務器發送一個ACK包，其中ACK標識位為1，表示客戶端確認收到了服務器的響應，并將確認號設置為y + 1。

那么這里在TCP的報頭結構中也有體現出來。如下圖所示：

上述的這幾個都是特殊的比特位，這幾個默認是0，如果設置為1，則表示特定的含義。

第二位也就是ACK如果是1，表示當前TCP數據報是一個應答報文。
第五位也就是SYN如果是1，表示當前TCP數據報是一個同步報文。?

了解完三次握手之后我們還得了解一下為什么要三次握手，它起到了啥效果達到了啥目的呢？

三次握手這個過程本質上是在投石問路，它驗證了客戶端和服務器之間各自發送能力和接收能力是否正常。?這就像是我們在通話的時候先會確認一下對方和自己的的信號是否正常一樣，

3.2.3.2四次揮手

上面是三次握手是客戶端與服務器之間建立連接，那么怎么斷開來連接呢？我們這里是采用四次揮手，具體的我們來看下面的圖所示：

四次揮手的具體流程如下所示：

客戶端發送FIN包：客戶端發送一個FIN包，其中FIN標識位為1，表示客戶端希望關閉連接。
服務器發送ACK包：服務器收到客戶端的FIN包后，向客戶端發送一個ACK包，其中ACK標識位為1，表示服務器已經收到了客戶端的請求，并將確認序號設置為客戶端發送的序列號+1。
服務器發送FIN包：服務器在發送完ACK包之后，也會發送一個FIN包，其中FIN標識位為1，表示服務器也希望關閉連接。
客戶端發送ACK包：客戶端收到服務器的FIN包后，向服務器發送一個ACK包，其中ACK標識位為1，表示客戶端已經收到服務器的請求，并將確認號設置為服務器發送的序列號+1。

這里小編給大家舉一個例子來方便大家的理解。假如客戶端和服務器是男女朋友的關系，此時他倆現在想要分手，那么女生就對男生說咱兩分手吧（向另一方發送了FIN的請求），男生收到之后，給女生說我知道了（向另一方發送一個ACK包表示已經收到了請求），那么接下來男生說那就分手吧（再向另一方發送了FIN包，表示斷開連接），此時女生收到這條分手消息之后，發個消息表示已經收到了（向另一方發送ACK包，表示已經接收到了）。

那么這里有一個問題就是上面在三次握手的時候中間的ACK和SYN可以合并一起發送，那么這里是不是也可以打包一起將FIN和ACK一起發送呢？會不會變成“三次揮手”呢？

答案是：否，首先這里需要明確一點三次握手中SYN和ACK是同一時機觸發的，都是有內核來完成的，而四次揮手的ACK和FIN則是不同時機觸發的，ACK內核完成的，會在收到FIN的時候第一時間返回，而FIN則是應用程序代碼控制的，在調用到socket的close方法的時候才會觸發FIN。所以是不可以合并的。

四次揮手的主要作用：

確保所有的數據都被傳輸完成：在關閉連接前，雙方都可能還有數據需要傳輸，因此需要四次揮手來確保所有的數據都被傳輸完成。
避免服務器收到來自已關閉的連接的數據：在關閉連接后，服務器可能會收到來自已關閉的連接的數據，因此需要等待一段時間，確保客戶端收到了服務器的FIN包并確認關閉連接，才能關閉連接。
確保雙方都能正確地關閉連接：四次揮手的過程中，客戶端和服務器都需要發送FIN包和ACK包，以確保雙方都能正確的關閉連接，避免連接一方關閉而另一方任然處于連接的狀態。

因此，TCP協議需要進行四次揮手，以確保雙方都能正確的關閉連接，并避免數據的丟失和混淆。?

3.2.4滑動窗口

TCP要保證的不僅僅是可靠性，還要保證效率，但是要提升效率往往意味著損失效率。如下所示的發送方式就是一種效率極其低的發送方式：

此時主機A這邊就花了大量的時間在等待ACK，就相當于是發送快遞，總不能是發送一個包裹，然后服務器等待客戶端收到包裹然后再給下一個客戶發送包裹吧，所以想要提高效率就得批量發送數據了，一次發送多條數據，一次等待多個ACK，如下所示：

上述就是一次批量發送了4條數據，發送完之后，統一等待ACK，每次收到一個ACK就立即發送下一條，上述批量傳輸數據的過程就稱為“滑動窗口”。?

批量并不是無限發送，而是發送到一定的程度，就等待ACK，不等待直接發送數據量是有上限的。而且是回來一個ACK就立即發下一條，相當于總的要等批量的數據是一致的。此時就把等待數據的數量就稱為“窗口大小”。示意圖如下所示：

所以此時看到的效果就像是窗口還會那么大，但是往后挪動了一個格子，如果收到的ACK非常快，此時這個窗口就在快速的往后滑動。

那么如果在發送的過程中，如果出現丟包咋辦呢？那么此時就是要“可靠性第一，效率第二”。出現的情況可能有以下幾種：

情況一：數據包已經到達，ACK被丟了。

在上述情況中相當于是一半的ACK都已經丟了，相當于是丟包率是非常的高，但是注意：這種情況下對于可靠性傳輸是沒有任何影響的，因為確認序號的含義表示該序號之前的數據都已經收到了，后一個ACK，能夠涵蓋前一個ACK的意思。?

假設現在是1001-2000這個數據丟失了，那么接收方就會繼續索要1001，此時不會說是因為收到的是2001-3000就會返回3001，那么接下來幾次的數據ACK確認序號都會是1001，也就是B在反復的向A索要1001這個數據，A這邊收到之后，就知道事情不簡單，就知道1001可能是丟失了，此時A就會重傳1001-2000這個數據了。這就是重傳過程，也叫快速重傳。

3.2.5流量控制

流量控制也是保證可靠性的機制。上述的滑動窗口越大相當于批量發送的數據就會越多，整體的速度就會越快，但是真的是越快越好嗎？如果發送的太快，那么就會瞬間把接收方的緩沖區給打滿了，此時數據就會出現丟包，這種情況就得不償失了，還不如發送的慢一點。那么怎么才能慢下來呢？這里就可以通過流量來進行控制，本質上就是讓接收方來限制一下發送的速度，讓發送的慢一點甚至阻塞一下。

具體在ACK報文中攜帶了一個“窗口大小”這樣的字段。如下所示：

注意：上述的16位窗口大小只是建議發送的窗口大小，并不是在發送的時候就非要采納這個值，那么接收方這里會計算出一個窗口大小的值，?那么究竟是如何計算的呢？它采用了一個簡單粗暴的辦法就是直接拿接收緩沖區剩余的空間作為窗口大小。

如下圖所示：

發送窗口的大小 =?流量控制 +?擁塞控制。

下面我們就來給大家講解一下擁塞控制。

3.2.6擁塞控制

上述中講解了流量控制，滑動窗口的大小主要就時取決于流量控制和擁塞控制的。流量控制主要是衡量了接收方的處理能力，而擁塞控制主要是衡量了傳輸路徑的處理能力。

如下圖所示：

在傳輸過程中數據并不是直接就能夠從主機A傳輸到主機B的，而是通過中間若干個路由器和交換機等的傳輸，最終才能夠到達主機B，?所以很明顯，在傳輸的路徑上任何一個設備處理能力如果遇到了瓶頸都會對整體的傳輸速率產生明顯的影響。

而擁塞機制要做的事情就是要衡量中間結點的傳輸能力，要衡量中間路徑上有多少個結點，以及每個結點當前的情況。

那么這里是通過什么來衡量出來的呢？

其實是“實驗”，就是通過實驗的方式來找到一個合適的發送速率。開始的時候先按照一個小的速率來進行發送，如果發現沒有出現丟包的現象，就可以提高一下發送的速率了，如果出現丟包的情況，則立即再把速率調小。也就是讓其維持著一個動態平衡的狀態。

如下圖所示：

具體的過程如下所示：?

剛剛開始傳遞的時候會給一個非常小的窗口（比較小的初識速度），也就是慢開始。
然后如果發現沒有丟包現象就會以指數式進行增長，此時窗口的大小就會在短時間內達到一個比較大的值，快速接近當前網絡傳輸路徑的能力瓶頸。
當增長到一定程度，出現丟包現象了，此時就會認為當前窗口大小已經達到了當前路徑上的傳輸上限了。此時就立即把窗口大小調回到一個比較小的初識值，然后重復上述的過程，但是第二次進入到平緩上升的階段比第一次的要小一點。?

3.2.7延時應答

延時應答就是為了提高傳輸效率，TCP可靠性的核心就是確認應答機制，ACK是要發，但也不是立即就發，而是稍微等一會在發送，發送方如果不停的發送數據，此時接收方接收到數據之后應用程序也在不停的消耗緩沖區里面的資源。此時立即返回一個ACK，此時的ACK是帶有一個窗口大小N的，但是如果是稍等一會再發送ACK，此時ACK的窗口大小大概率會比N要大一些。因為在等待的這一小會里面應用程序從接收緩沖區里會消費掉一批數據了，那么就可以讓下一次傳過來的數據就再多一點了。

延時應答的效果就是通過這個延時讓接收方應用程序乘機多消費一點，此時反饋的窗口大小就會更大一丟丟，此時發送方發送速率也就可能會更快一點。

3.2.8捎帶應答

捎帶應答他是基于延時應答的一個機制，在客戶端中有很多種通信模型：

一問一答，這是客戶端和服務器之間通常使用的通信模型。
多問多答，多用于上傳大文件。
一問多答，多用于下載大文件。
多問多答，多用于游戲串流。

如下圖所示：

如上所示：ACK和SYN的時機本來是不同的，但是由于延時應答的存在，此時ACK就可能會等一會在發送回去，所以就很有可能和SYN合并成一個數據報一起發送回去了。此時合并成一個數據報要比兩個數據報效率要更高一些。所以這也就是之前我們將的四次揮手可能會變成三次揮手了，這就是捎帶應答起到的效果。?

3.2.9面向字節流（粘包問題）

在面向字節流里面有一個比較嚴重的問題就是粘包問題，那么什么是粘包問題呢？

如下圖所示：

那么此時站在B主機的角度就不知道要從哪里斷開了，是aaa和abbbb還是啥，上述中所謂的一句話就相當于是一個應用層數據報，當A給B連續發了多個應用層數據報之后，這些數據就會累積到B的接收緩沖區中，緊緊挨在一起，此時B的應用程序在讀取數據的時候，就難以區分從哪到哪是一個完整的應用層數據報了。就會很容易讀出半個包。

那么該如何避免粘包問題呢？歸根結底就是一句話，明確兩個包之間的邊界。

3.2.10異常處理（心跳包）

在異常關閉中有以下四種情況：

進程關閉/進程奔潰：進程沒了，socket是文件，隨之就會被關閉，雖然進程是沒了，但是連接還在，仍然可以繼續四次揮手。
主機關機（正常流程關機）：他會先殺死所有的用戶進程，也會觸發四次揮手，如果揮完那更好，如果沒有揮完，比如對方發來的FIN還沒有來得及接收呢還沒有來得及ACK就已經關機了，那么此時對方就會重傳FIN，在重傳幾次之后，發現都沒有響應就會嘗試創新建立連接，如果還不行，就會直接放棄連接。
主機掉電（直接拔掉電源）：此時就會瞬間關閉，來不及進行任何操作。如果對端是發送端：對端就會收不到ACK，就會繼續超時重傳，然后進行重置連接，最后不行就會釋放連接。如果對端是接收方：對端是沒有辦法知道的，你這邊是沒有發送數據還是沒有來得及發新的數據，還是直接沒了。所以此時TCP內置了心跳包，他是一個保活機制。心跳包是一個周期性的，如果心跳沒有了就相當于是掛了，雖然對方是接收方，但是對端會定期給發送一個心跳包（ping），此時就會返回一個（pong）,如果每次ping過去之后都有及時的pong，這個時候就說明當前對端的狀態良好，如果ping過去之后，沒有pong，就說明心跳沒有了，也就是可能已經掛了。
網線斷開：與上述的情況一致。

3.3TCP與UDP的差別

TCP（傳輸控制協議）和UDP（用戶數據報協議）都是傳輸層的重要協議，它們都是用來將數據從源主機發送到目標主機的，但它們存在以下幾點不同：

連接機制不同：TCP是面向連接的協議，需要在客戶端和服務器之間建立一個穩定的連接，然后再進行數據傳輸；而UDP是無連接的協議，數據報可以直接發送給目標主機，不需要建立連接。
數據傳輸方式不同：TCP采用可靠的數據傳輸方式，即在傳輸過程中使用序號、確認序號和重傳機制等控制手段來保證數據的可靠傳輸；而UDP采用不可靠傳輸數據的方式，數據報可能會丟失或重復，不提供數據可靠性保障。
數據傳輸效率不同：由于TCP需要進行連接、序號確認等額外的數據包傳輸，因此在數據傳輸效率方面相對于UDP要低一些。
數據大小限制不同：UDP對數據包的大小有限制，最大只能傳輸64KB的數據，而TCP的數據包大小沒有限制的。
應用場景不同：TCP適用于要求數據傳輸可靠性高的場景，如網頁瀏覽、文件下載、電子郵件等；而UDP適用于實時性要求較高的場景，如視頻會議、在線游戲等。

4.網絡層

4.1IP協議

4.1.1地址管理

每個網絡上的設備，都要能分配到一個地址，并要求是唯一的。這個我們可以想象成是我們的身份證號，每個人都有唯一的身份證號用來區別身份。

協議格式如下圖所示：

32位源IP地址本質上是一個32位的整數，通常會把32位的整數轉換成點分十進制的表示方式。用三個點分隔，把這個整數分成4個部分，每個部分一個字節，每個部分的取值范圍都是0-255。那么32位的整數最多能表示多少個不同的地址呢？他可以表示42億9千萬個。雖然這個數字很大，但是現在全時間有那么多臺機器那么多的手機等其他電子產品都要進行分配IP地址，這顯然是不夠的，那么如何解決上述的問題呢？我們采用了動態分配和NAT機制來進行分配，我們接著往下看。

4.1.1.1動態分配IP地址

所謂動態就是讓上網的設備才給分配，不上網就不給分配了，此時就可以剩下一大批的IP地址了，但是這顯然是一種不靠譜的解決方式，這個機制并沒有增加IP的數量，只能在一定程度上緩解，不能徹底解決問題。那么追要想解決問題還是得靠NAT機制。

4.1.1.2NAT機制

對于NAT機制來說他是將所有的IP地址分為兩大類：一個內網IP，一個是外網IP。

內網IP：就是以10.* 、 172.16.* - 172.31.* 、 192.168.*?以這些開頭的都是內網。內網IP是可以重復出現的，尤其是在不同的局域網中。
外網IP：就是剩下的IP都是外網IP，外網IP必須是唯一的。

注意：內網設備如果要訪問外網設備，就會給他分配一個外網IP。但是外網設備是無法直接訪問內網設備的。外網的IP是不可以重復的，但是內網的IP是可以重復的，但是在同一個局域網中是不可以重復的。（就比如一個學校中同一級的班級的班號是不可以重復的，但是每一個學生在同的班級中時，他們的學號就可以重復。但是在同一個班級中學號是不可以重復的。）

NAT背景下的通信：

外網設備—>外網設備：不需要任何NAT直接就可以通信。
內網設備—>其他內網設備：不允許。
外網設備—>內網設備：不允許。
內網設備—>外網設備：對應的內網設備的路由器，觸發NAT機制進行IP替換，此時就會給這個網絡數據報的源IP替換成路由器自己的IP。?

4.1.1.3IPv6

我們當前使用的大部分IP分配機制都是由動態分配+NAT來解決的。但是我們現在大部分使用的是IPv4他是傳統的IP協議，使用的是4個字節，32位來表示IP地址的。現在出來了IPV6，他是更新了一些IP協議，使用的是16個字節，128位來表示IP地址的。它比之前的IP地址多出來了很多很多。但是目前為止還是有很少的在使用IPV6主要是他與IPV4并不兼容，所以大部分都沒有進行升級。

4.1.2路由選擇

從A到B之間，具體路線是怎么走的，在互聯網中存在很多冗余的路線，那么A和B之間存在多條路線具體走哪一條，該怎么選擇呢？

在網絡中，網絡環境是十分復雜的，某一個路由器是無法把整個網絡環境都記錄下來的，路由器只能記錄周圍的情況，也就是只能知道它的鄰居都是誰，這個是由路由器中的一個路由表來進行記錄的，在實際的轉發中是漸進式的，類似于問路一樣的逐漸接近自己的目標。

4.2IP地址的組成

IP地址主要分為兩個部分，網絡號和主機號。

網絡號：標識網段，保證互相連接的兩個網段之間具有不同的標識。它是標識了一個局域網。
主機號：標識主機，同一網段內，主機之間具有相同的網絡號，但是必須有不同的主機號。它是標識了一個局域網內部的主機。

如下圖所示：

上述中的198.168.0?就是一個網絡號，以及198.168.1也是一個網絡號。

此時我們通過路由器就將兩個局域網給連接到一起了，此時這兩個局域網就稱為“相鄰”的局域網。這兩局域網的網絡號是不能重復的。那么對于上述的IP地址中是前三個字節是網絡號，但是一定是前三個字節就是網絡號嗎？那不一定。對于網絡號主機號的劃分，主要有兩種方式一種是IP地址分類（ABCDE），另一種是子網掩碼。那么接下來我們就來分別看下它兩是怎么進行劃分的。