Http協議基礎知識的點點滴滴
HTTP協議作為網路傳輸的基本協議,有著廣泛的應用。HTTP協議的完整內容很多,但是其核心知識卻又簡單精煉。
HTTP協議:訊息的分類
· 請求訊息
· 響應訊息
HTTP協議:特點
· 無連線:無連線的含義是限制每次連線只處理一個請求。伺服器處理完客戶的請求,並收到客戶的應答後,即斷開連線。採用這種方式可以節省傳輸時間
· 無狀態:指協議對於事務處理沒有記憶能力。缺少狀態意味著如果後續處理需要前面的資訊,則它必須重傳,這樣可能導致每次連線傳送的資料量增大。另一方面,在伺服器不需要先前資訊時它的應答就較快。
HTTP協議:訊息的基本格式
· 首行
· 頭部(header)
· 正文(body)
==頭部==用來指出HTTP訊息的一些屬性,它們有固定的格式;==正文==部分是傳輸的實際內容,它們的格式是任意的,通常用Content-Type頭來指定。==首行==在請求訊息和響應訊息中具體格式略有區別,它們表示的按理說應該是HTTP訊息最基本的部分。不論是HTTP請求還是HTTP響應,首行都是有的,否則會出現不可饒恕的解析錯誤;然而頭部和正文是可選的,不過實際過程中,多多少少都要包含一些基本的頭。
首行和頭部都是以==ASCII==編碼,正文部分的編碼任意了。在實際的開發中,傳送的文字訊息時常會碰到亂碼的問題。通常約定以UTF-8格式進行編碼和解碼。
HTTP訊息是基於TCP協議的上層應用協議。TCP協議是網路流協議的一種。抽象地講,就是從一臺主機一個位元組一個位元組有序地傳輸到另一臺主機。對於HTTP協議來說,自然保持了這種有序性,即按照首行、頭部、正文的順序進行傳輸。首行和頭部都是ASCII文字流,正文部分是位元組流。一個特殊的控制結構CRLF用來控制每個部分的結束。
CRLF是回車符和換行符的意思,它們是兩個特殊的ASCII字元。CR是回車符(\r),在ASCII中的編碼是13;LF是換行符(\n),在ASCII中的編碼是10.
http請求報文示例:
GET /simple.html HTTP/1.1CRLF ----- 首行
Accept: text/htmlCRLF --
Accept-Language: zh-cnCRLF
Accept-Encoding: gzip, deflateCRLF -- 頭部
User-Agent: Mozilla/4.0CRLF
Host: localhost:8080CRLF
Connection: Keep-AliveCRLF --
CRLF ----- 空白行表示頭部的結束
----- 接下來的內容是正文部分
可以清楚地看到,第一行是首行,以CRLF標誌其結束;接下來是頭部,含有多個訊息頭,每行定義一個訊息頭,以CRLF標誌其結束;一個單獨的CRLF(緊接著上一個CRLF)表示整個頭部的結束,接下來是正文部分。在這個示例中,正文部分為空
它們在訊息實體中是連續的片段,並不像程式碼中所示那樣有換行的結構。換句話說,原始的訊息應該是如下形式:
GET /simple.html HTTP/1.1Accept: text/htmlAccept-Language: zh-cnAccept-Encoding: gzip, deflateUser-Agent: Mozilla/4.0Host: localhost:8080Connection: Keep-Alive
HTTP請求
之前已經說過,HTTP請求訊息分為三個部分:
· 請求行
· 請求頭部
· 請求正文
其中請求頭部的格式我們已經見過。請求行的基本格式為:
方法 路徑 版本
例如下面的例子:
GET /simple.html HTTP/1.1
就有對應關係:
· 方法:GET
· 路徑:/simple.html
· 版本:HTTP/1.1
HTTP請求:方法
首先列出最常用的HTTP方法:
· GET
· POST
· PUT
· PATCH
· DELETE
· HEAD
· OPTIONS
每個HTTP方法,都是有一些HTTP協議要求的。比如說GET方法請求的資源,瀏覽器端一般都會有快取,下次請求的時候可能從快取中去取就夠了,伺服器不用再重複傳送相同的資源了;但是伺服器如果將獲取資源的介面的方法定義為POST,那麼瀏覽器端就不會再對資源進行快取了,即使每次取到的都是同樣地內容,都會請求伺服器重新發送一遍。所以說,將請求資源的介面的方法定義為POST而不是GET,就是一種不合理的設計。
再比如,GET方法的請求訊息是不能定義訊息體的,HEAD方法的請求其響應訊息是不包含訊息體的,這些都是HTTP協議對於HTTP方法的約束
HTTP請求:路徑
路徑的基本格式一般是:
basic-path[?query-string]
問號後面的部分就是query-string。它的格式是任意的,只要客戶端和伺服器約定好一定的形式即可。這個部分一般是請求引數的附加。之前說過,GET方法是不包含請求體的,所以GET方法的HTTP請求想要附加引數只能使用這種方式。當然其他方法也是可以使用這種方式附加引數,只要伺服器同意就可以了。query-string的格式任意,但在客戶端和伺服器之間也有預先定好的約定,即鍵值對的形式。query-string可以表示成一系列鍵值對的集合,用以下方式表示:
k1=v1k2=v2k3=k4
在這裡,分隔不同的鍵值對,=表示鍵和值得關係。可以看到一共有四個鍵值對關係,它們是:
· k1: v1
· k2: v2
· k3: 空字串
· k4: 起碼該鍵被定義了
一般來說,鍵值對要寫成k=v的形式,但是k=和僅僅一個k都是允許的,前者表示鍵k的值是空字串,後者表示鍵k被定義了,但是其值是什麼並不關心。
HTTP請求頭
HTTP請求頭格式與之前所說的訊息頭格式沒什麼兩樣,就是以冒號分隔的鍵值對。HTTP請求頭中,既包含預定義的頭(如Content-Type、Content-Length等),也支援自定義頭。
==Content-Type==頭,既可用於請求訊息,也可用於響應訊息,是規定請求正文內容格式的頭部。例如利用這個頭部,我們可以規定正文的格式為純文字格式、表單格式、XML格式、JSON格式、影象格式等。例如==Content-Type:application/json==就表示JSON文字格式。
http訊息頭大全
HTTP響應
HTTP響應訊息的基本格式也是一樣的,包含三個部分:
· 響應行
· 響應頭部
· 響應正文
響應行的基本格式是:
版本號 狀態碼 狀態文字
例如下面的響應行:
HTTP/1.1 200 OK
其對應關係為:
· 版本號:HTTP/1.1
· 狀態碼:200
· 狀態文字:OK