/**
*@ author StormMaybin
*@ date 2016-10-11
*/

生命不息，奮鬥不止！

開始之前

Http無狀態性

HTTP 協議是無狀態的(stateless)。也就是說，同一個客戶端第二次訪問同一個伺服器上的頁面時，伺服器無法知道這個客戶端曾經訪問過，伺服器也無法分辨不同的客戶端。HTTP 的無狀態特性簡化了伺服器的設計，使伺服器更容易支援大量併發的HTTP 請求。

Http持久連線

HTTP1.0 使用的是非持久連線，主要缺點是客戶端必須為每一個待請求的物件建立並維護一個新的連線，即每請求一個文件就要有兩倍RTT 的開銷。因為同一個頁面可能存在多個物件，所以非持久連線可能使一個頁面的下載變得十分緩慢，而且這種短連線增加了網路傳輸的負擔。HTTP1.1 使用持久連線keepalive，所謂持久連線，就是伺服器在傳送響應後仍然在一段時間內保持這條連線，允許在同一個連線中存在多次資料請求和響應，即在持久連線情況下，伺服器在傳送完響應後並不關閉TCP 連線，而客戶端可以通過這個連線繼續請求其他物件。

域名解析

首先假如我們在瀏覽器位址列中輸入http://www.baidu.com。瀏覽器根據域名解析IP地址：

1. 瀏覽器快取：瀏覽器會快取DNS記錄一段時間。 但作業系統沒有告訴瀏覽器儲存DNS記錄的時間，這樣不同瀏覽器會儲存個自固定的一個時間（2分鐘到30分鐘不等）。
2. 系統快取：如果在瀏覽器快取裡沒有找到需要的域名，瀏覽器會做一個系統呼叫（windows裡是gethostbyname），這樣便可獲得系統快取中的記錄。
3. 路由器快取：如果系統快取也沒找到需要的域名，則會向路由器傳送查詢請求，它一般會有自己的DNS快取。
4. ISP DNS快取：如果依然沒找到需要的域名，則最後要查的就是ISP快取DNS的伺服器。在這裡一般都能找到相應的快取記錄。

域名解析流程：

或者

正文

當瀏覽器向Web伺服器發出請求時，它向伺服器傳遞了一個數據塊，也就是請求資訊，HTTP請求資訊由3部分組成：

l 請求方法URI協議/版本

l 請求頭(Request Header)

l 請求正文

下面是一個HTTP請求的例子：
GET/sample.jsp HTTP/1.1

Accept:image/gif.image/jpeg /

Accept-Language:zh-cn

Connection:Keep-Alive

Host:localhost

User-Agent:Mozila/4.0(compatible;MSIE5.01;Window NT5.0)

Accept-Encoding:gzip,deflate

username=admin&password=123456
（1）請求方法URI協議/版本

請求的第一行是“方法URL議/版本”：GET/sample.jsp HTTP/1.1

以上程式碼中“GET”代表請求方法，“/sample.jsp”表示URI，“HTTP/1.1代表協議和協議的版本。

根據HTTP標準，HTTP請求可以使用多種請求方法。例如：HTTP1.1目前支援7種請求方法：GET、POST、HEAD、OPTIONS、PUT、DELETE和TARCE。
GET 請求獲取由Request-URI所標識的資源。
POST 在Request-URI所標識的資源後附加新的資料。
HEAD 請求獲取由Request-URI所標識的資源的響應訊息報頭。

OPTIONS 請求查詢伺服器的效能，或查詢與資源相關的選項和需求。
PUT 請求伺服器儲存一個資源，並用Request-URI作為其標識。
DELETE 請求伺服器刪除由Request-URI所標識的資源。
TRACE 請求伺服器回送收到的請求資訊，主要用語測試或診斷。
（2）請求頭(Request Header)

請求頭包含許多有關的客戶端環境和請求正文的有用資訊。例如，請求頭可以宣告瀏覽器所用的語言，請求正文的長度等。

Accept:image/gif.image/jpeg./

Accept-Language:zh-cn

