作者：羅布頓珠
鏈接：https://www.nowcoder.com/discuss/567886?from=zhnkw
來(lái)源：牛客網(wǎng)
?

HTTP基礎(chǔ)

URL與資源

URL即統(tǒng)一資源定位系統(tǒng)，它定義了用戶所需的特定資源，它位于何處以及如何獲取它。大多數(shù)的URL方案的語(yǔ)法都建立在由9個(gè)部分構(gòu)成的通用格式上： <scheme>://<user>:<password>@<host>:<port>/<path>;<params>?<query>#<frag> 其中最重要的是方案（scheme，指明協(xié)議）、主機(jī)（host）和路徑（path）。

URL是使用US-ASCII字符集進(jìn)行編碼的，因此部分字符需要轉(zhuǎn)義后再重新編碼

HTTP報(bào)文

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

狀態(tài)碼

狀態(tài)碼含義

1XX	信息性狀態(tài)碼，服務(wù)器收到請(qǐng)求，需要請(qǐng)求者繼續(xù)執(zhí)行操作
2XX	成功狀態(tài)碼。200成功，204服務(wù)器處理成功，無(wú)內(nèi)容。
3XX	重定向狀態(tài)碼，需要進(jìn)一步的操作以完成請(qǐng)求；301永久重定向，302臨時(shí)重定向。
4XX	客戶端錯(cuò)誤，請(qǐng)求包含語(yǔ)法錯(cuò)誤或無(wú)法完成請(qǐng)求；400客戶端請(qǐng)求語(yǔ)法錯(cuò)誤，401請(qǐng)求要求用戶的身份認(rèn)證，403服務(wù)器理解請(qǐng)求客戶端的請(qǐng)求，但是拒絕執(zhí)行此請(qǐng)求。
5XX	服務(wù)器錯(cuò)誤，服務(wù)器在處理請(qǐng)求的過(guò)程中發(fā)生了請(qǐng)求；500服務(wù)器內(nèi)部錯(cuò)誤，無(wú)法完成請(qǐng)求；

請(qǐng)求方法

1.GET 請(qǐng)求指定的頁(yè)面信息，并返回實(shí)體主體

2.HEAD 類似于GET請(qǐng)求，只不過(guò)返回的響應(yīng)體，用于獲取報(bào)頭。

3.POST 向指定的資源提交數(shù)據(jù)進(jìn)行處理請(qǐng)求。數(shù)據(jù)被包含在請(qǐng)求體中。POST請(qǐng)求可能會(huì)導(dǎo)致新的資源的建立或已有資源的修改。

4.PUT 從客戶端向服務(wù)端傳送的數(shù)據(jù)取代指定的文檔的內(nèi)容

5.DELETE 請(qǐng)求服務(wù)器刪除指定的頁(yè)面

6.CONNECT HTTP/1.1協(xié)議中預(yù)留給能將連接改為管道方式的代理服務(wù)器

7.OPTIONS 允許客戶端查看服務(wù)端的性能

8.TRACE 回顯服務(wù)端收到的請(qǐng)求，主要用于測(cè)試或診斷

9.PATCH 是對(duì)PUT方法的補(bǔ)充，用來(lái)對(duì)已知資源進(jìn)行局部更新。

首部

1.Allow 服務(wù)器支持哪些請(qǐng)求方法

2.Content-Encoding 文檔的編碼方式

3.Content-Length 表示內(nèi)容的長(zhǎng)度。只有當(dāng)瀏覽器使用持久HTTP連接時(shí)才需要這個(gè)數(shù)據(jù)。

4.Content-Type 表示后面的文檔屬于什么MIME類型

5.Date 當(dāng)前的GMT時(shí)間

6.Expires 應(yīng)該在什么時(shí)候認(rèn)為文檔已經(jīng)過(guò)期，從而不再緩存它。

7.Last-Modified 文檔的最后改動(dòng)時(shí)間。

