程序員：我終于知道post和get的區(qū)別

IT界知名的程序員曾說(shuō)：對(duì)于那些月薪三萬(wàn)以下，自稱IT工程師的碼農(nóng)們，其實(shí)我們從來(lái)沒有把他們歸為我們IT工程師的隊(duì)伍。他們雖然總是以IT工程師自居，但只是他們一廂情愿罷了。

此話一出，不知激起了多少(碼農(nóng))程序員的憤怒，卻又無(wú)可奈何，于是碼農(nóng)問程序員。

碼農(nóng)：你知道get和post請(qǐng)求到底有什么區(qū)別？

程序員：你看這篇就知道了。

碼農(nóng)：你月薪三萬(wàn)了？

程序員：嗯。

碼農(nóng)：你是怎么做到的？

程序員：我做夢(mèng)做到的

前言

這個(gè)問題幾乎面試的時(shí)候都會(huì)問到，是一個(gè)老生常談的話題，然而隨著不斷的學(xué)習(xí)，對(duì)于以前的認(rèn)識(shí)有很多誤區(qū)，所以還是需要不斷地總結(jié)的，學(xué)而時(shí)習(xí)之，不亦說(shuō)乎。

關(guān)于get和post如果你有條件上百度的話，至少有200百萬(wàn)條結(jié)果，每個(gè)人都有每個(gè)人的思考，當(dāng)然，這篇也是我的思考，如果有些結(jié)論有錯(cuò)誤，希望能夠噴起來(lái)。在批評(píng)中不斷改進(jìn)，與諸君共勉一句話：若批評(píng)無(wú)意義，則贊美無(wú)意義。

01 特點(diǎn)

1.1 http的特點(diǎn)

基于tcp/ip、一種網(wǎng)絡(luò)應(yīng)用層協(xié)議、超文本傳輸協(xié)議HyperText Transfer Protocol
工作方式：客戶端請(qǐng)求服務(wù)端應(yīng)答的模式
快速：無(wú)狀態(tài)連接
靈活：可以傳輸任意對(duì)象，對(duì)象類型由Content-Type標(biāo)記
客戶端請(qǐng)求request消息包括以下格式：請(qǐng)求行（request line）、請(qǐng)求頭部（header）、空行、請(qǐng)求數(shù)據(jù)

服務(wù)端響應(yīng)response也由四個(gè)部分組成，分別是：狀態(tài)行、消息報(bào)頭、空行、響應(yīng)正文

1.2 請(qǐng)求方法

http請(qǐng)求可以使用多種請(qǐng)求方法。
HTTP1.0定義了三種請(qǐng)求方法： GET, POST 和 HEAD方法。

HTTP1.1新增了五種請(qǐng)求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。

1 GET 請(qǐng)求指定的頁(yè)面信息，并返回實(shí)體主體。
2 HEAD 類似于get請(qǐng)求，只不過返回的響應(yīng)中沒有具體的內(nèi)容，用于獲取報(bào)頭
3 POST 向指定資源提交數(shù)據(jù)進(jìn)行處理請(qǐng)求（例如提交表單或者上傳文件）。數(shù)據(jù)被包含在請(qǐng)求體中。POST請(qǐng)求可能會(huì)導(dǎo)致新的資源的建立和/或已有資源的修改。
4 PUT 從客戶端向服務(wù)器傳送的數(shù)據(jù)取代指定的文檔的內(nèi)容。
5 DELETE 請(qǐng)求服務(wù)器刪除指定的頁(yè)面。
6 CONNECT HTTP/1.1協(xié)議中預(yù)留給能夠?qū)⑦B接改為管道方式的代理服務(wù)器。
7 OPTIONS 允許客戶端查看服務(wù)器的性能。
8 TRACE 回顯服務(wù)器收到的請(qǐng)求，主要用于測(cè)試或診斷。

1.3 我們耳熟能詳?shù)牡膮^(qū)別

http協(xié)議最常見的兩種方法GET和POST，這幾點(diǎn)答案其實(shí)有幾點(diǎn)并不準(zhǔn)確

