HTTP協(xié)議，全稱超文本傳輸協(xié)議(HyperText Transfer Protocol)，是目前互聯(lián)網(wǎng)上應(yīng)用最為廣泛的一種網(wǎng)絡(luò)協(xié)議，位于應(yīng)用層。

一、HTTP基礎(chǔ)

1.HTTP協(xié)議用于客戶端和服務(wù)端之間的通信

兩臺(tái)計(jì)算機(jī)之間使用HTTP協(xié)議通信時(shí)，必有一端是客戶端，另外一端是服務(wù)器端。其中請求訪問資源的一端為客戶端，提供資源響應(yīng)的一端稱為服務(wù)器端。有時(shí)候兩臺(tái)計(jì)算機(jī)的角色可能會(huì)互換，但是僅從一條通信路線來說，客戶端和服務(wù)器端的角色是確定的。

2.通過請求和響應(yīng)的交換達(dá)成通信

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

3.HTTP是不保存狀態(tài)的協(xié)議

HTTP是一種無狀態(tài)協(xié)議。協(xié)議自身不對請求和響應(yīng)之間的通信狀態(tài)進(jìn)行保存。也就是說在 HTTP 這個(gè)級別，協(xié)議對于發(fā)送過的請求或響應(yīng)都不做持久化處理。這是為了更快地處理大量事務(wù)，確保協(xié)議的可伸縮性，而特意把 HTTP 協(xié)議設(shè)計(jì)成如此簡單的?？墒请S著 Web 的不斷發(fā)展，我們的很多業(yè)務(wù)都需要對通信狀態(tài)進(jìn)行保存。于是我們引入了 Cookie 技術(shù)。有了 Cookie 再用 HTTP 協(xié)議通信，就可以管理狀態(tài)了。

4.請求URI定位資源

HTTP協(xié)議使用 URI 定位互聯(lián)網(wǎng)上的資源。正是因?yàn)?URI 的特定功能，在互聯(lián)網(wǎng)上任意位置的資源都能訪問到。

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

6.持久鏈接節(jié)省通信量

HTTP協(xié)議的初始版本中，每進(jìn)行一個(gè) HTTP 通信都要斷開一次 TCP 連接。比如使用瀏覽器瀏覽一個(gè)包含多張圖片的 HTML 頁面時(shí)，在發(fā)送請求訪問 HTML 頁面資源的同時(shí)，也會(huì)請求該 HTML 頁面里包含的其他資源。因此，每次的請求都會(huì)造成無謂的 TCP 連接建立和斷開，增加通信量的開銷。

6.1 持久鏈接

為了解決上述 TCP 連接的問題，HTTP/1.1 和部分 HTTP/1.0 想出了持久連接的方法。其特點(diǎn)是，只要任意一端沒有明確提出斷開連接，則保持 TCP 連接狀態(tài)。旨在建立一次 TCP 連接后進(jìn)行多次請求和響應(yīng)的交互。在 HTTP/1.1 中，所有的連接默認(rèn)都是持久連接。它的好處在于減少了TCP連接的重復(fù)建立和斷開所造成的額外開銷，減輕了服務(wù)器端的負(fù)載。

6.2管線化(pipelining)

持久連接使得多數(shù)請求以管線化方式發(fā)送成為可能。以前發(fā)送請求后需等待并接收到響應(yīng)，才能發(fā)送下一個(gè)請求。管線化技術(shù)出現(xiàn)后，不用等待亦可發(fā)送下一個(gè)請求。這樣就能做到同時(shí)并行發(fā)送多個(gè)請求，而不需要一個(gè)接一個(gè)地等待響應(yīng)了。比如，當(dāng)請求一個(gè)包含多張圖片的 HTML 頁面時(shí)，與挨個(gè)連接相比，用持久連接可以讓請求更快結(jié)束。而管線化技術(shù)要比持久連接速度更快。請求數(shù)越多，時(shí)間差就越明顯。

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

Cookie 技術(shù)通過在請求和響應(yīng)報(bào)文中寫入 Cookie 信息來控制客戶端的狀態(tài)。Cookie 會(huì)根據(jù)從服務(wù)器端發(fā)送的響應(yīng)報(bào)文內(nèi)的一個(gè)叫做 Set-Cookie 的首部字段信息，通知客戶端保存Cookie。當(dāng)下次客戶端再往該服務(wù)器發(fā)送請求時(shí)，客戶端會(huì)自動(dòng)在請求報(bào)文中加入 Cookie 值后發(fā)送出去。服務(wù)器端發(fā)現(xiàn)客戶端發(fā)送過來的 Cookie 后，會(huì)去檢查究竟是從哪一個(gè)客戶端發(fā)來的連接請求，然后對比服務(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)傳遞信息。所以說HTTP工作流程，先談TCP/IP通信傳輸流。

TCP:IP通信傳輸流.png

利用 TCP/IP 協(xié)議族進(jìn)行網(wǎng)絡(luò)通信時(shí)，會(huì)通過分層順序與對方進(jìn)行通信。發(fā)送端從應(yīng)用層往下走，接收端則從鏈路層往上走。

