在網際網路已經滲透了生產、生活各個角落的今天，人們可以登入微信語音聊天，可以隨手“掃”到各種功能的二維碼，可以通過方便快捷的無人超市購物……這種網際網路領域的跨越式發展，不僅滿足了人們生活中各種各樣的需求，也催生了一個個新興領域的誕生，為經濟增長注入了強勁動力。 上網的過程，其實是瀏覽器向服務端傳送請求，之後將服務端主機上的內容顯示到本地的一個流程。而瀏覽器與伺服器之間的請求走的就是 HTTP 協議。  自 1990 年以來，超文字傳輸協議（HTTP） 就成為了網際網路資料通訊的基礎，它是分散式協作超媒體資訊系統的應用層協議，是一種通用的無狀態協議。具體來講就是讓伺服器不保留與客戶交易時的任何狀態，由客戶端單方面向伺服器傳送請求資料。 HTTP 主要有 0.9、1.0、1.1、2.0 版本，其中 1.1 版本定義了 9 種 Method（方法），分別是：  這些方法中，最常見的便是 GET 和 POST，但是可能很少有人關注兩者都有什麼作用，我們一起來看一看吧。 ## GET vs POST Method GET 和 POST 都是 HTTP 協定的一種請求標準，同樣基於 TCP 傳輸層協議。兩者主要區別在存放資料的方式不同，進而造成的傳輸量、安全性等差異。 **GET** 我們先來看一下 GET 是怎麼傳送資訊的： ``` ``` 如上完成程式碼點選“提交”之後，瀏覽器的網址就會變成 http://www.a.com/a.html?id=11111，瀏覽器會自動將表單內容轉為 Query String 加在 URL 後面進行請求。這樣，從瀏覽器的網址裡就可以看見表單要傳送的資料。 **POST** 接下來我們看看 POST 的傳送： ``` ``` 提交之後，地址並無變化，但是通過檢視 HTTP Request 的內容可以發現，POST 是將表單資料放在 Message Body 進行傳送。 看不太懂程式碼的小夥伴也不要著急，我們以現實生活中寄信的機制來舉例。如果說信封的撰寫格式是 HTTP，我們可以將信封外的內容稱為 Http-Header，信封內的書信稱為 Message Body。 HTTP Method 就是你要告訴郵差的寄信規則。 而假設 GET 就如同明信片一樣將要傳遞的資訊寫在信封（Http-Header）上，是信封內不裝信件的寄送方式，是直接將要傳送的資訊以 Query String（一種 Key/Vaule 的編碼方式）的形式加在地址（URL）後面進行傳送。那 POST 就是信封內裝有信件的寄送方式，不但信封可以寫東西，信封內（Message Body）還可以放入你想要寄送的其他資料，之後由郵差進行傳送。 **GET VS POST** 總體來說，兩種請求方式有如下區別： **- 傳遞引數方式：**GET 是將引數寫在 URL 中 ? 的後面，並用 & 分隔不同引數；而 POST 是將資訊存放在 Message Body 中傳送。 **- 傳輸資料量限制：**HTTP 協定本身沒有限制 URL 及正文長度，多半是瀏覽器為了避免過長的 URL 消耗過多的資源而限制長度；而以 POST 請求通常都沒有內容長度限制的問題。 **- 安全性問題：**GET 請求方式從瀏覽器的 URL 地址就可以看到引數；但無論是 GET 還是 POST 其實都是不安全的，因為 HTTP 協定是明文傳輸，只要攔截封包便能輕易獲取重要資訊。想要安全傳輸資料，必須使用 SSL/TLS來加密封包，也就是 HTTPS。 除了我們較為常見的 GET 和 POST 兩種請求方式，現在其他請求方式也越來越多的被使用。例如又拍雲基於 RESTful 架構的 REST API 中，除了使用 GET 獲取檔案外，也會使用 PUT 來上傳檔案，DELETE 用來刪除檔案，HEAD 用來獲取檔案資訊，使用 PATCH 來修改檔案 Metadata 資訊等等。 ## 請求與狀態碼 當然，上面講的請求方式雖然很常見，但是如果不是稍微有些瞭解或者對網際網路有些關注的小夥伴，可能並不會注意到。但是我們接下來說的肯定是大家都有見過的。畢竟在我們使用網頁瀏覽內容的過程中肯定，有見到過例如：404 NOT FOUND、504 TIME OUT，這類的提示。其實這個是 HTTP 的狀態碼。 HTTP 狀態碼由三個十進位制數字組成，第一個十進位制數字定義了狀態碼的型別，後兩位不具有任何分類作用。當用戶訪問一個網頁時，使用者的瀏覽器會向網頁所在伺服器發出請求。在瀏覽器接收並顯示網頁前，此網頁所在的伺服器會返回一個包含 HTTP 狀態碼的資訊頭（Header）用以響應瀏覽器的請求。而這個狀態碼則可以幫助我們粗略的判斷請求結果或錯誤原因。 HTTP 狀態碼共分為 5 種類型：  一直在使用又拍雲 CDN 的小夥伴兒對一些常見的狀態碼肯定很熟悉。比如，網站訪問成功請求會返回 200；開啟了強制 HTTPS，會返回 301；如果開啟了防盜鏈被攔截，則是返回 403 等等。 在這些常規的狀態碼下，又拍雲還進行了進一步的封裝，讓我們可以通過查詢又拍雲錯誤碼錶的方式獲得更為準確的網站報錯原因。 {"code":"40310013","msg":"invalid user token."} 查詢錯誤碼錶得知，觸發了 Token 防盜鏈規 講了這麼多，是不是對 HTTP 請求有了更近一步的瞭解？當然了，HTTP 協議不僅僅於此，有興趣的小夥伴兒們要持續關注哦~ #### 推薦閱讀 [QUIC協議詳解之Initial包的處理](https://www.upyun.com/tech/article/571/QUIC%E5%8D%8F%E8%AE%AE%E8%AF%A6%E8%A7%A3%E4%B9%8BInitial%E5%8C%85%E7%9A%84%E5%A4%84%E7%90%86.html) [當我談 HTTP 時，我談些什麼?](https://www.upyun.com/tech/article/564/%E5%BD%93%E6%88%91%E8%B0%88%20HTTP%20%E6%97%B6%EF%BC%8C%E6%88%91%E8%B0%88%E4%BA%9B%E4%BB%80%E4%B9%88%3