ARP 協議（Address Resolution Protocol）一種以解析地址的協議，根據通信雙方的 IP 地址就可以查出對應的 MAC 地址。
MAC（ Media Access Control Address）地址是指網卡所屬的固定的地址
MIME，多部分對象集合（Multipurpose Internet Mail Extensions，多用途因特網郵件擴展），它是一種允許處理文本、圖片、視頻等多種不同類型的數據。

第一章：了解 Web 及網絡基礎

在瀏覽器地址欄輸入 URL 時，可以看到 Web 頁面。當然 Web 頁面是不能憑空顯示出來，它需要根據指定的 URL 到服務器獲取文件資源，然后讓瀏覽器顯示 Web 頁面。

Web 使用一種名為 HTTP 的協議作為規范。HTTP 全稱 HyperText Transfer Protocol，超文本傳輸協議。

網絡基礎 TCP/IP

TCP/IP 協議族

什么是協議？
定義如何探測到通信目標，由哪一方發起通信，使用什么語言通信，怎樣結束通信，不同的硬件、操作系統之間的通信的規則。

TCP/IP 是互聯網相關的各類協議族的總稱，包括各式內容，從電纜規格到 IP 地址的選定方法、尋找異地用戶的方法、雙方建立通信的順序、以及 Web 頁面顯示需要處理的步驟等

TCP/IP 的分層管理

TCP/IP 協議族分為4層：應用層、傳輸層、網絡層和數據鏈路層
作用:

• 應用層：決定了向用戶提供應用服務時通信的活動，HTTP 協議也處于該層
• 傳輸層：對上層應用層，提供處于網絡連接中的兩臺計算機之間的數據傳輸
• 網絡層：又名網絡互聯層，用來處理在網絡上流動的數據包
• 鏈路層：又名數據鏈路層、網絡接口層，用來處理連接網絡硬件部分（屬于硬件范圍）

TCP/IP 通信傳輸流

利用 TCP/IP 協議族進行網絡通信時，發送端（客戶端）從應用層往下走，接收端（服務端）從鏈路層網上走

用 HTTP 舉例：

應用層（發送端）發送 HTTP 請求

傳輸層（TCP協議）把從應用層接收到的數據（HTTP報文）進行分割，并在各個報文上打上標記序號及端口號后發給網絡層

在網絡層（IP協議）增加作為通信目的的 MAC 地址后轉發給鏈路層（發往網絡的通信請求就準備齊全了）

接收端在鏈路層接收到數據，按序網上層發送，達到應用層后，才能算真正接收到發送端發過來的請求

發送端在每層之間傳輸時，會打上該層所屬的首部信息；接收端在曾與層之間傳輸時，每經過一層會刪除對應的首部信息。
這種把數據包轉起來的做法叫做封裝

與 HTTP 關系密切的協議：IP、TCP 和 DNS

負責傳輸的 IP 協議

TCP/IP 協議族中的 IP 指的是網際協議。IP 協議的作用是把各種數據包傳送給對方，要保證確實傳送到對方哪里，需要滿足各類條件。其中兩個重要條件是 IP 地址和 MAC 地址（Media Access Control Address）。

IP 地址指明了節點被分配到的地址，MAC 地址是指網卡所屬的固定的地址。IP 地址可以和 MAC 地址進行配對。IP 地址可變換，MAC 地址基本不會變。

使用 ARP 協議憑借 MAC 地址進行通信

IP 間的通信依賴 MAC 地址。在網絡上，通常是經過多臺計算機和網絡設備中轉才能連接到對方，在中轉時，會利用下一站中轉設備的 MAC 地址來搜索下一個中轉目標，這是會采用 ARP 協議
（Address Resolution Protocol）。ARP 協議是一種以解析地址的協議，根據通信雙方的 IP 地址就可以查出對應的 MAC 地址。

確保可靠的 TCP 協議

TCP 協議位于傳輸層，提供可靠的字節流服務，所謂字節流服務是將大塊數據分割層以報文段為單位的數據包進行管理，方便傳輸。

