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

第一章：了解 Web 及網(wǎng)絡(luò)基礎(chǔ)

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

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

網(wǎng)絡(luò)基礎(chǔ) TCP/IP

TCP/IP 協(xié)議族

什么是協(xié)議？
定義如何探測(cè)到通信目標(biāo)，由哪一方發(fā)起通信，使用什么語言通信，怎樣結(jié)束通信，不同的硬件、操作系統(tǒng)之間的通信的規(guī)則。

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

TCP/IP 的分層管理

TCP/IP 協(xié)議族分為4層：應(yīng)用層、傳輸層、網(wǎng)絡(luò)層和數(shù)據(jù)鏈路層
作用:

• 應(yīng)用層：決定了向用戶提供應(yīng)用服務(wù)時(shí)通信的活動(dòng)，HTTP 協(xié)議也處于該層
• 傳輸層：對(duì)上層應(yīng)用層，提供處于網(wǎng)絡(luò)連接中的兩臺(tái)計(jì)算機(jī)之間的數(shù)據(jù)傳輸
• 網(wǎng)絡(luò)層：又名網(wǎng)絡(luò)互聯(lián)層，用來處理在網(wǎng)絡(luò)上流動(dòng)的數(shù)據(jù)包
• 鏈路層：又名數(shù)據(jù)鏈路層、網(wǎng)絡(luò)接口層，用來處理連接網(wǎng)絡(luò)硬件部分（屬于硬件范圍）

TCP/IP 通信傳輸流

利用 TCP/IP 協(xié)議族進(jìn)行網(wǎng)絡(luò)通信時(shí)，發(fā)送端（客戶端）從應(yīng)用層往下走，接收端（服務(wù)端）從鏈路層網(wǎng)上走

用 HTTP 舉例：

應(yīng)用層（發(fā)送端）發(fā)送 HTTP 請(qǐng)求

傳輸層（TCP協(xié)議）把從應(yīng)用層接收到的數(shù)據(jù)（HTTP報(bào)文）進(jìn)行分割，并在各個(gè)報(bào)文上打上標(biāo)記序號(hào)及端口號(hào)后發(fā)給網(wǎng)絡(luò)層

在網(wǎng)絡(luò)層（IP協(xié)議）增加作為通信目的的 MAC 地址后轉(zhuǎn)發(fā)給鏈路層（發(fā)往網(wǎng)絡(luò)的通信請(qǐng)求就準(zhǔn)備齊全了）

接收端在鏈路層接收到數(shù)據(jù)，按序網(wǎng)上層發(fā)送，達(dá)到應(yīng)用層后，才能算真正接收到發(fā)送端發(fā)過來的請(qǐng)求

發(fā)送端在每層之間傳輸時(shí)，會(huì)打上該層所屬的首部信息；接收端在曾與層之間傳輸時(shí)，每經(jīng)過一層會(huì)刪除對(duì)應(yīng)的首部信息。
這種把數(shù)據(jù)包轉(zhuǎn)起來的做法叫做封裝

與 HTTP 關(guān)系密切的協(xié)議：IP、TCP 和 DNS

負(fù)責(zé)傳輸?shù)?IP 協(xié)議

TCP/IP 協(xié)議族中的 IP 指的是網(wǎng)際協(xié)議。IP 協(xié)議的作用是把各種數(shù)據(jù)包傳送給對(duì)方，要保證確實(shí)傳送到對(duì)方哪里，需要滿足各類條件。其中兩個(gè)重要條件是 IP 地址和 MAC 地址（Media Access Control Address）。

IP 地址指明了節(jié)點(diǎn)被分配到的地址，MAC 地址是指網(wǎng)卡所屬的固定的地址。IP 地址可以和 MAC 地址進(jìn)行配對(duì)。IP 地址可變換，MAC 地址基本不會(huì)變。

使用 ARP 協(xié)議憑借 MAC 地址進(jìn)行通信

IP 間的通信依賴 MAC 地址。在網(wǎng)絡(luò)上，通常是經(jīng)過多臺(tái)計(jì)算機(jī)和網(wǎng)絡(luò)設(shè)備中轉(zhuǎn)才能連接到對(duì)方，在中轉(zhuǎn)時(shí)，會(huì)利用下一站中轉(zhuǎn)設(shè)備的 MAC 地址來搜索下一個(gè)中轉(zhuǎn)目標(biāo)，這是會(huì)采用 ARP 協(xié)議
（Address Resolution Protocol）。ARP 協(xié)議是一種以解析地址的協(xié)議，根據(jù)通信雙方的 IP 地址就可以查出對(duì)應(yīng)的 MAC 地址。

