HTTP的結構

1. HTTP結構圖

HTTP結構圖

---

2. HTTP結構之請求篇

HTTP請求報文結構

(1)組成

http請求報文由三部分組成，分別是：請求行(請求頭)、消息報頭、請求正文。

• 請求頭（請求行）以一個方法符號開頭，以空格分開，後面跟着請求的URI和協議的版本，格式以下：Method Request-URI HTTP-Version CRLF 其中 Method表示請求方法；Request-URI是一個統一資源標識符；HTTP-Version表示請求的HTTP協議版本；CRLF表示回車和換行（除了做爲結尾的CRLF外，不容許出現單獨的CR或LF字符）。請求方法以下：

• 請求正文(實體主體)：通常不用

(2)請求報文的例子

GET /chn/yxsz/index.htm HTTP/1.1 /*請求行使用相對URL*/     
Host:www.tsinghua.edu.cn        /*此行爲首部行的開始，給出主機的域名*/ 
Connection:close               /*告訴服務器發送完請求的文檔可釋放鏈接*/                  
user-Agent:Mozilla/5.0        /*代表用戶代理是使用Netscape瀏覽器*/ 
Accept-Language:cn           /*表示用戶但願優先獲得中文版本的文檔*/
複製代碼

(3)HTTP請求過程（從URL輸入到頁面展示發生什麼？）

a.域名解析(瀏覽器經過向 DNS 服務器發送域名，DNS 服務器查詢(查詢緩存)到與域名相對應的 IP 地址，而後返回給瀏覽器，瀏覽器再將 IP 地址打在協議上，同時請求參數也會在協議搭載，而後一併發送給對應的服務器)

• 查找瀏覽器緩存（DNS緩存）
• 查找操做系統緩存（若是瀏覽器緩存沒有，瀏覽器會從hosts文件查找是否有DNS信息）
• 查找路由緩存
• 查找ISP緩存
• 查找ISP緩存ISP 是互聯網服務提供商(Internet Service Provider)的簡稱，ISP 有專門的 DNS 服務器應對 DNS 查詢請求
• 根服務器：ISP 的 DNS 服務器還找不到的話，它就會向根服務器發出請求，進行遞歸查詢（DNS 服務器先問根域名服務器.com 域名服務器的 IP 地址，而後再問.baidu 域名服務器，依次類推）

b.發起TCP的3次握手（瀏覽器得到對應的ip地址後，瀏覽器與遠程Web服務器經過TCP三次握手協商來創建一個TCP/IP鏈接。）

c.創建TCP鏈接後發送HTTP請求報文

d.服務器處理請求，並返回HTTP響應報文

e.瀏覽器解析,渲染,並繪製到網頁

• 根據 HTML 解析出 DOM 樹
• 根據 CSS 解析生成 CSS 規則樹
• 結合 DOM 樹和 CSS 規則樹，生成渲染樹
• 根據渲染樹計算每個節點的信息
• 根據計算好的信息繪製頁面

f. 斷開鏈接（TCP 四次揮手）

---

3. HTTP結構之響應篇

HTTP響應報文結構

(1)組成

在接收和解釋請求消息後，服務器返回一個HTTP響應消息。HTTP響應也是由三個部分組成，分別是：狀態行、消息報頭、響應正文

