HTTP協議基礎知識點點滴滴

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.1 ——- 首行
Accept: text/html — Accept-Language: zh-cn Accept-Encoding: gzip, deflate — 頭部
User-Agent: Mozilla/4.0 Host: localhost:8080 Connection: Keep-Alive — ——- 空白行表示頭部的結束

接下來的內容是正文部分 能夠清楚地看到，第一行是首行，以CRLF標誌其結束；

接下來是頭部，含有多個消息頭，每行定義一個消息頭，以CRLF標誌其結束；

一個單獨的CRLF（緊接着上一個CRLF）表示整個頭部的結束，接下來是正文部分。

在這個示例中，正文部分爲空 它們在消息實體中是連續的片斷，並不像代碼中所示那樣有換行的結構。

換句話說，原始的消息應該是以下形式：

GET /simple.html HTTP/1.1
Accept: text/html
Accept-Language: zh-cn
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0
Host: localhost:8080
Connection: Keep-Alive

HTTP請求 以前已經說過。

三個部份

HTTP請求消息分爲三個部分：

• 請求行
• 請求頭部
• 請求正文

其中請求頭部的格式咱們已經見過。

• 請求行的基本格式爲：
• 方法
• 路徑
• 版本
• 例以下面的例子： GET /simple.html HTTP/1.1
• 就有對應關係：
• 方法：GET
• 路徑：/simple.html
• 版本：HTTP/1.1

Http請求方法

HTTP請求：方法 首先列出最經常使用的
HTTP方法： GET POST PUT PATCH DELETE HEAD OPTIONS

每一個HTTP方法，都是有一些HTTP協議要求的。

好比說GET方法請求的資源，瀏覽器端通常都會有緩存，下次請求的時候可能從緩存中去取就夠了，服務器不用再重複發送相同的資源了；

可是服務器若是將獲取資源的接口的方法定義爲POST，那麼瀏覽器端就不會再對資源進行緩存了，即便每次取到的都是一樣地內容，都會請求服務器從新發送一遍。

因此說，將請求資源的接口的方法定義爲POST而不是GET，就是一種不合理的設計。

再好比，GET方法的請求消息是不能定義消息體的，HEAD方法的請求其響應消息是不包含消息體的。

這些都是HTTP協議對於HTTP方法的約束。

query-string

HTTP請求：路徑 路徑的基本格式通常是： basic-path[?query-string] 問號後面的部分就是query-string。

它的格式是任意的，只要客戶端和服務器約定好必定的形式便可。這個部分通常是請求參數的附加。

以前說過，GET方法是不包含請求體的，因此GET方法的HTTP請求想要附加參數只能使用這種方式。

固然其餘方法也是可使用這種方式附加參數，只要服務器贊成就能夠了。query-string的格式任意，但在客戶端和服務器之間也有預先定好的約定，即鍵值對的形式。

query-string能夠表示成一系列鍵值對的集合，用如下方式表示： k1=v1&k2=v2&k3=&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