什么是HTTP協議請求？

HTTP協議規定，請求從客戶端發出，最后服務端回應該請求并回傳，也就是說，先從客戶端開始建立通信的，服務端在沒有接受到請求之前不會發送回應，且HTTP協議自身不對請求和回應之間的通信狀態進行保存，

（在進行下一步學習之前首先要了解一下HTTP的訊息結構）

HTTP訊息結構

HTTP是基于客戶端/服務端的構架模型，通過一個可靠的鏈接在交換訊息，是一個無狀態的請求/回應協議，

一個HTTP“客戶端”是一個應用程式，通過連接到服務器達到向服務器發送一個HTTP或多個HTTP的請求的目的，

一個HTTP“服務器”同樣也是一個應用程式，通過接收客戶端的請求并向客戶端發送HTTP回應資料，

HTTP使用統一資源識別符號來傳輸資料和建立連接，一旦建立連接后，資料訊息就通過類似Internet郵件所使用的格式和多用途Internet郵件擴展來傳送，

客戶端請求訊息

客戶端發送一個HTTP請求到服務器的請求訊息包括以下格式：請求行、請求頭部、空行、請求資料

請求報文的一般格式如下圖所示：

服務器回應訊息

HTTP回應也由四個部分組成：狀態行、訊息報頭、空行、回應正文

HTTP協議的8種請求型別

OPTIONS:

回傳服務器針對特定資源所支持的HTTP請求方法，也可以利用向Web服務器發送請求來測驗服務器的功能性，允許客戶端查看服務器性能，

HEAD:

向服務器索要與GET請求相一致的回應，只不過回應體將不會被回傳，這一方法可以在不必傳輸整個回應內容的情況下，就可以獲取包含在回應訊息頭中的源資訊，（類似于GET請求，只不過回傳的回應中沒有具體的內容，用于獲取報頭，）

GET：

向特定的資源發出請求，即請求指定的頁面資訊，并回傳物體主體，

POST：

向指定資源提交資料進行處理請求（eg:提交表單上或者上傳檔案），資料被包含在請求體中，POST請求可能會導致新的資源的創建或已有資源的修改，

PUT：

向指定資源位置上傳其最新內容，（從客戶端向服務器傳送的資料取代指定的檔案的內容）

DELETE:

請求服務器洗掉Request-URI所標識的資源，（請求服務器洗掉指定的頁面）

TRACE:

回顯服務器收到的請求，主要用于測驗或診斷，

CONNECT：

HTTP/1.1協議中預留給能夠將連接改為管道方式的代理服務器，

注：管道方式：在等待上一個回應的同時，發送下一個請求，

（雖然HTTP的請求方式有8種，但是實際應用種常用的是GET和POST，其他請求方式都可以通過這兩種方式間接來實作，）

HTTP回應頭資訊

HTTP請求頭提供了關于請求，回應或者其他的發送物體的資訊，

應答頭主要有：

Allow：服務器支持哪些請求方法（如GET、POST等），

Content Encoding：檔案的編碼方法，只有在解碼之后才可以得到Content-Type頭指定的內容型別，用gzip壓縮檔案能夠顯著地減少HTML檔案的下載時間，Java的GZIPOutputStream可以很方便地進行gzip壓縮，但只有Unix上的Netscape和Windows上的IE 4、IE 5才支持它，因此，Servlet應該通過查看Accept-Encoding頭（即request.getHeader("Accept-Encoding")）檢查瀏覽器是否支持gzip，為支持gzip的瀏覽器回傳經gzip壓縮的HTML頁面，為其他瀏覽器回傳普通頁面，

