Http協(xié)議解析

一、概述

超文本傳輸協(xié)議（Hyper Text Transfer Protocol，簡(jiǎn)稱HTTP）是一種用于分布式、協(xié)作式和超媒體信息系統(tǒng)的應(yīng)用層協(xié)議。HTTP是萬(wàn)維網(wǎng)的數(shù)據(jù)通信的基礎(chǔ)。

1.1 發(fā)展歷史

起源：HTTP的發(fā)展是由蒂姆·伯納斯-李于1989年在歐洲核子研究組織（CERN）所發(fā)起。
標(biāo)準(zhǔn)制定：由萬(wàn)維網(wǎng)協(xié)會(huì)（W3C）和互聯(lián)網(wǎng)工程任務(wù)組（IETF）聯(lián)合協(xié)調(diào)，以RFC（請(qǐng)求評(píng)論）文檔形式發(fā)布
關(guān)鍵版本：
- HTTP/1.1（1999年6月，RFC2616）：目前應(yīng)用最廣泛的版本，奠定核心通信機(jī)制
- HTTP/2（2015年5月，RFC7540）：取代HTTP/1.1，優(yōu)化傳輸效率（多路復(fù)用、頭部壓縮等）

1.2 核心特性

應(yīng)用層協(xié)議：基于TCP/IP協(xié)議族，但不依賴特定傳輸層（僅要求下層提供可靠傳輸）
請(qǐng)求-響應(yīng)模型：客戶端主動(dòng)發(fā)起請(qǐng)求，服務(wù)器被動(dòng)響應(yīng)，無(wú)請(qǐng)求則無(wú)響應(yīng)
默認(rèn)端口：80（HTTP）、443（HTTPS，加密版）
通信角色：
- 客戶端（用戶代理）：瀏覽器、爬蟲等發(fā)起請(qǐng)求的終端
- 服務(wù)器（源服務(wù)器）：存儲(chǔ)HTML、圖像等資源并返回響應(yīng)的主機(jī)
- 中間層：代理服務(wù)器、網(wǎng)關(guān)、隧道等轉(zhuǎn)發(fā)請(qǐng)求/響應(yīng)的節(jié)點(diǎn)

二、工作原理

2.1 請(qǐng)求

HTTP協(xié)議定義Web客戶端如何從Web服務(wù)器請(qǐng)求Web頁(yè)面，以及服務(wù)器如何把Web頁(yè)面?zhèn)魉徒o客戶端。HTTP協(xié)議采用了請(qǐng)求/響應(yīng)模型。客戶端向服務(wù)器發(fā)送一個(gè)請(qǐng)求報(bào)文，請(qǐng)求報(bào)文包含請(qǐng)求的方法、URL、協(xié)議版本、請(qǐng)求頭部和請(qǐng)求數(shù)據(jù)。服務(wù)器以一個(gè)狀態(tài)行作為響應(yīng)，響應(yīng)的內(nèi)容包括協(xié)議的版本、成功或者錯(cuò)誤代碼、服務(wù)器信息、響應(yīng)頭部和響應(yīng)數(shù)據(jù)。

以下是HTTP請(qǐng)求/響應(yīng)的步驟：

客戶端連接到Web服務(wù)器
一個(gè)HTTP客戶端，通常是瀏覽器，與Web服務(wù)器的HTTP端口（默認(rèn)為80）建立一個(gè)TCP套接字連接。例如，http://www.baidu.com。
發(fā)送HTTP請(qǐng)求
通過(guò)TCP套接字，客戶端向Web服務(wù)器發(fā)送一個(gè)文本的請(qǐng)求報(bào)文，一個(gè)請(qǐng)求報(bào)文由請(qǐng)求行、請(qǐng)求頭部、空行和請(qǐng)求數(shù)據(jù)4部分組成。
服務(wù)器接受請(qǐng)求并返回HTTP響應(yīng)
Web服務(wù)器解析請(qǐng)求，定位請(qǐng)求資源。服務(wù)器將資源復(fù)本寫到TCP套接字，由客戶端讀取。一個(gè)響應(yīng)由狀態(tài)行、響應(yīng)頭部、空行和響應(yīng)數(shù)據(jù)4部分組成。
釋放連接TCP連接
若connection模式為close，則服務(wù)器主動(dòng)關(guān)閉TCP連接，客戶端被動(dòng)關(guān)閉連接，釋放TCP連接;若connection模式為keepalive，則該連接會(huì)保持一段時(shí)間，在該時(shí)間內(nèi)可以繼續(xù)接收請(qǐng)求;
客戶端瀏覽器解析HTML內(nèi)容
客戶端瀏覽器首先解析狀態(tài)行，查看表明請(qǐng)求是否成功的狀態(tài)代碼。然后解析每一個(gè)響應(yīng)頭，響應(yīng)頭告知以下為若干字節(jié)的HTML文檔和文檔的字符集。客戶端瀏覽器讀取響應(yīng)數(shù)據(jù)HTML，根據(jù)HTML的語(yǔ)法對(duì)其進(jìn)行格式化，并在瀏覽器窗口中顯示。