8.Location 表示客戶應(yīng)當(dāng)?shù)侥睦锶ヌ崛∥臋n

9.Set-Cookie 設(shè)置和頁(yè)面關(guān)聯(lián)的Cookie

連接管理

TCP連接

HTTP連接實(shí)際上就是TCP連接和一些使用連接的規(guī)則。

由于TCP協(xié)議導(dǎo)致的HTTP性能瓶頸：

• TCP連接建立握手

• TCP慢啟動(dòng)擁塞控制

• 數(shù)據(jù)聚集的Nagle算法

• 用于捎帶確認(rèn)的TCP延遲確認(rèn)算法

• TIME_WAIT時(shí)延和端口耗盡

HTTP連接

1.并行連接

通過(guò)多條TCP連接發(fā)起并發(fā)的HTTP請(qǐng)求. 并行連接可能會(huì)提高頁(yè)面加載的速度，但是多連接會(huì)導(dǎo)致資源的消耗，在帶寬競(jìng)爭(zhēng)激烈的時(shí)候性能提升有限。

2.持久連接

重用TCP連接，以消除連接及關(guān)閉時(shí)延。 HTTP/1.1允許HTTP設(shè)備在事務(wù)處理結(jié)束之后將TCP連接保持在打開(kāi)狀態(tài)，以便為未來(lái)的HTTP請(qǐng)求重用現(xiàn)存的連接。重用已對(duì)目標(biāo)服務(wù)打開(kāi)的空閑持久化連接，就可以避開(kāi)緩慢的連接建立階段和慢啟動(dòng)的擁塞適應(yīng)階段。

3.管道化連接

通過(guò)共享的TCP連接發(fā)起并發(fā)的HTTP請(qǐng)求 HTTP/1.1允許在持久連接上可選地使用請(qǐng)求管道。這是在keep-alive連接上地進(jìn)一步性能優(yōu)化。在響應(yīng)到達(dá)之前，可以將多條請(qǐng)求放入隊(duì)列。當(dāng)?shù)谝粭l請(qǐng)求通過(guò)完了流向另一端地服務(wù)器時(shí)，第二條和第三條請(qǐng)求也可以開(kāi)始發(fā)送了。在高時(shí)延網(wǎng)絡(luò)條件下，這樣做可以降低網(wǎng)絡(luò)的回環(huán)時(shí)間，提高性能。

4.復(fù)用的連接 交替?zhèn)魉驼?qǐng)求和響應(yīng)報(bào)文（實(shí)驗(yàn)階段）

客戶端識(shí)別與cookie機(jī)制

HTTP最初是一個(gè)匿名的、無(wú)狀態(tài)的請(qǐng)求/響應(yīng)協(xié)議。但是在有些場(chǎng)景下我們需要對(duì)用戶進(jìn)行跟蹤（個(gè)性化、推薦、管理信息的存檔、記錄會(huì)話）。

用戶識(shí)別機(jī)制主要有以下幾種：

1.承載用戶身份信息的HTTP首部 用于承載用戶身份信息的首部有這些：

首部名稱首部類型描述

From	請(qǐng)求	用戶的E-mail地址
User-Agent	請(qǐng)求	用戶的瀏覽器軟件
Referer	請(qǐng)求	用戶是從哪個(gè)頁(yè)面跳過(guò)來(lái)的
Authorization	請(qǐng)求	用戶認(rèn)證信息
Client-IP	拓展（請(qǐng)求）	客戶端的IP
X-Forwarded-For	拓展（請(qǐng)求）	客戶端的IP地址
Cookie	拓展（請(qǐng)求）	服務(wù)端設(shè)置的ID標(biāo)簽，cookie機(jī)制0