Connection:Keep-Alive

Host:localhost

User-Agent:Mozila/4.0(compatible:MSIE5.01:Windows NT5.0)

Accept-Encoding:gzip,deflate.

（3）請求正文

請求頭和請求正文之間是一個空行，這個行非常重要，它表示請求頭已經結束，接下來的是請求正文。請求正文中可以包含客戶提交的查詢字串資訊：

username=jinqiao&password=1234

在以上的例子的HTTP請求中，請求的正文只有一行內容。當然，在實際應用中，HTTP請求正文可以包含更多的內容。

HTTP請求方法我這裡只討論GET方法與POST方法

l GET方法

GET方法是預設的HTTP請求方法，我們日常用GET方法來提交表單資料，然而用GET方法提交的表單資料只經過了簡單的編碼，同時它將作為URL的一部分向Web伺服器傳送，因此，如果使用GET方法來提交表單資料就存在著安全隱患上。例如

從上面的URL請求中，很容易就可以辯認出表單提交的內容。（？之後的內容）另外由於GET方法提交的資料是作為URL請求的一部分所以提交的資料量不能太大

l POST方法

POST方法是GET方法的一個替代方法，它主要是向Web伺服器提交表單資料，尤其是大批量的資料。POST方法克服了GET方法的一些缺點。通過POST方法提交表單資料時，資料不是作為URL請求的一部分而是作為標準資料傳送給Web伺服器，這就克服了GET方法中的資訊無法保密和資料量太小的缺點。因此，出於安全的考慮以及對使用者隱私的尊重，通常表單提交時採用POST方法。

　　從程式設計的角度來講，如果使用者通過GET方法提交資料，則資料存放在QUERY＿STRING環境變數中，而POST方法提交的資料則可以從標準輸入流中獲取。

http響應格式

HTTP應答與HTTP請求相似，HTTP響應也由3個部分構成，分別是：

l 　狀態行

l 　響應頭(Response Header)

l 　響應正文

在接收和解釋請求訊息後，伺服器會返回一個HTTP響應訊息。

狀態行由協議版本、數字形式的狀態程式碼、及相應的狀態描述，各元素之間以空格分隔。

格式: HTTP-Version Status-Code Reason-Phrase CRLF

例如: HTTP/1.1 200 OK \r\n

狀態程式碼：

狀態程式碼由3位數字組成，表示請求是否被理解或被滿足。

狀態描述：

狀態描述給出了關於狀態程式碼的簡短的文字描述。

狀態程式碼的第一個數字定義了響應的類別，後面兩位沒有具體的分類。

第一個數字有五種可能的取值：

• 1xx: 指示資訊—表示請求已接收，繼續處理。

• 2xx: 成功—表示請求已經被成功接收、理解、接受。

• 3xx: 重定向—要完成請求必須進行更進一步的操作。

• 4xx: 客戶端錯誤—請求有語法錯誤或請求無法實現。

• 5xx: 伺服器端錯誤—伺服器未能實現合法的請求。

狀態程式碼 狀態描述 說明

200 OK 客戶端請求成功

400 Bad Request 由於客戶端請求有語法錯誤，不能被伺服器所理解。

401 Unauthonzed 請求未經授權。這個狀態程式碼必須和WWW-Authenticate報頭域一起使用

403 Forbidden 伺服器收到請求，但是拒絕提供服務。伺服器通常會在響應正文中給出不提供服務的原因

404 Not Found 請求的資源不存在，例如，輸入了錯誤的URL。

500 Internal Server Error 伺服器發生不可預期的錯誤，導致無法完成客戶端的請求。

503 Service Unavailable 伺服器當前不能夠處理客戶端的請求，在一段時間之後，伺服器可能會恢復正常。

響應頭

響應頭可能包括：

Location：

Location響應報頭域用於重定向接受者到一個新的位置。例如：客戶端所請求的頁面已不存在原先的位置，為了讓客戶端重定向到這個頁面新的位置，服務 器端可以發回Location響應報頭後使用重定向語句，讓客戶端去訪問新的域名所對應的伺服器上的資源。當我們在JSP中使用重定向語句的時候，伺服器 端向客戶端發回的響應報頭中，就會有Location響應報頭域。

