帶你瞭解HTTP協議（二）

時間 2019-11-20

標籤瞭解 http 協議欄目 HTTP/TCP 简体版

原文原文鏈接

一樣的，本文篇幅也比較長，先來一張思惟導圖，帶你們過一遍。前端

一圖看完本文

1、計算機網絡體系結構分層

計算機網絡體系結構分層

不難看出，TCP/IP 與 OSI 在分層模塊上稍有區別。OSI 參考模型注重「通訊協議必要的功能是什麼」，而 TCP/IP 則更強調「在計算機上實現協議應該開發哪一種程序」。

2、 TCP/IP 基礎

1. TCP/IP 的具體含義

從字面意義上講，有人可能會認爲 TCP/IP 是指 TCP 和 IP 兩種協議。實際生活當中有時也確實就是指這兩種協議。然而在不少狀況下，它只是利用 IP 進行通訊時所必須用到的協議羣的統稱。具體來講，IP 或 ICMP、TCP 或 UDP、TELNET 或 FTP、以及 HTTP 等都屬於 TCP/IP 協議。他們與 TCP 或 IP 的關係緊密，是互聯網必不可少的組成部分。TCP/IP 一詞泛指這些協議，所以，有時也稱 TCP/IP 爲網際協議羣。
互聯網進行通訊時，須要相應的網絡協議，TCP/IP 本來就是爲使用互聯網而開發制定的協議族。所以，互聯網的協議就是 TCP/IP，TCP/IP 就是互聯網的協議。編程

網際協議羣

2. 數據包

包、幀、數據包、段、消息
以上五個術語都用來表述數據的單位，大體區分以下：緩存

包能夠說是全能性術語；
幀用於表示數據鏈路層中包的單位；
數據包是 IP 和 UDP 等網絡層以上的分層中包的單位；
段則表示 TCP 數據流中的信息；
消息是指應用協議中數據的單位。

每一個分層中，都會對所發送的數據附加一個首部，在這個首部中包含了該層必要的信息，如發送的目標地址以及協議相關信息。一般，爲協議提供的信息爲包首部，所要發送的內容爲數據。在下一層的角度看，從上一層收到的包所有都被認爲是本層的數據。安全

數據包首部

網絡中傳輸的數據包由兩部分組成：一部分是協議所要用到的首部，另外一部分是上一層傳過來的數據。首部的結構由協議的具體規範詳細定義。在數據包的首部，明確標明瞭協議應該如何讀取數據。反過來講，看到首部，也就可以瞭解該協議必要的信息以及所要處理的數據。包首部就像協議的臉。服務器

3. 數據處理流程

下圖以用戶 a 向用戶 b 發送郵件爲例子：網絡

數據處理流程

① 應用程序處理
首先應用程序會進行編碼處理，這些編碼至關於 OSI 的表示層功能；
編碼轉化後，郵件不必定立刻被髮送出去，這種什麼時候創建通訊鏈接什麼時候發送數據的管理功能，至關於 OSI 的會話層功能。
② TCP 模塊的處理
TCP 根據應用的指示，負責創建鏈接、發送數據以及斷開鏈接。TCP 提供將應用層發來的數據順利發送至對端的可靠傳輸。爲了實現這一功能，須要在應用層數據的前端附加一個 TCP 首部。
③ IP 模塊的處理
IP 將 TCP 傳過來的 TCP 首部和 TCP 數據合起來當作本身的數據，並在 TCP 首部的前端加上本身的 IP 首部。IP 包生成後，參考路由控制表決定接受此 IP 包的路由或主機。
④ 網絡接口（以太網驅動）的處理
從 IP 傳過來的 IP 包對於以太網來講就是數據。給這些數據附加上以太網首部並進行發送處理，生成的以太網數據包將經過物理層傳輸給接收端。
⑤ 網絡接口（以太網驅動）的處理
主機收到以太網包後，首先從以太網包首部找到 MAC 地址判斷是否爲發送給本身的包，若不是則丟棄數據。
若是是發送給本身的包，則從以太網包首部中的類型肯定數據類型，再傳給相應的模塊，如 IP、ARP 等。這裏的例子則是 IP 。
⑥ IP 模塊的處理
IP 模塊接收到數據後也作相似的處理。從包首部中判斷此 IP 地址是否與本身的 IP 地址匹配，若是匹配則根據首部的協議類型將數據發送給對應的模塊，如 TCP、UDP。這裏的例子則是 TCP。
另外嗎，對於有路由器的狀況，接收端地址每每不是本身的地址，此時，須要藉助路由控制表，在調查應該送往的主機或路由器以後再進行轉發數據。
⑦ TCP 模塊的處理
在 TCP 模塊中，首先會計算一下校驗和，判斷數據是否被破壞。而後檢查是否在按照序號接收數據。最後檢查端口號，肯定具體的應用程序。數據被完整地接收之後，會傳給由端口號識別的應用程序。
⑧ 應用程序的處理
接收端應用程序會直接接收發送端發送的數據。經過解析數據，展現相應的內容。

