探索Android軟鍵盤的疑難雜癥 深入探討Android異步精髓Handler 詳解Android主流框架不可或缺的基石 站在源碼的肩膀上全解Scroller工作機制

Android多分辨率適配框架（1）— 核心基礎 Android多分辨率適配框架（2）— 原理剖析 Android多分辨率適配框架（3）— 使用指南

自定義View系列教程00–推翻自己和過往，重學自定義View 自定義View系列教程01–常用工具介紹 自定義View系列教程02–onMeasure源碼詳盡分析 自定義View系列教程03–onLayout源碼詳盡分析 自定義View系列教程04–Draw源碼分析及其實踐 自定義View系列教程05–示例分析 自定義View系列教程06–詳解View的Touch事件處理 自定義View系列教程07–詳解ViewGroup分發Touch事件 自定義View系列教程08–滑動沖突的產生及其處理

版權聲明

在上一篇博客中，我們已經對Servlet有了基礎的簡單的了解，在深入認識Servlet之前，我們來一起學習HTTP協議。

HTTP簡介

HTTP協議(HyperText Transfer PRotocol)又叫作超文本傳輸協議，它是用于從服務器傳輸超文本到瀏覽器的傳送協議。HTTP不僅保證計算機正確、高效、快速地傳輸超文本文檔還可確定傳輸文檔中的哪一部分內容優先顯示。

HTTP是一個應用層協議，一次HTTP通信由請求和響應構成。客戶端向服務器發送一個請求，在該請求中包含：請求的方法、URL、用戶信息、協議版本、等等信息。服務器在接收到請求后發對此作出響應并返回一個答復消息，該消息包括：響應的時間、請求成功或失敗的標識、協議的版本、回復的內容等等信息。

HTTP的特點

標準的HTTP協議是無連接的，無狀態的。無連接指的是：每次連接只處理一個請求。服務器處理完客戶的請求并收到客戶的應答后即斷開連接。無狀態指的是：協議對于請求的處理沒有記憶能力，也就是說每次請求都是獨立的，它的執行結果與之前和之后的請求是無直接關系的

標準HTTP協議既有優點也有缺點：優點在于極大地減輕了服務器的壓力，每一次請求不會造成不必要連接占用；缺點在于繁復地建立連接和斷開連接，請求會傳輸大量重復的信息，所以隨后出現了Keep-Alive、Cookie、session在某些程度上彌補了標準HTTP的缺點。

HTTP的請求與響應

我們知道：每一次HTTP的請求都由請求(request)和響應(response)構成，在此對這兩部分作進一步的說明。

HTTP的請求

HTTP請求由三部分組成：請求消息行、請求消息頭、請求消息體

請求消息行

示例如下：

GET /HelloWeb/test.html HTTP/1.1

請求消息行包含三部分內容：

請求消息頭

示例如下：

Host:localhost Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8 Accept-Charset: UTF-8 Accept-Encoding: gzip, deflate, sdch Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.6 Cache-Control: max-age=0 Cookie:JSESSIONID=97C4302F3350676F65B5E4409ABA87CF Referer: http://blog.csdn.net/lfdfhl Content-Type：application/x-www-form-urlencoded If-Modified-Since: Wed, 02 Feb 2011 12:04:56 GMT User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.130 Safari/537.36 Connection: keep-alive Date: Tue, 15 Nov 2017 01:12:31 GMT

請求消息頭中內容較多，現將常用和重要的字段介紹如下：