確保可靠的 TCP 協(xié)議

TCP 協(xié)議位于傳輸層，提供可靠的字節(jié)流服務(wù)，所謂字節(jié)流服務(wù)是將大塊數(shù)據(jù)分割層以報(bào)文段為單位的數(shù)據(jù)包進(jìn)行管理，方便傳輸。

為了確保準(zhǔn)確無誤的送達(dá)目的地，TCP 采用三次握手策略，數(shù)據(jù)發(fā)送出去之后，一定的會(huì)向?qū)Ψ酱_認(rèn)是否成功送達(dá)。握手的過程中采用 TCP 的標(biāo)志——SYN（synchronize）和 ACK（acknowledgement）。

發(fā)送端首先發(fā)送一個(gè)帶 SYN 標(biāo)志的數(shù)據(jù)包給對(duì)方；接收端收到后，回傳一個(gè)帶有 SYN/ACK 標(biāo)志的數(shù)據(jù)包以示表達(dá)確認(rèn)信息，最后發(fā)送端在回傳一個(gè)帶 ACK 標(biāo)志的數(shù)據(jù)包，代表握手結(jié)束。

如果某個(gè)階段莫名結(jié)束，TCP 協(xié)議會(huì)再次以相同順序發(fā)送相同的數(shù)據(jù)包。

負(fù)責(zé)域名解析的 DNS 服務(wù)

DNS（Domain Name System）服務(wù)是和 HTTP 協(xié)議一樣位于應(yīng)用層的協(xié)議。它提供域名到 IP 地址之間的解析服務(wù)。

用戶通常通過域名來訪問網(wǎng)站，相比于 IP 地址，域名更符合人類的記憶習(xí)慣。DNS 服務(wù)便應(yīng)運(yùn)而生，逆向從 IP 地址反查域名服務(wù)。

各協(xié)議與 HTTP 協(xié)議的關(guān)系

URI 和 URL

URI（Uniform Resource Identifier）統(tǒng)一資源標(biāo)識(shí)符
URL（Uniform Resource Locator）統(tǒng)一資源定位符

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

第二章：簡(jiǎn)單的 HTTP 協(xié)議

請(qǐng)求訪問文本或圖像等資源的一端稱為客戶端，提供資源響應(yīng)的一端稱為服務(wù)器端。

HTTP 協(xié)議規(guī)定，請(qǐng)求從客戶端發(fā)出，服務(wù)端響應(yīng)該請(qǐng)求并返回。

請(qǐng)求報(bào)文是由請(qǐng)求方法、請(qǐng)求URI、協(xié)議版本、可選的請(qǐng)求首部字段和內(nèi)容實(shí)體構(gòu)成的。

響應(yīng)報(bào)文基本上由協(xié)議版本、狀態(tài)碼（表示成功或失敗的代碼）、以及解釋狀態(tài)碼的原因短語、可選的響應(yīng)首部字段以及實(shí)體主體構(gòu)成。

HTTP 不保存狀態(tài)協(xié)議

HTTP 是一種不保存狀態(tài)，即無狀態(tài)協(xié)議。它自身不具備保存之前發(fā)送過的請(qǐng)求或響應(yīng)的功能，為了實(shí)現(xiàn)保持狀態(tài)的功能，引入了 Cookie 技術(shù)。

告知服務(wù)器意圖的 HTTP 方法

方法用途備注

GET	獲取資源
POST	傳輸實(shí)體主體
PUT	傳輸文件
HEAD	獲取報(bào)文首部
DELETE	刪除文件	響應(yīng)返回的狀態(tài)碼是 204
OPTIONS	詢問支持的方法
TRACE	追蹤路徑
CONNECT	要求用隧道協(xié)議連接代理

向請(qǐng)求 URI 指定的資源發(fā)送請(qǐng)求報(bào)文時(shí)，采用稱為方法的命令。方法名要用大寫字母。

持久連接節(jié)省通信量

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

管線化

持久化連接是的多數(shù)請(qǐng)求以管線化方式發(fā)送稱為可能，可以同時(shí)并行發(fā)送多個(gè)請(qǐng)求，而不需要一個(gè)接一個(gè)等待響應(yīng)。

使用 Cookie 的狀態(tài)管理

