posted @ 2008-12-29 14:22 井中月 閱讀(590) | 評論 (0) | 編輯 收藏
HTTP協(xié)議(http://www.w3.org/Protocols/)是“一次性單向”協(xié)議。
服務(wù)端不能主動連接客戶端,只能被動等待并答復(fù)客戶端請求。客戶端連接服務(wù)端,發(fā)出一個HTTP Request,服務(wù)端處理請求,并且返回一個HTTP Response給客戶端,本次HTTP Request-Response Cycle結(jié)束。
我們看到,HTTP協(xié)議本身并不能支持服務(wù)端保存客戶端的狀態(tài)信息。于是,Web Server中引入了session的概念,用來保存客戶端的狀態(tài)信息。
這里用一個形象的比喻來解釋session的工作方式。假設(shè)Web Server是一個商場的存包處,HTTP Request是一個顧客,第一次來到存包處,管理員把顧客的物品存放在某一個柜子里面(這個柜子就相當于Session),然后把一個號碼牌交給這個顧客,作為取包憑證(這個號碼牌就是Session ID)。顧客(HTTP Request)下一次來的時候,就要把號碼牌(Session ID)交給存包處(Web Server)的管理員。管理員根據(jù)號碼牌(Session ID)找到相應(yīng)的柜子(Session),根據(jù)顧客(HTTP Request)的請求,Web Server可以取出、更換、添加柜子(Session)中的物品,Web Server也可以讓顧客(HTTP Request)的號碼牌和號碼牌對應(yīng)的柜子(Session)失效。顧客(HTTP Request)的忘性很大,管理員在顧客回去的時候(HTTP Response)都要重新提醒顧客記住自己的號碼牌(Session ID)。這樣,顧客(HTTP Request)下次來的時候,就又帶著號碼牌回來了。
我們可以看到,Session ID實際上是在客戶端和服務(wù)端之間通過HTTP Request和HTTP Response傳來傳去的。
我們看到,號碼牌(Session ID)必須包含在HTTP Request里面。關(guān)于HTTP Request的具體格式,請參見HTTP協(xié)議(http://www.w3.org/Protocols/)。這里只做一個簡單的介紹。
在Java Web Server(即Servlet/JSP Server)中,Session ID用jsessionid表示(請參見Servlet規(guī)范)。
HTTP Request一般由3部分組成:
(1)Request Line
這一行由HTTP Method(如GET或POST)、URL、和HTTP版本號組成。
例如,GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
GET http://www.google.com/search?q=Tomcat HTTP/1.1
POST http://www.google.com/search HTTP/1.1
GET http://www.somsite.com/menu.do;jsessionid=1001 HTTP/1.1
(2)Request Headers
這部分定義了一些重要的頭部信息,如,瀏覽器的種類,語言,類型。Request Headers中還可以包括Cookie的定義。例如:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
Accept-Language: en-us
Cookie: jsessionid=1001
(3)Message Body
如果HTTP Method是GET,那么Message Body為空。
如果HTTP Method是POST,說明這個HTTP Request是submit一個HTML Form的結(jié)果,
那么Message Body為HTML Form里面定義的Input屬性。例如,
user=guest
password=guest
jsessionid=1001
主意,如果把HTML Form元素的Method屬性改為GET。那么,Message Body為空,所有的Input屬性都會加在URL的后面。你在瀏覽器的URL地址欄中會看到這些屬性,類似于
http://www.somesite/login.do?user=guest&password=guest&jsessionid=1001
從理論上來說,這3個部分(Request URL,Cookie Header, Message Body)都可以用來存放Session ID。由于Message Body方法必須需要一個包含Session ID的HTML Form,所以這種方法不通用。
一般用來實現(xiàn)Session的方法有兩種:
(1)URL重寫。
Web Server在返回Response的時候,檢查頁面中所有的URL,包括所有的連接,和HTML Form的Action屬性,在這些URL后面加上“;jsessionid=XXX”。
下一次,用戶訪問這個頁面中的URL。jsessionid就會傳回到Web Server。
(2)Cookie。
如果客戶端支持Cookie,Web Server在返回Response的時候,在Response的Header部分,加入一個“set-cookie: jsessionid=XXXX”header屬性,把jsessionid放在Cookie里傳到客戶端。
客戶端會把Cookie存放在本地文件里,下一次訪問Web Server的時候,再把Cookie的信息放到HTTP Request的“Cookie”header屬性里面,這樣jsessionid就隨著HTTP Request返回給Web Server。
我們來看Tomcat5的源代碼如何支持jsessionid。
org.apache.coyote.tomcat5.CoyoteResponse類的toEncoded()方法支持URL重寫。
String toEncoded(String url, String sessionId) {
…
StringBuffer sb = new StringBuffer(path);
if( sb.length() > 0 ) { // jsessionid can't be first.
sb.append(";jsessionid=");
sb.append(sessionId);
}
sb.append(anchor);
sb.append(query);
return (sb.toString());
}
我們來看org.apache.coyote.tomcat5.CoyoteRequest的兩個方法configureSessionCookie()
doGetSession()用Cookie支持jsessionid.
/**
* Configures the given JSESSIONID cookie.
*
* @param cookie The JSESSIONID cookie to be configured
*/
protected void configureSessionCookie(Cookie cookie) {
…
}
HttpSession doGetSession(boolean create){
…
// Creating a new session cookie based on that session
if ((session != null) && (getContext() != null)
&& getContext().getCookies()) {
Cookie cookie = new Cookie(Globals.SESSION_COOKIE_NAME,
session.getId());
configureSessionCookie(cookie);
((HttpServletResponse) response).addCookie(cookie);
}
…
}
Session的典型應(yīng)用是存放用戶的Login信息,如用戶名,密碼,權(quán)限角色等信息,應(yīng)用程序(如Email服務(wù)、網(wǎng)上銀行等系統(tǒng))根據(jù)這些信息進行身份驗證和權(quán)限驗證
posted @ 2008-12-29 14:14 井中月 閱讀(1127) | 評論 (0) | 編輯 收藏
1、HTTP 只有POST和GET 兩種命令模式;
2、POST是被設(shè)計用來向上放東西的,而GET是被設(shè)計用來從服務(wù)器取東西的,GET也能夠向服務(wù)器傳送較少的數(shù)據(jù),而Get之所以也能傳送數(shù)據(jù),只是用來設(shè)計告訴服務(wù)器,你到底需要什么樣的數(shù)據(jù).POST的信息作為HTTP 請求的內(nèi)容,而GET是在HTTP 頭部傳輸?shù)模?
3、POST與GET在HTTP 中傳送的方式不同,GET的參數(shù)是在HTTP 的頭部傳送的,而Post的數(shù)據(jù)則是在HTTP 請求的內(nèi)容里傳送;
4、POST傳輸數(shù)據(jù)時,不需要在URL中顯示出來,而GET方法要在URL中顯示;
5、GET方法由于受到URL長度的限制,只能傳遞大約1024字節(jié);POST傳輸?shù)臄?shù)據(jù)量大,可以達到2M,而根據(jù)微軟方面的說法,微軟對用 Request.Form() 可接收的最大數(shù)據(jù)有限制,IIS 4 中為 80 KB 字節(jié),IIS 5 中為 100 KB 字節(jié);
6、SOAP是依賴于HTTP POST模式實現(xiàn)的;
例子:
HTTP GET
發(fā)送
GET /DEMOWebServices2.8/Service.asmx/CancelOrder?UserID=string&PWD=string&OrderConfirmation=string HTTP/1.1
Host: api.efxnow.com
回復(fù)
HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Content-Length: length
<?xml version="1.0" encoding="utf-8"?>
<objPlaceOrderResponse xmlns="https://api.efxnow.com/webservices2.3">
<Success>boolean</Success>
<ErrorDescription>string</ErrorDescription>
<ErrorNumber>int</ErrorNumber>
<CustomerOrderReference>long</CustomerOrderReference>
<OrderConfirmation>string</OrderConfirmation>
<CustomerDealRef>string</CustomerDealRef>
</objPlaceOrderResponse>
HTTP POST
發(fā)送
POST /DEMOWebServices2.8/Service.asmx/CancelOrder HTTP/1.1
Host: api.efxnow.com
Content-Type: application/x-www-form-urlencoded
Content-Length: length
UserID=string&PWD=string&OrderConfirmation=string
回復(fù)
HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Content-Length: length
<?xml version="1.0" encoding="utf-8"?>
<objPlaceOrderResponse xmlns="https://api.efxnow.com/webservices2.3">
<Success>boolean</Success>
<ErrorDescription>string</ErrorDescription>
<ErrorNumber>int</ErrorNumber>
<CustomerOrderReference>long</CustomerOrderReference>
<OrderConfirmation>string</OrderConfirmation>
<CustomerDealRef>string</CustomerDealRef>
</objPlaceOrderResponse>
SOAP 1.2
發(fā)送
POST /DEMOWebServices2.8/Service.asmx HTTP/1.1
Host: api.efxnow.com
Content-Type: application/soap+xml; charset=utf-8
Content-Length: length
<?xml version="1.0" encoding="utf-8"?>
<soap12:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap12="http://www.w3.org/2003/05/soap-envelope">
<soap12:Body>
<CancelOrder xmlns="https://api.efxnow.com/webservices2.3">
<UserID>string</UserID>
<PWD>string</PWD>
<OrderConfirmation>string</OrderConfirmation>
</CancelOrder>
</soap12:Body>
</soap12:Envelope>
回復(fù)
HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset=utf-8
Content-Length: length
<?xml version="1.0" encoding="utf-8"?>
<soap12:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap12="http://www.w3.org/2003/05/soap-envelope">
<soap12:Body>
<CancelOrderResponse xmlns="https://api.efxnow.com/webservices2.3">
<CancelOrderResult>
<Success>boolean</Success>
<ErrorDescription>string</ErrorDescription>
<ErrorNumber>int</ErrorNumber>
<CustomerOrderReference>long</CustomerOrderReference>
<OrderConfirmation>string</OrderConfirmation>
<CustomerDealRef>string</CustomerDealRef>
</CancelOrderResult>
</CancelOrderResponse>
</soap12:Body>
</soap12:Envelope>
posted @ 2008-12-29 14:13 井中月 閱讀(3687) | 評論 (0) | 編輯 收藏
HTTP請求包括三部分:請求行(Request Line),頭部(Headers)和數(shù)據(jù)體(Body)。其中,請求行由請求方法(method),請求網(wǎng)址Request-URI和協(xié)議 (Protocol)構(gòu)成,而請求頭包括多個屬性,數(shù)據(jù)體則可以被認為是附加在請求之后的文本或二進制文件。
下面這個例子顯示了一個HTTP請求的Header內(nèi)容,這些數(shù)據(jù)是真正以網(wǎng)絡(luò)HTTP協(xié)議從IE瀏覽器傳遞到Apache服務(wù)器上的。
GET /icwork/? search=product HTTP/1.1
Accept:image/gif,image/x-xbitmap,image/jpeg,image/pjpeg,application/vnd.ms-powerpoint,application/vnd.ms-excel,application/msword,*.*
Accept-Language:en-us
Accept-Encoding:gzip,deflate
User-Agent:Mozilla/4.0(compatible;MSIE 5.01;Windows NT 5.0;DigExt)
Host:www.icconcept.com:8080
Referer:http://www.yoursite.com/header.html
Connection:Keep-Alive
這段程序使用了6個Header,還有一些Header沒有出現(xiàn)。我們參考這個例子具體解釋HTTP請求格式。
1.HTTP請求行:請求行格式為Method Request-URI Protocol。在上面這個例子里,“GET /icwork/? search=pruduct HTTP/1.1”是請求行。
2.Accept:指瀏覽器或其他客戶可以接愛的MIME文件格式。Servlet可以根據(jù)它判斷并返回適當?shù)奈募袷健?/p>
3.Accept-Charset:指出瀏覽器可以接受的字符編碼。英文瀏覽器的默認值是ISO-8859-1.
4.Accept-Language:指出瀏覽器可以接受的語言種類,如en或en-us,指英語。
5.Accept-Encoding:指出瀏覽器可以接受的編碼方式。編碼方式不同于文件格式,它是為了壓縮文件并加速文件傳遞速度。瀏覽器在接收到Web響應(yīng)之后先解碼,然后再檢查文件格式。
6.Authorization:當使用密碼機制時用來標識瀏覽器。
7.Cache-Control:設(shè)置關(guān)于請求被代理服務(wù)器存儲的相關(guān)選項。一般servlet用不到。
8.Connection:用來告訴服務(wù)器是否可以維持固定的HTTP連接。HTTP/1.1使用Keep-Alive為默認值,這樣,當瀏覽器需要多個文件時(比如一個HTML文件和相關(guān)的圖形文件),不需要每次都建立連接。
9.Content-Type:用來表名request的內(nèi)容類型。可以用HttpServletRequest的getContentType()方法取得。
10.Cookie:瀏覽器用這個屬性向服務(wù)器發(fā)送Cookie。Cookie是在瀏覽器中寄存的小型數(shù)據(jù)體,它可以記載和服務(wù)器相關(guān)的用戶信息,也可以用來實現(xiàn)會話功能。
11.Expect:表時客戶預(yù)期的響應(yīng)狀態(tài)。
12.From:給出客戶端HTTP請求負責人的email地址。
13.Host:對應(yīng)網(wǎng)址URL中的Web名稱和端口號。
14.If-Match:供PUT方法使用。
15.If-Modified-Since:客戶使用這個屬性表明它只需要在指定日期之后更改過的網(wǎng)頁。因為瀏覽器可以使用其存儲的文件而不必從服務(wù)器請求,這樣節(jié)省了Web資源。由于Servlet是動態(tài)生成的網(wǎng)頁,一般不需要使用這個屬性。
16.If-None-Match:和If-Match相反的操作,供PUT方法使用。
17.If-Unmodified-Since:和If-Match-Since相反。
18.Pragma:這個屬性只有一種值,即Pragma:no-cache,表明如果servlet充當代理服務(wù)器,即使其有已經(jīng)存儲的網(wǎng)頁,也要將請求傳遞給目的服務(wù)器。
19.Proxy-Authorization:代理服務(wù)器使用這個屬性,Servlet一般用不到。
20.Range:如果客戶有部分網(wǎng)頁,這個屬性可以請求剩余部分。
21.Referer:表明產(chǎn)生請求的網(wǎng)頁URL。如比從網(wǎng)頁/icconcept/index.jsp中點擊一個鏈接到網(wǎng)頁/icwork/search,在向服務(wù)器發(fā)送的GET/icwork/search中的請求中,Referer是http://hostname:8080/icconcept/index.php。這個屬性可以用來跟蹤Web請求是從什么網(wǎng)站來的。
22.Upgrage:客戶通過這個屬性設(shè)定可以使用與HTTP/1.1不同的協(xié)議。
23.User-Agent:是客戶瀏覽器名稱。
24.Via:用來記錄Web請求經(jīng)過的代理服務(wù)器或Web通道。
25.Warning:用來由客戶聲明傳遞或存儲(cache)錯誤。
posted @ 2008-12-29 14:13 井中月 閱讀(518) | 評論 (0) | 編輯 收藏
HTTP(HyperText Transfer Protocol)是一套計算機通過網(wǎng)絡(luò)進行通信的規(guī)則。計算機專家設(shè)計出HTTP,使HTTP客戶(如Web瀏覽器)能夠從HTTP服務(wù)器(Web服務(wù)器)請求信息和服務(wù),HTTP目前協(xié)議的版本是1.1.HTTP是一種無狀態(tài)的協(xié)議,無狀態(tài)是指Web瀏覽器和Web服務(wù)器之間不需要建立持久的連接,這意味著當一個客戶端向服務(wù)器端發(fā)出請求,然后Web服務(wù)器返回響應(yīng)(response),連接就被關(guān)閉了,在服務(wù)器端不保留連接的有關(guān)信息.HTTP遵循請求(Request)/應(yīng)答(Response)模型。Web瀏覽器向Web服務(wù)器發(fā)送請求,Web服務(wù)器處理請求并返回適當?shù)膽?yīng)答。所有HTTP連接都被構(gòu)造成一套請求和應(yīng)答。
HTTP使用內(nèi)容類型,是指Web服務(wù)器向Web瀏覽器返回的文件都有與之相關(guān)的類型。所有這些類型在MIME Internet郵件協(xié)議上模型化,即Web服務(wù)器告訴Web瀏覽器該文件所具有的種類,是HTML文檔、GIF格式圖像、聲音文件還是獨立的應(yīng)用程序。大多數(shù)Web瀏覽器都擁有一系列的可配置的輔助應(yīng)用程序,它們告訴瀏覽器應(yīng)該如何處理Web服務(wù)器發(fā)送過來的各種內(nèi)容類型。
HTTP通信機制是在一次完整的HTTP通信過程中,Web瀏覽器與Web服務(wù)器之間將完成下列7個步驟:
(1) 建立TCP連接
在HTTP工作開始之前,Web瀏覽器首先要通過網(wǎng)絡(luò)與Web服務(wù)器建立連接,該連接是通過TCP來完成的,該協(xié)議與IP協(xié)議共同構(gòu)建Internet,即著名的TCP/IP協(xié)議族,因此Internet又被稱作是TCP/IP網(wǎng)絡(luò)。HTTP是比TCP更高層次的應(yīng)用層協(xié)議,根據(jù)規(guī)則,只有低層協(xié)議建立之后才能,才能進行更層協(xié)議的連接,因此,首先要建立TCP連接,一般TCP連接的端口號是80
(2) Web瀏覽器向Web服務(wù)器發(fā)送請求命令
一旦建立了TCP連接,Web瀏覽器就會向Web服務(wù)器發(fā)送請求命令
例如:GET/sample/hello.jsp HTTP/1.1
(3) Web瀏覽器發(fā)送請求頭信息
瀏覽器發(fā)送其請求命令之后,還要以頭信息的形式向Web服務(wù)器發(fā)送一些別的信息,之后瀏覽器發(fā)送了一空白行來通知服務(wù)器,它已經(jīng)結(jié)束了該頭信息的發(fā)送。
(4) Web服務(wù)器應(yīng)答
客戶機向服務(wù)器發(fā)出請求后,服務(wù)器會客戶機回送應(yīng)答,
HTTP/1.1 200 OK
應(yīng)答的第一部分是協(xié)議的版本號和應(yīng)答狀態(tài)碼
(5) Web服務(wù)器發(fā)送應(yīng)答頭信息
正如客戶端會隨同請求發(fā)送關(guān)于自身的信息一樣,服務(wù)器也會隨同應(yīng)答向用戶發(fā)送關(guān)于它自己的數(shù)據(jù)及被請求的文檔。
(6) Web服務(wù)器向瀏覽器發(fā)送數(shù)據(jù)
Web服務(wù)器向瀏覽器發(fā)送頭信息后,它會發(fā)送一個空白行來表示頭信息的發(fā)送到此為結(jié)束,接著,它就以Content-Type應(yīng)答頭信息所描述的格式發(fā)送用戶所請求的實際數(shù)據(jù)
(7) Web服務(wù)器關(guān)閉TCP連接
一般情況下,一旦Web服務(wù)器向瀏覽器發(fā)送了請求數(shù)據(jù),它就要關(guān)閉TCP連接,然后如果瀏覽器或者服務(wù)器在其頭信息加入了這行代碼
Connection:keep-alive
TCP連接在發(fā)送后將仍然保持打開狀態(tài),于是,瀏覽器可以繼續(xù)通過相同的連接發(fā)送請求。保持連接節(jié)省了為每個請求建立新連接所需的時間,還節(jié)約了網(wǎng)絡(luò)帶寬。
HTTP請求格式
當瀏覽器向Web服務(wù)器發(fā)出請求時,它向服務(wù)器傳遞了一個數(shù)據(jù)塊,也就是請求信息,HTTP請求信息由3部分組成:
l 請求方法URI協(xié)議/版本
l 請求頭(Request Header)
l 請求正文
下面是一個HTTP請求的例子:
GET/sample.jspHTTP/1.1
Accept:image/gif.image/jpeg,*/*
Accept-Language:zh-cn
Connection:Keep-Alive
Host:localhost
User-Agent:Mozila/4.0(compatible;MSIE5.01;Window NT5.0)
Accept-Encoding:gzip,deflate
username=jinqiao&password=1234
(1) 請求方法URI協(xié)議/版本
請求的第一行是“方法URL議/版本”:GET/sample.jsp HTTP/1.1
以上代碼中“GET”代表請求方法,“/sample.jsp”表示URI,“HTTP/1.1代表協(xié)議和協(xié)議的版本。
根據(jù)HTTP標準,HTTP請求可以使用多種請求方法。例如:HTTP1.1支持7種請求方法:GET、POST、HEAD、OPTIONS、PUT、DELETE和TARCE。在Internet應(yīng)用中,最常用的方法是GET和POST。
URL完整地指定了要訪問的網(wǎng)絡(luò)資源,通常只要給出相對于服務(wù)器的根目錄的相對目錄即可,因此總是以“/”開頭,最后,協(xié)議版本聲明了通信過程中使用HTTP的版本。
(2) 請求頭(Request Header)
請求頭包含許多有關(guān)的客戶端環(huán)境和請求正文的有用信息。例如,請求頭可以聲明瀏覽器所用的語言,請求正文的長度等。
Accept:image/gif.image/jpeg.*/*
Accept-Language:zh-cn
Connection:Keep-Alive
Host:localhost
User-Agent:Mozila/4.0(compatible:MSIE5.01:Windows NT5.0)
Accept-Encoding:gzip,deflate.
(3) 請求正文
請求頭和請求正文之間是一個空行,這個行非常重要,它表示請求頭已經(jīng)結(jié)束,接下來的是請求正文。請求正文中可以包含客戶提交的查詢字符串信息:
username=jinqiao&password=1234
在以上的例子的HTTP請求中,請求的正文只有一行內(nèi)容。當然,在實際應(yīng)用中,HTTP請求正文可以包含更多的內(nèi)容。
HTTP請求方法我這里只討論GET方法與POST方法
GET方法
GET方法是默認的HTTP請求方法,我們?nèi)粘S肎ET方法來提交表單數(shù)據(jù),然而用GET方法提交的表單數(shù)據(jù)只經(jīng)過了簡單的編碼,同時它將作為URL的一部分向Web服務(wù)器發(fā)送,因此,如果使用GET方法來提交表單數(shù)據(jù)就存在著安全隱患上。例如
Http://127.0.0.1/login.jsp?Name=zhangshi&Age=30&Submit=%cc%E+%BD%BB
從上面的URL請求中,很容易就可以辯認出表單提交的內(nèi)容。(?之后的內(nèi)容)另外由于GET方法提交的數(shù)據(jù)是作為URL請求的一部分所以提交的數(shù)據(jù)量不能太大
POST方法
POST方法是GET方法的一個替代方法,它主要是向Web服務(wù)器提交表單數(shù)據(jù),尤其是大批量的數(shù)據(jù)。POST方法克服了GET方法的一些缺點。通過POST方法提交表單數(shù)據(jù)時,數(shù)據(jù)不是作為URL請求的一部分而是作為標準數(shù)據(jù)傳送給Web服務(wù)器,這就克服了GET方法中的信息無法保密和數(shù)據(jù)量太小的缺點。因此,出于安全的考慮以及對用戶隱私的尊重,通常表單提交時采用POST方法。
從編程的角度來講,如果用戶通過GET方法提交數(shù)據(jù),則數(shù)據(jù)存放在QUERY_STRING環(huán)境變量中,而POST方法提交的數(shù)據(jù)則可以從標準輸入流中獲取。
HTTP應(yīng)答與HTTP請求相似,HTTP響應(yīng)也由3個部分構(gòu)成,分別是:
l 協(xié)議狀態(tài)版本代碼描述
l 響應(yīng)頭(Response Header)
l 響應(yīng)正文
下面是一個HTTP響應(yīng)的例子:
HTTP/1.1 200 OK
Server:Apache Tomcat/5.0.12
Date:Mon,6Oct2003 13:23:42 GMT
Content-Length:112
<html>
<head>
<title>HTTP響應(yīng)示例<title>
</head>
<body>
Hello HTTP!
</body>
</html>
協(xié)議狀態(tài)代碼描述HTTP響應(yīng)的第一行類似于HTTP請求的第一行,它表示通信所用的協(xié)議是HTTP1.1服務(wù)器已經(jīng)成功的處理了客戶端發(fā)出的請求(200表示成功):
HTTP/1.1 200 OK
響應(yīng)頭(Response Header)響應(yīng)頭也和請求頭一樣包含許多有用的信息,例如服務(wù)器類型、日期時間、內(nèi)容類型和長度等:
Server:Apache Tomcat/5.0.12
Date:Mon,6Oct2003 13:13:33 GMT
Content-Type:text/html
Last-Moified:Mon,6 Oct 2003 13:23:42 GMT
Content-Length:112
響應(yīng)正文響應(yīng)正文就是服務(wù)器返回的HTML頁面:
<html>
<head>
<title>HTTP響應(yīng)示例<title>
</head>
<body>
Hello HTTP!
</body>
</html>
響應(yīng)頭和正文之間也必須用空行分隔。
HTTP應(yīng)答碼
HTTP應(yīng)答碼也稱為狀態(tài)碼,它反映了Web服務(wù)器處理HTTP請求狀態(tài)。HTTP應(yīng)答碼由3位數(shù)字構(gòu)成,其中首位數(shù)字定義了應(yīng)答碼的類型:
1XX-信息類(Information),表示收到Web瀏覽器請求,正在進一步的處理中
2XX-成功類(Successful),表示用戶請求被正確接收,理解和處理例如:200 OK
3XX-重定向類(Redirection),表示請求沒有成功,客戶必須采取進一步的動作。
4XX-客戶端錯誤(Client Error),表示客戶端提交的請求有錯誤 例如:404 NOT Found,意味著請求中所引用的文檔不存在。
5XX-服務(wù)器錯誤(Server Error)表示服務(wù)器不能完成對請求的處理:如 500
對于我們Web開發(fā)人員來說掌握HTTP應(yīng)答碼有助于提高Web應(yīng)用程序調(diào)試的效率和準確性。
安全連接
Web應(yīng)用最常見的用途之一是電子商務(wù),可以利用Web服務(wù)器端程序使人們能夠網(wǎng)絡(luò)購物,需要指出一點是,缺省情況下,通過Internet發(fā)送信息是不安全的,如果某人碰巧截獲了你發(fā)給朋友的一則消息,他就能打開它,假想在里面有你的信用卡號碼,這會有多么糟糕,幸運的是,很多Web服務(wù)器以及Web瀏覽器都有創(chuàng)立安全連接的能力,這樣它們就可以安全的通信了。
通過Internet提供安全連接最常見的標準是安全套接層(Secure Sockets layer,SSl)協(xié)議。SSL協(xié)議是一個應(yīng)用層協(xié)議(和HTTP一樣),用于安全方式在Web上交換數(shù)據(jù),SSL使用公開密鑰編碼系統(tǒng)。從本質(zhì)講,這意味著業(yè)務(wù)中每一方都擁有一個公開的和一個私有的密鑰。當一方使用另一方公開密鑰進行編碼時,只有擁有匹配密鑰的人才能對其解碼。簡單來講,公開密鑰編碼提供了一種用于在兩方之間交換數(shù)據(jù)的安全方法,SSL連接建立之后,客戶和服務(wù)器都交換公開密鑰,并在進行業(yè)務(wù)聯(lián)系之前進行驗證,一旦雙方的密鑰都通過驗證,就可以安全地交換數(shù)據(jù)。
posted @ 2008-12-29 14:12 井中月 閱讀(546) | 評論 (0) | 編輯 收藏
一、介紹(introduction)
1. 目的——HTTP/0.9-〉HTTP/1.0-〉HTTP/1.1
2. 要求——MUST、REQUIRED、SHOULD
3. 術(shù)語——連接(Connection)、消息(Message)、請求(Request)、應(yīng)答(Response)、資源(Resource)、實體(Entity)、表示方法(Representation)、內(nèi)容協(xié)商(Content Negotiation)、變量(Variant)、客戶機(Client)、用戶代理(User agent)、服務(wù)器(Server)、原服務(wù)器(Origin server)、代理服務(wù)器( Proxy)、網(wǎng)關(guān)(gateway)、高速緩存(Cache)、可緩存(Cacheable)、直接(first-hand)、明確終止時間(explicit expiration time)、探索終止時間(heuristic expiration time)、年齡(Age)、保鮮壽命(Freshness lifetime)、保鮮(Fresh)、陳舊(Stale)、語義透明(semantically transparent)、有效性判別器(Validator)、實體標記(entity tag)或最終更改時間(Last-Modified time))、上游/下游(upstream/downstream)、向內(nèi)/向外(inbound/outbound)
4. 總體操作——請求/應(yīng)答、中介
二、符號慣例與一般語法(notational conversions and generic grammar)
1. 擴充BNF——name = definition,"literal",rule1 | rule2,(rule1 rule2),*rule,[rule],N rule, #rule,; comment, implied *LWS
2. 基本規(guī)則——OCTET,CHAR,UPALPHA,LOALPHA,ALPHA,DIGIT,CTL,CR,LF,SP,HT,<">
三、協(xié)議參數(shù)(protocol parameters)
1. HTTP版本——HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT
2. 統(tǒng)一資源標示符(URI)——統(tǒng)一資源定位器(URL)和統(tǒng)一資源名稱(URN)的結(jié)合,http_URL = "http:" "http://" host [ ":" port ] [ abs_path [ "?" query ]]
3. 日期/時間格式——Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123,
Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036,
Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format
4. 字符集——本文檔中的術(shù)語"字符集"指一種用一個或更多表格將一個八字節(jié)序列轉(zhuǎn)換成一個字符序列的方法,
charset=token
失蹤字符集
5. 內(nèi)容編碼——內(nèi)容編碼主要用來允許文檔壓縮(信源編碼)
content-coding= token
注冊表包含下列標記:gzip,compress,deflate,identity
6. 傳輸編碼——目的是能夠確保通過網(wǎng)絡(luò)安全傳輸(信道編碼)
transfer-coding = "chunked" | transfer-extension
transfer-extension = token *( ";" parameter ),
成塊傳輸代碼
7. 媒體類型——media-type = type "/" subtype *( ";" parameter )
type = token
subtype = token
規(guī)范化和原文缺省
多部分類型
8. 產(chǎn)品標記——product = token ["/" product-version]
product-version = token
9. 質(zhì)量值——qvalue = ( "0" [ "." 0*3DIGIT ] )| ( "1" [ "." 0*3("0") ] )
10. 語言標記——language-tag = primary-tag *( "-" subtag )
primary-tag = 1*8ALPHA
subtag = 1*8ALPHA
11. 實體標記——entity-tag = [ weak ] opaque-tag
weak = "W/"
opaque-tag = quoted-string
12. 范圍單位——range-unit = bytes-unit | other-range-unit
bytes-unit = "bytes"
other-range-unit = token
四、 HTTP消息(HTTP message)
1. 消息類型——HTTP-message = Request | Response ; HTTP/1.1 messages
generic-message = start-line *(message-header CRLF) CRLF [ message-body ]
start-line = Request-Line | Status-Line
2. 消息頭——HTTP頭域包括常規(guī)頭,請求頭,應(yīng)答頭和實體頭域
message-header = field-name ":" [ field-value ]
field-name = token
field-value = *( field-content | LWS )
field-content = <the OCTETs making up the field-value and consisting of either *TEXT or combinations of token, separators, and quoted-string>
3. 消息體——message-body = entity-body| <entity-body encoded as per Transfer-Encoding>
4. 消息的長度——決定因素
5. 常規(guī)頭域——general-header = Cache-Control| Connection| Date| Pragma| Transfer-Encoding
五、 請求(request)
首行包括利用資源的方式,區(qū)分資源的標識,以及協(xié)議的版本號
Request = Request-Line * (( general-header| request-header| entity-header ) CRLF) CRLF [ message-body ]
1. 請求行——Request-Line = Method SP Request-URI SP HTTP-Version CRLF
方法——方法標記指的是在請求URI所指定的資源上所實現(xiàn)的方式
Method = "OPTIONS"| "GET"| "POST"| "PUT"| "DELETE"| "TRACE"| "CONNECT"| extension-method
extension-method = token
請求URL——請求URL是一種全球統(tǒng)一的應(yīng)用于資源請求的資源標識符
Request-URI = "*" | absoluteURI | abs_path | authority
請求行舉例:GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
GET /pub/WWW/TheProject.html HTTP/1.1
Host: www.w3.org
2. 請求定義的資源——一個INTERNET請求所定義的精確資源由請求URL和主機報頭域所決定
3. 請求報頭域——request-header = Accept| Accept-Charset| Accept-Encoding| Accept-Language| Authorization| Expect| From| Host| If-Match| If-Modified-Since| If-None-Match| If-Range| If-Unmodified-Since| Max-Forwards| Proxy-Authorization| Range| Referer| TE| User-Agent
六、 應(yīng)答(response)
接收和翻譯一個請求信息后,服務(wù)器發(fā)出一個HTTP應(yīng)答信息
Response = Status-Line*(( general-header| response-header| entity-header ) CRLF) CRLF [ message-body ]
1. 狀態(tài)行——Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
狀態(tài)碼——狀態(tài)碼是試圖理解和滿足請求的三位數(shù)字的整數(shù)碼,1xx,2xx,3xx,4xx,5xx,100-〉505-〉擴展碼
2. 應(yīng)答報頭域——response-header = Accept-Ranges| Age| Location| Proxy-Authenticate| Retry-After| Server| Vary| WWW-Authenticate
七、 實體(entity)
在未經(jīng)特別規(guī)定的情況下,請求與應(yīng)答的消息也可以傳送實體。 實體包括實體報頭域與實體正文,而有些應(yīng)答只包括實體報頭。
1. 實體報頭域——entity-header = Allow | Content-Encoding| Content-Language| Content-Length | Content-Location| Content-MD5| Content-Range| Content-Type| Expires| Last-Modified| extension-header
extension-header = message-header
2. 實體正文——entity-body = *OCTET
entity-body := Content-Encoding( Content-Type( data ) )
八、 連接(connection)
1. 持續(xù)連接——優(yōu)點
持續(xù)連接是任何HTTP連接的缺省方式,支持持續(xù)連接的客戶機可以以流水線方式發(fā)送請求
代理服務(wù)器
2. 消息傳遞要求——持續(xù)連接與流量控制
監(jiān)視連接中出錯狀態(tài)的消息
100號狀態(tài)的用途
服務(wù)器過早關(guān)閉連接時客戶機的動作
九、 方法定義(method definitions)
1. 安全和等冪方法
安全方法——GET和HEAD方法除了補救外不應(yīng)該有別的采取措施的含義
等冪方法——沒有副作用的序列是等冪的
2. OPTIONS——OPTIONS方法代表在請求URI確定的請求/應(yīng)答過程中通信條件是否可行的信息
3. GET——GET方法說明了重建信息的內(nèi)容由請求URI來確定
4. HEAD——除了應(yīng)答中禁止返回消息正文外,HEAD方法與GET方法一樣
5. POST——POST方法實現(xiàn)的實際功能取決于服務(wù)器
6. PUT——PUT方法要求所附實體存儲在提供的請求URI下
7. DELETE——DELELE方法要求原服務(wù)器釋放請求URI指向的資源
8. TRACE——TRACE方法用于調(diào)用遠程的應(yīng)用層循環(huán)請求消息
9. CONNECT——CONNECT方法用于能動態(tài)建立起隧道的代理服務(wù)器
十、 狀態(tài)碼定義(status code definitions)
1. 信息1XX——
100繼續(xù)
101轉(zhuǎn)換協(xié)議
2. 成功2XX——
200請求成功
201創(chuàng)建
202接受
203非權(quán)威信息
204無內(nèi)容
205重置內(nèi)容
206局部內(nèi)容
3. 重新定向3XX——
300多樣選擇
301永久移動
302創(chuàng)立
303觀察別的部分
304只讀
306(沒有用的)
307臨時重發(fā)
4. 客戶錯誤4xx——
400壞請求
401未授權(quán)的
402必需的支付
403禁用
404沒有找到
405不被允許的方法
406不接受
407代理服務(wù)器認證所必需
408請求超時
409沖突
410停止
411必需的長度
412預(yù)處理失敗
413請求實體太大
414請求的URI過長
415不被支持的媒體類型
416請求范圍不滿足
417期望失敗
5. 服務(wù)器錯誤5xx——
500服務(wù)器內(nèi)部錯誤
501不能實現(xiàn)
502壞網(wǎng)關(guān)
503難以獲得的服務(wù)
504網(wǎng)關(guān)超時
505 HTTP版本不支持
十一、 訪問驗證(access authentication)——可選擇
十二、 內(nèi)容談判(content negotiation)
HTTP為了"內(nèi)容談判"提供了一些機制,即當有很多種可能的表示時如何選擇對于一個請求的最佳的表示。
1. 服務(wù)器驅(qū)動談判——一個請求的最佳表示的選擇由服務(wù)器提供的運算法則來完成
2. 代理驅(qū)動談判——對于一個應(yīng)答的最佳表示法的選擇是在代理從原服務(wù)器端收到最初的應(yīng)答后實現(xiàn)的
3. 透明談判——透明的判斷是服務(wù)器驅(qū)動和代理驅(qū)動談判的結(jié)合體
十三、 HTTP中的緩存(caching in HTTP)
HTTP典型應(yīng)用于能通過采用緩存技術(shù)而提高性能的分布式信息系統(tǒng)
1. 緩存——
緩存正確性
警告信息
緩存控制機制
直接的用戶代理警告
規(guī)則和警告的例外情況
由客戶控制的行為
2. 過期模型——
服務(wù)器指定模型
啟發(fā)式過期
年齡計算
過期計算
澄清過期值
澄清多重響應(yīng)
3. 確認模型——當緩存器想要用一個失時效的條目來相應(yīng)客戶的請求,他首先必須向源服務(wù)器檢驗這一緩存條目是否仍然可用
最后修改日期
標簽緩存確認器
強弱控制器
關(guān)于何時使用實體標簽和最后修改時間的規(guī)則
不確認條件
4. 響應(yīng)的緩存能力——除非被明確限制,緩存系統(tǒng)可以將一成功的響應(yīng)作為緩存實體一直存儲
5. 從緩存構(gòu)造響應(yīng)——
端到端和Hop-by-hop報頭
不可更改報頭
聯(lián)合報頭
聯(lián)合字節(jié)范圍
6. 緩存談判響應(yīng)
7. 共享與非共享緩存
8. 錯誤和不完全響應(yīng)緩存行為
9. GET和 HEAD的副作用
10. 刷新或刪除后的無效性
11. 強制寫通過
12. 緩存替換
13. 歷史紀錄
十四、 報頭域定義(header field definitions)
1. Accept——Accept = "Accept" ":" #( media-range [ accept-params ] )
media-range = ( "*/*"| ( type "/" "*" )| ( type "/" subtype )) *( ";" parameter )
accept-params = ";" "q" "=" qvalue *( accept-extension )
accept-extension = ";" token [ "=" ( token | quoted-string ) ]
例1:Accept: audio/*; q=0.2, audio/basic
例2:Accept: text/plain; q=0.5, text/html, text/x-dvi; q=0.8, text/x-c
2. Accept-Charset——Accept-Charset = "Accept-Charset" ":" 1#( ( charset | "*" )[ ";" "q" "=" qvalue ] )
例:Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
3. Accept-Encoding——Accept-Encoding = "Accept-Encoding" ":" 1#( codings [ ";" "q" "=" qvalue ] )
codings = ( content-coding | "*" )
例:Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0
4. Accept-Language——Accept-Language = "Accept-Language" ":" 1#( language-range [ ";" "q" "=" qvalue ] )
language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" )
例:Accept-Language: da, en-gb;q=0.8, en;q=0.7
5. Accept-Range——Accept-Ranges = "Accept-Ranges" ":" acceptable-ranges
acceptable-ranges = 1#range-unit | "none"
例:Accept-Ranges: bytes
6. Age——Age = "Age" ":" age-value
age-value = delta-seconds
7. Allow——Allow = "Allow" ":" #Method
例:Allow: GET, HEAD, PUT
8. Authorization——Authorization = "Authorization" ":" credentials
9. Cache-Control——Cache-Control = "Cache-Control" ":" 1#cache-directive
cache-directive = cache-request-directive| cache-response-directive
cache-request-directive ="no-cache"| "no-store"| "max-age" "=" delta-seconds| "max-stale" [ "=" delta-seconds ]| "min-fresh" "=" delta-seconds| "no-transform"| "only-if-cached"| cache-extension
cache-response-directive ="public"| "private" [ "=" <"> 1#field-name <"> ]| "no-cache" [ "=" <"> 1#field-name <"> ]| "no-store"| "no-transform"| "must-revalidate"| "proxy-revalidate"| "max-age" "=" delta-seconds| "s-maxage" "=" delta-seconds| cache-extension
cache-extension = token [ "=" ( token | quoted-string ) ]
什么是可緩存的
哪些可能被緩存保存
對基本過期失效機制的改進
緩存重新確認有效和重載控制
不得轉(zhuǎn)換的指令
緩存控制擴展
10. Connection——Connection = "Connection" ":" 1#(connection-token)
connection-token = token
例:Connection: close
11. Content-Encoding——Content-Encoding = "Content-Encoding" ":" 1#content-coding
例:Content-Encoding: gzip
12. Content-Language——Content-Language = "Content-Language" ":" 1#language-tag
例:Content-Language: mi, en
13. Content-Length——Content-Length = "Content-Length" ":" 1*DIGIT
Content-Length: 3495
14. Content-Location——Content-Location = "Content-Location" ":"( absoluteURI | relativeURI )
15. Content-MD5——Content-MD5 = "Content-MD5" ":" md5-digest
md5-digest = <base64 of 128 bit MD5 digest as per RFC 1864>
16. Content-Range——Content-Range = "Content-Range" ":" content-range-spec
content-range-spec = byte-content-range-spec
byte-content-range-spec = bytes-unit SP byte-range-resp-spec "/"( instance-length | "*" )
byte-range-resp-spec = (first-byte-pos "-" last-byte-pos) | "*"
instance-length = 1*DIGIT
例:The first 500 bytes:bytes 0-499/1234
17. Content-Type——Content-Type = "Content-Type" ":" media-type
例:Content-Type: text/html; charset=ISO-8859-4
18. Date——Date = "Date" ":" HTTP-date
例:Date: Tue, 15 Nov 1994 08:12:31 GMT
沒有時鐘的原服務(wù)器的運作
19. Etag——ETag = "ETag" ":" entity-tag
例:ETag: W/"xyzzy"
20. Expect——Expect = "Expect" ":" 1#expectation
expectation = "100-continue" | expectation-extension
expectation-extension = token [ "=" ( token | quoted-string )*expect-params ]
expect-params = ";" token [ "=" ( token | quoted-string ) ]
21. Expires——Expires = "Expires" ":" HTTP-date
例:Expires: Thu, 01 Dec 1994 16:00:00 GMT
22. From——From = "From" ":" mailbox
例:From: webmaster@w3.org
23. Host——Host = "Host" ":" host [ ":" port ] ; Section 3.2.2
24. If-Match——If-Match = "If-Match" ":" ( "*" | 1#entity-tag )
例:If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
25. If-Modified-Since——If-Modified-Since = "If-Modified-Since" ":" HTTP-date
例:If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
26. If-None-Match ——If-None-Match = "If-None-Match" ":" ( "*" | 1#entity-tag )
例:If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"
27. If-Range ——If-Range = "If-Range" ":" ( entity-tag | HTTP-date )
28. If-Unmodified-Since ——If-Unmodified-Since = "If-Unmodified-Since" ":" HTTP-date
例:If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
29. Last-Modified ——Last-Modified = "Last-Modified" ":" HTTP-date
例:Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
30. Location ——Location = "Location" ":" absoluteURI
Location: http://www.w3.org/pub/WWW/People.html
31. Max-Forwards ——Max-Forwards = "Max-Forwards" ":" 1*DIGIT
32. Pragma ——Pragma = "Pragma" ":" 1#pragma-directive
pragma-directive = "no-cache" | extension-pragma
extension-pragma = token [ "=" ( token | quoted-string ) ]
33. Proxy-Authenticate ——Proxy-Authenticate = "Proxy-Authenticate" ":" 1#challenge
34. Proxy-Authorization ——Proxy-Authorization = "Proxy-Authorization" ":" credentials
35. Range——字節(jié)范圍
范圍檢索請求
Range = "Range" ":" ranges-specifier
36. Referer——Referer = "Referer" ":" ( absoluteURI | relativeURI )
37. Retry-After ——Retry-After = "Retry-After" ":" ( HTTP-date | delta-seconds )
38. Server ——Server = "Server" ":" 1*( product | comment )
39. TE ——TE = "TE" ":" #( t-codings )
t-codings = "trailers" | ( transfer-extension [ accept-params ] )
例:TE: trailers, deflate;q=0.5
40. Trailer ——Trailer = "Trailer" ":" 1#field-name
41. Transfer-Encoding ——Transfer-Encoding = "Transfer-Encoding" ":" 1#transfer-coding
例:Transfer-Encoding: chunked
42. Upgrade——Upgrade = "Upgrade" ":" 1#product
例:Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
43. User-Agent ——User-Agent = "User-Agent" ":" 1*( product | comment )
例:User-Agent: CERN-LineMode/2.15 libwww/2.17b3
44. Vary ——Vary = "Vary" ":" ( "*" | 1#field-name )
45. Via ——Via = "Via" ":" 1#( received-protocol received-by [ comment ] )
received-protocol = [ protocol-name "/" ] protocol-version
protocol-name = token
protocol-version = token
received-by = ( host [ ":" port ] ) | pseudonym
pseudonym = token
例:Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
46. Warning = "Warning" ":" 1#warning-value
warning-value = warn-code SP warn-agent SP warn-text [SP warn-date]
warn-code = 3DIGIT
warn-agent = ( host [ ":" port ] ) | pseudonym
warn-text = quoted-string
warn-date = <"> HTTP-date <">
47. WWW-Authenticate ——WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge
十五、 安全考慮(security considerations)
一些建議,但是并不包括最終解決方案
1. 個人信息
服務(wù)器日志信息的濫用
敏感信息的傳輸
URI中敏感信息的編碼
連接到Accept報頭的機要問題
2. 基于文件和路徑名稱的攻擊
3. DNS欺騙
4. Location(位置)報頭和欺騙
5. 內(nèi)容傾向問題
6. 鑒定證書和空閑的客戶機
7. 代理服務(wù)器和高速緩存
對代理服務(wù)器的拒絕服務(wù)攻擊
十六、 感謝
十七、 參考文獻
十八、 作者地址
十九、 附錄
posted @ 2008-12-29 14:11 井中月 閱讀(1051) | 評論 (0) | 編輯 收藏
posted @ 2008-12-29 14:10 井中月 閱讀(1190) | 評論 (0) | 編輯 收藏
針對此情況而衍生出來的一種廉價有效透明的方法以擴展現(xiàn)有網(wǎng)絡(luò)設(shè)備和服務(wù)器的帶寬、增加吞吐量、加強網(wǎng)絡(luò)數(shù)據(jù)處理能力、提高網(wǎng)絡(luò)的來實現(xiàn)的,在DNS中為多個地址配置同一個名字,因而查詢這個名字的客戶機將得到其中一個地址,從而使得不同的客戶訪問不同的服務(wù)器,達到負載均衡的目的。DNS負載均衡是一種簡單而有效的方法,但是它不能區(qū)分服務(wù)器的差異,也不能反映服務(wù)器的當前運行狀態(tài)。
2、代理服務(wù)器負載均衡 使用代理服務(wù)器,可以將請求轉(zhuǎn)發(fā)給內(nèi)部的服務(wù)器,使用這種加速模式顯然可以提升靜態(tài)網(wǎng)頁的訪問速度。然而,也可以考慮這樣一種技術(shù),使用代理服務(wù)器將請求均勻轉(zhuǎn)發(fā)給多臺服務(wù)器,從而達到負載均衡的目的。
3、地址轉(zhuǎn)換網(wǎng)關(guān)負載均衡 支持負載均衡的地址轉(zhuǎn)換網(wǎng)關(guān),可以將一個外部IP地址映射為多個內(nèi)部IP地址,對每次TCP連接請求動態(tài)使用其中一個內(nèi)部地址,達到負載均衡的目的。
4、協(xié)議內(nèi)部支持負載均衡 除了這三種負載均衡方式之外,有的協(xié)議內(nèi)部支持與負載均衡相關(guān)的功能,例如HTTP協(xié)議中的重定向能力等,HTTP運行于TCP連接的最高層。
5、NAT負載均衡 NAT(Network Address Translation 網(wǎng)絡(luò)地址轉(zhuǎn)換)簡單地說就是將一個IP地址轉(zhuǎn)換為另一個IP地址,一般用于未經(jīng)注冊的內(nèi)部地址與合法的、已獲注冊的Internet IP地址間進行轉(zhuǎn)換。適用于解決Internet IP地址緊張、不想讓網(wǎng)絡(luò)外部知道內(nèi)部網(wǎng)絡(luò)結(jié)構(gòu)等的場合下。
此種負載均衡是當前多WAN口路由器的帶寬匯聚技術(shù)基礎(chǔ),以欣向路由器為例:
欣向的多WAN路由器實現(xiàn)的是業(yè)界先進的動態(tài)負載平衡機制,我們獨立研發(fā)的多WAN口動態(tài)負載平衡技術(shù),使得在使用多條線路的情況下動態(tài)分配內(nèi)網(wǎng)的數(shù)據(jù)流量,動態(tài)的實現(xiàn)帶寬匯聚的功能,采用特有的三種負載平衡機制:
a.Session:所有啟用的WAN口,采用均分session的方式工作。
如第一個連接session通過WAN1口流出,則下一個session自動選擇WAN2流出,第三個session選擇WAN3口流出(假設(shè)所有WAN口都啟用)
這種方式適用于多條相同帶寬的線路捆綁時使用。
b.Round robin:同樣是根據(jù)session數(shù)目調(diào)整負載,但比例可調(diào)。
如將比例設(shè)為1:2:3:4,則按如下規(guī)則處理:
第1個session選擇WAN1口(session數(shù)=1);
第2,3個 session選擇WAN2口(session數(shù)=2);
第4 ~ 6個 session 選擇WAN3口(session數(shù)=3);
第7 ~ 10個session選擇WAN4口(session數(shù)=4);
這種方式適用于多條不同帶寬的線路能夠更好的協(xié)同工作。例如:WAN1口接一條512K的ADSL,WAN2口接2M的光纖,這種情況下我們就可以把比例設(shè)為1:4,這樣能夠充分利用兩條線路的帶寬。
c.Traffic:按數(shù)據(jù)流量分配負載,系統(tǒng)自動選擇流量最小的WAN口作為出口。
此種方式適用于線路不穩(wěn)定時的多條線路混用的情況。在某一條線路暫時不通或者線路不穩(wěn)定的情況下會把流量自動分配到另一條穩(wěn)定的線路上。但在多條線路穩(wěn)定的情況下不建議使用這種方式。
有了這三種負載平衡使得路由器可以靈活的應(yīng)對多種線路混用的復(fù)雜情況,支持多種線路混接,支持多種協(xié)議,能夠滿足多種復(fù)雜應(yīng)用。
6、反向代理負載均衡 普通代理方式是代理內(nèi)部網(wǎng)絡(luò)用戶訪問internet上服務(wù)器的連接請求,客戶端必須指定代理服務(wù)器,并將本來要直接發(fā)送到internet上服務(wù)器的連接請求發(fā)送給代理服務(wù)器處理。反向代理(Reverse Proxy)方式是指以代理服務(wù)器來接受internet上的連接請求,然后將請求轉(zhuǎn)發(fā)給內(nèi)部網(wǎng)絡(luò)上的服務(wù)器,并將從服務(wù)器上得到的結(jié)果返回給internet上請求連接的客戶端,此時代理服務(wù)器對外就表現(xiàn)為一個服務(wù)器。反向代理負載均衡技術(shù)是把將來自internet上的連接請求以反向代理的方式動態(tài)地轉(zhuǎn)發(fā)給內(nèi)部網(wǎng)絡(luò)上的多臺服務(wù)器進行處理,從而達到負載均衡的目的。
7、混合型負載均衡 在有些大型網(wǎng)絡(luò),由于多個服務(wù)器群內(nèi)硬件設(shè)備、各自的規(guī)模、提供的服務(wù)等的差異,我們可以考慮給每個服務(wù)器群采用最合適的負載均衡方式,然后又在這多個服務(wù)器群間再一次負載均衡或群集起來以一個整體向外界提供服務(wù)(即把這多個服務(wù)器群當做一個新的服務(wù)器群),從而達到最佳的性能。我們將這種方式稱之為混合型負載均衡。此種方式有時也用于單臺均衡設(shè)備的性能不能滿足大量連接請求的情況下。
posted @ 2008-12-29 14:09 井中月 閱讀(811) | 評論 (0) | 編輯 收藏
posted @ 2008-12-29 14:03 井中月 閱讀(151358) | 評論 (19) | 編輯 收藏
網(wǎng)址:http://scripteka.com/
該站是一個專門介紹Prototype框架擴展庫的站點。
posted @ 2008-12-29 11:53 井中月 閱讀(401) | 評論 (0) | 編輯 收藏