http協議-簡介

一、簡介
超文字傳輸通訊協定 (HTTP)(HTTP，HyperText Transfer Protocol)是互連網上應用最為廣泛的一種網路通訊協定。所有的WWW檔案都必須遵守這個標準。設計HTTP最初的目的是為了提供一種發布和接收HTML頁面的方法。
 超文字傳輸通訊協定 (HTTP)，是一種無狀態協議，就是說用戶端發送一次請求，伺服器端接收請求，經過處理返回給用戶端資訊，然後用戶端和伺服器端的連結就斷開了，為了維護他們之間的連結，讓伺服器知道這是前一個使用者發送的請求，必須在一個地方儲存用戶端的資訊，有2中解決方案，一是在用戶端儲存，二是在伺服器端儲存。
1.在用戶端儲存:Cookie
2.在伺服器端儲存:Session(session需要依靠cookie來實現)
3.在使用者禁用cookie的限制下，只能使用URL重寫的方式在每次請求之後附上一個索引值對來儲存用戶端的資訊。
4.隱藏表單。<input type="hidden" name="method" value="login">
　　HTTP協議的請求訊息和響應訊息有固定的格式
 
　-------------------------要求標頭格式------------------------------------------------------------------
　　HTTP請求行
　　（請求）頭
　　空行
　　可選的訊息體
---------------------------回應標頭格式------------------------------------------------------------------
　　HTTP狀態行
　　（應答）頭
　　空行
　　可選的訊息體
 HTTP 超文字傳輸通訊協定 (HTTP) 人類之所發展得如此快，就是因為有自己的語言
       1、所謂超文本：即純文字語言，不依賴於任何特定語言，任何語言都可以操作它(如java、c++)
       2、傳入：HTTP的應用價值在於傳輸
       3、HTTP是無狀態協議
        基於請求/響應模型
        伺服器和用戶端的互動僅限於請求/響應過程，結束之後便斷開，在下一次請求伺服器會認為新的用戶端

二、 HTTP請求
HTTP請求資訊(瀏覽器資訊)

　HTTP協議的請求和響應都有一定的規則，這篇網站當中首先著重介紹一下HTTP協議的請求協議的內容。
　HTTP協議的請求主要由一下幾部分組成：請求行，要求標頭，請求體（post）
 
　　　　請求行\r\n

　　　　要求標頭1\r\n

　　　　要求標頭1\r\n

　　　　...

　　　　\r\n

　　　　請求體（Post方式）\r\n
　　我們分別按塊來說明一下訊息請求的格式。
 
  1、請求行：GET/POST(流的組織(請求)方式) URL(地址+目錄) 版本號碼
　　首先來說一下請求行，請求行主要由三部分組成，要求方法，請求路徑，請求協議
　　要求方法：HTTP規範定義了8種可能的要求方法：
GET            檢索URI中標識資源的一個簡單請求

HEAD           與GET方法相同，伺服器只返回狀態行和頭標，並不返回請求文檔

POST           伺服器接受被寫入用戶端輸出資料流中的資料的請求

PUT            伺服器儲存請求資料作為指定URI新內容的請求

DELETE         伺服器刪除URI中命名的資源的請求

OPTIONS        關於伺服器支援的要求方法資訊的請求

TRACE          Web伺服器反饋Http請求和其頭標的請求

CONNECT        已文檔化但當前未實現的一個方法，預留做隧道處理
當然我們最常用的也就是get和post方法，get方法的請求方式比較簡單，所有請求的參數都顯示追加在請求的url後面，而且請求長度有限制，post方式的請求參數都追加在請求體當中，訊息長度沒有限制而且以隱式的方式進行發送，安全性相對較高（這個安全性對於現在的網路技術也沒有什麼可安全的了，^_^）。
 
　　請求路徑：請求路徑可以是相對或者絕對的方式，絕對路徑不去闡述，相對路徑是相對於當前TCP串連的主機的路徑（HTTP/1.0方式），在HTTP/1.1方式當中相對於的是要求標頭當中的host域，HTTP/1.1的新特性會在以後的方式當中進行闡述
　　請求協議：目前常用的支援HTTP/1.0和HTTP/1.1方式，HTTP/1.1和HTTP/1.0之間存在不少差異性，後面的部落格當中會專門去討論兩者之間的異同，以及效能差異。
 
 2、要求標頭：Host:用戶端IP和連接埠
         User-Agent:瀏覽器資訊
         Accept：用戶端能接收的資料類型
         Accept-encoding：是否支援壓縮的流
         Accept-charset：用戶端字元編碼集

 
　　要求標頭都是以key:value形式進行儲存的，裡面記錄了用戶端的一些基本資料，常用的要求標頭如下所示
 
Accept：瀏覽器可接受的MIME類型。

Accept-Charset：瀏覽器可接受的字元集。

Accept-Encoding：瀏覽器能夠進行解碼的資料編碼方式，比如gzip。Servlet能夠向支援gzip的瀏覽器返回經gzip編碼的HTML頁面。許多情形下這可以減少5到10倍的下載時間。

