前言
這個問題幾乎面試的時候都會問到，是一個老生常談的話題，然而隨着不斷的學習，對於以前的認識有很多誤區，所以還是需要不斷地總結的，學而時習之，不亦說乎。
關於get和post如果你有條件上百度的話，至少有200百萬條結果，每個人都有每個人的思考，當然，這篇也是我的思考，如果有些結論有錯誤，希望能夠噴起來。在批評中不斷改進，與諸君共勉一句話：若批評無意義，則讚美無意義。
文章目錄
1 特點
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對請求數據沒有限制
2 常見的誤區
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協議版本。