HTTP協議簡述

1.HTTP協議簡介

1.HTTP協議介紹

1.HTTP協議（HyperText Transfer Protocol，超文本傳輸協議）是因特網上應用最爲普遍的一種網絡傳輸協議，全部的WWW文件都必須遵照這個標準。

2.HTTP是基於TCP/IP通訊協議來傳遞數據（HTML 文件, 圖片文件, 查詢結果等）

2.HTTP協議一般承載於TCP協議之上，有時也承載於TLS或SSL協議層之上，這個時候，就成了咱們常說的HTTPS。

3.HTTP是一個應用層協議，由請求和響應構成，是一個標準的客戶端服務器模型。HTTP是一個無狀態的協議。

4.HTTP默認的端口號爲80，HTTPS的端口號爲443。

HTTP協議工做流程

一次HTTP操做稱爲一個事務，其工做過程大概以下：

1.用戶在瀏覽器中鍵入須要訪問網頁的URL或者點擊某個網頁中連接；

2.瀏覽器根據URL中的域名，經過DNS解析出目標網頁的IP地址；

eg：

a.瀏覽器請求這個頁面：hackr.ip/index.html

b.在這一步，須要域名系統DNS解析域名hackr.ip,得主機的IP地址 20X.189.105.112。

c.而後將上面結合本機本身的信息，封裝成一個http請求數據包

3.在HTTP開始工做前，客戶端首先會經過TCP/IP協議來和服務端創建連接（TCP三次握手）

4.創建鏈接後，客戶機發送一個請求給服務器，請求方式的格式爲：統一資源標識符（URL）、協議版本號，後邊是MIME信息包括請求修飾符、客戶機信息和內容。

5.服務器接到請求後，給予相應的響應信息，其格式爲一個狀態行，包括信息的協議版本號、一個成功或錯誤的代碼，後邊是MIME信息包括服務器信息、實體信息和可能的內容。

6.通常狀況下，一旦Web服務器向瀏覽器發送了請求數據，它就要關閉TCP鏈接，然而若是瀏覽器或者服務器在其頭信息加入了這行代碼：Connection:keep-alive，TCP鏈接在發送後將仍然保持打開狀態，因而，瀏覽器能夠繼續經過相同的鏈接發送請求。保持鏈接節省了爲每一個請求創建新鏈接所需的時間，還節約了網絡帶寬。

2.1 短鏈接

短鏈接的操做步驟是：創建鏈接——數據傳輸——關閉鏈接...創建鏈接——數據傳輸——關閉鏈接

若是客戶請求頻繁，將在TCP的創建和關閉操做上浪費較多時間和帶寬。

2.2 長連接

示意：長連接,指在一個鏈接上能夠連續發送多個數據包，在鏈接保持期間，若是沒有數據包發送，須要雙方發鏈路檢測包。

長連接操做步驟：創建鏈接——數據傳輸...（保持鏈接）...數據傳輸——關閉鏈接

長鏈接能夠省去較多的TCP創建和關閉的操做，減小浪費，節約時間

長連接分爲 without pipelining 和 with pipelining，下圖中是without

pipelining，客戶端只在收到前一個請求的響應後，才發出新的請求

2.3 管線化

下圖是with pipelining，每次創建連接後無需等待請求回來就能夠發送下一個請求

3. Http請求報文

客戶端發送一個HTTP請求到服務器的請求消息包括如下格式：

請求行（request line）、請求頭部（header）、請求體組成，下圖給出了請求報文的通常格式。

請求行:

方法:
    GET 獲取資源
    POST 向服務器端發送數據，傳輸實體主體
    PUT 傳輸文件
    HEAD 獲取報文首部
    DELETE 刪除文件
    OPTIONS 詢問支持的方法
    TRACE 追蹤路徑
協議/版本號
URL
複製代碼

請求頭:

通用首部(General Header)
請求首部(Request Header)
響應首部(Response Header)
實體首部(Entity Header Fields)
複製代碼

請求體

請求報文拆解：

3.1 get請求

3.2 post請求

4. Http響應報文

HTTP響應組成：響應行、響應頭、響應體。

響應行

（HTTP/1.1）代表HTTP版本爲1.1版本，狀態碼爲200，狀態消息爲（ok）
複製代碼

響應頭

Date:生成響應的日期和時間；
Content-Type:指定了MIME類型的HTML(text/html),編碼類型是ISO-8859-1
複製代碼

響應體

響應報文拆解：

5. Http狀態碼

類別 緣由

1XX Informational(信息性狀態碼)

2XX Success(成功狀態碼)

3XX Redirection(重定向)

4XX Client Error(客戶端錯誤狀態碼)

5XX Server Error(服務器錯誤狀態嗎)

5.1 2XX 成功