3、傳輸層中的 TCP 和 UDP

TCP/IP 中有兩個具備表明性的傳輸層協議，分別是 TCP 和 UDP。數據結構

TCP 是面向鏈接的、可靠的流協議。流就是指不間斷的數據結構，當應用程序採用 TCP 發送消息時，雖然能夠保證發送的順序，但仍是猶如沒有任何間隔的數據流發送給接收端。TCP 爲提供可靠性傳輸，實行「順序控制」或「重發控制」機制。此外還具有「流控制（流量控制）」、「擁塞控制」、提升網絡利用率等衆多功能。
UDP 是不具備可靠性的數據報協議。細微的處理它會交給上層的應用去完成。在 UDP 的狀況下，雖然能夠確保發送消息的大小，卻不能保證消息必定會到達。所以，應用有時會根據本身的須要進行重發處理。
TCP 和 UDP 的優缺點沒法簡單地、絕對地去作比較：TCP 用於在傳輸層有必要實現可靠傳輸的狀況；而在一方面，UDP 主要用於那些對高速傳輸和實時性有較高要求的通訊或廣播通訊。TCP 和 UDP 應該根據應用的目的按需使用。

1. 端口號

數據鏈路和 IP 中的地址，分別指的是 MAC 地址和 IP 地址。前者用來識別同一鏈路中不一樣的計算機，後者用來識別 TCP/IP 網絡中互連的主機和路由器。在傳輸層也有這種相似於地址的概念，那就是端口號。端口號用來識別同一臺計算機中進行通訊的不一樣應用程序。所以，它也被稱爲程序地址。socket

1.1 根據端口號識別應用

一臺計算機上同時能夠運行多個程序。傳輸層協議正是利用這些端口號識別本機中正在進行通訊的應用程序，並準確地將數據傳輸。函數

經過端口號識別應用

1.2 經過 IP 地址、端口號、協議號進行通訊識別

僅憑目標端口號識別某一個通訊是遠遠不夠的。

經過端口號、IP地址、協議號進行通訊識別

① 和② 的通訊是在兩臺計算機上進行的。它們的目標端口號相同，都是80。這裏能夠根據源端口號加以區分。
③ 和 ① 的目標端口號和源端口號徹底相同，但它們各自的源 IP 地址不一樣。
此外，當 IP 地址和端口號全都同樣時，咱們還能夠經過協議號來區分（TCP 和 UDP）。

1.3 端口號的肯定

標準既定的端口號：這種方法也叫靜態方法。它是指每一個應用程序都有其指定的端口號。但並非說能夠隨意使用任何一個端口號。例如 HTTP、FTP、TELNET 等廣爲使用的應用協議中所使用的端口號就是固定的。這些端口號被稱爲知名端口號，分佈在 0~1023 之間；除知名端口號以外，還有一些端口號被正式註冊，它們分佈在 1024~49151 之間，不過這些端口號可用於任何通訊用途。
時序分配法：服務器有必要肯定監聽端口號，可是接受服務的客戶端不必肯定端口號。在這種方法下，客戶端應用程序徹底能夠不用本身設置端口號，而全權交給操做系統進行分配。動態分配的端口號範圍在 49152~65535 之間。

1.4 端口號與協議

端口號由其使用的傳輸層協議決定。所以，不一樣的傳輸層協議可使用相同的端口號。
此外，那些知名端口號與傳輸層協議並沒有關係。只要端口一致都將分配同一種應用程序進行處理。

2. UDP

UDP 不提供複雜的控制機制，利用 IP 提供面向無鏈接的通訊服務。
而且它是將應用程序發來的數據在收到的那一刻，當即按照原樣發送到網絡上的一種機制。即便是出現網絡擁堵的狀況，UDP 也沒法進行流量控制等避免網絡擁塞行爲。
此外，傳輸途中出現丟包，UDP 也不負責重發。
甚至當包的到達順序出現亂序時也沒有糾正的功能。
若是須要以上的細節控制，不得不交由採用 UDP 的應用程序去處理。
UDP 經常使用於一下幾個方面：1.包總量較少的通訊（DNS、SNMP等）；2.視頻、音頻等多媒體通訊（即時通訊）；3.限定於 LAN 等特定網絡中的應用通訊；4.廣播通訊（廣播、多播）。

