http協議簡介

一、簡介
超文本傳輸協議(HTTP,HyperText Transfer Protocol)是互聯網上應用最爲廣泛的一種網絡協議。所有的WWW文件都必須遵守這個標準。設計HTTP最初的目的是爲了提供一種發佈和接收HTML頁面的方法。
 超文本傳輸協議,是一種無狀態協議,就是說客戶端發送一次請求,服務器端接收請求,經過處理返回給客戶端信息,然後客戶端和服務器端的鏈接就斷開了,爲了維護他們之間的鏈接,讓服務器知道這是前一個用戶發送的請求,必須在一個地方保存客戶端的信息,有2中解決方案,一是在客戶端保存,二是在服務器端保存。
1.在客戶端保存:Cookie
2.在服務器端保存:Session(session需要依靠cookie來實現)
3.在用戶禁用cookie的限制下,只能使用URL重寫的方式在每次請求之後附上一個鍵值對來保存客戶端的信息。
4.隱藏表單。<input type="hidden" name="method" value="login">
  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”值表示服務器必須返回一個刷新後的文檔,即使它是代理服務器而且已經有了頁面的

       本地拷貝。

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建立連接-----服務器
       客戶端-----請求----->服務器
       客戶端<-----響應-----服務器
       客戶端-----斷開-----服務器
       下一次連接.......


發佈了0 篇原創文章 · 獲贊 3 · 訪問量 3萬+
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章