相信大家在不管是學習、工作或者面試中，肯定會碰到或被問到HTTP相關的知識。今天我們來聊聊有哪些HTTP請求方式，以及區別吧！

小伙伴們寫過接口或者使用過網頁開發者模式的，肯定對以下的內容不陌生：

沒錯，這些就是HTTP 請求的方式。

有一次面試的時候也被問到了這個問題，下面我會以面試的形式呈現給大家,那么就讓我把大家拉到面試的現場吧！

持續的腳步聲，由遠及近，隨之會議室的門被推開了。我起身定睛一看面試官，他那發際線即將觸碰到后腦勺，大框黑邊眼鏡也掩蓋不住那黝黑的眼圈，顯得格外的程序員。穿著也非常不拘一格，上半身是襯衣西服，下半身是牛仔褲配拖鞋。

我心中的默念：真大佬，無疑了！

隨后面試官就讓我坐下，面試就正式拉開帷幕！

自我介紹以及其他問題此處省略 1w 字……

面試官：平時開發過程中，你們常用的 HTTP 請求方法都有哪些啊？

我：是這樣的，HTTP 1.1 協議中共定義了八種方法，有時也叫動作，來表明 Request-URL 指定的資源不同的操作方式：

在 HTTP 1.0 中，定義了三種請求方法：GET、POST 和 HEAD 方法。

在 HTTP 1.1 中，新增了五種請求方法：OPTIONS、PUT、DELETE、TRACE 和 CONNECT 方法。但我們常用的一般就是 GET 和 POST 請求。

面試官：嗯，那你說說 GET 和 POST 請求都有哪些區別呢？（果然進套了，看你小子有幾斤幾兩）

我：（我假裝被難住，然后思考了一會兒說）這個……沒有特別去關注過，但是按照我的理解，大概有這么幾種區別吧。

GET 請求在 URL 中傳送的參數是有長度限制的，而 POST 沒有；

GET 比 POST 更不安全，因為參數直接暴露在 URL 上，所以不能用來傳遞敏感信息。而 POST 數據不會顯示在 URL 中。是放在 Request body 中；

對參數的數據類型，GET 只接受 ASCII 字符，而 POST 沒有限制；

GET 請求參數會被完整保留在瀏覽器歷史記錄里。相反，POST 請求參數也不會被瀏覽器保留；

GET 請求只能進行 URL 編碼（ application/x-www-form-urlencoded），而 POST 支持多種編碼方式；

GET 請求會被瀏覽器主動緩存，而 POST 不會，除非手動設置；

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

面試官：沒關注過，那你還背的一條不差。跟我擱這兒裝杯呢？看我怎么教育你。

面試官：那 GE嗎？

我：吼吼，看來有機會把我昨天精心準備的東西給他扯半小時了[手動撓頭] 。讓開，我要開始放大招了

其實吧，GET 和 POST 在本質上沒有區別，都是 HTTP 協議中的兩種發送請求的方法。而 HTTP 呢，是基于 TCP/IP 關于數據如何在萬維網中如何通信的協議。

萬維網：簡稱 WWW，是 World Wide Web 的簡稱，也稱為 Web、3W 等。

HTTP 的底層是 TCP/IP，所以 GET 和 POST 的底層也是 TCP/IP。也就是說， GET/POST 都是 TCP 鏈接。

GET 和 POST 能做的事情是一樣一樣的。你要給 GET 加上 Request body，給 POST 帶上 URL 參數，技術上是完全行的通的。

舉個栗子吧：（嗯？栗子？好餓，待會兒面試完去買點）

TCP 就像汽車，我們用 TCP 來運輸數據很可靠，從來不會發生丟件少件的現象。

但是如果路上跑的全是看起來一模一樣的汽車，那這個世界看起來是一團混亂。送急件的汽車可能被前面滿載貨物的汽車攔堵在路上，整個交通系統一定會癱瘓。

為了避免這種情況發生，交通規則HTTP誕生了。HTTP 給汽車運輸設定了好幾個服務類別，包括 GET、POST、PUT 等等。

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

如果是 POST 請求，就要在車上貼上 POST 的標簽，并把貨物放在車廂里（Request body 中）。

當然，你也可以在用 GET 時往車廂內偷偷藏點貨物，但這并不不光彩。也可以在POST的時候在車頂上也放一些數據，也會讓人覺得傻乎乎的。

HTTP 只是個行為準則，而 GET 和 POST 本質上就是 TCP 連接，并無差別。但是由于 HTTP 的規定和瀏覽器/服務器的限制，導致他們在應用過程中體現出一些不同。

面試官：哎呀，這小子還真的了解這塊兒啊。看來是我誤會他了，難道遇到了大佬？

面試官：你說的不錯，那你剛才說的 URL 中傳送參數的長度限制在 GET 和 POST 中都是怎么樣的呢？

我：其實在 Web 中啊，還有另一個重要的角色——運輸公司。

不同的瀏覽器 Client 端（發起 HTTP 請求）和服務器 Server 端（接受 HTTP 請求）就是不同的運輸公司。

