1.3 Web應用程序架構

目前流行的應用軟件架構模式有兩種：客戶機/服務器（client/server, C/S）模式和瀏覽器/服務器（brower/server, B/S）模式。在客戶機/服務器模式中，服務器通常采用高性能的計算機、工作站或小型機，客戶端需要安裝專用的客戶端軟件，如圖1-1所示。在瀏覽器/服務器模式中，客戶端只要安裝一個瀏覽器，通過瀏覽器與Web服務器進行數據交互，如圖1-2所示。Web應用程序則屬于B/S結構的軟件系統。

1.3.1 客戶機/服務器模式

客戶機/服務器（C/S）架構的發展過程經歷了兩層C/S架構、三層C/S架構以及多層C/S架構的演變。

兩層的C/S架構是由客戶端和后臺數據庫組成。數據庫用于存放數據，并且使用數據庫編程語言編寫業務邏輯，客戶端則采用VB、VC、Delphi這樣的可視化編程語言，以便捷地開發客戶端的應用程序。用戶通過界面向服務器發送請求，服務器發回的數據則通過界面進行顯示，服務器的角色就由數據庫來充當。這樣做的好處就是開發效率高，能滿足企業需求。但是這種架構存在著很大的弊端，第一是可移植性差，如當數據庫從SQL Server更換為Oracle時就必須將業務邏輯用新的語言重新編寫一遍；第二則是大型系統做不了，因為客戶端與數據庫需要建立持續的連接，而數據庫能夠支持的最大連接數是有限制的。

2000年之后，三層C/S架構慢慢開始流行。三層的C/S架構指的是客戶端+應用服務器+數據庫，即將混合在數據庫端的業務邏輯從中分離出來，放入應用服務器，數據庫只負責數據的管理、存儲及檢索。客戶端負責界面。三層之中的應用服務器其實也是程序，任何支持TCP編程的語言都可以作為應用服務器。用戶通過圖形用戶界面（GUI）進行操作，然后調用客戶端的通信模塊。通信模塊依據自定義協議將請求數據打包，通過網絡發送該請求，到達應用服務器時，應用服務器同樣也有一個通信模塊，將收到的數據包按照協議進行拆包，調用相應的業務處理模塊處理數據。其中可能需要訪問數據庫來完成數據的獲取，將處理完的結果再次發送給通信模塊。通信模塊將結果按照自定義協議進行打包，然后將數據包發送給客戶端的通信模塊，客戶端進行拆包獲取響應數據，將結果顯示在界面上，更新界面上的數據顯示。三層C/S架構雖然在一定程度上降低了對數據庫編程的依賴，并且能夠適應大型的應用程序，但數據通信模塊的增加卻加大了開發的難度以及整體架構的復雜度。

· 優點

①能充分發揮客戶端計算機的處理能力，很多工作可以在客戶端處理后再提交給服務器，所以C/S客戶端響應速度快；②操作界面漂亮、形式多樣，可以充分滿足客戶自身的個性化要求；③C/S結構的管理信息系統具有較強的事務處理能力，能實現復雜的業務流程；④安全性有保證，C/S一般面向相對固定的用戶群，程序更加注重流程，它可以對權限進行多層次校驗，提供了更安全的存取模式，對信息安全的控制能力很強。一般高度機密的信息系統宜采用C/S結構。

· 缺點

①需要專門的客戶端安裝程序，分布功能弱，針對點多面廣且不具備網絡條件的用戶群體，不能夠實現快速部署安裝和配置；②兼容性差，對于不同的開發工具，具有較大的局限性；③若采用不同工具，需要重新改寫程序；④開發、維護成本較高，需要具有一定專業水準的技術人員才能完成，發生一次升級，則所有客戶端的程序都需要改變；⑤用戶群固定，由于程序需要安裝才可使用，因此不適合面向一些不可知的用戶，所以適用面窄，通常用于局域網。

1.3.2 超文本傳輸協議

