（一）、不完全正確的網(wǎng)紅答案

1. GET的URL會(huì)有長(zhǎng)度上的限制，則POST的數(shù)據(jù)則可以非常大。

2. POST比GET安全，ET請(qǐng)求的數(shù)據(jù)會(huì)附在URL之后，POST把提交的數(shù)據(jù)則放置在是HTTP包的包體中。

（二）、為什么是不完全正確的答案

1. HTTP協(xié)議對(duì)GET和POST都沒(méi)有對(duì)長(zhǎng)度的限制：HTTP協(xié)議沒(méi)有對(duì)傳輸?shù)臄?shù)據(jù)大小進(jìn)行限制，HTTP協(xié)議規(guī)范也沒(méi)有對(duì)URL長(zhǎng)度進(jìn)行限制。
   而在實(shí)際開(kāi)發(fā)中存在的限制主要有：
   GET:特定瀏覽器和服務(wù)器對(duì)URL長(zhǎng)度有限制，例如 IE對(duì)URL長(zhǎng)度的限制是2083字節(jié)(2K+35)。對(duì)于其他瀏覽器，如Netscape、FireFox等，理論上沒(méi)有長(zhǎng)度限制，其限制取決于操作系 統(tǒng)的支持。因此對(duì)于GET提交時(shí)，傳輸數(shù)據(jù)就會(huì)受到URL長(zhǎng)度的 限制。
   POST:由于不是通過(guò)URL傳值，理論上數(shù)據(jù)不受 限。但實(shí)際各個(gè)WEB服務(wù)器會(huì)規(guī)定對(duì)post提交數(shù)據(jù)大小進(jìn)行限制，Apache、IIS6都有各自的配置。

2. 安全性意義不同：通過(guò)GET提交數(shù)據(jù)，用戶名和密碼將明文出現(xiàn)在URL上，因?yàn)榈卿涰?yè)面有可能被瀏覽器緩存，其他人查看瀏覽器的歷史紀(jì)錄，那么別人就可以拿到你的賬號(hào)和密碼了。post一般來(lái)說(shuō)都不會(huì)被緩存，但有很多抓包工具也是可以窺探到你的數(shù)據(jù)，真的要安全那就要把傳輸?shù)男畔⒓用堋５@不是HTTP協(xié)議對(duì)get和post做的的安全性區(qū)別，是瀏覽器使用的具體表現(xiàn)出來(lái)的。get在HTPP協(xié)議中用于獲取數(shù)據(jù)，post在在HTTP協(xié)議中用于修改數(shù)據(jù)。

（三）、在HTTP中g(shù)et和post的原理區(qū)別

Http定義了與服務(wù)器交互的不同方法，最基本的方法有4種，分別是GET，POST，PUT，DELETE
URL全稱是資源描述符，我們可以這樣認(rèn)為：一個(gè)URL地址，它用于描述一個(gè)網(wǎng)絡(luò)上的資源，而HTTP中的GET，POST，PUT，DELETE就對(duì)應(yīng)著對(duì)這個(gè)資源的查 ，改 ，增 ，刪 4個(gè)操作。到這里，大家應(yīng)該有個(gè)大概的了解了，GET一般用于獲取/查詢資源信息，而POST一般用于更新資源信息

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

1. 所謂安全的意味著該操作用于獲取信息而非修改信息。換句話說(shuō)，GET請(qǐng)求一般不應(yīng)產(chǎn)生副作用。就是說(shuō)，它僅僅是獲取資源信息，就像數(shù)據(jù)庫(kù)查詢一樣，不會(huì)修改，增加數(shù)據(jù)，不會(huì)影響資源的狀態(tài)。
   注意：這里安全的含義僅僅是指是非修改信息。