• 狀態行包括狀態碼，協議版本，狀態碼描述;(狀態行格式以下：

HTTP-Version Status-Code Reason-Phrase CRLF
複製代碼

其中，HTTP-Version表示服務器HTTP協議的版本；Status-Code表示服務器發回的響應狀態代碼；Reason-Phrase表示狀態代碼的文本描述

a. 1XX（信息響應類，表示接受的請求正在處理）

b. 2XX（處理成功類，表示請求已被成功接收、理解、接受）

200 OK //客戶端請求成功 ，請求被成功處理，服務器會根據不一樣的請求方法返回結果：

GET：請求的對應資源會做爲響應返回。
 HEAD：請求的對應資源的響應頭(entity-header)會做爲響應返回,不包括響應體(message-body)
 POST：返回處理對應請求的結果。
複製代碼

204 No Content //該狀態碼錶示服務器接收到的請求已經處理完畢，可是服務器不須要返回響應體.好比，客戶端是瀏覽器的話，發出的請求返回204響應，那麼瀏覽器顯示的頁面不會發生更新。

206 Partial Content //該狀態碼錶示客戶端進行了範圍請求，而服務器成功執行了這部分的GET請求。客戶端發起的請求，必須在請求頭中包含Range字段。服務端響應報文中，必須包含由Content-Range指定範圍的實體內容(entity-bodies )

c. 3XX（重定向響應類，表示須要客戶端須要進行附加操做）

301 Moved Permanently // 永久重定向 該狀態碼錶示請求的資源已經被分配了新的URI，而且之後使用資源如今所指的URI。而且根據請求的方法有不一樣的處理方式：

HEAD：必須在響應頭部Location字段中指明新的永久性的URI。
GET：除了有Location字段之外，還須要在響應體中附上永久性URI的超連接文本。
POST：客戶端在發送POST請求，受到301響應以後，不該該自動跳轉URI，應當讓用戶確認跳轉。
複製代碼

302 Found // 臨時重定向，該狀態碼錶示請求的資源已被分配了新的URI，但願用戶本次能使用新的URI訪問 和301 Moved Permanently 狀態碼類似，但302狀態碼錶明的資源不是被永久移動，只是臨時性質的。若是，用戶把一個URI收藏爲書籤，302響應是不會像301那樣去更新書籤。

303 See Other //臨時重定向，該狀態碼錶示因爲請求對應的資源存在另外一個URI，應使用GET方法定向獲取請求的資源。303與302不一樣之處在於，302是不會改變請求的方法，若是請 求方法是POST的話，重定向的請求也應該是POST。而對於303，使用POST請求的話，重定向的請求應該是GET請求。

304 Not Modified //資源找到可是不符合請求條件 該狀態碼錶示客戶端發送附帶條件請求時，服務器端容許請求訪問資源，但未知足條件的狀況。304狀態碼返回時，不包含任何響應的主題部分。附帶條件的請求指的是採用GET方法的請求頭中包含：If-Match、If-Modified-Since、If-None-Match、If-Range、If-Unmodified-Since中任一首部。

307 Temporary Redirect //臨時重定向。該狀態碼與302和303的有着相似的含義，不一樣之處在於，307狀態碼並不會指定客戶端要用什麼樣的請求方法請求重定向地址。(302指定使用原有請求方法，303指定使用GET方法)

d. 4XX（客戶端錯誤，請求有語法錯誤或請求沒法實現）

400 Bad Request //錯誤請求 客表示該請求報文中存在語法錯誤，致使服務器沒法理解該請求。客戶端須要修改請求的內容後再次發送請求。

401 Unauthorized //請求未受權 該狀態碼錶示發送的請求須要有經過HTTP認證(Basic認證，Digest認證)的認證信息。返回含有401的響應，必須在頭部包含WWW-Authenticate以指明服務器須要哪一種方式的認證。

403 Forbidden //拒絕 該狀態碼代表對請求資源的訪問被服務器拒絕了。服務器沒有必要給出拒絕的詳細理由，但若是想作說明的話，能夠在實體的主體部分緣由進行描述，這樣就能讓用戶看到了。未得到文件系統的訪問權限，訪問權限出現某些問題，從未受權的發送源IP地址試圖訪問等狀況均可能發生403響應

404 Not Found //未找到 該狀態碼代表服務器上沒法找到指定的資源。一般被用於服務器不想透露拒絕請求的緣由，或者沒有其餘的響應可提供。

405 //方法禁用 禁用請求中指定的方法

e. 5XX（服務端錯誤，服務器處理請求出錯 ）

500 Internal Server Error //服務器內部錯誤 該狀態碼代表服務器端在執行請求時發生了錯誤。也有多是Web應用存在的BUG或某些臨時的故障。

501 //還沒有實施 服務器不具有完成請求的功能。 例如，服務器沒法識別請求方法時可能會返回此代碼。

502 //錯誤網關 服務器做爲網關或代理，從上游服務器收到無效響應。

503 Service Unavailable //服務不可用 狀態碼代表服務器暫時處於超負載或正在進行停機維護，如今沒法處理請求。若是事先得知解除以上須要的時間，最好寫入Retry-After首部字段再返回給客戶端。

504 //網關超時 服務器做爲網關或代理，可是沒有及時從上游服務器收到請求

---

3. HTTP結構之消息報文（HTTP協議頭）篇

(1)組成

HTTP消息由客戶端到服務器的請求和服務器到客戶端的響應組成。請求消息和響應消息都是由開始行（對於請求消息，開始行就是請求行，對於響應消息，開始行就是狀態行），消息報頭（可選），空行（只有CRLF的行），消息正文（可選）組成。 HTTP消息報頭包括普通報頭、請求報頭、響應報頭、實體報頭。 每個報頭域都是由名字+「：」+空格+值 組成，消息報頭域的名字是大小寫無關的。

• 普通報頭

在普通報文頭中，有少數報頭域用於全部的請求和響應消息，但並不用於被傳輸的實體，只用於傳輸的消息。

經常使用的普通報頭

a. Cache-Control:用於指定緩存指令，緩存指令是單向的（響應中出現的緩存指令在請求中未必會出現），且是獨立的（一個消息的緩存指令不會影響另外一個消息處理的緩存機制），HTTP1.0使用的相似的報頭域爲Pragma。

b. Date:普通報頭域表示消息產生的日期和時間

c. Connection:普通報頭域容許發送指定鏈接的選項。例如指定鏈接是連續，或者指定「close」選項，通知服務器，在響應完成後，關閉鏈接

• 請求報頭

請求報頭容許客戶端向服務器端傳遞請求的附加信息以及客戶端自身的信息。

經常使用的請求報頭

a.Accept

Accept請求報頭域用於指定客戶端接受哪些類型的信息。eg：Accept：image/gif，代表客戶端但願接受GIF圖象格式的源； Accept：text/html，代表客戶端但願接受html文本

b.Accept-Charset

Accept-Charset請求報頭域用於指定客戶端接受的字符集。 eg：Accept-Charset:iso-8859-1,gb2312 若是在請求消息中沒有設置這個域，缺省是任何字符集均可以接受。

c.Accept-Encoding

Accept-Encoding請求報頭域相似於Accept，可是它是用於指定可接受的內容編碼。eg：Accept-Encoding:gzip,deflate 若是請求消息中沒有設置這個域服務器假定客戶端對各類內容編碼均可以接受。

d.Accept-Language

Accept-Language請求報頭域相似於Accept，可是它是用於指定一種天然語言。eg：Accept-Language:zh-cn若是請求消息中沒有設置這個報頭域，服務器假定客戶端對各類語言均可以接受。

e.Authorization

Authorization請求報頭域主要用於證實客戶端有權查看某個資源。當瀏覽器訪問一個頁面時，若是收到服務器的響應代碼爲401（未受權），能夠發送一個包含Authorization請求報頭域的請求，要求服務器對其進行驗證。

f.Host（發送請求時，該報頭域是必需的）

Host請求報頭域主要用於指定被請求資源的Internet主機和端口號，它一般從HTTP URL中提取出來的，eg：咱們在瀏覽器中輸入：http://www.guet.edu.cn/index.html;瀏覽器發送的請求消息中，就會包含Host請求報頭域，以下： Host：www.guet.edu.cn此處使用缺省端口號80，若指定了端口號，則變成：Host：www.guet.edu.cn:指定端口號

g.User-Agent

User-Agent請求報頭域容許客戶端將它的操做系統、瀏覽器和其它屬性告訴服務器。 請求報頭舉例：

GET /form.html HTTP/1.1 (CRLF)
Accept:image/gif,image/x-xbitmap,image/jpeg,application/x-shockwave-flash,application/vnd.ms-excel,application/vnd.ms-powerpoint,application/msword,*/* (CRLF)
Accept-Language:zh-cn (CRLF)
Accept-Encoding:gzip,deflate (CRLF)
If-Modified-Since:Wed,05 Jan 2007 11:21:25 GMT (CRLF)
If-None-Match:W/"80b1a4c018f3c41:8317" (CRLF)
User-Agent:Mozilla/4.0(compatible;MSIE6.0;Windows NT 5.0) (CRLF)
Host:www.guet.edu.cn (CRLF)
Connection:Keep-Alive (CRLF)
(CRLF)
複製代碼

• 響應報頭

響應報頭容許服務器傳遞不能放在狀態行中的附加響應信息，以及關於服務器的信息和對Request-URI所標識的資源進行下一步訪問的信息。

經常使用的響應報頭

a. Location

Location響應報頭域用於重定向接受者到一個新的位置。Location響應報頭域經常使用在更換域名的時候。

b.Server

Server響應報頭域包含了服務器用來處理請求的軟件信息。與User-Agent請求報頭域是相對應的。下面是 Server響應報頭域的一個例子： Server：Apache-Coyote/1.1 WWW-Authenticate WWW-Authenticate響應報頭域必須被包含在401（未受權的）響應消息中，客戶端收到401響應消息時候，併發送Authorization報頭域請求服務器對其進行驗證時，服務端響應報頭就包含該報頭域。 eg：WWW-Authenticate:Basic realm="Basic Auth Test!" //能夠看出服務器對請求資源採用的是基本驗證機制。

• 實體報頭

請求和響應消息均可以傳送一個實體。一個實體由實體報頭域和實體正文組成，但並非說實體報頭域和實體正文要在一塊兒發送，能夠只發送實體報頭域。實體報頭定義了關於實體正文（eg：有無實體正文）和請求所標識的資源的元信息。

經常使用的實體報頭

a. Content-Encoding

Content-Encoding實體報頭域被用做媒體類型的修飾符，它的值指示了已經被應用到實體正文的附加內容的編碼，於是要得到Content-Type報頭域中所引用的媒體類型，必須採用相應的解碼機制。Content-Encoding這樣用於記錄文檔的壓縮方法，eg：Content-Encoding：gzip

b. Content-Language

Content-Language實體報頭域描述了資源所用的天然語言。沒有設置該域則認爲實體內容將提供給全部的語言閱讀 者。eg：Content-Language:da

c.Content-Length

Content-Length實體報頭域用於指明實體正文的長度，以字節方式存儲的十進制數字來表示。

d. Content-Type

Content-Type實體報頭域用語指明發送給接收者的實體正文的媒體類型。eg：

Content-Type:text/html;charset=ISO-8859-1
Content-Type:text/html;charset=GB2312
複製代碼

e. Last-Modified

Last-Modified實體報頭域用於指示資源的最後修改日期和時間。

f. Expires

Expires實體報頭域給出響應過時的日期和時間。爲了讓代理服務器或瀏覽器在一段時間之後更新緩存中(再次訪問曾訪問過的頁面時，直接從緩存中加載，縮短響應時間和下降服務器負載)的頁面，咱們可使用Expires實體報頭域指定頁面過時的時間。eg：Expires：Thu，15 Sep 2006 16:23:12 GMT HTTP1.1的客戶端和緩存必須將其餘非法的日期格式（包括0）看做已通過期。eg：爲了讓瀏覽器不要緩存頁面，咱們也能夠利用Expires實體報頭域，設置爲0，jsp中程序以下：response.setDateHeader("Expires","0");

---

參考文章

• blog.csdn.net/gueter/arti…
• github.com/fortheallli…
• www.cnblogs.com/fundebug/p/…
• www.cnblogs.com/xianyulaodi…
• my.oschina.net/snowing1990…