超文本傳輸協議（hyper text transfer protocol, HTTP），是TCP/IP協議的一個應用層協議。客戶端通過HTTP協議向服務器端發送的數據，稱為請求消息（request），反之則為響應消息（response）。HTTP是一種無連接的協議。無連接是指Web瀏覽器與Web服務器之間不需要建立持久的連接，這意味著當一個客戶端向服務器端發出請求，然后Web服務器返回響應，連接就被關閉了，在服務器端不保留連接的有關信息。也就是說，HTTP請求只能由客戶端發起，而服務器不能主動向客戶端發送數據。

· HTTP請求

HTTP請求信息由4部分組成：

（1）請求行：請求方法（GET/POST）、URI、協議/版本。

（2）請求消息頭。

（3）空行。

（4）請求正文。

· HTTP響應

HTTP應答與HTTP請求相似，HTTP響應也由3個部分構成，分別是：

（1）狀態行。

（2）響應頭。

（3）響應正文。

· HTTP狀態碼

當用戶訪問一個網頁時，瀏覽器會向網頁所在服務器發出請求。當瀏覽器接收并顯示網頁前，此網頁所在的服務器會返回一個包含HTTP狀態碼的信息頭（server header）用以響應瀏覽器的請求。我們常見的狀態碼有五種：

1xx：信息提示，表示請求已被成功接收，繼續處理。

2xx：請求被成功提交。

3xx：客戶端被重定向到其他資源。

4xx：客戶端錯誤狀態碼，格式錯誤或者不存在資源。

5xx：描述服務器內部錯誤。

下面列舉幾種常見的狀態碼含義，如表1-1所示。在后面的程序開發中，我們會經常見到它們。

1.3.3 瀏覽器/服務器模式

為了降低三層C/S架構中與通信有關的復雜度，瀏覽器/服務器（B/S）架構成為網絡程序中的一種流行架構。在B/S架構中，客戶端使用HTTP協議進行數據打包拆包的程序是各廠商依據標準開發的瀏覽器，Web服務器也是基于HTTP協議由一些廠商提供，如IIS、Apache等。在B/S架構中，由于協議已被限定，所以與通信有關的數據打包拆包的過程都不用我們開發人員來編寫程序，只需要考慮怎么將HTTP協議解析出來的數據進行業務處理，以及根據不同的結果產生響應。這大大降低了網絡程序的開發難度，所以這種架構得到了大量的應用。

· 優點

①開發簡單，共享性強；②分布性強，客戶端零維護；③只要有網絡和瀏覽器，就可以隨時隨地進行查詢、瀏覽等業務處理；④業務擴展簡單方便，通過增加網頁即可增加服務器功能；⑤維護簡單方便，只需要改變網頁，即可實現所有用戶的同步更新。

· 缺點

①個性化特點明顯降低，無法實現具有個性化的功能要求；②在跨瀏覽器上，B/S架構不盡如人意；③客戶端與服務器端的交互是請求-響應模式，通常動態刷新頁面，響應速度明顯降低（Ajax可以在一定程度上解決這個問題）; ④無法實現分頁顯示，給數據庫訪問造成較大的壓力；⑤在速度和安全性上需要花費巨大的設計成本。

1.3.4 動態Web應用訪問過程

所謂動態Web，是指網頁數據是由程序產生的，不同時間點、不同地點、不同人訪問同一個URL看到的內容和界面可能不一樣，且網頁具有交互性，內容可以動態更新。在動態Web中，客戶端使用瀏覽器（IE、Chrome等），通過網絡連接到服務器上，使用HTTP協議發起請求。所有請求都先經過服務器插件（web server plugin）來處理，此插件用于區分所請求的是靜態資源還是動態資源，如圖1-3所示。

如果服務器插件發現客戶端請求的是靜態資源，比如．htm或者是．html，則將請求直接轉交給Web服務器。Web服務器從文件系統中取出內容，發送回客戶端瀏覽器進行解析執行。

如果服務器插件發現客戶端請求的是動態資源，比如JSP、ASP/ASPX、PHP，則先將請求轉交給Web容器，通過Web容器連接數據庫，再從數據庫中取出數據，動態拼湊頁面的展示內容；最后，把所有的展示內容交給Web服務器，通過Web服務器將內容發送回客戶端瀏覽器進行解析執行。