Accept-Language：瀏覽器所希望的語言種類，當伺服器能夠提供一種以上的語言版本時要用到。

Authorization：授權資訊，通常出現在對伺服器發送的WWW-Authenticate頭的應答中。

Connection：表示是否需要持久串連。如果Servlet看到這裡的值為“Keep-Alive”，

            或者看到請求使用的是HTTP 1.1（HTTP 1.1預設進行持久串連），它就可以利用持久串連的優點，

            當頁麵包含多個元素時（例如Applet，圖片），顯著地減少下載所需要的時間。要實現這一點，

            Servlet需要在應答中發送一個Content-Length頭，最簡單的實現方法是：先把內容寫入

            ByteArrayOutputStream，然後在正式寫出內容之前計算它的大小。

Content-Length：表示請求訊息本文的長度。

Cookie：這是最重要的要求標頭資訊之一，參見後面《Cookie處理》一章中的討論。

From：請求寄件者的email地址，由一些特殊的Web客戶程式使用，瀏覽器不會用到它。

Host：初始URL中的主機和連接埠。

If-Modified-Since：只有當所請求的內容在指定的日期之後又經過修改才返回它，

                   否則返回304“Not Modified”應答。

Pragma：指定“no-cache”值表示伺服器必須返回一個重新整理後的文檔，即使它是Proxy 伺服器而且已經有了頁面的

       本地拷貝。

Referer：包含一個URL，使用者從該URL代表的頁面出發訪問當前請求的頁面。

User-Agent：瀏覽器類型，如果Servlet返回的內容與瀏覽器類型有關則該值非常有用。

UA-Pixels，UA-Color，UA-OS，UA-CPU：由某些版本的IE瀏覽器所發送的非標準的要求標頭，表示螢幕大小、色彩深度、作業系統和CPU類型。
如果想瞭解更詳細的要求標頭資訊可以去w3c的官網去查閱
 
 
3、請求體
 
　　請求體（又叫請求本文）是post請求方式當中的請求參數，以key=value形式進行儲存，多個請求參數之間用&串連，如果請求當中有請求提，那麼在要求標頭當中的Content-Length屬性中記錄的是該請求體的長度。
　　下面來看一個還算完整的請求訊息吧，這樣可能會稍微直觀一點
 
POST hysj.jsp HTTP/1.1

Host: search.cnipr.com

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; zh-CN; rv:1.9.1.13) Gecko/20100914 Firefox/3.5.13 ( .NET CLR 3.5.30729)

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Accept-Language: zh-cn,zh;q=0.5

Accept-Encoding: gzip,deflate

Accept-Charset: GB2312,utf-8;q=0.7,*;q=0.7

Keep-Alive: 300

Connection: keep-alive

Referer: http://search.cnipr.com/cnipr/zljs/hyjs-biaodan-y.jsp

Content-Length: 405

username=guest&extension=&issearch=on&searchword=pd%3D%2820100901%29&presearchword=&sortfield=RELEVANCE&sRecordNumber=&searchType=0&searchFrom=0&channelid=14%2C15%2C16&searchChannel=14%2C15%2C16&strdb=14&strdb=15&strdb=16&cizi=2&sortcolumn=RELEVANCE&R1=-&txtA=&txtB=&txtC=&txtD=20100901&txtE=&txtF=&txtG=&txtH=&txtI=&txtJ=&txtK=&txtL=&txtM=&txtN=&txtP=&txtQ=&txtR=&txtSearchWord=&Submit=%BC%EC%A1%A1%CB%F7
 
三、 HTTP響應
HTTP響應資訊(伺服器資訊)
       1、狀態行：HTTP版本  伺服器狀態(比如：404找不到...) 描述資訊
       2、回應標頭
        content-text：伺服器發送資訊的類型
        date：發送時間
        server：伺服器類型
       3、訊息體：伺服器發送給用戶端的頁面內容
 
HTTP響應的格式類似於請求的格式，主要由，響應行，回應標頭，響應體組成，其格式如下所示
 
響應行\r\n
回應標頭\r\n
回應標頭\r\n
...

響應體
　　響應行：識別服務器端對用戶端請求的處理結果，主要由響應狀態資訊，響應狀態代碼，伺服器協議
　　　　HTTP協議：參考要求標頭當中對協議的描述
　　　　HTTP狀態代碼：
 
　　　　100 繼續
　　　　101 封包交換協
　　　　200 OK
　　　　201 被建立
　　　　202 被採納
　　　　203 非授權資訊
　　　　204 無內容
　　　　205 重設內容
　　　　206 部分內容
　　　　300 多選項
　　　　301 永久地傳送
　　　　302 找到
　　　　303 參見其他
　　　　304 未改動
　　　　305 使用代理
　　　　307 暫時重新導向
　　　　400 錯誤請求
　　　　401 未授權
　　　　402 要求付費
　　　　403 禁止
　　　　404 未找到
　　　　405 不允許的方法
　　　　406 不被採納
　　　　407 要求代理授權
　　　　408 請求逾時
　　　　409 衝突
　　　　410 到期的
　　　　411 要求的長度
　　　　412 前提不成立
　　　　413 請求執行個體太大
　　　　414 請求URI太大
　　　　415 不支援的媒體類型
　　　　416 無法滿足的請求範圍
　　　　417 失敗的預期
　　　　500 內部伺服器錯誤
　　　　501 未被使用
　　　　502 網關錯誤
　　　　503 停用服務
　　　　504 網關逾時
　　　　505 HTTP版本未被支援
 