請(qǐng)求緩存：GET 會(huì)被緩存，而post不會(huì)
收藏書簽：GET可以，而POST不能
保留瀏覽器歷史記錄：GET可以，而POST不能
用處：get常用于取回?cái)?shù)據(jù)，post用于提交數(shù)據(jù)
安全性：post比get安全
請(qǐng)求參數(shù)：querystring 是url的一部分get、post都可以帶上。 get的querystring（僅支持urlencode編碼），post的參數(shù)是放在body（支持多種編碼）
請(qǐng)求參數(shù)長(zhǎng)度限制：get請(qǐng)求長(zhǎng)度最多1024kb，post對(duì)請(qǐng)求數(shù)據(jù)沒有限制

02 常見的誤區(qū)

get和post誤區(qū)

針對(duì)上面常見的區(qū)別，如果面試的時(shí)候這么說(shuō)，肯定是有很大的毛病，剛在學(xué)校面試的時(shí)候也曾經(jīng)囫圇吞棗地這樣說(shuō)過，現(xiàn)在回過頭再想以前的錯(cuò)誤認(rèn)知，又有許多新的認(rèn)識(shí)。

2.1 誤區(qū)一

“用處：get常用于取回?cái)?shù)據(jù)，post用于提交數(shù)據(jù)”

曾聽到過這樣一種說(shuō)法：get替換post來(lái)優(yōu)化網(wǎng)站性能，雖然這種說(shuō)法沒錯(cuò)，也的確get常被用于取回?cái)?shù)據(jù)，但是post也被一些ui框架使用于取回?cái)?shù)據(jù)，比如kendo ui中的grid，就是用post來(lái)接受數(shù)據(jù)的。所以結(jié)論是get、post用途也是因地制宜。如果你有使用過kendo UI，會(huì)發(fā)現(xiàn)分頁(yè)、過濾、自定義的參數(shù)都包含在form data里面。

請(qǐng)求參數(shù)

get是querystring（僅支持urlencode編碼），post是放在body（支持多種編碼）

query參數(shù)是URL的一部分，而GET、POST等是請(qǐng)求方法的一種，不管是哪種請(qǐng)求方法，都必須有URL，而URL的query是可選的，可有可無(wú)。

2.2 誤區(qū)二

“請(qǐng)求參數(shù)長(zhǎng)度限制：get請(qǐng)求長(zhǎng)度最多1024kb，post對(duì)請(qǐng)求數(shù)據(jù)沒有限制”

這句話看上去實(shí)在沒毛病啊，菜鳥教程也是這樣說(shuō)的啊。雖然字面意思上沒有錯(cuò)誤，但是理解一定要正確。我想說(shuō)的是GET方法提交的url參數(shù)數(shù)據(jù)大小沒有限制，在http協(xié)議中沒有對(duì)url長(zhǎng)度進(jìn)行限制（不僅僅是querystring的長(zhǎng)度），這個(gè)限制是特定的瀏覽器及服務(wù)器對(duì)他的限制

下面就是對(duì)各種瀏覽器和服務(wù)器的最大處理能力做一些說(shuō)明

IE瀏覽器對(duì)URL的最大限制為2083個(gè)字符
Firefox (Browser)：對(duì)于Firefox瀏覽器URL的長(zhǎng)度限制為65,536個(gè)字符。
Safari (Browser)：URL最大長(zhǎng)度限制為 80,000個(gè)字符。
Opera (Browser)：URL最大長(zhǎng)度限制為190,000個(gè)字符。
google (chrome)：URL最大長(zhǎng)度限制為8182個(gè)字符。
Apache (Server)：能接受最大url長(zhǎng)度為8,192個(gè)字符。
Microsoft Internet Information Server(IIS)：能接受最大url的長(zhǎng)度為16,384個(gè)字符。