200(OK 客戶端發過來的數據被正常處理

204(Not Content 正常響應，沒有實體

206(Partial Content 範圍請求，返回部分數據，響應報文中由Content-Range指定實體內容

5.2 3XX 重定向

301(Moved Permanently) 永久重定向

302(Found) 臨時重定向，規範要求，方法名不變，可是都會改變

303(See Other) 和302相似，但必須用GET方法

304(Not Modified) 狀態未改變，

配合(If-Match、If-Modified-Since、If-None_Match、If-Range、If-Unmodified-Since)

307(Temporary Redirect) 臨時重定向，不應改變請求方法

5.3 4XX 客戶端錯誤

• 400(Bad Request) 請求報文語法錯誤

• 401 (unauthorized) 須要認證

• 403(Forbidden) 服務器拒絕訪問對應的資源

• 404(Not Found) 服務器上沒法找到資源

5.4 5XX 服務器端錯誤

• 500(Internal Server Error)服務器故障

• 503(Service Unavailable) 服務器處於超負載或正在停機維護

6. 首部

6.1 通用首部字段

首部字段名 說明

• Cache-Control 控制緩存行爲

• Connection 連接的管理

• Date 報文日期

• Pragma 報文指令

• Trailer 報文尾部的首部

• Trasfer-Encoding 指定報文主體的傳輸編碼方式

• Upgrade 升級爲其餘協議

• Via 代理服務器信息

• Warning 錯誤通知

6.2 請求首部字段

首部字段名 說明

Accept 用戶代理可處理的媒體類型

Accept-Charset 優先的字符集

Accept-Encoding 優先的編碼

Accept-Langulage 優先的語言

Authorization Web認證信息

Expect 期待服務器的特定行爲

From 用戶的電子郵箱地址

Host 請求資源所在的服務器

If-Match 比較實體標記

If-Modified-Since 比較資源的更新時間

If-None-Match 比較實體標記

If-Range 資源未更新時發送實體Byte的範圍請求

If-Unmodified-Since 比較資源的更新時間(和If-Modified-Since相反)

Max-Forwards 最大傳輸跳數

Proxy-Authorization 代理服務器須要客戶端認證

Range 實體字節範圍請求

Referer 請求中的URI的原始獲取方

TE 傳輸編碼的優先級

User-Agent HTTP客戶端程序的信息

6.3 響應首部字段

首部字段名 說明

Accept-Ranges 是否接受字節範圍

Age 資源的建立時間

ETag 資源的匹配信息

Location 客戶端重定向至指定的URI

Proxy-Authenticate 代理服務器對客戶端的認證信息

Retry-After 再次發送請求的時機

Server 服務器的信息

Vary 代理服務器緩存的管理信息

www-Authenticate 服務器對客戶端的認證

6.4 實體首部字段

首部字段名 說明

Allow 資源可支持的HTTP方法

Content-Encoding 實體的編碼方式

Content-Language 實體的天然語言

Content-Length 實體的內容大小(字節爲單位)

Content-Location 替代對應資源的URI

Content-MD5 實體的報文摘要

Content-Range 實體的位置範圍

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

Expires 實體過時時間

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

七、HTTP中的重定向和請求轉發的區別

解釋一   一句話，轉發是服務器行爲，重定向是客戶端行爲。爲何這樣說呢，這就要看兩個動做的工做流程：

轉發過程：客戶瀏覽器發送http請求----》web服務器接受此請求--》調用內部的一個方法在容器內部完成請求處理和轉發動做----》將目標資源發送給客戶；在這裏，轉發的路徑必須是同一個web容器下的url，其不能轉向到其餘的web路徑上去，中間傳遞的是本身的容器內的request。在客戶瀏覽器路徑欄顯示的仍然是其第一次訪問的路徑，也就是說客戶是感受不到服務器作了轉發的。轉發行爲是瀏覽器只作了一次訪問請求。

重定向過程：客戶瀏覽器發送http請求----》web服務器接受後發送302狀態碼響應及對應新的location給客戶瀏覽器--》客戶瀏覽器發現是302響應，則自動再發送一個新的http請求，請求url是新的location地址----》服務器根據此請求尋找資源併發送給客戶。在這裏location能夠重定向到任意URL，既然是瀏覽器從新發出了請求，則就沒有什麼request傳遞的概念了。在客戶瀏覽器路徑欄顯示的是其重定向的路徑，客戶能夠觀察到地址的變化的。重定向行爲是瀏覽器作了至少兩次的訪問請求的。

解釋二

重定向，實際上是兩次request, 第一次，客戶端request A,服務器響應，並response回來，告訴瀏覽器，你應該去B。這個時候IE能夠看到地址變了，並且歷史的回退按鈕也亮了。重定向能夠訪問本身web應用之外的資源。在重定向的過程當中，傳輸的信息會被丟失。

請求轉發是服務器內部把對一個request/response的處理權，移交給另一個 對於客戶端而言，它只知道本身最先請求的那個A，而不知道中間的B，甚至C、D。 傳輸的信息不會丟失。

解釋三 假設你去辦理某個執照，

重定向：你先去了A局，A局的人說：「這個事情不歸咱們管，去B局」，而後，你就從A退了出來，本身乘車去了B局。

轉發：你先去了A局，A局看了之後，知道這個事情其實應該B局來管，可是他沒有把你退回來，而是讓你坐一下子，本身到後面辦公室聯繫了B的人，讓他們辦好後，送了過來。