Host：發起請求的主機名及其端口號 Accept：客戶端可接收的文檔類型。其中，*/*表示可接收任何類型 Accept-Charset: 客戶端可接受的字符編碼集 Accept-Encoding: 客戶端支持的壓縮格式 Accept-Language：客戶端可接受的語言 Cache-Control：設置請求和響應遵循的緩存機制 Cookie：HTTP請求發送時會把保存在該請求域名下的所有cookie值一起發送至服務器。 Referrer：發起HTTP請求的頁面的URL Content-Type：請求時所傳遞的內容的類型 Content-Length：請求時所傳遞的內容的長度 If-Modified-Since:該值與響應消息頭的Last-Modified字段相對應。Last-Modified與If-Modified-Since都是用來記錄頁面的最后修改時間。當客戶端訪問頁面時，服務器會將頁面最后修改時間通過Last-Modified由服務器發往客戶端，客戶端會記錄下該值；當客戶端再次發起請求時，客戶端會通過 If-Modified-Since將此前服務器端發過來的最后修改時間戳發送回去；服務器通過這個時間戳判斷客戶端的頁面是否是最新的，如果不是最新的則返回新的內容，如果是最新的則返回304告訴客戶端其本地cache的頁面是最新的，于是客戶端就可直接從本地加載頁面。 User-Agent：表示發出該請求的客戶端的相關信息，比如操作系統及版本、CPU類型、瀏覽器及版本、瀏覽器渲染引擎、瀏覽器語言等等 Connection: 表示是否需要持久連接，HTTP 1.1默認進行持久連接。 Date: 請求發送的日期和時間

其實，從這里可以看出來：在每次請求時，客戶端需要告訴服務器：自身支持的字符集，壓縮格式，語言；請求的消息內容，長度等等眾多信息，從而盡量清楚地表達自身的條件和需求以便服務器做出相應的響應。

請求消息體

username=大澤瑪利亞&hobby=攝影

當請求方式是POST方式時可見消息正文，假若是GET方式則請求消息體中無內容

HTTP的響應

HTTP響應由三部分組成：響應消息行、響應消息頭、響應消息體

響應消息行

HTTP/1.1 200 OK

響應消息行由三部分組成：

響應消息頭

Accept-Ranges: bytes Content-Encoding: gzip Content-Length: 4533 Content-Language: en,zh Content-Type: text/html Date: Sun, 06 Sep 2015 07:56:07 GMT Last-Modified: Fri, 04 Sep 2015 13:37:55 GMT Server: apache tomcat Location: http://blog.csdn.net/lfdfhl Refresh: 5; url=http://www.csdn.net/ Content-Disposition: attachment; filename=test.zip Set-Cookie: UserID=tom; Max-Age=3600; Version=1 Expires: Thu, 01 Dec 2015 12:20:00 GMT Cache-Control: no-cache Pragma: no-cache Connection: keep-alive

響應消息頭中內容較多，現將常用和重要的字段介紹如下：

Accept-Ranges: 表明服務器是否支持指定范圍請求及哪種類型的分段請求 Content-Encoding: 服務器的返回內容的壓縮編碼類型 Content-Length: 服務器的返回內容的的長度 Content-Language: 服務器的返回內容的語言 Content-Type: 服務器的返回內容的類型 Date：服務器發出響應的時間 Last-Modified: 返回的內容的最后修改時間 Server: 服務器的類型 Location：指示被請求的資源的位置，常和請求消息頭一起使用完成請求重定向 Refresh：延時跳轉到某個頁面或者定時刷新本頁面 Content-Disposition: 指示客戶端下載文件 Set-Cookie: 服務器端發送給客戶端的Cookie Expires: 響應過期的時間 Cache-Control: 指定響應遵循的緩存機制 Pragma: 用來包含實現特定的指令，最常用的是Pragma:no-cache。在HTTP/1.1協議中，它的含義和Cache-Control:no-cache相同 Connection: 表示是否需要持久連接，HTTP 1.1默認進行持久連接。

響應消息體

響應消息體中表示響應的的具體內容。比如，響應的內容是網頁，那么響應消息體的內容和網頁右鍵”查看網頁源代碼”所看到的內容一樣。

后會有期

在此簡單地介紹了HTTP協議，但也不會如此倉促地完結。我們將在后續的博客中結合Servlet對與HTTP緊密相關的Cookie和Session進行詳細的學習，再會。