HTTP協定

HTTP

概念

1、HTTP是Hypertext Transfer Protocol超文本傳輸協定，是一種應用協定

2、HTTP協定是無狀态的

3、HTTP事務是指一次request-response的完整過程

4、HTTP協定是建構在TCP協定之後的，傳輸過程中的分組、重排與防止丢包是TCP進行控制，減少了HTTP協定的複雜性

5、HTTP是端到端，一次HTTP可以明确區分用戶端和服務端，發送請求的為用戶端

6、HTTP目前的協定版本為HTTP/1.1,HTTP/2.0還沒有普及

8、WEB元件包括：代理、緩存、網關、隧道、Agent代理

協定詳解

協定棧位置

鍊路層頭 IP頭 TCP頭 HTTP

封包封裝

封包首部 請求行

狀态行 請求的方法 請求URL HTTP協定版本

HTTP協定版本 響應結構 原因短語

響應首部字段 請求首部：

1、請求封包特有的，如Accept: /

響應首部：

1、響應封包特有的，如Server: Tiki-Hut/1.0

2、比如， Date 首部就是一個通用首部，每一端都可以用它來說明建構封包的時間和日期

空白行 CTRL + LF

封包主體

資源與URL

URI 1、URI 是一類更通用的資源辨別符

2、由兩個主要的子集 URL 和 URN 構成

URL 1、URL 實際上是URI的一個子集

2、URL 分以下三部分：URL 方案（schema）、伺服器的位置（www.joes-hardware.com）、資源路徑（/index.html）

3、格式：

://:@:/;?#

4、如圖

URN

URL編碼

方法、狀态碼、首部

方法

方法 協定版本 說明

GET 1.0、1.1 擷取資源

POST 1.0、1.1 1、POST 方法起初是用來向伺服器輸入資料的

2、向伺服器發送表單資料

HEAD 1.0、1.1 HEAD 方法與 GET 方法的行為很類似，但伺服器在響應中隻傳回首部。不會傳回實體的主體部分

1、在不擷取資源的情況下了解資源的情況（比如，判斷其類型）

2、通過檢視響應中的狀态碼，看看某個對象是否存在

3、通過檢視首部，測試資源是否被修改了

PUT 1.0、1.1 與 GET 從伺服器讀取文檔相反，PUT 方法會向伺服器寫入文檔

如：/PUT.txt ddddd 将ddddd寫入到文檔中

DELETE 1.0、1.1 請伺服器删除請求 URL 所指定的資源

TRACE 1.1 用戶端發起一個請求時，這個請求可能要穿過防火牆、代理、網關或其他一些應用程式。每個中間節點都可能會修改原始的 HTTP 請求。TRACE 方法允許用戶端在最終将請求發送給伺服器時，看看它變成了什麼樣子

OPTIONS 1.1 OPTIONS 方法請求 Web 伺服器告知其支援的各種功能

CONNECT 1.1

LINK 1.0

UNLINK 1.0

狀态碼

僅記錄在 RFC2616 上的 HTTP 狀态碼就達 40 種，若再加上WebDAV（Web-based Distributed Authoring and Versioning，基于網際網路的分布式創作和版本控制）（RFC4918、5842） 和附加 HTTP 狀态碼（RFC6585）等擴充，數量就達 60 餘種。别看種類繁多，實際上經常使用的大概隻有 14 種

1XX Informational（資訊性狀态碼） 接收的請求正在處理

2XX Success（成功狀态碼） 請求正常處理完畢

3XX Redirection（重定向狀态碼） 需要進行附加操作以完成請求

4XX Client Error（用戶端錯誤狀态碼） 伺服器無法處理請求

5XX Server Error（伺服器錯誤狀态碼） 伺服器處理請求出錯

常用的狀态碼

200 OK

表示從用戶端發來的請求在伺服器端被正常處理了

204 No Content

該狀态碼代表伺服器接收的請求已成功處理，但在傳回的響應封包中不含實體的主體部分。另外，也不允許傳回任何實體的主體