為了確保準確無誤的送達目的地，TCP 采用三次握手策略，數據發送出去之后，一定的會向對方確認是否成功送達。握手的過程中采用 TCP 的標志——SYN（synchronize）和 ACK（acknowledgement）。

發送端首先發送一個帶 SYN 標志的數據包給對方；接收端收到后，回傳一個帶有 SYN/ACK 標志的數據包以示表達確認信息，最后發送端在回傳一個帶 ACK 標志的數據包，代表握手結束。

如果某個階段莫名結束，TCP 協議會再次以相同順序發送相同的數據包。

負責域名解析的 DNS 服務

DNS（Domain Name System）服務是和 HTTP 協議一樣位于應用層的協議。它提供域名到 IP 地址之間的解析服務。

用戶通常通過域名來訪問網站，相比于 IP 地址，域名更符合人類的記憶習慣。DNS 服務便應運而生，逆向從 IP 地址反查域名服務。

各協議與 HTTP 協議的關系

URI 和 URL

URI（Uniform Resource Identifier）統一資源標識符
URL（Uniform Resource Locator）統一資源定位符

• 登錄信息：指定用戶名和密碼作為服務器端獲取資源時必要的登錄信息（可選）
• 服務器地址：必須指定待訪問的服務器地址
• 服務器端口號：指定服務器連接的網絡端口號（可選，省略的話使用默認端口號）
• 帶層次的文件路徑：指定服務器上的文件路徑來定位特指的資源
• 查詢字符串：針對已指定的文件路徑內的資源，可以使用查詢字符串傳入任意參數（可選）
• 片斷標識符：使用片段標識符通常可標記出以獲取資源中的資資源（可選）

第二章：簡單的 HTTP 協議

請求訪問文本或圖像等資源的一端稱為客戶端，提供資源響應的一端稱為服務器端。

HTTP 協議規定，請求從客戶端發出，服務端響應該請求并返回。

請求報文是由請求方法、請求URI、協議版本、可選的請求首部字段和內容實體構成的。

響應報文基本上由協議版本、狀態碼（表示成功或失敗的代碼）、以及解釋狀態碼的原因短語、可選的響應首部字段以及實體主體構成。

HTTP 不保存狀態協議

HTTP 是一種不保存狀態，即無狀態協議。它自身不具備保存之前發送過的請求或響應的功能，為了實現保持狀態的功能，引入了 Cookie 技術。

告知服務器意圖的 HTTP 方法

方法用途備注

GET	獲取資源
POST	傳輸實體主體
PUT	傳輸文件
HEAD	獲取報文首部
DELETE	刪除文件	響應返回的狀態碼是 204
OPTIONS	詢問支持的方法
TRACE	追蹤路徑
CONNECT	要求用隧道協議連接代理

向請求 URI 指定的資源發送請求報文時，采用稱為方法的命令。方法名要用大寫字母。

持久連接節省通信量

在 HTTP 初始版本中，由于傳輸數據容量比較小，每進行一次 HTTP 通信就要斷開一次 TCP 連接；
隨著 HTTP 普及，傳輸數據越來越大，未解決 TCP 連接問題，引入了持久連接（HTTP Persistent Connections，也成為 HTTP keep-alive 或 HTTP connection reuse），特點是：只要任意一端沒有明確提出斷開連接，則保持 TCP 連接狀態。

管線化

持久化連接是的多數請求以管線化方式發送稱為可能，可以同時并行發送多個請求，而不需要一個接一個等待響應。

使用 Cookie 的狀態管理

Cookie 技術通過在請求和響應報文中寫入 Cookie 信息來控制客戶端的狀態。
服務器在接受到請求后，在響應報文內加入 Set-Cookie，通知客戶端保存 Cookie，當下次在發送請求時，會在請求報文中加入 Cookie 后發送出去。服務器在根據發送過來的 Cookie 去對比，從而保存狀態信息。

第三章：HTTP 報文內的 HTTP 信息

用于 HTTP 協議交互的信息被稱為 HTTP 報文，請求端（客戶端）的報文叫做請求報文，響應端（服務端）的叫做響應報文。