例如：在瀏覽器地址欄鍵入URL，按下回車之后會(huì)經(jīng)歷以下流程：

瀏覽器向DNS服務(wù)器請(qǐng)求解析該URL中的域名所對(duì)應(yīng)的IP地址;
解析出IP地址后，根據(jù)該IP地址和默認(rèn)端口80，和服務(wù)器建立TCP連接;
瀏覽器發(fā)出讀取文件(URL中域名后面部分對(duì)應(yīng)的文件)的HTTP請(qǐng)求，該請(qǐng)求報(bào)文作為TCP三次握手的第三個(gè)報(bào)文的數(shù)據(jù)發(fā)送給服務(wù)器;
服務(wù)器對(duì)瀏覽器請(qǐng)求作出響應(yīng)，并把對(duì)應(yīng)的html文本發(fā)送給瀏覽器;
釋放TCP連接;
瀏覽器將該html文本并顯示內(nèi)容;

http協(xié)議是基于TCP/IP協(xié)議之上的應(yīng)用層協(xié)議。

基于請(qǐng)求-響應(yīng)的模式

HTTP協(xié)議規(guī)定,請(qǐng)求從客戶端發(fā)出,最后服務(wù)器端響應(yīng)該請(qǐng)求并返回。換句話說(shuō),肯定是先從客戶端開(kāi)始建立通信的,服務(wù)器端在沒(méi)有接收到請(qǐng)求之前不會(huì)發(fā)送響應(yīng)

無(wú)狀態(tài)保存

HTTP是一種不保存狀態(tài),即無(wú)狀態(tài)(stateless)協(xié)議。HTTP協(xié)議自身不對(duì)請(qǐng)求和響應(yīng)之間的通信狀態(tài)進(jìn)行保存。也就是說(shuō)在HTTP這個(gè)級(jí)別,協(xié)議對(duì)于發(fā)送過(guò)的請(qǐng)求或響應(yīng)都不做持久化處理。

使用HTTP協(xié)議,每當(dāng)有新的請(qǐng)求發(fā)送時(shí),就會(huì)有對(duì)應(yīng)的新響應(yīng)產(chǎn)生。協(xié)議本身并不保留之前一切的請(qǐng)求或響應(yīng)報(bào)文的信息。這是為了更快地處理大量事務(wù),確保協(xié)議的可伸縮性,而特意把HTTP協(xié)議設(shè)計(jì)成如此簡(jiǎn)單的。可是,隨著Web的不斷發(fā)展,因無(wú)狀態(tài)而導(dǎo)致業(yè)務(wù)處理變得棘手的情況增多了。比如,用戶登錄到一家購(gòu)物網(wǎng)站,即使他跳轉(zhuǎn)到該站的其他頁(yè)面后,也需要能繼續(xù)保持登錄狀態(tài)。針對(duì)這個(gè)實(shí)例,網(wǎng)站為了能夠掌握是誰(shuí)送出的請(qǐng)求,需要保存用戶的狀態(tài)。HTTP/1.1雖然是無(wú)狀態(tài)協(xié)議,但為了實(shí)現(xiàn)期望的保持狀態(tài)功能,于是引入了Cookie技術(shù)。有了Cookie再用HTTP協(xié)議通信,就可以管理狀態(tài)了。有關(guān)Cookie的詳細(xì)內(nèi)容稍后講解。

無(wú)連接

無(wú)連接的含義是限制每次連接只處理一個(gè)請(qǐng)求。服務(wù)器處理完客戶的請(qǐng)求，并收到客戶的應(yīng)答后，即斷開(kāi)連接。采用這種方式可以節(jié)省傳輸時(shí)間，并且可以提高并發(fā)性能，不能和每個(gè)用戶建立長(zhǎng)久的連接，請(qǐng)求一次相應(yīng)一次，服務(wù)端和客戶端就中斷了。但是無(wú)連接有兩種方式，早期的http協(xié)議是一個(gè)請(qǐng)求一個(gè)響應(yīng)之后，直接就斷開(kāi)了，但是現(xiàn)在的http協(xié)議1.1版本不是直接就斷開(kāi)了，而是等幾秒鐘，這幾秒鐘是等什么呢，等著用戶有后續(xù)的操作，如果用戶在這幾秒鐘之內(nèi)有新的請(qǐng)求，那么還是通過(guò)之前的連接通道來(lái)收發(fā)消息，如果過(guò)了這幾秒鐘用戶沒(méi)有發(fā)送新的請(qǐng)求，那么就會(huì)斷開(kāi)連接，這樣可以提高效率，減少短時(shí)間內(nèi)建立連接的次數(shù)，因?yàn)榻⑦B接也是耗時(shí)的，默認(rèn)的好像是3秒中現(xiàn)在，但是這個(gè)時(shí)間是可以通過(guò)咱們后端的代碼來(lái)調(diào)整的，自己網(wǎng)站根據(jù)自己網(wǎng)站用戶的行為來(lái)分析統(tǒng)計(jì)出一個(gè)最優(yōu)的等待時(shí)間。

2.2 URL