所以為了符合所有標(biāo)準(zhǔn)，url的最好不好超過最低標(biāo)準(zhǔn)的2083個(gè)字符（2k+35）。當(dāng)然在做客戶端程序時(shí)，url并不展示給用戶，只是個(gè)程序調(diào)用，這時(shí)長(zhǎng)度只收web服務(wù)器的影響了。對(duì)于中文的傳遞，一個(gè)漢字最終編碼后的字符長(zhǎng)度是9個(gè)字符。

最常見的form表單，瀏覽器默認(rèn)的form表單，默認(rèn)的content-type是Application/x-www-form-urlencoded,提交的數(shù)據(jù)會(huì)按照key value的方式，jquery的ajax默認(rèn)的也是這種content-type。當(dāng)然在post方式中添加querystring一定是可以接收的到，但是在get方式中加body參數(shù)就不一定能成功接收到了。

2.3 誤區(qū)三

“post比get安全性要高”

這里的安全是相對(duì)性，并不是真正意義上的安全，通過get提交的數(shù)據(jù)都將顯示到url上，頁(yè)面會(huì)被瀏覽器緩存，其他人查看歷史記錄會(huì)看到提交的數(shù)據(jù)，而post不會(huì)。另外get提交數(shù)據(jù)還可能會(huì)造成CSRF攻擊。

2.4 誤區(qū)四：“GET產(chǎn)生一個(gè)TCP數(shù)據(jù)包；POST產(chǎn)生兩個(gè)TCP數(shù)據(jù)包。”

這一點(diǎn)理解起來(lái)還是有一定難度的,實(shí)際上，不論哪一種瀏覽器，在發(fā)送 POST 的時(shí)候都沒有帶 Expect 頭，server 也自然不會(huì)發(fā) 100 continue。通過抓包發(fā)現(xiàn)，盡管會(huì)分兩次，body 就是緊隨在 header 后面發(fā)送的，根本不存在『等待服務(wù)器響應(yīng)』這一說(shuō)。

從另一個(gè)角度說(shuō)，TCP 是傳輸層協(xié)議。別人問你應(yīng)用層協(xié)議里的 GET 和 POST 有啥區(qū)別，你回答說(shuō)這倆在傳輸層上發(fā)送數(shù)據(jù)的時(shí)候不一樣，確定別人不抽你？

參考資料：https://zhuanlan.zhihu.com/p/25028045

3 http狀態(tài)碼附錄

3.1 狀態(tài)碼1xx

100 Continue：

服務(wù)器僅接收到部分請(qǐng)求，但是一旦服務(wù)器并沒有拒絕該請(qǐng)求，客戶端應(yīng)該繼續(xù)發(fā)送其余的請(qǐng)求。

101 Switching Protocols：

服務(wù)器轉(zhuǎn)換協(xié)議：服務(wù)器將遵從客戶的請(qǐng)求轉(zhuǎn)換到另外一種協(xié)議。

102: 由WebDAV（RFC 2518）：

擴(kuò)展的狀態(tài)碼，代表處理將被繼續(xù)執(zhí)行

3.2 狀態(tài)碼2xx:成功

200 OK：

請(qǐng)求成功（其后是對(duì)GET和POST請(qǐng)求的應(yīng)答文檔。）

201 Created：

請(qǐng)求被創(chuàng)建完成，同時(shí)新的資源被創(chuàng)建。

202 Accepted：

供處理的請(qǐng)求已被接受，但是處理未完成。

203 Non-authoritative Information：

文檔已經(jīng)正常地返回，但一些應(yīng)答頭可能不正確，因?yàn)槭褂玫氖俏臋n的拷貝。

204 No Content：

沒有新文檔。瀏覽器應(yīng)該繼續(xù)顯示原來(lái)的文檔。如果用戶定期地刷新頁(yè)面，而Servlet可以確定用戶文檔足夠新，這個(gè)狀態(tài)代碼是很有用的。

205 Reset Content：

沒有新文檔。但瀏覽器應(yīng)該重置它所顯示的內(nèi)容。用來(lái)強(qiáng)制瀏覽器清除表單輸入內(nèi)容。

206 Partial Content：

客戶發(fā)送了一個(gè)帶有Range頭的GET請(qǐng)求，服務(wù)器完成了它。

