HTTP协议基础知识总结
作者：羅布頓珠
鏈接：https://www.nowcoder.com/discuss/567886?from=zhnkw
來源：牛客網
?
HTTP基礎
URL與資源
URL即統一資源定位系統，它定義了用戶所需的特定資源，它位于何處以及如何獲取它。大多數的URL方案的語法都建立在由9個部分構成的通用格式上： <scheme>://<user>:<password>@<host>:<port>/<path>;<params>?<query>#<frag> 其中最重要的是方案（scheme，指明協議）、主機（host）和路徑（path）。
URL是使用US-ASCII字符集進行編碼的，因此部分字符需要轉義后再重新編碼
HTTP報文
請求和響應報文結構
狀態碼
| 1XX | 信息性狀態碼，服務器收到請求，需要請求者繼續執行操作 |
| 2XX | 成功狀態碼。200成功，204服務器處理成功，無內容。 |
| 3XX | 重定向狀態碼，需要進一步的操作以完成請求；301永久重定向，302臨時重定向。 |
| 4XX | 客戶端錯誤，請求包含語法錯誤或無法完成請求；400客戶端請求語法錯誤，401請求要求用戶的身份認證，403服務器理解請求客戶端的請求，但是拒絕執行此請求。 |
| 5XX | 服務器錯誤，服務器在處理請求的過程中發生了請求；500服務器內部錯誤，無法完成請求； |
請求方法
1.GET 請求指定的頁面信息，并返回實體主體
2.HEAD 類似于GET請求，只不過返回的響應體，用于獲取報頭。
3.POST 向指定的資源提交數據進行處理請求。數據被包含在請求體中。POST請求可能會導致新的資源的建立或已有資源的修改。
4.PUT 從客戶端向服務端傳送的數據取代指定的文檔的內容
5.DELETE 請求服務器刪除指定的頁面
6.CONNECT HTTP/1.1協議中預留給能將連接改為管道方式的代理服務器
7.OPTIONS 允許客戶端查看服務端的性能
8.TRACE 回顯服務端收到的請求，主要用于測試或診斷
9.PATCH 是對PUT方法的補充，用來對已知資源進行局部更新。
首部
1.Allow 服務器支持哪些請求方法
2.Content-Encoding 文檔的編碼方式
3.Content-Length 表示內容的長度。只有當瀏覽器使用持久HTTP連接時才需要這個數據。
4.Content-Type 表示后面的文檔屬于什么MIME類型
5.Date 當前的GMT時間
6.Expires 應該在什么時候認為文檔已經過期，從而不再緩存它。
7.Last-Modified 文檔的最后改動時間。
8.Location 表示客戶應當到哪里去提取文檔
9.Set-Cookie 設置和頁面關聯的Cookie
連接管理
TCP連接
HTTP連接實際上就是TCP連接和一些使用連接的規則。
由于TCP協議導致的HTTP性能瓶頸：
-
TCP連接建立握手
-
TCP慢啟動擁塞控制
-
數據聚集的Nagle算法
-
用于捎帶確認的TCP延遲確認算法
-
TIME_WAIT時延和端口耗盡
HTTP連接
1.并行連接
通過多條TCP連接發起并發的HTTP請求. 并行連接可能會提高頁面加載的速度，但是多連接會導致資源的消耗，在帶寬競爭激烈的時候性能提升有限。
2.持久連接
重用TCP連接，以消除連接及關閉時延。 HTTP/1.1允許HTTP設備在事務處理結束之后將TCP連接保持在打開狀態，以便為未來的HTTP請求重用現存的連接。重用已對目標服務打開的空閑持久化連接，就可以避開緩慢的連接建立階段和慢啟動的擁塞適應階段。
3.管道化連接
通過共享的TCP連接發起并發的HTTP請求 HTTP/1.1允許在持久連接上可選地使用請求管道。這是在keep-alive連接上地進一步性能優化。在響應到達之前，可以將多條請求放入隊列。當第一條請求通過完了流向另一端地服務器時，第二條和第三條請求也可以開始發送了。在高時延網絡條件下，這樣做可以降低網絡的回環時間，提高性能。
4.復用的連接 交替傳送請求和響應報文（實驗階段）
客戶端識別與cookie機制
HTTP最初是一個匿名的、無狀態的請求/響應協議。但是在有些場景下我們需要對用戶進行跟蹤（個性化、推薦、管理信息的存檔、記錄會話）。
用戶識別機制主要有以下幾種：
1.承載用戶身份信息的HTTP首部 用于承載用戶身份信息的首部有這些：
| From | 請求 | 用戶的E-mail地址 |
| User-Agent | 請求 | 用戶的瀏覽器軟件 |
| Referer | 請求 | 用戶是從哪個頁面跳過來的 |
| Authorization | 請求 | 用戶認證信息 |
| Client-IP | 拓展（請求） | 客戶端的IP |
| X-Forwarded-For | 拓展（請求） | 客戶端的IP地址 |
| Cookie | 拓展（請求） | 服務端設置的ID標簽，cookie機制0 |
2.客戶端的IP地址跟蹤，通過用戶的IP地址對其進行識別 使用IP地址進行跟蹤已經是一個比較落后的做法。原因在于IP地址描述的是機器而不是用戶，且由于代理和NAT的存在，導致IP地址不再準確。
3.用戶登錄，用認證方式識別用戶 用戶登錄后利用首部的Authorization進行用戶標識。
4.胖URL，一種在URL嵌入識別信息的技術 在URL中添加用戶標識，該方案主要用于無法使用cookie時。 該方案的局限性在：
-
URL變得復雜，可讀性變差
-
無法共享URL，URL包含了用戶和會話信息
-
破環緩存。為每個URL生成特定的版本就意味著不再有可供公共訪問的URL需要緩存了
-
額外的服務器負載。服務器需要重寫URL，給服務器帶來了新的負載
-
逃逸口，當用戶跳轉到其他URL后，可能導致原有URL中的信息丟失
-
在會話間是非持久的，下次進入網站URL中的信息都會丟失
5.cookie機制 當服務器想要標識用戶時，會再響應首部中添加一個Set-Cookie來設置cookie。之后的每次請求都會攜帶該cookie值。出于安全考慮可以將Cookie設置為httpOnly,禁止js讀取。
cookie的分類：
-
會話cookie：是一種臨時的cookie，瀏覽器關閉后會話cookie就會被刪除
-
持久cookie：持久cookie存儲在磁盤上，瀏覽器關閉后下次啟動該cookie依然存在，持久cookie就是設置了過期時間的cookie
HTTP高級
代理
web上的代理服務器是代表客戶端完成事務處理的中間人。代理服務器按照是否被客戶端共享可以被分為公共代理和私有代理。
代理和網關的對比：
-
代理是連接是兩個或多個使用相同協議的應用程序，而網關連接的則是兩個或多個使用不同協議的端點。
-
網關扮演的是“協議轉換器”
代理的用處：
-
內容過濾器
-
文檔訪問控制
-
安全防火墻
-
Web緩存：代理緩存維護了常用文檔的本地副本，并將它們按需提供，以減少緩慢且昂貴的因特網通信
-
反向代理：代理可以假扮web服務器，這些反向代理接受發給web服務器的真實請求，但與web服務器不同的是，他們可以發起與其他服務器的通信，以便按需定位所請求的內容。
-
內容路由器
-
轉碼器
-
匿名者代理
幾種代理服務器的部署方式：
-
出口代理
-
訪問入口代理
-
反向代理
-
網絡交換代理
代理獲得流量的方式：
-
修改客戶端
-
修改網絡。在網絡基礎設施中對HTTP流量進行監控，然后對其攔截，將流量導入代理中
-
修改DNS命名空間
-
修改Web服務器，由Web服務器重定向來完成流量導入
緩存
web緩存時可以自動保存常見文檔副本的HTTP設備。當web請求抵達緩存時，如果本地由“已緩存的”副本，就可以從本地存儲設備而不是元素服務器中提取這個文檔。
緩存的優點：
-
減少了冗余的網絡傳輸
-
緩解了網絡瓶頸問題
-
減低了對原始服務器的要求
-
降低了距離時延
命中和未命中： 原始服務器的內容可能會發生變化，緩存要不時對其進行檢測，看看他們保存的副本是否仍然時服務器上最新的副本。這種操作被稱為 HTTP再驗證 。
緩存對緩存的副本進行再驗證時，會向原始服務器發送一個小的再驗證請求。如果內容沒有變化，服務器會以一個小的304 Not Modified進行響應。如果再驗證未命中，則服務器向客戶端發送一條普通的、帶有完整內容的HTTP 200 OK響應。如果對象被刪除，則服務器回送一個404 Not Found。
緩存的處理步驟：
接受：緩存從網絡中讀取抵達的請求報文
解析：緩存對報文進行解析，提取出URL和各種首部
查詢：緩存查看是否有本地副本可用，如果沒有，就獲取一份副本
新鮮度檢測：緩存查看已緩存副本是否足夠新鮮，如果不是，就詢問服務器是否有任何更新
創建響應：緩存會用新的首部和已緩存的主體來構建一條響應
發送：緩存通過網絡將響應發回給客戶端
日志：緩存可選地創建一個日志文件條目來描述這個事務
內容協商
一個URL通常需要代表若干不同的資源，比如不同的語言的版本，因此HTTP提供了內容協商方法，允許從一個URL中表示的不同資源中做選擇。
內容協商的分類：
-
客戶端驅動的協商：讓客戶端選擇
-
服務器驅動的協商：服務器自動判定
-
透明協商：讓中間代理來選擇
內容協商相關的首部：
| Accept | 告知服務器發送何種媒體類型 | Content-Type |
| Accept-Language | 告知服務器發送何種語言 | Content-Language |
| Accept-Charset | 告知服務器發送何種字符集 | Content-Type |
| Accept-Encoding | 告知服務器采用何種編碼 | Content-Encoding |
?
?
*參考書籍《HTTP權威指南》*
總結
以上是生活随笔為你收集整理的HTTP协议基础知识总结的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 基于 qiankun 的微前端应用实践
- 下一篇： 什么是mmap？