　　響應狀態資訊：參照狀態代碼
 
　　回應標頭：類似於要求標頭的key：value形式，常用回應標頭如下所示
 
Allow 伺服器支援哪些要求方法（如GET、POST等）。

Content-Encoding 文檔的編碼（Encode）方法。只有在解碼之後才可以得到Content-Type頭指定的內容類型。利用gzip壓縮文檔能夠顯著地減少HTML文檔的下載時間。Java的GZIPOutputStream可以很方便地進行gzip壓縮，但只有Unix上的Netscape和Windows上的IE 4、IE 5才支援它。因此，Servlet應該通過查看Accept-Encoding頭（即request.getHeader("Accept-Encoding")）檢查瀏覽器是否支援gzip，為支援gzip的瀏覽器返回經gzip壓縮的HTML頁面，為其他瀏覽器返回普通頁面。

Content-Length 表示內容長度。只有當瀏覽器使用持久HTTP串連時才需要這個資料。如果你想要利用持久串連的優勢，可以把輸出文檔寫入ByteArrayOutputStram，完成後查看其大小，然後把該值放入Content-Length頭，最後通過byteArrayStream.writeTo(response.getOutputStream()發送內容。

Content-Type 表示後面的文檔屬於什麼MIME類型。Servlet預設為text/plain，但通常需要顯式地指定為text/html。由於經常要設定Content-Type，因此HttpServletResponse提供了一個專用的方法setContentTyep。

Date 當前的GMT時間。你可以用setDateHeader來設定這個頭以避免轉換時間格式的麻煩。

Expires 應該在什麼時候認為文檔已經到期，從而不再緩衝它？

Last-Modified 文檔的最後改動時間。客戶可以通過If-Modified-Since要求標頭提供一個日期，該請求將被視為一個條件GET，只有改動時間遲於指定時間的文檔才會返回，否則返回一個304（Not Modified）狀態。Last-Modified也可用setDateHeader方法來設定。

Location 表示客戶應當到哪裡去提取文檔。Location通常不是直接設定的，而是通過HttpServletResponse的sendRedirect方法，該方法同時設定狀態碼為302。

Refresh 表示瀏覽器應該在多少時間之後重新整理文檔，以秒計。除了重新整理當前文檔之外，你還可以通過setHeader("Refresh", "5; URL=http://host/path")讓瀏覽器讀取指定的頁面。 
注意這種功能通常是通過設定HTML頁面HEAD區的＜META HTTP-EQUIV="Refresh" CONTENT="5;URL=http://host/path"＞實現，這是因為，自動重新整理或重新導向對於那些不能使用CGI或Servlet的HTML編寫者十分重要。但是，對於Servlet來說，直接設定Refresh頭更加方便。
注意Refresh的意義是“N秒之後重新整理本頁面或訪問指定頁面”，而不是“每隔N秒重新整理本頁面或訪問指定頁面”。因此，連續重新整理要求每次都發送一個Refresh頭，而發送204狀態碼則可以阻止瀏覽器繼續重新整理，不管是使用Refresh頭還是＜META HTTP-EQUIV="Refresh" ...＞。
注意Refresh頭不屬於HTTP 1.1正式規範的一部分，而是一個擴充，但Netscape和IE都支援它。

Server 伺服器名字。Servlet一般不設定這個值，而是由Web伺服器自己設定。

Set-Cookie 設定和頁面關聯的Cookie。Servlet不應使用response.setHeader("Set-Cookie", ...)，而是應使用HttpServletResponse提供的專用方法addCookie。參見下文有關Cookie設定的討論。

WWW-Authenticate 客戶應該在Authorization頭中提供什麼類型的授權資訊？在包含401（Unauthorized）狀態行的應答中這個頭是必需的。例如，response.setHeader("WWW-Authenticate", "BASIC realm=＼"executives＼"")。
注意Servlet一般不進行這方面的處理，而是讓Web伺服器的專門機制來控制受密碼保護頁面的訪問 
 
 <---------------------------------------------------------------------------------------------------------------------------------->
 
　　響應體也就是網頁的本文內容，一般在回應標頭當中會用Content-Length來明確響應體的長度，便於瀏覽器接收，對於大資料量的本文資訊，也會使用chunked的編碼方式，該編碼方式會在後期進行詳細描述。
 
四、模型
       用戶端-----通過socket建立串連-----伺服器
       用戶端-----請求----->伺服器
       用戶端<-----響應-----伺服器
       用戶端-----斷開-----伺服器
       下一次串連.......