超文本傳輸協(xié)議（HTTP）的統(tǒng)一資源定位符將從因特網(wǎng)獲取信息的五個(gè)基本元素包括在一個(gè)簡(jiǎn)單的地址中：

傳送協(xié)議。
層級(jí)URL標(biāo)記符號(hào)(為[//],固定不變)
訪問(wèn)資源需要的憑證信息（可省略）
服務(wù)器。（通常為域名，有時(shí)為IP地址）
端口號(hào)。（以數(shù)字方式表示，若為HTTP的默認(rèn)值“:80”可省略）
路徑。（以“/”字符區(qū)別路徑中的每一個(gè)目錄名稱）
查詢。（GET模式的窗體參數(shù)，以“?”字符為起點(diǎn)，每個(gè)參數(shù)以“&”隔開(kāi)，再以“=”分開(kāi)參數(shù)名稱與數(shù)據(jù)，通常以UTF8的URL編碼，避開(kāi)字符沖突的問(wèn)題）
片段。以“#”字符為起點(diǎn)

以http://www.baidu.com:80/news/index.html?id=250&page=1為例，其中：

http，是協(xié)議；
www.baidu.com，是服務(wù)器；
80，是服務(wù)器上的默認(rèn)網(wǎng)絡(luò)端口號(hào)，默認(rèn)不顯示；
/news/index.html，是路徑（URI：直接定位到對(duì)應(yīng)的資源）；
?id=250&page=1，是查詢。

大多數(shù)網(wǎng)頁(yè)瀏覽器不要求用戶輸入網(wǎng)頁(yè)中“http://”的部分，因?yàn)榻^大多數(shù)網(wǎng)頁(yè)內(nèi)容是超文本傳輸協(xié)議文件。同樣，“80”是超文本傳輸協(xié)議文件的常用端口號(hào)，因此一般也不必寫明。一般來(lái)說(shuō)用戶只要鍵入統(tǒng)一資源定位符的一部分（www.baidu.com:80/news/index.html?id=250&page=1）就可以了。

由于超文本傳輸協(xié)議允許服務(wù)器將瀏覽器重定向到另一個(gè)網(wǎng)頁(yè)地址，因此許多服務(wù)器允許用戶省略網(wǎng)頁(yè)地址中的部分，比如www。從技術(shù)上來(lái)說(shuō)這樣省略后的網(wǎng)頁(yè)地址實(shí)際上是一個(gè)不同的網(wǎng)頁(yè)地址，瀏覽器本身無(wú)法決定這個(gè)新地址是否通，服務(wù)器必須完成重定向的任務(wù)。

2.3 連接

在HTTP/1.0中默認(rèn)使用短連接。也就是說(shuō)，客戶端和服務(wù)器每進(jìn)行一次HTTP操作，就建立一次連接，任務(wù)結(jié)束就中斷連接。當(dāng)客戶端瀏覽器訪問(wèn)的某個(gè)HTML或其他類型的Web頁(yè)中包含有其他的Web資源（如JavaScript文件、圖像文件、CSS文件等），每遇到這樣一個(gè)Web資源，瀏覽器就會(huì)重新建立一個(gè)HTTP會(huì)話。

而從HTTP/1.1起，默認(rèn)使用長(zhǎng)連接，用以保持連接特性。使用長(zhǎng)連接的HTTP協(xié)議，會(huì)在響應(yīng)頭加入這行代碼：

Connection:keep-aliveCopy to clipboardErrorCopied

在使用長(zhǎng)連接的情況下，當(dāng)一個(gè)網(wǎng)頁(yè)打開(kāi)完成后，客戶端和服務(wù)器之間用于傳輸HTTP數(shù)據(jù)的TCP連接不會(huì)關(guān)閉，客戶端再次訪問(wèn)這個(gè)服務(wù)器時(shí)，會(huì)繼續(xù)使用這一條已經(jīng)建立的連接。Keep-Alive不會(huì)永久保持連接，它有一個(gè)保持時(shí)間，可以在不同的服務(wù)器軟件（如Apache）中設(shè)定這個(gè)時(shí)間。實(shí)現(xiàn)長(zhǎng)連接需要客戶端和服務(wù)端都支持長(zhǎng)連接。

HTTP協(xié)議的長(zhǎng)連接和短連接，實(shí)質(zhì)上是TCP協(xié)議的長(zhǎng)連接和短連接。

——《HTTP長(zhǎng)連接、短連接究竟是什么？》

三、HTTP請(qǐng)求格式

URL包含：/index/index2?a=1&b=2；路徑和參數(shù)都在這里。

請(qǐng)求頭里面的內(nèi)容舉個(gè)例子：這個(gè)length表示請(qǐng)求體里面的數(shù)據(jù)長(zhǎng)度，其他的請(qǐng)求頭里面的這些鍵值對(duì)，陸續(xù)我們會(huì)講的，大概知道一下就可以了，其中有一個(gè)user-agent，算是需要你記住的吧，就是告訴你的服務(wù)端，我是用什么給你發(fā)送的請(qǐng)求。

以京東為例，看一下user-agent

看一個(gè)爬蟲的例子，爬京東的時(shí)候沒(méi)問(wèn)題，但是爬抽屜的時(shí)候必須帶著user-agent，因?yàn)槌閷蠈?duì)user-agent做了判斷，來(lái)判斷你是不是一個(gè)正常的請(qǐng)求，算是反扒機(jī)制的一種。