Cookie 技術(shù)通過在請(qǐng)求和響應(yīng)報(bào)文中寫入 Cookie 信息來控制客戶端的狀態(tài)。
服務(wù)器在接受到請(qǐng)求后，在響應(yīng)報(bào)文內(nèi)加入 Set-Cookie，通知客戶端保存 Cookie，當(dāng)下次在發(fā)送請(qǐng)求時(shí)，會(huì)在請(qǐng)求報(bào)文中加入 Cookie 后發(fā)送出去。服務(wù)器在根據(jù)發(fā)送過來的 Cookie 去對(duì)比，從而保存狀態(tài)信息。

第三章：HTTP 報(bào)文內(nèi)的 HTTP 信息

用于 HTTP 協(xié)議交互的信息被稱為 HTTP 報(bào)文，請(qǐng)求端（客戶端）的報(bào)文叫做請(qǐng)求報(bào)文，響應(yīng)端（服務(wù)端）的叫做響應(yīng)報(bào)文。

請(qǐng)求報(bào)文及響應(yīng)報(bào)文的結(jié)構(gòu)

HTTP 報(bào)文 大致可分為報(bào)文首部和報(bào)文主體，兩者之間由空行（CR+LF）來劃分。
請(qǐng)求報(bào)文

響應(yīng)報(bào)文

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

編碼提升傳輸速率

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

報(bào)文主體和實(shí)體主體的差異

• 報(bào)文：是 HTTP 通信中的基本單位，由8位組字節(jié)流（octet sequence，其中 octet 為8個(gè)比特）組成，通過 HTTP 通信傳輸。
• 實(shí)體：作為請(qǐng)求或響應(yīng)的有效載荷數(shù)據(jù)（補(bǔ)充項(xiàng)）被傳輸，其內(nèi)容由實(shí)體首部和實(shí)體主體組成。

通常報(bào)文主體等于實(shí)體主體，只有當(dāng)傳輸中進(jìn)行編碼操作時(shí)，實(shí)體主體的內(nèi)容發(fā)生變化才會(huì)導(dǎo)致它和報(bào)文主體產(chǎn)生差異。

壓縮傳輸?shù)膬?nèi)容編碼

內(nèi)容編碼指明應(yīng)用在實(shí)體內(nèi)容上的編碼格式，并保存實(shí)體信息原樣壓縮。內(nèi)容編碼后的實(shí)體由客戶端接收并負(fù)責(zé)編碼。

常用的內(nèi)容編碼

• gzip(GNU zip)
• compress(UNIX 系統(tǒng)的標(biāo)準(zhǔn)壓縮)
• deflate(zlib)
• identity(不進(jìn)行編碼)

分割發(fā)送的分塊傳輸編碼

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

發(fā)送多種數(shù)據(jù)的多部分對(duì)象集合

HTTP 協(xié)議采用了多部分對(duì)象集合——MIME機(jī)制（Multipurpose Internet Mail Extensions，多用途因特網(wǎng)郵件擴(kuò)展），它是一種允許處理文本、圖片、視頻等多種不同類型的數(shù)據(jù)。

在 HTTP 報(bào)文中使用 多部分對(duì)象集合時(shí)，需要在首部字段里加上 Content-type，使用 boundary 字符串來劃分各個(gè)實(shí)體的起始行，需要在起始行前插入 "--" 標(biāo)記，，最后以 "--" 結(jié)束。

獲取部分內(nèi)容的范圍請(qǐng)求

指定范圍發(fā)送的請(qǐng)求叫做范圍請(qǐng)求

執(zhí)行范圍請(qǐng)求會(huì)用到首部字段 Range 來指定資源的 byte 范圍

請(qǐng)求： Range: bytes = 5001-10000響應(yīng)： Content-Range: bytes 5001-10000/10000

針對(duì)范圍請(qǐng)求，響應(yīng)會(huì)返回狀態(tài)碼為 206 Partial Content 的響應(yīng)報(bào)文，如果服務(wù)器無法響應(yīng)范圍請(qǐng)求，則會(huì)返回狀態(tài)碼 200 OK 和完成的實(shí)體內(nèi)容。

內(nèi)容協(xié)商返回最合適的內(nèi)容

同一個(gè) Web 網(wǎng)站可能會(huì)存在多份相同內(nèi)容的頁面，比如英文版和中文版，當(dāng)瀏覽器默認(rèn)語言為中文時(shí)，訪問 URI 的 Web 頁面時(shí)，則會(huì)顯示中文版的 Web 頁面，這種機(jī)制稱為內(nèi)容協(xié)商（Content Negotiation）。

內(nèi)容協(xié)商機(jī)制會(huì)在請(qǐng)求報(bào)文中用到下面首部字段：

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