• 首先作為發(fā)送端的客戶端在應(yīng)用層（HTTP 協(xié)議）發(fā)出一個(gè)想看某個(gè) Web 頁面的 HTTP 請求。
• 為了傳輸方便，在傳輸層（TCP 協(xié)議）把從應(yīng)用層處收到的數(shù)據(jù)（HTTP 請求報(bào)文）進(jìn)行分割，并在各個(gè)報(bào)文上打上標(biāo)記序號及端口號后轉(zhuǎn)發(fā)給網(wǎng)絡(luò)層。
• 在網(wǎng)絡(luò)層（IP 協(xié)議），增加作為通信目的地的 MAC 地址后轉(zhuǎn)發(fā)給鏈路層。這樣一來，發(fā)往網(wǎng)絡(luò)的通信請求就準(zhǔn)備齊全了。
• 接收端的服務(wù)器在鏈路層接收到數(shù)據(jù)，按序往上層發(fā)送，一直到應(yīng)用層。當(dāng)傳輸?shù)綉?yīng)用層，才能算真正接收到由客戶端發(fā)送過來的 HTTP請求。

2.2 HTTP請求流程

HTTP請求流程.png

• 發(fā)送端在層與層之間傳輸數(shù)據(jù)時(shí)，每經(jīng)過一層時(shí)必會(huì)被打上該層所屬的頭部信息。
• 接收端在層與層之間傳輸數(shù)據(jù)時(shí)，每經(jīng)過一層時(shí)會(huì)把對應(yīng)的頭部消去。

具體介紹如下：

1. 地址解析
   比如我們用百度搜索swift

http://www.baidu.com/baidu?wd=swift

協(xié)議名：http。這里指要發(fā)出的是什么協(xié)議。
主機(jī)名：www.baidu.com。通過DNS解析，我們可以把主機(jī)名解析成服務(wù)器的IP地址。
請求文件名：baidu。當(dāng)我們訪問到服務(wù)器后，就可以通過文件名請求指定的文件。
請求參數(shù)：wd=swift。即使同一個(gè)網(wǎng)頁，可能針對不同的用戶，服務(wù)器要返回給客戶端的信息也是不一樣的 。而服務(wù)器就是通過URL中“?”后面攜帶的參數(shù)不同來響應(yīng)不同的用戶或者同一個(gè)用戶的不同請求的。

2. 封裝HTTP 請求
   這一步把上面寫的 URL 以及本機(jī)的一些信息封裝成一個(gè) HTTP 請求數(shù)據(jù)包
3. 封裝 TCP 包
   第三步就是封裝 TCP 包 , 建立 TCP 連接 , 也就是常說的"三次握手"。
4. 客戶端發(fā)送請求命令
   在連接建立之后 , 客戶端發(fā)送 HTTP 請求到服務(wù)端與請求相關(guān)的信息都會(huì)包含在請求頭和請求體中發(fā)送給服務(wù)器端 。
5. 服務(wù)器端響應(yīng)
   服務(wù)器端在收到請求之后 , 根據(jù)客戶端的請求發(fā)送給客戶端相應(yīng)的信息 , 相關(guān)的響應(yīng)信息都會(huì)放在響應(yīng)頭和響應(yīng)體中。
6. 關(guān)閉連接
   服務(wù)器端在發(fā)送完響應(yīng)之后 , 就會(huì)關(guān)閉連接 , 如果過客戶端的請求的頭部信息中有 Connection-alive , 那么客戶端在響應(yīng)完這個(gè)請求之后不會(huì)關(guān)閉連接 , 知道客戶端的所有請求都響應(yīng)完畢 , 才會(huì)關(guān)閉連接 , 這樣大大節(jié)省了帶寬和 IO 資源。

三、HTTP協(xié)議報(bào)文結(jié)構(gòu)

1.報(bào)文

用于 HTTP 協(xié)議交互的信息被稱為 HTTP 報(bào)文。請求端（客戶端）的 HTTP 報(bào)文叫做請求報(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）來劃分。通常，并不一定有報(bào)文主體。
報(bào)文結(jié)構(gòu)如下：

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

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

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

上面是請求報(bào)文，下面是響應(yīng)報(bào)文。

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

上面是請求報(bào)文實(shí)例，下面是響應(yīng)報(bào)文實(shí)例。
請求報(bào)文和響應(yīng)報(bào)文的首部內(nèi)容由以下數(shù)據(jù)組成。

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

舉個(gè)例子：
我們用Chrome瀏覽器打開百度，然后對當(dāng)前網(wǎng)頁進(jìn)行檢查，右鍵選擇檢查。然后刷新當(dāng)前頁面，選擇Netword選項(xiàng)，就可以看到當(dāng)前頁面網(wǎng)絡(luò)活動(dòng)情況。查看www.baidu.com:

例子.png

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)文的要素之一。在客戶端與服務(wù)端之間以HTTP協(xié)議進(jìn)行通信的過程中，無論是請求還是響應(yīng)都會(huì)使用首部字段，它能起到傳遞額外重要信息的作用。比如給瀏覽器和服務(wù)器提供報(bào)文主體大小、所使用的語言、認(rèn)證信息等內(nèi)容。

