前言

雖然應用層協議是我們程序猿自己定的，但實際上已經有大佬們定義了一些現成的又非常好用的應用層協議供我們直接參考使用，HTTP(超文本傳輸協議)就是其中之一。

在互聯網世界中，HTTP（HyperText Transfer Protocol，超文本傳輸協議）是一個至關重要的協議。它定義了客戶端（如瀏覽器）與服務器之間如何通信以交換或傳輸超文本（如 HTML 文檔）。 HTTP 協議是客戶端與服務器之間通信的基礎。客戶端通過HTTP協議向服務器發送請求，服務器收到請求后處理并返回響應。HTTP協議是一個無連接、無狀態的協議，即每次請求都需要建立新的連接，且服務器不會保存客戶端的狀態信息。

1. URL

1.1 url 的認識

平時我們俗稱的 "網址" 其實就是說的 URL（Uniform Resource Locator，統一資源定位符）。
下圖就是一個URL的常見格式：

認識：

1. 我們上網的行為，本質就是IO。（我的數據給別人，別人的數據給我）

2. 我們上網所獲得的圖片、音頻、文本等都是資源。

3. 我們想要通過網絡獲取資源，首先就需要確定資源在哪臺服務器（IP+端口號），在什么路徑下（linux的文件路徑，這里的路徑指的是web根目錄），于是就有了URL。

4. 成熟的應用層協議往往都與端口號是強關聯的，所以不需要指明端口號。

1.2?urlencode 和 urldecode

像 / ? : 等這樣的字符，已經被 url 當做特殊意義理解了，因此這些字符不能隨意出現。比如，某個參數中需要帶有這些特殊字符，就必須先對特殊字符進行轉義，轉義的規則如下：將需要轉碼的字符轉為16進制，然后從右到左，取 4 位(不足 4 位直接處理)，每 2 位做一位，前面加上%，編碼成%XY格式。urldecode 就是 urlencode 的逆過程。例如：

2. HTTP協議的宏觀格式

HTTP不想依賴任何的庫所以自己做了序列化和反序列化。

2.1 HTTP的請求行與狀態行

2.1.1 請求方法

請求方法中最常用的就是 GET 方法和 POST 方法。

GET和POST方法的區別：

??相同點：兩者均用于請求url的指定資源。

??不同點：GET方法請求的資源，參數附加在URL中（如??name=Alice&age=20），可見且長度受限。POST方法請求的資源，參數封裝在請求正文中，不可見且理論上無大小限制。

2.1.2 HTTP的狀態碼

最常見的狀態碼, 比如 200(OK), 404(Not Found), 403(Forbidden), 302(Redirect, 重定向), 504(Bad Gateway)

狀態碼	含義	應用樣例
100	Continue	上傳大文件時，服務器告訴客戶端可以 繼續上傳
200	OK	訪問網站首頁，服務器返回網頁內容
201	Created	發布新文章，服務器返回文章創建成功 的信息
204	No Content	刪除文章后，服務器返回“無內容”表示操 作成功
301	Moved Permanently	網站換域名后，自動跳轉到新域名；搜 索引擎更新網站鏈接時使用
302	Found 或 See Other	用戶登錄成功后，重定向到用戶首頁
304	Not Modified	瀏覽器緩存機制，對未修改的資源返回 304 狀態碼
400	Bad Request	填寫表單時，格式不正確導致提交失敗
401	Unauthorized	訪問需要登錄的頁面時，未登錄或認證 失敗
403	Forbidden	嘗試訪問你沒有權限查看的頁面
404	Not Found	訪問不存在的網頁鏈接
500	Internal Server Error	服務器崩潰或數據庫錯誤導致頁面無法 加載
502	Bad Gateway	使用代理服務器時，代理服務器無法從 上游服務器獲取有效響應
503	Service Unavailable	服務器維護或過載，暫時無法處理請求

2.2 HTTP的請求報頭

? Content-Type：數據類型(text/html 等)
? Content-Length：Body 的長度
? Host：客戶端告知服務器, 所請求的資源是在哪個主機的哪個端口上;
? User-Agent：聲明用戶的操作系統和瀏覽器版本信息
? referer：當前頁面是從哪個頁面跳轉過來的
? Location：搭配 3xx 狀態碼使用, 告訴客戶端接下來要去哪里訪問
? Cookie：用于在客戶端存儲少量信息. 通常用于實現會話(session)的功能

3. HTTP協議的版本變遷

版本	發布年份	核心特性	存在問題
HTTP/0.9	1991	僅支持 GET 請求，傳輸純文本	無狀態、無首部、功能極簡
HTTP/1.0	1996	引入狀態碼、請求/響應首部、多種方法	每次請求重新建立連接
HTTP/1.1	1997-1999	長連接、管道化、緩存機制	隊頭阻塞、效率不高
HTTP/2	2015	二進制幀、多路復用、頭部壓縮	加密依賴 TLS，復雜度高
HTTP/3	2022	基于 QUIC 協議，0-RTT 建連，減少丟包	仍在推廣中，部署成本高

特性	HTTP/1.0	HTTP/1.1	HTTP/2	HTTP/3
連接方式	短連接	長連接	多路復用（TCP）	多路復用（QUIC/UDP）
并發性能	差	管道化，有限提升	真正多路復用	多路復用 + 低延遲
編碼方式	文本	文本	二進制幀結構	二進制幀結構
頭部壓縮	無	無	HPACK	QPACK
隊頭阻塞	嚴重	存在	應用層阻塞（TCP 造成）	無（QUIC 層完全避免）
安全機制	無	支持 TLS	默認需 TLS	內置加密（QUIC 原生支持）