1、什么是HTTP協議

超文本傳輸協議(HTTP)是一種通信協議，它允許將超文本標記語言(HTML)文檔從Web服務器傳送到客戶端的瀏覽器。

2、Web服務器，瀏覽器，代理服務器

當我們打開瀏覽器，在地址欄中輸入URL，然后我們就看到了網頁。 原理是怎樣的呢？
　　實際上我們輸入URL后，我們的瀏覽器給Web服務器發送了一個Request, Web服務器接到Request后進行處理，生成相應的Response，然后發送給瀏覽器， 瀏覽器解析Response中的HTML,這樣我們就看到了網頁，過程如下圖所示

屏幕快照 2017-10-31 10.48.33.png

我們的Request 有可能是經過了代理服務器，最后才到達Web服務器的。

屏幕快照 2017-10-31 10.48.51.png

代理服務器就是網絡信息的中轉站，有什么功能呢？
　1. 提高訪問速度， 大多數的代理服務器都有緩存功能。
　2. 突破限制， 也就是翻墻了
　3. 隱藏身份。

3、URL詳解（地址定位符）

URL(Uniform Resource Locator) 地址用于描述一個網絡上的資源， 基本格式如下

schema://host[:port#]/path/.../[;url-params][?query-string][#anchor]
　　scheme               指定低層使用的協議(例如：http, https, ftp)
　　host                  HTTP服務器的IP地址或者域名
　　port#                 HTTP服務器的默認端口是80，這種情況下端口號可以省略。如果使用了別的端口，必須指明，例如 http://www.cnblogs.com:8080/
　　path                   訪問資源的路徑
　　url-params
　　query-string       發送給http服務器的數據
　　anchor-             錨

URL 的一個例子
http://www.mywebsite.com/sj/test;id=8079?name=sviergn&x=true#stuffSchema: http
host: www.mywebsite.com
path: /sj/test
URL params: id=8079
Query String: name=sviergn&x=true
Anchor: stuff

4、HTTP請求報文和HTTP響應報文

HTTP報文是面向文本的，報文中的每一個字段都是一些ASCII碼串，各個字段的長度是不確定的。HTTP有兩類報文：請求報文和響應報文。

4.1HTTP請求報文

HTTP請求報文由3部分組成（請求行+請求頭+請求體）：
下面是一個實際的請求報文：

屏幕快照 2017-10-31 15.27.16.png

① 是請求方法，GET和POST是最常見的HTTP方法，除此以外還包括DELETE、HEAD、OPTIONS、PUT、TRACE。不過，當前的大多數瀏覽器只支持GET和POST，Spring 3.0提供了一個HiddenHttpMethodFilter，允許你通過“_method”的表單參數指定這些特殊的HTTP方法（實際上還是通過POST提交表單）。服務端配置了HiddenHttpMethodFilter后，Spring會根據_method參數指定的值模擬出相應的HTTP方法，這樣，就可以使用這些HTTP方法對處理方法進行映射了。

② 為請求對應的URL地址，它和報文頭的Host屬性組成完整的請求URL，③是協議名稱及版本號。

④ 是HTTP的報文頭，報文頭包含若干個屬性，格式為“屬性名:屬性值”，服務端據此獲取客戶端的信息。

⑤ 是報文體，它將一個頁面表單中的組件值通過param1=value1&param2=value2的鍵值對形式編碼成一個格式化串，它承載多個請求參數的數據。不但報文體可以傳遞請求參數，請求URL也可以通過類似于“/chapter15/user.html? param1=value1&param2=value2”的方式傳遞請求參數。

對照上面的請求報文，我們把它進一步分解，你可以看到一幅更詳細的結構圖：

屏幕快照 2017-10-31 15.28.23.png

常見的HTTP請求報文頭屬性

• Accept
  請求報文可通過一個 Accept
  報文頭屬性告訴服務端 客戶端接受什么類型的響應。
  如下報文頭相當于告訴服務端，俺客戶端能夠接受的響應類型僅為純文本數據啊，你丫別發其它什么圖片啊，視頻啊過來，那樣我會歇菜的~~~：
  Accept:text/plain

