自己動手寫Web容器之TomJetty之一:服務內功經脈

傳送門 ☞ 輪子的專欄 ☞ 轉載請註明 ☞ http://blog.csdn.net/leverage_1229

        Jetty 是一個開源的servlet容器,它爲基於Java的web內容,例如JSP和servlet提供運行環境。Jetty是使用Java語言編寫的,它的API以一組JAR包的形式發佈。開發人員可以將Jetty容器實例化成一個對象,可以迅速爲一些獨立運行(stand-alone)的Java應用提供網絡和web連接。Tomcat 是一個免費的開放源代碼的Web 應用服務器,屬於輕量級應用服務器,在中小型系統和併發訪問用戶不是很多的場合下被普遍使用,是開發和調試JSP 程序的首選。

        Jetty和Tomcat都是業內很優秀的web應用服務器。作爲一名Java應用工程師,相信都會邀請它們加入到自己的項目中去。尤其是Tomcat,在國外網站的普及率在7成以上,很多應用服務器的設計思路和基層架構都源自於它。正是憑藉着其小身板、免費、兼容性好的特性,贏得了絕大多數企業的傾愛,成爲他們心中web應用服務器的首選。但是兼容性越好的東東,往往在某些特性方面就表現不夠。例如,當服務器內存容量有限,又需要兼顧高併發性能,不少企業在選擇web應用服務器上,多半會傾向於其他web容器,Jetty就是其中之一。

         最近由於項目需要寫Android後臺服務器程序,用到了Servlet技術。筆者以前也是做Java EE的,這塊兒的很多東西都忘得差不多了-_-!。這兩天在整理以前的技術資料時,無意間發現一本好書《HowTomcatWorks》。在參考借鑑的同時,決定自己弄個野生的web容器玩玩。畢竟黑盒“巧克力"吃多了也想換換口味兒嘛。

1網頁中的“動”與“靜”

        現今的網頁技術日新月異,記得06年在學校上網經常看到網址的後綴名都是“3P”(.asp、jsp、php),而最近的兩三年已經很難再看到以這種後綴結尾的網址了,基本都是.html。有人要問這是爲什麼呢?主要是現在的網站構架基本都是CMS模式的。當內容基本不變或剛剛瀏覽過的網頁採用靜態技術生成,而像發帖、查找這種經常變化的網頁運用動態技術生成html,當靜態網頁的內容需要變化時,動態網頁可以幫它生成。自從引入CMS模式之後,瀏覽網頁的速度大大加快了,網頁既保持靜態Html優勢又兼顧動態效果。淘寶、微博、人人的網站都是這麼幹的^_^。

2Web應用服務器(Web容器)

        對於Java而言,Web應用服務器主要是用來執行Servlet的,所以也稱爲Servlet容器。Servlet技術支持在服務器端編寫Java程序並邏輯生成Html文件,非常切合動態網頁技術的需要。但是它需要在Web容器才能運行。Web容器也是基於HTTP協議的服務器,因爲它是使用HTTP協議與客戶端進行通信的。一個基於java的web服務器使用兩個重要的類:java.net.Socket和java.net.ServerSocket,並通過HTTP消息進行通信。

3超文本傳輸協議(HTTP)

        HTTP是一種協議,允許web服務器和瀏覽器通過互聯網進行來發送和接受數據。它是一種請求和響應協議。客戶端請求一個文件而服務器響應請求。HTTP使用可靠的TCP連接--TCP默認使用80端口。第一個HTTP版是HTTP/0.9,然後被HTTP/1.0所替代。正在取代HTTP/1.0的是當前版本HTTP/1.1,它定義於徵求意見文檔(RFC) 2616,可以從http://www.w3.org/Protocols/HTTP/1.1/rfc2616.pdf下載。在HTTP中,始終都是客戶端通過建立連接和發送一個HTTP請求從而開啓一個事務。web服務器不需要聯繫客戶端或者對客戶端做一個回調連接。無論是客戶端或者服務器都可以提前終止連接。舉例來說,當你正在使用一個web瀏覽器的時候,可以通過點擊瀏覽器上的停止按鈕來停止一個文件的下載進程,從而有效的關閉與web服務器的HTTP連接。

4HTTP請求

        一個HTTP請求包括三個組成部分:

