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