一、概述

本文的內(nèi)容源自其他博客的總結(jié)，結(jié)構(gòu)如下：

HTTP 的請求報文

GET 方法的特點(diǎn)

POST 方法的特點(diǎn)

GET 和 POST 的區(qū)別

二、HTTP 的請求報文

首先我們要解決的第一個問題是：GET 和 POST 是什么？

GET 和 POST 其實(shí)都是 HTTP 的請求方法。除了這 2 個請求方法之外，HTTP 還有 HEAD、PUT、DELETE、TRACE、CONNECT、OPTIONS 這 6 個請求方法。所以HTTP 的請求方法共計(jì)有 8 種，它們的描述如下所示：

接下來我們解決第二個問題：請求方法如何使用？

要解決這個問題，我們首先需要了解 HTTP 的請求報文結(jié)構(gòu)：

可以看到 HTTP 的請求報文由三部分構(gòu)成：

請求行：由請求方法（Method）、URL 字段和 HTTP 的協(xié)議版本組成，注意其中的空格、回車符和換行符均不可省略，所以我們的請求方法實(shí)際上就是位于請求行中的了。

請求頭部：位于請求行之后，個數(shù)可以為 0~若干個，每個請求頭部都包含一個頭部字段名和一個值，它們之間用冒號 ":" 分隔，在最后用回車符和換行符表示結(jié)束。

請求數(shù)據(jù)：如果請求方法為 GET，那么請求數(shù)據(jù)為空。它主要是在 POST 中進(jìn)行使用，適用于需要填表單（FORM）的場景。

我們通過一個實(shí)際的例子來看看 HTTP 的 GET 請求報文是什么樣的，我們這里以訪問 https://api.github.com/search/users?q=JakeWharton 為例，通過抓包我們得到的請求報文如下所示：

GET /search/users?q=JakeWharton HTTP/1.1
Host: api.github.com
Connection: keep-alive
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.86 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9
Cookie: _octo=GH1.1.1623908978.1549006668; _ga=GA1.2.548087391.1549006688; logged_in=yes; dotcom_user=GoMarck; _gid=GA1.2.17634150.1554639136; _gat=1

我們重點(diǎn)看到請求行：

GET /search/users?q=JakeWharton HTTP/1.1

可以看到請求方法用的是 GET 請求，URL為 /search/users?q=JakeWharton，協(xié)議為 HTTP1.1。

請求行下面部分全都是請求頭部，我們可以看到 host 為 api.github.com，連接方式為長連接等信息。值得注意的是我們這個例子中是不存在請求數(shù)據(jù)的。

接下來我們在來看一下 POST 請求的報文（該例子源自其他博客）：

POST / HTTP/1.1
Host: www.wrox.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6)
Gecko/20050225 Firefox/1.0.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 40
Connection: Keep-Alive


name=Professional%20Ajax&publisher=Wiley

可以看到請求行中請求方法為 POST，URL 為空，協(xié)議版本也是 HTTP1.1。它和上面 GET 方法例子不一樣的地方在于它的請求參數(shù)是位于請求數(shù)據(jù)中的，可以看到 name=Professional%20Ajax&publisher=Wiley 就是它的請求數(shù)據(jù)。并且我們要注意到在請求數(shù)據(jù)和請求頭之間是空出一行的，這是必不可少的。

三、GET 方法的特點(diǎn)

1、前面的例子：
https://api.github.com/search/users?q=JakeWharton 就是一個非常典型的 GET 請求的表現(xiàn)形式，即請求的數(shù)據(jù)會附在 URL 之后（放在請求行中），以 ? 分割 URL 和傳輸數(shù)據(jù)，多個參數(shù)用 & 連接。

2、除此之外，根據(jù) HTTP 規(guī)范，GET 用于信息獲取，而且應(yīng)該是安全和冪等的 。

安全性指的是非修改信息，即該操作用于獲取信息而非修改信息。換句話說，GET請求一般不應(yīng)產(chǎn)生副作用，也就是說，它僅僅是獲取資源信息，就像數(shù)據(jù)庫查詢一樣，不會修改，增加數(shù)據(jù)，不會影響資源的狀態(tài)。

冪等性 (Idempotence) 則指的是無論調(diào)用這個URL 多少次，都不會有不同的結(jié)果的 HTTP 方法。而在實(shí)際過程中，這個規(guī)定沒有那么嚴(yán)格。例如在一個新聞應(yīng)用中，新聞?wù)军c(diǎn)的頭版不斷更新，雖然第二次請求會返回不同的一批新聞，該操作仍然被認(rèn)為是安全的和冪等的，因?yàn)樗偸欠祷禺?dāng)前的新聞。

3、GET 是會被瀏覽器主動緩存的，如果下一次傳輸?shù)臄?shù)據(jù)相同，那么就會返回緩存中的內(nèi)容，以求更快地展示數(shù)據(jù)。

4、GET 方法的 URL 一般都具有長度限制，但是需要注意的是 HTTP 協(xié)議中并未規(guī)定 GET 請求的長度。這個長度限制主要是由瀏覽器和 Web 服務(wù)器所決定的，并且各個瀏覽器對長度的限制也各不相同。