3. TCP

TCP 與 UDP 的區別至關大。它充分地實現了數據傳輸時各類控制功能，能夠進行丟包時的重發控制，還能夠對次序亂掉的分包進行順序控制。而這些在 UDP 中都沒有。
此外，TCP 做爲一種面向有鏈接的協議，只有在確認通訊對端存在時纔會發送數據，從而能夠控制通訊流量的浪費。
根據 TCP 的這些機制，在 IP 這種無鏈接的網絡上也可以實現高可靠性的通訊（主要經過檢驗和、序列號、確認應答、重發控制、鏈接管理以及窗口控制等機制實現）。

3.1 三次握手（重點）

TCP 提供面向有鏈接的通訊傳輸。面向有鏈接是指在數據通訊開始以前先作好兩端之間的準備工做。
所謂三次握手是指創建一個 TCP 鏈接時須要客戶端和服務器端總共發送三個包以確認鏈接的創建。在socket編程中，這一過程由客戶端執行connect來觸發。

下面來看看三次握手的流程圖：性能

三次握手

第一次握手：客戶端將標誌位SYN置爲1，隨機產生一個值seq=J，並將該數據包發送給服務器端，客戶端進入SYN_SENT狀態，等待服務器端確認。
第二次握手：服務器端收到數據包後由標誌位SYN=1知道客戶端請求創建鏈接，服務器端將標誌位SYN和ACK都置爲1，ack=J+1，隨機產生一個值seq=K，並將該數據包發送給客戶端以確認鏈接請求，服務器端進入SYN_RCVD狀態。
第三次握手：客戶端收到確認後，檢查ack是否爲J+1，ACK是否爲1，若是正確則將標誌位ACK置爲1，ack=K+1，並將該數據包發送給服務器端，服務器端檢查ack是否爲K+1，ACK是否爲1，若是正確則鏈接創建成功，客戶端和服務器端進入ESTABLISHED狀態，完成三次握手，隨後客戶端與服務器端之間能夠開始傳輸數據了。

3.2 四次揮手（重點）

四次揮手即終止TCP鏈接，就是指斷開一個TCP鏈接時，須要客戶端和服務端總共發送4個包以確認鏈接的斷開。在socket編程中，這一過程由客戶端或服務端任一方執行close來觸發。
因爲TCP鏈接是全雙工的，所以，每一個方向都必需要單獨進行關閉，這一原則是當一方完成數據發送任務後，發送一個FIN來終止這一方向的鏈接，收到一個FIN只是意味着這一方向上沒有數據流動了，即不會再收到數據了，可是在這個TCP鏈接上仍然可以發送數據，直到這一方向也發送了FIN。首先進行關閉的一方將執行主動關閉，而另外一方則執行被動關閉。

下面來看看四次揮手的流程圖：

四次揮手

中斷鏈接端能夠是客戶端，也能夠是服務器端。
第一次揮手：客戶端發送一個FIN=M，用來關閉客戶端到服務器端的數據傳送，客戶端進入FIN_WAIT_1狀態。意思是說"我客戶端沒有數據要發給你了"，可是若是你服務器端還有數據沒有發送完成，則沒必要急着關閉鏈接，能夠繼續發送數據。
第二次揮手：服務器端收到FIN後，先發送ack=M+1，告訴客戶端，你的請求我收到了，可是我還沒準備好，請繼續你等個人消息。這個時候客戶端就進入FIN_WAIT_2 狀態，繼續等待服務器端的FIN報文。
第三次揮手：當服務器端肯定數據已發送完成，則向客戶端發送FIN=N報文，告訴客戶端，好了，我這邊數據發完了，準備好關閉鏈接了。服務器端進入LAST_ACK狀態。
第四次揮手：客戶端收到FIN=N報文後，就知道能夠關閉鏈接了，可是他仍是不相信網絡，怕服務器端不知道要關閉，因此發送ack=N+1後進入TIME_WAIT狀態，若是Server端沒有收到ACK則能夠重傳。服務器端收到ACK後，就知道能夠斷開鏈接了。客戶端等待了2MSL後依然沒有收到回覆，則證實服務器端已正常關閉，那好，我客戶端也能夠關閉鏈接了。最終完成了四次握手。

上面是一方主動關閉，另外一方被動關閉的狀況，實際中還會出現同時發起主動關閉的狀況，
具體流程以下圖：

同時揮手

3.3 經過序列號與確認應答提升可靠性

