《图解HTTP》核心知识总结
HTTP協(xié)議的簡介
HTTP是超文本傳輸協(xié)議，用于客戶端和服務(wù)器端之間的通信，屬于TCP/IP中的應(yīng)用層。
HTTP協(xié)議的基礎(chǔ)知識
客戶端和服務(wù)器端
客戶端是服務(wù)請求方，服務(wù)器端是服務(wù)提供方。
URI和URL
URI:URI是統(tǒng)一資源標(biāo)識符；
URL:是統(tǒng)一資源定位器;
URI的格式(了解即可)
[scheme:][//user:password@]host[:port][/path][?query][#fragment]
如上是URI的具體格式，下面介紹其意義：
- scheme::是協(xié)議方案，比如http:,https:,file:等,此項(xiàng)可選可不選
- [//[user:password@]:指定用戶名和密碼作為從服務(wù)器獲取資源時必要的登陸信息，此項(xiàng)是可選項(xiàng)
- host:服務(wù)器地址，例如www.runoob.com
- [:port]：服務(wù)器端口號,例如：8080，此項(xiàng)是可選項(xiàng)
- [/path]:指定服務(wù)器上的文件路徑來定位特指的資源
- [?query]:查詢字符串，例如?id=123&pas=123
- [#fragment]:片段標(biāo)識符
DNS
見DNS基礎(chǔ)知識
HTTP的特點(diǎn)
HTTP通過請求和響應(yīng)來達(dá)成通信
如圖：
HTTP 是無狀態(tài)協(xié)議
HTTP 是無狀態(tài)協(xié)議，它不對之前發(fā)生過的請求和響應(yīng)的狀態(tài)進(jìn)行管理。也就是說，無法根據(jù)之前的狀態(tài)進(jìn)行本次的請求處理。
假設(shè)要求登錄認(rèn)證的 Web 頁面本身無法進(jìn)行狀態(tài)的管理（不記錄已 登錄的狀態(tài)），那么每次跳轉(zhuǎn)新頁面不是要再次登錄，就是要在每次 請求報文中附加參數(shù)來管理登錄狀態(tài)。
HTTP使用 Cookie 的狀態(tài)管理，Cookie 技術(shù)通過在請求和響應(yīng)報文中寫入 Cookie 信 息來控制客戶端的狀態(tài)。
Cookie 會根據(jù)從服務(wù)器端發(fā)送的響應(yīng)報文內(nèi)的一個叫做 Set-Cookie 的首部字段信息，通知客戶端保存Cookie。當(dāng)下次客戶端再往該服務(wù)器發(fā)送請求時，客戶端會自動在請求報文中加入 Cookie 值后發(fā)送出 去。服務(wù)器端發(fā)現(xiàn)客戶端發(fā)送過來的 Cookie 后，會去檢查究竟是從哪一 個客戶端發(fā)來的連接請求，然后對比服務(wù)器上的記錄，最后得到之前 的狀態(tài)信息。
如下圖：
HTTP報文
HTTP報文是HTTP請求和響應(yīng)的單位。用于請求的報文叫做請求報文，而用于響應(yīng)的報文叫做 響應(yīng)報文。
報文的結(jié)構(gòu)如圖
報文主體和實(shí)體主體的差異 :
實(shí)體作為請求或響應(yīng)的有效載荷數(shù)據(jù)（補(bǔ)充項(xiàng)）被傳輸，其內(nèi)容由實(shí)體首部和實(shí)體主體組成。HTTP 報文的主體用于傳輸請求或響應(yīng)的實(shí)體主體。 通常，報文主體等于實(shí)體主體。只有當(dāng)傳輸中進(jìn)行編碼操作時，實(shí)體 主體的內(nèi)容發(fā)生變化，才導(dǎo)致它和報文主體產(chǎn)生差異
HTTP首部字段的結(jié)構(gòu)
首部字段名: 字段值
如果有多個值，則首部字段名: 字段值1, 字段值2
如果HTTP首部字段重復(fù)了會如何？
當(dāng)HTTP報文首部中出現(xiàn)中出現(xiàn)了兩個或兩個以上具有相同首部字段名時會怎么樣？這種情況 在規(guī)范中尚未明確，根據(jù)瀏覽器內(nèi)部處理邏輯的不同，結(jié)果可能并不一致。
HTTP首部字段分為四個部分：
- 通用首部字段：請求報文和響應(yīng)報文兩方都會使用的首部字段
- 請求首部字段：從客戶端向服務(wù)器端發(fā)送請求報文時使用的首部。補(bǔ)充了請求的附加內(nèi)容、客戶端信息、響應(yīng)內(nèi)容相關(guān)優(yōu)先級等信息。
- 響應(yīng)首部字段：從服務(wù)器端向客戶端返回響應(yīng)報文時使用的首部。補(bǔ)充了響應(yīng)的附加內(nèi)容，也會為客戶端附加額外的內(nèi)容信息
- 實(shí)體首部字段：針對請求報文和響應(yīng)報文的實(shí)體部分使用的首部。補(bǔ)充了資源內(nèi)容的更新時間等與實(shí)體有關(guān)的信息
實(shí)例分析
現(xiàn)在以請求菜鳥教程的報文為例來進(jìn)行分析：
請求報文
GET /HTTP/1.1 //請求行 Host: www.runoob.com User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2 Accept-Encoding: gzip, deflate, br Referer: https://cn.bing.com/ Connection: keep-alive Cookie: Hm_lvt_3eec0b7da6548cf07db3bc477ea905ee=1554627142,1556799533; _ga=GA1.2.579069872.1554627144; Hm_lpvt_3eec0b7da6548cf07db3bc477ea905ee=1556799533; _gid=GA1.2.1514513796.1556799533; _gat_gtag_UA_84264393_2=1 Upgrade-Insecure-Requests: 1 Cache-Control: max-age=0 復(fù)制代碼響應(yīng)報文
HTTP/1.1 200 OK //狀態(tài)行 Server: Tengine Content-Type: text/html Content-Length: 150124 Connection: keep-alive Date: Thu, 02 May 2019 09:27:08 GMT Content-Encoding: gzip Vary: Accept-Encoding X-M-Log: QNM:xs446;QNM3:1 X-M-Reqid: jVAAADsHtCKO05oV X-Powered-By: HHVM/3.28.1 X-Qnm-Cache: Hit Ali-Swift-Global-Savetime: 1556270140 Via: cache16.l2cn1807[0,200-0,H], cache37.l2cn1807[1,0], cache9.cn1066[0,200-0,H], cache5.cn1066[1,0] Age: 10328 X-Cache: HIT TCP_MEM_HIT dirn:11:466942761 X-Swift-SaveTime: Thu, 02 May 2019 10:36:54 GMT X-Swift-CacheTime: 86400 Timing-Allow-Origin: * EagleId: db971b1915567995564074785e 復(fù)制代碼請求行和狀態(tài)行
請求行：請求行中包含用于請求的方法，請求的URI和HTTP版本
狀態(tài)行：狀態(tài)行包含響應(yīng)結(jié)果的狀態(tài)碼，原因短語和HTTP版本
在請求報文中GET /HTTP/1.1是請求行，其中GET代表請求的方法，/HTTP/1.1代表HTTP版本，在這個請求中未出現(xiàn)請求的URI。
在響應(yīng)報文中HTTP/1.1 200 OK是狀態(tài)行，其中HTTP/1.1是請求的版本，200是響應(yīng)結(jié)果的狀態(tài)碼，而OK 則是原因短語。
請求的方法
GET：GET方法用來訪問以被URI識別的資源。指定的資源經(jīng)服務(wù)器解析后返回響應(yīng)的內(nèi)容。如下圖
POST: POST方法用來傳輸實(shí)體的主體。如下圖
其他方法如PUT HEAD DELETE OPTIONS TRACE CONNECT一般不使用。下面簡單介紹一下：
| PUT | 用來傳輸文件 | PUT方法不采用任何驗(yàn)證機(jī)制，存在安全問題 |
| HEAD | 和GET方法一樣，不過只返回響應(yīng)首部 | --- |
| DELETE | 用來刪除文件 | DELETE不采用任何驗(yàn)證機(jī)制，存在安全問題 |
| OPTIONS | 查詢針對請求URI指定的資源支持的方法 | ---- |
| TRACE | 讓W(xué)EB服務(wù)器端將之前的請求通信返回給客戶端 | 容易引發(fā)跨站追蹤（XST）攻擊 |
| CONNECT | 要求在與代理服務(wù)器通信時建立隧道，實(shí)現(xiàn)用隧道協(xié)議進(jìn)行TCP通信 | ---- |
狀態(tài)碼
2XX
200 ok
表示從客戶端發(fā)來的請求在服務(wù)器端被正常處理了
204 Not Content
該狀態(tài)碼代表服務(wù)器接收的請求已經(jīng)被成功處理，但是返回的響應(yīng)報文中不包含實(shí)體的主體部分
206 Partial Content
該狀態(tài)碼表示客戶端進(jìn)行了范圍請求，而服務(wù)器成功執(zhí)行了這部分的GET請求
3XX
301 Moved Permanently
永久性重定向，該狀態(tài)碼表示請求的資源已被分配到新的URI，以后應(yīng)該 使用現(xiàn)在所指的URI。
302 Found
臨時重定向。該狀態(tài)碼表明請求的資源已被分配了新的URI，希望用戶本次能使用新的URI訪問。
303 See Other
該狀態(tài)碼表示由于請求資源存在另一個URI，應(yīng)該使用GET方法定向獲取請求的資源
304 Not Modified
該狀態(tài)碼表示客戶端發(fā)送附帶條件請求時，服務(wù)器端允許請求訪問資源，但因?yàn)檎埱笪礉M足條件的情況后， 直接返回304.
307 Temporary Redirect
臨時重定向，和302相似。但是307不會從Post變成GET
4XX
400 Bad Request
該狀態(tài)碼表示請求報文中存在語法錯誤。當(dāng)錯誤發(fā)生時，需要修改請求的內(nèi)容后再次發(fā)送請求
401 Unauthorized
該狀態(tài)碼表示發(fā)送的請求需要通過HTTP認(rèn)證的認(rèn)證信息。另外若之前已經(jīng)進(jìn)行過一次請求，則表示用戶認(rèn)證失敗
403 Forbidden
該狀態(tài)碼表明對請求資源的訪問被服務(wù)器拒絕了
404 Not Found
該狀態(tài)碼表明服務(wù)器上無法找到請求的資源
5XX
500 Internal Server Error
該主題碼表示服務(wù)器在執(zhí)行請求時發(fā)生了錯誤
503 Service Unavailable
該狀態(tài)碼表明服務(wù)器暫時處于超負(fù)載或正在進(jìn)行停機(jī)維護(hù)，現(xiàn)在無法處理請求。
HTTP所有的首部字段
HTTP/1.1定義了如下47種首部地段，如下
通用首部字段：
請求首部字段：
響應(yīng)首部字段：
實(shí)體首部字段：
非HTTP/1.1首部字段（不屬于47種中的字段）:Cookie、 Set-Cookie、 Content-Disposition等。
端到端首部和逐跳首部
HTTP將使用 緩存代理和非緩存代理 的首部字段分成兩種類型：端到端首部（End-to-end Header）、逐跳首部(Hop-by-hop Header)
緩存代理
代理轉(zhuǎn)發(fā)響應(yīng)時，緩存代理（Caching Proxy）會預(yù)先將資源的副本 （緩存）保存在代理服務(wù)器上。 當(dāng)代理再次接收到對相同資源的請求時，就可以不從源服務(wù)器那里獲 取資源，而是將之前緩存的資源作為響應(yīng)返回。
透明代理
轉(zhuǎn)發(fā)請求或響應(yīng)時，不對報文做任何加工的代理類型被稱為透明代理 （Transparent Proxy）。反之，對報文內(nèi)容進(jìn)行加工的代理被稱為非 透明代理。
注意：這里的非緩存代理不等于透明代理；它們劃分的標(biāo)準(zhǔn)不一樣。`緩存代理`和`非緩存代理`是通過是否使用緩存來劃分的；而`透明代理`和`非透明代理`是通過是否會修改報文來劃分。
端到端首部：分在此類別中的首部會轉(zhuǎn)發(fā)給請求/響應(yīng)對應(yīng)的最終接收目標(biāo)(即全程有效)，且必須保存在由緩存生成的響應(yīng)中，另外規(guī)定它必須被轉(zhuǎn)發(fā)
逐跳首部：分在此類別的首部只對單次轉(zhuǎn)發(fā)有效，會因?yàn)橥ㄟ^緩存或代理而不再轉(zhuǎn)發(fā)。在HTTP/1.1和以后版本中，如果要使用逐跳首部，需要通過Connection首部字段
逐跳首部字段為：
- Connection
- Keep-Alive(新增字段，可忽略)
- Proxy-Authenticate
- Proxy-Authorization
- Trailer
- TE
- Transfer-Encoding
- Upgrade
其他字段都為端到端首部
通用首部字段
在實(shí)例的請求報文中出現(xiàn)的通用首部
Connection: keep-alive Cache-Control: max-age=0 復(fù)制代碼在實(shí)例的響應(yīng)報文中出現(xiàn)的通用首部
Connection: keep-alive Date: Thu, 02 May 2019 09:27:08 GMT Via: cache16.l2cn1807[0,200-0,H], cache37.l2cn1807[1,0], cache9.cn1066[0,200-0,H], cache5.cn1066[1,0] 復(fù)制代碼Cache-Control
通過指定首部字段Cathe-Control的指令，就可以操作緩存的工作機(jī)制，如圖：
請求報文中Cache-Control: max-age=0表示緩存服務(wù)器通常需要將請求轉(zhuǎn)發(fā)給源服務(wù)器。
Connection
Connection的作用：
控制不再轉(zhuǎn)發(fā)給代理的首部字段
代理服務(wù)器的基本行為就是接收客戶端發(fā)送的請求后轉(zhuǎn)發(fā)給其他服務(wù)器。代理不改變請求 URI，會直接發(fā)送給前方持有資源的目標(biāo)服務(wù)器。上面介紹的緩存代理是代理服務(wù)器作用的一種。
管理持久化連接
Connection: close //表明服務(wù)器想斷開連接 Connection: Keep-Alive //保持持久化連接（默認(rèn)） 復(fù)制代碼Via
用來追蹤客戶端與服務(wù)器端之間的請求和響應(yīng)報文的傳輸路徑。
如Via: cache16.l2cn1807[0,200-0,H], cache37.l2cn1807[1,0], cache9.cn1066[0,200-0,H], cache5.cn1066[1,0]
Date
首部字段Date表明創(chuàng)建HTTP報文的時間，如Date: Thu, 02 May 2019 09:27:08 GMT就表示創(chuàng)建報文的時間為2019年5月2日，星期二。
Pragma
Pragma是歷史遺留字段，僅作為與HTTP/1.0的向后兼容而定義。
Trailer
用來說明在報文主體后記錄了哪些首部字段
Transfer-Encoding
規(guī)定傳輸報文主體時采用的編碼方式（僅對分塊傳輸編碼有效）
Upgrade
用來檢測HTTP協(xié)議及其他協(xié)議是否可使用更高的版本進(jìn)行通信。
Warning
告訴用戶一些與緩存有關(guān)的問題的警告
請求首部字段
請求報文（去除了通用首部字段）
Host: www.runoob.com User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2 Accept-Encoding: gzip, deflate, br Referer: https://cn.bing.com/ Cookie: Hm_lvt_3eec0b7da6548cf07db3bc477ea905ee=1554627142,1556799533; _ga=GA1.2.579069872.1554627144; Hm_lpvt_3eec0b7da6548cf07db3bc477ea905ee=1556799533; _gid=GA1.2.1514513796.1556799533; _gat_gtag_UA_84264393_2=1 Upgrade-Insecure-Requests: 1 Cache-Control: max-age=0 復(fù)制代碼Host
告訴服務(wù)器請求的資源所處的互聯(lián)網(wǎng)主機(jī)名和端口號，如Host: www.runoob.com。Host是唯一必須包含在請求內(nèi)的首部字段
User-Agent
用來將創(chuàng)建請求的瀏覽器和用戶代理名稱等信息傳達(dá)給服務(wù)器。
例如上面的請求首部:
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0
Accept
通知服務(wù)器可以處理的媒體類型及媒體類型的相對優(yōu)先級
例如Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
媒體類型
文本文件
text/html, text/plain, text/css ... application/xhtml+xml, application/xml ...
圖片文件
image/jpeg, image/gif, image/png ...
視頻文件
video/mpeg, video/quicktime ...
應(yīng)用程序使用的二進(jìn)制文件
application/octet-stream, application/zip
優(yōu)先級
使用q=來額外表示權(quán)重值，用;進(jìn)行分隔。權(quán)重值的范圍是0~1（可精確到小數(shù)點(diǎn)后3位），且1為最大值。不指定 權(quán)重值時，默認(rèn)權(quán)重為q=1.0.當(dāng)服務(wù)器提供多個內(nèi)容時會首先返回權(quán)重值最高的媒體類型。
Accept-Charset
Accept-Charset首部字段可用來通知服務(wù)器用戶代理支持的字符集及字符集的相對優(yōu)先順序。另外可一次性指定多種字符集。與首部字段 Accept相同的可用權(quán)重q值來表示相對優(yōu)先級
Accept-Encoding
Accept-Encoding首部字段用來告知服務(wù)器用戶代理支持的內(nèi)容編碼及內(nèi)容編碼的優(yōu)先級順序。可一次性指定多種內(nèi)容編碼，可用權(quán)重q來指定優(yōu)先級 例如Accept-Encoding: gzip, deflate, br
Accept-Language
首部字段Accept-Language用來告訴服務(wù)器用戶代理能夠處理的語言，可以指定多個語言，可以使用q來決定優(yōu)先級。 例如Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Authorization
用來告訴服務(wù)器，用戶代理的認(rèn)證信息
Expect
告知服務(wù)器期望出現(xiàn)某種特定的行為
From
告訴服務(wù)器使用用戶代理的用戶的電子郵箱地址
If-Match
告訴服務(wù)器匹配資源所用的實(shí)體標(biāo)記（ETag）值，服務(wù)器會對比If-Match的字段值和資源的ETag值，僅 當(dāng)兩者一致時才執(zhí)行請求.反之則返回狀碼412
If-Modified-Since
告訴服務(wù)器若If-Modified-Since字段值早于資源更新的時間，則希望能處理該請求。 反之如果在If-Modified-Since指定的時間日期之后，如果請求的資源都沒有更新，則 返回的狀態(tài)碼 304
If-None-Match
與If-Match相反
If-Range
告訴服務(wù)器若指定的If-Range字段值（ETag值或者時間）和請求資源的ETag值或時間相一致時，則作為范圍請求處理。 反之，則返回全體資源。如圖：
If-Unmodified-Since
與If-Modified-Since作用相反
Range
對于只需獲取部分資源的范圍請求，包含首部字段Range即可告知服務(wù)器資源的指定范圍。 接收到附帶Range首部字段請求的服務(wù)器，會在處理請求之后返回206.無法處理該范圍的 請求時，則會返回200的響應(yīng)及全部資源。
Referer
告訴服務(wù)器請求的原始URI
例如：Referer: https://cn.bing.com/說明我是從微軟必應(yīng)請求的
Upgrade-Insecure-Requests
Upgrade-Insecure-Requests是一個請求首部，用來向服務(wù)器端發(fā)送信號，表示客戶端優(yōu)先選擇加密及帶有身份驗(yàn)證的響應(yīng)。不屬于47種報文首部字段。
TE
告訴服務(wù)器，客戶端能夠處理的傳輸編碼方式及相對優(yōu)先級
Transfer-Encoding,TE,Content-Encoding,Accept-Encoding四個首部字段的區(qū)別
- Transfer-Encoding：用于指定傳輸報文主體時使用的編碼方式，屬于逐跳首部，即只在兩個節(jié)點(diǎn)間有效。
- TE：用于告知服務(wù)器客戶端能夠處理的編碼方式和相對優(yōu)先級，屬于逐跳首部，即只在兩個節(jié)點(diǎn)間有效。
- Content-Encoding：用于指定報文主體已經(jīng)采用的編碼方式，屬于端到端首部，即在整個傳輸過程中有效。
- Accept-Encoding：用于告知服務(wù)器客戶端能夠處理的編碼方式和相對優(yōu)先級，屬于端到端首部，即在整個傳輸過程中有效。
很顯然，Transfer-Encoding和TE是一組，Content-Encoding和Accept-Encoding是一組。 根本區(qū)別在于，Content-Encoding和Accept-Encoding限制的是報文主體在整個傳輸過程中使用的編碼方式，全局有效；Transfer-Encoding和TE限制的是報文主體在兩個節(jié)點(diǎn)間（源服務(wù)器和代理服務(wù)器之間、代理服務(wù)器和客戶端之間等）傳輸時使用的編碼方式，只在兩節(jié)點(diǎn)間有效。
轉(zhuǎn)自區(qū)分Transfer-Encoding,TE,Content-Encoding,Accept-Encoding四個首部字段
響應(yīng)首部字段
響應(yīng)報文
Server: Tengine Vary: Accept-Encoding X-M-Log: QNM:xs446;QNM3:1 X-M-Reqid: jVAAADsHtCKO05oV X-Powered-By: HHVM/3.28.1 X-Qnm-Cache: Hit Ali-Swift-Global-Savetime: 1556270140 Age: 10328 X-Cache: HIT TCP_MEM_HIT dirn:11:466942761 X-Swift-SaveTime: Thu, 02 May 2019 10:36:54 GMT X-Swift-CacheTime: 86400 Timing-Allow-Origin: * EagleId: db971b1915567995564074785e 復(fù)制代碼Accept-Ranges
首部字段Accept-Ranges是用來告訴客戶端服務(wù)器是否能處理范圍請求，以指定獲取服務(wù)器端 某個部分的資源。可以指定的值為bytes(表示接受范圍請求)和none（表示不接受范圍請求）.
Age
告訴客戶端，源服務(wù)器在多久前創(chuàng)建了響應(yīng)。字段值的單位為秒。
ETag
主要用于檢驗(yàn)緩存是否改變。它告訴客戶端實(shí)體標(biāo)識，是一種可將資源以字符串的形式做唯一標(biāo)識的方式。服務(wù)器會為每份資源分配對應(yīng)的ETag值
另外當(dāng)資源更新時，ETag值也需要更新。當(dāng)資源被緩存時，就會被分配唯一的標(biāo)識。若在下載過程中 出現(xiàn)連接的中斷，再連接的情況，都會依照ETag值來指定資源。
ETag中有強(qiáng)ETag值和弱ETag值
強(qiáng)ETag值，無論實(shí)體發(fā)生多么細(xì)微的變化都會改變其值。
弱ETag值，只用于提示資源是否相同。只有資源發(fā)生了根本改變，產(chǎn)生差異時才會改變ETag值。這時， 會在字段值最開始處附加 W/
Location
將響應(yīng)接受方引領(lǐng)到某個與請求URI位置不同的資源。基本上，該字段會配合3XX的響應(yīng)，提供重定向的URI。
Proxy-Authenticate
會把由代理服務(wù)器所要求的認(rèn)證信息發(fā)生給客戶端
Retry-After
告訴客戶端應(yīng)該在多久之后再發(fā)送請求。主要配合狀態(tài)碼503響應(yīng)或3xx響應(yīng)一起使用。字段值可以指定為具體的日期時間，也可以是創(chuàng)建響應(yīng)后的秒數(shù)
Server
告訴客戶端當(dāng)前服務(wù)器上安裝的HTTP服務(wù)器應(yīng)用程序的信息
Vary
對緩存進(jìn)行控制。具體見這里
WWW-Authenticate
用于HTTP訪問認(rèn)證
實(shí)體首部字段
Allow
告訴客戶端支持的請求方法
Content-Encoding
告知客戶端服務(wù)器對實(shí)體的主體部分選用的內(nèi)容編碼方式。內(nèi)容編碼是指在不丟失實(shí)體信息的前提下所進(jìn)行的壓縮
主要采用以下4種內(nèi)容編碼的方式
- gzip
- compress
- deflate
- identity
Content-Language
告訴客戶端，實(shí)體使用的語言
Content-Length
表明實(shí)體主體部分的大小，單位是字節(jié)。對實(shí)體主體進(jìn)行內(nèi)容編碼傳輸時，不能再使用Content-Length 首部字段
Content-Location
給出報文主體部分相對應(yīng)的URI。和首部字段Location不同，Content-Location表示的是報文主體返回資源對應(yīng)的URI
Content-MD5
首部字段 Content-MD5 是一串由 MD5 算法生成的值，其目的在于檢 查報文主體在傳輸過程中是否保持完整，以及確認(rèn)傳輸?shù)竭_(dá)。
Content-Range
針對范圍請求，返回響應(yīng)時使用的首部字段Content-Range，能告訴客戶端作為響應(yīng)返回的實(shí)體的哪個部分 符合范圍請求。字段值以字節(jié)為單位，表示當(dāng)前發(fā)送部分及整個實(shí)體大小。
Content-Type
說明實(shí)體主體內(nèi)對象的媒體類型，和首部字段Accept一樣，字段值用type/subtype形式賦值
Http Header里的Content-Type一般有這三種：
- application/x-www-form-urlencoded：數(shù)據(jù)被編碼為名稱/值對(這是標(biāo)準(zhǔn)的編碼格式)。
- multipart/form-data： 數(shù)據(jù)被編碼為一條消息，頁上的每個控件對應(yīng)消息中的一個部分。
- text/plain： 數(shù)據(jù)以純文本形式(text/json/xml/html)進(jìn)行編碼，其中不含任何控件或格式字符(postman軟件里標(biāo)的是RAW)
form的enctype屬性為編碼方式，常用有兩種：application/x-www-form-urlencoded和multipart/form-data，默認(rèn)為application/x-www-form-urlencoded。
當(dāng)action為get時候，瀏覽器用x-www-form-urlencoded的編碼方式把form數(shù)據(jù)轉(zhuǎn)換成一個字串（name1=value1&name2=value2...），然后把這個字串追加到url后面，用?分割，加載這個新的url。
當(dāng)action為post時候，瀏覽器把form數(shù)據(jù)封裝到http body中，然后發(fā)送到server。 如果沒有type=file的控件，用默認(rèn)的application/x-www-form-urlencoded就可以了。 但是如果有type=file的話，就要用到multipart/form-data了。
當(dāng)action為post且Content-Type類型是multipart/form-data，瀏覽器會把整個表單以控件為單位分割，并為每個部分加上Content-Disposition(form-data或者file),Content-Type(默認(rèn)為text/plain),name(控件name)等信息，并加上分割符。
轉(zhuǎn)自Http Header里的Content-Type
Expires
會將資源失效的日期告訴客戶端
Last-Modified
指明資源最終修改的時間
為Cookie服務(wù)的首部字段
Set-Cookie
開始狀態(tài)管理所使用的Cookie信息（響應(yīng)首部字段）
Cookie
告訴服務(wù)器，當(dāng)客戶端想獲取HTTP狀態(tài)管理支持時，就會在請求中包含從服務(wù)器接受到的Cookie。接收到多個 Cookie時，同時可以以多個Cookie形式發(fā)送
其他首部字段
HTTP首部字段是可以自行擴(kuò)展的。所以在WEB服務(wù)器和瀏覽器應(yīng)用上，會出現(xiàn)各種非標(biāo)準(zhǔn)的首部字段
X-Frame-Options
屬于響應(yīng)首部，用于控制網(wǎng)站內(nèi)容在其他web網(wǎng)站的Frame標(biāo)簽內(nèi)的顯示問題。其主要目的是為了防止 點(diǎn)擊劫持攻擊
有兩個可指定的字段值 DENY:拒絕 SAMEORIGIN:僅在同源域名下的頁面匹配時許可
X-XSS-Protection
屬于響應(yīng)首部，它是針對跨站腳本攻擊（XSS）的一種對策，用于控制瀏覽器XSS防護(hù)機(jī)制開關(guān)。
字段值： 0：將XSS過濾設(shè)置為無效狀態(tài) 1：將XSS過濾設(shè)置為有效狀態(tài)
DNT
屬于請求字段，意味拒絕個人信息被采集，是表示拒絕被精準(zhǔn)廣告追蹤的一種方法
字段值 0：同意被追蹤 1：拒絕被追蹤
P3P
屬于響應(yīng)首部，通過利用 P3P（The Platform for Privacy Preferences，在線隱私偏好平臺）技術(shù)，可以讓 Web 網(wǎng)站上 的個人隱私變成一種僅供程序可理解的形式，以達(dá)到保護(hù)用戶隱私的 目的。
協(xié)議中對X-前綴的廢除
在HTTP等多種協(xié)議中，通過給非標(biāo)準(zhǔn)參數(shù)加上前綴X-，來區(qū)別于標(biāo)準(zhǔn)參數(shù)，并使那些非標(biāo)準(zhǔn)參數(shù)作為擴(kuò)展變成可能（如上面的響應(yīng)首部）。但是這種簡單粗暴的做法沒有任何好處，因此被提議停止。然而對已經(jīng)在使用中的X-前綴來說，不應(yīng)該要求其變更。
HTTP的缺點(diǎn)
- 通信使用明文（不加密），內(nèi)容可能被竊聽
- 不驗(yàn)證通信方的身份，因此有可能遭受偽裝
- 無法證明報文的完整性，所以內(nèi)容可能被篡改
HTTP+ 加密 + 認(rèn)證 + 完整性保護(hù) =HTTPS
HTTPS 并非是應(yīng)用層的一種新協(xié)議。只是 HTTP 通信接口部分用 SSL（Secure Socket Layer）和 TLS（Transport Layer Security）協(xié)議代 替而已。 通常，HTTP 直接和 TCP 通信。當(dāng)使用 SSL 時，則演變成先和 SSL 通 信，再由 SSL 和 TCP 通信了。簡言之，所謂 HTTPS，其實(shí)就是身披 SSL 協(xié)議這層外殼的 HTTP
在采用 SSL 后，HTTP 就擁有了 HTTPS 的加密、證書和完整性保護(hù) 這些功能。
SSL 是獨(dú)立于 HTTP 的協(xié)議，所以不光是 HTTP 協(xié)議，其他運(yùn)行在應(yīng) 用層的 SMTP 和 Telnet 等協(xié)議均可配合 SSL 協(xié)議使用。可以說 SSL 是 當(dāng)今世界上應(yīng)用最為廣泛的網(wǎng)絡(luò)安全技術(shù)。
加密
加密和解密同用一個密鑰的方式稱為共享密鑰加密（Common key crypto system），也被叫做對稱密鑰加密
共享密鑰加密的困境
以共享密鑰方式加密時必須將密鑰也發(fā)給對方。可究竟怎樣才能 安全地轉(zhuǎn)交？在互聯(lián)網(wǎng)上轉(zhuǎn)發(fā)密鑰時，如果通信被監(jiān)聽那么密鑰 就可會落入攻擊者之手，同時也就失去了加密的意義。另外還得 設(shè)法安全地保管接收到的密鑰。
公開密鑰加密使用一對非對稱的密鑰。一把叫做私有密鑰 （private key），另一把叫做公開密鑰（public key）。顧名思 義，私有密鑰不能讓其他任何人知道，而公開密鑰則可以隨意發(fā) 布，任何人都可以獲得。
HTTPS 采用混合加密機(jī)制
HTTPS 采用共享密鑰加密和公開密鑰加密兩者并用的混合加密 機(jī)制。若密鑰能夠?qū)崿F(xiàn)安全交換，那么有可能會考慮僅使用公開 密鑰加密來通信。
但是公開密鑰加密與共享密鑰加密相比，其處 理速度要慢。 所以應(yīng)充分利用兩者各自的優(yōu)勢，將多種方法組合起來用于通 信。在交換密鑰環(huán)節(jié)使用公開密鑰加密方式，之后的建立通信交 換報文階段則使用共享密鑰加密方式。
證明公開密鑰正確性的證書
遺憾的是，公開密鑰加密方式還是存在一些問題的。那就是無法證明 公開密鑰本身就是貨真價實(shí)的公開密鑰。比如，正準(zhǔn)備和某臺服務(wù)器 建立公開密鑰加密方式下的通信時，如何證明收到的公開密鑰就是原 本預(yù)想的那臺服務(wù)器發(fā)行的公開密鑰。或許在公開密鑰傳輸途中，真 正的公開密鑰已經(jīng)被攻擊者替換掉了。
為了解決上述問題，可以使用由數(shù)字證書認(rèn)證機(jī)構(gòu)（CA，Certificate Authority）和其相關(guān)機(jī)關(guān)頒發(fā)的公開密鑰證書
服務(wù)器會將這份由數(shù)字證書認(rèn)證機(jī)構(gòu)頒發(fā)的公鑰證書發(fā)送給客戶端， 以進(jìn)行公開密鑰加密方式通信。
公鑰證書也可叫做數(shù)字證書或直接稱 為證書。 接到證書的客戶端可使用數(shù)字證書認(rèn)證機(jī)構(gòu)的公開密鑰，對那張證書 上的數(shù)字簽名進(jìn)行驗(yàn)證，一旦驗(yàn)證通過，客戶端便可明確兩件事：
- 認(rèn)證服務(wù)器的公開密鑰的是真實(shí)有效的數(shù)字證書認(rèn)證機(jī)構(gòu)。
- 服務(wù)器的公開密鑰是值得信賴的。
此處認(rèn)證機(jī)關(guān)的公開密鑰必須安全地轉(zhuǎn)交給客戶端。使用通信方式 時，如何安全轉(zhuǎn)交是一件很困難的事，因此，多數(shù)瀏覽器開發(fā)商發(fā)布 版本時，會事先在內(nèi)部植入常用認(rèn)證機(jī)關(guān)的公開密鑰。
HTTPS 的通信步驟
- 步驟 1： 客戶端通過發(fā)送 Client Hello 報文開始 SSL 通信。報文中包 含客戶端支持的 SSL 的指定版本、加密組件（Cipher Suite）列表（所 使用的加密算法及密鑰長度等）。
- 步驟 2： 服務(wù)器可進(jìn)行 SSL 通信時，會以 Server Hello 報文作為應(yīng) 答。和客戶端一樣，在報文中包含 SSL 版本以及加密組件。服務(wù)器的 加密組件內(nèi)容是從接收到的客戶端加密組件內(nèi)篩選出來的。
- 步驟 3： 之后服務(wù)器發(fā)送 Certificate 報文。報文中包含公開密鑰證 書。
- 步驟 4： 最后服務(wù)器發(fā)送 Server Hello Done 報文通知客戶端，最初階 段的 SSL 握手協(xié)商部分結(jié)束。
- 步驟 5： SSL 第一次握手結(jié)束之后，客戶端以 Client Key Exchange 報 文作為回應(yīng)。報文中包含通信加密中使用的一種被稱為 Pre-master secret 的隨機(jī)密碼串。該報文已用步驟 3 中的公開密鑰進(jìn)行加密。
- 步驟 6： 接著客戶端繼續(xù)發(fā)送 Change Cipher Spec 報文。該報文會提 示服務(wù)器，在此報文之后的通信會采用 Pre-master secret 密鑰加密。
- 步驟 7： 客戶端發(fā)送 Finished 報文。該報文包含連接至今全部報文的 整體校驗(yàn)值。這次握手協(xié)商是否能夠成功，要以服務(wù)器是否能夠正確 解密該報文作為判定標(biāo)準(zhǔn)。
- 步驟 8： 服務(wù)器同樣發(fā)送 Change Cipher Spec 報文。
- 步驟 9： 服務(wù)器同樣發(fā)送 Finished 報文。
- 步驟 10： 服務(wù)器和客戶端的 Finished 報文交換完畢之后，SSL 連接 就算建立完成。當(dāng)然，通信會受到 SSL 的保護(hù)。從此處開始進(jìn)行應(yīng)用 層協(xié)議的通信，即發(fā)送 HTTP 請求。
- 步驟 11： 應(yīng)用層協(xié)議通信，即發(fā)送 HTTP 響應(yīng)。
- 步驟 12： 最后由客戶端斷開連接。斷開連接時，發(fā)送 close_notify 報 文。上圖做了一些省略，這步之后再發(fā)送 TCP FIN 報文來關(guān)閉與 TCP 的通信。 在以上流程中，應(yīng)用層發(fā)送數(shù)據(jù)時會附加一種叫做 MAC（Message Authentication Code）的報文摘要。MAC 能夠查知報文是否遭到篡 改，從而保護(hù)報文的完整性。
SSL 和 TLS HTTPS 使用 SSL（Secure Socket Layer） 和 TLS（Transport Layer Security）這兩個協(xié)議。 SSL 技術(shù)最初是由瀏覽器開發(fā)商網(wǎng)景通信公司率先倡導(dǎo)的，開發(fā) 過 SSL3.0 之前的版本。目前主導(dǎo)權(quán)已轉(zhuǎn)移到 IETF（Internet Engineering Task Force，Internet 工程任務(wù)組）的手中。 IETF 以 SSL3.0 為基準(zhǔn)，后又制定了 TLS1.0、TLS1.1 和 TLS1.2。TSL 是以 SSL 為原型開發(fā)的協(xié)議，有時會統(tǒng)一稱該協(xié)議 為 SSL。當(dāng)前主流的版本是 SSL3.0 和 TLS1.0。 由于 SSL1.0 協(xié)議在設(shè)計之初被發(fā)現(xiàn)出了問題，就沒有實(shí)際投入 使用。SSL2.0 也被發(fā)現(xiàn)存在問題，所以很多瀏覽器直接廢除了 該協(xié)議版本。
轉(zhuǎn)載于:https://juejin.im/post/5cd16ba251882541cc70cbf8
總結(jié)
以上是生活随笔為你收集整理的《图解HTTP》核心知识总结的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Facebook 游戏开发更新文档 AP
- 下一篇： CSS属性（display）