當面試的時候，考官問你：GET和POST的作用是什麼，它們又有什麼區別呢

這時候你該如何回答呢？

且讓我們來理一理思緒~

開始入手web專案的夥伴們基本上都開始使用GET和POST請求了，那這兩種請求到底是什麼東西呢，它又有什麼作用？

今天我們來細細瞭解一下。GET和POST作為http的兩種請求，想要了解它們就得先認識一下HTTP協議。

那麼什麼是HTTP協議呢？

超文字傳輸協議，即Hyper Text Transfer Protocol——HTTP，是一個為了使客戶端和伺服器順利進行通訊而設計的協議。

它是如何工作的呢？

HTTP在客戶端與伺服器之間以request-response protocol（請求-回覆協議）

那這兩種方法有什麼作用呢？

GET——從指定的伺服器中獲取資料

POST——提交資料給指定的伺服器處理

接下來我們就好好了解一下這兩種方法。

GET方法

概念：

使用GET方法時，查詢字串以鍵值對的形式被附加在URL地址後面，一起傳送到伺服器。

比如我們在CSDN搜尋“什麼是GET”，得到的網址如下：

從上圖我們可以看到，GET方式將搜尋的內容附加在URL地址後面，再從指定的伺服器中獲取資料顯示。其格式為：

分割URL和傳輸資料，引數之間以&相連。 資料如果是英文字母/數字，原樣傳送， 如果是空格，轉換為+， 如果是中文/其他字元，則直接把字串用BASE64加密，及“%”加上“字串的16進位制ASCII碼”。 

特點：

• GET請求能夠被快取
• GET請求會儲存在瀏覽器的瀏覽記錄中
• 以GET請求的URL能夠儲存為瀏覽器書籤
• GET請求有長度限制
• GET請主要用於獲取資料。

從上面所述的特點可以發現，大多數的搜尋引擎的搜尋框用的都是GET請求，通過GET請求獲取搜尋到的相關資料。對於倒數第二點——GET請求有長度限制，這個想必很多人在用搜索引擎的時候也發現了：當你複製一大段文字到搜尋框的時候，它只會顯示少部分。這就說明了GET請求有長度限制。

POST方法：

概念：

使用POST方法時，查詢字串在POST資訊中單獨存在，和HTTP請求一起傳送到伺服器。

特點：

• POST請求不能被快取下來
• POST請求不會儲存在瀏覽器的瀏覽記錄中
• 以Post請求的URL無法儲存為瀏覽器書籤
• POST請求沒有長度限制

顯然，POST請求的很多特點於GET請求相反，從這個對比我們可以知道，POST請求比GET請求更具有保密性以及安全性。像我們平常的登入網站的賬號與密碼的提交就屬於POST請求。

接下來我們通過一張表來具體對比一下GET和POST這兩種請求。

當然了， HTTP其實也不止GET和POST這兩種，還有一些其他的請求方法，如下表：

想到這裡，你恐怕即將要脫口而出一大段：

• GET在瀏覽器回退時是無害的，而POST會再次提交請求。

• GET產生的URL地址可以被新增為書籤，而POST不可以。

• GET請求會被瀏覽器主動儲存，而POST不會，除非手動設定。

• GET請求只能進行url編碼，而POST支援多種編碼方式。

• GET請求引數會被完整保留在瀏覽器歷史記錄裡，而POST中的引數不會被保留。

• GET請求在URL中傳送的引數是有長度限制的，而POST麼有。

• 對引數的資料型別，GET只接受ASCII字元，而POST沒有限制。

• GET比POST更不安全，因為引數直接暴露在URL上，所以不能用來傳遞敏感資訊。

• GET引數通過URL傳遞，POST放在Request body中。

 就在你信心滿滿，底氣十足地將一通標準答案傾倒在面試官面前的時候，你卻發現對方嘴角還帶著一絲絲輕笑，似乎不是很滿意這個答案。

難道，事情還有更進一步挖探的可能？

按道理來說，上面答的已經很全面了呀，難不成還有遺漏？

且讓我再梳理一遍。

GET和POST是什麼？

HTTP協議中的兩種傳送請求的方法。

HTTP是什麼？

HTTP是基於TCP/IP的關於資料如何在全球資訊網中如何通訊的協議。

HTTP的底層是TCP/IP。所以GET和POST的底層也是TCP/IP，也就是說，GET/POST都是TCP連結。GET和POST能做的事情是一樣一樣的。你要給GET加上request body，給POST帶上url引數，技術上是完全行的通的。 

嗯？這好像和剛才梳理的不太一樣。

那既然大家都是TCP連結，那為什麼這兩種方法特徵不一？莫非在成長的路上變異了咩~