2.客戶端的IP地址跟蹤，通過(guò)用戶的IP地址對(duì)其進(jìn)行識(shí)別 使用IP地址進(jìn)行跟蹤已經(jīng)是一個(gè)比較落后的做法。原因在于IP地址描述的是機(jī)器而不是用戶，且由于代理和NAT的存在，導(dǎo)致IP地址不再準(zhǔn)確。

3.用戶登錄，用認(rèn)證方式識(shí)別用戶 用戶登錄后利用首部的Authorization進(jìn)行用戶標(biāo)識(shí)。

4.胖URL，一種在URL嵌入識(shí)別信息的技術(shù) 在URL中添加用戶標(biāo)識(shí)，該方案主要用于無(wú)法使用cookie時(shí)。 該方案的局限性在：

• URL變得復(fù)雜，可讀性變差

• 無(wú)法共享URL，URL包含了用戶和會(huì)話信息

• 破環(huán)緩存。為每個(gè)URL生成特定的版本就意味著不再有可供公共訪問(wèn)的URL需要緩存了

• 額外的服務(wù)器負(fù)載。服務(wù)器需要重寫(xiě)URL，給服務(wù)器帶來(lái)了新的負(fù)載

• 逃逸口，當(dāng)用戶跳轉(zhuǎn)到其他URL后，可能導(dǎo)致原有URL中的信息丟失

• 在會(huì)話間是非持久的，下次進(jìn)入網(wǎng)站URL中的信息都會(huì)丟失

5.cookie機(jī)制 當(dāng)服務(wù)器想要標(biāo)識(shí)用戶時(shí)，會(huì)再響應(yīng)首部中添加一個(gè)Set-Cookie來(lái)設(shè)置cookie。之后的每次請(qǐng)求都會(huì)攜帶該cookie值。出于安全考慮可以將Cookie設(shè)置為httpOnly,禁止js讀取。

cookie的分類：

• 會(huì)話cookie：是一種臨時(shí)的cookie，瀏覽器關(guān)閉后會(huì)話cookie就會(huì)被刪除

• 持久cookie：持久cookie存儲(chǔ)在磁盤(pán)上，瀏覽器關(guān)閉后下次啟動(dòng)該cookie依然存在，持久cookie就是設(shè)置了過(guò)期時(shí)間的cookie

HTTP高級(jí)

代理

web上的代理服務(wù)器是代表客戶端完成事務(wù)處理的中間人。代理服務(wù)器按照是否被客戶端共享可以被分為公共代理和私有代理。

代理和網(wǎng)關(guān)的對(duì)比：

• 代理是連接是兩個(gè)或多個(gè)使用相同協(xié)議的應(yīng)用程序，而網(wǎng)關(guān)連接的則是兩個(gè)或多個(gè)使用不同協(xié)議的端點(diǎn)。

• 網(wǎng)關(guān)扮演的是“協(xié)議轉(zhuǎn)換器”

代理的用處：

• 內(nèi)容過(guò)濾器

• 文檔訪問(wèn)控制

• 安全防火墻

• Web緩存：代理緩存維護(hù)了常用文檔的本地副本，并將它們按需提供，以減少緩慢且昂貴的因特網(wǎng)通信

• 反向代理：代理可以假扮web服務(wù)器，這些反向代理接受發(fā)給web服務(wù)器的真實(shí)請(qǐng)求，但與web服務(wù)器不同的是，他們可以發(fā)起與其他服務(wù)器的通信，以便按需定位所請(qǐng)求的內(nèi)容。

• 內(nèi)容路由器

• 轉(zhuǎn)碼器

• 匿名者代理

幾種代理服務(wù)器的部署方式：

• 出口代理

• 訪問(wèn)入口代理

• 反向代理

• 網(wǎng)絡(luò)交換代理

代理獲得流量的方式：

• 修改客戶端

• 修改網(wǎng)絡(luò)。在網(wǎng)絡(luò)基礎(chǔ)設(shè)施中對(duì)HTTP流量進(jìn)行監(jiān)控，然后對(duì)其攔截，將流量導(dǎo)入代理中