內(nèi)容協(xié)商技術(shù)有3種類型：

• 服務(wù)器驅(qū)動(dòng)協(xié)商：由服務(wù)器端進(jìn)行內(nèi)容協(xié)商。以請(qǐng)求的首部字段為參考，在服務(wù)端自動(dòng)處理。
• 客戶端驅(qū)動(dòng)協(xié)商：由客戶端進(jìn)行內(nèi)容協(xié)商。用戶利用瀏覽器提供的可選項(xiàng)列表手動(dòng)選擇；還可以利用 JavaScript 腳本在 Web 頁面上自動(dòng)進(jìn)行選擇。
• 透明協(xié)商：是服務(wù)器驅(qū)動(dòng)和客戶端驅(qū)動(dòng)的結(jié)合體，是由服務(wù)器端和客戶端各自進(jìn)行內(nèi)容協(xié)商的一種方法。

第四章：返回結(jié)果的 HTTP 狀態(tài)碼

狀態(tài)碼告知從服務(wù)器端返回的請(qǐng)求結(jié)果

狀態(tài)碼的職責(zé)是當(dāng)客戶端向服務(wù)器端發(fā)送請(qǐng)求時(shí)，描述返回的請(qǐng)求結(jié)果。
狀態(tài)碼由三位數(shù)字和原因短語組成，其中數(shù)字第一位指定了相應(yīng)類別，后兩位無分類。

類別原因短語

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

狀態(tài)碼

2XX 成功：表示請(qǐng)求被正常處理了

• 200 OK 表示從客戶端發(fā)來的請(qǐng)求在服務(wù)器端被正常處理了。
• 204 No Content 請(qǐng)求處理成功，返回的響應(yīng)報(bào)文中不含實(shí)體的主體部分
• 206 Partial Content 表示客戶端進(jìn)行范圍請(qǐng)求

3XX 重定向：表明瀏覽器需要執(zhí)行某些特殊處理以正確處理請(qǐng)求

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

4XX 客戶端錯(cuò)誤：表明客戶端發(fā)生錯(cuò)誤的原因所在

• 400 Bad Request：表示請(qǐng)求報(bào)文中存在語法錯(cuò)誤
• 401 Unauthorized：表示發(fā)送的請(qǐng)求需要有通過 HTTP 認(rèn)證的認(rèn)證信息
• 403 Forbidden：表示請(qǐng)求資源被服務(wù)器拒絕了
• 400 Not Found：表示服務(wù)器上無法找到請(qǐng)求資源

5XX 服務(wù)器錯(cuò)誤：表明服務(wù)器本身發(fā)生錯(cuò)誤

• 500 Internal Server Error：表示服務(wù)器在執(zhí)行請(qǐng)求時(shí)發(fā)生了錯(cuò)誤
• 503 Serveice Unavailable：表示服務(wù)器暫時(shí)處于超負(fù)荷或正在停機(jī)維護(hù)，無法處理請(qǐng)求。

第五章：與 HTTP 協(xié)作的 Web 服務(wù)器

HTTP/1.1 允許一臺(tái) HTTP 服務(wù)器搭建多個(gè) Web 站點(diǎn)
在互聯(lián)網(wǎng)上，域名通過 DNS 服務(wù)映射到 IP 地址之后訪問目標(biāo)網(wǎng)站，在相同 IP 下，發(fā)送 HTTP 請(qǐng)求時(shí)，必須在 Host 首部?jī)?nèi)完整指定主機(jī)名和域名的 URI

通信數(shù)據(jù)轉(zhuǎn)發(fā)程序：代理、網(wǎng)關(guān)、隧道

• 代理：是一種有轉(zhuǎn)發(fā)功能的應(yīng)用程序，它扮演了位于服務(wù)器和客戶端“中間人”的角色
• 網(wǎng)關(guān)：網(wǎng)關(guān)是轉(zhuǎn)發(fā)其他服務(wù)器通信數(shù)據(jù)的服務(wù)器，接受從客戶端發(fā)來的請(qǐng)求時(shí)，它就像自己擁有資源的源服務(wù)器一樣對(duì)請(qǐng)求進(jìn)行處理
• 隧道：相隔甚遠(yuǎn)的客戶端和服務(wù)器兩者之間進(jìn)行中轉(zhuǎn)，并保持雙方通信連接的應(yīng)用程序

代理

使用代理服務(wù)器的理由：利用緩存技術(shù)減少網(wǎng)絡(luò)帶寬的流量，組織內(nèi)部針對(duì)特定網(wǎng)站的訪問控制，以獲取訪問日志為主要目的

