HTTP 通用首部字段

Http 協(xié)議除了我們的請求和響應參數(shù)，還包含了很多首部字段，這些字段使 Http 在滿足基本接口的請求接收參數(shù)之余，還有更多高級豐富的擴展。這些首部字段可以分為3類：通用首部字段 / 請求首部字段 / 響應首部字段。本節(jié)我們將學習的是通用首部字段。

1. 簡介

通用的首部字段指的是請求和響應的首部都能使用的字段。

請求示例

GET / HTTP/1.1
Host: idcbgp.cn
Connection: keep-alive

請求實體內(nèi)容

響應示例

HTTP/1.1 200 OK
Date: Web 29 Apr 2020 08:08:08 GMT
Connection: keep-alive

響應實體內(nèi)容

示例中請求和響應的協(xié)議首部均有 Connection 字段，這類即為公共首部字段。

2. 字段介紹

2.1 Connection

Upgrade

該字段用來支持以一種協(xié)議建立連接后，想要升級成更高層的協(xié)議，比如 Http/1.1 想要升級成 Http/2.0 的協(xié)議，或者說要升級成 Websocket 協(xié)議。

Upgrade：websocket
Connection: Upgrade

如果 Connection 的值是 Upgrade ，通常也需要一個 Upgrade 字段來標明要升級的協(xié)議，該值可以是多個的逗號分隔開，服務端會按照順序查看支持的升級服務。

上面客戶端想要升級成 Websocket 協(xié)議，如果服務端支持就會返回一個 101 Switching Protocols 響應狀態(tài)碼，和一個要切換到的協(xié)議的頭部字段 Upgrade。 如果服務器沒有（或者不能）升級這次連接，它會忽略客戶端發(fā)送的 Upgrade 頭部字段，返回一個常規(guī)的響應。

Close

Http/1.1 規(guī)定了默認保持長連接（HTTP persistent connection ，也有翻譯為持久連接），數(shù)據(jù)傳輸完成了保持 TCP 連接不斷開（不發(fā) RST 包、不四次握手），等待在同域名下繼續(xù)用這個通道傳輸數(shù)據(jù)。當服務器端想明確斷開連接時，則指定 Connection 首部字段的值為 Close。

Connection: close

Keep-Alive

Http/1.1 之前的 HTTP 版本的默認連接都是非持久連接。為此， 如果想在舊版本的 HTTP 協(xié)議上維持持續(xù)連接，則需要指定 Connection 首部字段的值為 Keep-Alive。

Connection: Keep-Alive

2.2 Cache-Control

通過指定首部字段 Cache-Control 的指令，就能操作緩存的工作機制。

請求緩存

• no-cache：不讀取過期的資源；
• no-store：不緩存；
• max-age = [ 秒]：響應的最大 Age 值；
• max-stale( = [ 秒 ])：接收已過期的響應；
• min-fresh = [ 秒 ]：期望在指定時間內(nèi)的響應仍有效；
• no-transform：代理不可更改媒體類型；
• only-if-cached：只讀緩存的資源；
• cache-extension：可以拓展 Cache-Control 首部字段內(nèi)的指令。

響應緩存

• public：可向任意方提供響應的緩存；
• private：僅向特定用戶返回響應；
• no-cache：緩存前必須先確認其有效性；
• no-store：不緩存請求或響應的任何內(nèi)容；
• no-transform：代理不可更改媒體類型；
• must-revalidate：可緩存但必須再向源服務器進行確認；
• proxy-revalidate：可緩存但必須再向源服務器進行確認；
• max-age = [ 秒] ：響應的最大 Age 值；
• s-maxage = [ 秒]：可以拓展 Cache-Control 首部字段內(nèi)的指令；

2.3 Date

表明協(xié)議的日期，并沒有什么特殊含義，在這里就不過多贅述了。

2.4 Trailer

Trailer 是拖車的意思，正常的報文是 首部字段+回車符+請求體，Trailer 允許在請求體的后面再添加首部信息。Trailer 的值會先表明請求體后面的首部字段是什么。

HTTP/1.1 200 OK
Trailer: Expires

--報文--
Expires: May, 1 Sep 2020 23:59:59 GMT

使用場景：首部字段的值是動態(tài)生成的，事先無法知道。如 content-length 請求體的長度，在分塊傳輸中一開始無法確定內(nèi)容的長度。還有一些可能是消息的數(shù)字簽名，完整性校驗等。

2.5 Transfer-Encoding

可以通過此頭屬性確定通信內(nèi)容的傳輸方式，如果指定 chunk 表示把大資源分為多個小塊進行傳輸 。
通常情況下靜態(tài)資源等小文件傳輸時可以指定 Content-Length 告知通信雙方文件大小，而當傳輸資源無法確定大小時可以指定該屬性進行傳輸
通信雙方也無需知道文件大小，這樣可以節(jié)省內(nèi)存空間。此屬性和 Content-Length 沖突，不能同時指定。

2.6 Via

每經(jīng)過一個代理服務器就往 head via 字段添加服務器信息，可以用來追蹤請求的傳輸路徑。

2.7 Warning

用來告知客戶端的一些告警信息。

3. 小結

通用首部字段不多，一般是用來表示 緩存 / 時間 / 連接信息等通用內(nèi)容。 其中 Connection 和 Cache-Control 是很常見的首部內(nèi)容，要清楚的掌握它。