part 13.HTTP協議簡介

 

1. 使用谷歌/火狐瀏覽器分析

在Web應用中，服務器把網頁傳給瀏覽器，實際上就是把網頁的HTML代碼發送給瀏覽器，讓瀏覽器顯示出來。而瀏覽器和服務器之間的傳輸協議是HTTP，因此：

• HTML是一種用來定義網頁的文本，會HTML，就能夠編寫網頁；

• HTTP是在網絡上傳輸HTML的協議，用於瀏覽器和服務器的通訊。

Chrome瀏覽器提供了一套完整地調試工具，很是適合Web開發。

安裝好Chrome瀏覽器後，打開Chrome，在菜單中選擇「視圖」，「開發者」，「開發者工具」，就能夠顯示開發者工具：

說明

• Elements顯示網頁的結構
• Network顯示瀏覽器和服務器的通訊

咱們點Network，確保第一個小紅燈亮着，Chrome就會記錄全部瀏覽器和服務器之間的通訊：

 

2. http協議的分析

當咱們在地址欄輸入www.sina.com時，瀏覽器將顯示新浪的首頁。在這個過程當中，瀏覽器都幹了哪些事情呢？經過Network的記錄，咱們就能夠知道。在Network中，找到www.sina.com那條記錄，點擊，右側將顯示Request Headers，點擊右側的view source，咱們就能夠看到瀏覽器發給新浪服務器的請求：

2.1 瀏覽器請求

 

說明：

最主要的頭兩行分析以下，第一行：

 GET / HTTP/1.1 

GET表示一個讀取請求，將從服務器得到網頁數據，/表示URL的路徑，URL老是以/開頭，/就表示首頁，最後的HTTP/1.1指示採用的HTTP協議版本是1.1。目前HTTP協議的版本就是1.1，可是大部分服務器也支持1.0版本，主要區別在於1.1版本容許多個HTTP請求複用一個TCP鏈接，以加快傳輸速度。

從第二行開始，每一行都相似於Xxx: abcdefg：

Host: www.sina.com

表示請求的域名是www.sina.com。若是一臺服務器有多個網站，服務器就須要經過Host來區分瀏覽器請求的是哪一個網站。

2.2 服務器響應

繼續往下找到Response Headers，點擊view source，顯示服務器返回的原始響應數據：

 

HTTP響應分爲Header和Body兩部分（Body是可選項），咱們在Network中看到的Header最重要的幾行以下：

HTTP/1.1 200 OK

200表示一個成功的響應，後面的OK是說明。

若是返回的不是200，那麼每每有其餘的功能，例如

• 失敗的響應有404 Not Found：網頁不存在
• 500 Internal Server Error：服務器內部出錯
• ...等等...

Content-Type: text/html

Content-Type指示響應的內容，這裏是text/html表示HTML網頁。

請注意，瀏覽器就是依靠Content-Type來判斷響應的內容是網頁仍是圖片，是視頻仍是音樂。瀏覽器並不靠URL來判斷響應的內容，因此，即便URL是http://www.baidu.com/meimei.jpg，它也不必定就是圖片。

HTTP響應的Body就是HTML源碼，咱們在菜單欄選擇「視圖」，「開發者」，「查看網頁源碼」就能夠在瀏覽器中直接查看HTML源碼：

 

2.3瀏覽器解析過程

當瀏覽器讀取到新浪首頁的HTML源碼後，它會解析HTML，顯示頁面，而後，根據HTML裏面的各類連接，再發送HTTP請求給新浪服務器，拿到相應的圖片、視頻、Flash、JavaScript腳本、CSS等各類資源，最終顯示出一個完整的頁面。因此咱們在Network下面能看到不少額外的HTTP請求。

 

3. 總結

3.1 HTTP請求

跟蹤了新浪的首頁，咱們來總結一下HTTP請求的流程：

3.1.1 步驟1：瀏覽器首先向服務器發送HTTP請求，請求包括：

方法：GET仍是POST，GET僅請求資源，POST會附帶用戶數據；

路徑：/full/url/path；

域名：由Host頭指定：Host: www.sina.com

以及其餘相關的Header；

若是是POST，那麼請求還包括一個Body，包含用戶數據

3.1.1 步驟2：服務器向瀏覽器返回HTTP響應，響應包括：

響應代碼：200表示成功，3xx表示重定向，4xx表示客戶端發送的請求有錯誤，5xx表示服務器端處理時發生了錯誤；

響應類型：由Content-Type指定；

以及其餘相關的Header；

一般服務器的HTTP響應會攜帶內容，也就是有一個Body，包含響應的內容，網頁的HTML源碼就在Body中。

3.1.1 步驟3：若是瀏覽器還須要繼續向服務器請求其餘資源，好比圖片，就再次發出HTTP請求，重複步驟一、2。

Web採用的HTTP協議採用了很是簡單的請求-響應模式，從而大大簡化了開發。當咱們編寫一個頁面時，咱們只須要在HTTP請求中把HTML發送出去，不須要考慮如何附帶圖片、視頻等，瀏覽器若是須要請求圖片和視頻，它會發送另外一個HTTP請求，所以，一個HTTP請求只處理一個資源(此時就能夠理解爲TCP協議中的短鏈接，每一個連接只獲取一個資源，如須要多個就須要創建多個連接)

HTTP協議同時具有極強的擴展性，雖然瀏覽器請求的是http://www.sina.com的首頁，可是新浪在HTML中能夠鏈入其餘服務器的資源，

好比<img src="http://i1.sinaimg.cn/home/2013/1008/U8455P30DT20131008135420.png">，從而將請求壓力分散到各個服務器上，

而且，一個站點能夠連接到其餘站點，無數個站點互相連接起來，就造成了World Wide Web，簡稱WWW。

3.2 HTTP格式

每一個HTTP請求和響應都遵循相同的格式，一個HTTP包含Header和Body兩部分，其中Body是可選的。

HTTP協議是一種文本協議，因此，它的格式也很是簡單。

3.2.1 HTTP GET請求的格式：

GET /path HTTP/1.1
    Header1: Value1
    Header2: Value2
    Header3: Value3

每一個Header一行一個，換行符是\r\n。

3.2.2 HTTP POST請求的格式：

POST /path HTTP/1.1
    Header1: Value1
    Header2: Value2
    Header3: Value3

    body data goes here...

當遇到連續兩個\r\n時，Header部分結束，後面的數據所有是Body。

3.2.3 HTTP響應的格式：

200 OK
    Header1: Value1
    Header2: Value2
    Header3: Value3

    body data goes here...

HTTP響應若是包含body，也是經過\r\n\r\n來分隔的。

請再次注意，Body的數據類型由Content-Type頭來肯定，若是是網頁，Body就是文本，若是是圖片，Body就是圖片的二進制數據。

當存在Content-Encoding時，Body數據是被壓縮的，最多見的壓縮方式是gzip，因此，看到Content-Encoding: gzip時，須要將Body數據先解壓縮，才能獲得真正的數據。壓縮的目的在於減小Body的大小，加快網絡傳輸。