HTTP協(xié)議,全稱(chēng)超文本傳輸協(xié)議(HyperText Transfer Protocol),是目前互聯(lián)網(wǎng)上應(yīng)用最為廣泛的一種網(wǎng)絡(luò)協(xié)議勿决,位于應(yīng)用層茫船。
一琅束、HTTP基礎(chǔ)
1.HTTP協(xié)議用于客戶(hù)端和服務(wù)端之間的通信
兩臺(tái)計(jì)算機(jī)之間使用HTTP協(xié)議通信時(shí)扭屁,必有一端是客戶(hù)端,另外一端是服務(wù)器端涩禀。其中請(qǐng)求訪(fǎng)問(wèn)資源的一端為客戶(hù)端料滥,提供資源響應(yīng)的一端稱(chēng)為服務(wù)器端。有時(shí)候兩臺(tái)計(jì)算機(jī)的角色可能會(huì)互換艾船,但是僅從一條通信路線(xiàn)來(lái)說(shuō)葵腹,客戶(hù)端和服務(wù)器端的角色是確定的。
2.通過(guò)請(qǐng)求和響應(yīng)的交換達(dá)成通信
HTTP協(xié)議規(guī)定屿岂,請(qǐng)求從客戶(hù)端發(fā)出践宴,最后服務(wù)器端響應(yīng)該請(qǐng)求并返回。
3.HTTP是不保存狀態(tài)的協(xié)議
HTTP是一種無(wú)狀態(tài)協(xié)議爷怀。協(xié)議自身不對(duì)請(qǐng)求和響應(yīng)之間的通信狀態(tài)進(jìn)行保存阻肩。也就是說(shuō)在 HTTP 這個(gè)級(jí)別,協(xié)議對(duì)于發(fā)送過(guò)的請(qǐng)求或響應(yīng)都不做持久化處理运授。這是為了更快地處理大量事務(wù)烤惊,確保協(xié)議的可伸縮性,而特意把 HTTP 協(xié)議設(shè)計(jì)成如此簡(jiǎn)單的吁朦∑馐遥可是隨著 Web 的不斷發(fā)展,我們的很多業(yè)務(wù)都需要對(duì)通信狀態(tài)進(jìn)行保存逗宜。于是我們引入了 Cookie 技術(shù)雄右。有了 Cookie 再用 HTTP 協(xié)議通信,就可以管理狀態(tài)了纺讲。
4.請(qǐng)求URI定位資源
HTTP協(xié)議使用 URI 定位互聯(lián)網(wǎng)上的資源不脯。正是因?yàn)?URI 的特定功能,在互聯(lián)網(wǎng)上任意位置的資源都能訪(fǎng)問(wèn)到刻诊。
5.告知服務(wù)器意圖的 HTTP 方法
方法名 | 說(shuō)明 | 描述 | 支持版本 |
---|---|---|---|
GET | 獲取資源 | GET 方法用來(lái)請(qǐng)求訪(fǎng)問(wèn)已被 URI 識(shí)別的資源防楷。指定的資源經(jīng)服務(wù)器端解析后返回響應(yīng)內(nèi)容 | 1.0 1.1 |
POST | 傳輸實(shí)體主體 | POST 方法用來(lái)傳輸實(shí)體的主體。雖然 GET 也可以傳輸實(shí)體的主體则涯,但一般不用 GET 而用 POST复局,POST 的主要目的并不是獲取響應(yīng)的主體內(nèi)容 | 1.0 1.1 |
PUT | 傳輸文件 | PUT方法用來(lái)傳輸文件,要求再請(qǐng)求報(bào)文的主體中包含文件內(nèi)容粟判,然后保存到請(qǐng)求URI指定的位置 | 1.0 1.1 |
HEAD | 獲取報(bào)文首部 | HEAD 方法和 GET 方法一樣亿昏,只是不返回報(bào)文主體部分。用于確認(rèn) URI 的有效性及資源更新的日期時(shí)間等等 | 1.0 1.1 |
DELETE | 刪除文件 | 與 PUT 相反的方法档礁,DELETE 方法按請(qǐng)求 URI 刪除指定資源 | 1.0 1.1 |
OPTIONS | 詢(xún)問(wèn)支持的方法 | OPTIONS 用來(lái)查詢(xún)針對(duì)請(qǐng)求 URI 指定的資源支持的方法 | 1.1 |
TRACE | 追蹤路徑 | TRACE 方法是讓 Web 服務(wù)器將之前的請(qǐng)求通信返回給客戶(hù)端的方法角钩,TRACE 方法不常用,并且容易引發(fā) XST ( Cross-Site-Tracing ,跨站追蹤)攻擊递礼,所以通常更不會(huì)用到了 | 1.1 |
CONNECT | 要求用隧道協(xié)議連接代理 | CONNECT 方法要求在與代理服務(wù)器通信時(shí)建立隧道惨险,實(shí)現(xiàn)用隧道協(xié)議進(jìn)行 TCP 通信,主要使用 SSL ( Secure Sockets Layers 脊髓,安全套接層)和 TLS ( Transport Layer Security 辫愉,傳輸層安全)協(xié)議把通信內(nèi)容加密后經(jīng)網(wǎng)絡(luò)隧道傳輸 | 1.1 |
PATCH | 更新部分文件內(nèi)容 | 當(dāng)資源存在的時(shí)候,PATCH 用于資源的部分內(nèi)容的更新将硝,例如更新某一個(gè)字段恭朗。具體比如說(shuō)只更新用戶(hù)信息的電話(huà)號(hào)碼字段,而 PUT 用于更新某個(gè)資源較完整的內(nèi)容依疼,比如說(shuō)用戶(hù)要重填完整表單更新所有信息痰腮,后臺(tái)處理更新時(shí)可能只是保留內(nèi)部記錄 ID 不變。 當(dāng)資源不存在的時(shí)候律罢,PATCH 是修改原來(lái)的內(nèi)容膀值,也可能會(huì)產(chǎn)生一個(gè)新的版本。比如當(dāng)資源不存在的時(shí)候弟翘,PATCH 可能會(huì)去創(chuàng)建一個(gè)新的資源虫腋,這個(gè)意義上像是 saveOrUpdate 操作骄酗。而 PUT 只對(duì)已有資源進(jìn)行更新操作稀余,所以是 update 操作 | 1.1 |
6.持久鏈接節(jié)省通信量
HTTP協(xié)議的初始版本中,每進(jìn)行一個(gè) HTTP 通信都要斷開(kāi)一次 TCP 連接趋翻。比如使用瀏覽器瀏覽一個(gè)包含多張圖片的 HTML 頁(yè)面時(shí)睛琳,在發(fā)送請(qǐng)求訪(fǎng)問(wèn) HTML 頁(yè)面資源的同時(shí),也會(huì)請(qǐng)求該 HTML 頁(yè)面里包含的其他資源踏烙。因此师骗,每次的請(qǐng)求都會(huì)造成無(wú)謂的 TCP 連接建立和斷開(kāi),增加通信量的開(kāi)銷(xiāo)讨惩。
6.1 持久鏈接
為了解決上述 TCP 連接的問(wèn)題辟癌,HTTP/1.1 和部分 HTTP/1.0 想出了持久連接的方法。其特點(diǎn)是荐捻,只要任意一端沒(méi)有明確提出斷開(kāi)連接黍少,則保持 TCP 連接狀態(tài)。旨在建立一次 TCP 連接后進(jìn)行多次請(qǐng)求和響應(yīng)的交互处面。在 HTTP/1.1 中厂置,所有的連接默認(rèn)都是持久連接。它的好處在于減少了TCP連接的重復(fù)建立和斷開(kāi)所造成的額外開(kāi)銷(xiāo)魂角,減輕了服務(wù)器端的負(fù)載昵济。
6.2管線(xiàn)化(pipelining)
持久連接使得多數(shù)請(qǐng)求以管線(xiàn)化方式發(fā)送成為可能。以前發(fā)送請(qǐng)求后需等待并接收到響應(yīng),才能發(fā)送下一個(gè)請(qǐng)求访忿。管線(xiàn)化技術(shù)出現(xiàn)后瞧栗,不用等待亦可發(fā)送下一個(gè)請(qǐng)求。這樣就能做到同時(shí)并行發(fā)送多個(gè)請(qǐng)求醉顽,而不需要一個(gè)接一個(gè)地等待響應(yīng)了沼溜。比如,當(dāng)請(qǐng)求一個(gè)包含多張圖片的 HTML 頁(yè)面時(shí)游添,與挨個(gè)連接相比系草,用持久連接可以讓請(qǐng)求更快結(jié)束。而管線(xiàn)化技術(shù)要比持久連接速度更快唆涝。請(qǐng)求數(shù)越多找都,時(shí)間差就越明顯。
7.使用Cookie的狀態(tài)管理
Cookie 技術(shù)通過(guò)在請(qǐng)求和響應(yīng)報(bào)文中寫(xiě)入 Cookie 信息來(lái)控制客戶(hù)端的狀態(tài)廊酣。Cookie 會(huì)根據(jù)從服務(wù)器端發(fā)送的響應(yīng)報(bào)文內(nèi)的一個(gè)叫做 Set-Cookie 的首部字段信息能耻,通知客戶(hù)端保存Cookie。當(dāng)下次客戶(hù)端再往該服務(wù)器發(fā)送請(qǐng)求時(shí)亡驰,客戶(hù)端會(huì)自動(dòng)在請(qǐng)求報(bào)文中加入 Cookie 值后發(fā)送出去晓猛。服務(wù)器端發(fā)現(xiàn)客戶(hù)端發(fā)送過(guò)來(lái)的 Cookie 后,會(huì)去檢查究竟是從哪一個(gè)客戶(hù)端發(fā)來(lái)的連接請(qǐng)求凡辱,然后對(duì)比服務(wù)器上的記錄戒职,最后得到之前的狀態(tài)信息。
二透乾、HTTP工作流程
2.1 TCP/IP通信傳輸流
HTTP協(xié)議是站在在TCP/IP協(xié)議肩膀上的洪燥,從HTTP往下看,是TCP協(xié)議保證了運(yùn)輸?shù)目煽啃匀槲冢荌P協(xié)議保證了數(shù)據(jù)可以達(dá)到目標(biāo)地址捧韵,是以太網(wǎng)協(xié)議在局域網(wǎng)內(nèi)傳遞信息。所以說(shuō)HTTP工作流程汉操,先談TCP/IP通信傳輸流再来。
利用 TCP/IP 協(xié)議族進(jìn)行網(wǎng)絡(luò)通信時(shí),會(huì)通過(guò)分層順序與對(duì)方進(jìn)行通信磷瘤。發(fā)送端從應(yīng)用層往下走芒篷,接收端則從鏈路層往上走。
- 首先作為發(fā)送端的客戶(hù)端在應(yīng)用層(HTTP 協(xié)議)發(fā)出一個(gè)想看某個(gè) Web 頁(yè)面的 HTTP 請(qǐng)求膀斋。
- 為了傳輸方便梭伐,在傳輸層(TCP 協(xié)議)把從應(yīng)用層處收到的數(shù)據(jù)(HTTP 請(qǐng)求報(bào)文)進(jìn)行分割,并在各個(gè)報(bào)文上打上標(biāo)記序號(hào)及端口號(hào)后轉(zhuǎn)發(fā)給網(wǎng)絡(luò)層仰担。
- 在網(wǎng)絡(luò)層(IP 協(xié)議)糊识,增加作為通信目的地的 MAC 地址后轉(zhuǎn)發(fā)給鏈路層绩社。這樣一來(lái),發(fā)往網(wǎng)絡(luò)的通信請(qǐng)求就準(zhǔn)備齊全了赂苗。
- 接收端的服務(wù)器在鏈路層接收到數(shù)據(jù)愉耙,按序往上層發(fā)送,一直到應(yīng)用層拌滋。當(dāng)傳輸?shù)綉?yīng)用層朴沿,才能算真正接收到由客戶(hù)端發(fā)送過(guò)來(lái)的 HTTP請(qǐng)求。
2.2 HTTP請(qǐng)求流程
- 發(fā)送端在層與層之間傳輸數(shù)據(jù)時(shí)败砂,每經(jīng)過(guò)一層時(shí)必會(huì)被打上該層所屬的頭部信息赌渣。
- 接收端在層與層之間傳輸數(shù)據(jù)時(shí),每經(jīng)過(guò)一層時(shí)會(huì)把對(duì)應(yīng)的頭部消去昌犹。
具體介紹如下:
- 地址解析
比如我們用百度搜索swift
http://www.baidu.com/baidu?wd=swift
協(xié)議名:http坚芜。這里指要發(fā)出的是什么協(xié)議。
主機(jī)名:www.baidu.com斜姥。通過(guò)DNS解析鸿竖,我們可以把主機(jī)名解析成服務(wù)器的IP地址。
請(qǐng)求文件名:baidu铸敏。當(dāng)我們?cè)L問(wèn)到服務(wù)器后缚忧,就可以通過(guò)文件名請(qǐng)求指定的文件。
請(qǐng)求參數(shù):wd=swift杈笔。即使同一個(gè)網(wǎng)頁(yè)闪水,可能針對(duì)不同的用戶(hù),服務(wù)器要返回給客戶(hù)端的信息也是不一樣的 桩撮。而服務(wù)器就是通過(guò)URL中“?”后面攜帶的參數(shù)不同來(lái)響應(yīng)不同的用戶(hù)或者同一個(gè)用戶(hù)的不同請(qǐng)求的敦第。
- 封裝HTTP 請(qǐng)求
這一步把上面寫(xiě)的 URL 以及本機(jī)的一些信息封裝成一個(gè) HTTP 請(qǐng)求數(shù)據(jù)包 - 封裝 TCP 包
第三步就是封裝 TCP 包 , 建立 TCP 連接 , 也就是常說(shuō)的"三次握手"峰弹。 - 客戶(hù)端發(fā)送請(qǐng)求命令
在連接建立之后 , 客戶(hù)端發(fā)送 HTTP 請(qǐng)求到服務(wù)端與請(qǐng)求相關(guān)的信息都會(huì)包含在請(qǐng)求頭和請(qǐng)求體中發(fā)送給服務(wù)器端 店量。 - 服務(wù)器端響應(yīng)
服務(wù)器端在收到請(qǐng)求之后 , 根據(jù)客戶(hù)端的請(qǐng)求發(fā)送給客戶(hù)端相應(yīng)的信息 , 相關(guān)的響應(yīng)信息都會(huì)放在響應(yīng)頭和響應(yīng)體中。 - 關(guān)閉連接
服務(wù)器端在發(fā)送完響應(yīng)之后 , 就會(huì)關(guān)閉連接 , 如果過(guò)客戶(hù)端的請(qǐng)求的頭部信息中有 Connection-alive , 那么客戶(hù)端在響應(yīng)完這個(gè)請(qǐng)求之后不會(huì)關(guān)閉連接 , 知道客戶(hù)端的所有請(qǐng)求都響應(yīng)完畢 , 才會(huì)關(guān)閉連接 , 這樣大大節(jié)省了帶寬和 IO 資源鞠呈。
三融师、HTTP協(xié)議報(bào)文結(jié)構(gòu)
1.報(bào)文
用于 HTTP 協(xié)議交互的信息被稱(chēng)為 HTTP 報(bào)文。請(qǐng)求端(客戶(hù)端)的 HTTP 報(bào)文叫做請(qǐng)求報(bào)文蚁吝;響應(yīng)端(服務(wù)器端)的叫做響應(yīng)報(bào)文旱爆。HTTP 報(bào)文本身是由多行(用 CR+LF 作換行符)數(shù)據(jù)構(gòu)成的字符串文本。
2.報(bào)文結(jié)構(gòu)
HTTP 報(bào)文大致可分為報(bào)文首部和報(bào)文主體兩部分窘茁。兩者由最初出現(xiàn)的空行(CR+LF)來(lái)劃分怀伦。通常,并不一定有報(bào)文主體山林。
報(bào)文結(jié)構(gòu)如下:
3.請(qǐng)求報(bào)文及響應(yīng)報(bào)文的結(jié)構(gòu)
上面是請(qǐng)求報(bào)文房待,下面是響應(yīng)報(bào)文。
上面是請(qǐng)求報(bào)文實(shí)例,下面是響應(yīng)報(bào)文實(shí)例桑孩。
請(qǐng)求報(bào)文和響應(yīng)報(bào)文的首部?jī)?nèi)容由以下數(shù)據(jù)組成拜鹤。
- 請(qǐng)求行:包含用戶(hù)請(qǐng)求的方法,請(qǐng)求URI和HTTP版本流椒。
- 狀態(tài)行:包含表明響應(yīng)結(jié)果的狀態(tài)碼敏簿,原因短語(yǔ)和HTTP版本。
- 首部字段:包含表示請(qǐng)求和響應(yīng)的各種條件和屬性的各類(lèi)首部宣虾。一般有四種首部惯裕,分別是:通用首部、請(qǐng)求首部绣硝、響應(yīng)首部和實(shí)體首部轻猖。
- 其他:可能包含HTTP的RFC里未定義的首部(Cookie等)。
舉個(gè)例子:
我們用Chrome瀏覽器打開(kāi)百度域那,然后對(duì)當(dāng)前網(wǎng)頁(yè)進(jìn)行檢查咙边,右鍵選擇檢查。然后刷新當(dāng)前頁(yè)面次员,選擇Netword
選項(xiàng)败许,就可以看到當(dāng)前頁(yè)面網(wǎng)絡(luò)活動(dòng)情況。查看www.baidu.com
:
我們來(lái)看一下淑蔚,這里有什么:
General:
Request URL: https://www.baidu.com/
Request Method: GET
Status Code: 200 OK
Remote Address: 180.97.33.108:443
Referrer Policy: no-referrer-when-downgrade
Response Headers:
HTTP/1.1 200 OK
Bdpagetype: 1
Bdqid: 0xa9952ef000020d8a
Cache-Control: private
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/html
Cxy_all: baidu+9cadcdf18d354de5e0816c739f51f361
Date: Tue, 30 Oct 2018 08:50:53 GMT
Expires: Tue, 30 Oct 2018 08:50:27 GMT
Server: BWS/1.1
Set-Cookie: delPer=0; path=/; domain=.baidu.com
Set-Cookie: BDSVRTM=0; path=/
Set-Cookie: BD_HOME=0; path=/
Set-Cookie: H_PS_PSSID=26524_1420_21093_27400_26350; path=/; domain=.baidu.com
Strict-Transport-Security: max-age=172800
Vary: Accept-Encoding
X-Ua-Compatible: IE=Edge,chrome=1
Transfer-Encoding: chunked
Request Headers:
GET / HTTP/1.1
Host: www.baidu.com
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.77 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9,zh-TW;q=0.8
Cookie: BAIDUID=0A51A4710C9C0407204028C7D18379A0:FG=1; BIDUPSID=0A51A4710C9C0407204028C7D18379A0; PSTM=1529891328; BD_UPN=123253; MCITY=-315%3A; ispeed_lsm=3; delPer=0; BD_HOME=0; H_PS_PSSID=26524_1420_21093_27400_26350; BD_CK_SAM=1; PSINO=3
四市殷、HTTP 報(bào)文首部字段具體分析
HTTP首部字段是構(gòu)成HTTP報(bào)文的要素之一。在客戶(hù)端與服務(wù)端之間以HTTP協(xié)議進(jìn)行通信的過(guò)程中刹衫,無(wú)論是請(qǐng)求還是響應(yīng)都會(huì)使用首部字段醋寝,它能起到傳遞額外重要信息的作用。比如給瀏覽器和服務(wù)器提供報(bào)文主體大小带迟、所使用的語(yǔ)言音羞、認(rèn)證信息等內(nèi)容。
1. HTTP首部字段結(jié)構(gòu)
HTTP首部字段是由首部字段名和字段值構(gòu)成仓犬,中間用冒號(hào)“:”分開(kāi)嗅绰。比如上面我們看到的:
Host: www.baidu.com
Connection: keep-alive
Pragma: no-cache
2. 4種HTTP首部字段類(lèi)型
HTTP首部字段根據(jù)實(shí)際用途可以分為以下4種:
- 通用首部字段:請(qǐng)求報(bào)文和響應(yīng)報(bào)文兩方都會(huì)使用的 首部。
- 請(qǐng)求首部字段:從客戶(hù)端向服務(wù)器端發(fā)送請(qǐng)求報(bào)文時(shí)使用的首部搀继。補(bǔ)充了請(qǐng)求的附加內(nèi)容窘面、客戶(hù)端信息、響應(yīng)內(nèi)容相關(guān)優(yōu)先級(jí)等信息叽躯。
- 響應(yīng)首部字段:從服務(wù)器端向客戶(hù)端返回響應(yīng)報(bào)文時(shí)使用的首部财边。補(bǔ)充了響應(yīng)的附加內(nèi)容,也會(huì)要求客戶(hù)端附加額外的內(nèi)容信息点骑。
- 實(shí)體首部字段:針對(duì)請(qǐng)求報(bào)文和響應(yīng)報(bào)文的實(shí)體部分使用的首部酣难。補(bǔ)充了資源內(nèi)容更新時(shí)間等與實(shí)體有關(guān)的信息们童。
3.通用首部字段
首部字段名 | 說(shuō)明 |
---|---|
Cache-Control | 控制緩存的行為,用于隨報(bào)文傳送緩存的指示 |
Connection | 允許客戶(hù)端和服務(wù)器指定與請(qǐng)求/響應(yīng)連接有關(guān)的選項(xiàng) |
Date | 提供日期和時(shí)間標(biāo)志鲸鹦,說(shuō)明報(bào)文是什么時(shí)間創(chuàng)建的 |
Pragma | 報(bào)文指令慧库,另一種隨報(bào)文傳送指示的方式,但并不專(zhuān)用于緩存 |
MIME-Version | 給出了發(fā)送端使用的 MIME 版本 |
Trailer | 如果報(bào)文采用了分塊傳輸編碼(chunked transfer encoding)方式馋嗜,就可以用這個(gè)首部列出位于報(bào)文拖掛(trailer)部分的首部集合 |
Transfer- Encoding | 告知接收端為了保證報(bào)文的可靠傳輸齐板,對(duì)報(bào)文采用了什么編碼方式 |
Update | 給出了發(fā)送端可能想要 “升級(jí)” 使用的新版本或協(xié)議 |
Via | 顯示了報(bào)文經(jīng)過(guò)的中間節(jié)點(diǎn)(代理、網(wǎng)關(guān)) |
Warning | 錯(cuò)誤通知 |
3.1 Cache-Control
通過(guò)指定首部字段Cache-Control的指令葛菇,就能操作緩存的工作機(jī)制甘磨。
指令的參數(shù)是可選的,多個(gè)指令之間通過(guò)“眯停,”分隔济舆。
緩存請(qǐng)求指令
指令 | 參數(shù) | 說(shuō)明 |
---|---|---|
no-cache | 無(wú) | 強(qiáng)制向資源服務(wù)器再次驗(yàn)證 |
no-store | 無(wú) | 不緩存請(qǐng)求或響應(yīng)的任何內(nèi)容 |
max-age = [秒] | 必需 | 響應(yīng)的最大Age值 |
max-stale ( = [秒]) | 可忽略 | 接收已過(guò)期的響應(yīng) |
min-fresh = [秒] | 必需 | 期望在指定時(shí)間內(nèi)的響應(yīng)仍有效 |
no-transform | 無(wú) | 代理不可更改媒體類(lèi)型 |
only-if-cached | 無(wú) | 從緩存獲取資源 |
cache-extension | - | 新指令標(biāo)記(token) |
緩存響應(yīng)指令
指令 | 參數(shù) | 說(shuō)明 |
---|---|---|
public | 無(wú) | 可向任意方提供響應(yīng)的緩存 |
private | 可省略 | 僅向特定用戶(hù)返回響應(yīng) |
no-cache | 可省略 | 緩存前必須先確認(rèn)其有效性 |
no-store | 無(wú) | 不緩存請(qǐng)求或響應(yīng)的任何內(nèi)容 |
no-transform | 無(wú) | 代理不可更改媒體類(lèi)型 |
must-revalidate | 無(wú) | 可緩存但必須再向源服務(wù)器進(jìn)行確認(rèn) |
proxy-revalidate | 無(wú) | 要求中間緩存服務(wù)器對(duì)緩存的響應(yīng)有效性再進(jìn)行確認(rèn) |
max-age = [秒] | 必需 | 響應(yīng)的最大Age值 |
s-max-age = [秒] | 必須 | 公共緩存服務(wù)器響應(yīng)的最大Age值 |
cache-extension | - | 新指令標(biāo)記(token) |
4. 請(qǐng)求首部字段
首部字段名 | 說(shuō)明 |
---|---|
Accept | 用戶(hù)可處理的媒體類(lèi)型 |
Accept- Charset | 優(yōu)先的字符集 |
Accept- Encoding | 優(yōu)先的編碼內(nèi)容 |
Accept- Language | 優(yōu)先的語(yǔ)言 |
TE | 傳輸編碼的優(yōu)先級(jí) |
Expect | 期待服務(wù)器的特定行為 |
If-Match | 比較實(shí)體標(biāo)記(ETAG) |
If-Modified-Since | 比較資源的更新時(shí)間 |
If-None-Match | 比較實(shí)體標(biāo)記(與If-Match相反) |
If-Range | 資源未更新時(shí)發(fā)送實(shí)體Btye的范圍請(qǐng)求 |
If-Unmodified-Since | 比較資源的更新時(shí)間(與If-Modified-Since相反) |
Range | 實(shí)體的字節(jié)范圍請(qǐng)求 |
Authorization | WEB認(rèn)證信息 |
Cookie | 客戶(hù)端用它向服務(wù)器傳送一個(gè)令牌 |
Cookie2 | 用來(lái)說(shuō)明請(qǐng)求端支持的 cookie 版本 |
Max-Forward | 在通往源端服務(wù)器的路徑上,將請(qǐng)求轉(zhuǎn)發(fā)給其他代理或網(wǎng)關(guān)的最大次數(shù) |
Proxy-Authorization | 代理服務(wù)器要求客戶(hù)端的認(rèn)證信息 |
5. 響應(yīng)首部字段
首部字段名 | 說(shuō)明 |
---|---|
Age | 推算資源創(chuàng)建經(jīng)過(guò)時(shí)間 |
Public | 服務(wù)器為其資源支持的請(qǐng)求方法列表 |
Retry-After | 對(duì)再次發(fā)起請(qǐng)求的時(shí)機(jī)要求 |
Title | 對(duì) HTML 文檔來(lái)說(shuō)莺债,就是 HTML 文檔 的源端給出的標(biāo)題 |
Warning | 比原因短語(yǔ)中更詳細(xì)一些的警告報(bào)文 |
Accept-Ranges | 服務(wù)器可接受的范圍類(lèi)型 |
Vary | 代理服務(wù)器的安裝信息 |
Proxy-Authenticate | 代理服務(wù)器對(duì)客戶(hù)端的認(rèn)證信息 |
Set-Cookie | 在客戶(hù)端設(shè)置滋觉,以便服務(wù)器對(duì)客戶(hù)端進(jìn)行標(biāo)識(shí) |
WWW-Authenticate | 服務(wù)器對(duì)客戶(hù)端的認(rèn)證信息 |
5. 實(shí)體首部字段
首部字段名 | 說(shuō)明 |
---|---|
Allow | 資源可支持的HTTP方法 |
Location | 告知客戶(hù)端實(shí)體實(shí)際上位于何處 |
Content-Base16 | 解析主體中的相對(duì) URL 時(shí)使用的基礎(chǔ) URL |
Content-Encoding | 實(shí)體主體適用的編碼方式 |
Content-Language | 實(shí)體主體的自然語(yǔ)言 |
Content-Length | 實(shí)體主體的大小(單位:字節(jié)) |
Content-Location | 替代對(duì)應(yīng)資源的URI |
Content-MD5 | 實(shí)體主體的報(bào)文摘要 |
Content-Range | 實(shí)體主體的位置范圍 |
ETag | 與此實(shí)體相關(guān)的實(shí)體標(biāo)記 |
Expires | 實(shí)體主體的過(guò)期時(shí)間 |
Last-Modified | 資源的最后修改日期時(shí)間 |
6. 其他首部字段
HTTP 首部字段是可以自行擴(kuò)展的。所以在 Web 服務(wù)器和瀏覽器的應(yīng)用上齐邦,會(huì)出現(xiàn)各種非標(biāo)準(zhǔn)的首部字段椎侠。以下是最為常用的首部字段:
6.1 X-Frame-Options
X-Frame-Options 屬于 HTTP 響應(yīng)首部,用于控制網(wǎng)站內(nèi)容在其他 Web 網(wǎng)站的 Frame 標(biāo)簽內(nèi)的顯示問(wèn)題措拇。其主要目的是為了防止點(diǎn)擊劫持(clickjacking)攻擊我纪。首部字段 X-Frame-Options 有以下兩個(gè)可指定的字段值:
- DENY:拒絕
- SAMEORIGIN:僅同源域名下的頁(yè)面(Top-level-browsing-context)匹配時(shí)許可
6.2 X-XSS-Protection
X-XSS-Protection 屬于 HTTP 響應(yīng)首部,它是針對(duì)跨站腳本攻擊(XSS)的一種對(duì)策丐吓,用于控制瀏覽器 XSS 防護(hù)機(jī)制的開(kāi)關(guān)浅悉。首部字段 X-XSS-Protection 可指定的字段值如下:
- 0:將 XSS 過(guò)濾設(shè)置成無(wú)效狀態(tài)
- 1:將 XSS 過(guò)濾設(shè)置成有效狀態(tài)
6.3 DNT
DNT 屬于 HTTP 請(qǐng)求首部,其中 DNT 是 Do Not Track 的簡(jiǎn)稱(chēng)券犁,意為拒絕個(gè)人信息被收集术健,是表示拒絕被精準(zhǔn)廣告追蹤的一種方法。首部字段 DNT 可指定的字段值如下:
- 0:同意被追蹤
- 1:拒絕被追蹤
6.4 P3P
P3P 屬于 HTTP 響應(yīng)首部族操,通過(guò)利用 P3P(The Platform for Privacy Preferences苛坚,在線(xiàn)隱私偏好平臺(tái))技術(shù)比被,可以讓 Web 網(wǎng)站上的個(gè)人隱私變成一種僅供程序可理解的形式色难,以達(dá)到保護(hù)用戶(hù)隱私的目的。要進(jìn)行 P3P 的設(shè)定等缀,需按以下操作步驟進(jìn)行:
- 創(chuàng)建 P3P 隱私
- 創(chuàng)建 P3P 隱私對(duì)照文件后枷莉,保存命名在 /w3c/p3p.xml
- 從 P3P 隱私中新建 Compact policies 后,輸出到 HTTP 響應(yīng)中
五尺迂、HTTP響應(yīng)狀態(tài)嗎
狀態(tài)碼的職責(zé)是當(dāng)客戶(hù)端向服務(wù)器端發(fā)送請(qǐng)求時(shí)笤妙,描述返回的請(qǐng)求結(jié)果冒掌。借助狀態(tài)碼,用戶(hù)可以知道服務(wù)器端是正常處理了請(qǐng)求蹲盘,還是出現(xiàn)了錯(cuò)誤股毫。
1. 狀態(tài)碼類(lèi)別
類(lèi)別 | 原因 | |
---|---|---|
1XX | nformational(信息性狀態(tài)碼) | 接收的請(qǐng)求正在處理 |
2XX | Success(成功狀態(tài)碼) | 請(qǐng)求正常處理完畢 |
3XX | Redirection(重定向狀態(tài)碼) | 需要進(jìn)行附加操作以完成請(qǐng)求 |
4XX | Client Error(客戶(hù)端錯(cuò)誤狀態(tài)碼) | 服務(wù)器無(wú)法處理請(qǐng)求 |
5XX | Server Error(服務(wù)器錯(cuò)誤狀態(tài)碼 | 服務(wù)器處理請(qǐng)求出錯(cuò) |
2. 狀態(tài)具體描述
在 RFC2616 中定義了 40 種 HTTP 狀態(tài)碼,webDAV ( Web-based Distributed Authoring and Versioning召衔,基于萬(wàn)維網(wǎng)的分布式創(chuàng)作和版本控制)在 RFC4918 和 RFC5842 中铃诬,定義了一些特殊的狀態(tài)碼,在 RFC2518苍凛、RFC2817趣席、RFC2295、RFC2774醇蝴、RFC6585 中還額外定義了一些附加的 HTTP 狀態(tài)碼宣肚。總共有 60+ 種悠栓。具體鏈接可以見(jiàn) HTTP狀態(tài)碼 (wikipedia)霉涨。雖然狀態(tài)種類(lèi)繁多,但實(shí)際上經(jīng)常使用的大概有14種惭适,我們簡(jiǎn)單介紹一下這14種嵌纲。
消息 | 描述 |
---|---|
200 OK | 請(qǐng)求成功(其后是對(duì)GET和POST請(qǐng)求的應(yīng)答文檔) |
204 No Content | 沒(méi)有新文檔。瀏覽器應(yīng)該繼續(xù)顯示原來(lái)的文檔 |
206 Partial Content | 客戶(hù)發(fā)送了一個(gè)帶有Range頭的GET請(qǐng)求腥沽,服務(wù)器完成了它 |
301 Moved Permanently | 所請(qǐng)求的頁(yè)面已經(jīng)轉(zhuǎn)移至新的url |
302 Found | 所請(qǐng)求的頁(yè)面已經(jīng)臨時(shí)轉(zhuǎn)移至新的url |
303 See Other | 所請(qǐng)求的頁(yè)面可在別的url下被找到 |
304 Not Modified | 未按預(yù)期修改文檔 |
307 Temporary Redirect | 被請(qǐng)求的頁(yè)面已經(jīng)臨時(shí)移至新的url |
400 Bad Request | 服務(wù)器未能理解請(qǐng)求 |
401 Unauthorized | 被請(qǐng)求的頁(yè)面需要用戶(hù)名和密碼 |
403 Forbidden | 對(duì)被請(qǐng)求頁(yè)面的訪(fǎng)問(wèn)被禁止 |
404 Not Found | 服務(wù)器無(wú)法找到被請(qǐng)求的頁(yè)面 |
500 Internal Server Error | 請(qǐng)求未完成逮走,服務(wù)器遇到不可預(yù)知的情況 |
503 Service Unavailable | 請(qǐng)求未完成,服務(wù)器臨時(shí)過(guò)載或當(dāng)機(jī) |