## HTTP 簡介
HTTP協議是Hyper Text Transfer Protocol（超文本傳輸協議）的縮寫,是用于從萬維網（WWW：World Wide Web ）服務器傳輸超文本到本地瀏覽器的傳送協議。
HTTP是一個基于TCP/IP通信協議來傳遞數據（HTML 文件, 圖片文件, 查詢結果等）。
## HTTP 工作原理
HTTP協議工作于客戶端-服務端架構上。瀏覽器作為HTTP客戶端通過URL向HTTP服務端即WEB服務器發送所有請求。
Web服務器有：Apache服務器，IIS服務器（Internet Information Services）等。
Web服務器根據接收到的請求后，向客戶端發送響應信息。
HTTP默認端口號為80，但是你也可以改為8080或者其他端口。
**HTTP三點注意事項：**
- HTTP是無連接：
無連接的含義是限制每次連接只處理一個請求。服務器處理完客戶的請求，并收到客戶的應答后，即斷開連接。采用這種方式可以節省傳輸時間。
- HTTP是媒體獨立的：
這意味著，只要客戶端和服務器知道如何處理的數據內容，任何類型的數據都可以通過HTTP發送。客戶端以及服務器指定使用適合的MIME-type內容類型。
- HTTP是無狀態：
HTTP協議是無狀態協議。無狀態是指協議對于事務處理沒有記憶能力。缺少狀態意味著如果后續處理需要前面的信息，則它必須重傳，這樣可能導致每次連接傳送的數據量增大。另一方面，在服務器不需要先前信息時它的應答就較快。
以下圖表展示了HTTP協議通信流程：
## HTTP 消息結構
HTTP是基于客戶端/服務端（C/S）的架構模型，通過一個可靠的鏈接來交換信息，是一個無狀態的請求/響應協議。
一個HTTP"客戶端"是一個應用程序（Web瀏覽器或其他任何客戶端），通過連接到服務器達到向服務器發送一個或多個HTTP的請求的目的。
一個HTTP"服務器"同樣也是一個應用程序（通常是一個Web服務，如Apache Web服務器或IIS服務器等），通過接收客戶端的請求并向客戶端發送HTTP響應數據。
HTTP使用統一資源標識符（Uniform Resource Identifiers, URI）來傳輸數據和建立連接。
一旦建立連接后，數據消息就通過類似Internet郵件所使用的格式[RFC5322]和多用途Internet郵件擴展（MIME）[RFC2045]來傳送。
## 客戶端請求消息
客戶端發送一個HTTP請求到服務器的請求消息包括以下格式：請求行（request line）、請求頭部（header）、空行和請求數據四個部分組成，下圖給出了請求報文的一般格式。
## 服務器響應消息
HTTP響應也由四個部分組成，分別是：狀態行、消息報頭、空行和響應正文。
## HTTP GET實例
下面實例是一點典型的使用GET來傳遞數據的實例：
客戶端請求：
```
GET /hello.txt HTTP/1.1
User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
Host: www.example.com
Accept-Language: en, mi
```
服務端響應:
```
HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Accept-Ranges: bytes
Content-Length: 51
Vary: Accept-Encoding
Content-Type: text/plain
```
輸出結果：
```
Hello World! My payload includes a trailing CRLF.
```
## HTTP 請求方法
根據HTTP標準，HTTP請求可以使用多種請求方法。
HTTP1.0定義了三種請求方法： GET, POST 和 HEAD方法。
HTTP1.1新增了五種請求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。
| 序號 | 方法 | 描述 |
| ------------ | ------------ | ------------ |
| 1 | GET | 請求指定的頁面信息，并返回實體主體。 |
| 2 | HEAD | 類似于get請求，只不過返回的響應中沒有具體的內容，用于獲取報頭 |
| 3 | POST | 向指定資源提交數據進行處理請求（例如提交表單或者上傳文件）。數據被包含在請求體中。POST請求可能會導致新的資源的建立和或已有資源的修改。 |
| 4 | PUT | 從客戶端向服務器傳送的數據取代指定的文檔的內容。 |
| 5 | DELETE | 請求服務器刪除指定的頁面。 |
| 6 | CONNECT | HTTP/1.1協議中預留給能夠將連接改為管道方式的代理服務器。 |
| 7 | OPTIONS | 允許客戶端查看服務器的性能。 |
| 8 | TRACE | 回顯服務器收到的請求，主要用于測試或診斷。 |
## HTTP 響應頭信息
HTTP請求頭提供了關于請求，響應或者其他的發送實體的信息。
| 應答頭 | 說明 |
| ------------ | ------------ |
| Allow | 服務器支持哪些請求方法（如GET、POST等）。 |
| Content-Encoding | 檔的編碼（Encode）方法。只有在解碼之后才可以得到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類型。Servlet默認為text/plain，但通常需要顯式地指定為text/html。由于經常要設置Content-Type，因此HttpServletResponse提供了一個專用的方法setContentType。 |
| Date | 當前的GMT時間。你可以用setDateHeader來設置這個頭以避免轉換時間格式的麻煩。 |
| Expires | 應該在什么時候認為文檔已經過期，從而不再緩存它？ |
| Last-Modified | 文檔的最后改動時間。客戶可以通過If-Modified-Since請求頭提供一個日期，該請求將被視為一個條件GET，只有改動時間遲于指定時間的文檔才會返回，否則返回一個304（Not Modified）狀態。Last-Modified也可用setDateHeader方法來設置。 |
| Location | 表示客戶應當到哪里去提取文檔。Location通常不是直接設置的，而是通過HttpServletResponse的sendRedirect方法，該方法同時設置狀態代碼為302。 |
| Refresh | 表示瀏覽器應該在多少時間之后刷新文檔，以秒計。除了刷新當前文檔之外，你還可以通過setHeader("Refresh", "5; URL=http://host/path ")讓瀏覽器讀取指定的頁面。<br><br> **注意 1：**這種功能通常是通過設置HTML頁面HEAD區的＜META HTTP-EQUIV="Refresh" CONTENT="5;URL=http://host/path "＞實現，這是因為，自動刷新或重定向對于那些不能使用CGI或Servlet的HTML編寫者十分重要。但是，對于Servlet來說，直接設置Refresh頭更加方便。<br><br> **注意 2：**Refresh的意義是"N秒之后刷新本頁面或訪問指定頁面"，而不是"每隔N秒刷新本頁面或訪問指定頁面"。因此，連續刷新要求每次都發送一個Refresh頭，而發送204狀態代碼則可以阻止瀏覽器繼續刷新，不管是使用Refresh頭還是＜META HTTP-EQUIV="Refresh" ...＞。<br><br> **注意 3：**Refresh頭不屬于HTTP 1.1正式規范的一部分，而是一個擴展，但Netscape和IE都支持它。 |
| Server | 服務器名字。Servlet一般不設置這個值，而是由Web服務器自己設置。 |
| Set-Cookie | 設置和頁面關聯的Cookie。Servlet不應使用response.setHeader("Set-Cookie", ...)，而是應使用HttpServletResponse提供的專用方法addCookie。參見下文有關Cookie設置的討論。 |
| WWW-Authenticate | 客戶應該在Authorization頭中提供什么類型的授權信息？在包含401（Unauthorized）狀態行的應答中這個頭是必需的。例如，response.setHeader("WWW-Authenticate", "BASIC realm=＼"executives＼"")。<br><br> **注意：**Servlet一般不進行這方面的處理，而是讓Web服務器的專門機制來控制受密碼保護頁面的訪問（例如.htaccess）。 |
## HTTP 狀態碼
當瀏覽者訪問一個網頁時，瀏覽者的瀏覽器會向網頁所在服務器發出請求。當瀏覽器接收并顯示網頁前，此網頁所在的服務器會返回一個包含HTTP狀態碼的信息頭（server header）用以響應瀏覽器的請求。
HTTP狀態碼的英文為HTTP Status Code。
下面是常見的HTTP狀態碼：
- 200 - 請求成功
- 301 - 資源（網頁等）被永久轉移到其它URL
- 404 - 請求的資源（網頁等）不存在
- 500 - 內部服務器錯誤
## HTTP 狀態碼分類
HTTP狀態碼由三個十進制數字組成，第一個十進制數字定義了狀態碼的類型，后兩個數字沒有分類的作用。HTTP狀態碼共分為5種類型：
| 分類 | 分類描述 |
| ------------ | ------------ |
| 1** | 信息，服務器收到請求，需要請求者繼續執行操作 |
| 2** | 成功，操作被成功接收并處理 |
| 3** | 重定向，需要進一步的操作以完成請求 |
| 4** | 客戶端錯誤，請求包含語法錯誤或無法完成請求 |
| 5** | 服務器錯誤，服務器在處理請求的過程中發生了錯誤 |
## HTTP 狀態碼列表
**1****
| 狀態碼 | 英文名稱 | 中文描述 |
| ------------ | ------------ | ------------ |
| 100 | Continue | 繼續。客戶端應繼續其請求 |
| 101 | Switching Protocols | 切換協議。服務器根據客戶端的請求切換協議。只能切換到更高級的協議，例如，切換到HTTP的新版本協議 |
**2****
| 狀態碼 | 英文名稱 | 中文描述 |
| ------------ | ------------ | ------------ |
| 200 | OK | 請求成功。一般用于GET與POST請求 |
| 201 | Created | 已創建。成功請求并創建了新的資源 |
| 202 | Accepted | 已接受。已經接受請求，但未處理完成 |
| 203 | Non-Authoritative Information | 非授權信息。請求成功。但返回的meta信息不在原始的服務器，而是一個副本 |
| 204 | No Content | 無內容。服務器成功處理，但未返回內容。在未更新網頁的情況下，可確保瀏覽器繼續顯示當前文檔 |
| 205 | Reset Content | 重置內容。服務器處理成功，用戶終端（例如：瀏覽器）應重置文檔視圖。可通過此返回碼清除瀏覽器的表單域 |
| 206 | Partial Content | 部分內容。服務器成功處理了部分GET請求 |
**3****
| 狀態碼 | 英文名稱 | 中文描述 |
| ------------ | ------------ | ------------ |
| 300 | Multiple Choices | 多種選擇。請求的資源可包括多個位置，相應可返回一個資源特征與地址的列表用于用戶終端（例如：瀏覽器）選擇 |
| 301 | Moved Permanently | 永久移動。請求的資源已被永久的移動到新URI，返回信息會包括新的URI，瀏覽器會自動定向到新URI。今后任何新的請求都應使用新的URI代替 |
| 302 | Found | 臨時移動。與301類似。但資源只是臨時被移動。客戶端應繼續使用原有URI |
| 303 | See Other | 查看其它地址。與301類似。使用GET和POST請求查看 |
| 304 | Not Modified | 未修改。所請求的資源未修改，服務器返回此狀態碼時，不會返回任何資源。客戶端通常會緩存訪問過的資源，通過提供一個頭信息指出客戶端希望只返回在指定日期之后修改的資源 |
| 305 | Use Proxy | 使用代理。所請求的資源必須通過代理訪問 |
| 306 | Unused | 已經被廢棄的HTTP狀態碼 |
| 307 | Temporary Redirect | 臨時重定向。與302類似。使用GET請求重定向 |
**4****
| 狀態碼 | 英文名稱 | 中文描述 |
| ------------ | ------------ | ------------ |
| 400 | Bad Request | 客戶端請求的語法錯誤，服務器無法理解 |
| 401 | Unauthorized | 請求要求用戶的身份認證 |
| 402 | Payment Required | 保留，將來使用 |
| 403 | Forbidden | 服務器理解請求客戶端的請求，但是拒絕執行此請求 |
| 404 | Not Found | 服務器無法根據客戶端的請求找到資源（網頁）。通過此代碼，網站設計人員可設置"您所請求的資源無法找到"的個性頁面 |
| 405 | Method Not Allowed | 客戶端請求中的方法被禁止 |
| 406 | Not Acceptable | 服務器無法根據客戶端請求的內容特性完成請求 |
| 407 | Proxy Authentication Required | 請求要求代理的身份認證，與401類似，但請求者應當使用代理進行授權 |
| 408 | Request Time-out | 服務器等待客戶端發送的請求時間過長，超時 |
| 409 | Conflict | 服務器完成客戶端的PUT請求是可能返回此代碼，服務器處理請求時發生了沖突 |
| 410 | Gone | 客戶端請求的資源已經不存在。410不同于404，如果資源以前有現在被永久刪除了可使用410代碼，網站設計人員可通過301代碼指定資源的新位置 |
| 411 | Length Required | 服務器無法處理客戶端發送的不帶Content-Length的請求信息 |
| 412 | Precondition Failed | 客戶端請求信息的先決條件錯誤 |
| 413 | Request Entity Too Large | 由于請求的實體過大，服務器無法處理，因此拒絕請求。為防止客戶端的連續請求，服務器可能會關閉連接。如果只是服務器暫時無法處理，則會包含一個Retry-After的響應信息 |
| 414 | Request-URI Too Large | 請求的URI過長（URI通常為網址），服務器無法處理 |
| 415 | Unsupported Media Type | 服務器無法處理請求附帶的媒體格式 |
| 416 | Requested range not satisfiable | 客戶端請求的范圍無效 |
| 417 | Expectation Failed | 服務器無法滿足Expect的請求頭信息 |
**5****
| 狀態碼 | 英文名稱 | 中文描述 |
| ------------ | ------------ | ------------ |
| 500 | Internal Server Error | 服務器內部錯誤，無法完成請求 |
| 501 | Not Implemented | 服務器不支持請求的功能，無法完成請求 |
| 502 | Bad Gateway | 作為網關或者代理工作的服務器嘗試執行請求時，從遠程服務器接收到了一個無效的響應 |
| 503 | Service Unavailable | 由于超載或系統維護，服務器暫時的無法處理客戶端的請求。延時的長度可包含在服務器的Retry-After頭信息中 |
| 504 | Gateway Time-out | 充當網關或代理的服務器，未及時從遠端服務器獲取請求 |
| 505 | HTTP Version not supported | 服務器不支持請求的HTTP協議的版本，無法完成處理 |
## HTTP content-type
Content-Type，內容類型，一般是指網頁中存在的Content-Type，用于定義網絡文件的類型和網頁的編碼，決定瀏覽器將以什么形式、什么編碼讀取這個文件，這就是經常看到一些Asp網頁點擊的結果卻是下載到的一個文件或一張圖片的原因。