緩存代理：代理轉(zhuǎn)發(fā)時(shí)，緩存代理會(huì)預(yù)先將資源的副本緩存到代理服務(wù)器上，當(dāng)代理再次接收到相同資源的請(qǐng)求時(shí)，就可以不從源服務(wù)器那里獲取資源，而是將緩存的資源作為響應(yīng)返回

透明代理：轉(zhuǎn)發(fā)請(qǐng)求或響應(yīng)時(shí)，不對(duì)報(bào)文做任何加工的代理類型稱為透明代理

網(wǎng)關(guān)：

網(wǎng)關(guān)能使通信線路上的服務(wù)器提供非 HTTP 協(xié)議服務(wù)。
利用網(wǎng)關(guān)能提高通信的安全性

隧道

隧道的目的是確保客戶端能與服務(wù)器進(jìn)行安全的通信，隧道本身不會(huì)去解析 HTTP 請(qǐng)求，隧道會(huì)在通信雙方斷開連接時(shí)結(jié)束

保存資源的緩存

緩存是指代理服務(wù)器或客戶端本地磁盤內(nèi)保存的資源副本。利用緩存可減少對(duì)源服務(wù)器的訪問，因此也節(jié)省了通信流量和通信時(shí)間。

緩存的有效期

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

第六章：HTTP 首部

HTTP 協(xié)議的請(qǐng)求和響應(yīng)報(bào)文中必須必定包含 HTTP 首部。首部?jī)?nèi)容為請(qǐng)求或響應(yīng)所需要的信息

HTTP 請(qǐng)求報(bào)文由方法、URI、HTTP 版本、HTTP 首部字段等部分構(gòu)成
HTTP 響應(yīng)報(bào)文由 HTTP 版本、狀態(tài)碼、HTTP 首部字段組成

HTTP 首部字段

HTTP 首部字段是構(gòu)成 HTTP 報(bào)文的要素之一。使用首部字段是為了給瀏覽器和服務(wù)器提供報(bào)文主體大小、所使用的語言、認(rèn)證信息等內(nèi)容。

4種 HTTP 首部字段類型

• 通用首部字段：請(qǐng)求報(bào)文和響應(yīng)報(bào)文都會(huì)使用的首部
• 請(qǐng)求首部字段：從客戶端向服務(wù)器端發(fā)送請(qǐng)求報(bào)文時(shí)使用的首部
• 響應(yīng)首部字段：從服務(wù)器端向客戶端返回響應(yīng)報(bào)文時(shí)使用的首部
• 實(shí)體首部字段：針對(duì)請(qǐng)求報(bào)文和響應(yīng)報(bào)文的實(shí)體部分使用的首部

通用首部字段

首部字段名說明

Cache-Control	控制緩存的行為
Connection	逐跳首部、連接的管理
Date	創(chuàng)建報(bào)文的日期時(shí)間
Pragma	報(bào)文指令
Trailer	報(bào)文末端的首部一覽
Transfer-Encoding	指定報(bào)文主體的傳輸編碼方式
Upgrade	升級(jí)為其他協(xié)議
Via	代理服務(wù)器的相關(guān)信息
Warning	錯(cuò)誤通知

請(qǐng)求首部字段

首部字段名說明

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

響應(yīng)首部字段

首部字段名說明

Accept-Ranges	是否接收字節(jié)范圍請(qǐng)求
Age	推算資源創(chuàng)建經(jīng)過時(shí)間
ETag	資源的匹配信息
Location	令客戶端重定向至指定 URI
Proxy-Authenticate	代理服務(wù)器對(duì)客戶端的認(rèn)證信息
Retry-After	對(duì)再次發(fā)起請(qǐng)求的時(shí)機(jī)要求
Server	HTTP 服務(wù)器的安裝信息
Vary	代理服務(wù)器緩存的管理信息
WWW-Authenticate	服務(wù)器對(duì)客戶端的認(rèn)證信息

實(shí)體首部字段

首部字段名說明

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

第七章：確保 Web 安全的 HTTPS

HTTP的缺點(diǎn)：

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

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

內(nèi)容的加密
把 HTTP 報(bào)文里所含的內(nèi)容進(jìn)行加密，前提需要客戶端和服務(wù)器同時(shí)具備加密和解密機(jī)制

HTTP + 加密 + 認(rèn)證 + 完整性保護(hù) = HTTPS

未完待續(xù)...

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。