基础（网络知识 三）——网络系统各层协议分析总结（TCP/IP/UDP/HTTP.....）
網絡系統按照分層的思想設計了當下的網絡系統結構，主要是TCP/IP四層網絡結構，各層是如何工作的呢？每一層都有相關的協議，各協議具體是什么？原理與作用是什么？本節主要總結介紹網絡層的相關協議規則，從而明白網絡系統工作原理。
1. 什么是協議？
協議就是雙方協調商議出來的一套規則，有了這個規則，雙方才能“對話”，理解對方的意思，并正確表達自己的想法，讓對方明白。
計算機網絡中的數據交換必須遵守事先約定好的規則，這些規則明確規定了所交換的數據的格式以及有關的同步問題（同步含有時序的意思），為進行網絡中的數據交換而建立的規則、標準或約定即網絡協議(network protocol)，也是一類協議。
1.1 網絡協議的組成要素
- 語法 數據與控制信息的結構或格式 。
- 語義 需要發出何種控制信息，完成何種動作以及做出何種響應。
- 同步 事件實現順序的詳細說明。
1.2 協議與服務的關系
- 本層的服務用戶只能看見服務而無法看見下面的協議。
- 下面的協議對上面的服務用戶是透明的。
- 協議是“水平的”，即協議是控制對等實體之間通信的規則。
- 服務是“垂直的”，即服務是由下層向上層通過層間接口提供的。
- 同一系統相鄰兩層的實體進行交互的地方，稱為服務訪問點 SAP (Service Access Point)。
1.3 協議很復雜
- 協議必須將各種不利的條件事先都估計到，而不能假定一切情況都是很理想和很順利的。
- 必須非常仔細地檢查所設計協議能否應付所有的不利情況。
- 應當注意：事實上難免有極個別的不利情況在設計協議時并沒有預計到。在出現這種情況時，協議就會失敗。因此實際上協議往往只能應付絕大多數的不利情況。
2. 網絡層及對應的協議
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 就是互聯網的協議。
?
3. 網際層（IP）
IP（IPv4、IPv6）相當于 OSI 參考模型中的第3層——網絡層。網絡層的主要作用是“實現終端節點之間的通信”。這種終端節點之間的通信也叫“點對點通信”。
網絡的下一層——數據鏈路層的主要作用是在互連同一種數據鏈路的節點之間進行包傳遞。而一旦跨越多種數據鏈路，就需要借助網絡層。網絡層可以跨越不同的數據鏈路，即使是在不同的數據鏈路上也能實現兩端節點之間的數據包傳輸。
IP 大致分為三大作用模塊，它們是 IP 尋址、路由（最終節點為止的轉發）以及 IP 分包與組包。
3.1 IP 地址概述
在計算機通信中，為了識別通信對端，必須要有一個類似于地址的識別碼進行標識。在數據鏈路中的 MAC 地址正是用來標識同一個鏈路中不同計算機的一種識別碼。
作為網絡層的 IP ,也有這種地址信息，一般叫做 IP 地址。IP 地址用于在“連接到網絡中的所有主機中識別出進行通信的目標地址”。因此，在 TCP/IP 通信中所有主機或路由器必須設定自己的 IP 地址。
不論一臺主機與哪種數據鏈路連接，其 IP 地址的形式都保持不變。
IP 地址（IPv4 地址）由32位正整數來表示。IP 地址在計算機內部以二進制方式被處理。然而，由于我們并不習慣于采用二進制方式，我們將32位的 IP 地址以每8位為一組，分成4組，每組以 “.” 隔開，再將每組數轉換成十進制數。如下：
3.2 IP 地址由網絡標識和主機組成
如下圖，網絡標識在數據鏈路的每個段配置不同的值，網絡標識必須保證相互連接的每個段的地址不相重復，而相同段內相連的主機必須有相同的網絡地址，IP 地址的“主機標識”則不允許在同一個網段內重復出現。由此，可以通過設置網絡地址和主機地址，在相互連接的整個網絡中保證每臺主機的 IP 地址都不會相互重疊，即 IP 地址具有了唯一性。
IP地址的主機標識，如下圖，IP 包被轉發到途中某個路由器時，正是利用目標 IP 地址的網絡標識進行路由。因為即使不看主機標識，只要一見到網絡標識就能判斷出是否為該網段內的主機。
3.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（ 28?- 2 = 254）個主機地址的原因。
3.4 廣播地址
廣播地址用于在同一個鏈路中相互連接的主機之間發送數據包。將 IP 地址中的主機地址部分全部設置為 1，就成了廣播地址。
廣播分為本地廣播和直接廣播兩種。在本網絡內的廣播叫做本地廣播；在不同網絡之間的廣播叫做直接廣播。
3.5 IP 多播
多播用于將包發送給特定組內的所有主機。由于其直接使用 IP 地址，因此也不存在可靠傳輸。
相比于廣播，多播既可以穿透路由器，又可以實現只給那些必要的組發送數據包。請看下圖：
多播使用 D 類地址。因此，如果從首位開始到第 4 位是 “1110”，就可以認為是多播地址。而剩下的 28 位可以成為多播的組編號。
此外， 對于多播，所有的主機（路由器以外的主機和終端主機）必須屬于 224.0.0.1 的組，所有的路由器必須屬于 224.0.0.2 的組。
3.6 子網掩碼
現在一個 IP 地址的網絡標識和主機標識已不再受限于該地址的類別，而是由一個叫做“子網掩碼”的識別碼通過子網網絡地址細分出比 A 類、B 類、C 類更小粒度的網絡。這種方式實際上就是將原來 A 類、B 類、C 類等分類中的主機地址部分用作子網地址，可以將原網絡分為多個物理網絡的一種機制。
子網掩碼用二進制方式表示的話，也是一個 32 位的數字。它對應 IP 地址網絡標識部分的位全部為 “1”，對應 IP 地址主機標識的部分則全部為 “0”。由此，一個 IP 地址可以不再受限于自己的類別，而是可以用這樣的子網掩碼自由地定位自己的網絡標識長度。當然，子網掩碼必須是 IP 地址的首位開始連續的 “1”。
對于子網掩碼，目前有兩種表示方式。第一種是，將 IP 地址與子網掩碼的地址分別用兩行來表示。以 172.20.100.52 的前 26 位是網絡地址的情況為例，如下：
?
- 第二種表示方式是，在每個 IP 地址后面追加網絡地址的位數用 “/ ” 隔開，如下：
3.7?IP 協議相關技術
IP 旨在讓最終目標主機收到數據包，但是在這一過程中僅僅有 IP 是無法實現通信的。必須還有能夠解析主機名稱和 MAC 地址的功能，以及數據包在發送過程中異常情況處理的功能。
（1）DNS
我們平常在訪問某個網站時不適用 IP 地址，而是用一串由羅馬字和點號組成的字符串。而一般用戶在使用 TCP/IP 進行通信時也不使用 IP 地址。能夠這樣做是因為有了 DNS （Domain Name System）功能的支持。DNS 可以將那串字符串自動轉換為具體的 IP 地址。
這種 DNS 不僅適用于 IPv4，還適用于 IPv6。
（2） ARP
只要確定了 IP 地址，就可以向這個目標地址發送 IP 數據報。然而，在底層數據鏈路層，進行實際通信時卻有必要了解每個 IP 地址所對應的 MAC 地址。
ARP 是一種解決地址問題的協議。以目標 IP 地址為線索，用來定位下一個應該接收數據分包的網絡設備對應的 MAC 地址。不過 ARP 只適用于 IPv4，不能用于 IPv6。IPv6 中可以用 ICMPv6 替代 ARP 發送鄰居探索消息。
RARP 是將 ARP 反過來，從 MAC 地址定位 IP 地址的一種協議。
（3） ICMP
ICMP 的主要功能包括，確認 IP 包是否成功送達目標地址，通知在發送過程當中 IP 包被廢棄的具體原因，改善網絡設置等。
IPv4 中 ICMP 僅作為一個輔助作用支持 IPv4。也就是說，在 IPv4 時期，即使沒有 ICMP，仍然可以實現 IP 通信。然而，在 IPv6 中，ICMP 的作用被擴大，如果沒有 ICMPv6，IPv6 就無法進行正常通信。
（4）DHCP
如果逐一為每一臺主機設置 IP 地址會是非常繁瑣的事情。特別是在移動使用筆記本電腦、只能終端以及平板電腦等設備時，每移動到一個新的地方，都要重新設置 IP 地址。
于是，為了實現自動設置 IP 地址、統一管理 IP 地址分配，就產生了 DHCP（Dynamic Host Configuration Protocol）協議。有了 DHCP，計算機只要連接到網絡，就可以進行 TCP/IP 通信。也就是說，DHCP 讓即插即用變得可能。
DHCP 不僅在 IPv4 中，在 IPv6 中也可以使用。
（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。
（6） IP 隧道
如上圖的網絡環境中，網絡 A 與網絡 B 之間無法直接進行通信，為了讓它們之間正常通信，這時必須得采用 IP 隧道的功能。
IP 隧道可以將那些從網絡 A 發過來的 IPv6 的包統合為一個數據，再為之追加一個 IPv4 的首部以后轉發給網絡 C。
一般情況下，緊接著 IP 首部的是 TCP 或 UDP 的首部。然而，現在的應用當中“ IP 首部的后面還是 IP 首部”或者“ IP 首部的后面是 IPv6 的首部”等情況與日俱增。這種在網絡層的首部后面追加網絡層首部的通信方法就叫做“ IP 隧道”。
?
4. 運輸層（TCP/UDP）
TCP/UDP 都是傳輸層協議，但是兩者具有不同的特效，同時也具有不同的應用場景。
4.1 UDP
- UDP 不提供復雜的控制機制，利用 IP 提供面向無連接的通信服務。
- 并且它是將應用程序發來的數據在收到的那一刻，立即按照原樣發送到網絡上的一種機制。即使是出現網絡擁堵的情況，UDP 也無法進行流量控制等避免網絡擁塞行為。
- 此外，傳輸途中出現丟包，UDP 也不負責重發。
- 甚至當包的到達順序出現亂序時也沒有糾正的功能。
- 如果需要以上的細節控制，不得不交由采用 UDP 的應用程序去處理。
- UDP 常用于一下幾個方面：1.包總量較少的通信（DNS、SNMP等）；2.視頻、音頻等多媒體通信（即時通信）；3.限定于 LAN 等特定網絡中的應用通信；4.廣播通信（廣播、多播）。
- UDP面向報文：面向報文的傳輸方式是應用層交給UDP多長的報文，UDP發送多長的報文，即一次發送一個報文。因此，應用程序必須選擇合適大小的報文。
?
4.2 TCP
- TCP面向字節流：雖然應用程序和TCP的交互是一次一個數據塊(大小不等)，但TCP把應用程序看成是一連串的無結構的字節流。TCP有一個緩沖，當應該程序傳送的數據塊太長，TCP就可以把它劃分短一些再傳送。
- TCP 與 UDP 的區別相當大。它充分地實現了數據傳輸時各種控制功能，可以進行丟包時的重發控制，還可以對次序亂掉的分包進行順序控制。而這些在 UDP 中都沒有。
- 此外，TCP 作為一種面向有連接的協議，只有在確認通信對端存在時才會發送數據，從而可以控制通信流量的浪費。
- 根據 TCP 的這些機制，在 IP 這種無連接的網絡上也能夠實現高可靠性的通信（ 主要通過檢驗和、序列號、確認應答、重發控制、連接管理以及窗口控制等機制實現）。
提到TCP就必須開始介紹“TCP的三次握手與四次揮手”。
4.2.1 三次握手
具體過程如下：
第一次握手：建立連接。客戶端發送連接請求報文段，并將syn(標記位)設置為1，Squence Number(數據包序號)(seq)為x,接下來等待服務端確認，客戶端進入SYN_SENT狀態(請求連接)；
第二次握手：服務端收到客戶端的 SYN 報文段，對 SYN 報文段進行確認，設置 ack(確認號)為 x+1(即seq+1 ; 同時自己還要發送 SYN 請求信息，將 SYN 設置為1, seq為 y。服務端將上述所有信息放到 SYN+ACK 報文段中，一并發送給客戶端，此時服務器進入 SYN_RECV狀態。
SYN_RECV是指,服務端被動打開后,接收到了客戶端的SYN并且發送了ACK時的狀態。 再進一步接收到客戶端的ACK就進入ESTABLISHED狀態。第三次握手：客戶端收到服務端的 SYN+ACK(確認符) 報文段；然后將 ACK 設置為 y+1,向服務端發送ACK報文段，這個報文段發送完畢后，客戶端和服務端都進入ESTABLISHED(連接成功)狀態，完成TCP 的三次握手。
?
不好理解？看下面兩個圖配合理解一下：
（1）
?
（2）
簡化三步握手的流程就是
- C發給S我要跟你通信。
- S告訴C你可以跟我通信同時我也要跟你通信。
- C告訴S你可以跟我通信，咱們可以開始通信了。
4.2.2 四次揮手
第一次揮手：客戶端發送一個FIN=1，用來關閉客戶端到服務器端的數據傳送，客戶端進入FIN_WAIT_1狀態。意思是說”我客戶端沒有數據要發給你了”，但是如果你服務器端還有數據沒有發送完成，則不必急著關閉連接，可以繼續發送數據。
第二次揮手：服務器端收到FIN后，先發送ack=u+1，告訴客戶端，你的請求我收到了，但是我還沒準備好，請繼續你等我的消息（服務端會等待沒有發送的數據發送完畢）。這個時候客戶端就進入FIN_WAIT_2 狀態，繼續等待服務器端的FIN報文。
第三次揮手：當服務器端確定數據已發送完成，則向客戶端發送FIN=1報文，告訴客戶端，好了，我這邊數據發完了，準備好關閉連接了。服務器端進入LAST_ACK狀態。
第四次揮手：客戶端收到FIN=1報文后，就知道可以關閉連接了，但是他還是不相信網絡，怕服務器端不知道要關閉，所以發送ack=w+1后進入TIME_WAIT狀態，如果Server端沒有收到ACK則可以重傳。服務器端收到ACK后，就知道可以斷開連接了。客戶端等待了2MSL（2倍最大報文存活時間）后依然沒有收到回復，則證明服務器端已正常關閉，那好，我客戶端也可以關閉連接了。最終完成了四次握手。
注意：是第四次握手2端才分別關閉的！而不是第三次！ S端收到ACK后會關閉連接，同時C端發送ACK后在等待2MSL（2倍最大報文存活時間）后C端連接也會關閉。如果第三次揮手S端直接關閉的話那么如果C端因為網絡因素沒有收到FIN的話那么客戶端會一直等待FIN，這時S端已經關閉了將導致C端永遠無法關閉的情況發生。
【注?MSL：報文段最大生存時間，它是任何報文段被丟棄前在網絡內的最長時間
- 保證TCP協議的全雙工連接能夠可靠關閉
- 保證這次連接的重復數據從網絡中消息
第一點： 如果主機1直接 關閉，由于IP協議的不可靠性或者其他網絡原因，導致主機2沒有收到主機1最后回復的 ACK。那么主機2就會在超時之后繼續發送 FIN，此時由于主機1已經關閉，就找不到與重發的 FIN 對應的連接。所以，主機1 不是直接進入 關閉，而是TIME_WAIT 狀態。當再次收到 FIN 的時候，能夠保證對方收到 ACK ，最后正確關閉連接。
第二點：如果主機1直接 關閉，然后又再向主機 2 發起一個新連接，我們不能保證這個新連接與剛才關閉的連接端口是不同的。也就是說有可能新連接和老連接的端口號是相同的。一般來說不會發生什么問題，但還是有特殊情況出現；假設新連接和已經關閉的老連接端口號是一樣的，如果前一次連接的某些數據仍然滯留在網絡中( Lost Duplicate )，那些延遲數據在建立新連接之后才到達主機2，由于新連接和老連接的端口號是一樣的，TCP 協議就認為哪個延遲的數據時屬于新連接的，這樣就和真正的新連接的數據包發生混淆了。所以TCP連接要在 TIME_WAIT 狀態等待兩倍 MSL ，保證本次連接的所有數據都從網絡中消失。】
完整的過程：
4.2.3 長連接
如果有大量的連接，每次在連接，關閉都要經歷三次握手，四次揮手，這顯然會造成性能低下。因此。Http 有一種叫做 長連接（keepalive connections） 的機制。它可以在傳輸數據后仍保持連接，當客戶端需要再次獲取數據時，直接使用剛剛空閑下來的連接而無需再次握手。
長連接的實現方式 。心跳，即在一定間隔時間內，使用 TCP 連接發送超短無意義消息來讓網關不能將自己定義為「空閑連接」，從而防止網關將自己的連接關閉(防止TCP連接通道被被動的關閉)。
4.3 應用層（HTTP）
僅僅介紹HTTP。
4.3.1 概念
HTTP協議（HyperText Transfer Protocol，超文本傳輸協議）是因特網上應用最為廣泛的一種網絡傳輸協議，所有的WWW文件都必須遵守這個標準。
HTTP是一個簡單的請求-響應協議，它指定了客戶端可能發送給服務器什么樣的消息以及得到什么樣的響應。請求和響應消息的頭以ASCII碼形式給出；而
HTTP是一個基于TCP/IP通信協議來傳遞數據（HTML 文件, 圖片文件, 查詢結果等）。TCP/IP用在傳輸層，HTTP則是工作在應用層。
注：http與https的區別
????????1、https協議需要到CA申請證書，一般免費證書較少，因而需要一定費用。
? ? ? ? ? ?? ? 2、http是超文本傳輸協議，信息是明文傳輸，https則是具有安全性的ssl/tls加密傳輸協議。
? ? ? ? ? ? ? ?3、http和https使用的是完全不同的連接方式，用的端口也不一樣，前者是80，后者是443。
? ? ? ? ? ? ? ?4、http的連接很簡單，是無狀態的；HTTPS協議是由SSL/TLS+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，比http協議安全。
4.3.2 HTTP 工作原理
HTTP協議工作于客戶端-服務端架構上。客戶端（瀏覽器）通過URL向服務端（WEB服務器）發送請求。
注：
（1）Web服務器有：Apache服務器，IIS服務器（Internet Information Services）等。
（2）Web服務器根據接收到的請求后，向客戶端發送響應信息。
（3）HTTP默認端口號為80，但是你也可以改為8080或者其他端口。
（4）URL（Uniform Resource Loator 統一資源定位符）：互聯網上每個文件都有唯一的URL，它包含的信息指出文件的位置以及瀏覽器應該如何處理它。
URL格式：http://host[":"port][abs_path]
? ? ? ? http表示要通過HTTP協議來定位網絡資源；host表示合法的Internet主機域名或者IP地址；port指定一個端口號，為空則使用缺省端口80；abs_path指定請求資源的URI；如果URL中沒有給出abs_path，那么當它作為請求URI時，必須以“/”的形式給出，通常這個工作瀏覽器自動幫我們完成。
eg:
1、輸入：www.baidu.com
瀏覽器自動轉換成：http://www.baidu.com/
2、http:192.168.0.110:8080/index.jsp?
片段標志符：URL中任一帶#的后面部分稱為片段標志符，也稱URL hash
- 片段標志符表示資源內的某一個位置，HTML文檔里，瀏覽器會尋找該標志符對應的<a>標簽 - 片段標志符只會被瀏覽器識別，不會發送給服務端 - 修改片段標志符不會重新加載頁面，但會增加一條瀏覽器的歷史記錄 - javascript可以通過window.location.hash修改片段標志符HTTP三點注意事項：
- HTTP是無連接：無連接的含義是限制每次連接只處理一個請求。服務器處理完客戶的請求，并收到客戶的應答后，即斷開連接。采用這種方式可以節省傳輸時間。
- HTTP是媒體獨立的：這意味著，只要客戶端和服務器知道如何處理的數據內容，任何類型的數據都可以通過HTTP發送。客戶端以及服務器指定使用適合的MIME-type內容類型。
HTTP是無狀態：HTTP協議是無狀態協議。無狀態是指協議對于事務處理沒有記憶能力。缺少狀態意味著如果后續處理需要前面的信息，則它必須重傳，這樣可能導致每次連接傳送的數據量增大。另一方面，在服務器不需要先前信息時它的應答就較快。
以下圖表展示了HTTP協議通信流程：
?
4.3.3. 消息結構
HTTP是基于客戶端/服務端（C/S）的架構模型，通過一個可靠的鏈接來交換信息，是一個無狀態的請求/響應協議。
一個HTTP"客戶端"是一個應用程序（Web瀏覽器或其他任何客戶端），通過連接到服務器達到向服務器發送一個或多個HTTP的請求的目的。
一個HTTP"服務器"同樣也是一個應用程序（通常是一個Web服務，如Apache Web服務器或IIS服務器等），通過接收客戶端的請求并向客戶端發送HTTP響應數據。
HTTP使用統一資源標識符（Uniform Resource Identifiers, URI）來傳輸數據和建立連接。
一旦建立連接后，數據消息就通過類似Internet郵件所使用的格式[RFC5322]和多用途Internet郵件擴展（MIME）[RFC2045]來傳送。
Data URI：以data開始的協議頭，常被用于作為小文件插入到其他文檔之中，由四部分組成：
data:image/gif;base64,R0lGODlhEAAOALMAAOazToeHh0tLS/7LZv/0jvb29t/f3//Ub//ge8WSLf/rhf/3kdbW1mxsbP//mf///yH5BAAAAAAALAAAAAAQAA4AAARe8L1Ekyky67QZ1hLnjM5UUde0ECwLJoExKcppV0aCcGCmTIHEIUEqjgaORCMxIC6e0CcguWw6aFjsVMkkIr7g77ZKPJjPZqIyd7sJAgVGoEGv2xsBxqNgYPj/gAwXEQA7- 第一部分是 data: 協議頭 - 第二部分是 MIME 類型，表示這串內容的展現方式 - 第三部分是編碼設置，默認編碼是 charset=US-ASCII - 最后一部分為這個 Data URI 承載的內容，它可以是純文本編寫的內容，也可以是經過base64編碼的內容http報文格式：
（1）客戶端請求消息
客戶端發送一個HTTP請求到服務器的請求消息包括以下格式：請求行（request line）、請求頭部（header）、空行和請求數據四個部分組成，下圖給出了請求報文的一般格式。
（2） 服務器響應消息
HTTP響應也由四個部分組成，分別是：狀態行、消息報頭、空行和響應正文。
（3） 實例
下面實例是一點典型的使用GET來傳遞數據的實例：
客戶端請求：
GET /hello.txt HTTP/1.1 User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3 Host: www.example.com Accept-Language: en, mi服務端響應:
HTTP/1.1 200 OK Date: Mon, 27 Jul 2009 12:28:53 GMT Server: Apache Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT ETag: "34aa387-d-1568eb00" Accept-Ranges: bytes Content-Length: 51 Vary: Accept-Encoding Content-Type: text/plain輸出結果：
Hello World! My payload includes a trailing CRLF.4.3.4 HTTP 請求方法
根據 HTTP 標準，HTTP 請求可以使用多種請求方法。
HTTP1.0 定義了三種請求方法： GET, POST 和 HEAD方法。
HTTP1.1 新增了六種請求方法：OPTIONS、PUT、PATCH、DELETE、TRACE 和 CONNECT 方法。
| 1 | GET | 請求指定的頁面信息，并返回實體主體。 |
| 2 | HEAD | 類似于 GET 請求，只不過返回的響應中沒有具體的內容，用于獲取報頭 |
| 3 | POST | 向指定資源提交數據進行處理請求（例如提交表單或者上傳文件）。數據被包含在請求體中。POST 請求可能會導致新的資源的建立和/或已有資源的修改。 |
| 4 | PUT | 從客戶端向服務器傳送的數據取代指定的文檔的內容。 |
| 5 | DELETE | 請求服務器刪除指定的頁面。 |
| 6 | CONNECT | HTTP/1.1 協議中預留給能夠將連接改為管道方式的代理服務器。 |
| 7 | OPTIONS | 允許客戶端查看服務器的性能。 |
| 8 | TRACE | 回顯服務器收到的請求，主要用于測試或診斷。 |
| 9 | PATCH | 是對 PUT 方法的補充，用來對已知資源進行局部更新 。 |
4.3.5?HTTP 響應頭信息
HTTP請求頭提供了關于請求，響應或者其他的發送實體的信息。
在本章節中我們將具體來介紹HTTP響應頭信息。
| Allow | 服務器支持哪些請求方法（如GET、POST等）。 |
| Content-Encoding | 文檔的編碼（Encode）方法。只有在解碼之后才可以得到Content-Type頭指定的內容類型。利用gzip壓縮文檔能夠顯著地減少HTML文檔的下載時間。Java的GZIPOutputStream可以很方便地進行gzip壓縮，但只有Unix上的Netscape和Windows上的IE 4、IE 5才支持它。因此，Servlet應該通過查看Accept-Encoding頭（即request.getHeader("Accept-Encoding")）檢查瀏覽器是否支持gzip，為支持gzip的瀏覽器返回經gzip壓縮的HTML頁面，為其他瀏覽器返回普通頁面。 |
| Content-Length | 表示內容長度。只有當瀏覽器使用持久HTTP連接時才需要這個數據。如果你想要利用持久連接的優勢，可以把輸出文檔寫入 ByteArrayOutputStream，完成后查看其大小，然后把該值放入Content-Length頭，最后通過byteArrayStream.writeTo(response.getOutputStream()發送內容。 |
| Content-Type | 表示后面的文檔屬于什么MIME類型。Servlet默認為text/plain，但通常需要顯式地指定為text/html。由于經常要設置Content-Type，因此HttpServletResponse提供了一個專用的方法setContentType。 |
| Date | 當前的GMT時間。你可以用setDateHeader來設置這個頭以避免轉換時間格式的麻煩。 |
| Expires | 應該在什么時候認為文檔已經過期，從而不再緩存它？ |
| Last-Modified | 文檔的最后改動時間。客戶可以通過If-Modified-Since請求頭提供一個日期，該請求將被視為一個條件GET，只有改動時間遲于指定時間的文檔才會返回，否則返回一個304（Not Modified）狀態。Last-Modified也可用setDateHeader方法來設置。 |
| Location | 表示客戶應當到哪里去提取文檔。Location通常不是直接設置的，而是通過HttpServletResponse的sendRedirect方法，該方法同時設置狀態代碼為302。 |
| Refresh | 表示瀏覽器應該在多少時間之后刷新文檔，以秒計。除了刷新當前文檔之外，你還可以通過setHeader("Refresh", "5; URL=http://host/path")讓瀏覽器讀取指定的頁面。 |
| Server | 服務器名字。Servlet一般不設置這個值，而是由Web服務器自己設置。 |
| Set-Cookie | 設置和頁面關聯的Cookie。Servlet不應使用response.setHeader("Set-Cookie", ...)，而是應使用HttpServletResponse提供的專用方法addCookie。參見下文有關Cookie設置的討論。 |
| WWW-Authenticate | 客戶應該在Authorization頭中提供什么類型的授權信息？在包含401（Unauthorized）狀態行的應答中這個頭是必需的。例如，response.setHeader("WWW-Authenticate", "BASIC realm=＼"executives＼"")。 |
4.3.6 HTTP狀態碼
當瀏覽者訪問一個網頁時，瀏覽者的瀏覽器會向網頁所在服務器發出請求。當瀏覽器接收并顯示網頁前，此網頁所在的服務器會返回一個包含HTTP狀態碼的信息頭（server header）用以響應瀏覽器的請求。
HTTP狀態碼的英文為HTTP Status Code。
下面是常見的HTTP狀態碼：
- 200 - 請求成功
- 301 - 資源（網頁等）被永久轉移到其它URL
- 404 - 請求的資源（網頁等）不存在
- 500 - 內部服務器錯誤
4.3.7 HTTP狀態碼分類
HTTP狀態碼由三個十進制數字組成，第一個十進制數字定義了狀態碼的類型，后兩個數字沒有分類的作用。HTTP狀態碼共分為5種類型：
| 1** | 信息，服務器收到請求，需要請求者繼續執行操作 |
| 2** | 成功，操作被成功接收并處理 |
| 3** | 重定向，需要進一步的操作以完成請求 |
| 4** | 客戶端錯誤，請求包含語法錯誤或無法完成請求 |
| 5** | 服務器錯誤，服務器在處理請求的過程中發生了錯誤 |
HTTP狀態碼列表:
| 100 | Continue | 繼續。客戶端應繼續其請求 |
| 101 | Switching Protocols | 切換協議。服務器根據客戶端的請求切換協議。只能切換到更高級的協議，例如，切換到HTTP的新版本協議 |
| ? | ||
| 200 | OK | 請求成功。一般用于GET與POST請求 |
| 201 | Created | 已創建。成功請求并創建了新的資源 |
| 202 | Accepted | 已接受。已經接受請求，但未處理完成 |
| 203 | Non-Authoritative Information | 非授權信息。請求成功。但返回的meta信息不在原始的服務器，而是一個副本 |
| 204 | No Content | 無內容。服務器成功處理，但未返回內容。在未更新網頁的情況下，可確保瀏覽器繼續顯示當前文檔 |
| 205 | Reset Content | 重置內容。服務器處理成功，用戶終端（例如：瀏覽器）應重置文檔視圖。可通過此返回碼清除瀏覽器的表單域 |
| 206 | Partial Content | 部分內容。服務器成功處理了部分GET請求 |
| ? | ||
| 300 | Multiple Choices | 多種選擇。請求的資源可包括多個位置，相應可返回一個資源特征與地址的列表用于用戶終端（例如：瀏覽器）選擇 |
| 301 | Moved Permanently | 永久移動。請求的資源已被永久的移動到新URI，返回信息會包括新的URI，瀏覽器會自動定向到新URI。今后任何新的請求都應使用新的URI代替 |
| 302 | Found | 臨時移動。與301類似。但資源只是臨時被移動。客戶端應繼續使用原有URI |
| 303 | See Other | 查看其它地址。與301類似。使用GET和POST請求查看 |
| 304 | Not Modified | 未修改。所請求的資源未修改，服務器返回此狀態碼時，不會返回任何資源。客戶端通常會緩存訪問過的資源，通過提供一個頭信息指出客戶端希望只返回在指定日期之后修改的資源 |
| 305 | Use Proxy | 使用代理。所請求的資源必須通過代理訪問 |
| 306 | Unused | 已經被廢棄的HTTP狀態碼 |
| 307 | Temporary Redirect | 臨時重定向。與302類似。使用GET請求重定向 |
| ? | ||
| 400 | Bad Request | 客戶端請求的語法錯誤，服務器無法理解 |
| 401 | Unauthorized | 請求要求用戶的身份認證 |
| 402 | Payment Required | 保留，將來使用 |
| 403 | Forbidden | 服務器理解請求客戶端的請求，但是拒絕執行此請求 |
| 404 | Not Found | 服務器無法根據客戶端的請求找到資源（網頁）。通過此代碼，網站設計人員可設置"您所請求的資源無法找到"的個性頁面 |
| 405 | Method Not Allowed | 客戶端請求中的方法被禁止 |
| 406 | Not Acceptable | 服務器無法根據客戶端請求的內容特性完成請求 |
| 407 | Proxy Authentication Required | 請求要求代理的身份認證，與401類似，但請求者應當使用代理進行授權 |
| 408 | Request Time-out | 服務器等待客戶端發送的請求時間過長，超時 |
| 409 | Conflict | 服務器完成客戶端的 PUT 請求時可能返回此代碼，服務器處理請求時發生了沖突 |
| 410 | Gone | 客戶端請求的資源已經不存在。410不同于404，如果資源以前有現在被永久刪除了可使用410代碼，網站設計人員可通過301代碼指定資源的新位置 |
| 411 | Length Required | 服務器無法處理客戶端發送的不帶Content-Length的請求信息 |
| 412 | Precondition Failed | 客戶端請求信息的先決條件錯誤 |
| 413 | Request Entity Too Large | 由于請求的實體過大，服務器無法處理，因此拒絕請求。為防止客戶端的連續請求，服務器可能會關閉連接。如果只是服務器暫時無法處理，則會包含一個Retry-After的響應信息 |
| 414 | Request-URI Too Large | 請求的URI過長（URI通常為網址），服務器無法處理 |
| 415 | Unsupported Media Type | 服務器無法處理請求附帶的媒體格式 |
| 416 | Requested range not satisfiable | 客戶端請求的范圍無效 |
| 417 | Expectation Failed | 服務器無法滿足Expect的請求頭信息 |
| ? | ||
| 500 | Internal Server Error | 服務器內部錯誤，無法完成請求 |
| 501 | Not Implemented | 服務器不支持請求的功能，無法完成請求 |
| 502 | Bad Gateway | 作為網關或者代理工作的服務器嘗試執行請求時，從遠程服務器接收到了一個無效的響應 |
| 503 | Service Unavailable | 由于超載或系統維護，服務器暫時的無法處理客戶端的請求。延時的長度可包含在服務器的Retry-After頭信息中 |
| 504 | Gateway Time-out | 充當網關或代理的服務器，未及時從遠端服務器獲取請求 |
| 505 | HTTP Version not supported | 服務器不支持請求的HTTP協議的版本，無法完成處理 |
4.3.8 HTTP content-type
Content-Type（內容類型），一般是指網頁中存在的 Content-Type，用于定義網絡文件的類型和網頁的編碼，決定瀏覽器將以什么形式、什么編碼讀取這個文件，這就是經常看到一些 PHP 網頁點擊的結果卻是下載一個文件或一張圖片的原因。
Content-Type 標頭告訴客戶端實際返回的內容的內容類型。
語法格式：
Content-Type: text/html; charset=utf-8 Content-Type: multipart/form-data; boundary=something實例：
常見的媒體格式類型如下：
- text/html ： HTML格式
- text/plain ：純文本格式
- text/xml ： XML格式
- image/gif ：gif圖片格式
- image/jpeg ：jpg圖片格式
- image/png：png圖片格式
以application開頭的媒體格式類型：
- application/xhtml+xml ：XHTML格式
- application/xml： XML數據格式
- application/atom+xml ：Atom XML聚合格式
- application/json： JSON數據格式
- application/pdf：pdf格式
- application/msword ： Word文檔格式
- application/octet-stream ： 二進制流數據（如常見的文件下載）
- application/x-www-form-urlencoded ： <form encType=””>中默認的encType，form表單數據被編碼為key/value格式發送到服務器（表單默認的提交數據的格式）
另外一種常見的媒體格式是上傳文件之時使用的：
- multipart/form-data ： 需要在表單中進行文件上傳時，就需要使用該格式
HTTP content-type 對照表
| .*（ 二進制流，不知道下載文件類型） | application/octet-stream | .tif | image/tiff |
| .001 | application/x-001 | .301 | application/x-301 |
| .323 | text/h323 | .906 | application/x-906 |
| .907 | drawing/907 | .a11 | application/x-a11 |
| .acp | audio/x-mei-aac | .ai | application/postscript |
| .aif | audio/aiff | .aifc | audio/aiff |
| .aiff | audio/aiff | .anv | application/x-anv |
| .asa | text/asa | .asf | video/x-ms-asf |
| .asp | text/asp | .asx | video/x-ms-asf |
| .au | audio/basic | .avi | video/avi |
| .awf | application/vnd.adobe.workflow | .biz | text/xml |
| .bmp | application/x-bmp | .bot | application/x-bot |
| .c4t | application/x-c4t | .c90 | application/x-c90 |
| .cal | application/x-cals | .cat | application/vnd.ms-pki.seccat |
| .cdf | application/x-netcdf | .cdr | application/x-cdr |
| .cel | application/x-cel | .cer | application/x-x509-ca-cert |
| .cg4 | application/x-g4 | .cgm | application/x-cgm |
| .cit | application/x-cit | .class | java/* |
| .cml | text/xml | .cmp | application/x-cmp |
| .cmx | application/x-cmx | .cot | application/x-cot |
| .crl | application/pkix-crl | .crt | application/x-x509-ca-cert |
| .csi | application/x-csi | .css | text/css |
| .cut | application/x-cut | .dbf | application/x-dbf |
| .dbm | application/x-dbm | .dbx | application/x-dbx |
| .dcd | text/xml | .dcx | application/x-dcx |
| .der | application/x-x509-ca-cert | .dgn | application/x-dgn |
| .dib | application/x-dib | .dll | application/x-msdownload |
| .doc | application/msword | .dot | application/msword |
| .drw | application/x-drw | .dtd | text/xml |
| .dwf | Model/vnd.dwf | .dwf | application/x-dwf |
| .dwg | application/x-dwg | .dxb | application/x-dxb |
| .dxf | application/x-dxf | .edn | application/vnd.adobe.edn |
| .emf | application/x-emf | .eml | message/rfc822 |
| .ent | text/xml | .epi | application/x-epi |
| .eps | application/x-ps | .eps | application/postscript |
| .etd | application/x-ebx | .exe | application/x-msdownload |
| .fax | image/fax | .fdf | application/vnd.fdf |
| .fif | application/fractals | .fo | text/xml |
| .frm | application/x-frm | .g4 | application/x-g4 |
| .gbr | application/x-gbr | . | application/x- |
| .gif | image/gif | .gl2 | application/x-gl2 |
| .gp4 | application/x-gp4 | .hgl | application/x-hgl |
| .hmr | application/x-hmr | .hpg | application/x-hpgl |
| .hpl | application/x-hpl | .hqx | application/mac-binhex40 |
| .hrf | application/x-hrf | .hta | application/hta |
| .htc | text/x-component | .htm | text/html |
| .html | text/html | .htt | text/webviewhtml |
| .htx | text/html | .icb | application/x-icb |
| .ico | image/x-icon | .ico | application/x-ico |
| .iff | application/x-iff | .ig4 | application/x-g4 |
| .igs | application/x-igs | .iii | application/x-iphone |
| .img | application/x-img | .ins | application/x-internet-signup |
| .isp | application/x-internet-signup | .IVF | video/x-ivf |
| .java | java/* | .jfif | image/jpeg |
| .jpe | image/jpeg | .jpe | application/x-jpe |
| .jpeg | image/jpeg | .jpg | image/jpeg |
| .jpg | application/x-jpg | .js | application/x-javascript |
| .jsp | text/html | .la1 | audio/x-liquid-file |
| .lar | application/x-laplayer-reg | .latex | application/x-latex |
| .lavs | audio/x-liquid-secure | .lbm | application/x-lbm |
| .lmsff | audio/x-la-lms | .ls | application/x-javascript |
| .ltr | application/x-ltr | .m1v | video/x-mpeg |
| .m2v | video/x-mpeg | .m3u | audio/mpegurl |
| .m4e | video/mpeg4 | .mac | application/x-mac |
| .man | application/x-troff-man | .math | text/xml |
| .mdb | application/msaccess | .mdb | application/x-mdb |
| .mfp | application/x-shockwave-flash | .mht | message/rfc822 |
| .mhtml | message/rfc822 | .mi | application/x-mi |
| .mid | audio/mid | .midi | audio/mid |
| .mil | application/x-mil | .mml | text/xml |
| .mnd | audio/x-musicnet-download | .mns | audio/x-musicnet-stream |
| .mocha | application/x-javascript | .movie | video/x-sgi-movie |
| .mp1 | audio/mp1 | .mp2 | audio/mp2 |
| .mp2v | video/mpeg | .mp3 | audio/mp3 |
| .mp4 | video/mpeg4 | .mpa | video/x-mpg |
| .mpd | application/vnd.ms-project | .mpe | video/x-mpeg |
| .mpeg | video/mpg | .mpg | video/mpg |
| .mpga | audio/rn-mpeg | .mpp | application/vnd.ms-project |
| .mps | video/x-mpeg | .mpt | application/vnd.ms-project |
| .mpv | video/mpg | .mpv2 | video/mpeg |
| .mpw | application/vnd.ms-project | .mpx | application/vnd.ms-project |
| .mtx | text/xml | .mxp | application/x-mmxp |
| .net | image/pnetvue | .nrf | application/x-nrf |
| .nws | message/rfc822 | .odc | text/x-ms-odc |
| .out | application/x-out | .p10 | application/pkcs10 |
| .p12 | application/x-pkcs12 | .p7b | application/x-pkcs7-certificates |
| .p7c | application/pkcs7-mime | .p7m | application/pkcs7-mime |
| .p7r | application/x-pkcs7-certreqresp | .p7s | application/pkcs7-signature |
| .pc5 | application/x-pc5 | .pci | application/x-pci |
| .pcl | application/x-pcl | .pcx | application/x-pcx |
| application/pdf | application/pdf | ||
| .pdx | application/vnd.adobe.pdx | .pfx | application/x-pkcs12 |
| .pgl | application/x-pgl | .pic | application/x-pic |
| .pko | application/vnd.ms-pki.pko | .pl | application/x-perl |
| .plg | text/html | .pls | audio/scpls |
| .plt | application/x-plt | .png | image/png |
| .png | application/x-png | .pot | application/vnd.ms-powerpoint |
| .ppa | application/vnd.ms-powerpoint | .ppm | application/x-ppm |
| .pps | application/vnd.ms-powerpoint | .ppt | application/vnd.ms-powerpoint |
| .ppt | application/x-ppt | .pr | application/x-pr |
| .prf | application/pics-rules | .prn | application/x-prn |
| .prt | application/x-prt | .ps | application/x-ps |
| .ps | application/postscript | .ptn | application/x-ptn |
| .pwz | application/vnd.ms-powerpoint | .r3t | text/vnd.rn-realtext3d |
| .ra | audio/vnd.rn-realaudio | .ram | audio/x-pn-realaudio |
| .ras | application/x-ras | .rat | application/rat-file |
| .rdf | text/xml | .rec | application/vnd.rn-recording |
| .red | application/x-red | .rgb | application/x-rgb |
| .rjs | application/vnd.rn-realsystem-rjs | .rjt | application/vnd.rn-realsystem-rjt |
| .rlc | application/x-rlc | .rle | application/x-rle |
| .rm | application/vnd.rn-realmedia | .rmf | application/vnd.adobe.rmf |
| .rmi | audio/mid | .rmj | application/vnd.rn-realsystem-rmj |
| .rmm | audio/x-pn-realaudio | .rmp | application/vnd.rn-rn_music_package |
| .rms | application/vnd.rn-realmedia-secure | .rmvb | application/vnd.rn-realmedia-vbr |
| .rmx | application/vnd.rn-realsystem-rmx | .rnx | application/vnd.rn-realplayer |
| .rp | image/vnd.rn-realpix | .rpm | audio/x-pn-realaudio-plugin |
| .rsml | application/vnd.rn-rsml | .rt | text/vnd.rn-realtext |
| .rtf | application/msword | .rtf | application/x-rtf |
| .rv | video/vnd.rn-realvideo | .sam | application/x-sam |
| .sat | application/x-sat | .sdp | application/sdp |
| .sdw | application/x-sdw | .sit | application/x-stuffit |
| .slb | application/x-slb | .sld | application/x-sld |
| .slk | drawing/x-slk | .smi | application/smil |
| .smil | application/smil | .smk | application/x-smk |
| .snd | audio/basic | .sol | text/plain |
| .sor | text/plain | .spc | application/x-pkcs7-certificates |
| .spl | application/futuresplash | .spp | text/xml |
| .ssm | application/streamingmedia | .sst | application/vnd.ms-pki.certstore |
| .stl | application/vnd.ms-pki.stl | .stm | text/html |
| .sty | application/x-sty | .svg | text/xml |
| .swf | application/x-shockwave-flash | .tdf | application/x-tdf |
| .tg4 | application/x-tg4 | .tga | application/x-tga |
| .tif | image/tiff | .tif | application/x-tif |
| .tiff | image/tiff | .tld | text/xml |
| .top | drawing/x-top | .torrent | application/x-bittorrent |
| .tsd | text/xml | .txt | text/plain |
| .uin | application/x-icq | .uls | text/iuls |
| .vcf | text/x-vcard | .vda | application/x-vda |
| .vdx | application/vnd.visio | .vml | text/xml |
| .vpg | application/x-vpeg005 | .vsd | application/vnd.visio |
| .vsd | application/x-vsd | .vss | application/vnd.visio |
| .vst | application/vnd.visio | .vst | application/x-vst |
| .vsw | application/vnd.visio | .vsx | application/vnd.visio |
| .vtx | application/vnd.visio | .vxml | text/xml |
| .wav | audio/wav | .wax | audio/x-ms-wax |
| .wb1 | application/x-wb1 | .wb2 | application/x-wb2 |
| .wb3 | application/x-wb3 | .wbmp | image/vnd.wap.wbmp |
| .wiz | application/msword | .wk3 | application/x-wk3 |
| .wk4 | application/x-wk4 | .wkq | application/x-wkq |
| .wks | application/x-wks | .wm | video/x-ms-wm |
| .wma | audio/x-ms-wma | .wmd | application/x-ms-wmd |
| .wmf | application/x-wmf | .wml | text/vnd.wap.wml |
| .wmv | video/x-ms-wmv | .wmx | video/x-ms-wmx |
| .wmz | application/x-ms-wmz | .wp6 | application/x-wp6 |
| .wpd | application/x-wpd | .wpg | application/x-wpg |
| .wpl | application/vnd.ms-wpl | .wq1 | application/x-wq1 |
| .wr1 | application/x-wr1 | .wri | application/x-wri |
| .wrk | application/x-wrk | .ws | application/x-ws |
| .ws2 | application/x-ws | .wsc | text/scriptlet |
| .wsdl | text/xml | .wvx | video/x-ms-wvx |
| .xdp | application/vnd.adobe.xdp | .xdr | text/xml |
| .xfd | application/vnd.adobe.xfd | .xfdf | application/vnd.adobe.xfdf |
| .xhtml | text/html | .xls | application/vnd.ms-excel |
| .xls | application/x-xls | .xlw | application/x-xlw |
| .xml | text/xml | .xpl | audio/scpls |
| .xq | text/xml | .xql | text/xml |
| .xquery | text/xml | .xsd | text/xml |
| .xsl | text/xml | .xslt | text/xml |
| .xwd | application/x-xwd | .x_b | application/x-x_b |
| .sis | application/vnd.symbian.install | .sisx | application/vnd.symbian.install |
| .x_t | application/x-x_t | .ipa | application/vnd.iphone |
| .apk | application/vnd.android.package-archive | .xap | application/x-silverlight-app |
5.補充
5.1 路由
發送數據包時所使用的地址是網絡層的地址，即 IP 地址。然而僅僅有 IP 地址還不足以實現將數據包發送到對端目標地址，在數據發送過程中還需要類似于“指明路由器或主機”的信息，以便真正發往目標地址。保存這種信息的就是路由控制表。
該路由控制表的形成方式有兩種：一種是管理員手動設置，另一種是路由器與其他路由器相互交換信息時自動刷新。前者也叫做靜態路由控制，而后者叫做動態路由控制。
IP 協議始終認為路由表是正確的。然后，IP 本身并沒有定義制作路由控制表的協議。即 IP 沒有制作路由控制表的機制。該表示由一個叫做“路由協議”的協議制作而成。
5.2 IP 地址與路由控制
IP 地址的網絡地址部分用于進行路由控制。
路由控制表中記錄著網絡地址與下一步應該發送至路由器的地址。
在發送 IP 包時，首先要確定 IP 包首部中的目標地址，再從路由控制表中找到與該地址具有相同網絡地址的記錄，根據該記錄將 IP 包轉發給相應的下一個路由器。如果路由控制表中存在多條相同網絡地址的記錄，就選擇一個最為吻合的網絡地址。
5.3?IP 分包與組包
每種數據鏈路的最大傳輸單元（MTU）都不盡相同，因為每個不同類型的數據鏈路的使用目的不同。使用目的不同，可承載的 MTU 也就不同。
任何一臺主機都有必要對 IP 分片進行相應的處理。分片往往在網絡上遇到比較大的報文無法一下子發送出去時才會進行處理。
經過分片之后的 IP 數據報在被重組的時候，只能由目標主機進行。路由器雖然做分片但不會進行重組。
5.3.1 路徑 MTU 發現
分片機制也有它的不足。如路由器的處理負荷加重之類。因此，只要允許，是不希望由路由器進行 IP 數據包的分片處理的。
為了應對分片機制的不足，“路徑 MTU 發現” 技術應運而生。路徑 MTU 指的是，從發送端主機到接收端主機之間不需要分片是最大 MTU 的大小。即路徑中存在的所有數據鏈路中最小的 MTU 。
進行路徑 MTU 發現，就可以避免在中途的路由器上進行分片處理，也可以在 TCP 中發送更大的包。
5.4 IPv6
IPv6（IP version 6）是為了根本解決 IPv4 地址耗盡的問題而被標準化的網際協議。IPv4 的地址長度為 4 個 8 位字節，即 32 比特。而 IPv6 的地址長度則是原來的 4 倍，即 128 比特，一般寫成 8 個 16 位字節。
5.4.1 IPv6 的特點
IP 得知的擴大與路由控制表的聚合。
性能提升。包首部長度采用固定的值（40字節），不再采用首部檢驗碼。簡化首部結構，減輕路由器負擔。路由器不再做分片處理。
支持即插即用功能。即使沒有DHCP服務器也可以實現自動分配 IP 地址。
采用認證與加密功能。應對偽造 IP 地址的網絡安全功能以及防止線路竊聽的功能。
多播、Mobile IP 成為擴展功能。
5.4.2 IPv6 中 IP 地址的標記方法
一般人們將 128 比特 IP 地址以每 16 比特為一組，每組用冒號（“：”）隔開進行標記。
而且如果出現連續的 0 時還可以將這些 0 省略，并用兩個冒號（“：：”）隔開。但是，一個 IP 地址中只允許出現一次兩個連續的冒號。
5.4.3 IPv6 地址的結構
IPv6 類似 IPv4，也是通過 IP 地址的前幾位標識 IP 地址的種類。
在互聯網通信中，使用一種全局的單播地址。它是互聯網中唯一的一個地址，不需要正式分配 IP 地址。
5.4.4 全局單播地址
全局單播地址是指世界上唯一的一個地址。它是互聯網通信以及各個域內部通信中最為常用的一個 IPv6 地址。
格式如下圖所示，現在 IPv6 的網絡中所使用的格式為，n = 48，m = 16 以及 128 - n - m = 64。即前 64 比特為網絡標識，后 64 比特為主機標識。
5.4.5 鏈路本地單播地址
鏈路本地單播地址是指在同一個數據鏈路內唯一的地址。它用于不經過路由器，在同一個鏈路中的通信。通常接口 ID 保存 64 比特版的 MAC 地址。
5.4.6 唯一本地地址
- 唯一本地地址是不進行互聯網通信時所用的地址。
- 唯一本地地址雖然不會與互聯網連接，但是也會盡可能地隨機生成一個唯一的全局 ID。
- L 通常被置為 1。
- 全局 ID 的值隨機決定。
- 子網 ID 是指該域子網地址。
- 接口 ID 即為接口的 ID。
5.4.7 IPv6 分段處理
IPv6 的分片處理只在作為起點的發送端主機上進行，路由器不參與分片。
IPv6 中最小 MTU 為 1280 字節，因此，在嵌入式系統中對于那些有一定系統資源限制的設備來說，不需要進行“路徑 MTU 發現”，而是在發送 IP 包時直接以 1280 字節為單位分片送出。
6. 小結
分析再多協議，即使看懂，不去實際使用一下還是模棱兩可，更看不出來網絡層的實際作用，各個協議完成的工作。
?
?
?
?
?
?
?
?
?
總結
以上是生活随笔為你收集整理的基础（网络知识 三）——网络系统各层协议分析总结（TCP/IP/UDP/HTTP.....）的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 自己动手写股票数据分析软件之数据获取
- 下一篇： 系统可行性研究