Content-Length：表示內容長度，只有當瀏覽器使用持久HTTP連接時才需要這個資料，如果想要利用持久連接的優勢，可以把輸出檔案寫入 ByteArrayOutputStream，完成后查看其大小，然后把該值放入Content-Length頭，最后通過byteArrayStream.writeTo(response.getOutputStream()發送內容，

Content-Type：表示后面的檔案屬于什么MIME型別，

Date：當前的GMT時間，（可以使用setDateHeader來設定這個頭避免轉換時間格式的麻煩）

Expires：應該在什么時候認為檔案過期，從而不再快取它，

Last-Modified：檔案最后改動的時間，

Location：表示客戶應當到哪里去提取檔案，Location通常不是直接設定的，而是通過HttpServletResponse的sendRedirect方法，該方法同時設定狀態代碼為302，

Refresh：表示瀏覽器應該在多久之后重繪檔案，以秒計，除了重繪當前檔案之外，還可以通過setHeader("Refresh", "5; URL=http://host/path")讓瀏覽器讀取指定的頁面，

注：連續重繪要求每次都發送一個Refresh頭，而發送204狀態代碼則可以阻止瀏覽器繼續重繪，

Server：服務器名字（Servlet一般不設定這個值，而是由Web服務器自己設定）

Set-Cookie：設定和頁面關聯的Cookie，

WWW-Authenticate：客戶應該在Authentication頭中提供什么型別的授權資訊？在包含401狀態行的應答中這個頭是必需的，

注：Servlet一般不進行這方面的處理，而是讓Web服務器的專門機制來控制受密碼保護頁面的訪問，

HTTP狀態碼

當瀏覽者訪問一個網頁時，瀏覽者的瀏覽器會向網頁所在的服務器發送請求，當瀏覽器接收并顯示網頁前，此網頁所在的服務器會回傳一個包含HTTP狀態碼的資訊頭用以回應瀏覽器的請求，

常見的HTTP狀態碼

200-請求成功

301-資源（網頁等）被永久轉移到其他URL，（什么時URL：即統一資源定位符，它用來表示互聯網的某個資源地址，互聯網上的每個檔案都有唯一的URL，它包含資訊指出檔案的位置以及瀏覽器應該怎么處理它，）

404-請求的資源（網頁等）不存在，

500-內部服務器錯誤，

GET和POST的區別（前面提到最常用的兩種請求方式是GET和POST，下面對其進行比較）

我們常說的一些區別都是一些表面上的，比如：GET沒有POST安全、GET請求時URL的長度是有限制的、GET沒有body而POST有body等等，這些都是針對瀏覽器中的要求， 在使用HTTP作為介面進行傳輸時，就沒有這么多條條框框了，此時GET和POST只是HTTP協議中的兩種請求方式，而HTTP協議是基于TCP/IP的應用層協議， 無論GET還是POST，用的都是同一個傳輸層協議，所以在傳輸上沒有區別，

因此，在用作為介面進行傳輸時，最大的不同就在于報文格式上的不同了

POST /url HTTP/1.1 \r\n GET /url HTTP/1.1 \r\n

上面所示的分別為POST方法請求的報文第一行和GET請求的報文第一行， 顯而易見的區別就是方法名不同，除此以外，就沒有那么多要求了，GET也可以有body，POST也不一定非要使用body，只要客戶端和服務器端確定好規范即可，至于形式則你們隨意，只不過現在已經習慣了現有的規則，再去改變有些麻煩，畢竟客戶端和服務器端要花時間去探討具體的對接形式，

由于平時大部分見到的都是基于瀏覽器的請求，下面我們再看幾個常見的問題

1. 我們前面說，無論是GET請求還是POST請求，其本質都是不安全的，為什么這樣說呢？如果僅僅從GET請求的引數在地址欄是可見的，POST是不可見的，那就太膚淺了， 由于HTTP自己本身是一個明文協議，每個HTTP請求和回傳的資料在網路上都是明文傳播，無論是url、header還是body， 只要在網路節點捉包，就能獲取完整的資料報文，要防止泄密的唯一手段就是使用HTTPS（用SSL協議協商出的密鑰加密明文HTTP資料），

2. 為什么在瀏覽器中GET請求方式的url長度有限制呢？這是因為瀏覽器要對url進行決議，而決議的時候就要分配記憶體，對于一個位元組流的決議，必須分配buffer來保存所有要存盤的資料，而url這種東西必須當作一個整體看待，無法一塊一塊處理，于是就處理一個請求時必須分配一整塊足夠大的記憶體，如果url太長，而并發又很高，就容易擠爆服務器的記憶體，

3. POST是發送兩個請求嗎？ 上面提到POST請求可以被分為“請求頭”和“請求體”兩個部分，那這兩部分是一起發送出去呢？還是先發“請求頭”，再發“請求體”呢？ 在HTTP協議中并沒有明確說明POST會產生兩個資料包，之所以會發兩個資料包，則是出于以下考慮：如果服務器先收到“請求頭”，則會對其進行校驗，如果校驗通過，則回復客戶端“100 - Continue”，客戶端再把”請求體“發給服務器，如果請求被拒了，服務器就回復個400之類的錯誤，這個互動就終止了，這樣做的優點是可以避免浪費帶寬傳輸請求體，但是代價就是會多一次Round Trip，如果剛好請求體的資料也不多，那么一次性全部發給服務器可能反而更好，所以說，這和POST完全沒有關系，只是基于兩端的一種優化手段罷了，