2019獨(dú)角獸企業(yè)重金招聘Python工程師標(biāo)準(zhǔn)>>>

HTTP協(xié)議

HTTP協(xié)議作為網(wǎng)絡(luò)傳輸?shù)幕緟f(xié)議，有著廣泛的應(yīng)用。
HTTP協(xié)議的完整內(nèi)容很多，但是其核心知識卻又簡單精煉。
HTTP協(xié)議：消息的分類 請求消息 響應(yīng)消息
HTTP特點：無連接，無連接的含義是限制每次連接只處理一個請求，服務(wù)器處理完客戶的請求，并收到客戶的應(yīng)答后，即斷開連接，采用這種方式可以節(jié)省傳輸時間 。

無狀態(tài): 指協(xié)議對于事務(wù)處理沒有記憶能力。

缺少狀態(tài)意味著如果后續(xù)處理需要前面的信息，則它必須重傳，這樣可能導(dǎo)致每次連接傳送的數(shù)據(jù)量增大。

另一方面，在服務(wù)器不需要先前信息時它的應(yīng)答就較快。
HTTP協(xié)議消息的基本格式：

• 首行
• 頭部(header)
• 正文(body)

頭部

用來指出HTTP消息的一些屬性，它們有固定的格式；

正文

部分是傳輸?shù)膶嶋H內(nèi)容，它們的格式是任意的，通常用Content-Type頭來指定。

首行

在請求消息和響應(yīng)消息中具體格式略有區(qū)別，它們表示的按理說應(yīng)該是HTTP消息最基本的部分。
不論是HTTP請求還是HTTP響應(yīng)，首行都是有的，否則會出現(xiàn)不可饒恕的解析錯誤；
然而頭部和正文是可選的，不過實際過程中，多多少少都要包含一些基本的頭。 首行和頭部都是以進(jìn)行ASCII編碼，正文部分的編碼任意了。
在實際的開發(fā)中，發(fā)送的文本消息時常會碰到亂碼的問題。
通常約定以UTF-8格式進(jìn)行編碼和解碼， HTTP消息是基于TCP協(xié)議的上層應(yīng)用協(xié)議。
TCP協(xié)議是網(wǎng)絡(luò)流協(xié)議的一種。
抽象地講，就是從一臺主機(jī)一個字節(jié)一個字節(jié)有序地傳輸?shù)搅硪慌_主機(jī)。對于HTTP協(xié)議來說，自然保持了這種有序性，即按照首行、頭部、正文的順序進(jìn)行傳輸。
首行和頭部都是ASCII文本流，正文部分是字節(jié)流。一個特殊的控制結(jié)構(gòu)CRLF用來控制每個部分的結(jié)束。
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 — ——- 空白行表示頭部的結(jié)束

接下來的內(nèi)容是正文部分 可以清楚地看到，第一行是首行，以CRLF標(biāo)志其結(jié)束；

接下來是頭部，含有多個消息頭，每行定義一個消息頭，以CRLF標(biāo)志其結(jié)束；

一個單獨(dú)的CRLF（緊接著上一個CRLF）表示整個頭部的結(jié)束，接下來是正文部分。

在這個示例中，正文部分為空 它們在消息實體中是連續(xù)的片段，并不像代碼中所示那樣有換行的結(jié)構(gòu)。

換句話說，原始的消息應(yīng)該是如下形式：

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請求 之前已經(jīng)說過。

三個部份

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

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

其中請求頭部的格式我們已經(jīng)見過。

• 請求行的基本格式為：
• 方法
• 路徑
• 版本
• 例如下面的例子： GET /simple.html HTTP/1.1
• 就有對應(yīng)關(guān)系：
• 方法：GET
• 路徑：/simple.html
• 版本：HTTP/1.1

Http請求方法

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

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

比如說GET方法請求的資源，瀏覽器端一般都會有緩存，下次請求的時候可能從緩存中去取就夠了，服務(wù)器不用再重復(fù)發(fā)送相同的資源了；

但是服務(wù)器如果將獲取資源的接口的方法定義為POST，那么瀏覽器端就不會再對資源進(jìn)行緩存了，即使每次取到的都是同樣地內(nèi)容，都會請求服務(wù)器重新發(fā)送一遍。

所以說，將請求資源的接口的方法定義為POST而不是GET，就是一種不合理的設(shè)計。

再比如，GET方法的請求消息是不能定義消息體的，HEAD方法的請求其響應(yīng)消息是不包含消息體的。

這些都是HTTP協(xié)議對于HTTP方法的約束。

query-string

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

它的格式是任意的，只要客戶端和服務(wù)器約定好一定的形式即可。這個部分一般是請求參數(shù)的附加。

之前說過，GET方法是不包含請求體的，所以GET方法的HTTP請求想要附加參數(shù)只能使用這種方式。

當(dāng)然其他方法也是可以使用這種方式附加參數(shù)，只要服務(wù)器同意就可以了。query-string的格式任意，但在客戶端和服務(wù)器之間也有預(yù)先定好的約定，即鍵值對的形式。

query-string可以表示成一系列鍵值對的集合，用以下方式表示： k1=v1&k2=v2&k3=&k4 在這里。

&分隔不同的鍵值對，=表示鍵和值得關(guān)系，可以看到一共有四個鍵值對關(guān)系，它們是： k1: v1 k2: v2 k3: 空字符串k4: 起碼該鍵被定義了 一般來說，鍵值對要寫成k=v的形式，但是k=和僅僅一個k都是允許的，前者表示鍵k的值是空字符串，后者表示鍵k被定義了，但是其值是什么并不關(guān)心。

HTTP請求頭 HTTP請求頭格式與之前所說的消息頭格式?jīng)]什么兩樣，就是以冒號分隔的鍵值對。HTTP請求頭中，既包含預(yù)定義的頭（如Content-Type、Content-Length等），也支持自定義頭。

==Content-Type==頭

既可用于請求消息，也可用于響應(yīng)消息，是規(guī)定請求正文內(nèi)容格式的頭部。例如利用這個頭部，我們可以規(guī)定正文的格式為純文本格式、表單格式、XML格式、JSON格式、圖像格式等。

例如==Content-Type:application/json==就表示JSON文本格式。 http消息頭大全 HTTP響應(yīng) HTTP響應(yīng)消息的基本格式也是一樣的。

包含三個部分：
響應(yīng)行
響應(yīng)頭部
響應(yīng)正文

響應(yīng)行

響應(yīng)行的基本格式是：
版本號
狀態(tài)碼
狀態(tài)文本
例如下面的響應(yīng)行： HTTP/1.1 200 OK
其對應(yīng)關(guān)系為： 版本號：HTTP/1.1
狀態(tài)碼：200 狀態(tài)文本：OK

轉(zhuǎn)載于:https://my.oschina.net/zyt1978/blog/757910

《新程序員》：云原生和全面數(shù)字化實踐50位技術(shù)專家共同創(chuàng)作，文字、視頻、音頻交互閱讀

總結(jié)

以上是生活随笔為你收集整理的HTTP协议基础知识点点滴滴的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。