在 TCP 中，當發送端的數據到達接收主機時，接收端主機會返回一個已收到消息的通知。這個消息叫作確認應答（ACK）。當發送端將數據發出以後會等待對端的確認應答。若是有確認應答，說明數據已經成功到達對端。反之，則數據丟失的可能性很大。
在必定時間內沒有等待到確認應答，發送端就能夠認爲數據已經丟失，並進行重發。由此，即便產生了丟包，仍然可以保證數據可以到達對端，實現可靠傳輸。
未收到確認應答並不意味着數據必定丟失。也有多是數據對方已經收到，只是返回的確認應答在途中丟失。這種狀況也會致使發送端誤覺得數據沒有到達目的地而重發數據。
此外，也有可能由於一些其餘緣由致使確認應答延遲到達，在源主機重發數據之後纔到達的狀況也家常便飯。此時，源主機只要按照機制重發數據便可。
對於目標主機來講，反覆收到相同的數據是不可取的。爲了對上層應用提供可靠的傳輸，目標主機必須放棄重複的數據包。爲此咱們引入了序列號。
序列號是按照順序給發送數據的每個字節（8位字節）都標上號碼的編號。接收端查詢接收數據 TCP 首部中的序列號和數據的長度，將本身下一步應該接收的序列號做爲確認應答返送回去。經過序列號和確認應答號，TCP 可以識別是否已經接收數據，又可以判斷是否須要接收，從而實現可靠傳輸。

序列號和確認應答

3.4 重發超時的肯定

重發超時是指在重發數據以前，等待確認應答到來的那個特定時間間隔。若是超過這個時間仍未收到確認應答，發送端將進行數據重發。最理想的是，找到一個最小時間，它能保證「確認應答必定能在這個時間內返回」。
TCP 要求不論處在何種網絡環境下都要提供高性能通訊，而且不管網絡擁堵狀況發生何種變化，都必須保持這一特性。爲此，它在每次發包時都會計算往返時間及其誤差。將這個往返時間和誤差時間相加，重發超時的時間就是比這個總和要稍大一點的值。
在 BSD 的 Unix 以及 Windows 系統中，超時都以0.5秒爲單位進行控制，所以重發超時都是0.5秒的整數倍。不過，最初其重發超時的默認值通常設置爲6秒左右。
數據被重發以後若仍是收不到確認應答，則進行再次發送。此時，等待確認應答的時間將會以2倍、4倍的指數函數延長。
此外，數據也不會被無限、反覆地重發。達到必定重發次數以後，若是仍沒有任何確認應答返回，就會判斷爲網絡或對端主機發生了異常，強制關閉鏈接。而且通知應用通訊異常強行終止。

3.5 以段爲單位發送數據

在創建 TCP 鏈接的同時，也能夠肯定發送數據包的單位，咱們也能夠稱其爲「最大消息長度」（MSS）。最理想的狀況是，最大消息長度正好是 IP 中不會被分片處理的最大數據長度。
TCP 在傳送大量數據時，是以 MSS 的大小將數據進行分割發送。進行重發時也是以 MSS 爲單位。
MSS 在三次握手的時候，在兩端主機之間被計算得出。兩端的主機在發出創建鏈接的請求時，會在 TCP 首部中寫入 MSS 選項，告訴對方本身的接口可以適應的 MSS 的大小。而後會在二者之間選擇一個較小的值投入使用。

3.6 利用窗口控制提升速度

TCP 以1個段爲單位，每發送一個段進行一次確認應答的處理。這樣的傳輸方式有一個缺點，就是包的往返時間越長通訊性能就越低。
爲解決這個問題，TCP 引入了窗口這個概念。確認應答再也不是以每一個分段，而是以更大的單位進行確認，轉發時間將會被大幅地縮短。也就是說，發送端主機，在發送了一個段之後沒必要要一直等待確認應答，而是繼續發送。以下圖所示：

窗口控制
窗口大小就是指無需等待確認應答而能夠繼續發送數據的最大值。上圖中窗口大小爲4個段。這個機制實現了使用大量的緩衝區，經過對多個段同時進行確認應答的功能。

3.7 滑動窗口控制

滑動窗口

上圖中的窗口內的數據即使沒有收到確認應答也能夠被髮送出去。不過，在整個窗口的確認應答沒有到達以前，若是其中部分數據出現丟包，那麼發送端仍然要負責重傳。爲此，發送端主機須要設置緩存保留這些待被重傳的數據，直到收到他們的確認應答。
在滑動窗口之外的部分包括未發送的數據以及已經確認對端已收到的數據。當數據發出後若如期收到確認應答就能夠不用再進行重發，此時數據就能夠從緩存區清除。
收到確認應答的狀況下，將窗口滑動到確認應答中的序列號的位置。這樣能夠順序地將多個段同時發送提升通訊性能。這種機制也別稱爲滑動窗口控制。