打開(kāi)我們保存的demo.html文件，然后通過(guò)瀏覽器打開(kāi)看看就能看到頁(yè)面效果。

寫上面這些內(nèi)容的意思是讓你知道有這么個(gè)請(qǐng)求頭的存在，有些是有意義的，請(qǐng)求頭我們還可以自己定義，就在requests模塊里面那個(gè)headers={}，這個(gè)字典里面加就行。

HTTP請(qǐng)求是瀏覽器或其他客戶端和服務(wù)器之間通信的基礎(chǔ)。一個(gè)HTTP請(qǐng)求由四個(gè)部分組成：

請(qǐng)求行(request line)
請(qǐng)求頭(headers)
空行(blank line)
請(qǐng)求體(body)

3.1 請(qǐng)求行(Request Line)

請(qǐng)求行由方法(Method)、請(qǐng)求URI(Uniform Resource Identifier)、協(xié)議版本組成，這三部分通過(guò)空格分開(kāi)。

方法(Method): 定義了對(duì)資源的操作，如GET、POST、PUT、DELETE等
請(qǐng)求URI: 指定了請(qǐng)求的資源路徑
協(xié)議版本: 通常是HTTP/1.1或HTTP/2.0

示例: GET /index.html HTTP/1.1

3.1.1 方法(Method)

方法指明了客戶端希望服務(wù)器對(duì)資源執(zhí)行的操作。這個(gè)部分是一個(gè)動(dòng)詞或者一個(gè)名詞，常見(jiàn)的HTTP方法包括：

GET: 請(qǐng)求獲取指定資源。GET請(qǐng)求應(yīng)當(dāng)只用于獲取數(shù)據(jù)而不會(huì)引發(fā)服務(wù)器上數(shù)據(jù)的改變。
POST: 用于提交數(shù)據(jù)，例如表單數(shù)據(jù)。POST請(qǐng)求可能會(huì)導(dǎo)致新的資源的創(chuàng)建或已有資源的修改。
PUT: 將請(qǐng)求的數(shù)據(jù)上傳到指定的URI（如果指定的URI不存在，則創(chuàng)建它）。
DELETE: 請(qǐng)求刪除指定的URI上可用的資源。
HEAD: 請(qǐng)求獲取資源的元數(shù)據(jù)（metadata），類似于GET請(qǐng)求，但不返回消息體。
OPTIONS: 用于描述目標(biāo)資源的通信選項(xiàng)。
PATCH: 用于對(duì)資源應(yīng)用部分修改。

其他方法（如TRACE和CONNECT）在Web應(yīng)用中較少使用。

3.1.2 請(qǐng)求URI

請(qǐng)求URI（Uniform Resource Identifier）指明了請(qǐng)求應(yīng)當(dāng)被應(yīng)用的資源。它告訴服務(wù)器要獲取或操作的具體資源。例如：

絕對(duì)路徑: /index.html或/images/logo.png
帶查詢字符串: /search?q=http(q=http是查詢參數(shù)，告訴服務(wù)器按照"http"進(jìn)行搜索)

在HTTP/1.1中，請(qǐng)求URI通常傳遞的是URI的路徑和可選的查詢字符串。但是在代理請(qǐng)求中，它可能是完整的URI。

3.1.3 協(xié)議版本

協(xié)議版本標(biāo)識(shí)了客戶端用于構(gòu)造請(qǐng)求的HTTP協(xié)議的版本。這個(gè)信息非常重要，因?yàn)樗嬷?wù)器客戶端理解的協(xié)議細(xì)節(jié)和能力。常見(jiàn)的版本有：

HTTP/1.0: 較早的HTTP版本，簡(jiǎn)單并且不支持每個(gè)連接多個(gè)請(qǐng)求（非持續(xù)連接）。
HTTP/1.1: 當(dāng)今最普遍的版本，支持持續(xù)連接、流水線化請(qǐng)求、更高效的緩存處理等。
HTTP/2: 最新的HTTP版本（直到知識(shí)截止日期為止），支持多路復(fù)用、頭部壓縮、服務(wù)器推送等。

完整的請(qǐng)求行通常看起來(lái)像這樣：

GET /index.html HTTP/1.1

這個(gè)請(qǐng)求行告訴服務(wù)器客戶端想要通過(guò)GET方法獲取根目錄下的index.html文件，并且客戶端會(huì)按照HTTP/1.1版本的規(guī)則進(jìn)行通信。

每個(gè)部分由空白字符（通常是個(gè)空格）分隔。請(qǐng)求行后面緊接著是請(qǐng)求頭部，由一個(gè)CRLF（回車加換行，\r\n）標(biāo)識(shí)請(qǐng)求行的結(jié)束。在HTTP請(qǐng)求和響應(yīng)中，CRLF用來(lái)作為消息中各個(gè)頭部字段的分隔符。