請求報文及響應報文的結構

HTTP 報文 大致可分為報文首部和報文主體，兩者之間由空行（CR+LF）來劃分。
請求報文

響應報文

• 請求行：包含用于請求的方法，請求 URI 和 HTTP 版本
• 狀態行：包含表明響應結果的狀態碼，原因短語和 HTTP 版本
• 首部字段：包含表明請求和響應的各種條件和屬性的各類首部，一般有4種首部：通用首部、請求首部、響應首部、實體首部
• 其他：可能包含 HTTP 的 RFC 里未定義 的首部，如：Cookie

編碼提升傳輸速率

HTTP 在傳輸數據時可以按照數據原貌直接傳輸，也可以在傳輸時通過編碼提升傳輸速率，但這樣會消耗更多的 CPU 等資源

報文主體和實體主體的差異

• 報文：是 HTTP 通信中的基本單位，由8位組字節流（octet sequence，其中 octet 為8個比特）組成，通過 HTTP 通信傳輸。
• 實體：作為請求或響應的有效載荷數據（補充項）被傳輸，其內容由實體首部和實體主體組成。

通常報文主體等于實體主體，只有當傳輸中進行編碼操作時，實體主體的內容發生變化才會導致它和報文主體產生差異。

壓縮傳輸的內容編碼

內容編碼指明應用在實體內容上的編碼格式，并保存實體信息原樣壓縮。內容編碼后的實體由客戶端接收并負責編碼。

常用的內容編碼

• gzip(GNU zip)
• compress(UNIX 系統的標準壓縮)
• deflate(zlib)
• identity(不進行編碼)

分割發送的分塊傳輸編碼

在 HTTP 通信過程中，在傳輸大容量數據時，通過把數據分割成多塊，能夠讓瀏覽器逐步顯示頁面的功能稱為分塊傳輸編碼（Chunked Transfer Coding）。

發送多種數據的多部分對象集合

HTTP 協議采用了多部分對象集合——MIME機制（Multipurpose Internet Mail Extensions，多用途因特網郵件擴展），它是一種允許處理文本、圖片、視頻等多種不同類型的數據。

在 HTTP 報文中使用 多部分對象集合時，需要在首部字段里加上 Content-type，使用 boundary 字符串來劃分各個實體的起始行，需要在起始行前插入 "--" 標記，，最后以 "--" 結束。

獲取部分內容的范圍請求

指定范圍發送的請求叫做范圍請求

執行范圍請求會用到首部字段 Range 來指定資源的 byte 范圍

請求： Range: bytes = 5001-10000響應： Content-Range: bytes 5001-10000/10000

針對范圍請求，響應會返回狀態碼為 206 Partial Content 的響應報文，如果服務器無法響應范圍請求，則會返回狀態碼 200 OK 和完成的實體內容。

內容協商返回最合適的內容

同一個 Web 網站可能會存在多份相同內容的頁面，比如英文版和中文版，當瀏覽器默認語言為中文時，訪問 URI 的 Web 頁面時，則會顯示中文版的 Web 頁面，這種機制稱為內容協商（Content Negotiation）。

內容協商機制會在請求報文中用到下面首部字段：

• Accept
• Accept-Charset
• Accept-Encoding
• Accept-Language
• Content-Language

內容協商技術有3種類型：

• 服務器驅動協商：由服務器端進行內容協商。以請求的首部字段為參考，在服務端自動處理。
• 客戶端驅動協商：由客戶端進行內容協商。用戶利用瀏覽器提供的可選項列表手動選擇；還可以利用 JavaScript 腳本在 Web 頁面上自動進行選擇。
• 透明協商：是服務器驅動和客戶端驅動的結合體，是由服務器端和客戶端各自進行內容協商的一種方法。

第四章：返回結果的 HTTP 狀態碼

狀態碼告知從服務器端返回的請求結果

狀態碼的職責是當客戶端向服務器端發送請求時，描述返回的請求結果。
狀態碼由三位數字和原因短語組成，其中數字第一位指定了相應類別，后兩位無分類。