• 修改DNS命名空間

• 修改Web服務(wù)器，由Web服務(wù)器重定向來(lái)完成流量導(dǎo)入

緩存

web緩存時(shí)可以自動(dòng)保存常見(jiàn)文檔副本的HTTP設(shè)備。當(dāng)web請(qǐng)求抵達(dá)緩存時(shí)，如果本地由“已緩存的”副本，就可以從本地存儲(chǔ)設(shè)備而不是元素服務(wù)器中提取這個(gè)文檔。

緩存的優(yōu)點(diǎn)：

• 減少了冗余的網(wǎng)絡(luò)傳輸

• 緩解了網(wǎng)絡(luò)瓶頸問(wèn)題

• 減低了對(duì)原始服務(wù)器的要求

• 降低了距離時(shí)延

命中和未命中： 原始服務(wù)器的內(nèi)容可能會(huì)發(fā)生變化，緩存要不時(shí)對(duì)其進(jìn)行檢測(cè)，看看他們保存的副本是否仍然時(shí)服務(wù)器上最新的副本。這種操作被稱為 HTTP再驗(yàn)證 。

緩存對(duì)緩存的副本進(jìn)行再驗(yàn)證時(shí)，會(huì)向原始服務(wù)器發(fā)送一個(gè)小的再驗(yàn)證請(qǐng)求。如果內(nèi)容沒(méi)有變化，服務(wù)器會(huì)以一個(gè)小的304 Not Modified進(jìn)行響應(yīng)。如果再驗(yàn)證未命中，則服務(wù)器向客戶端發(fā)送一條普通的、帶有完整內(nèi)容的HTTP 200 OK響應(yīng)。如果對(duì)象被刪除，則服務(wù)器回送一個(gè)404 Not Found。

緩存的處理步驟：

接受：緩存從網(wǎng)絡(luò)中讀取抵達(dá)的請(qǐng)求報(bào)文

解析：緩存對(duì)報(bào)文進(jìn)行解析，提取出URL和各種首部

查詢：緩存查看是否有本地副本可用，如果沒(méi)有，就獲取一份副本

新鮮度檢測(cè)：緩存查看已緩存副本是否足夠新鮮，如果不是，就詢問(wèn)服務(wù)器是否有任何更新

創(chuàng)建響應(yīng)：緩存會(huì)用新的首部和已緩存的主體來(lái)構(gòu)建一條響應(yīng)

發(fā)送：緩存通過(guò)網(wǎng)絡(luò)將響應(yīng)發(fā)回給客戶端

日志：緩存可選地創(chuàng)建一個(gè)日志文件條目來(lái)描述這個(gè)事務(wù)

內(nèi)容協(xié)商

一個(gè)URL通常需要代表若干不同的資源，比如不同的語(yǔ)言的版本，因此HTTP提供了內(nèi)容協(xié)商方法，允許從一個(gè)URL中表示的不同資源中做選擇。

內(nèi)容協(xié)商的分類：

• 客戶端驅(qū)動(dòng)的協(xié)商：讓客戶端選擇

• 服務(wù)器驅(qū)動(dòng)的協(xié)商：服務(wù)器自動(dòng)判定

• 透明協(xié)商：讓中間代理來(lái)選擇

內(nèi)容協(xié)商相關(guān)的首部：

首部描述與之匹配的實(shí)體首部

Accept	告知服務(wù)器發(fā)送何種媒體類型	Content-Type
Accept-Language	告知服務(wù)器發(fā)送何種語(yǔ)言	Content-Language
Accept-Charset	告知服務(wù)器發(fā)送何種字符集	Content-Type
Accept-Encoding	告知服務(wù)器采用何種編碼	Content-Encoding

?

?

*參考書(shū)籍《HTTP權(quán)威指南》*

總結(jié)

以上是生活随笔為你收集整理的HTTP协议基础知识总结的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。