3.8 窗口控制中的重發控制

在使用窗口控制中，出現丟包通常分爲兩種狀況：

① 確認應答未能返回的狀況。在這種狀況下，數據已經到達對端，是不須要再進行重發的，以下圖：

部分確認應答丟失

② 某個報文段丟失的狀況。接收主機若是收到一個本身應該接收的序列號之外的數據時，會針對當前爲止收到數據返回確認應答。以下圖所示，當某一報文段丟失後，發送端會一直收到序號爲1001的確認應答，所以，在窗口比較大，又出現報文段丟失的狀況下，同一個序列號的確認應答將會被重複不斷地返回。而發送端主機若是連續3次收到同一個確認應答，就會將其對應的數據進行重發。這種機制比以前提到的超時管理更加高效，所以也被稱爲高速重發控制。

高速重發控制

4、網絡層中的 IP 協議

IP（IPv四、IPv6）至關於 OSI 參考模型中的第3層——網絡層。網絡層的主要做用是「實現終端節點之間的通訊」。這種終端節點之間的通訊也叫「點對點通訊」。
網絡的下一層——數據鏈路層的主要做用是在互連同一種數據鏈路的節點之間進行包傳遞。而一旦跨越多種數據鏈路，就須要藉助網絡層。網絡層能夠跨越不一樣的數據鏈路，即便是在不一樣的數據鏈路上也能實現兩端節點之間的數據包傳輸。
IP 大體分爲三大做用模塊，它們是 IP 尋址、路由（最終節點爲止的轉發）以及 IP 分包與組包。

1. IP 地址

1.1 IP 地址概述

在計算機通訊中，爲了識別通訊對端，必需要有一個相似於地址的識別碼進行標識。在數據鏈路中的 MAC 地址正是用來標識同一個鏈路中不一樣計算機的一種識別碼。
做爲網絡層的 IP ,也有這種地址信息，通常叫作 IP 地址。IP 地址用於在「鏈接到網絡中的全部主機中識別出進行通訊的目標地址」。所以，在 TCP/IP 通訊中全部主機或路由器必須設定本身的 IP 地址。
不論一臺主機與哪一種數據鏈路鏈接，其 IP 地址的形式都保持不變。
IP 地址（IPv4 地址）由32位正整數來表示。IP 地址在計算機內部以二進制方式被處理。然而，因爲咱們並不習慣於採用二進制方式，咱們將32位的 IP 地址以每8位爲一組，分紅4組，每組以「.」隔開，再將每組數轉換成十進制數。以下：

2⁸	2⁸	2⁸	2⁸
10101100	00010100	00000001	00000001	（2進制）
10101100.	00010100.	00000001.	00000001	（2進制）
172.	20.	1.	1	（10進制）

1.2 IP 地址由網絡和主機兩部分標識組成

以下圖，網絡標識在數據鏈路的每一個段配置不一樣的值。網絡標識必須保證相互鏈接的每一個段的地址不相重複。而相同段內相連的主機必須有相同的網絡地址。IP 地址的「主機標識」則不容許在同一個網段內重複出現。由此，能夠經過設置網絡地址和主機地址，在相互鏈接的整個網絡中保證每臺主機的 IP 地址都不會相互重疊。即 IP 地址具備了惟一性。

IP地址的主機標識

以下圖，IP 包被轉發到途中某個路由器時，正是利用目標 IP 地址的網絡標識進行路由。由於即便不看主機標識，只要一見到網絡標識就能判斷出是否爲該網段內的主機。

IP地址的網絡標識

1.3 IP 地址的分類