1. HTTP首部字段結(jié)構(gòu)

HTTP首部字段是由首部字段名和字段值構(gòu)成，中間用冒號“：”分開。比如上面我們看到的：

Host: www.baidu.com
Connection: keep-alive
Pragma: no-cache

2. 4種HTTP首部字段類型

HTTP首部字段根據(jù)實(shí)際用途可以分為以下4種：

• 通用首部字段：請求報(bào)文和響應(yīng)報(bào)文兩方都會(huì)使用的 首部。
• 請求首部字段：從客戶端向服務(wù)器端發(fā)送請求報(bào)文時(shí)使用的首部。補(bǔ)充了請求的附加內(nèi)容、客戶端信息、響應(yīng)內(nèi)容相關(guān)優(yōu)先級等信息。
• 響應(yīng)首部字段：從服務(wù)器端向客戶端返回響應(yīng)報(bào)文時(shí)使用的首部。補(bǔ)充了響應(yīng)的附加內(nèi)容，也會(huì)要求客戶端附加額外的內(nèi)容信息。
• 實(shí)體首部字段：針對請求報(bào)文和響應(yīng)報(bào)文的實(shí)體部分使用的首部。補(bǔ)充了資源內(nèi)容更新時(shí)間等與實(shí)體有關(guān)的信息。

3.通用首部字段

3.1 Cache-Control

通過指定首部字段Cache-Control的指令，就能操作緩存的工作機(jī)制。
指令的參數(shù)是可選的，多個(gè)指令之間通過“，”分隔。
緩存請求指令

緩存響應(yīng)指令

4. 請求首部字段

5. 響應(yīng)首部字段

5. 實(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)的顯示問題。其主要目的是為了防止點(diǎn)擊劫持（clickjacking）攻擊。首部字段 X-Frame-Options 有以下兩個(gè)可指定的字段值：

• DENY：拒絕
• SAMEORIGIN：僅同源域名下的頁面（Top-level-browsing-context）匹配時(shí)許可

6.2 X-XSS-Protection

X-XSS-Protection 屬于 HTTP 響應(yīng)首部，它是針對跨站腳本攻擊（XSS）的一種對策，用于控制瀏覽器 XSS 防護(hù)機(jī)制的開關(guān)。首部字段 X-XSS-Protection 可指定的字段值如下:

• 0：將 XSS 過濾設(shè)置成無效狀態(tài)
• 1：將 XSS 過濾設(shè)置成有效狀態(tài)

6.3 DNT

DNT 屬于 HTTP 請求首部，其中 DNT 是 Do Not Track 的簡稱，意為拒絕個(gè)人信息被收集，是表示拒絕被精準(zhǔn)廣告追蹤的一種方法。首部字段 DNT 可指定的字段值如下：

• 0：同意被追蹤
• 1：拒絕被追蹤

6.4 P3P

P3P 屬于 HTTP 響應(yīng)首部，通過利用 P3P（The Platform for Privacy Preferences，在線隱私偏好平臺(tái)）技術(shù)，可以讓 Web 網(wǎng)站上的個(gè)人隱私變成一種僅供程序可理解的形式，以達(dá)到保護(hù)用戶隱私的目的。要進(jìn)行 P3P 的設(shè)定，需按以下操作步驟進(jìn)行：

1. 創(chuàng)建 P3P 隱私
2. 創(chuàng)建 P3P 隱私對照文件后，保存命名在 /w3c/p3p.xml
3. 從 P3P 隱私中新建 Compact policies 后，輸出到 HTTP 響應(yīng)中

五、HTTP響應(yīng)狀態(tài)嗎

狀態(tài)碼的職責(zé)是當(dāng)客戶端向服務(wù)器端發(fā)送請求時(shí)，描述返回的請求結(jié)果。借助狀態(tài)碼，用戶可以知道服務(wù)器端是正常處理了請求，還是出現(xiàn)了錯(cuò)誤。

1. 狀態(tài)碼類別

2. 狀態(tài)具體描述

在 RFC2616 中定義了 40 種 HTTP 狀態(tài)碼，webDAV ( Web-based Distributed Authoring and Versioning，基于萬維網(wǎng)的分布式創(chuàng)作和版本控制)在 RFC4918 和 RFC5842 中，定義了一些特殊的狀態(tài)碼，在 RFC2518、RFC2817、RFC2295、RFC2774、RFC6585 中還額外定義了一些附加的 HTTP 狀態(tài)碼。總共有 60+ 種。具體鏈接可以見 HTTP狀態(tài)碼 (wikipedia)。雖然狀態(tài)種類繁多，但實(shí)際上經(jīng)常使用的大概有14種，我們簡單介紹一下這14種。