類別原因短語

1XX	Informational(信息性狀態碼)	接收的請求正在處理
2XX	Success(成功狀態碼)	請求正常處理完畢
3XX	Redirection(重定向狀態碼)	需要進行附加操作以完成請求
4XX	Client Error(客戶端錯誤狀態碼)	服務器無法處理請求
5XX	Server Error(服務器錯誤狀態碼)	服務器處理請求出錯

狀態碼

2XX 成功：表示請求被正常處理了

• 200 OK 表示從客戶端發來的請求在服務器端被正常處理了。
• 204 No Content 請求處理成功，返回的響應報文中不含實體的主體部分
• 206 Partial Content 表示客戶端進行范圍請求

3XX 重定向：表明瀏覽器需要執行某些特殊處理以正確處理請求

• 301 Moved Permanently 永久重定向
• 302 Found 臨時重定向
• 303 See Other 表示由于請求對應的資源存在著另一個 URI，應使用 GET 方法定向獲取請求的資源
• 304 Not Modified 表示客戶端發送附帶條件的請求，服務器端允許請求訪問資源，但因發生請求未滿足條件的情況后，直接返回 304 Not Modified。304 狀態碼返回時，不包含任何響應的主體部分，304 雖然被劃分在 3XX 類別中，但和重定向沒有關系
• 307 Temporary Redirect 臨時重定向，和 302 差不多，它不會把 POST 變成 GET

4XX 客戶端錯誤：表明客戶端發生錯誤的原因所在

• 400 Bad Request：表示請求報文中存在語法錯誤
• 401 Unauthorized：表示發送的請求需要有通過 HTTP 認證的認證信息
• 403 Forbidden：表示請求資源被服務器拒絕了
• 400 Not Found：表示服務器上無法找到請求資源

5XX 服務器錯誤：表明服務器本身發生錯誤

• 500 Internal Server Error：表示服務器在執行請求時發生了錯誤
• 503 Serveice Unavailable：表示服務器暫時處于超負荷或正在停機維護，無法處理請求。

第五章：與 HTTP 協作的 Web 服務器

HTTP/1.1 允許一臺 HTTP 服務器搭建多個 Web 站點
在互聯網上，域名通過 DNS 服務映射到 IP 地址之后訪問目標網站，在相同 IP 下，發送 HTTP 請求時，必須在 Host 首部內完整指定主機名和域名的 URI

通信數據轉發程序：代理、網關、隧道

• 代理：是一種有轉發功能的應用程序，它扮演了位于服務器和客戶端“中間人”的角色
• 網關：網關是轉發其他服務器通信數據的服務器，接受從客戶端發來的請求時，它就像自己擁有資源的源服務器一樣對請求進行處理
• 隧道：相隔甚遠的客戶端和服務器兩者之間進行中轉，并保持雙方通信連接的應用程序

代理

使用代理服務器的理由：利用緩存技術減少網絡帶寬的流量，組織內部針對特定網站的訪問控制，以獲取訪問日志為主要目的

緩存代理：代理轉發時，緩存代理會預先將資源的副本緩存到代理服務器上，當代理再次接收到相同資源的請求時，就可以不從源服務器那里獲取資源，而是將緩存的資源作為響應返回

透明代理：轉發請求或響應時，不對報文做任何加工的代理類型稱為透明代理

網關：

網關能使通信線路上的服務器提供非 HTTP 協議服務。
利用網關能提高通信的安全性

隧道

隧道的目的是確保客戶端能與服務器進行安全的通信，隧道本身不會去解析 HTTP 請求，隧道會在通信雙方斷開連接時結束

保存資源的緩存

緩存是指代理服務器或客戶端本地磁盤內保存的資源副本。利用緩存可減少對源服務器的訪問，因此也節省了通信流量和通信時間。

緩存的有效期

緩存服務器內緩存室友有效期的，如果資源更新，緩存就沒有用了，需要重新獲取新的資源
客戶端的緩存同緩存服務器一樣