IP 地址分爲四個級別，分別爲A類、B類、C類、D類。它根據 IP 地址中從第 1 位到第 4 位的比特列對其網絡標識和主機標識進行區分。
A 類 IP 地址是首位以「0」開頭的地址。從第 1 位到第 8 位是它的網絡標識。用十進制表示的話，0.0.0.0~127.0.0.0 是 A 類的網絡地址。A 類地址的後 24 位至關於主機標識。所以，一個網段內可容納的主機地址上限爲16,777,214個。
B 類 IP 地址是前兩位「10」的地址。從第 1 位到第 16 位是它的網絡標識。用十進制表示的話，128.0.0.0~191.255.0.0 是 B 類的網絡地址。B 類地址的後 16 位至關於主機標識。所以，一個網段內可容納的主機地址上限爲65,534個。
C 類 IP 地址是前三位爲「110」的地址。從第 1 位到第 24 位是它的網絡標識。用十進制表示的話，192.0.0.0~223.255.255.0 是 C 類的網絡地址。C 類地址的後 8 位至關於主機標識。所以，一個網段內可容納的主機地址上限爲254個。
D 類 IP 地址是前四位爲「1110」的地址。從第 1 位到第 32 位是它的網絡標識。用十進制表示的話，224.0.0.0~239.255.255.255 是 D 類的網絡地址。D 類地址沒有主機標識，經常使用於多播。
在分配 IP 地址時關於主機標識有一點須要注意。即要用比特位表示主機地址時，不能夠所有爲 0 或所有爲 1。由於所有爲 0 只有在表示對應的網絡地址或 IP 地址不能夠獲知的狀況下才使用。而所有爲 1 的主機一般做爲廣播地址。所以，在分配過程當中，應該去掉這兩種狀況。這也是爲何 C 類地址每一個網段最多隻能有 254（ 2⁸ - 2 = 254）個主機地址的緣由。

1.4 廣播地址

廣播地址用於在同一個鏈路中相互鏈接的主機之間發送數據包。將 IP 地址中的主機地址部分所有設置爲 1，就成了廣播地址。
廣播分爲本地廣播和直接廣播兩種。在本網絡內的廣播叫作本地廣播；在不一樣網絡之間的廣播叫作直接廣播。

1.5 IP 多播

多播用於將包發送給特定組內的全部主機。因爲其直接使用 IP 地址，所以也不存在可靠傳輸。
相比於廣播，多播既能夠穿透路由器，又能夠實現只給那些必要的組發送數據包。請看下圖：

IP 多播
多播使用 D 類地址。所以，若是從首位開始到第 4 位是「1110」，就能夠認爲是多播地址。而剩下的 28 位能夠成爲多播的組編號。
此外，對於多播，全部的主機（路由器之外的主機和終端主機）必須屬於 224.0.0.1 的組，全部的路由器必須屬於 224.0.0.2 的組。

1.6 子網掩碼

如今一個 IP 地址的網絡標識和主機標識已再也不受限於該地址的類別，而是由一個叫作「子網掩碼」的識別碼經過子網網絡地址細分出比 A 類、B 類、C 類更小粒度的網絡。這種方式實際上就是將原來 A 類、B 類、C 類等分類中的主機地址部分用做子網地址，能夠將原網絡分爲多個物理網絡的一種機制。
子網掩碼用二進制方式表示的話，也是一個 32 位的數字。它對應 IP 地址網絡標識部分的位所有爲「1」，對應 IP 地址主機標識的部分則所有爲「0」。由此，一個 IP 地址能夠再也不受限於本身的類別，而是能夠用這樣的子網掩碼自由地定位本身的網絡標識長度。固然，子網掩碼必須是 IP 地址的首位開始連續的「1」。
對於子網掩碼，目前有兩種表示方式。第一種是，將 IP 地址與子網掩碼的地址分別用兩行來表示。以 172.20.100.52 的前 26 位是網絡地址的狀況爲例，以下：

IP 地址	172.	20.	100.	52
子網掩碼	255.	255.	255.	192

網絡地址	172.	20.	100.	0
子網掩碼	255.	255.	255.	192

廣播地址	172.	20.	100.	63
子網掩碼	255.	255.	255.	192

第二種表示方式是，在每一個 IP 地址後面追加網絡地址的位數用「/ 」隔開，以下：

IP 地址	172.	20.	100.	52	/ 26
網絡地址	172.	20.	100.	0	/ 26
廣播地址	172.	20.	100.	63	/ 26

另外，在第二種方式下記述網絡地址時能夠省略後面的「0」。例如：172.20.0.0/26 跟 172.20/26 實際上是一個意思。

2. 路由

發送數據包時所使用的地址是網絡層的地址，即 IP 地址。然而僅僅有 IP 地址還不足以實現將數據包發送到對端目標地址，在數據發送過程當中還須要相似於「指明路由器或主機」的信息，以便真正發往目標地址。保存這種信息的就是路由控制表。
該路由控制表的造成方式有兩種：一種是管理員手動設置，另外一種是路由器與其餘路由器相互交換信息時自動刷新。前者也叫作靜態路由控制，然後者叫作動態路由控制。
IP 協議始終認爲路由表是正確的。而後，IP 自己並無定義製做路由控制表的協議。即 IP 沒有製做路由控制表的機制。該表示由一個叫作「路由協議」的協議製做而成。