雖然理論上，你可以在車頂上無限的堆貨物（URL 中無限加參數）。但是運輸公司可不傻，裝貨和卸貨也是有很大成本的。他們會限制單次運輸量來控制風險，數據量太大對瀏覽器和服務器都是很大負擔。

業界不成文的規定是，（大多數）瀏覽器通常都會限制 URL 長度在 2K 個字節，而（大多數）服務器最多處理 64K 大小的 URL。超過的部分恕不處理。

如果你用 GET 服務，在 Request body 偷偷藏了數據，不同服務器的處理方式也是不同的：有些服務器會幫你卸貨讀出數據，有些服務器直接忽略。

所以，雖然 GET 可以帶 Request body，卻不能保證一定能被接收到。

面試官：（看來理論確實是掌握的不錯，讓我考考他實際應用）那 GET 方法參數寫法是固定的嗎？

我：在約定中，我們的參數是寫在?后面，用&分割。就像下面這樣：

http://ip:port/test/getHelloWorld?username=langwang&age=26&sex=2

我們知道，解析報文的過程是通過獲取 TCP 數據，用正則等工具從數據中獲取 Header 和 Body，從而提取參數。比如header請求頭中添加token，來驗證用戶是否登錄等權限問題。

也就是說，我們可以自己約定參數的寫法，只要服務端能夠解釋出來就行，萬變不離其宗。

面試官：那么說來，是不是 POST 方法比 GET 方法更安全呢？

我：有人說 POST 比 GET 安全，因為數據在地址欄上不可見。

然而，從傳輸的角度來說，他們都是不安全的。因為 HTTP 在網絡上是明文傳輸的，只要在網絡節點上捉包，就能完整地獲取數據報文。

其實，要想安全傳輸，就只有加密，也就是HTTPS。

面試官：嗯，不錯不錯，看來你對 HTTP 協議這塊兒還是有一定了解的，那么你知道GET、POST 請求發送的數據包有什么不同嗎？

我：（看來這面試官是非要是把我問倒才滿意啊？可惜可惜。看我套路他一波）實不相瞞，我上家公司加班比較多，最近剛簽完離職，貴公司是我面的第一家公司，所以準備的不充分。這樣吧，我大致談談我的理解吧，不對的地方您見諒。

面試官：沒關系，按你的理解聊聊就行。（這小子沒準備就說成這樣，我的好好考慮一下，別錯失了先機，失去一個能為公司加班的人才）

我：嗯嗯。是這樣的，GET 請求時產生一個 TCP 數據包，POST 請求時產生兩個 TCP 數據包。

GET：瀏覽器會把 http header 和 data 一并發送出去，服務器響應 200（返回數據）；

POST：瀏覽器先發送 header，服務器響應 100 continue，瀏覽器再發送 data，服務器響應 200 OK（返回數據）。

就像是 GET 只需要汽車跑一趟就把貨送到了，而 POST 得跑兩趟。

第一趟，先去和服務器打個招呼：老鐵，我等下要送一批貨來，你們準備接收一下哈。然后再回頭把貨送過去。

因為 POST 需要兩步，理論上時間上消耗的要多一點。看起來 GET 比 POST 更有效。但并不是，后來發現原來是個坑。

在我看來：

GET 與 POST 都有自己的語義，不能隨便混用；

據研究，在網絡環境好的情況下，發一次包的時間和發兩次包的時間差別基本可以無視。而在網絡環境差的情況下，兩次包的 TCP 在驗證數據包完整性上，有非常大的優點；

并不是所有瀏覽器都會在 POST 中發送兩次包，Firefox 就只發送一次。我去年用 Chrome 瀏覽器測試發現也是只發送一次，所以我認為 GET、POST 性能差可以人為忽略。

面試官：嗯，你說的很不錯，那你稍微等一下啊。

我：（難道還有變故？這波操作難道被發現了我在套路面試官？不應該啊）五分鐘后，面試官拿著一杯飲料走了進來……

面試官：你嘗嘗這咖啡味道如何？（自古套路得人心，學好了）

我喝了一口，豎起大拇指說道：“面試官，這是正宗的卡布奇諾啊，我平時就喜歡喝，可惜太貴了”。

咦？我進來之前沒有看到你們這有咖啡店呀，這是？

面試官嘴角上翹，微微一笑，露出了潔白的兩顆大門牙說道：

我看你簡歷說你愛喝咖啡。巧了，我們公司有專門的水吧，福利之一就是是每天免費一杯咖啡或飲料。以后你可以經常喝了。

我：那您的意思是，我面試過了了嗎？太好了！對了，水吧每天幾點下班吶？跟開發一個點兒么？（不會是因為經常加班才免費喝咖啡吧，我得試探試探）

面試官：哈哈是啊，水吧一直都是按點下班，咱們公司如果有人加班的話，可以自己去水吧做著喝就行，加班時間都是免費的。你這兒沒問題的話，我看下周一就入職吧。

我：好的，面試官，我回去考慮下，到時候和您聯系，再見！

至此，本次關于 HTTP 請求方式，以及 GET 和 POST 的區別相關的面試就結束啦，感謝大家的觀看！

責任編輯：haq