3.2 請(qǐng)求頭(Request Headers)

HTTP請(qǐng)求頭由一系列的鍵值對(duì)組成，它們?yōu)?code>HTTP請(qǐng)求提供了額外的上下文和參數(shù)設(shè)置。以下是一些常見(jiàn)的請(qǐng)求頭部字段，以及它們的含義和用途：

Host
描述: 指定服務(wù)器的域名和（可選的）端口號(hào)。在HTTP/1.1中，Host是唯一一個(gè)必須存在的請(qǐng)求頭。
示例: Host: www.example.com
User-Agent
描述: 包含了發(fā)起請(qǐng)求的客戶端信息，比如瀏覽器類型、版本、操作系統(tǒng)等。
示例: User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Accept
描述: 指明客戶端能夠接受的內(nèi)容類型，也就是服務(wù)器可以返回的媒體資源類型。
示例: Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,/;q=0.8
Accept-Language
描述: 告訴服務(wù)器客戶端優(yōu)先選擇的語(yǔ)言，通常用于國(guó)際化內(nèi)容。
示例: Accept-Language: en-US,en;q=0.5
Accept-Encoding
描述: 告訴服務(wù)器客戶端支持的內(nèi)容編碼方式，比如gzip或deflate壓縮。
示例: Accept-Encoding: gzip, deflate
Connection
描述: 控制當(dāng)前事務(wù)完成后，客戶端和服務(wù)器之間連接的處理方式，例如keep-alive或close。
示例: Connection: keep-alive
Cache-Control
描述: 指示請(qǐng)求和響應(yīng)遵循的緩存機(jī)制。
示例: Cache-Control: no-cache
Cookie
描述: 包含從服務(wù)器接收的所有cookies，服務(wù)器可以用它來(lái)恢復(fù)客戶端的會(huì)話狀態(tài)。
示例: Cookie: sessionToken=abc123; userId=789
Content-Length
描述: 在POST或PUT請(qǐng)求中，指示請(qǐng)求體的大小（以字節(jié)計(jì)）。
示例: Content-Length: 348
Content-Type
描述: 當(dāng)發(fā)送POST或PUT請(qǐng)求時(shí)，這個(gè)請(qǐng)求頭必須被使用來(lái)指示提交數(shù)據(jù)的MIME類型。
示例: Content-Type: application/json
Authorization
描述: 包含了證明客戶端有權(quán)查看某資源的證書。它通常涉及一個(gè)承載令牌，如JWT或OAuth令牌。
示例: Authorization: Bearer YOUR_TOKEN_HERE
Referer
描述: 指示發(fā)起請(qǐng)求的前一個(gè)頁(yè)面的URI，可以用來(lái)跟蹤從何處鏈接到當(dāng)前請(qǐng)求的資源。
示例: Referer: http://www.example.com/index.html

示例:

Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Cookie: userID=12345; sessionToken=abcdef

這些請(qǐng)求頭部字段是用于客戶端和服務(wù)器之間交換附加信息，優(yōu)化請(qǐng)求處理和響應(yīng)內(nèi)容。并不是所有的頭部字段都會(huì)在每個(gè)請(qǐng)求中出現(xiàn)，它們依據(jù)請(qǐng)求的類型和客戶端的需求而變化。

在真實(shí)的HTTP通信中，還會(huì)有很多其他的請(qǐng)求頭部字段，這些字段可以定義非標(biāo)準(zhǔn)的、實(shí)驗(yàn)性的或針對(duì)某個(gè)應(yīng)用的特定行為。開(kāi)發(fā)者有時(shí)也會(huì)自定義HTTP頭部來(lái)傳輸特定的信息。

3.3 空行(Blank Line)

頭部和主體之間的空行是請(qǐng)求的一個(gè)重要部分，即使請(qǐng)求沒(méi)有主體，這個(gè)空行也必須存在。它告訴服務(wù)器頭部結(jié)束、接下來(lái)是請(qǐng)求體。

3.4 請(qǐng)求體(Request Body)

請(qǐng)求體（Request Body）是HTTP請(qǐng)求消息的可選部分，僅在請(qǐng)求方法支持且需要發(fā)送數(shù)據(jù)時(shí)使用。例如，當(dāng)你提交表單數(shù)據(jù)時(shí)使用POST方法，或使用PUT方法上傳內(nèi)容，對(duì)于GET和HEAD請(qǐng)求來(lái)說(shuō)，通常沒(méi)有請(qǐng)求體。請(qǐng)求體中包含的實(shí)際數(shù)據(jù)類型和格式取決于請(qǐng)求頭中的Content-Type字段。以下是一些常見(jiàn)的請(qǐng)求體類型及其使用場(chǎng)景：