第六章：HTTP 首部

HTTP 協議的請求和響應報文中必須必定包含 HTTP 首部。首部內容為請求或響應所需要的信息

HTTP 請求報文由方法、URI、HTTP 版本、HTTP 首部字段等部分構成
HTTP 響應報文由 HTTP 版本、狀態碼、HTTP 首部字段組成

HTTP 首部字段

HTTP 首部字段是構成 HTTP 報文的要素之一。使用首部字段是為了給瀏覽器和服務器提供報文主體大小、所使用的語言、認證信息等內容。

4種 HTTP 首部字段類型

• 通用首部字段：請求報文和響應報文都會使用的首部
• 請求首部字段：從客戶端向服務器端發送請求報文時使用的首部
• 響應首部字段：從服務器端向客戶端返回響應報文時使用的首部
• 實體首部字段：針對請求報文和響應報文的實體部分使用的首部

通用首部字段

首部字段名說明

Cache-Control	控制緩存的行為
Connection	逐跳首部、連接的管理
Date	創建報文的日期時間
Pragma	報文指令
Trailer	報文末端的首部一覽
Transfer-Encoding	指定報文主體的傳輸編碼方式
Upgrade	升級為其他協議
Via	代理服務器的相關信息
Warning	錯誤通知

請求首部字段

首部字段名說明

Accept	用戶代理可處理的媒體類型
Accept-Charset	優先的字符集
Accept-Encoding	優先的內容編碼
Accept-Language	優先的語言（自然語言）
Authorization	Web 認證信息
Expect	期待服務器的特定行為
From	用戶的電子郵箱地址
Host	請求資源所在的服務器
If-Match	比較實體標記（ETag）
If-Modified-Since	比較資源的更新時間
If-None-Match	比較實體標記（與If-Match相反）
If-Range	資源未更新時發送實體 Byte 的范圍請求
If-Unmodified-Since	比較資源的更新時間（與 If-Modified-Since 相反）
Max-Forwards	最大傳輸逐跳數
Proxy-Authorization	代理服務器要求客戶端的認證信息
Range	實體的字節范圍
Referer	對請求中 URI 的原始獲取方
TE	傳輸編碼的優先級
User-Agent	HTTP 客戶端程序的信息

響應首部字段

首部字段名說明

Accept-Ranges	是否接收字節范圍請求
Age	推算資源創建經過時間
ETag	資源的匹配信息
Location	令客戶端重定向至指定 URI
Proxy-Authenticate	代理服務器對客戶端的認證信息
Retry-After	對再次發起請求的時機要求
Server	HTTP 服務器的安裝信息
Vary	代理服務器緩存的管理信息
WWW-Authenticate	服務器對客戶端的認證信息

實體首部字段

首部字段名說明

Allow	資源可支持的 HTTP方法
Content-Encoding	實體主體適用的編碼方式
Content-Language	實體主體的自然語言
Content-Length	實體主體的大小（單位：字節）
Content-Location	替代對應資源的 URI
Content-MD5	實體主體的報文摘要
Content-Range	實體主體的位置范圍
Content-Type	實體主體的媒體類型
Expires	實體主體過期的日期時間
Last-Modified	資源的最后修改日期時間

第七章：確保 Web 安全的 HTTPS

HTTP的缺點：

• 通信使用明文（不加密），內容可能會被竊聽
• 不驗證通信方的身份，因此有可能遭遇偽裝
• 無法證明報文的完整性，所以有可能已遭篡改

通信的加密
HTTP 和 SSL（Secure Socket Layer，安全套連接）或 TLS（Transport Layer Security，安全傳輸層協議）組合使用，被稱為 HTTPS（HTTP Secure，超文本傳輸安全協議）

內容的加密
把 HTTP 報文里所含的內容進行加密，前提需要客戶端和服務器同時具備加密和解密機制

HTTP + 加密 + 認證 + 完整性保護 = HTTPS

未完待續...

總結

以上是生活随笔為你收集整理的《图解 HTTP》读书笔记（未完待续）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。