2.1 IP 地址與路由控制

IP 地址的網絡地址部分用於進行路由控制。
路由控制表中記錄着網絡地址與下一步應該發送至路由器的地址。
在發送 IP 包時，首先要肯定 IP 包首部中的目標地址，再從路由控制表中找到與該地址具備相同網絡地址的記錄，根據該記錄將 IP 包轉發給相應的下一個路由器。若是路由控制表中存在多條相同網絡地址的記錄，就選擇一個最爲吻合的網絡地址。

路由控制表與 IP 包發送

3. IP 分包與組包

每種數據鏈路的最大傳輸單元（MTU）都不盡相同，由於每一個不一樣類型的數據鏈路的使用目的不一樣。使用目的不一樣，可承載的 MTU 也就不一樣。
任何一臺主機都有必要對 IP 分片進行相應的處理。分片每每在網絡上遇到比較大的報文沒法一會兒發送出去時纔會進行處理。
通過分片以後的 IP 數據報在被重組的時候，只能由目標主機進行。路由器雖然作分片但不會進行重組。

3.1 路徑 MTU 發現

分片機制也有它的不足。如路由器的處理負荷加劇之類。所以，只要容許，是不但願由路由器進行 IP 數據包的分片處理的。
爲了應對分片機制的不足，「路徑 MTU 發現」技術應運而生。路徑 MTU 指的是，從發送端主機到接收端主機之間不須要分片是最大 MTU 的大小。即路徑中存在的全部數據鏈路中最小的 MTU 。
進行路徑 MTU 發現，就能夠避免在中途的路由器上進行分片處理，也能夠在 TCP 中發送更大的包。

4. IPv6

IPv6（IP version 6）是爲了根本解決 IPv4 地址耗盡的問題而被標準化的網際協議。IPv4 的地址長度爲 4 個 8 位字節，即 32 比特。而 IPv6 的地址長度則是原來的 4 倍，即 128 比特，通常寫成 8 個 16 位字節。

4.1 IPv6 的特色

IP 得知的擴大與路由控制表的聚合。
性能提高。包首部長度採用固定的值（40字節），再也不採用首部檢驗碼。簡化首部結構，減輕路由器負擔。路由器再也不作分片處理。
支持即插即用功能。即便沒有DHCP服務器也能夠實現自動分配 IP 地址。
採用認證與加密功能。應對僞造 IP 地址的網絡安全功能以及防止線路竊聽的功能。
多播、Mobile IP 成爲擴展功能。

4.2 IPv6 中 IP 地址的標記方法

通常人們將 128 比特 IP 地址以每 16 比特爲一組，每組用冒號（「：」）隔開進行標記。
並且若是出現連續的 0 時還能夠將這些 0 省略，並用兩個冒號（「：：」）隔開。可是，一個 IP 地址中只容許出現一次兩個連續的冒號。

4.3 IPv6 地址的結構

IPv6 相似 IPv4，也是經過 IP 地址的前幾位標識 IP 地址的種類。
在互聯網通訊中，使用一種全局的單播地址。它是互聯網中惟一的一個地址，不須要正式分配 IP 地址。

未定義	0000 ... 0000（128比特）	：：/ 128
環回地址	0000 ... 0001（128比特）	：：1 / 128
惟一本地地址	1111 110	FC00：/ 7
鏈路本地單播地址	1111 1110 10	FE80：：/ 10
多播地址	1111 1111	FF00：：/ 8
全局單播地址	（其餘）

4.4 全局單播地址

全局單播地址是指世界上惟一的一個地址。它是互聯網通訊以及各個域內部通訊中最爲經常使用的一個 IPv6 地址。
格式以下圖所示，如今 IPv6 的網絡中所使用的格式爲，n = 48，m = 16 以及 128 - n - m = 64。即前 64 比特爲網絡標識，後 64 比特爲主機標識。

全局單播地址

4.5 鏈路本地單播地址

鏈路本地單播地址是指在同一個數據鏈路內惟一的地址。它用於不通過路由器，在同一個鏈路中的通訊。一般接口 ID 保存 64 比特版的 MAC 地址。

鏈路本地單播地址

4.6 惟一本地地址

惟一本地地址是不進行互聯網通訊時所用的地址。
惟一本地地址雖然不會與互聯網鏈接，可是也會盡量地隨機生成一個惟一的全局 ID。
L 一般被置爲 1
全局 ID 的值隨機決定
子網 ID 是指該域子網地址
接口 ID 即爲接口的 ID

惟一本地地址

