在互聯網已經滲透了生產、生活各個角落的今天，人們可以登錄微信語音聊天，可以隨手“掃”到各種功能的二維碼，可以通過方便快捷的無人超市購物……這種互聯網領域的跨越式發展，不僅滿足了人們生活中各種各樣的需求，也催生了一個個新興領域的誕生，為經濟增長注入了強勁動力。
上網的過程，其實是瀏覽器向服務端發送請求，之後將服務端主機上的內容顯示到本地的一個流程。而瀏覽器與服務器之間的請求走的就是 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 是怎麼傳送信息的：
<form method="get" action="">
<input type="text" name="id" />
<input type="submit" />
</form>如上完成代碼點擊“提交”之後，瀏覽器的網址就會變成 http://www.a.com/a.html?id=11111，瀏覽器會自動將表單內容轉為 Query String 加在 URL 後面進行請求。這樣，從瀏覽器的網址裏就可以看見表單要傳送的資料。
POST
接下來我們看看 POST 的傳送：
<form method="post" action="">
<input type="text" name="id" />
<input type="submit" />
</form>提交之後，地址並無變化，但是通過查看 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包的處理
當我談 HTTP 時，我談些什麼?
