http協議（三）幾種數據傳輸方式

說說http協議的一些特色：

1）無狀態

http協議是一種自身不對請求和響應之間的通訊狀態進行保存的協議，即無狀態協議。

這種設置的好處是：更快的處理更多的請求事務，確保協議的可伸縮性

不過隨着web的不斷髮展，有時候，須要將這種狀態進行保持，隨即，就引入了cookie技術，cookie技術經過在請求和響應報文中寫入cookie信息來控制客戶端的狀態。

有關cookie的內容後面咱們再說。。。

2）持久性

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

 

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

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

當設置成keep-alive，http就會創建一條持久化的鏈接，不須要每次都創建鏈接，再中斷。

這樣作的好處是：減輕了服務器端的負載，減小開銷的那部分時間，使http請求和響應都能更快的結束，相應的，web頁面顯示速度也就相對提高了。

3）管線化

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

如今，管線化技術的出現，使得http請求比持久性鏈接更要快；特色在於：請求數越多，時間差越明顯。

4）內容編碼

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

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

有下面幾種方式：

gzip：GNU壓縮格式

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

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

identity：不進行壓縮

5）多部分對象集合

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

這就須要使用多部分對象集合，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中的內容編碼成鍵值對的形式。

6）範圍請求

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

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

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

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

 

接下來，說說幾種http協議的數據傳輸方式

http協議的傳輸方式有不少種，處於安全考慮，經常使用的通常都是GET和POST兩種，先來介紹下這兩種

1）GET：獲取資源

GET方法用來請求訪問已被URL識別的資源

2）POST：傳輸實體主體

POST方法用來請求服務器傳輸信息實體的主體

GET和POST的區別：

首先，使用目標不一樣：GET方法只是用來查詢，不會對瀏覽器上的信息產生影響，每次GET的方法都是相同的

其次，大小不一樣：GET是放在URL首部，所以大小隨着瀏覽器而定，而POST則是在報文中，只要沒有具體限制，文件的大小是沒限制的

而後，安全性不一樣：GET採用的是明文傳輸，而POST是放在報文內部，沒法看到

從使用場景的角度來講，通常像用戶註冊登陸這種信息都是私密的，採用POST，而針對查詢等，爲了快速，大多采用GET傳輸。

（關於關於GET和POST的區別，最近從新看了不少別人寫的博客啊資料什麼的，發現上面的解釋比較模糊，我就在下面的評論區裏面將區別清晰的描述一下，固然，後面的博客也會詳細的解釋）

 

接下來介紹其餘幾種數據傳輸方式：

3）PUT：傳輸文件

PUT要求在請求報文的主體中包含文件內容，而後保存到請求URL指定的位置

處於安全考慮，通常web網站不使用此方法，若配合web的安全驗證機制，或者架構採用REST標準的網站，就可能開放使用此方法

4）HEAD：得到報文首部

HEAD和GET方法同樣，只不過不返回報文主體部分，用於確認URI的有效性及資源更新的日期時間等

5）DELETE：刪除文件

DELETE是與PUT相反的方法，是按請求URI刪除指定的資源

處於安全考慮，通常web網站不使用此方法，若配合web的安全驗證機制，或者架構採用REST標準的網站，就可能開放使用此方法

6）OPTIONS：詢問支持的方法

用來查詢針對請求URI指定的資源支持的方法

7）TRACE：追蹤路徑

是讓web服務器端將以前的請求通訊還回給客戶端的方法

發送請求時，在Max-Frowards首部字段中填入數值，每通過一個服務器端就-1，當數值爲0時，中止傳輸，最後收到服務器返回狀態碼200 OK的響應

可是，這種方法基本不多使用，並且很容易引發XST（跨站追蹤）攻擊，就更不會用到了。

8）CONNECT：要求採用隧道協議鏈接代理

該方法要求在於代理服務器通訊時創建隧道，實現用隧道協議進行TCP通訊，主要使用SSL（安全套接層）和TLS（傳輸層安全）協議把通訊內容加密後通過網絡傳輸。

 

最後，附上一張http1.1和http1.0版本各自支持的方法，另外，注意用大寫。。。。。。

其中，LINK和UNLINK已被HTTP1.1廢棄，再也不支持！