4.7 IPv6 分段處理

IPv6 的分片處理只在做爲起點的發送端主機上進行，路由器不參與分片。
IPv6 中最小 MTU 爲 1280 字節，所以，在嵌入式系統中對於那些有必定系統資源限制的設備來講，不須要進行「路徑 MTU 發現」，而是在發送 IP 包時直接以 1280 字節爲單位分片送出。

4.8 IP 首部（暫略）

5. IP 協議相關技術

IP 旨在讓最終目標主機收到數據包，可是在這一過程當中僅僅有 IP 是沒法實現通訊的。必須還有可以解析主機名稱和 MAC 地址的功能，以及數據包在發送過程當中異常狀況處理的功能。

5.1 DNS

咱們日常在訪問某個網站時不適用 IP 地址，而是用一串由羅馬字和點號組成的字符串。而通常用戶在使用 TCP/IP 進行通訊時也不使用 IP 地址。可以這樣作是由於有了 DNS （Domain Name System）功能的支持。DNS 能夠將那串字符串自動轉換爲具體的 IP 地址。
這種 DNS 不只適用於 IPv4，還適用於 IPv6。

5.2 ARP

只要肯定了 IP 地址，就能夠向這個目標地址發送 IP 數據報。然而，在底層數據鏈路層，進行實際通訊時卻有必要了解每一個 IP 地址所對應的 MAC 地址。
ARP 是一種解決地址問題的協議。以目標 IP 地址爲線索，用來定位下一個應該接收數據分包的網絡設備對應的 MAC 地址。不過 ARP 只適用於 IPv4，不能用於 IPv6。IPv6 中能夠用 ICMPv6 替代 ARP 發送鄰居探索消息。
RARP 是將 ARP 反過來，從 MAC 地址定位 IP 地址的一種協議。

5.3 ICMP

ICMP 的主要功能包括，確認 IP 包是否成功送達目標地址，通知在發送過程中 IP 包被廢棄的具體緣由，改善網絡設置等。
IPv4 中 ICMP 僅做爲一個輔助做用支持 IPv4。也就是說，在 IPv4 時期，即便沒有 ICMP，仍然能夠實現 IP 通訊。然而，在 IPv6 中，ICMP 的做用被擴大，若是沒有 ICMPv6，IPv6 就沒法進行正常通訊。

5.4 DHCP

若是逐一爲每一臺主機設置 IP 地址會是很是繁瑣的事情。特別是在移動使用筆記本電腦、只能終端以及平板電腦等設備時，每移動到一個新的地方，都要從新設置 IP 地址。
因而，爲了實現自動設置 IP 地址、統一管理 IP 地址分配，就產生了 DHCP（Dynamic Host Configuration Protocol）協議。有了 DHCP，計算機只要鏈接到網絡，就能夠進行 TCP/IP 通訊。也就是說，DHCP 讓即插即用變得可能。
DHCP 不只在 IPv4 中，在 IPv6 中也可使用。

5.5 NAT

NAT（Network Address Translator）是用於在本地網絡中使用私有地址，在鏈接互聯網時轉而使用全局 IP 地址的技術。
除轉換 IP 地址外，還出現了能夠轉換 TCP、UDP 端口號的 NAPT（Network Address Ports Translator）技術，由此能夠實現用一個全局 IP 地址與多個主機的通訊。
NAT（NAPT）其實是爲正在面臨地址枯竭的 IPv4 而開發的技術。不過，在 IPv6 中爲了提升網絡安全也在使用 NAT，在 IPv4 和 IPv6 之間的相互通訊當中經常使用 NAT-PT。

5.6 IP 隧道

夾着 IPv4 網絡的兩個 IPv6 網絡

如上圖的網絡環境中，網絡 A 與網絡 B 之間沒法直接進行通訊，爲了讓它們之間正常通訊，這時必須得采用 IP 隧道的功能。
IP 隧道能夠將那些從網絡 A 發過來的 IPv6 的包統合爲一個數據，再爲之追加一個 IPv4 的首部之後轉發給網絡 C。
通常狀況下，緊接着 IP 首部的是 TCP 或 UDP 的首部。然而，如今的應用當中「 IP 首部的後面仍是 IP 首部」或者「 IP 首部的後面是 IPv6 的首部」等狀況與日俱增。這種在網絡層的首部後面追加網絡層首部的通訊方法就叫作「 IP 隧道」。

做者：滌生_Woo 連接：https://www.jianshu.com/p/9f3e879a4c9c 來源：簡書簡書著做權歸做者全部，任何形式的轉載都請聯繫做者得到受權並註明出處。