206 Partial Content

該狀态碼表示用戶端進行了範圍請求，而伺服器成功執行了這部分的GET 請求。響應封包中包含由 Content-Range 指定範圍的實體内容

301 Moved Permanently

永久性重定向。該狀态碼表示請求的資源已被配置設定了新的 URI，以後

應使用資源現在所指的 URI

如果已經把資源對應的 URI儲存為書簽了，這時應該按 Location 首部字段提示的 URI 重新儲存

302 Found

臨時性重定向

該狀态碼表示請求的資源已被配置設定了新的 URI，希望使用者（本次）能使用新的 URI 通路

303 See Other

該狀态碼表示由于請求對應的資源存在着另一個 URI，應使用 GET方法定向擷取請求的資源

304 Not Modified

該狀态碼表示用戶端發送附帶條件的請求時，伺服器端允許請求訪

問資源，但未滿足條件的情況

304 狀态碼傳回時，不包含任何響應的主體部分。304 雖然被劃分在 3XX 類别中，但是和重定向沒有關系

307 Temporary Redirect

臨時重定向

盡管 302 标準禁止 POST 變換成 GET，但實際使用時大家并不遵守。307 會遵照浏覽器标準，不會從 POST 變成 GET。但是，對于處理響應時的行為，每種浏覽器有可能出現不同的情況

400 Bad Request

該狀态碼表示請求封包中存在文法錯誤

401 Unauthorized

該狀态碼表示發送的請求需要有通過 HTTP 認證（BASIC 認證、DIGEST 認證）的認證資訊

403 Forbidden

該狀态碼表明對請求資源的通路被伺服器拒絕了

404 Not Found

該狀态碼表明伺服器上無法找到請求的資源

500 Internal Server Error

該狀态碼表明伺服器端在執行請求時發生了錯誤

503 Service Unavailable

該狀态碼表明伺服器暫時處于超負載或正在進行停機維護，現在無法處理請求

首部

1、HTTP1.1中RFC中定義了47個首部，詳見RFC2616

通用首部字段

Cache-Control 控制緩存的行為

Connection 逐跳首部、連接配接的管理

Date 建立封包的日期時間

Pragma 封包指令

Trailer 封包末端的首部一覽

Transfer-Encoding 指定封包主體的傳輸編碼方式

Upgrade 更新為其他協定

Via 代理伺服器的相關資訊

Warning 錯誤通知

請求首部字段

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 用戶端程式的資訊

響應首部字段

Accept-Ranges 是否接受位元組範圍請求

Age 推算資源建立經過時間

ETag 資源的比對資訊

Location 令用戶端重定向至指定URI

Proxy-Authenticate 代理伺服器對用戶端的認證資訊

Retry-After 對再次發起請求的時機要求

Server HTTP伺服器的安裝資訊

Vary 代理伺服器緩存的管理資訊

WWW-Authenticate 伺服器對用戶端的認證資訊

實體首部字段

Allow 資源可支援的HTTP方法

Content-Encoding 實體主體适用的編碼方式

Content-Language 實體主體的自然語言

Content-Length 實體主體的大小（機關：位元組）

Content-Location 替代對應資源的URI

Content-MD5 實體主體的封包摘要

Content-Range 實體主體的位置範圍

Content-Type 實體主體的媒體類型

Expires 實體主體過期的日期時間

Last-Modified 資源的最後修改日期時間

一次HTTP請求

HTTP身份認證

BASIC

DIGEST

詳見

<a href="http://blog.csdn.net/andrewpj/article/details/45727853">http://blog.csdn.net/andrewpj/article/details/45727853</a>

<a href="http://www.ietf.org/rfc/rfc2617.txt">http://www.ietf.org/rfc/rfc2617.txt</a>

SSL用戶端

FORM表單

最常見的認證方式

參考

<a href="http://www.ietf.org/rfc/rfc2616.txt">http://www.ietf.org/rfc/rfc2616.txt</a>