4.1方法&統一資源標識符(URI)&協議/版本,三者用英文" "分隔

POST /examples/default.jsp HTTP/1.1

4.2請求的頭部,均以名-值對的方式顯示,每個參數可用英文"/n"分隔

Accept: image/gif, image/jpeg, image/pjpeg, image/pjpeg, application/msword, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/QVOD, application/QVOD, */*
Accept-Language: zh-cn
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; KB974488)
Accept-Encoding: gzip, deflate
Host: 127.0.0.1:8080
Connection: Keep-Alive

4.3請求主體內容,發送給服務器的信息

<html>
  <head>
    <title>HTTP Re Example</title>
  </head>
  <body>
    Hello!
  </body>
</html>

5HTTP響應

        類似於HTTP請求,一個HTTP響應也包括三個組成部分:

5.1協議/版本&結果碼&結果,三者用英文" "分隔

HTTP/1.1 200 OK

5.2響應的頭部,均以名-值對的方式顯示,每個參數可用英文"/n"分隔

Server: Microsoft-IIS/4.0
Date: Mon, 5 Jan 2013 13:13:33 GMT
Content-Type: text/html
Last-Modified: Mon, 5 Jan 2013 13:13:12 GMT
Content-Length: 112

5.3響應主體內容,響應給客戶端的信息

<html>
  <head>
    <title>HTTP Response Example</title>
  </head>
  <body>
    I'm Ok!
  </body>
</html>

6Socket類

        套接字是網絡連接的一個端點。套接字使得一個應用可以從網絡中讀取和寫入數據。放在兩個不同計算機上的兩個應用可以通過連接發送和接受字節流。爲了從你的應用發送一條信息到另一個應用,你需要知道另一個應用的IP地址和套接字端口。在Java裏邊,套接字指的是java.net.Socket類。
        要創建一個套接字,你可以使用Socket類衆多構造方法中的一個。其中一個接收主機名稱和端口號:

public Socket (java.lang.String host, int port)
        在這裏主機是指遠程機器名稱或者IP地址,端口是指遠程應用的端口號。例如,要連接CSDN的9527端口,你需要構造以下的Socket對象:
new Socket ("www.csdn.net", 9527);
        一旦你成功創建了一個Socket類的實例,你可以使用它來發送和接受字節流。要發送字節流,你首先必須調用Socket類的getOutputStream方法來獲取一個java.io.OutputStream對象。要發送文本到一個遠程應用,你經常要從返回的OutputStream對象中構造一個java.io.PrintWriter對象。要從連接的另一端接受字節流,你可以調用Socket類的getInputStream方法用來返回一個java.io.InputStream對象。

7ServerSocket類

        Socket類代表一個客戶端套接字,即任何時候你想連接到一個遠程服務器應用的時候你構造的套接字,現在,假如你想實施一個服務器應用,例如一個HTTP服務器或者FTP服務器,你需要一種不同的做法。這是因爲你的服務器必須隨時待命,因爲它不知道一個客戶端應用什麼時候會嘗試去連接它。爲了讓你的應用能隨時待命,你需要使用java.net.ServerSocket類。這是服務器套接字的實現。ServerSocket和Socket不同,服務器套接字的角色是等待來自客戶端的連接請求。一旦服務器套接字獲得一個連接請求,它創建一個Socket實例來與客戶端進行通信。
        要創建一個服務器套接字,你需要使用ServerSocket類提供的四個構造方法中的一個。你需要指定IP地址和服務器套接字將要進行監聽的端口號。通常,IP地址將會是127.0.0.1,也就是說,服務器套接字將會監聽本地機器。

public ServerSocket(int port);
        一旦你有一個ServerSocket實例,你可以讓它在服務器套接字正在監聽的端口上等待傳入的連接請求。你可以通過調用ServerSocket類的accept方法做到這點。這個方法只會在有連接請求時纔會返回,並且返回值是一個Socket類的實例。Socket對象接下去可以發送字節流並從客戶端應用中接受字節流。
Socket socket = server.accept();

        本節我們對實現一個野生Web服務器做了一些相關的知識儲備與回顧,從下節開始,我們將正式踏上野生Web容器之旅,第一站將是解析HTTP請求頭。敬請期待^~^

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章