TCP/IP協議族

在介紹 HTTP 協議之前，我們先對 TCP/IP 協議族有個大概的了解，TCP/IP 協議從上到下主要分為應用層、傳輸層、網絡層和數據鏈路層，各層的主要功能如下表所示：

協議層	功能	詳細說明
應用層	向用戶提供應用服務時通信的活動	比如FTP、DNS、Telnet等服務
傳輸層	對上層應用層提供處于網絡連接中的兩臺計算機之間的數據傳輸	該層包括TCP、UDP兩個性質不同的協議
網絡層	處理網絡數據包，規定通過怎樣的路徑到達對方計算機，并把數據包傳輸給對方	與對方計算機之間通過多臺計算機或網絡設備進行傳輸時，網絡層所起的作用就是在眾多的選項內選擇一條
數據鏈路層	用來處理連接網絡的硬件部分	包括操作系統中的設備驅動程序和計算機中對應的網卡

TCP/IP 通信傳輸流

TCP/IP 通信傳輸流的整體過程如下，其中發送端在層與層之間傳輸數據時，每經過一層時必定會被打上一個該層所屬的首部信息。反之，接收端在層與層傳輸數據時，每經過一層時會把對應的首部消去。

URI 與 URL 的區別

• URI：Uniform Resource Identifier 統一資源標識符

• URL：Uniform Resource Locator 統一資源定位符

  URI 用字符串標識某一互聯網資源，而 URL 表示資源的地點，所以一般來講 URL 是 URI 的一個子集。

  看個例子：

  http://user:password@www.example.com:80/dir/index.html?uid=1#ch1

  http: 協議方案名

  user:password：登陸認證信息，屬于可選項

  www.example.com：服務器地址

  80： 服務器端口號

  dir/index.html?： 帶層次文件路徑

  uid=1：查詢字符串，屬于可選項

  ch1： 片段標識符，屬于可選項

HTTP 是不保存狀態的協議

HTTP 是一種不保存狀態，即無狀態（stateless）協議。HTTP 協議自身不對請求和響應之間的通信狀態進行保存。也就是說在 HTTP 這個級別，協議對于發送過的請求或響應都不做持久化處理。

使用 HTTP 協議，每當有新的請求發送時，就會有對應的新響應產生。協議本身并不保留之前一切的請求或響應報文的信息。

HTTP/1.1 雖然是無狀態協議，但為了實現期望的保持狀態功能，于是引入了 Cookie 技術。有了 Cookie 再用 HTTP 協議通信，就可以管理狀態了。

Cookie 狀態管理

Cookie 技術通過在請求和響應報文中寫入 Cookie 信息來控制客戶端的狀態。

Cookie 會根據從服務器端發送的響應報文內的一個叫做 Set-Cookie 的首部字段信息，通知客戶端保存Cookie。當下次客戶端再往該服務器發送請求時，客戶端會自動在請求報文中加入Cookie 值后發送出去。

服務器端發現客戶端發送過來的 Cookie 后，會去檢查究竟是從哪一個客戶端發來的連接請求，然后對比服務器上的記錄，最后得到之前的狀態信息。

HTTP 支持的方法

主要方法	功能說明
GET	獲取資源
POST	傳輸實體主體，一般用于向服務器提交數據
PUT	傳輸文件
HEAD	獲取報文首部
DELETE	刪除文件
OPTIONS	詢問服務器支持的方法
TRACE	追蹤路徑
CONNECT	要求用隧道協議連接

HTTP/1.1 的 DELETE 方法本身和 PUT 方法一樣不帶驗證機制，所以一般的 Web 網站也不使用 DELETE 方法。當配合 Web 應用程序的驗證機制，或遵守 REST 標準時還是有可能會開放使用的。

CONNECT 方法要求在與代理服務器通信時建立隧道，實現用隧道協議進行 TCP 通信。主要使用 SSL（Secure Sockets Layer，安全套接層）和 TLS（Transport Layer Security，傳輸層安全）協議把通信內容加密后經網絡隧道傳輸。

持久化連接

持久連接的特點是，只要任意一端（客戶端或者服務器）沒有明確提出斷開連接，則保持 TCP 連接狀態，目的就是在建立 1 次 TCP 連接后進行多次請求和響應的交互。

持久連接的好處在于減少了 TCP 連接的重復建立和斷開所造成的額外開銷，減輕了服務器端的負載。另外，減少開銷的那部分時間，使HTTP 請求和響應能夠更早地結束，這樣 Web 頁面的顯示速度也就相應提高了。

在 HTTP/1.1 中，所有的連接默認都是持久連接。

狀態碼類別

狀態碼	類型	說明
1XX	Informational（信息性狀態碼）	接收的請求正在處理
2XX	Success（成功狀態碼）	請求正常處理完畢
3XX	Redirection（重定向狀態碼）	需要進行附加操作以完成請求
4XX	Client Error（客戶端錯誤狀態碼）	服務器無法處理請求
5XX	Server Error（服務器錯誤狀態碼）	服務器處理請求出錯

用戶身份認證

• BASIC 認證（基本認證）

  BASIC 認證的主要步驟：

  BASIC 認證雖然采用 Base64 編碼方式，但這不是加密處理。不需要任何附加信息即可對其解碼。換言之，由于明文解碼后就是用戶 ID和密碼，在 HTTP 等非加密通信的線路上進行 BASIC 認證的過程中，如果被人竊聽，被盜的可能性極高。