Server：

Server響應報頭域包含了伺服器用來處理請求的軟體資訊。它和User-Agent請求報頭域是相對應的，前者傳送伺服器端軟體的資訊，後者傳送客戶 端軟體(瀏覽器)和作業系統的資訊。下面是Server響應報頭域的一個例子：Server: Apache-Coyote/1.1

WWW-Authenticate：

WWW-Authenticate響應報頭域必須被包含在401(未授權的)響應訊息中，這個報頭域和前面講到的Authorization請求報頭域是 相關的，當客戶端收到401響應訊息，就要決定是否請求伺服器對其進行驗證。如果要求伺服器對其進行驗證，就可以傳送一個包含了 Authorization報頭域的請求，下面是WWW-Authenticate響應報頭域的一個例子：WWW-Authenticate: Basic realm=”Basic Auth Test!”

從這個響應報頭域，可以知道伺服器端對我們所請求的資源採用的是基本驗證機制。

Content-Encoding：

Content-Encoding實體報頭域被使用作媒體型別的修飾符，它的值指示了已經被應用到實體正文的附加內容編碼，因而要獲得Content- Type報頭域中所引用的媒體型別，必須採用相應的解碼機制。Content-Encoding主要用語記錄文件的壓縮方法，下面是它的一個例子： Content-Encoding: gzip。如果一個實體正文采用了編碼方式儲存，在使用之前就必須進行解碼。

Content-Language：

Content-Language實體報頭域描述了資源所用的自然語言。Content-Language允許使用者遵照自身的首選語言來識別和區分實體。 如果這個實體內容僅僅打算提供給丹麥的閱讀者，那麼可以按照如下的方式設定這個實體報頭域：Content-Language: da。

如果沒有指定Content-Language報頭域，那麼實體內容將提供給所以語言的閱讀者。

Content-Length：

Content-Length實體報頭域用於指明正文的長度，以位元組方式儲存的十進位制數字來表示，也就是一個數字字元佔一個位元組，用其對應的ASCII碼儲存傳輸。

   要注意的是：這個長度僅僅是表示實體正文的長度，沒有包括實體報頭的長度。

Content-Type

 Content-Type實體報頭域用語指明發送給接收者的實體正文的媒體型別。例如：

Content-Type: text/html;charset=ISO-8859-1

Content-Type: text/html;charset=GB2312

Last-Modified

 Last-Modified實體報頭域用於指示資源最後的修改日期及時間。

Expires

 Expires實體報頭域給出響應過期的日期和時間。通常，代理伺服器或瀏覽器會快取一些頁面。當用戶再次訪問這些頁面時，直接從快取中載入並顯示給用 戶，這樣縮短了響應的時間，減少伺服器的負載。為了讓代理伺服器或瀏覽器在一段時間後更新頁面，我們可以使用Expires實體報頭域指定頁面過期的時 間。當用戶又一次訪問頁面時，如果Expires報頭域給出的日期和時間比Date普通報頭域給出的日期和時間要早(或相同)，那麼代理伺服器或瀏覽器就 不會再使用快取的頁面而是從伺服器上請求更新的頁面。不過要注意，即使頁面過期了，也並不意味著伺服器上的原始資源在此時間之前或之後發生了改變。

  Expires實體報頭域使用的日期和時間必須是RFC 1123中的日期格式，例如：

Expires: Thu, 15 Sep 2005 16:00:00 GMT

   HTTP1.1的客戶端和快取必須將其他非法的日期格式(也包括0)看作已過期。例如，為了讓瀏覽器不要快取頁面，我們也可以利用Expires實體報頭 域，設定它的值為0，如下(JSP)：response.setDateHeader("Expires",0); 

下面是一個HTTP響應的例子：

HTTP/1.1 200 OK

Server:Apache Tomcat/5.0.12

Date:Mon,6Oct2003 13:23:42 GMT

Content-Length:112