（一）舆瘪、不完全正確的網(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ù)驻襟，用戶(hù)名和密碼將明文出現(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全稱(chēng)是資源描述符卷谈，我們可以這樣認(rèn)為：一個(gè)URL地址，它用于描述一個(gè)網(wǎng)絡(luò)上的資源霞篡，而HTTP中的GET世蔗，POST，PUT朗兵，DELETE就對(duì)應(yīng)著對(duì)這個(gè)資源的查 污淋，改 ，增 余掖，刪 4個(gè)操作寸爆。到這里赁豆，大家應(yīng)該有個(gè)大概的了解了，GET一般用于獲取/查詢(xún)資源信息叶摄，而POST一般用于更新資源信息

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

1. 所謂安全的意味著該操作用于獲取信息而非修改信息。換句話(huà)說(shuō)氓辣，GET請(qǐng)求一般不應(yīng)產(chǎn)生副作用喇潘。就是說(shuō)絮吵，它僅僅是獲取資源信息，就像數(shù)據(jù)庫(kù)查詢(xún)一樣，不會(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é)果是一樣的私股，那么我們就稱(chēng)該運(yùn)算是冪等的。 比如絕對(duì)值運(yùn)算就是一個(gè)例子，在實(shí)數(shù)集中服球，有abs(a) = abs(abs(a)) 。
   對(duì)于雙目運(yùn)算仍翰，則要求當(dāng)參與運(yùn)算的兩個(gè)值是等值的情況下，如果滿(mǎn)足運(yùn)算結(jié)果與參與運(yùn)算的兩個(gè)值相等，則稱(chēng)該運(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)用戶(hù)打開(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以?xún)?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ì)話(huà)需要先建立tcp連接然后才能通信摊阀，如果每次連接都只進(jìn)行一次http會(huì)話(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中，還有一種稱(chēng)為管道通信的方式進(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í)客戶(hù)端即使收到了前9個(gè)請(qǐng)求的答復(fù)蒲障，也會(huì)將這9個(gè)請(qǐng)求的內(nèi)容清空歹篓，也就是說(shuō)，白忙活了……此時(shí)揉阎，客戶(hù)端的這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)啟Ｃ印徘溢！

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

管道化傳輸.png

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