等等，HTTP的底層是TCP/IP，既然TCP沒有啥不同的地方，那GET/POST的差別會不會是HTTP協議給搗鼓出來的？

那這次我們從底層出發，再來梳理梳理。

首先，在咱們全球資訊網世界裡，TCP就是運輸工具（如汽車），我們用TCP來運輸資料。它很可靠，從來不會發生丟件少件的現象。但是，大家都是TCP連結，也就是說所有的汽車都長一樣，路上全是一樣的汽車。那麼假如有加急的資料需要傳送，若是被不急的資料給擋住路，堵車了怎麼辦？整個交通系統一定會癱瘓。那怎麼辦？

這個時候就需要交通規則來約束行為。因此我們的奧義——HTTP協議，由此破殼而出。

HTTP給汽車運輸設定了好幾個服務類別，有GET, POST, PUT, DELETE等等，

HTTP規定，當執行GET請求的時候，要給汽車貼上GET的標籤（設定method為GET），而且要求把傳送的資料放在車頂上（url中）以方便記錄。

如果是POST請求，就要在車上貼上POST的標籤，並把貨物放在車廂裡。當然，你也可以在GET的時候往車廂內偷偷藏點貨物，但是這是很不光彩；也可以在POST的時候在車頂上也放一些資料，但這讓人覺得傻乎乎的。

顯然，TCP才是GET和POST怎麼實現的基本。而HTTP只是個行為準則。

到這裡也許你如果以為可以繼續作答了，那你就too simple啦~

從上文的描述中我們可以知道，HTTP只是對GET和POST引數的傳送渠道（url還是requrest body）提出了要求，那“標準答案”裡關於引數大小的限制又是從哪來的呢？

我們仔細想想，既然全球資訊網裡邊有那麼多運輸工具，那不還得有運輸公司嗎？這麼多種運輸工具，豈不是有很多家運輸公司咩?

因此，在我大全球資訊網世界中，還有另一個重要的角色：運輸公司。不同的瀏覽器（發起http請求）和伺服器（接受http請求）就是不同的運輸公司。 雖然理論上，你可以在車頂上無限的堆貨物（url中無限加引數）。但是運輸公司可不傻，裝貨和卸貨也是有很大成本的，他們會限制單次運輸量來控制風險，資料量太大對瀏覽器和伺服器都是很大負擔。

注：業界不成文的規定是，（大多數）瀏覽器通常都會限制url長度在2K個位元組，而（大多數）伺服器最多處理64K大小的url。超過的部分，恕不處理。如果你用GET服務，在request body偷偷藏了資料，不同伺服器的處理方式也是不同的，有些伺服器會幫你卸貨，讀出資料，有些伺服器直接忽略，所以，雖然GET可以帶request body，也不能保證一定能被接收到哦。

所以，GET和POST本質上就是TCP連結，並無差別。但是由於HTTP的規定和瀏覽器/伺服器的限制，導致他們在應用過程中體現出一些不同。 

看到這裡你是不是覺得自己已經明白了GET/POST的真諦，想要奪門而去？

這裡，我不得不挽留一下：少年！請留步！

因為我手裡還攥著一個終極大boss！

GET和POST還有一個重大區別，簡單的說：

GET產生一個TCP資料包；POST產生兩個TCP資料包。

這個怎麼理解呢？

實際上，對於GET方式的請求，瀏覽器會把http header和data一併傳送出去，伺服器響應200（返回資料）；

而對於POST，瀏覽器先發送header，伺服器響應100 continue，瀏覽器再發送data，伺服器響應200 ok（返回資料）。

還是以運輸車舉例，貼著GET標籤的運輸車車跑一趟就把貨送到了，而POST得先跑過去告訴伺服器，說：“你準備一下，我要運貨到你這裡啦~”，然後再回去將貨物運輸到目的地。

從上面的描述來看，POST需要走兩趟，而GET只需要一趟，似乎GET更加的高效一些。

但孔子說“因材施教”，這兩種方式也因不同的運用環境而有著其各自的優勢。

也許有些人會想要用GET來優化效能，還望大家多加謹慎一些，畢竟GET與POST都有自己的語義，不能隨便混用。

而且在網路環境好的情況下，發一次包的時間和發兩次包的時間差別基本可以無視，兩種都很快。而在網路環境差的情況下，兩次包的TCP在驗證資料包完整性這一點上，有非常大的優點。

此外，也並不是所有的瀏覽器都會在POST中傳送兩次包，像Firefox就只發送一次。

所以，要想通過GET置換POST，還是要謹慎一些喲。

好啦，今天的內容就到這裡。

關於GET和POST的作用、區別與其本質，只需要將上文中的標準答案以及文中後半部分對這兩種方法本質的闡述結合來看即可。

只要總結理解好，天王老子也不怕~

biu~~~~