application/x-www-form-urlencoded
描述: 這是最常見(jiàn)的請(qǐng)求體類型，通常用于HTML表單提交。
格式: 鍵值對(duì)以&符號(hào)分隔，且鍵和值都為URL編碼。例如，key1=value1&key2=value2。
multipart/form-data
描述: 用于文件上傳和發(fā)送表單數(shù)據(jù)時(shí)，當(dāng)表單中有字段時(shí)常用這種類型。
格式: 請(qǐng)求體被分割成多個(gè)部分，每部分包含一個(gè)不同的表單域數(shù)據(jù)，部分之間由分隔符（boundary）隔開(kāi)。
application/json
描述: 用于發(fā)送JSON編碼的數(shù)據(jù)。現(xiàn)代Web APIs和RESTful服務(wù)通常用這種格式。
格式: JSON字符串，如{"key1":"value1","key2":"value2"}。
text/plain
描述: 純文本數(shù)據(jù)，不含任何數(shù)據(jù)類型或結(jié)構(gòu)描述符。
格式: 簡(jiǎn)單的文本字符串，沒(méi)有特定的結(jié)構(gòu)。
application/xml或text/xml
描述: XML數(shù)據(jù)格式，某些服務(wù)或API可能需要使用XML格式進(jìn)行數(shù)據(jù)交換。
格式: 符合XML規(guī)范的字符串，例如value1value2。
application/octet-stream
描述: 用于傳輸二進(jìn)制數(shù)據(jù)或文件內(nèi)容，指示請(qǐng)求體中的數(shù)據(jù)是原始的字節(jié)。
格式: 數(shù)據(jù)被當(dāng)作一系列字節(jié)處理。

請(qǐng)求體示例

application/x-www-form-urlencoded: username=user1&password=pass123&email=user1%40example.com
multipart/form-data: --boundary12345
Content-Disposition: form-data; name="file"; filename="example.txt"
Content-Type: text/plain

... file contents here ...

--boundary12345--

application/json: { 
    "username": "user1",
    "password": "pass123",
    "email": "user1@example.com"
}

text/plain: This is plain text.

請(qǐng)求體被視為消息的負(fù)載，并且根據(jù)用途可能含有不同的媒體類型、字符集編碼以及內(nèi)容編碼（如gzip）。需要注意的是，并非所有HTTP方法都含有請(qǐng)求體（例如，GET和HEAD請(qǐng)求通常沒(méi)有請(qǐng)求體），并且即使方法支持包含請(qǐng)求體，也不代表每次請(qǐng)求都必須包含請(qǐng)求體內(nèi)容；這取決于具體的使用場(chǎng)景和需求。

四、HTTP響應(yīng)格式

HTTP響應(yīng)同樣由三部分組成：

狀態(tài)行
響應(yīng)頭
響應(yīng)體

4.1 狀態(tài)行（Status Line）

狀態(tài)行包含HTTP協(xié)議版本、狀態(tài)碼和狀態(tài)消息。其格式如下：

<HTTP協(xié)議版本> <狀態(tài)碼> <狀態(tài)消息>

HTTP協(xié)議版本：與請(qǐng)求行中的協(xié)議版本相對(duì)應(yīng)。
狀態(tài)碼：一個(gè)三位數(shù)，用于表示請(qǐng)求的處理結(jié)果。
狀態(tài)消息：與狀態(tài)碼對(duì)應(yīng)的文本描述。

示例：HTTP/1.1 200 OK

狀態(tài)碼如下：

所有HTTP響應(yīng)的第一行都是狀態(tài)行，依次是當(dāng)前HTTP版本號(hào)，3位數(shù)字組成的狀態(tài)代碼，以及描述狀態(tài)的短語(yǔ)，彼此由空格分隔。

狀態(tài)代碼的第一個(gè)數(shù)字代表當(dāng)前響應(yīng)的類型：

1xx消息——請(qǐng)求已被服務(wù)器接收，繼續(xù)處理
2xx成功——請(qǐng)求已成功被服務(wù)器接收、理解、并接受
3xx重定向——需要后續(xù)操作才能完成這一請(qǐng)求
4xx請(qǐng)求錯(cuò)誤——請(qǐng)求含有詞法錯(cuò)誤或者無(wú)法被執(zhí)行
5xx服務(wù)器錯(cuò)誤——服務(wù)器在處理某個(gè)正確請(qǐng)求時(shí)發(fā)生錯(cuò)誤

雖然RFC 2616中已經(jīng)推薦了描述狀態(tài)的短語(yǔ)，例如"200 OK"，"404 Not Found"，但是WEB開(kāi)發(fā)者仍然能夠自行決定采用何種短語(yǔ)，用以顯示本地化的狀態(tài)描述或者自定義信息。

4.2 響應(yīng)頭（Response Headers）

響應(yīng)頭包含關(guān)于響應(yīng)的元數(shù)據(jù)，同樣以鍵值對(duì)的形式存在。這些字段提供了關(guān)于響應(yīng)內(nèi)容、緩存指令、服務(wù)器信息等方面的詳細(xì)信息。常見(jiàn)的響應(yīng)頭字段包括：

Content-Type：響應(yīng)主體的媒體類型。
Content-Length：響應(yīng)主體的長(zhǎng)度。
Server：服務(wù)器軟件的信息。
Cache-Control：指定請(qǐng)求/響應(yīng)鏈中所有的緩存機(jī)制必須遵守的指令。
Expires：響應(yīng)過(guò)期的時(shí)間。
ETag：資源的特定版本的標(biāo)識(shí)符，通常用于緩存。