5、GET 方法只產(chǎn)生一個 TCP 數(shù)據(jù)包，瀏覽器會把請求頭和請求數(shù)據(jù)一并發(fā)送出去，服務(wù)器響應(yīng) 200 ok(返回?cái)?shù)據(jù))。

四、POST 方法的特點(diǎn)

根據(jù) HTTP 規(guī)范，POST 表示可能修改變服務(wù)器上的資源的請求。例如我們在刷知乎的時候?qū)δ称恼逻M(jìn)行點(diǎn)贊，就是提交的 POST 請求，因?yàn)樗淖兞朔?wù)器中的數(shù)據(jù)（該篇文章的點(diǎn)贊數(shù)）。

POST 方法因?yàn)橛锌赡苄薷姆?wù)器上的資源，所以它是不符合安全和冪等性的。

從前面關(guān)于 POST 的請求報文也可以看出，POST 是將請求信息放置在請求數(shù)據(jù)中的，這也是 POST 和 GET 的一點(diǎn)不那么重要的區(qū)別。有一些博客的說法是 GET 請求的請求信息是放置在 URL 的而 POST 是放置在請求數(shù)據(jù)中的所以 POST 比 GET 更安全。其實(shí)這種說法很有問題，隨便抓下包 POST 中的請求報文就暴露無疑了，這又何來安全之說？

因?yàn)?POST 方法的請求信息是放置在請求數(shù)據(jù)中的，所以它的請求信息是沒有長度限制的。

POST 方法會產(chǎn)生兩個 TCP 數(shù)據(jù)包，瀏覽器會先將請求頭發(fā)送給服務(wù)器，待服務(wù)器響應(yīng)100 continue，瀏覽器再發(fā)送請求數(shù)據(jù)，服務(wù)器響應(yīng)200 ok(返回?cái)?shù)據(jù))。這么看起來 GET 請求的傳輸會比 POST 快上一些（因?yàn)镚ET 方法只發(fā)送一個 TCP 數(shù)據(jù)包），但是實(shí)際上在網(wǎng)絡(luò)良好的情況下它們的傳輸速度基本相同。

五、GET 和 POST 的區(qū)別

上面說了那么多 GET 方法和 POST 方法各自的特點(diǎn)，它們在外在的表現(xiàn)上似乎是有著諸多的不同，但是實(shí)際上，它們的本質(zhì)是一樣的，并無區(qū)別！！！

這似乎有些不可思議，但是我們重新回想一下 GET 和 POST 是什么？它們是 HTTP 請求協(xié)議的請求方法，而 HTTP 又是基于TCP/IP的關(guān)于數(shù)據(jù)如何在萬維網(wǎng)中如何通信的協(xié)議，所以 GET/POST 實(shí)際上都是 TCP 鏈接。

也就是說，GET 和 POST 所做的事其實(shí)是一樣的，如果你給 GET 加上請求數(shù)據(jù)，給 POST 加上 URL 參數(shù)，這在技術(shù)上是完全可行的，事實(shí)上確實(shí)有一些人為了貪圖方便在更新資源時用了GET，因?yàn)橛肞OST必須要到FORM（表單），這樣會麻煩一點(diǎn)（但是強(qiáng)烈不建議這樣子做！！！）。

既然 GET 和 POST 的底層都是 TCP，那么為什么 HTTP 還要特別將它們區(qū)分出來呢？

其實(shí)可以想象一下，如果我們直接使用 TCP 進(jìn)行數(shù)據(jù)的傳輸，那么無論是單純獲取資源的請求還是修改服務(wù)器資源的請求在外觀上看起來都是 TCP 鏈接，這樣就非常不利于進(jìn)行管理。所以在 HTTP 協(xié)議中，就會對這些不同的請求設(shè)置不同的類別進(jìn)行管理，例如單純獲取資源的請求就規(guī)定為 GET、修改服務(wù)器資源的請求就規(guī)定為 POST，并且也對它們的請求報文的格式做出了相應(yīng)的要求（例如請求參數(shù) GET 位于 URL 而 POST 則位于請求數(shù)據(jù)中）。

當(dāng)然，如果我們想將 GET 的請求參數(shù)放置在請求數(shù)據(jù)中或者將 POST 的請求數(shù)據(jù)放置在 URL 中，這是完全可以的，雖然這樣子做并不符合 HTTP 的規(guī)范。但是這樣子做是否能得到我們期望的響應(yīng)數(shù)據(jù)呢？答案是未必，這取決于服務(wù)器的行為。

以 GET 方法在請求數(shù)據(jù)中放置請求參數(shù)為例，有些服務(wù)器會將請求數(shù)據(jù)中的參數(shù)讀出，在這種情況下我們依然能獲得我們期望的響應(yīng)數(shù)據(jù)；而有些服務(wù)器則會選擇直接忽略，這種情況下我們就無法獲取期望的響應(yīng)數(shù)據(jù)了。

所以，對于 GET 和 POST 的區(qū)別，總結(jié)來說就是：它們的本質(zhì)都是 TCP 鏈接，并無區(qū)別。但是由于 HTTP 的規(guī)定以及瀏覽器/服務(wù)器的限制，導(dǎo)致它們在應(yīng)用過程中可能會有所不同。

編輯：黃飛

?