http://www.cnblogs.com/linjiqin/p/3560152.html（轉載）
HTTP通信機制是在一次完整的HTTP通信過程中，Web瀏覽器與Web服務器之間將完成下列7個步驟：
1. 建立TCP連接
在HTTP工作開始之前，Web瀏覽器首先要通過網絡與Web服務器建立連接，該連接是通過TCP來完成的，該協議與IP協議共同構建Internet，即著名的TCP/IP協議族，因此Internet又被稱作是TCP/IP網絡。HTTP是比TCP更高層次的應用層協議，根據規則，只有低層協議建立之後才能進行更高層協議的連接，因此，首先要建立TCP連接，一般TCP連接的端口號是80。
2. Web瀏覽器向Web服務器發送請求命令
一旦建立了TCP連接，Web瀏覽器就會向Web服務器發送請求命令。例如：GET/sample/hello.jsp HTTP/1.1。
3. Web瀏覽器發送請求頭信息
瀏覽器發送其請求命令之後，還要以頭信息的形式向Web服務器發送一些別的信息，之後瀏覽器發送了一空白行來通知服務器，它已經結束了該頭信息的發送。
4. Web服務器應答
客戶機向服務器發出請求後，服務器會客戶機回送應答， HTTP/1.1 200 OK ，應答的第一部分是協議的版本號和應答狀態碼。
5. Web服務器發送應答頭信息
正如客戶端會隨同請求發送關於自身的信息一樣，服務器也會隨同應答向用戶發送關於它自己的數據及被請求的文檔。
6. Web服務器向瀏覽器發送數據
Web服務器向瀏覽器發送頭信息後，它會發送一個空白行來表示頭信息的發送到此爲結束，接着，它就以Content-Type應答頭信息所描述的格式發送用戶所請求的實際數據。
7. Web服務器關閉TCP連接
一般情況下，一旦Web服務器向瀏覽器發送了請求數據，它就要關閉TCP連接，然後如果瀏覽器或者服務器在其頭信息加入了這行代碼：Connection:keep-alive
TCP連接在發送後將仍然保持打開狀態，於是，瀏覽器可以繼續通過相同的連接發送請求。保持連接節省了爲每個請求建立新連接所需的時間，還節約了網絡帶寬。
TCP通過三次握手建立可靠連接，此篇文章對此不做多贅述，這裏主要簡單講講客戶端在發起HTTP請求的時候，發送的數據包裏面有什麼數據，以及請求成功接收WEB服務器的數據包；
這裏通過Fiddler工具抓取手機APP向WEB服務器發送的數據包：
HTTP請求爲http://xg.mediportal.com.cn/health/sms/verify/telephone
當瀏覽器向Web服務器發出請求時，它向服務器傳遞了一個數據塊，也就是請求信息，
HTTP請求信息由3部分組成：
1、請求方法（GET/POST）、URI、協議/版本
2、請求頭(Request Header)
3、請求正文
以上圖做例進行分析：
POST http://xg.mediportal.com.cn/health/sms/verify/telephone HTTP/1.1
User-Agent: DGroupPatient/1.052701.230/Dalvik/2.1.0 (Linux;
U; Android 5.1.1; KIW-AL10 Build/HONORKIW-AL10)
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Host: xg.mediportal.com.cn
Connection: Keep-Alive
Accept-Encoding: gzip
Content-Length: 33
telephone=15527177736&userType=1&
（1）請求方法、URI、協議/版本
請求的第一行是“方法、URL、協議/版本”：
POST http://xg.mediportal.com.cn/health/sms/verify/telephone HTTP/1.1
以上代碼中“POST”代表請求方法，“http://xg.mediportal.com.cn/health/sms/verify/telephone”表示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 |
請求服務器回送收到的請求信息，主要用語測試或診斷 |
在Internet應用中，最常用的方法是GET和POST。最後，協議版本聲明瞭通信過程中使用HTTP的版本。
（2）請求頭(Request Header)
請求頭包含許多有關的客戶端環境和請求正文的有用信息。例如，請求頭可以聲明瀏覽器所用的語言，請求正文的長度等。
User-Agent: DGroupPatient/1.052701.230/Dalvik/2.1.0 (linux;
U; android 5.1.1; KIW-AL10 Build/HONORKIW-AL10) //用戶發送請求的客戶端環境
Content-Type: application/x-www-form-urlencoded; charset=UTF-8 //表單默認的提交數據的格式
Host: xg.mediportal.com.cn //請求資源的Intenet主機和端口號
Connection: Keep-Alive //持久連接
Accept-Encoding: gzip //瀏覽器能夠進行解碼的數據編碼方式
Content-Length: 33 //請求正文的長度
|
Content-Type |
是返回消息中非常重要的內容，表示後面的文檔屬於什麼MIME類型。Content-Type: [type]/[subtype]; parameter。例如最常見的就是text/html，它的意思是說返回的內容是文本類型，這個文本又是HTML格式的。原則上瀏覽器會根據Content-Type來決定如何顯示返回的消息體內容 |
|
Host |
指定請求資源的Intenet主機和端口號，必須表示請求url的原始服務器或網關的位置。HTTP/1.1請求必須包含主機頭域，否則系統會以400狀態碼返回 |
|
Accept |
瀏覽器可接受的MIME類型 |
|
Accept-Charset |
瀏覽器可接受的字符集 |
|
Accept-Encoding |
瀏覽器能夠進行解碼的數據編碼方式，比如gzip。Servlet能夠向支持gzip的瀏覽器返回經gzip編碼的HTML頁面。許多情形下這可以減少5到10倍的下載時間 |
|
Accept-Language |
瀏覽器所希望的語言種類，當服務器能夠提供一種以上的語言版本時要用到 |
|
Authorization |
授權信息，通常出現在對服務器發送的WWW-Authenticate頭的應答中 |
|
Connection |
表示是否需要持久連接。如果Servlet看到這裏的值爲“Keep- Alive”，或者看到請求使用的是HTTP1.1（HTTP 1.1默認進行持久連接），它就可以利用持久連接的優點，當頁面包含多個元素時（例如Applet，圖片），顯著地減少下載所需要的時間。要實現這一點，Servlet需要在應答中發送一個Content-Length頭，最簡單的實現方法是：先把內容寫入 ByteArrayOutputStream，然後在正式寫出內容之前計算它的大小 |
|
Content-Length |
表示請求消息正文的長度 |
|
Cookie |
這是最重要的請求頭信息之一 |
|
From |
請求發送者的email地址，由一些特殊的Web客戶程序使用，瀏覽器不會用到它 |
|
Host |
初始URL中的主機和端口 |
|
If-Modified-Since |
只有當所請求的內容在指定的日期之後又經過修改才返回它，否則返回304“Not Modified”應答 |
|
Pragma |
指定“no-cache”值表示服務器必須返回一個刷新後的文檔，即使它是代理服務器而且已經有了頁面的本地拷貝 |
|
Referer |
包含一個URL，用戶從該URL代表的頁面出發訪問當前請求的頁面 |
|
User-Agent |
瀏覽器類型，如果Servlet返回的內容與瀏覽器類型有關則該值非常有用 |
|
UA-Pixels，UA-Color，UA-OS，UA-CPU |
由某些版本的IE瀏覽器所發送的非標準的請求頭，表示屏幕大小、顏色深度、操作系統和CPU類型 |
常見的MIME類型如下：
- text/html ： HTML格式
- text/plain ：純文本格式
- text/xml ： XML格式
- image/gif ：gif圖片格式
- image/jpeg ：jpg圖片格式
- image/png：png圖片格式
以application開頭的媒體格式類型：
- application/xhtml+xml ：XHTML格式
- application/xml ： XML數據格式
- application/atom+xml ：Atom XML聚合格式
- application/json ： JSON數據格式
- application/pdf ：pdf格式
- application/msword ： Word文檔格式
- application/octet-stream ： 二進制流數據（如常見的文件下載）
- application/x-www-form-urlencoded ： <form encType=””>中默認的encType，form表單數據被編碼爲key/value格式發送到服務器（表單默認的提交數據的格式）
另外一種常見的媒體格式是上傳文件之時使用的：
- multipart/form-data ： 需要在表單中進行文件上傳時，就需要使用該格式
（3）請求正文
請求頭和請求正文之間是一個空行，這個行非常重要，它表示請求頭已經結束，接下來的是請求正文。請求正文中可以包含客戶提交的查詢字符串信息：
telephone=15527177736&userType=1&
http響應格式
HTTP應答與HTTP請求相似，HTTP響應也由3個部分構成，分別是：
1、狀態行
2、響應頭(Response Header)
3、響應正文
HTTP/1.1 200 OK //狀態行
Server: nginx
Date: Tue, 31 May 2016 02:09:24 GMT
Content-Type: application/json;charset=UTF-8
Connection: keep-alive
Vary: Accept-Encoding
Access-Control-Allow-Origin: *
Access-Control-Allow-Headers: X-Requested-With,access_token,access-token,content-type,multipart/form-data,application/x-www-form-urlencoded
Access-Control-Allow-Methods: GET,POST,OPTIONS
Content-Length: 49
{"resultCode":1,"resultMsg":"手機號未註冊"} //正文
（1）狀態行
由協議版本、數字形式的狀態代碼、及相應的狀態描述，各元素之間以空格分隔。
狀態代碼：
狀態代碼由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 服務器當前不能夠處理客戶端的請求，在一段時間之後，服務器可能會恢復正常
（2）響應頭
響應頭可能包括：
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);