HTTP模塊設計

1、超文本協(xié)議模塊方案介紹 HTTP協(xié)議WWW的基礎協(xié)議是HTTP(Hyper Text Transfer Protocol), 它是TCP/IP協(xié)議集中的一個應用層協(xié)議,是基于端對端連接的TCP協(xié)議. 是一種面向分布,協(xié)作的超媒體信息系統(tǒng)的協(xié)議.它具有通用,無狀態(tài),面向對象等特點:l HTTP是一種通用協(xié)議.它所描述的是一種通用的語義和語法結構.因此除了用于WWW,還用于用戶代理(User Agent,通常指瀏覽器等)和通向其他Internet系統(tǒng)的服務代理(Proxy)/網(wǎng)關(Gateway)間的通訊.后者一般連接其他的Internet協(xié)議模塊,如那些基于SMTP,NNTP,FTP, 

2、;Gopher和WAIS的應用系統(tǒng),從而實現(xiàn)各類Internet應用資源超媒體訪問的集成.通過協(xié)議轉換,可以對來自不同應用的資源進行超媒體訪問,以簡化用戶代理的設計和實現(xiàn).l HTTP是一種無狀態(tài)的協(xié)議.通信雙方(客戶和服務器)都不必為互相通信而建立起的TCP連接存儲任何狀態(tài)信息,雙方都可以根據(jù)它們之間交換的消息來確定如何響應.而不必存儲狀態(tài),所以當接收到對方的消息后只要做一個響應便可以不再理它,知道它下一次發(fā)出消息為止,這樣對與服務器而言,可以很容易為多個客戶服務.l 作為一個通用的面向對象的協(xié)議,在HTTP中,資源對資源操作的方法是一起發(fā)送的.通過其請求/應答方法(命令),為許多系統(tǒng)如DN

3、S服務器,分布式對象管理系統(tǒng)所采用.以其簡便快速而成為超媒體信息系統(tǒng)的基本協(xié)議.l 靈活性與內容-類型(content-type)標識 HTTP允許任意類型數(shù)據(jù)的傳送，因此可以利用HTTP傳送任何類型的對象，并讓客戶程序能夠恰當?shù)靥幚硭鼈?，內?類型標識指示了所傳輸數(shù)據(jù)的類型。打個比方，如果數(shù)據(jù)是罐頭，內容-類型標識就是罐頭上的標簽。 HTTP協(xié)議的發(fā)展歷史HTTP作為WWW的支撐協(xié)議始于1990年,最早的HTTP/0.9只是一個簡單的原始數(shù)據(jù)傳輸協(xié)議.經(jīng)過幾年的使用與發(fā)展,如今的WWW中廣泛采用的是HTTP/1.0,即RFC1945.它通過引入類MIME(Multipurpose Inter

4、net Mail Extensions)格式消息,數(shù)據(jù)的元信息表示以及請求/響應語義修師符等改進了HTTP/0.9,但它不能對超媒體信息傳輸所需要的層次代理,緩沖,持續(xù)連接和虛擬主機提供足夠的支持.為此Internet工程部IETF在1996年6月提交了新版的HTTP/1.1草案,它在HTTP/1.0的基礎上增加了對層次代理,緩沖,持續(xù)連接和虛擬逐級的充分支持.以下講解均以HTTP/1.1規(guī)范作為基礎. RFC 2616 (HTTP1.1協(xié)議)的內容目前在Web中采用的HTTP協(xié)議的1.1版,即 RFC2616,它對HTTP協(xié)議的內容進行了詳細規(guī)范的描述,其基本內容包括:(1) 一般語法和標識

