1.HTTP背景知識

HTTP協議：HTTP（HyperText Transfer Protocol，超文本傳輸協議）的本質是運行在 TCP/IP 協議族之上的 “應用層協議”，核心作用是定義客戶端（如瀏覽器、APP）與服務器之間的 “數據交互格式與流程”，最終實現 “超文本（如 HTML、圖片、JSON）的傳輸與展示”。HTTP 協議的實質：應用層的 “請求 - 響應” 通信規則。

為什么設計為無狀態？核心是降低服務器負擔：若服務器需要記憶每個客戶端的狀態（如登錄狀態、瀏覽記錄），則需為每個客戶端維護 “狀態數據”，當并發量極高（如百萬級用戶）時，服務器的內存和性能會被嚴重消耗。

如何解決 “無狀態” 的局限性？通過 “額外機制” 在無狀態基礎上實現 “狀態保持”，最典型的是Cookie+Session。

2.HTTP協議組成部分

1.請求行?[?法] + [url] + [版本]

2.請求報頭?請求的屬性, 冒號分割的鍵值對;每組屬性之間使? \r\n 分隔;遇到空?表? Header部分結束

3.空白行?

4.請求正文?Body: 空?后?的內容都是Body. Body允許為空字符串. 如果Body存在, 則在Header中會有?個Content-Length屬性來標識Body的?度;

3.HTTP的?法

?途：?于傳輸實體的主體，通常?于提交表單數據。

?例： POST /submit.cgi HTTP/1.1

特性：可以發送?量的數據給服務器，并且數據包含在請求體中。

4.HTTP的狀態碼

我們常用的狀態碼有404(Not Found),200(OK),403((Forbidden), 302(Redirect, 重定向), 504(Bad Gateway)

HTTP狀態碼301（永久重定向）和302（臨時重定向）都依賴Location選項。以下是關于兩者依賴 Location選項的詳細說明：

HTTP狀態碼301(永久重定向)

當服務器返回HTTP 301狀態碼時，表?請求的資源已經被永久移動到新的位置。

在這種情況下，服務器會在響應中添加?個Location頭部，?于指定資源的新位置。這個Location頭部包含了新的URL地址，瀏覽器會?動重定向到該地址。

當服務器返回HTTP 302狀態碼時，表?請求的資源臨時被移動到新的位置。

同樣地，服務器也會在響應中添加?個Location頭部來指定資源的新位置。瀏覽器會暫時使?新的URL進?后續的請求，但不會緩存這個重定向。

服務器的職責僅在于通過重定向狀態碼和Location字段，向瀏覽器傳遞 “臨時重定向的目標地址”，不參與后續的新請求 —— 既不會主動幫瀏覽器訪問Location對應的 URL，也不會處理新請求的邏輯（新請求需由瀏覽器重新發起，服務器再按新請求的 URL 處理）。

Content-Type: 數據類型(text/html等)

Content-Length: Body的?度

Host: 客?端告知服務器, 所請求的資源是在哪個主機的哪個端?上;

User-Agent: 聲明??的操作系統和瀏覽器版本信息;

Referer: 當前??是從哪個??跳轉過來的;

Location: 搭配3xx狀態碼使?, 告訴客?端接下來要去哪?訪問;

Cookie: ?于在客?端存儲少量信息. 通常?于實現會話(session)的功能;

5.實現一個簡單的服務器

如果我們將狀態行改成302我們會得到以下的結果，我們的頁面被重定向到了百度的首頁，這就是重定向的用法

6.總結

如果想要實現與客戶端瀏覽器更多詳細的交互，需要對客戶端的請求進行反序列化與序列化，然后根據方法做對應的處理，以及根據請求的url將外部根目錄的文件填寫到正文中，這個文件可以是Html，可以是圖片等，然后響應信息并進行反序列化，將信息交給瀏覽器渲染，這樣就能夠實現一些好玩的后端與前端交互的網頁。我的前面文章中寫了一篇基于Tcp實現一個電商網站，感興趣也可以瀏覽一下。

具體的代碼已經上傳我的gitee，需要的可以自取study_code: 學習路上寫的一些代碼 - Gitee.com

感謝瀏覽，如有錯誤可以指出。