【web必知必會】——圖解HTTP（上）

　　本篇總結關於http的相關知識，主要內容參考以下導圖：

　　主要講解的內容有：

　　1 URL與URI的區別。

　　2 請求報文與相應報文的內容。

　　3 GET與POST的區別。

　　4 http的cookie、持久化、管道化、多部分對象集合、範圍請求等

　　後續會更新http其餘的相關知識。

　　關鍵詞概念

　　平時會常常接觸到URL，他就是咱們訪問web的一個字符串地址，那麼URI是什麼呢？他們是什麼關係呢？

　　先看看官方的解釋：

　　URL：uniform resource location 統一資源定位符

　　URI：uniform resource identifier 統一資源標識符

　　這也就是說，URI是一種資源的標識；而URL也是一種URI，也是一種資源的標識，但它也指明瞭如何定位Locate到這個資源。

　　URI是一種抽象的資源標識，既能夠是絕對的，也能夠是相對的。可是URL是一種URI，它指明瞭定位的信息，必須是絕對的。

　　而咱們平時所說的相對地址，僅僅是相對於另外一個絕對地址而言。

 

　　RFC：reqeust for comments 徵求修正意見書

　　RFC素有網絡知識聖經之稱，規定了網絡中協議的基本內容。所以許多的不一樣系統的應用程序才能夠互相訪問。

 

　　報文格式

　　首先報文的格式以下：

　　其中空行用於區分報文首部和報文主體內容，是由一個回車符和一個換行符組成。

　　不管是請求報文仍是響應報文都須要有報文首部，固然報文主體有的請求報文是沒有的。

　　通常來講，請求報文的格式以下：

　　其中請求首部還包括其餘的內容，不一一列舉了。

　　響應報文格式以下：

　　下面咱們看一下在不一樣的瀏覽器中http報文的內容：

　　上圖是chrome中http的內容，其中request headers描述了請求報文頭部的內容，response headers描述了響應報文頭部的內容。

　　其中最長使用的屬性是：

　　1 URL, 即http訪問的地址

　　2 request method, 報文的請求方式

　　3 status code, 狀態碼以及狀態短語

　　4 Accept Encoding, 內容編碼

　　5 Connection, 鏈接方式

　　6 Cookie, 添加的cookie內容

　　7 Host, 目標主機

　　8 User-Agent, 客戶端瀏覽器的相關信息

　　9 Set-Cookie, 指定想要在Cookie中保存的內容

　　經常使用的屬性內容就是上面這些。

　　在IE中捕獲到的顯示方式不一樣，可是內容都是相同的：

　　http請求方式

　　如何發送http有不少種方式，可是最經常使用的就是POST和GET。

　　其餘的有些出於安全性的考慮通常都不建議使用。那麼POST與GET有什麼區別呢？

　　1 使用目標不一樣：

　　　　POST與GET都用於獲取信息，可是GET方式僅僅是查詢，並不對服務器上的內容產生任何做用結果；每次GET的內容都是相同的。

　　　　POST則經常使用於發送必定的內容進行某些修改操做。

　　2 大小不一樣：

　　　　因爲不一樣的瀏覽器對URL的長度大小有必定的字符限制，所以因爲GET方式放在URL的首部中，天然也跟着首先，可是具體的大小要依瀏覽器而定。

　　　　POST方式則是把內容放在報文內容中，所以只要報文的內容沒有限制，它的大小就沒有限制。

　　3 安全性不一樣：

　　　　上面也說了GET是直接添加到URL後面的，直接就能夠在URL中看到內容。

　　　　而POST是放在報文內部的，用戶沒法直接看到。

　　總的來講，GET用於獲取某個內容，POST用於提交某種數據請求。

　　按照使用場景來講，通常用戶註冊的內容屬於私密的，這應該使用POST方式；而針對某一內容的查詢，爲了快速的響應，可使用GET方式。

　　

　　無狀態

　　因爲http是一種無狀態的協議，所以不管是客戶端仍是服務器都不記錄http的相關信息。

　　這樣設計一方面減輕了服務器端的負載，另外一方面減少了http請求的開銷。

　　可是針對某些特殊的場景，須要時刻記錄用戶的相關信息，這該如何處理呢?

　　Cookie剛好能夠解決這個問題,Cookie的運行機制以下：

　　Cookie是一種由服務器端肯定，並保存在客戶端瀏覽器中的內容。這樣，就不須要每次都添加用戶的相關信息，請求會自動添加cookie中對應的內容。

　　持久化

　　正常在發送http時，都須要創建TCP的鏈接，再發送報文。

　　若是每次想要發送http報文都須要通過這個過程，那麼時間大部分都會消耗在創建和斷開鏈接的過程當中。

　　所以http中使用了connection屬性，用於指定鏈接的方式。

　　當設置成keep-alive，如上面所示的www.baidu.com的http頭部信息所示，就會創建一條持久化的鏈接。

　　不須要每次都創建鏈接，再中斷。

　　管道化

　　若是一個http請求，請求了大量的圖片等大文件，那麼其餘的http請求怎麼辦呢？

　　不用怕，http能夠一次發送多個http請求，而後等待響應鏈接。不須要排隊等候，這樣就加快了http的響應時間。

　　內容編碼

　　因爲某些報文的內容過大，所以在傳輸時，爲了減小傳輸的時間，會採起一些壓縮的措施。

　　例如上面的報文信息中，Accept-Encoding就定義了內容編碼的格式：gzip

　　有下面幾種方式：

　　gzip：GNU壓縮格式

　　compress：UNIX系統的標準壓縮格式

　　deflate：是一種同時使用了LZ77和哈弗曼編碼的無損壓縮格式

　　identity：不進行壓縮

 

　　多部分對象集合

　　有的時候傳輸的內容，不只僅是一些字符串，還有多是一些圖片，字符，音樂二進制等混雜的內容。

　　這就須要使用多部分對象集合，multipart，例如在使用java編寫web上傳文件的代碼時，須要在form中指定form的編碼格式。

　　設置form的enctype屬性的值爲multipart/form-data。

　　這是由於默認的狀況下form使用的編碼格式是：applicatin/x-www-form-urlencoded，這種編碼格式會把全部的內容進行編碼，不適合上傳文件這種狀況。

　　這兩種編碼格式的區別主要是：

　　multipart/form-data 會以控件爲基準，編碼form中的內容。

　　application/x-www-form-urlencoded 會把form中的內容編碼成鍵值對的形式。

　　範圍請求

　　有些場景下，http報文請求一些很大的圖片，可是加載過程很慢。

　　好比咱們登陸一些大圖片的網址，會發現有時候圖片是一塊一塊加載的。

　　這就是由於設置了http請求的長度，這樣就能夠分塊的加載資源文件。

　　在請求報文中使用Range屬性，在響應報文中使用Content-Type屬性均可以指定必定字節範圍的http請求。

　　參考

　　[1] URL與URI的區別：http://www.cnblogs.com/gaojing/archive/2012/02/04/2413626.html

　　[2] POST與GET的區別：http://www.cnblogs.com/hyddd/archive/2009/03/31/1426026.html

　　[3] GET與POST的長度限制：http://blog.csdn.net/blueling51/article/details/6935901