• DIGEST 認證（摘要認證）

  DIGEST 認證同樣使用質詢 / 響應的方式（challenge/response），但不會像 BASIC 認證那樣直接發送明文密碼。

  所謂質詢響應方式是指，一開始一方會先發送認證要求給另一方，接著使用從另一方那接收到的質詢碼計算生成響應碼。最后將響應碼返回給對方進行認證的方式。

  因為發送給對方的只是響應摘要及由質詢碼產生的計算結果，所以比起 BASIC 認證，密碼泄露的可能性就降低了。

  DIGEST 認證的主要步驟：

  DIGEST 認證提供了高于 BASIC 認證的安全等級，但是和 HTTPS 的客戶端認證相比仍舊很弱。DIGEST 認證提供防止密碼被竊聽的保護機制，但并不存在防止用戶偽裝的保護機制。
  DIGEST 認證和 BASIC 認證一樣，使用上不那么便捷靈活，且仍達不到多數 Web 網站對高度安全等級的追求標準。因此它的適用范圍也有所受限。

• SSL 客戶端認證

• FormBase 認證（基于表單認證）

  多數情況下，輸入已事先登錄的用戶 ID（通常是任意字符串或郵件地址）和密碼等登錄信息后，發送給 Web 應用程序，基于認證結果來決定認證是否成功。

Session 管理及 Cookie 應用

基于表單認證本身是通過服務器端的 Web 應用，將客戶端發送過來的用戶 ID 和密碼與之前登錄過的信息做匹配來進行認證的。

但鑒于 HTTP 是無狀態協議，之前已認證成功的用戶狀態無法通過協議層面保存下來。即，無法實現狀態管理，因此即使當該用戶下一次繼續訪問，也無法區分他與其他的用戶。于是我們會使用 Cookie 來管理 Session，以彌補 HTTP 協議中不存在的狀態管理功能。

步驟 1： 客戶端把用戶 ID 和密碼等登錄信息放入報文的實體部分，通常是以 POST 方法把請求發送給服務器。而這時，會使用 HTTPS通信來進行 HTML 表單畫面的顯示和用戶輸入數據的發送。

步驟 2： 服務器會發放用以識別用戶的 Session ID。通過驗證從客戶端發送過來的登錄信息進行身份認證，然后把用戶的認證狀態與Session ID 綁定后記錄在服務器端。

向客戶端返回響應時，會在首部字段 Set-Cookie 內寫入 SessionID（如PHPSESSID=028a8c…）。

步驟 3： 客戶端接收到從服務器端發來的 Session ID 后，會將其作為Cookie 保存在本地。下次向服務器發送請求時，瀏覽器會自動發送Cookie，所以 Session ID 也隨之發送到服務器。服務器端可通過驗證接收到的 Session ID 識別用戶和其認證狀態。

HTTP 首部字段

HTTP 首部字段根據實際用途被分為以下 4 種類型。

1).通用首部字段（General Header Fields）

請求報文和響應報文兩方都會使用的首部。

首部字段名	說明
Cache-Control	控制緩存的行為
Connection	逐跳首部、連接的管理
Date	創建報文的日期時間
Pragma	報文指令
Trailer	報文末端的首部一覽
Transfer-Encoding	指定報文主體的傳輸編碼方式
Upgrade	升級為其他協議
Via	代理服務器的相關信息
Warning	錯誤通知

2).請求首部字段（Request Header Fields）

從客戶端向服務器端發送請求報文時使用的首部。補充了請求的附加內容、客戶端信息、響應內容相關優先級等信息。

首部字段名	說明
Accept	用戶代理可處理的媒體類型
Accept-Charset	優先的字符集
Accept-Encoding	優先的內容編碼
Accept-Language	優先的語言（自然語言）
Authorization	Web認證信息
Expect	期待服務器的特定行為
From	用戶的電子郵箱地址
Host	請求資源所在服務器
If-Match	比較實體標記（ETag）
If-Modified-Since	比較資源的更新時間
If-None-Match	比較實體標記（與 If-Match 相反）
If-Range	資源未更新時發送實體 Byte 的范圍請求
If-Unmodified-Since	比較資源的更新時間（與If-Modified-Since相反）
Max-Forwards	最大傳輸逐跳數
Proxy-Authorization	代理服務器要求客戶端的認證信息
Range	實體的字節范圍請求
Referer	對請求中 URI 的原始獲取方
TE	傳輸編碼的優先級
User-Agent	HTTP 客戶端程序的信息

3).響應首部字段（Response Header Fields）

從服務器端向客戶端返回響應報文時使用的首部。補充了響應的附加內容，也會要求客戶端附加額外的內容信息。

首部字段名	說明
Accept-Ranges	是否接受字節范圍請求
Age	推算資源創建經過時間
ETag	資源的匹配信息
Location	令客戶端重定向至指定URI
Proxy-Authenticate	代理服務器對客戶端的認證信息
Retry-After	對再次發起請求的時機要求
Server	HTTP服務器的安裝信息
Vary	代理服務器緩存的管理信息
WWW-Authenticate	服務器對客戶端的認證信息

4).實體首部字段（Entity Header Fields）

針對請求報文和響應報文的實體部分使用的首部。補充了資源內容更新時間等與實體有關的信息。

首部字段名	說明
Allow	資源可支持的HTTP方法
Content-Encoding	實體主體適用的編碼方式
Content-Language	實體主體的自然語言
Content-Length	實體主體的大小（單位：字節）
Content-Location	替代對應資源的URI
Content-MD5	實體主體的報文摘要
Content-Range	實體主體的位置范圍
Content-Type	實體主體的媒體類型
Expires	實體主體過期的日期時間
Last-Modified	資源的最后修改日期時間

總結

以上是生活随笔為你收集整理的HTTP 协议入门 — （TCP/IP协议族、通信传输流、URI 与 URL 的区别、Cookie 状态管理、HTTP 支持的方法、状态码类别、HTTP 首部字段）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。