Accept屬性的值可以為一個或多個MIME類型的值，關于MIME類型，大家請參考：http://en.wikipedia.org/wiki/MIME_type

• Cookie
  這是第一個要說的，客戶端的Cookie就是通過這個報文頭屬性傳給服務端的哦！如下所示：
  Cookie:skin=blue; jsessionid=5F4771183629C9834F8382E23BE13C4C

注意到后臺的那個 jsessionid=5F4771183629C9834F8382E23BE13C4C
沒有，服務端是怎么知道客戶端的多個請求是屬于一個Session的，原來就是通過HTTP請求報文頭的Cookie屬性的jsessionid的值關聯起來的！（當然也可以通過重寫URL的方式將會話ID附帶在每個URL的后后面哦）。

• Referer
  表示這個請求是從哪個URL過來的，假如你通過google搜索出一個商家的廣告頁面，你對這個廣告頁面感興趣，鼠標一點發送一個請求報文到商家的網站，這個請求報文的Referer報文頭屬性值就是 http://www.google.com。
  很多貌似神奇的網頁監控軟件（如著名的 我要啦），只要在你的網頁上放上一段JavaScript，就可以幫你監控流量，全國訪問客戶的分布情況等報表和圖表，其原理就是通過這個Referer及其它一些HTTP報文頭工作的。
• Cache-Control
  對緩存進行控制，如一個請求希望響應返回的內容在客戶端要被緩存一年，或不希望被緩存就可以通過這個報文頭達到目的。
  如以下設置，相當于讓服務端將對應請求返回的響應內容不要在客戶端緩存（當然響應報文也是通過響應報文頭通知瀏覽器客戶端的，這個下面再說）：
  Cache-Control: no-cache

其它報文頭屬性
參見：http://en.wikipedia.org/wiki/List_of_HTTP_header_fields

如何訪問請求報文頭

由于請求報文頭是客戶端發過來的，服務端當然只能讀取了，以下是 HttpServletRequest
一些用于讀取請求報文頭的API：
//獲取請求報文中的屬性名稱java.util.Enumeration<java.lang.String> getHeaderNames();//獲取指定名稱的報文頭屬性的值java.lang.String getHeader(java.lang.String name)

由于一些請求報文頭屬性“太著名”了，因此HttpServletRequest為它們提供了VIP的API：
//獲取報文頭中的Cookie(讀取Cookie的報文頭屬性） Cookie[] getCookies() ;//獲取客戶端本地化信息（讀取 Accept-Language 的報文頭屬性）java.util.Locale getLocale() //獲取請求報文體的長度（讀取Content-Length的報文頭屬性）int getContentLength();

HttpServletRequest可以通過 HttpSession getSession()

獲取請求所關聯的HttpSession,其內部的機理是通過讀取請求報文頭中Cookie屬性的JSESSIONID的值，在服務端的一個會話Map中，根據這個JSESSIONID獲取對應的HttpSession的對象。（這樣，你就不會覺得HttpSession很神秘了吧，你自己也可以做一個類似的會話管理）

4.2 HTTP響應報文

響應報文結構

HTTP的響應報文也由三部分組成（響應行+響應頭+響應體）：
以下是一個實際的HTTP響應報文：

屏幕快照 2017-10-31 15.33.18.png

① 報文協議及版本；
② 狀態碼及狀態描述；
③ 響應報文頭，也是由多個屬性組成；
④ 響應報文體，即我們真正要的“干貨”。

響應狀態碼

和請求報文相比，響應報文多了一個“響應狀態碼”，它以“清晰明確”的語言告訴客戶端本次請求的處理結果。

HTTP的響應狀態碼由5段組成：

• 1xx 消息，一般是告訴客戶端，請求已經收到了，正在處理，別急...
• 2xx 處理成功，一般表示：請求收悉、我明白你要的、請求已受理、已經處理完成等信息.
• 3xx 重定向到其它地方。它讓客戶端再發起一個請求以完成整個處理。
• 4xx 處理發生錯誤，責任在客戶端，如客戶端的請求一個不存在的資源，客戶端未被授權，禁止訪問等。
• 5xx 處理發生，責任在服務端，如服務端拋出異常，路由出錯，HTTP版本不支持等。

