前言

今天講講 Http，以及其服務器的開發(fā)。 Http，大家應該并不陌生，URL 中也會出現(xiàn) http: 或 https: 這樣的前綴。 本期就講講 Http 的底層工作原理。 注意（非廣告）：Http 的所有知識均可在菜鳥教程（runoob.com）中找到，包括狀態(tài)碼、請求/響應頭部、請求方法等。 基本內(nèi)容

Http，全稱 HyperText Transfer Protocol，超文本傳輸協(xié)議。 其版本號分 1.0 1.1 2 3，HTTP/2 及以前基于 TCP，HTTP/3 及以后基于 QUIC 及 UDP。 將

超文本傳輸協(xié)議

分開解釋，

超文本

：人類認知中，數(shù)字、字母、漢字、符號均屬于文本?！俺谋尽奔礊椤俺轿淖帧钡奈谋?。例如，瀏覽的網(wǎng)頁一般為 text/html 文本，API 一般使用 application/json 文本。

傳輸

：兩點之間數(shù)據(jù)互相“共享”，或“請求”，這些都屬于傳輸。

協(xié)議

：指“有兩個或兩個以上的參與方”。Http 中的參與方為“兩點”以及傳輸?shù)摹爸虚g方”。 整合起來，Http 的含義就是：

計算機中兩點之間傳輸超文本的一個約定和規(guī)范

。 請求

請求格式如下（[CrLf]代表換行，斜體字代表注釋）：

Method

URI

Version

[CrLf]

Key1

:

Value1

[CrLf]

Key2

:

Value2

[CrLf] ……[CrLf]

Key

:

Value

[CrLf] [CrLf]

（空行）

Content

[CrLf] 空行前的內(nèi)容稱為 HTTP Header，空行后內(nèi)容稱為 HTTP Body。 舉例：

GET

/

HTTP/1.1

[CrLf]

Accept

:

*/*

[CrLf] [CrLf] 其中，請求方法（Method）為

GET

，路徑（URI）為

/

（根目錄），版本號（Version）為

HTTP/1.1

，會

在下文詳細說明。 請求方法

Http 使用的是“請求—響應”方式，客戶端如果需要獲取服務端的某個資源，必須先進行請求。 請求方法位于請求報文的最前端，通常為全部大寫。 常用的請求方法有：GET、POST、PUT。

Get 請求

，用于靜態(tài)獲取服務端的某一個資源。例如，打開任意網(wǎng)頁，瀏覽器便會給服務器發(fā)送 Get 請求。其響應僅取決于服務端，客戶端在 Content 中不得攜帶任何內(nèi)容。

Post 請求

，主要用于 API 或登錄賬號，也就是客戶端需要上傳數(shù)據(jù)時使用。 例如： POST /login.html HTTP/1.1 Accept: */* Content-Type: application/json Content-Length: 35 {"username":"114","password":"514"}

Put 請求

，主要用于上傳文件，也可以代替 Post 使用。 其實 Put 本身也并不常用，因為其無法確定數(shù)據(jù)的完整性、安全性，也無法保證數(shù)據(jù)由授信任的主機上傳，甚至可能導致覆蓋原數(shù)據(jù)。 請求頭

Http 常用請求頭如下，

Accept