2. 冪等的意味著對(duì)同一URL的多個(gè)請(qǐng)求應(yīng)該返回同樣的結(jié)果。冪等（idempotent、idempotence）是一個(gè)數(shù)學(xué)或計(jì)算機(jī)學(xué)概念，常見(jiàn)于抽象代數(shù)中。
   冪等有以下幾種定義：
   對(duì)于單目運(yùn)算，如果一個(gè)運(yùn)算對(duì)于在范圍內(nèi)的所有的一個(gè)數(shù)多次進(jìn)行該運(yùn)算所得的結(jié)果和進(jìn)行一次該運(yùn)算所得的結(jié)果是一樣的，那么我們就稱該運(yùn)算是冪等的。 比如絕對(duì)值運(yùn)算就是一個(gè)例子，在實(shí)數(shù)集中，有abs(a) = abs(abs(a)) 。
   對(duì)于雙目運(yùn)算，則要求當(dāng)參與運(yùn)算的兩個(gè)值是等值的情況下，如果滿足運(yùn)算結(jié)果與參與運(yùn)算的兩個(gè)值相等，則稱該運(yùn)算冪等，如求兩個(gè)數(shù)的最大值的函數(shù)，有在實(shí)數(shù)集中冪等，即max(x,x) = x 。看完上述解釋后，應(yīng)該可以理解GET冪等的含義了。

• 但在實(shí)際應(yīng)用中，以上2條規(guī)定并沒(méi)有這么嚴(yán)格。引用別人文章的例子：比如，新聞?wù)军c(diǎn)的頭版不斷更新。雖然第二次請(qǐng)求會(huì)返回不同的一批新聞，該操作仍然被認(rèn)為是安全的和冪等的，因?yàn)樗偸欠祷禺?dāng)前的新聞。從根本上說(shuō)，如果目標(biāo)是當(dāng)用戶打開(kāi)一個(gè)鏈接時(shí)，他可以確信從自身的角度來(lái)看沒(méi)有改變資源即可。

• 根據(jù)HTTP規(guī)范，POST表示可能修改變服務(wù)器上的資源的請(qǐng)求。繼續(xù)引用上面的例子：還是新聞以網(wǎng)站為例，讀者對(duì)新聞發(fā)表自己的評(píng)論應(yīng)該通過(guò)POST實(shí)現(xiàn)，因?yàn)樵谠u(píng)論提交后站點(diǎn)的資源已經(jīng)不同了，或者說(shuō)資源被修改了。

上面大概說(shuō)了一下HTTP規(guī)范中，GET和POST的一些原理性的問(wèn)題。但在實(shí)際的做的時(shí)候，很多人卻沒(méi)有按照HTTP規(guī)范去做，導(dǎo)致這個(gè)問(wèn)題的原因有很多，比如說(shuō)：

1. 很多人貪方便，更新資源時(shí)用了GET，因?yàn)橛肞OST必須要到FORM（表單），這樣會(huì)麻煩一點(diǎn)。

2. 對(duì)資源的增，刪，改，查操作，其實(shí)都可以通過(guò)GET/POST完成，不需要用到PUT和DELETE。

3. 另外一個(gè)是，早期的但是Web MVC框架設(shè)計(jì)者們并沒(méi)有有意識(shí)地將URL當(dāng)作抽象的資源來(lái)看待和設(shè)計(jì)。還有一個(gè)較為嚴(yán)重的問(wèn)題是傳統(tǒng)的Web MVC框架基本上都只支持GET和POST兩種HTTP方法，而不支持PUT和DELETE方法。

（四）、既然post有這么多優(yōu)點(diǎn)，那我們?yōu)槭裁匆褂胓et？

答案就是：因?yàn)間et比post更快。

（一）、post請(qǐng)求的過(guò)程，會(huì)先將請(qǐng)求頭發(fā)送給服務(wù)器進(jìn)行確認(rèn)，然后才真正發(fā)送數(shù)據(jù)；而get請(qǐng)求的過(guò)程，會(huì)在連接建立后會(huì)將請(qǐng)求頭和請(qǐng)求數(shù)據(jù)一起發(fā)送。

post請(qǐng)求的過(guò)程

1. 瀏覽器請(qǐng)求tcp連接（第一次握手）
2. 服務(wù)器答應(yīng)進(jìn)行tcp連接（第二次握手）
3. 瀏覽器確認(rèn)，并發(fā)送post請(qǐng)求頭（第三次握手，這個(gè)報(bào)文比較小，所以http會(huì)在此時(shí)進(jìn)行第一次數(shù)據(jù)發(fā)送）
4. 服務(wù)器返回100 continue響應(yīng)
5. 瀏覽器開(kāi)始發(fā)送數(shù)據(jù)
6. 服務(wù)器返回200 ok響應(yīng)