以下是幾個常見的狀態碼：

• 200 OK
  你最希望看到的，即處理成功！

• 303 See Other
  我把你redirect到其它的頁面，目標的URL通過響應報文頭的Location告訴你。
  悟空：師傅給個桃吧，走了一天了 :relieved:唐僧：我哪有桃啊！去王母娘娘那找吧 :unamused:

• 304 Not Modified
  告訴客戶端，你請求的這個資源至你上次取得后，并沒有更改，你直接用你本地的緩存吧，我很忙哦，你能不能少來煩我啊！

• 404 Not Found
  你最不希望看到的，即找不到頁面。如你在google上找到一個頁面，點擊這個鏈接返回404，表示這個頁面已經被網站刪除了，google那邊的記錄只是美好的回憶。

• 500 Internal Server Error
  看到這個錯誤，你就應該查查服務端的日志了，肯定拋出了一堆異常，別睡了，起來改BUG去吧！
  有些響應碼，Web應用服務器會自動給生成。你可以通過HttpServletResponse的API設置狀態碼：
  //設置狀態碼，狀態碼在HttpServletResponse中通過一系列的常量預定義了，如SC_ACCEPTED，SC_OKvoid setStatus(int sc)

常見的HTTP響應報文頭屬性

• Cache-Control
  響應輸出到客戶端后，服務端通過該報文頭屬告訴客戶端如何控制響應內容的緩存。
  下面，的設置讓客戶端對響應內容緩存3600秒，也即在3600秒內，如果客戶再次訪問該資源，直接從客戶端的緩存中返回內容給客戶，不要再從服務端獲取（當然，這個功能是靠客戶端實現的，服務端只是通過這個屬性提示客戶端“應該這么做”，做不做，還是決定于客戶端，如果是自己宣稱支持HTTP的客戶端，則就應該這樣實現）。
  Cache-Control: max-age=3600

• ETag
  一個代表響應服務端資源（如頁面）版本的報文頭屬性，如果某個服務端資源發生變化了，這個ETag就會相應發生變化。它是Cache-Control的有益補充，可以讓客戶端“更智能”地處理什么時候要從服務端取資源，什么時候可以直接從緩存中返回響應。

• 關于ETag的說明，你可以參見：http://en.wikipedia.org/wiki/HTTP_ETag。Spring 3.0還專門為此提供了一個 org.springframework.web.filter.ShallowEtagHeaderFilter
  （實現原理很簡單，對JSP輸出的內容MD5，這樣內容有變化ETag就相應變化了），用于生成響應的ETag，因為這東東確實可以幫助減少請求和響應的交互。
  下面是一個ETag：
  ETag: "737060cd8c284d8af7ad3082f209582d"

• Location
  我們在JSP中讓頁面Redirect到一個某個A頁面中，其實是讓客戶端再發一個請求到A頁面，這個需要Redirect的A頁面的URL，其實就是通過響應報文頭的Location屬性告知客戶端的，如下的報文頭屬性，將使客戶端redirect到iteye的首頁中：
  Location: https://github.com/biezhi/jb

• Set-Cookie
  服務端可以設置客戶端的Cookie，其原理就是通過這個響應報文頭屬性實現的：
  Set-Cookie: UserID=Jack; Max-Age=3600; Version=1

其它HTTP請求報文頭屬性
更多其它的HTTP請求頭報文，參見：http://en.wikipedia.org/wiki/List_of_HTTP_header_fields

如何寫HTTP請求報文頭

在服務端可以通過HttpServletResponse的API寫響應報文頭的屬性：
//添加一個響應報文頭屬性void setHeader(String name, String value)

像Cookie，Location這些響應頭是有福之人，HttpServletResponse為它們都提供了VIP（非API 哈）：
//添加Cookie報文頭屬性void addCookie(Cookie cookie) //不但會設置Location的響應報文頭，還會生成303的狀態碼呢，兩者天仙配呢void sendRedirect(String location)

摘自：http://www.cnblogs.com/ImBit/p/5513401.html#two.one
http://blog.csdn.net/zhangliang_571/article/details/23508953
https://yq.aliyun.com/articles/44672