HTTP
HTTP（Hyper Text Transfer Protocol）超文本傳輸協定，用于網際網路WWW.（World Wide Web）與浏覽器的傳輸協定。（基于TCP/IP通信協定）
HTTP工作原理
http協定工作于用戶端、服務端架構上，用戶端浏覽器通過URL（統一資源定位器，網址）向http服務端（web伺服器）發送所有請求。
web伺服器包括：Nginx、Apache、IIS、Google等。
Web伺服器根據接收到的請求後，向用戶端發送響應資訊。
HTTP預設端口号為80，但是你也可以改為8080或者其他端口。
HTTP三點注意事項
無連接配接：同時處理一個請求，處理完成收到應答後連接配接斷開，節約傳輸的時間。
無狀态：協定對事物的處理無記憶能力，不支援斷點續傳；優點在于不會造成不必要連接配接占用，缺點在于每次請求會傳輸大量重複的内容資訊。
媒體類型： MIME-type内容類型，浏覽器通常使用MIME類型（而不是檔案擴充名）來确定如何處理URL，是以Web伺服器在響應頭中添加正确的MIME類型非常重要。如果配置不正确，浏覽器可能會曲解檔案内容，網站将無法正常工作，并且下載下傳的檔案也會被錯誤處理。
HTTP協定通信流程：
HTTP消息結構
HTTP使用統一資源辨別符URI（Unifrom Resource Identifiers）來傳輸和建立連接配接。
HTTP伺服器（應用程式）通常為一個web服務（Nginx，Apache），通過用戶端發送HTTP相應資料。
HTTP用戶端是一個應用程式（浏覽器等）通過連接配接到伺服器達到向伺服器發送HTTP請求。
HTTP是基于用戶端/服務端（C/S）的架構模型，通過一個可靠的連結來交換資訊，是一個無狀态的請求/響應協定。
用戶端請求消息
用戶端發送一個HTTP請求到伺服器的請求消息包括以下格式：請求行（request line）、請求頭部（header）、空行和請求資料四個部分組成
伺服器響應消息
HTTP伺服器響應也由四個部分組成，分别是：狀态行、消息報頭、空行和響應正文。
HTTP 請求方法
常用： GET,POST,DELETE,PUT
HTTP1.0定義了三種請求方法： GET, POST 和 HEAD方法。
HTTP1.1新增了五種請求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。
GET：單純擷取資料（擷取一個index.html頁面）
POST：上傳/建立檔案（會産生新的資料）
PUT：儲存資料（覆寫/更新檔案、圖檔等，不會産生新的資料）
DELETE：删除
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")讓浏覽器讀取指定的頁面。 注意這種功能通常是通過設定HTML頁面HEAD區的＜META HTTP-EQUIV="Refresh" CONTENT="5;URL=http://host/path"＞實作，這是因為，自動重新整理或重定向對于那些不能使用CGI或Servlet的HTML編寫者十分重要。但是，對于Servlet來說，直接設定Refresh頭更加友善。 注意Refresh的意義是"N秒之後重新整理本頁面或通路指定頁面"，而不是"每隔N秒重新整理本頁面或通路指定頁面"。是以，連續重新整理要求每次都發送一個Refresh頭，而發送204狀态代碼則可以阻止浏覽器繼續重新整理，不管是使用Refresh頭還是＜META HTTP-EQUIV="Refresh" ...＞。 注意Refresh頭不屬于HTTP 1.1正式規範的一部分，而是一個擴充，但Netscape和IE都支援它。 |
| Server | 伺服器名字。Servlet一般不設定這個值，而是由Web伺服器自己設定。 |
| Set-Cookie | 設定和頁面關聯的Cookie。Servlet不應使用response.setHeader("Set-Cookie", ...)，而是應使用HttpServletResponse提供的專用方法addCookie。參見下文有關Cookie設定的讨論。 |
HTTP 狀态碼
常見的HTTP狀态碼：
- 200 - 請求成功
- 301 - 資源（網頁等）被永久轉移到其它URL
- 302 - 資源（網頁等）臨時轉移到其它URL
- 404 - 請求的資源（網頁等）不存在
- 403 - 伺服器了解請求用戶端的請求，但是拒絕執行此請求
- 500 - 内部伺服器錯誤
HTTP狀态碼分類
HTTP狀态碼由三個十進制數字組成，第一個十進制數字定義了狀态碼的類型，後兩個數字沒有分類的作用。HTTP狀态碼共分為5種類型：
HTTP狀态碼清單:
| 狀态碼 | 狀态碼英文名稱 | 中文描述 |
| 100 | Continue | 繼續。用戶端應繼續其請求 |
| 101 | Switching Protocols | 切換協定。伺服器根據用戶端的請求切換協定。隻能切換到更進階的協定，例如，切換到HTTP的新版本協定 |
| 200 | OK | 請求成功。一般用于GET與POST請求 |
| 201 | Created | 已建立。成功請求并建立了新的資源 |
| 202 | Accepted | 已接受。已經接受請求，但未處理完成 |
| 203 | Non-Authoritative Information | 非授權資訊。請求成功。但傳回的meta資訊不在原始的伺服器，而是一個副本 |
| 204 | No Content | 無内容。伺服器成功處理，但未傳回内容。在未更新網頁的情況下，可確定浏覽器繼續顯示目前文檔 |
| 205 | Reset Content | 重置内容。伺服器處理成功，使用者終端（例如：浏覽器）應重置文檔視圖。可通過此傳回碼清除浏覽器的表單域 |
| 206 | Partial Content | 部分内容。伺服器成功處理了部分GET請求 |
| 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請求重定向 |
| 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的請求頭資訊 |
| 500 | Internal Server Error | 伺服器内部錯誤，無法完成請求 |
| 501 | Not Implemented | 伺服器不支援請求的功能，無法完成請求 |
| 502 | Bad Gateway | 作為網關或者代理工作的伺服器嘗試執行請求時，從遠端伺服器接收到了一個無效的響應 |
| 503 | Service Unavailable | 由于超載或系統維護，伺服器暫時的無法處理用戶端的請求。延時的長度可包含在伺服器的Retry-After頭資訊中 |
| 504 | Gateway Time-out | 充當網關或代理的伺服器，未及時從遠端伺服器擷取請求 |
| 505 |