5、符約定.其語法使用BNF(RFC822中的擴展巴科斯范式(Augmented Backus-Naur Form,BNF)描述.(2) 協(xié)議參數(shù).包括協(xié)議的版本號,URI,字符集,編碼方式以及媒體類型等.這些參數(shù)主要設在HTTP的請求/應答格式的各種頭標域中.(3) HTTP消息.包括HTTP請求和應答,每種又分為簡單式和完整式.協(xié)議對請求/應答的格式以及各域的相關內容,進行了詳細的說明.這部分是協(xié)議的主要內容.(4) 訪問權限.目前一般僅支持Basic訪問方案,即用戶名/用戶口令方式.(5) 安全考慮.HTTP協(xié)議的工作模式HTTP協(xié)議的實現(xiàn)基于請求/應答模式.它是一種請求/響應協(xié)議.其基本運

6、作方式見下圖. 建立TCP/IP連接客戶->服務器 發(fā)送請求消息客戶->服務器 發(fā)送響應消息客戶<-服務器 關閉連接客戶<-服務器 圖1: HTTP的基本運作過程一個客戶首先于服務器建立一個連接,并向服務器發(fā)送請求服務的消息,服務器收到請求消息后進行相應操作,然后發(fā)出一個響應消息給客戶,最后關閉連接.其中客戶與服務器是一個相對的概念,只存在于某個特定的連接期間,即在某個連接中的客戶在另一個連接中可能作為服務器,這也就是說,對于HTTP中的程序它應具有客戶與服務器的雙重功能.HTTP的服務器還可以使其他類型的網(wǎng)關或服務代理,通過它們HTTP允許超媒體訪問現(xiàn)存的Intern

7、et協(xié)議,如SMTP,NNTP,FTP,Gopher,WAIS等.在Internet上的通訊一般是建立在TCP/IP連接上的,HTTP的連接也不例外,其缺省端口是TCP 80端口,當然其他端口也可以使用.正常的握手過程要求客戶在每一次發(fā)送請求之前建立連接,并由服務器在發(fā)送響應消息后關閉,但客戶和服務器還必須具有處理任意一方因突發(fā)事件(如用戶強制,自動超時或程序失敗等)而發(fā)生關閉連接的能力.在這些情況下,通常不論當前狀態(tài)怎樣都中止當前請求.圖1只是HTTP正常的運作過程,對突發(fā)情況并沒有體現(xiàn).從圖1我們可以看出,當客戶和服務器的一次請求/響應完成后,將斷開它們之間的連接.在WWW服務中,經(jīng)常會碰

8、到這樣的情況:常常要求客戶程序在一段較短時間內向同一服務器發(fā)送多個請求,如WWW頁面中有內插圖表(Inline Image)時.然而,在持續(xù)連接出現(xiàn)之前,每取回一個URL都需要重新建立一個獨立的TCP連接,很顯然,這樣增加了HTTP服務器一端的開銷,并且可能導致網(wǎng)絡阻塞.為了解決這個問題,HTTP/1.1提供了持續(xù)連接功能,持續(xù)連接的好處有:l 減少了TCP連接建立和關閉的次數(shù),從而節(jié)約了CPU時間和TCP協(xié)議控制塊消耗的內存.l 減少了TCP連接建立時所發(fā)送的報文數(shù),并給TCP控制進程足夠的時間已確定網(wǎng)絡的阻塞狀態(tài),從而減少了整個網(wǎng)絡阻塞的發(fā)生次數(shù).l 在一個TCP連接之上就可以實現(xiàn)HTTP

9、請求和相應的流水作業(yè),這意味著程序可以不必等待響應就可以連續(xù)發(fā)出多個請求,減少了系統(tǒng)延遲,提高了單個TCP連接的使用效率.l 沒有關閉TCP連接的負擔就可以報告差錯,從而促進HTTP平穩(wěn)地發(fā)展.未來版本的HTTP客戶可能為了優(yōu)化而采用新的協(xié)議特性,如果這些客戶和舊版本的服務器通信并收到差錯報告,由于有了持續(xù)性連接,就可以在不關閉連接的情況下,采用舊的語義和語法規(guī)范重試. 客戶與服務器建立連接后向服務器發(fā)出一個請求,其請求具有一定的格式.一個請求一般包括這些內容:請求方法,請求資源的 URI和協(xié)議的版本號的請求行;有關請求的其他信息和客戶本身的信息;實體頭和可能的實體內容.服務器應答客戶端發(fā)來的

10、請求,其應答也具有一定的格式.一個應答一般包括這樣的一些內容:HTTP協(xié)議版本號,狀態(tài)代碼和狀態(tài)說明的狀態(tài)行;服務器信息和進一步訪問資源的URI以及WWW權限識別;實體頭和可能的實體內容.決大多數(shù)HTTP通訊是從客戶代理(通常為客戶瀏覽器)發(fā)出對某資源的請求開始的,在最簡單的情況下,這只需在客戶代理和源服務器(存放請求資源的服務器)間建立一條連接即可.當請求/應答鏈路中有中介系統(tǒng)時,情況會復雜一些.一般由三種形式中介系統(tǒng),即代理Proxy,網(wǎng)關Gataway和通道Tunnel.Proxy是客戶端轉發(fā)代理(既是服務器又是客戶).它接受客戶端的請求,必要時重寫部分或全部請求信息,然后將重新格式化的

11、請求轉發(fā)給請求所指的服務器.Gataway是源服務器的接受代理(是服務器).作為其他源服務器的上一層,在必要時,轉換客戶端的請求,以適應下層源服務器所采用的協(xié)議(一般為非HTTP協(xié)議,如FTP,Gopher等).Tunnel作為連接鏈路中的中繼接點,它不改變消息內容.當連接鏈路要通過一中介(如防火墻.該中介可以不理解傳送消息的內容)時,Tunnel才被使用.HTTP消息兩種分類HTTP消息包括客戶端請求消息和服務器應答消息:HTTP-message=Request|Response這兩種類型的消息都由一個起始行,一個或多個頭標域,一個空行(表示頭標域結束)和一個可選的消息凈荷組成:消息頭標:H

12、TTP消息頭標包括通用頭標,請求頭標,響應頭標和實體頭標等類型.每個頭標字段由一個字段,加上冒號,而后跟一個值組成.一個消息的不同頭標的接收順序并不重要,然而,一般情況下最好按下列順序發(fā)送:通用頭標,請求頭標,響應頭標和實體頭標.消息體:一個消息的消息體是用于運載請求或響應消息的實體內容.實體是請求或響應消息攜帶的數(shù)據(jù),它包括實體頭標和實體內容.消息體于實體內容的區(qū)別在于,消息體不僅包括實體內容,而且還包括經(jīng)過傳輸編碼處理的實體內容.generic_message=start_line *message_header CRLF message_body start_line=Request_l

13、ine|Status_line這里的*message_header表示形式符,message_header可以出現(xiàn)若干次(可以為0次).方括號表示可選;CRLF表示回車,換行符.HTTP的請求消息的擴展BNF表示如下:Request=Request_line *(general_header |request_header |entity_header CRLF message_body例如:_GET /test/mh-email.asp HTTP/1.0Referer: Connection: Keep-AliveUser-Agent: Mozilla/4.51 en (Win95; I)H

14、ost: Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */*Accept-Encoding: gzipAccept-Language: enAccept-Charset: iso-8859-1,*,utf-8Cookie: ASPSESSIONIDQGQGQQAD=AIHJBHPBNDLGGKPBPOGKDHOB _ 請求行有一個操作字段(token)開始,接著是Request-URI和協(xié)議版本號,最后以CRLF結尾.個項內容之間用空格分開,除了最后的CRLF外,Request-URI

15、中其他地方不能出現(xiàn)CR和LF: Request_line=Method Request_URI HTTP_VersionCRLF Method ="OPTIONS" ; Section 9.2 | "GET" ; Section 9.3 | "HEAD" ; Section 9.4 | "POST" ; Section 9.5 | "PUT" ; Section 9.6 | "DELETE" ; Section 9.7 | "TRACE" ; Sectio

16、n 9.8 | "CONNECT" ; Section 9.9 | extension-methodHTTP應答消息的擴展BNF表示如下:Response=Status_line *(general_header) |response_header |entity_header) CRLF message_body例如:_/1HTTP/1.1 200 OKServer: Microsoft-IIS/4.0Connection: keep-aliveDate: Wed, 12 May 1999 09:14:17 GMTContent-Type: image/gifAccept

17、-Ranges: bytesLast-Modified: Wed, 24 Jun 1998 02:58:00 GMTETag: "0ec86e51b9fbd1:10c0"Content-Length: 5357 (blank line)GIF89a?薜蘄蕙汁?鼢 /GIF圖片余下部分省略_ 應答消息的頭一行是狀態(tài)行,其定義如下: Status_line=HTTP_Version Status_Code Reason_PhraseCRLF其中的狀態(tài)代碼Status_Code是一個3位數(shù)字的結果代碼:原因短語Reason_Phrase是對狀態(tài)代碼的簡短文字陳述.狀態(tài)碼供協(xié)議自動

18、機使用,而原因短語是為用戶使用的.有時我們可以在瀏覽器的服務器返回狀態(tài)中看到狀態(tài)代碼.狀態(tài)代碼的第一個數(shù)字定一個應答的類別,其余的兩位數(shù)字只起編號作用.一共有5種應答類別:1xx:Informational 提示,收到并接受請求,繼續(xù)請求其他部分;2xx:Success - 請求成功,操作指令被成功的接收到,理解和接受; 3xx:Redirection - 請求未完成,為了完成請求,必須采取進一步的操作;4xx:ClientError - 客戶錯,請求語法錯或無法完成;5xx:ServerError - 服務器錯,服務器無法完成有效的請求. HTTP狀態(tài)碼列表 Status-Code = &q

19、uot;100" ; Section 10.1.1: Continue | "101" ; Section 10.1.2: Switching Protocols | "200" ; Section 10.2.1: OK | "201" ; Section 10.2.2: Created | "202" ; Section 10.2.3: Accepted | "203" ; Section 10.2.4: Non-Authoritative Information | "2

20、04" ; Section 10.2.5: No Content | "205" ; Section 10.2.6: Reset Content | "206" ; Section 10.2.7: Partial Content | "300" ; Section 10.3.1: Multiple Choices | "301" ; Section 10.3.2: Moved Permanently | "302" ; Section 10.3.3: Found | "303

21、" ; Section 10.3.4: See Other | "304" ; Section 10.3.5: Not Modified | "305" ; Section 10.3.6: Use Proxy | "307" ; Section 10.3.8: Temporary Redirect | "400" ; Section 10.4.1: Bad Request | "401" ; Section 10.4.2: Unauthorized | "402"

22、; Section 10.4.3: Payment Required | "403" ; Section 10.4.4: Forbidden | "404" ; Section 10.4.5: Not Found | "405" ; Section 10.4.6: Method Not Allowed | "406" ; Section 10.4.7: Not Acceptable | "407" ; Section 10.4.8: Proxy Authentication Required |

23、 "408" ; Section 10.4.9: Request Time-out | "409" ; Section 10.4.10: Conflict | "410" ; Section 10.4.11: Gone | "411" ; Section 10.4.12: Length Required | "412" ; Section 10.4.13: Precondition Failed | "413" ; Section 10.4.14: Request Entit

24、y Too Large | "414" ; Section 10.4.15: Request-URI Too Large | "415" ; Section 10.4.16: Unsupported Media Type | "416" ; Section 10.4.17: Requested range not satisfiable | "417" ; Section 10.4.18: Expectation Failed | "500" ; Section 10.5.1: Internal

25、 Server Error | "501" ; Section 10.5.2: Not Implemented | "502" ; Section 10.5.3: Bad Gateway | "503" ; Section 10.5.4: Service Unavailable | "504" ; Section 10.5.5: Gateway Time-out | "505" ; Section 10.5.6: HTTP Version not supported | extension-co

26、deHTTP的操作(全部共7種)1. OPTIONSOPTIONS操作說明了由Request-URI所標識的HTTP請求/應答鏈上有關通訊功能選項.客戶使用該操作可以在對不同實體操作或傳送實體的情況下獲得某個實體的操作要求,功能選項,服務器的能力.對OPTIONS的應答是不能被緩存的.2. GETGET操作表示以實體的形式取回由Request-URI所標識的任何信息.如果Request-URI指向一個數(shù)據(jù)處理進程,那么該進程運行結果將作為應答消息包中的實體而返回.如果請求消息帶有 If-Modified-Since,If-Unmodified-Since,If-Match,If-None-Ma

27、tch或If-Range頭標域,則GET就變成”條件GET”;如果請求消息中含有Range頭標域,這相當于一個”部分GET”.部分 GET只要求傳送實體的一部分內容,這樣就不必傳送客戶已擁有的數(shù)據(jù),從而減輕網(wǎng)絡負載.3. HEADHEAD操作和GET語義基本相同,但是HEAD規(guī)定應答消息包中不能含有消息凈荷.使用該操作可以在不傳送實體凈荷的情況下獲取實體的元信息,因此它經(jīng)常被用來測試超文本鏈的有效性,可訪問性和最近修改狀態(tài).4. POSTPOST操作用于請求目的服務器接收請求消息包中的實體,作為Request-URI所標識資源的一個新的從屬.有了POST,可以在實體應用中完成如下的功能:.注解

28、已存在的資源.向BBS,新聞組或郵件列表張貼消息.向數(shù)據(jù)處理進程提供一組數(shù)據(jù),如表格(form)提交結果.實現(xiàn)數(shù)據(jù)庫的添加操作.(POST:用于客戶向服務器傳送數(shù)據(jù),以便服務器作出相應的處理。POST方法經(jīng)常用于向HTTP服務器提交HTML表格以便處理.例如,網(wǎng)上的聯(lián)機就業(yè)服務中就是靠提交簡歷表格來找工作.當你填寫了一份WWW頁面表格后,瀏覽器通常就使用POST方法向服務器提交你輸入的數(shù)據(jù).)5. PUTPUT操作請求把攜帶的實體存放于Request-URI處,請注意它和POST的區(qū)別.如果Request-URI指向一個已經(jīng)存在的資源,請求消息包中攜帶的實體將作為起始服務其上原資源的一個更新版

29、本;如果Request-URI所指向的資源不存在,而且該URI能被請求用戶進程定義為一個新資源,那么服務器將用該URI創(chuàng)建一個新資源.POST操作和PUT操作的最根本的差別反映在Request-URI的含義中POST的URI標識了將對被攜帶實體進行處理的某個資源,該資源可能是一個數(shù)據(jù)處理進程,一個多協(xié)議網(wǎng)關或者一個接收注解信息的獨立實體.而PUT請求中的URI標識了該請求所攜帶的實體本身,只有客戶知道URI的確切含義,服務器絕不對其他資源實施被請求的操作.6. DELETEDELETE操作請求服務器刪除由Request-URI標識的資源.不過DELETE操作可能受到服務器一端認為干預而不予執(zhí)行

30、,所以即使從服務器返回的狀態(tài)代碼表明刪除成功完成,客戶也不能據(jù)此確認真正執(zhí)行了刪除.7. TRACETRACE操作用于引發(fā)請求消息包的遠程應用自環(huán)測試.如果成功,請求消息的最后一個接收者應該把整個請求消息包作為相應消息的實體內容部分發(fā)送還給客戶端.TRACE是客戶可以了解到請求/響應鏈另一端數(shù)據(jù)接收的情況,并把接收的數(shù)據(jù)作為測試或診斷信息送回.HTTP的協(xié)議參數(shù)1. URI(Uniform Resource Identifiers)統(tǒng)一資源標識符URI是一種格式化字符串,可以用名字,地點或其他特征標識某個資源,因此URI有許多別名,如WWW地址,Universal Document Ideni

31、fiers(全局文檔標識符),Uniform Resourct Names(統(tǒng)一資源名),以及大家很熟悉的統(tǒng)一資源定位器Uniform Resource Locators.2. 實體標記(Entity Tags)實體標記用于區(qū)分同一個被請求資源的不同實體.頭標域 Etag,If-Match,If-None-Match和If-Range中使用了實體標記.3. 實體域單元(Entity-Range Unit)HTTP/1.1允許客戶端請求服務器發(fā)送的應答消息中只包含原應答實體的一部分(實體域).頭標域Range和Content-Range中用到了該協(xié)議參數(shù).在當前版本中,HhHHTTP/1.1定義

32、實體域單元為一個字節(jié).HTTP的頭標域對實體頭標域來說,術語發(fā)送方sender和接收recipient可能指客戶或者服務器任何一方,這取決于發(fā)送或接收實體的當前實際行為.同樣實體頭標域即可用于請求消息,也可用于應答消息,但是不能用于被傳輸?shù)膶嶓w.所以下面的通用頭標域只能用于消息本身.消息中被表示的頭標域可以認為是實體頭標域.HTTP/1.1頭標域的語法如下:genner_header=cache_control |Connection |Date |Program |Transfer_Encoding |Upgrade |Via主要的頭標域包括Content_Base,Content_Leng

33、th,Content_Location,Content_Range,Content_Type,Date,Etag,Host,If_modified_Since,If_Range,Last_modified,Location,Pragma,Proxy_authenticate,Range等.頭標域列表RFC#2616 14章 Header Field Definitions general-header = Cache-Control ; Section 14.9 | Connection ; Section 14.10 | Date ; Section 14.18 | Pragma ; Sec

34、tion 14.32 | Trailer ; Section 14.40 | Transfer-Encoding ; Section 14.41 | Upgrade ; Section 14.42 | Via ; Section 14.45 | Warning ; Section 14.46 request-header = Accept ; Section 14.1 | Accept-Charset ; Section 14.2 | Accept-Encoding ; Section 14.3 | Accept-Language ; Section 14.4 | Authorization

35、; Section 14.8 | Expect ; Section 14.20 | From ; Section 14.22 | Host ; Section 14.23 | If-Match ; Section 14.24 | If-Modified-Since ; Section 14.25 | If-None-Match ; Section 14.26 | If-Range ; Section 14.27 | If-Unmodified-Since ; Section 14.28 | Max-Forwards ; Section 14.31 | Proxy-Authorization ;

36、 Section 14.34 | Range ; Section 14.35 | Referer ; Section 14.36 | TE ; Section 14.39 | User-Agent ; Section 14.43 response-header = Accept-Ranges ; Section 14.5 | Age ; Section 14.6 | ETag ; Section 14.19 | Location ; Section 14.30 | Proxy-Authenticate ; Section 14.33 | Retry-After ; Section 14.37

37、| Server ; Section 14.38 | Vary ; Section 14.44 | WWW-Authenticate ; Section 14.47 entity-header = Allow ; Section 14.7 | Content-Encoding ; Section 14.11 | Content-Language ; Section 14.12 | Content-Length ; Section 14.13 | Content-Location ; Section 14.14 | Content-MD5 ; Section 14.15 | Content-Ra

38、nge ; Section 14.16 | Content-Type ; Section 14.17 | Expires ; Section 14.21 | Last-Modified ; Section 14.29 | extension-header extension-header = message-header快速理解HTTP協(xié)議HTTP協(xié)議使Web服務器和瀏覽器可以通過Web交換數(shù)據(jù).它是一種請求/響應協(xié)議,即服務器等待并響應客戶請求.HTTP不維護與客戶方的連接,它使用可靠的TCP連結,通常采用TCP 80端口. Web服務器運行著一個守護進程(HTTPDaemon),它始終在端

39、口80監(jiān)聽著來自遠端客戶的請求.當一個請求發(fā)來時,它就會產(chǎn)生一個子進程來處理當前請求,守護進程繼續(xù)以后臺方式運行,在端口80繼續(xù)監(jiān)聽來自遠端的連接請求.客戶/服務器傳輸過程可以分為四個基本步驟:1)瀏覽器與服務器建立連接;2)瀏覽器向服務器請求文檔;3)服務器響應瀏覽器請求;4)斷開連接.HTTP是一種無狀態(tài)協(xié)議,它不維護連接的狀態(tài)信息.(注:最新RFC中有關HTTP協(xié)議概述RFC2616可在/Protocols/中找到)每個資源都有其特定的URL標識,經(jīng)由各種不同的協(xié)議,對Internet上任何地方的信息都可以用URL定位或取回.URL可以指定FTP文件傳輸

40、,尋找新聞信息,定義用戶的Email地址,標識HTTP文件和其他類型數(shù)據(jù).URL中的字符不區(qū)分大小寫.為了使客戶端和服務器通信成為可能,HTTP協(xié)議建立了一種由請求和響應消息組成的Web語言.1) 客戶請求客戶請求包括如下信息:l 請求方法l 請求頭l 請求數(shù)據(jù)請求方法是用于特定URL或Web頁面的程序.表 快速理解-表1列出了可用的請求方法. 表1 HTTP請求方法=- 請求操作方法(共7種)描述=- (1) GET 請求指定文檔 (2) HEAD 僅請求文檔頭 (3) POST 請求服務器接收指定文當作為可執(zhí)行的信息 (4) PUT 用從客戶端傳送的數(shù)據(jù)取代指定文檔中的內容 (5) DELETE 請求服務器刪除指