posted @ 2008-12-29 14:22 井中月 閱讀(590) | 評論 (0) | 編輯 收藏
HTTP協議(http://www.w3.org/Protocols/)是“一次性單向”協議。
服務端不能主動連接客戶端,只能被動等待并答復客戶端請求。客戶端連接服務端,發出一個HTTP Request,服務端處理請求,并且返回一個HTTP Response給客戶端,本次HTTP Request-Response Cycle結束。
我們看到,HTTP協議本身并不能支持服務端保存客戶端的狀態信息。于是,Web Server中引入了session的概念,用來保存客戶端的狀態信息。
這里用一個形象的比喻來解釋session的工作方式。假設Web Server是一個商場的存包處,HTTP Request是一個顧客,第一次來到存包處,管理員把顧客的物品存放在某一個柜子里面(這個柜子就相當于Session),然后把一個號碼牌交給這個顧客,作為取包憑證(這個號碼牌就是Session ID)。顧客(HTTP Request)下一次來的時候,就要把號碼牌(Session ID)交給存包處(Web Server)的管理員。管理員根據號碼牌(Session ID)找到相應的柜子(Session),根據顧客(HTTP Request)的請求,Web Server可以取出、更換、添加柜子(Session)中的物品,Web Server也可以讓顧客(HTTP Request)的號碼牌和號碼牌對應的柜子(Session)失效。顧客(HTTP Request)的忘性很大,管理員在顧客回去的時候(HTTP Response)都要重新提醒顧客記住自己的號碼牌(Session ID)。這樣,顧客(HTTP Request)下次來的時候,就又帶著號碼牌回來了。
我們可以看到,Session ID實際上是在客戶端和服務端之間通過HTTP Request和HTTP Response傳來傳去的。
我們看到,號碼牌(Session ID)必須包含在HTTP Request里面。關于HTTP Request的具體格式,請參見HTTP協議(http://www.w3.org/Protocols/)。這里只做一個簡單的介紹。
在Java Web Server(即Servlet/JSP Server)中,Session ID用jsessionid表示(請參見Servlet規范)。
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的結果,
那么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,所以這種方法不通用。
一般用來實現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的典型應用是存放用戶的Login信息,如用戶名,密碼,權限角色等信息,應用程序(如Email服務、網上銀行等系統)根據這些信息進行身份驗證和權限驗證
posted @ 2008-12-29 14:14 井中月 閱讀(1128) | 評論 (0) | 編輯 收藏
1、HTTP 只有POST和GET 兩種命令模式;
2、POST是被設計用來向上放東西的,而GET是被設計用來從服務器取東西的,GET也能夠向服務器傳送較少的數據,而Get之所以也能傳送數據,只是用來設計告訴服務器,你到底需要什么樣的數據.POST的信息作為HTTP 請求的內容,而GET是在HTTP 頭部傳輸的;
3、POST與GET在HTTP 中傳送的方式不同,GET的參數是在HTTP 的頭部傳送的,而Post的數據則是在HTTP 請求的內容里傳送;
4、POST傳輸數據時,不需要在URL中顯示出來,而GET方法要在URL中顯示;
5、GET方法由于受到URL長度的限制,只能傳遞大約1024字節;POST傳輸的數據量大,可以達到2M,而根據微軟方面的說法,微軟對用 Request.Form() 可接收的最大數據有限制,IIS 4 中為 80 KB 字節,IIS 5 中為 100 KB 字節;
6、SOAP是依賴于HTTP POST模式實現的;
例子:
HTTP GET
發送
GET /DEMOWebServices2.8/Service.asmx/CancelOrder?UserID=string&PWD=string&OrderConfirmation=string HTTP/1.1
Host: api.efxnow.com
回復
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
發送
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
回復
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
發送
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>
回復
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 井中月 閱讀(3688) | 評論 (0) | 編輯 收藏
HTTP請求包括三部分:請求行(Request Line),頭部(Headers)和數據體(Body)。其中,請求行由請求方法(method),請求網址Request-URI和協議 (Protocol)構成,而請求頭包括多個屬性,數據體則可以被認為是附加在請求之后的文本或二進制文件。
下面這個例子顯示了一個HTTP請求的Header內容,這些數據是真正以網絡HTTP協議從IE瀏覽器傳遞到Apache服務器上的。
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沒有出現。我們參考這個例子具體解釋HTTP請求格式。
1.HTTP請求行:請求行格式為Method Request-URI Protocol。在上面這個例子里,“GET /icwork/? search=pruduct HTTP/1.1”是請求行。
2.Accept:指瀏覽器或其他客戶可以接愛的MIME文件格式。Servlet可以根據它判斷并返回適當的文件格式。
3.Accept-Charset:指出瀏覽器可以接受的字符編碼。英文瀏覽器的默認值是ISO-8859-1.
4.Accept-Language:指出瀏覽器可以接受的語言種類,如en或en-us,指英語。
5.Accept-Encoding:指出瀏覽器可以接受的編碼方式。編碼方式不同于文件格式,它是為了壓縮文件并加速文件傳遞速度。瀏覽器在接收到Web響應之后先解碼,然后再檢查文件格式。
6.Authorization:當使用密碼機制時用來標識瀏覽器。
7.Cache-Control:設置關于請求被代理服務器存儲的相關選項。一般servlet用不到。
8.Connection:用來告訴服務器是否可以維持固定的HTTP連接。HTTP/1.1使用Keep-Alive為默認值,這樣,當瀏覽器需要多個文件時(比如一個HTML文件和相關的圖形文件),不需要每次都建立連接。
9.Content-Type:用來表名request的內容類型。可以用HttpServletRequest的getContentType()方法取得。
10.Cookie:瀏覽器用這個屬性向服務器發送Cookie。Cookie是在瀏覽器中寄存的小型數據體,它可以記載和服務器相關的用戶信息,也可以用來實現會話功能。
11.Expect:表時客戶預期的響應狀態。
12.From:給出客戶端HTTP請求負責人的email地址。
13.Host:對應網址URL中的Web名稱和端口號。
14.If-Match:供PUT方法使用。
15.If-Modified-Since:客戶使用這個屬性表明它只需要在指定日期之后更改過的網頁。因為瀏覽器可以使用其存儲的文件而不必從服務器請求,這樣節省了Web資源。由于Servlet是動態生成的網頁,一般不需要使用這個屬性。
16.If-None-Match:和If-Match相反的操作,供PUT方法使用。
17.If-Unmodified-Since:和If-Match-Since相反。
18.Pragma:這個屬性只有一種值,即Pragma:no-cache,表明如果servlet充當代理服務器,即使其有已經存儲的網頁,也要將請求傳遞給目的服務器。
19.Proxy-Authorization:代理服務器使用這個屬性,Servlet一般用不到。
20.Range:如果客戶有部分網頁,這個屬性可以請求剩余部分。
21.Referer:表明產生請求的網頁URL。如比從網頁/icconcept/index.jsp中點擊一個鏈接到網頁/icwork/search,在向服務器發送的GET/icwork/search中的請求中,Referer是http://hostname:8080/icconcept/index.php。這個屬性可以用來跟蹤Web請求是從什么網站來的。
22.Upgrage:客戶通過這個屬性設定可以使用與HTTP/1.1不同的協議。
23.User-Agent:是客戶瀏覽器名稱。
24.Via:用來記錄Web請求經過的代理服務器或Web通道。
25.Warning:用來由客戶聲明傳遞或存儲(cache)錯誤。
posted @ 2008-12-29 14:13 井中月 閱讀(520) | 評論 (0) | 編輯 收藏
HTTP(HyperText Transfer Protocol)是一套計算機通過網絡進行通信的規則。計算機專家設計出HTTP,使HTTP客戶(如Web瀏覽器)能夠從HTTP服務器(Web服務器)請求信息和服務,HTTP目前協議的版本是1.1.HTTP是一種無狀態的協議,無狀態是指Web瀏覽器和Web服務器之間不需要建立持久的連接,這意味著當一個客戶端向服務器端發出請求,然后Web服務器返回響應(response),連接就被關閉了,在服務器端不保留連接的有關信息.HTTP遵循請求(Request)/應答(Response)模型。Web瀏覽器向Web服務器發送請求,Web服務器處理請求并返回適當的應答。所有HTTP連接都被構造成一套請求和應答。
HTTP使用內容類型,是指Web服務器向Web瀏覽器返回的文件都有與之相關的類型。所有這些類型在MIME Internet郵件協議上模型化,即Web服務器告訴Web瀏覽器該文件所具有的種類,是HTML文檔、GIF格式圖像、聲音文件還是獨立的應用程序。大多數Web瀏覽器都擁有一系列的可配置的輔助應用程序,它們告訴瀏覽器應該如何處理Web服務器發送過來的各種內容類型。
HTTP通信機制是在一次完整的HTTP通信過程中,Web瀏覽器與Web服務器之間將完成下列7個步驟:
(1) 建立TCP連接
在HTTP工作開始之前,Web瀏覽器首先要通過網絡與Web服務器建立連接,該連接是通過TCP來完成的,該協議與IP協議共同構建Internet,即著名的TCP/IP協議族,因此Internet又被稱作是TCP/IP網絡。HTTP是比TCP更高層次的應用層協議,根據規則,只有低層協議建立之后才能,才能進行更層協議的連接,因此,首先要建立TCP連接,一般TCP連接的端口號是80
(2) Web瀏覽器向Web服務器發送請求命令
一旦建立了TCP連接,Web瀏覽器就會向Web服務器發送請求命令
例如:GET/sample/hello.jsp HTTP/1.1
(3) Web瀏覽器發送請求頭信息
瀏覽器發送其請求命令之后,還要以頭信息的形式向Web服務器發送一些別的信息,之后瀏覽器發送了一空白行來通知服務器,它已經結束了該頭信息的發送。
(4) Web服務器應答
客戶機向服務器發出請求后,服務器會客戶機回送應答,
HTTP/1.1 200 OK
應答的第一部分是協議的版本號和應答狀態碼
(5) Web服務器發送應答頭信息
正如客戶端會隨同請求發送關于自身的信息一樣,服務器也會隨同應答向用戶發送關于它自己的數據及被請求的文檔。
(6) Web服務器向瀏覽器發送數據
Web服務器向瀏覽器發送頭信息后,它會發送一個空白行來表示頭信息的發送到此為結束,接著,它就以Content-Type應答頭信息所描述的格式發送用戶所請求的實際數據
(7) Web服務器關閉TCP連接
一般情況下,一旦Web服務器向瀏覽器發送了請求數據,它就要關閉TCP連接,然后如果瀏覽器或者服務器在其頭信息加入了這行代碼
Connection:keep-alive
TCP連接在發送后將仍然保持打開狀態,于是,瀏覽器可以繼續通過相同的連接發送請求。保持連接節省了為每個請求建立新連接所需的時間,還節約了網絡帶寬。
HTTP請求格式
當瀏覽器向Web服務器發出請求時,它向服務器傳遞了一個數據塊,也就是請求信息,HTTP請求信息由3部分組成:
l 請求方法URI協議/版本
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協議/版本
請求的第一行是“方法URL議/版本”:GET/sample.jsp HTTP/1.1
以上代碼中“GET”代表請求方法,“/sample.jsp”表示URI,“HTTP/1.1代表協議和協議的版本。
根據HTTP標準,HTTP請求可以使用多種請求方法。例如:HTTP1.1支持7種請求方法:GET、POST、HEAD、OPTIONS、PUT、DELETE和TARCE。在Internet應用中,最常用的方法是GET和POST。
URL完整地指定了要訪問的網絡資源,通常只要給出相對于服務器的根目錄的相對目錄即可,因此總是以“/”開頭,最后,協議版本聲明了通信過程中使用HTTP的版本。
(2) 請求頭(Request Header)
請求頭包含許多有關的客戶端環境和請求正文的有用信息。例如,請求頭可以聲明瀏覽器所用的語言,請求正文的長度等。
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) 請求正文
請求頭和請求正文之間是一個空行,這個行非常重要,它表示請求頭已經結束,接下來的是請求正文。請求正文中可以包含客戶提交的查詢字符串信息:
username=jinqiao&password=1234
在以上的例子的HTTP請求中,請求的正文只有一行內容。當然,在實際應用中,HTTP請求正文可以包含更多的內容。
HTTP請求方法我這里只討論GET方法與POST方法
GET方法
GET方法是默認的HTTP請求方法,我們日常用GET方法來提交表單數據,然而用GET方法提交的表單數據只經過了簡單的編碼,同時它將作為URL的一部分向Web服務器發送,因此,如果使用GET方法來提交表單數據就存在著安全隱患上。例如
Http://127.0.0.1/login.jsp?Name=zhangshi&Age=30&Submit=%cc%E+%BD%BB
從上面的URL請求中,很容易就可以辯認出表單提交的內容。(?之后的內容)另外由于GET方法提交的數據是作為URL請求的一部分所以提交的數據量不能太大
POST方法
POST方法是GET方法的一個替代方法,它主要是向Web服務器提交表單數據,尤其是大批量的數據。POST方法克服了GET方法的一些缺點。通過POST方法提交表單數據時,數據不是作為URL請求的一部分而是作為標準數據傳送給Web服務器,這就克服了GET方法中的信息無法保密和數據量太小的缺點。因此,出于安全的考慮以及對用戶隱私的尊重,通常表單提交時采用POST方法。
從編程的角度來講,如果用戶通過GET方法提交數據,則數據存放在QUERY_STRING環境變量中,而POST方法提交的數據則可以從標準輸入流中獲取。
HTTP應答與HTTP請求相似,HTTP響應也由3個部分構成,分別是:
l 協議狀態版本代碼描述
l 響應頭(Response Header)
l 響應正文
下面是一個HTTP響應的例子:
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響應示例<title>
</head>
<body>
Hello HTTP!
</body>
</html>
協議狀態代碼描述HTTP響應的第一行類似于HTTP請求的第一行,它表示通信所用的協議是HTTP1.1服務器已經成功的處理了客戶端發出的請求(200表示成功):
HTTP/1.1 200 OK
響應頭(Response Header)響應頭也和請求頭一樣包含許多有用的信息,例如服務器類型、日期時間、內容類型和長度等:
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
響應正文響應正文就是服務器返回的HTML頁面:
<html>
<head>
<title>HTTP響應示例<title>
</head>
<body>
Hello HTTP!
</body>
</html>
響應頭和正文之間也必須用空行分隔。
HTTP應答碼
HTTP應答碼也稱為狀態碼,它反映了Web服務器處理HTTP請求狀態。HTTP應答碼由3位數字構成,其中首位數字定義了應答碼的類型:
1XX-信息類(Information),表示收到Web瀏覽器請求,正在進一步的處理中
2XX-成功類(Successful),表示用戶請求被正確接收,理解和處理例如:200 OK
3XX-重定向類(Redirection),表示請求沒有成功,客戶必須采取進一步的動作。
4XX-客戶端錯誤(Client Error),表示客戶端提交的請求有錯誤 例如:404 NOT Found,意味著請求中所引用的文檔不存在。
5XX-服務器錯誤(Server Error)表示服務器不能完成對請求的處理:如 500
對于我們Web開發人員來說掌握HTTP應答碼有助于提高Web應用程序調試的效率和準確性。
安全連接
Web應用最常見的用途之一是電子商務,可以利用Web服務器端程序使人們能夠網絡購物,需要指出一點是,缺省情況下,通過Internet發送信息是不安全的,如果某人碰巧截獲了你發給朋友的一則消息,他就能打開它,假想在里面有你的信用卡號碼,這會有多么糟糕,幸運的是,很多Web服務器以及Web瀏覽器都有創立安全連接的能力,這樣它們就可以安全的通信了。
通過Internet提供安全連接最常見的標準是安全套接層(Secure Sockets layer,SSl)協議。SSL協議是一個應用層協議(和HTTP一樣),用于安全方式在Web上交換數據,SSL使用公開密鑰編碼系統。從本質講,這意味著業務中每一方都擁有一個公開的和一個私有的密鑰。當一方使用另一方公開密鑰進行編碼時,只有擁有匹配密鑰的人才能對其解碼。簡單來講,公開密鑰編碼提供了一種用于在兩方之間交換數據的安全方法,SSL連接建立之后,客戶和服務器都交換公開密鑰,并在進行業務聯系之前進行驗證,一旦雙方的密鑰都通過驗證,就可以安全地交換數據。
posted @ 2008-12-29 14:12 井中月 閱讀(547) | 評論 (0) | 編輯 收藏
一、介紹(introduction)
1. 目的——HTTP/0.9-〉HTTP/1.0-〉HTTP/1.1
2. 要求——MUST、REQUIRED、SHOULD
3. 術語——連接(Connection)、消息(Message)、請求(Request)、應答(Response)、資源(Resource)、實體(Entity)、表示方法(Representation)、內容協商(Content Negotiation)、變量(Variant)、客戶機(Client)、用戶代理(User agent)、服務器(Server)、原服務器(Origin server)、代理服務器( Proxy)、網關(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)、向內/向外(inbound/outbound)
4. 總體操作——請求/應答、中介
二、符號慣例與一般語法(notational conversions and generic grammar)
1. 擴充BNF——name = definition,"literal",rule1 | rule2,(rule1 rule2),*rule,[rule],N rule, #rule,; comment, implied *LWS
2. 基本規則——OCTET,CHAR,UPALPHA,LOALPHA,ALPHA,DIGIT,CTL,CR,LF,SP,HT,<">
三、協議參數(protocol parameters)
1. HTTP版本——HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT
2. 統一資源標示符(URI)——統一資源定位器(URL)和統一資源名稱(URN)的結合,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. 字符集——本文檔中的術語"字符集"指一種用一個或更多表格將一個八字節序列轉換成一個字符序列的方法,
charset=token
失蹤字符集
5. 內容編碼——內容編碼主要用來允許文檔壓縮(信源編碼)
content-coding= token
注冊表包含下列標記:gzip,compress,deflate,identity
6. 傳輸編碼——目的是能夠確保通過網絡安全傳輸(信道編碼)
transfer-coding = "chunked" | transfer-extension
transfer-extension = token *( ";" parameter ),
成塊傳輸代碼
7. 媒體類型——media-type = type "/" subtype *( ";" parameter )
type = token
subtype = token
規范化和原文缺省
多部分類型
8. 產品標記——product = token ["/" product-version]
product-version = token
9. 質量值——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頭域包括常規頭,請求頭,應答頭和實體頭域
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. 常規頭域——general-header = Cache-Control| Connection| Date| Pragma| Transfer-Encoding
五、 請求(request)
首行包括利用資源的方式,區分資源的標識,以及協議的版本號
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所指定的資源上所實現的方式
Method = "OPTIONS"| "GET"| "POST"| "PUT"| "DELETE"| "TRACE"| "CONNECT"| extension-method
extension-method = token
請求URL——請求URL是一種全球統一的應用于資源請求的資源標識符
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
六、 應答(response)
接收和翻譯一個請求信息后,服務器發出一個HTTP應答信息
Response = Status-Line*(( general-header| response-header| entity-header ) CRLF) CRLF [ message-body ]
1. 狀態行——Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
狀態碼——狀態碼是試圖理解和滿足請求的三位數字的整數碼,1xx,2xx,3xx,4xx,5xx,100-〉505-〉擴展碼
2. 應答報頭域——response-header = Accept-Ranges| Age| Location| Proxy-Authenticate| Retry-After| Server| Vary| WWW-Authenticate
七、 實體(entity)
在未經特別規定的情況下,請求與應答的消息也可以傳送實體。 實體包括實體報頭域與實體正文,而有些應答只包括實體報頭。
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. 持續連接——優點
持續連接是任何HTTP連接的缺省方式,支持持續連接的客戶機可以以流水線方式發送請求
代理服務器
2. 消息傳遞要求——持續連接與流量控制
監視連接中出錯狀態的消息
100號狀態的用途
服務器過早關閉連接時客戶機的動作
九、 方法定義(method definitions)
1. 安全和等冪方法
安全方法——GET和HEAD方法除了補救外不應該有別的采取措施的含義
等冪方法——沒有副作用的序列是等冪的
2. OPTIONS——OPTIONS方法代表在請求URI確定的請求/應答過程中通信條件是否可行的信息
3. GET——GET方法說明了重建信息的內容由請求URI來確定
4. HEAD——除了應答中禁止返回消息正文外,HEAD方法與GET方法一樣
5. POST——POST方法實現的實際功能取決于服務器
6. PUT——PUT方法要求所附實體存儲在提供的請求URI下
7. DELETE——DELELE方法要求原服務器釋放請求URI指向的資源
8. TRACE——TRACE方法用于調用遠程的應用層循環請求消息
9. CONNECT——CONNECT方法用于能動態建立起隧道的代理服務器
十、 狀態碼定義(status code definitions)
1. 信息1XX——
100繼續
101轉換協議
2. 成功2XX——
200請求成功
201創建
202接受
203非權威信息
204無內容
205重置內容
206局部內容
3. 重新定向3XX——
300多樣選擇
301永久移動
302創立
303觀察別的部分
304只讀
306(沒有用的)
307臨時重發
4. 客戶錯誤4xx——
400壞請求
401未授權的
402必需的支付
403禁用
404沒有找到
405不被允許的方法
406不接受
407代理服務器認證所必需
408請求超時
409沖突
410停止
411必需的長度
412預處理失敗
413請求實體太大
414請求的URI過長
415不被支持的媒體類型
416請求范圍不滿足
417期望失敗
5. 服務器錯誤5xx——
500服務器內部錯誤
501不能實現
502壞網關
503難以獲得的服務
504網關超時
505 HTTP版本不支持
十一、 訪問驗證(access authentication)——可選擇
十二、 內容談判(content negotiation)
HTTP為了"內容談判"提供了一些機制,即當有很多種可能的表示時如何選擇對于一個請求的最佳的表示。
1. 服務器驅動談判——一個請求的最佳表示的選擇由服務器提供的運算法則來完成
2. 代理驅動談判——對于一個應答的最佳表示法的選擇是在代理從原服務器端收到最初的應答后實現的
3. 透明談判——透明的判斷是服務器驅動和代理驅動談判的結合體
十三、 HTTP中的緩存(caching in HTTP)
HTTP典型應用于能通過采用緩存技術而提高性能的分布式信息系統
1. 緩存——
緩存正確性
警告信息
緩存控制機制
直接的用戶代理警告
規則和警告的例外情況
由客戶控制的行為
2. 過期模型——
服務器指定模型
啟發式過期
年齡計算
過期計算
澄清過期值
澄清多重響應
3. 確認模型——當緩存器想要用一個失時效的條目來相應客戶的請求,他首先必須向源服務器檢驗這一緩存條目是否仍然可用
最后修改日期
標簽緩存確認器
強弱控制器
關于何時使用實體標簽和最后修改時間的規則
不確認條件
4. 響應的緩存能力——除非被明確限制,緩存系統可以將一成功的響應作為緩存實體一直存儲
5. 從緩存構造響應——
端到端和Hop-by-hop報頭
不可更改報頭
聯合報頭
聯合字節范圍
6. 緩存談判響應
7. 共享與非共享緩存
8. 錯誤和不完全響應緩存行為
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 ) ]
什么是可緩存的
哪些可能被緩存保存
對基本過期失效機制的改進
緩存重新確認有效和重載控制
不得轉換的指令
緩存控制擴展
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
沒有時鐘的原服務器的運作
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——字節范圍
范圍檢索請求
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. 個人信息
服務器日志信息的濫用
敏感信息的傳輸
URI中敏感信息的編碼
連接到Accept報頭的機要問題
2. 基于文件和路徑名稱的攻擊
3. DNS欺騙
4. Location(位置)報頭和欺騙
5. 內容傾向問題
6. 鑒定證書和空閑的客戶機
7. 代理服務器和高速緩存
對代理服務器的拒絕服務攻擊
十六、 感謝
十七、 參考文獻
十八、 作者地址
十九、 附錄
posted @ 2008-12-29 14:11 井中月 閱讀(1051) | 評論 (0) | 編輯 收藏
posted @ 2008-12-29 14:10 井中月 閱讀(1191) | 評論 (0) | 編輯 收藏
針對此情況而衍生出來的一種廉價有效透明的方法以擴展現有網絡設備和服務器的帶寬、增加吞吐量、加強網絡數據處理能力、提高網絡的來實現的,在DNS中為多個地址配置同一個名字,因而查詢這個名字的客戶機將得到其中一個地址,從而使得不同的客戶訪問不同的服務器,達到負載均衡的目的。DNS負載均衡是一種簡單而有效的方法,但是它不能區分服務器的差異,也不能反映服務器的當前運行狀態。
2、代理服務器負載均衡 使用代理服務器,可以將請求轉發給內部的服務器,使用這種加速模式顯然可以提升靜態網頁的訪問速度。然而,也可以考慮這樣一種技術,使用代理服務器將請求均勻轉發給多臺服務器,從而達到負載均衡的目的。
3、地址轉換網關負載均衡 支持負載均衡的地址轉換網關,可以將一個外部IP地址映射為多個內部IP地址,對每次TCP連接請求動態使用其中一個內部地址,達到負載均衡的目的。
4、協議內部支持負載均衡 除了這三種負載均衡方式之外,有的協議內部支持與負載均衡相關的功能,例如HTTP協議中的重定向能力等,HTTP運行于TCP連接的最高層。
5、NAT負載均衡 NAT(Network Address Translation 網絡地址轉換)簡單地說就是將一個IP地址轉換為另一個IP地址,一般用于未經注冊的內部地址與合法的、已獲注冊的Internet IP地址間進行轉換。適用于解決Internet IP地址緊張、不想讓網絡外部知道內部網絡結構等的場合下。
此種負載均衡是當前多WAN口路由器的帶寬匯聚技術基礎,以欣向路由器為例:
欣向的多WAN路由器實現的是業界先進的動態負載平衡機制,我們獨立研發的多WAN口動態負載平衡技術,使得在使用多條線路的情況下動態分配內網的數據流量,動態的實現帶寬匯聚的功能,采用特有的三種負載平衡機制:
a.Session:所有啟用的WAN口,采用均分session的方式工作。
如第一個連接session通過WAN1口流出,則下一個session自動選擇WAN2流出,第三個session選擇WAN3口流出(假設所有WAN口都啟用)
這種方式適用于多條相同帶寬的線路捆綁時使用。
b.Round robin:同樣是根據session數目調整負載,但比例可調。
如將比例設為1:2:3:4,則按如下規則處理:
第1個session選擇WAN1口(session數=1);
第2,3個 session選擇WAN2口(session數=2);
第4 ~ 6個 session 選擇WAN3口(session數=3);
第7 ~ 10個session選擇WAN4口(session數=4);
這種方式適用于多條不同帶寬的線路能夠更好的協同工作。例如:WAN1口接一條512K的ADSL,WAN2口接2M的光纖,這種情況下我們就可以把比例設為1:4,這樣能夠充分利用兩條線路的帶寬。
c.Traffic:按數據流量分配負載,系統自動選擇流量最小的WAN口作為出口。
此種方式適用于線路不穩定時的多條線路混用的情況。在某一條線路暫時不通或者線路不穩定的情況下會把流量自動分配到另一條穩定的線路上。但在多條線路穩定的情況下不建議使用這種方式。
有了這三種負載平衡使得路由器可以靈活的應對多種線路混用的復雜情況,支持多種線路混接,支持多種協議,能夠滿足多種復雜應用。
6、反向代理負載均衡 普通代理方式是代理內部網絡用戶訪問internet上服務器的連接請求,客戶端必須指定代理服務器,并將本來要直接發送到internet上服務器的連接請求發送給代理服務器處理。反向代理(Reverse Proxy)方式是指以代理服務器來接受internet上的連接請求,然后將請求轉發給內部網絡上的服務器,并將從服務器上得到的結果返回給internet上請求連接的客戶端,此時代理服務器對外就表現為一個服務器。反向代理負載均衡技術是把將來自internet上的連接請求以反向代理的方式動態地轉發給內部網絡上的多臺服務器進行處理,從而達到負載均衡的目的。
7、混合型負載均衡 在有些大型網絡,由于多個服務器群內硬件設備、各自的規模、提供的服務等的差異,我們可以考慮給每個服務器群采用最合適的負載均衡方式,然后又在這多個服務器群間再一次負載均衡或群集起來以一個整體向外界提供服務(即把這多個服務器群當做一個新的服務器群),從而達到最佳的性能。我們將這種方式稱之為混合型負載均衡。此種方式有時也用于單臺均衡設備的性能不能滿足大量連接請求的情況下。
posted @ 2008-12-29 14:09 井中月 閱讀(812) | 評論 (0) | 編輯 收藏
posted @ 2008-12-29 14:03 井中月 閱讀(151359) | 評論 (19) | 編輯 收藏
網址:http://scripteka.com/
該站是一個專門介紹Prototype框架擴展庫的站點。
posted @ 2008-12-29 11:53 井中月 閱讀(402) | 評論 (0) | 編輯 收藏