get請(qǐng)求的過(guò)程

1. 瀏覽器請(qǐng)求tcp連接（第一次握手）
2. 服務(wù)器答應(yīng)進(jìn)行tcp連接（第二次握手）
3. 瀏覽器確認(rèn)，并發(fā)送get請(qǐng)求頭和數(shù)據(jù)（第三次握手，這個(gè)報(bào)文比較小，所以http會(huì)在此時(shí)進(jìn)行第一次數(shù)據(jù)發(fā)送）
4. 服務(wù)器返回200 ok響應(yīng)

也就是說(shuō)，目測(cè)get的總耗是post的2/3左右

（二）、get會(huì)將數(shù)據(jù)緩存起來(lái)，而post不會(huì)

• 可以做個(gè)簡(jiǎn)短的測(cè)試，使用ajax采用get方式請(qǐng)求靜態(tài)數(shù)據(jù)（比如html頁(yè)面，圖片）的時(shí)候，如果兩次傳輸?shù)臄?shù)據(jù)相同，第二次以后耗費(fèi)的時(shí)間將在10ms以內(nèi)（chrome測(cè)試），而post每次耗費(fèi)的時(shí)間都差不多。經(jīng)測(cè)試，chrome下和firefox下如果檢測(cè)到get請(qǐng)求的是靜態(tài)資源，則會(huì)緩存，如果是數(shù)據(jù)，則不緩存，但是IE這個(gè)傻X啥都會(huì)緩存起來(lái)

（三）、post不能進(jìn)行管道化傳輸

• http在的一次會(huì)話需要先建立tcp連接然后才能通信，如果每次連接都只進(jìn)行一次http會(huì)話，那這個(gè)連接過(guò)程占的比例太大了！

• 于是出現(xiàn)了持久連接：在http/1.0+中是connection首部中添加keep-alive值，在http/1.1中是在connection首部中添加persistent值，當(dāng)然兩者不僅僅是命名上的差別，http/1.1中，持久連接是默認(rèn)的，除非顯示在connection中添加close，否則持久連接不會(huì)關(guān)閉，而http/1.0+中則恰好相反，除非顯示在connection首部中添加keep-alive，否則在接收數(shù)據(jù)包后連接就斷開(kāi)了。

• 出現(xiàn)了持久連接還不夠，在http/1.1中，還有一種稱為管道通信的方式進(jìn)行速度優(yōu)化：把需要發(fā)送到服務(wù)器上的所有請(qǐng)求放到輸出隊(duì)列中，在第一個(gè)請(qǐng)求發(fā)送出去后，不等到收到服務(wù)器的應(yīng)答，第二個(gè)請(qǐng)求緊接著就發(fā)送出去，但是這樣的方式有一個(gè)問(wèn)題：不安全，如果一個(gè)管道中有10個(gè)連接，在發(fā)送出9個(gè)后，突然服務(wù)器告訴你，連接關(guān)閉了，此時(shí)客戶端即使收到了前9個(gè)請(qǐng)求的答復(fù)，也會(huì)將這9個(gè)請(qǐng)求的內(nèi)容清空，也就是說(shuō)，白忙活了……此時(shí)，客戶端的這9個(gè)請(qǐng)求需要重新發(fā)送。這對(duì)于冪等請(qǐng)求還好（比如get，多發(fā)送幾次都沒(méi)關(guān)系，每次都是相同的結(jié)果），如果是post這樣的非冪等請(qǐng)求（比如支付的時(shí)候，多發(fā)送幾次就慘了），肯定是行不通的。所以，post請(qǐng)求不能通過(guò)管道的方式進(jìn)行通信！

*管道化傳輸在瀏覽器端的實(shí)現(xiàn)還需考證，貌似默認(rèn)情況下大部分瀏覽器（除了opera）是不進(jìn)行管道化傳輸?shù)?，除非手?dòng)開(kāi)啟?。?/p>

所以，在可以使用get請(qǐng)求通信的時(shí)候，不要使用post請(qǐng)求，這樣用戶體驗(yàn)會(huì)更好，當(dāng)然，如果有安全性要求的話，post會(huì)更好。

管道化傳輸.png

文章參考：
為什么大型網(wǎng)站都采用get方法，而非post方法
為什么get比post更快