3.3 狀態(tài)碼3xx:重定向

300 Multiple Choices：

多重選擇。鏈接列表。用戶可以選擇某鏈接到達(dá)目的地。最多允許五個(gè)地址。

301 Moved Permanently：

所請(qǐng)求的頁(yè)面已經(jīng)轉(zhuǎn)移至新的url

302 Found：

所請(qǐng)求的頁(yè)面已經(jīng)臨時(shí)轉(zhuǎn)移至新的url。

303 See Other：

所請(qǐng)求的頁(yè)面可在別的url下被找到。

304 Not Modified：

未按預(yù)期修改文檔?？蛻舳擞芯彌_的文檔并發(fā)出了一個(gè)條件性的請(qǐng)求（一般是提供If-Modified-Since頭表示客戶只想比指定日期更新的文檔）。服務(wù)器告訴客戶，原來(lái)緩沖的文檔還可以繼續(xù)使用。

305 Use Proxy：

客戶請(qǐng)求的文檔應(yīng)該通過Location頭所指明的代理服務(wù)器提取。

306 Unused：

此代碼被用于前一版本。目前已不再使用，但是代碼依然被保留。

307 Temporary Redirect：

被請(qǐng)求的頁(yè)面已經(jīng)臨時(shí)移至新的url。

3.4 狀態(tài)碼4xx:客戶端錯(cuò)誤

400 Bad Request：
服務(wù)器未能理解請(qǐng)求。
401 Unauthorized：
被請(qǐng)求的頁(yè)面需要用戶名和密碼。
401.1：
登錄失敗。
401.2：
服務(wù)器配置導(dǎo)致登錄失敗。
401.3：
由于 ACL 對(duì)資源的限制而未獲得授權(quán)。
401.4：
篩選器授權(quán)失敗。
401.5：
ISAPI/CGI 應(yīng)用程序授權(quán)失敗。
401.7：
訪問被 Web 服務(wù)器上的 URL 授權(quán)策略拒絕。這個(gè)錯(cuò)誤代碼為 IIS 6.0 所專用。
402 Payment Required：
此代碼尚無(wú)法使用。
403 Forbidden：
對(duì)被請(qǐng)求頁(yè)面的訪問被禁止。
404 Not Found:
服務(wù)器無(wú)法找到被請(qǐng)求的頁(yè)面。
405 Method Not Allowed:
請(qǐng)求中指定的方法不被允許。
406 Not Acceptable:
服務(wù)器生成的響應(yīng)無(wú)法被客戶端所接受。
407 Proxy Authentication Required:
用戶必須首先使用代理服務(wù)器進(jìn)行驗(yàn)證，這樣請(qǐng)求才會(huì)被處理。
408 Request Timeout:
請(qǐng)求超出了服務(wù)器的等待時(shí)間。
409 Conflict:
由于沖突，請(qǐng)求無(wú)法被完成。
410 Gone:
被請(qǐng)求的頁(yè)面不可用。
411 Length Required:
“Content-Length” 未被定義。如果無(wú)此內(nèi)容，服務(wù)器不會(huì)接受請(qǐng)求。
412 Precondition Failed:
請(qǐng)求中的前提條件被服務(wù)器評(píng)估為失敗。
413 Request Entity Too Large:
由于所請(qǐng)求的實(shí)體的太大，服務(wù)器不會(huì)接受請(qǐng)求。
414 Request-url Too Long:
由于url太長(zhǎng)，服務(wù)器不會(huì)接受請(qǐng)求。當(dāng)post請(qǐng)求被轉(zhuǎn)換為帶有很長(zhǎng)的查詢信息的get請(qǐng)求時(shí)，就會(huì)發(fā)生這種情況。
415 Unsupported Media Type:
由于媒介類型不被支持，服務(wù)器不會(huì)接受請(qǐng)求。
416 Requested Range Not Satisfiable:
服務(wù)器不能滿足客戶在請(qǐng)求中指定的Range頭。
417 Expectation Failed:
執(zhí)行失敗。
423:
鎖定的錯(cuò)誤。