網(wǎng)絡(luò)編程 - HTTP協(xié)議

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通信傳輸流.png

利用 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)求流程

HTTP請(qǐng)求流程.png
  • 發(fā)送端在層與層之間傳輸數(shù)據(jù)時(shí)败砂,每經(jīng)過(guò)一層時(shí)必會(huì)被打上該層所屬的頭部信息赌渣。
  • 接收端在層與層之間傳輸數(shù)據(jù)時(shí),每經(jīng)過(guò)一層時(shí)會(huì)把對(duì)應(yīng)的頭部消去昌犹。

具體介紹如下:

  1. 地址解析
    比如我們用百度搜索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)求的敦第。

  1. 封裝HTTP 請(qǐng)求
    這一步把上面寫(xiě)的 URL 以及本機(jī)的一些信息封裝成一個(gè) HTTP 請(qǐng)求數(shù)據(jù)包
  2. 封裝 TCP 包
    第三步就是封裝 TCP 包 , 建立 TCP 連接 , 也就是常說(shuō)的"三次握手"峰弹。
  3. 客戶(hù)端發(fā)送請(qǐng)求命令
    在連接建立之后 , 客戶(hù)端發(fā)送 HTTP 請(qǐng)求到服務(wù)端與請(qǐng)求相關(guān)的信息都會(huì)包含在請(qǐng)求頭和請(qǐng)求體中發(fā)送給服務(wù)器端 店量。
  4. 服務(wù)器端響應(yīng)
    服務(wù)器端在收到請(qǐng)求之后 , 根據(jù)客戶(hù)端的請(qǐng)求發(fā)送給客戶(hù)端相應(yīng)的信息 , 相關(guān)的響應(yīng)信息都會(huì)放在響應(yīng)頭和響應(yīng)體中。
  5. 關(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)如下:

HTTP報(bào)文結(jié)構(gòu).png

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

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

上面是請(qǐng)求報(bào)文房待,下面是響應(yīng)報(bào)文。


請(qǐng)求報(bào)文和響應(yīng)報(bào)文實(shí)例.png

上面是請(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:

例子.png

我們來(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)行:

  1. 創(chuàng)建 P3P 隱私
  2. 創(chuàng)建 P3P 隱私對(duì)照文件后枷莉,保存命名在 /w3c/p3p.xml
  3. 從 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ī)
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
  • 序言:七十年代末今阳,一起剝皮案震驚了整個(gè)濱河市师溅,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌盾舌,老刑警劉巖墓臭,帶你破解...
    沈念sama閱讀 222,378評(píng)論 6 516
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現(xiàn)場(chǎng)離奇詭異妖谴,居然都是意外死亡窿锉,警方通過(guò)查閱死者的電腦和手機(jī),發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 94,970評(píng)論 3 399
  • 文/潘曉璐 我一進(jìn)店門(mén)膝舅,熙熙樓的掌柜王于貴愁眉苦臉地迎上來(lái)嗡载,“玉大人,你說(shuō)我怎么就攤上這事仍稀⊙匝” “怎么了袱蚓?”我有些...
    開(kāi)封第一講書(shū)人閱讀 168,983評(píng)論 0 362
  • 文/不壞的土叔 我叫張陵疑俭,是天一觀的道長(zhǎng)。 經(jīng)常有香客問(wèn)我千康,道長(zhǎng),這世上最難降的妖魔是什么铲掐? 我笑而不...
    開(kāi)封第一講書(shū)人閱讀 59,938評(píng)論 1 299
  • 正文 為了忘掉前任拾弃,我火速辦了婚禮,結(jié)果婚禮上摆霉,老公的妹妹穿的比我還像新娘砸彬。我一直安慰自己,他們只是感情好斯入,可當(dāng)我...
    茶點(diǎn)故事閱讀 68,955評(píng)論 6 398
  • 文/花漫 我一把揭開(kāi)白布砂碉。 她就那樣靜靜地躺著,像睡著了一般刻两。 火紅的嫁衣襯著肌膚如雪增蹭。 梳的紋絲不亂的頭發(fā)上,一...
    開(kāi)封第一講書(shū)人閱讀 52,549評(píng)論 1 312
  • 那天磅摹,我揣著相機(jī)與錄音滋迈,去河邊找鬼。 笑死户誓,一個(gè)胖子當(dāng)著我的面吹牛饼灿,可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播帝美,決...
    沈念sama閱讀 41,063評(píng)論 3 422
  • 文/蒼蘭香墨 我猛地睜開(kāi)眼碍彭,長(zhǎng)吁一口氣:“原來(lái)是場(chǎng)噩夢(mèng)啊……” “哼!你這毒婦竟也來(lái)了悼潭?” 一聲冷哼從身側(cè)響起庇忌,我...
    開(kāi)封第一講書(shū)人閱讀 39,991評(píng)論 0 277
  • 序言:老撾萬(wàn)榮一對(duì)情侶失蹤,失蹤者是張志新(化名)和其女友劉穎舰褪,沒(méi)想到半個(gè)月后皆疹,有當(dāng)?shù)厝嗽跇?shù)林里發(fā)現(xiàn)了一具尸體,經(jīng)...
    沈念sama閱讀 46,522評(píng)論 1 319
  • 正文 獨(dú)居荒郊野嶺守林人離奇死亡占拍,尸身上長(zhǎng)有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 38,604評(píng)論 3 342
  • 正文 我和宋清朗相戀三年略就,在試婚紗的時(shí)候發(fā)現(xiàn)自己被綠了。 大學(xué)時(shí)的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片晃酒。...
    茶點(diǎn)故事閱讀 40,742評(píng)論 1 353
  • 序言:一個(gè)原本活蹦亂跳的男人離奇死亡表牢,死狀恐怖,靈堂內(nèi)的尸體忽然破棺而出掖疮,到底是詐尸還是另有隱情初茶,我是刑警寧澤,帶...
    沈念sama閱讀 36,413評(píng)論 5 351
  • 正文 年R本政府宣布浊闪,位于F島的核電站恼布,受9級(jí)特大地震影響,放射性物質(zhì)發(fā)生泄漏搁宾。R本人自食惡果不足惜折汞,卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 42,094評(píng)論 3 335
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望盖腿。 院中可真熱鬧爽待,春花似錦、人聲如沸翩腐。這莊子的主人今日做“春日...
    開(kāi)封第一講書(shū)人閱讀 32,572評(píng)論 0 25
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽(yáng)茂卦。三九已至何什,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間等龙,已是汗流浹背处渣。 一陣腳步聲響...
    開(kāi)封第一講書(shū)人閱讀 33,671評(píng)論 1 274
  • 我被黑心中介騙來(lái)泰國(guó)打工, 沒(méi)想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留蛛砰,地道東北人罐栈。 一個(gè)月前我還...
    沈念sama閱讀 49,159評(píng)論 3 378
  • 正文 我出身青樓,卻偏偏與公主長(zhǎng)得像泥畅,于是被迫代替她去往敵國(guó)和親荠诬。 傳聞我的和親對(duì)象是個(gè)殘疾皇子,可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 45,747評(píng)論 2 361

推薦閱讀更多精彩內(nèi)容