4.3 響應(yīng)體（Response Body）

響應(yīng)體包含服務(wù)器返回的實(shí)際數(shù)據(jù)，如HTML頁(yè)面、圖片、JSON數(shù)據(jù)等。響應(yīng)體的格式和內(nèi)容由Content-Type頭字段決定。

五、拓展

5.1 HTTP是不保存狀態(tài)的協(xié)議,如何保存用戶狀態(tài)?

HTTP是一種不保存狀態(tài)，即無(wú)狀態(tài)（stateless）協(xié)議。也就是說(shuō)HTTP協(xié)議自身不對(duì)請(qǐng)求和響應(yīng)之間的通信狀態(tài)進(jìn)行保存。那么我們保存用戶狀態(tài)呢？Session機(jī)制的存在就是為了解決這個(gè)問(wèn)題，Session的主要作用就是通過(guò)服務(wù)端記錄用戶的狀態(tài)。典型的場(chǎng)景是購(gòu)物車，當(dāng)你要添加商品到購(gòu)物車的時(shí)候，系統(tǒng)不知道是哪個(gè)用戶操作的，因?yàn)?code>HTTP協(xié)議是無(wú)狀態(tài)的。服務(wù)端給特定的用戶創(chuàng)建特定的Session之后就可以標(biāo)識(shí)這個(gè)用戶并且跟蹤這個(gè)用戶了（一般情況下，服務(wù)器會(huì)在一定時(shí)間內(nèi)保存這個(gè)Session，過(guò)了時(shí)間限制，就會(huì)銷毀這個(gè)Session）。

在服務(wù)端保存Session的方法很多，最常用的就是內(nèi)存和數(shù)據(jù)庫(kù)(比如是使用內(nèi)存數(shù)據(jù)庫(kù)redis保存)。既然Session存放在服務(wù)器端，那么我們?nèi)绾螌?shí)現(xiàn)Session跟蹤呢？大部分情況下，我們都是通過(guò)在Cookie中附加一個(gè)Session ID來(lái)方式來(lái)跟蹤。

Cookie被禁用怎么辦?

最常用的就是利用URL重寫把Session ID直接附加在URL路徑的后面。

HTTP是無(wú)狀態(tài)的.png

5.2 Cookie的作用是什么?和Session區(qū)別

Cookie和Session都是用來(lái)跟蹤瀏覽器用戶身份的會(huì)話方式，但是兩者的應(yīng)用場(chǎng)景不太一樣。

Cookie一般用來(lái)保存用戶信息，比如
1. 我們?cè)?code>Cookie中保存已經(jīng)登錄過(guò)得用戶信息，下次訪問(wèn)網(wǎng)站的時(shí)候頁(yè)面可以自動(dòng)幫你登錄的一些基本信息給填了；
2. 一般的網(wǎng)站都會(huì)有保持登錄也就是說(shuō)下次你再訪問(wèn)網(wǎng)站的時(shí)候就不需要重新登錄了，這是因?yàn)橛脩舻卿浀臅r(shí)候我們可以存放了一個(gè)Token在Cookie中，下次登錄的時(shí)候只需要根據(jù)Token值來(lái)查找用戶即可(為了安全考慮，重新登錄一般要將Token重寫)；
3. 登錄一次網(wǎng)站后訪問(wèn)網(wǎng)站其他頁(yè)面不需要重新登錄。
Session的主要作用就是通過(guò)服務(wù)端記錄用戶的狀態(tài)。典型的場(chǎng)景是購(gòu)物車，當(dāng)你要添加商品到購(gòu)物車的時(shí)候，系統(tǒng)不知道是哪個(gè)用戶操作的，因?yàn)?code>HTTP協(xié)議是無(wú)狀態(tài)的。服務(wù)端給特定的用戶創(chuàng)建特定的Session之后就可以標(biāo)識(shí)這個(gè)用戶并且跟蹤這個(gè)用戶了。

Cookie數(shù)據(jù)保存在客戶端(瀏覽器端)，Session數(shù)據(jù)保存在服務(wù)器端。

Cookie存儲(chǔ)在客戶端中，而Session存儲(chǔ)在服務(wù)器上，相對(duì)來(lái)說(shuō)Session安全性更高。如果要在Cookie中存儲(chǔ)一些敏感信息，不要直接寫入Cookie中，最好能將Cookie信息加密然后使用到的時(shí)候再去服務(wù)器端解密。

5.3 HTTP 1.0和HTTP 1.1的主要區(qū)別

這部分回答引用這篇文章https://mp.weixin.qq.com/s/GICbiyJpINrHZ41u_4zT-A?的一些內(nèi)容。

HTTP 1.0最早在網(wǎng)頁(yè)中使用是在1996年，那個(gè)時(shí)候只是使用一些較為簡(jiǎn)單的網(wǎng)頁(yè)上和網(wǎng)絡(luò)請(qǐng)求上，而HTTP 1.1則在1999年才開(kāi)始廣泛應(yīng)用于現(xiàn)在的各大瀏覽器網(wǎng)絡(luò)請(qǐng)求中，同時(shí)HTTP 1.1也是當(dāng)前使用最為廣泛的HTTP協(xié)議。主要區(qū)別主要體現(xiàn)在：