：指定客戶端接受的 MIME 類型以及質(zhì)量因子。例如：text/html, application/json, text/plain, */*; q=0.2, image/*，代表客戶端接受所有數(shù)據(jù)格式，并且對 image/* 進行處理，使其質(zhì)量達到 0.2（有助于減小圖片大小）。

Accept-Encoding

：指定客戶端支持的壓縮格式。

Authorization

：授權。

Cookie

：用于標識客戶端。服務器可以主動為客戶端頒發(fā) Cookie，也可以主動吊銷。經(jīng)常在登錄賬號時使用，所以 Cookie 也可以用于賬戶驗證。

Connection

：指定連接方式。keep-alive 代表不立刻關閉連接，close 代表立刻關閉連接。

Content-Encoding

：指定請求正文的壓縮格式。

Content-Length

：指定請求正文的長度。這有助于服務端決定是否接受該請求。

Content-Type

：指定請求正文的 MIME 類型與編碼格式。

Host

：指定服務器地址。

Referer

：指定用戶從何 URL 出發(fā)訪問當前頁面。

User-Agent

：瀏覽器內(nèi)核類型。 響應

響應格式如下： Version Code Status[CrLf] Key: Value[CrLf] ……[CrLf] [CrLf] Content[CrLf] Version 同上，Code 與 Status 的作用相同，不過 Code 是狀態(tài)碼，Status 是狀態(tài)說明。 狀態(tài)碼

Http 狀態(tài)碼（Status Code），標識在響應報文的第一行。其為十進制正整數(shù)，范圍在[100,600]。 狀態(tài)碼分五類：

1XX

，屬于信息響應，是 Http 的中間狀態(tài)，平時不常用。

2XX

，屬于正常響應，表示 Http 資源被正常接收。

3XX

，屬于重定向響應，會將瀏覽器的 URL 改為其它 URL。

4XX

，屬于請求錯誤。

5XX

，屬于服務器錯誤。

常用

狀態(tài)碼如下： (100) Continue 繼續(xù)：表示客戶端繼續(xù)其請求。 (101) Switching Protocols 切換協(xié)議：切換至

更高版本

的 Http。 (200) OK 正常：表示請求正常。在響應正文中附帶全部資源。 (201) Created 已創(chuàng)建：服務端已經(jīng)根據(jù)客戶端請求創(chuàng)建了新的文檔。 (202) Accepted 已接受：服務端已經(jīng)驗證請求有效，但暫時不會返回數(shù)據(jù)。常在服務器繁忙時出現(xiàn)。 (203) Non-Authoritative Information 非授權信息：正常返回數(shù)據(jù)，但文件為副本。 (204) No Content 無內(nèi)容：客戶端請求正常，但資源為空。 (206) Partial Content 部分內(nèi)容：服務端處理了請求，但是僅返回資源的部分內(nèi)容。常在使用 Range 請求頭指定資源范圍時出現(xiàn)。 (301) Moved Permanently 已移動：服務器資源永久移動?？蛻舳酥蟛粫俅伟l(fā)送請求，而是直接自行重定向。 (302) Found 已找到：服務器資源臨時移動。與 301 不同，客戶端下次仍需發(fā)送請求。 (304) Not Modified 未修改：資源在指定時間段內(nèi)未被修改，或資源符合客戶端的摘要。 (305) Use Proxy 使用代理：需要切換至指定代理以繼續(xù)訪問。常在服務器地址更改時使用。 (307) Temporary Redirect 臨時重定向：與 302 類似，但是必須使用 Get 請求進行重定向。 (400) Bad Request 錯誤的請求：請求錯誤，但是無法詳細說明。服務器應該盡量避免該錯誤，而是提供詳細的錯誤原因。 (401) Unauthorized 未認證：需要客戶端進行認證以繼續(xù)操作。也可以用于有驗證頭部，但不正確的情況。 (403) Forbidden 已禁止：拒絕處理請求。 (404) Not Found 未找到：無法找到請求的資源。 (410) Gone 不存在：與 404 類似，但是資源曾經(jīng)存在過。 (411) Length Required 需要長度：客戶端請求頭中不包含長度，需要標識。對于服務器開發(fā)者，可在服務器繁忙時要求提供長度。 (416) Requested range not satisfiable 請求范圍無效：請求頭 Range 指示的范圍溢出或無效。 (500) Internal Server Error 服務器內(nèi)部錯誤：籠統(tǒng)的服務器錯誤，例如過載或 Expection。同樣的，應當盡量避免該錯誤，而是提供詳細錯誤信息；但有一些信息不宜公開，需做好保密。 (502) Bad Gateway 錯誤的網(wǎng)關：服務器嘗試請求其它服務器或網(wǎng)關時失敗。 (503) Service Unavailable 服務不可用：服務器過載/維護/服務尚未開放。 響應頭

Http 響應也與請求相似，擁有響應頭部。以下為常見響應頭部：

Allow

：服務端支持的請求方法。

Content-Encoding

：指定響應正文的壓縮格式。

Content-Length

：指定響應正文的長度。

Content-Type

：指定響應正文的 MIME 類型。

Date

：當前（返回響應時）的 GMT 時間。

Expires

：指定緩存過期時間。

Location

：在重定向響應時，指定重定向 URL。

Refresh

：指定刷新頁面的時間間隔。注意，該字段表示“n 秒后刷新該頁面”而不是“每隔 n 秒刷新該頁面”。但如果刷新頁面后的響應相同，會重置計時器并重新刷新。

Set-Cookie

：為客戶端頒發(fā) Cookie。

WWW-Authenticate

：指定客戶端應該提供的授權信息。 服務器開發(fā)

以下為個人經(jīng)驗。 制作 Http 服務器，必須要做到：速度快，避錯誤，反饋準。 后臺的代碼，不能占用大量資源，而且要盡可能讓反應時間小到忽略不計，不能丟出任何一個 Exception，吃不準就用 try。 流程如下：收到請求 → 建立處理線程?→?啟動計時器 → 解析請求?→?確認請求語法有效性?→?確認緩存數(shù)據(jù)有效性?→?讀取緩存?→?（讀取數(shù)據(jù)庫）?→?生成響應?→?發(fā)送響應。 線程處理時間超時，可以先返回 (202) 已接受；系統(tǒng)或數(shù)據(jù)庫繁忙，返回 (503) 服務不可用，并說明原因；處理過程中出現(xiàn) Exception 或錯誤，返回 (500) 服務器內(nèi)部錯誤。 數(shù)據(jù)在緩存與數(shù)據(jù)庫中均無法找到，返回 (404) 未找到，曾經(jīng)存在過的特例，可以考慮 (410) 不存在；URL 更改，返回 (302) 已找到，但不建議使用 (301) 已移動；請求頭部帶 Range，需判斷文件長度是否接受 Range 的范圍，支持則返回 (206) 部分內(nèi)容，不支持則返回 (416) 請求范圍無效。 需要驗證的操作，如果有驗證頭部但無效，則返回 (401) 未認證；無驗證頭部，返回 (403) 已禁止。 緩存需要避免緩存擊穿、雪崩，具體可以去某度搜。 總結

本期講了 Http 基礎知識，包括報文格式、請求方法、請求頭部、狀態(tài)碼、響應頭部，以及服務端的基礎開發(fā)，下期還要繼續(xù)講 Https 與各種雜項知識。 怎樣，是不是感覺 Http 比 TCP 還復雜？ 好了，我們下期再見。 字數(shù)：4296