IT界知名的程序員曾說：對於那些月薪三萬以下，自稱IT工程師的碼農們，其實我們從來沒有把他們歸為我們IT工程師的隊伍。他們雖然總是以IT工程師自居，但只是他們一廂情願罷了。
此話一出，不知激起了多少(碼農)程序員的憤怒，卻又無可奈何，於是碼農問程序員。
碼農：你知道get和post請求到底有什麼區別？
程序員：你看這篇就知道了。
碼農：你月薪三萬了？
程序員：嗯。
碼農：你是怎麼做到的?
程序員：我做夢做到的
前言
這個問題幾乎面試的時候都會問到，是一個老生常談的話題，然而隨著不斷的學習，對於以前的認識有很多誤區，所以還是需要不斷地總結的，學而時習之，不亦說乎。
關於get和post如果你有條件上百度的話，至少有200百萬條結果，每個人都有每個人的思考，當然，這篇也是我的思考，如果有些結論有錯誤，希望能夠噴起來。在批評中不斷改進，與諸君共勉一句話：若批評無意義，則讚美無意義。
文章目錄
前言
01 特點
1.1 http的特點
1.2 請求方法
1.3 我們耳熟能詳的的區別
02 常見的誤區
2.1 誤區一
2.2 誤區二
2.3 誤區三
2.4 誤區四：“GET產生一個TCP數據包；POST產生兩個TCP數據包。”
3 http狀態碼附錄
3.1 狀態碼1xx
3.2 狀態碼2xx:成功
3.3 狀態碼3xx:重定向
3.4 狀態碼4xx:客戶端錯誤
3.5 狀態碼5** 服務端錯誤
01 特點
1.1 http的特點
基於tcp/ip、一種網絡應用層協議、超文本傳輸協議HyperText Transfer Protocol
工作方式：客戶端請求服務端應答的模式
快速：無狀態連接
靈活：可以傳輸任意對象，對象類型由Content-Type標記
客戶端請求request消息包括以下格式：請求行（request line）、請求頭部（header）、空行、請求數據
服務端響應response也由四個部分組成，分別是：狀態行、消息報頭、空行、響應正文
1.2 請求方法
http請求可以使用多種請求方法。
HTTP1.0定義了三種請求方法： GET, POST 和 HEAD方法。
HTTP1.1新增了五種請求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。
HTTP2.0 新的二進制格式（Binary Format），HTTP1.x的解析是基於文本。基於文本協議的格式解析存在天然缺陷，文本的表現形式有多樣性，要做到健壯性考慮的場景必然很多，二進制則不同，只認0和1的組合。基於這種考慮HTTP2.0的協議解析決定採用二進制格式，實現方便且健壯。
多路複用（MultiPlexing），即連接共享，即每一個request都是是用作連接共享機制的。一個request對應一個id，這樣一個連接上可以有多個request，每個連接的request可以隨機的混雜在一起，接收方可以根據request的 id將request再歸屬到各自不同的服務端請求裡面。
header壓縮，如上文中所言，對前面提到過HTTP1.x的header帶有大量信息，而且每次都要重複發送，HTTP2.0使用encoder來減少需要傳輸的header大小，通訊雙方各自cache一份header fields表，既避免了重複header的傳輸，又減小了需要傳輸的大小。
服務端推送（server push），同SPDY一樣，HTTP2.0也具有server push功能。
參考鏈接：https://baike.baidu.com/item/HTTP%202.0/12520156?fr=aladdin
1 GET 請求指定的頁面信息，並返回實體主體。
2 HEAD 類似於get請求，只不過返回的響應中沒有具體的內容，用於獲取報頭
3 POST 向指定資源提交數據進行處理請求（例如提交表單或者上傳文件）。數據被包含在請求體中。POST請求可能會導致新的資源的建立和/或已有資源的修改。
4 PUT 從客戶端向服務器傳送的數據取代指定的文檔的內容。
5 DELETE 請求服務器刪除指定的頁面。
6 CONNECT HTTP/1.1協議中預留給能夠將連接改為管道方式的代理服務器。
7 OPTIONS 允許客戶端查看服務器的性能。
8 TRACE 回顯服務器收到的請求，主要用於測試或診斷。
1.3 我們耳熟能詳的的區別
http協議最常見的兩種方法GET和POST，這幾點答案其實有幾點並不準確
請求緩存：GET 會被緩存，而post不會
收藏書籤：GET可以，而POST不能
保留瀏覽器歷史記錄：GET可以，而POST不能
用處：get常用於取回數據，post用於提交數據
安全性：post比get安全
請求參數：querystring 是url的一部分get、post都可以帶上。 get的querystring（僅支持urlencode編碼），post的參數是放在body（支持多種編碼）
請求參數長度限制：get請求長度最多1024kb，post對請求數據沒有限制
02 常見的誤區
get和post誤區
針對上面常見的區別，如果面試的時候這麼說，肯定是有很大的毛病，剛在學校面試的時候也曾經囫圇吞棗地這樣說過，現在回過頭再想以前的錯誤認知，又有許多新的認識。
2.1 誤區一
“用處：get常用於取回數據，post用於提交數據”
曾聽到過這樣一種說法：get替換post來優化網站性能，雖然這種說法沒錯，也的確get常被用於取回數據，但是post也被一些ui框架使用於取回數據，比如kendo ui中的grid，就是用post來接受數據的。所以結論是get、post用途也是因地制宜。如果你有使用過kendo UI，會發現分頁、過濾、自定義的參數都包含在form data裡面。
請求參數
get是querystring（僅支持urlencode編碼），post是放在body（支持多種編碼）
query參數是URL的一部分，而GET、POST等是請求方法的一種，不管是哪種請求方法，都必須有URL，而URL的query是可選的，可有可無。
2.2 誤區二
“請求參數長度限制：get請求長度最多1024kb，post對請求數據沒有限制”
這句話看上去實在沒毛病啊，菜鳥教程也是這樣說的啊。雖然字面意思上沒有錯誤，但是理解一定要正確。我想說的是GET方法提交的url參數數據大小沒有限制，在http協議中沒有對url長度進行限制（不僅僅是querystring的長度），這個限制是特定的瀏覽器及服務器對他的限制
下面就是對各種瀏覽器和服務器的最大處理能力做一些說明
IE瀏覽器對URL的最大限制為2083個字符
Firefox (Browser)：對於Firefox瀏覽器URL的長度限制為65,536個字符。
Safari (Browser)：URL最大長度限制為 80,000個字符。
Opera (Browser)：URL最大長度限制為190,000個字符。
Google (chrome)：URL最大長度限制為8182個字符。
Apache (Server)：能接受最大url長度為8,192個字符。
Microsoft Internet Information Server(IIS)：能接受最大url的長度為16,384個字符。
所以為了符合所有標準，url的最好不好超過最低標準的2083個字符（2k+35）。當然在做客戶端程序時，url並不展示給用戶，只是個程序調用，這時長度只收web服務器的影響了。對於中文的傳遞，一個漢字最終編碼後的字符長度是9個字符。
最常見的form表單，瀏覽器默認的form表單，默認的content-type是application/x-www-form-urlencoded,提交的數據會按照key value的方式，jquery的ajax默認的也是這種content-type。當然在post方式中添加querystring一定是可以接收的到，但是在get方式中加body參數就不一定能成功接收到了。
2.3 誤區三
“post比get安全性要高”
這裡的安全是相對性，並不是真正意義上的安全，通過get提交的數據都將顯示到url上，頁面會被瀏覽器緩存，其他人查看歷史記錄會看到提交的數據，而post不會。另外get提交數據還可能會造成CSRF攻擊。
2.4 誤區四：“GET產生一個TCP數據包；POST產生兩個TCP數據包。”
這一點理解起來還是有一定難度的,實際上，不論哪一種瀏覽器，在發送 POST 的時候都沒有帶 Expect 頭，server 也自然不會發 100 continue。通過抓包發現，儘管會分兩次，body 就是緊隨在 header 後面發送的，根本不存在『等待服務器響應』這一說。
從另一個角度說，TCP 是傳輸層協議。別人問你應用層協議裡的 GET 和 POST 有啥區別，你回答說這倆在傳輸層上發送數據的時候不一樣，確定別人不抽你？
參考資料：https://zhuanlan.zhihu.com/p/25028045
3 http狀態碼附錄
3.1 狀態碼1xx
100 Continue：
服務器僅接收到部分請求，但是一旦服務器並沒有拒絕該請求，客戶端應該繼續發送其餘的請求。
101 Switching Protocols：
服務器轉換協議：服務器將遵從客戶的請求轉換到另外一種協議。
102: 由WebDAV（RFC 2518）：
擴展的狀態碼，代表處理將被繼續執行
3.2 狀態碼2xx:成功
200 OK：
請求成功（其後是對GET和POST請求的應答文檔。）
201 Created：
請求被創建完成，同時新的資源被創建。
202 Accepted：
供處理的請求已被接受，但是處理未完成。
203 Non-authoritative Information：
文檔已經正常地返回，但一些應答頭可能不正確，因為使用的是文檔的拷貝。
204 No Content：
沒有新文檔。瀏覽器應該繼續顯示原來的文檔。如果用戶定期地刷新頁面，而Servlet可以確定用戶文檔足夠新，這個狀態代碼是很有用的。
205 Reset Content：
沒有新文檔。但瀏覽器應該重置它所顯示的內容。用來強制瀏覽器清除表單輸入內容。
206 Partial Content：
客戶發送了一個帶有Range頭的GET請求，服務器完成了它。
3.3 狀態碼3xx:重定向
300 Multiple Choices：
多重選擇。鏈接列表。用戶可以選擇某鏈接到達目的地。最多允許五個地址。
301 Moved Permanently：
所請求的頁面已經轉移至新的url
302 Found：
所請求的頁面已經臨時轉移至新的url。
303 See Other：
所請求的頁面可在別的url下被找到。
304 Not Modified：
未按預期修改文檔。客戶端有緩衝的文檔併發出了一個條件性的請求（一般是提供If-Modified-Since頭表示客戶只想比指定日期更新的文檔）。服務器告訴客戶，原來緩衝的文檔還可以繼續使用。
305 Use Proxy：
客戶請求的文檔應該通過Location頭所指明的代理服務器提取。
306 Unused：
此代碼被用於前一版本。目前已不再使用，但是代碼依然被保留。
307 Temporary Redirect：
被請求的頁面已經臨時移至新的url。
3.4 狀態碼4xx:客戶端錯誤
400 Bad Request：
服務器未能理解請求。
401 Unauthorized：
被請求的頁面需要用戶名和密碼。
401.1：
登錄失敗。
401.2：
服務器配置導致登錄失敗。
401.3：
由於 ACL 對資源的限制而未獲得授權。
401.4：
401.5：
ISAPI/CGI 應用程序授權失敗。
401.7：
訪問被 Web 服務器上的 URL 授權策略拒絕。這個錯誤代碼為 IIS 6.0 所專用。
402 Payment Required：
此代碼尚無法使用。
403 Forbidden：
對被請求頁面的訪問被禁止。
404 Not Found:
服務器無法找到被請求的頁面。
405 Method Not Allowed:
請求中指定的方法不被允許。
406 Not Acceptable:
服務器生成的響應無法被客戶端所接受。
407 Proxy Authentication Required:
用戶必須首先使用代理服務器進行驗證，這樣請求才會被處理。
408 Request Timeout:
請求超出了服務器的等待時間。
409 Conflict:
由於衝突，請求無法被完成。
410 Gone:
被請求的頁面不可用。
411 Length Required:
“Content-Length” 未被定義。如果無此內容，服務器不會接受請求。
412 Precondition Failed:
請求中的前提條件被服務器評估為失敗。
413 Request Entity Too Large:
由於所請求的實體的太大，服務器不會接受請求。
414 Request-url Too Long:
由於url太長，服務器不會接受請求。當post請求被轉換為帶有很長的查詢信息的get請求時，就會發生這種情況。
415 Unsupported Media Type:
由於媒介類型不被支持，服務器不會接受請求。
416 Requested Range Not Satisfiable:
服務器不能滿足客戶在請求中指定的Range頭。
417 Expectation Failed:
執行失敗。
423:
鎖定的錯誤。
3.5 狀態碼5** 服務端錯誤
500 Internal Server Error：
請求未完成。服務器遇到不可預知的情況。
501 Not Implemented：
請求未完成。服務器不支持所請求的功能。
502 Bad Gateway：
請求未完成。服務器從上游服務器收到一個無效的響應。
503 Service Unavailable：
請求未完成。服務器臨時過載或宕機。
504 Gateway Timeout：
網關超時。
505 HTTP Version Not Supported：
服務器不支持請求中指明的HTTP協議版本。
閱讀更多 技術剛剛好 的文章
