http是應用層協議，他要使用下層協議提供的服務，http的連接建立，就是利用傳輸層的 tcp協議來完成的。我們知道tcp是面向連接的協議。一方等待一方發起連接，web服務其連接就是等待的一方，瀏覽器是發起的一方。默認情況下瀏覽器與在web服務器80端口上的監聽程序建立連接，在internet 上http協議基本上都是基于tcp協議的，但是在internet上不排除 http基于其他協議和網絡的http實現方式傳輸。http只是假定傳輸是可靠的。因而任何能夠提供這種保證都是可以使用的。
持續連接(Persistent Connections)
http1.0中，當連接建立后，瀏覽器發送一個請求，服務器回應一個消息，之后，連接就被關閉。當瀏覽器下次請求的時候，需要重新建立連接，很顯然這種需要不斷建立連接的通信方式造成的開銷比較大。早期的web頁面通常只包含html文本，因此即使建立連接的開銷較大，不會有太大的影響，而現在web頁面往往包含多種資源(圖片，動畫，聲音等)，每獲取一種資源就建立一次連接這樣就增加了http服務器的開銷，造成了internet上的信息阻塞。因此在http1.1版中，給出了持續連接的機制，并將其作為http1.1中建立連接的缺省行為。通過這種連接，瀏覽器可以建立一個連接之后 ，發送請求并得到回應，然后繼續發送請求再次得到回應，而其，客戶端還可以發送流水線請求，也就是說，客戶端可以連續發送多個請求，而不用等待每一個響應的到來。
HTTP URL
http url的格式 如下：http://host[":"port][abs_path]
其中http表示要通過http協議來定位網絡資源。host表示合法的internet主機域名或ip地址（以點分十進制的格式表示）。port用于指定一個端口號，擁有被請求資源的服務器主機監聽該端口的tcp連接，如果port是空，或者沒有給出，則使用缺省的端口80。abs_path指定請求資源的url，如果url中沒有給出abs_path那么當它作為請求url時，必須以“/”的形式給出。通常，這個工作瀏覽器就幫我們完成了。我們在瀏覽器的地址欄中輸入www.xx.com然后回車，瀏覽器會默認轉換為http://www.xx.com/.
注: URI區別URL
URI(Uniform Resource Identifier,統一資源標識符)純粹是一個符號結構,用于指定構成web資源的字符串的各個不同部分.
URL是一種特殊的URI,它包含了用于查找某個資源的足夠信息.其它的URI, mailto:zhao@sina.com則不屬于URL,因為它里面不存在 根據該標識符來查找的任何數據.這種URI稱為URN(通用資源名).
HTTP 請求
客戶端通過發送HTTP請求向服務器請求資源的訪問.
HTTP 請求由三部分組成 分別是請求行,消息報頭,請求正文 .
請求行以一個方法符號開頭,后面跟著請求URI 和協議的版本,以CRLF作為結尾,請求行以空格分隔,除了作為結尾的CRLF外,不允許出現單獨的CR或者LF字符.格式如下:
Method Request-URI HTTP-Version CRLF
Method 表示請求的方法,Request-URI是一個統一資源標識符,標識了要請求的資源,HTTP-Version表示請
求的HTTP協議的版本,如：
GET /form.html HTTP/1.1(CRLF).
HTTP請求
| 方法 |
作用 |
| GET |
請求獲取由Request-URI所標識的資源 |
| POST |
在Request-URI所標識的資源后附加新的數據 |
| HEAD |
請求Request-URI所標識的資源響應消息報頭 |
| PUT |
請求服務器存儲一個資源，并用Request-URI作為其標識 |
| DELETE |
請求服務器刪除由Request-URI所標識的資源 |
| TRACE |
請求服務器回送收到的請求信息，主要用于測試或診斷 |
| CONNECT |
保留將來使用。 |
| OPTIONS |
請求查詢服務器的性能，或者查詢與資源相關的選項和需求。 |
注：HTTP協議是區分大小寫的，但是form表單中的get/post是不區分大小寫的。目前http協議中的方法都是大寫的。
GET 方法用于獲取由Request-URI所標識的資源的信息，常見格式：
GET Request-URI HTTP/1.1
當我們通過在瀏覽器的地址欄中直接輸入網址的方式訪問網頁的時候，瀏覽器采用的就是 GET 方法向服務器獲取資源
POST 方法用于向目的服務器發出請求，要求服務器接受附在請求后面的數據。POST方法在表單提交的時候用的較多。
采用POST方法提交表單的例子：
POST/reg.jsp HTTP/1.1(CRLF)
Accept:image/gif,image/x-xbit...........(CRLF)
Host:www.xx.com(CRLF)
Content-Length:22(CRLF)
Connection:Keep-Alive(CRLF)
Cache-Control:no-cache(CRLF)
(CRLF)-----到上面的為消息報頭
username=sss@password=wwww
上面再兩個回車之后就是正文的內容
HEAD方法與GET方法幾乎是一樣的,他們的區別在于HEAD方法只是請求消息報頭,而不是完整的內容.對于HEAD請求的回應部分來說,他的HTTP頭部分中包含的信息與通過GET請求所得到的信息是相同的,利用這個方法,不必傳輸這個資源內容,就可以得到Request-URI所標識的資源信息.這個方法通常被用于測試超連接的有效性,是否可以訪問,以及最近是否更新.
HTTP響應
在接受和解釋請求信息后,服務器會返回一個HTTP響應消息.
與HTTP請求類似,HTTP響應也是由三個部分組成,分別是: 狀態行，消息報頭,響應正文.
狀態行由協議版本,數字形式的狀態代碼,及相應的狀態描述組成,各元素之間一空格分隔,除了結尾的CRLF(回車換行)序列外,不允許出現CR或LF字符.格式如下:
HTTP-Version Status-Code Reason-Phrase CRLF
HTTP-Version 表示服務器HTTP協議的版本,Status-Code表示服務器發回的響應代碼,Reason-Phrase表示狀態代碼的文本描述,CRLF表示回車換行
如 : HTTP/1.1 200 OK (CRLF)
狀態代碼由3位數字組成，表示請求是否被理解或被滿足，狀態描述了給出狀態碼的簡短的文本描述。
狀態代碼的第一個數字定義了響應的類別，后面兩位數字沒有具體的分類。第一個數字有五種可能的取值：
-1XX：指示信息-表示請求已經接收，繼續處理 。
-2XX：成功- 表示請求已經被成功接收、理解、接受。
-3XX：重定向 - 要完成請求必須進行更進一步的操作 。
-4XX：客戶端錯誤 - 請求有語法錯誤或請求無法實現。
-5XX：服務端粗五 - 服務器未能實現合法的請求。
HTTP響應-狀態代碼與狀態描述
狀態代碼 狀態描述 說明
200 ok 客戶端請求成功。
400 bad request 由于客戶端請求有語法錯誤，不能被服務器所理解。
401 unauthorized 請求未經授權。這個狀態代碼必須和www-authenticate報頭域一起使用。
403 forbidden 服務器收到請求，但是拒絕提供服務。服務器通常會在響應中文中給出不提供服務的原因。
404 not found 請求的資源不存在，例如，輸入了錯誤的URL
HTTP 消息
HTTP 消息由客戶端到服務器的請求和服務器到客戶端的響應組成。請求消息和響應消息都是由開始行，
消息報頭（可選的），空行（只有CRLF的行），消息正文（可選的）組成。
對于請求消息，開始行就是請求行，對于響應消息，開始行就是狀態行。
消息報頭
HTTP 消息報頭包括普通報頭，請求報頭，響應報頭，實體報頭。
每一個報頭域都是由名字+":"+空格+值組成，消息報頭域的名字是大小寫無關的。
普通報頭：在普通報頭中，有少數報頭域應用于所有的請求和響應消息，但并不用于被傳輸的實體，這些報頭域只用于傳輸的消息。
cache-Control
Cache-Control 普通報頭域用于指定緩存指令，該指令將被請求/響應鏈中所有的緩存機制所遵循。這些指令將覆蓋缺省的緩存規則。緩存指令是單向的，在請求出現緩存指令，并不意味著在響應中也會出現。此外，在一個消息（請求或響應消息）中指定的緩存指令，并不影響另一個消息的緩沖機制。
注意：Cache-Control普通報頭是在http1.1中新加的，HTTP1.0 使用的類似報頭域為pragma
緩存指令分為請求時的緩存指令和響應時的緩存指令。
請求時的緩存指令包括no-cache,no-store,max-age,max-stale,min-fresh,only-if-cached;
響應時的緩存指令包括public ,private ,no-cache ,no-store,no-transform,must-revalidate,proxy-revalidate,max-age,s-maxage.
其中最常用的是no-cache,用于指示請求或響應消息不能緩存。
例如：為了指示ie瀏覽器（客戶端）不要緩存頁面，服務器端的jsp程序可以編寫下面的代碼：
response.setHeader("Cache-Control","no-cache");
這句代碼將在發送的響應消息中設置普通報頭域：Cache-Control: no-cache
Date
Date普通報頭域表示消息產生的日期和時間，可以用于HTTP響應中，也可以用于HTTP請求中，作為
服務器端，應該總是在所有的響應中包含Date報頭域。作為客戶端只有在發送的消息中包含了消息的正
文的時候，才應該發送Date報頭域，例如：在ＰＯＳＴ請求的時候。
Connection
Connection普通報頭域允許發送者指定連接的選項。例如指定連接是持續的，或者指定“close”選項，通知服務器，在響應完成后，關閉連接。
Accept
Accept請求報頭域用于指定客戶端接受哪些類型的信息。例如：Accept:image/gis,表明客戶端希望
接受gif圖像格式的資源;Accept:text/html,表明客戶端希望接受html文本.
Accept-Charset
Accept-Charset請求報頭域用于指定客戶端接受的字符串.如: Accept-Charset:iso-8859-1,gb2312.如果在請求消息中沒有設置這個域，缺省是任何字符集都可以接受。
Accept-Encoding
Accept-Encoding請求報頭域類似于Accept，但是它是用于指定可以接受的內容編碼。例如：Accept-Encoding:gzip,deflate.如果請求消息中沒有設置這個域，服務器假定客戶端對各種內容編碼都可以接受。
Accept-Language
Accept-Language請求報頭域類似于Accept，但是它是用于指定一種自然語言。例如：Accept-Language:zh-ch.如果請求消息中沒有設置這個域，服務器假定客戶端對各種語言都可以接受。
Authorization
Authorization請求報頭域主要用于證明客戶端有權查看某個資源。當瀏覽器訪問一個頁面時，如果收到服務器響應代碼為401（未授權），可以發送一個包含Authorization請求報頭域的請求，要求服務器對其進行驗證。
Host
Host請求報頭域主要用于指定被請求資源的internet主機和端口號，它通常是HTTP URL中提取出來的
例如：http://www.xx.com/index.html瀏覽器發送的請求消息中，就會包含Host請求報頭域，如下：
Host:www.xx.com
后面沒有跟端口號，表明使用的是缺省端口號80，如果端口號不是80，那么就要在主機后面加上一個冒號（：），然后接上端口號，例如：
Host:www.xx.com:8080
注意: 在發送HTTP請求的時候這個報頭域是必須的.
User-Agent
User-Agent請求報頭域允許客戶端將他的操作系統，瀏覽器和其他屬性告訴服務器，不過這個報頭域不是必須的，如果我們自己編寫一個瀏覽器，不使用User-Agent請求報頭域，那么服務器端就無法識別User-Agent中包含的操作系統等信息。
響應報頭允許服務器傳遞不能放在狀態行中的附加響應信息，以及關于服務器的信息和Request-URI所標
識的資源進行下一步訪問的信息。
Location
Location響應報頭域用于重定向接受者到一個新的位置。例如：客戶端所請求的頁面已不存在原先的位置，為了讓客戶端重定向到這個頁面新的位置，服務器端可以發回Location響應報頭域。這種情況還經常發生在更換域名的時候 ，在舊的域名所對應的服務器上保留一個文件，然后使用重定向語句，讓客戶端去訪問新的域名所對應的服務器上的資源。
Location：http://www.xx.com
Server
Server響應報頭域包了服務器用來處理請求的軟件信息。他和User-Agent請求報頭域是相對應的，前者發送服務器軟件的信息，后者發送客戶端軟件的信息（瀏覽器）和操作系統的信息。
Server：Apache-Coyote/1.1
消息報頭-實體報頭
請求和響應消息都可以傳送一個實體，一個實體由實體報頭域和實體正文組成，在大多數情況下，實體正文就是請求消息中的請求正文或者響應消息中的響應正文。但是在發送時，并不是說實體報頭域和實體正文要在一起發送，例如：有些響應可以包含實體報頭域。實體就好像我們寫的書信，而在信中，我們可以寫上標題，加上頁號等，這部分就相當于 是實體報頭域，而我們所寫的書信的內容，就相當于是實體正文。前面所講的普通報頭，請求報頭和響應報頭我們可以看成寫在信封上的郵編，接收者，發送者等內容。
實體報頭定義了關于實體正文（例如：有無實體正文）和請求所標識的資源的元信息。
常用的實體報頭
Content-Encoding
Content-Encoding實體報頭域被用作媒體類型的修飾符，它的值指示了已經被應用到實體正文的附加內容編碼，因而要獲得Content-Type報頭域中所有引用的媒體類型，必須采用相應的解碼機制。
Content-Encoding主要用于記錄文檔的壓縮方法，下面是它的一個例子：
Content-Encoding：gzip
如果是一個實體正文采用了編碼方式存儲，在使用之前就必須進行解碼。
Content-Language
Content-Languag實體報頭域描述了資源所用的自然語言。Content-Language允許用戶遵照自身的首選語言來識別和區分實體。如果這個實體內容僅僅打算提供給丹麥的閱讀者，那么可以按照如下的方式設置這個實體報頭域：
Content-Language：da
如果沒有指定Content-Language報頭域，那么實體內容提供給所有語言的閱讀者。
Content-Length
Content-Length實體報頭域用于指名實體正文的長度，以字節方式存儲的十進制數據來表示，也就是一個數字字符占一個字節，用其對應的ASCCII碼存儲傳輸。
要注意的是：這個長度僅僅是表示實體正文的長度，沒有包括實體報頭的長度。
Content-Type
Content-Type實體報頭域用于指明發送給接收者的實體正文的媒體類型。例如：
Content-Type: text/html;charset=iso-8859-1
Content-Type: text/html;charset=gbk
Last-Modified
Last-Modified實體報頭域用于指示資源最后的修改日期及時間。
Expires
Expires實體報頭域給出響應過期的日期和時間。通常，代理服務器或瀏覽器會緩存一些頁面，當用戶在次訪問這些頁面時，直接從緩存中加載并顯示給用戶，這樣縮短了響應的時間，減少了服務器的負載。為了讓代理服務器或瀏覽器在一段時間后更新頁面，我們可以使用Expires實體報頭域指定頁面過期的時間。當用戶又一次訪問頁面時，如果Expires報頭給出的時間和時間比Date普通報頭域給出的日期和時間早（或者相同），那么代理服務器或瀏覽器就不會再使用緩存的頁面，而是從服務器上請求新的頁面。不過要注意，即使頁面過期了，也并不意味著服務器上的原始資源在此時間之前或者之后發生了改變。
Expires實體報頭使用的日期和時間必須是RFC 1123中的日期格式，如
Expires:Thu,15 Sep 2008 16:00:00 GMT
HTTP1.1的客戶端和緩存必須將其他非法的日期格式（也包括0）看作已經過期。例如，為了讓瀏覽器不要緩存頁面，我們也可以利用Expires實體報頭域，設置它的值為0，如下：
response.setDateHeader("Expires",0);