長(zhǎng)連接: 在HTTP/1.0中，默認(rèn)使用的是短連接，也就是說(shuō)每次請(qǐng)求都要重新建立一次連接。HTTP是基于TCP/IP協(xié)議的,每一次建立或者斷開(kāi)連接都需要三次握手四次揮手的開(kāi)銷，如果每次請(qǐng)求都要這樣的話，開(kāi)銷會(huì)比較大。因此最好能維持一個(gè)長(zhǎng)連接，可以用個(gè)長(zhǎng)連接來(lái)發(fā)多個(gè)請(qǐng)求。HTTP1.1起，默認(rèn)使用長(zhǎng)連接，默認(rèn)開(kāi)啟Connection：keep-alive。HTTP/1.1的持續(xù)連接有非流水線方式和流水線方式。流水線方式是客戶在收到HTTP的響應(yīng)報(bào)文之前就能接著發(fā)送新的請(qǐng)求報(bào)文。與之相對(duì)應(yīng)的非流水線方式是客戶在收到前一個(gè)響應(yīng)后才能發(fā)送下一個(gè)請(qǐng)求。
錯(cuò)誤狀態(tài)響應(yīng)碼 :在HTTP1.1中新增了24個(gè)錯(cuò)誤狀態(tài)響應(yīng)碼，如409（Conflict）表示請(qǐng)求的資源與資源的當(dāng)前狀態(tài)發(fā)生沖突；410（Gone）表示服務(wù)器上的某個(gè)資源被永久性的刪除。
緩存處理:在HTTP1.0中主要使用header里的If-Modified-Since,Expires來(lái)做為緩存判斷的標(biāo)準(zhǔn)，HTTP 1.1則引入了更多的緩存控制策略例如Entity tag，If-Unmodified-Since,If-Match,If-None-Match等更多可供選擇的緩存頭來(lái)控制緩存策略。
帶寬優(yōu)化及網(wǎng)絡(luò)連接的使用:HTTP1.0中，存在一些浪費(fèi)帶寬的現(xiàn)象，例如客戶端只是需要某個(gè)對(duì)象的一部分，而服務(wù)器卻將整個(gè)對(duì)象送過(guò)來(lái)了，并且不支持?jǐn)帱c(diǎn)續(xù)傳功能，HTTP1.1則在請(qǐng)求頭引入了range頭域，它允許只請(qǐng)求資源的某個(gè)部分，即返回碼是206（Partial Content），這樣就方便了開(kāi)發(fā)者自由的選擇以便于充分利用帶寬和連接。

5.4 URI和URL的區(qū)別

URI(Uniform Resource Identifier)是統(tǒng)一資源標(biāo)志符，可以唯一標(biāo)識(shí)一個(gè)資源。
URL(Uniform Resource Locator)是統(tǒng)一資源定位符，可以提供該資源的路徑。它是一種具體的URI，即URL可以用來(lái)標(biāo)識(shí)一個(gè)資源，而且還指明了如何locate這個(gè)資源。

URI的作用像身份證號(hào)一樣，URL的作用更像家庭住址一樣。URL是一種具體的URI，它不僅唯一標(biāo)識(shí)資源，而且還提供了定位該資源的信息。

5.5 HTTP和HTTPS的區(qū)別

端口：HTTP的URL由“http://”起始且默認(rèn)使用端口80，而HTTPS的URL由“https://”起始且默認(rèn)使用端口443。
安全性和資源消耗：HTTP協(xié)議運(yùn)行在TCP之上，所有傳輸?shù)膬?nèi)容都是明文，客戶端和服務(wù)器端都無(wú)法驗(yàn)證對(duì)方的身份。HTTPS是運(yùn)行在SSL/TLS之上的HTTP協(xié)議，SSL/TLS運(yùn)行在TCP之上。所有傳輸?shù)膬?nèi)容都經(jīng)過(guò)加密，加密采用對(duì)稱加密，但對(duì)稱加密的密鑰用服務(wù)器方的證書進(jìn)行了非對(duì)稱加密。所以說(shuō)，HTTP安全性沒(méi)有HTTPS高，但是HTTPS比HTTP耗費(fèi)更多服務(wù)器資源。
- 對(duì)稱加密：密鑰只有一個(gè)，加密解密為同一個(gè)密碼，且加解密速度快，典型的對(duì)稱加密算法有DES、AES等；
- 非對(duì)稱加密：密鑰成對(duì)出現(xiàn)（且根據(jù)公鑰無(wú)法推知私鑰，根據(jù)私鑰也無(wú)法推知公鑰），加密解密使用不同密鑰（公鑰加密需要私鑰解密，私鑰加密需要公鑰解密），相對(duì)對(duì)稱加密速度較慢，典型的非對(duì)稱加密算法有RSA、DSA等。

posted @ 2025-11-05 20:24 夏爾_717 閱讀(6) 評(píng)論(0) 收藏舉報(bào)

刷新頁(yè)面返回頂部

ciel_717