WEB必知必會--圖解Http(上),web必知
本篇總結關於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
作者:xingoo
Github:https://github.com/xinghalo
本文著作權歸作者和部落格園共有,歡迎轉載,但未經作者同意必須保留此段聲明,且在文章頁面明顯位置給出原文串連,否則保留追究法律責任的權利。 分類: JavaScript