書桌上擺著一本一年前就已經買好的書。 從來就沒覺得web技術有多複雜，無非是架構在http協議上的一種使用者和伺服器之間互動的技術而已，不過最近拿起來這本書看了看，才發現這裡面還是講了不少好東西，不僅僅是web上的，還有一些討論設計架構的知識。

    言歸正傳，書中的第一章簡單的介紹了web相關的一些常識。包括當年為了使用web技術不得不編寫CGI而且還要讓系統對每一個http請求都開一個重量級程序來應對（其實這到也沒什麼，你去看看apache httpd的應對方式，發現它現在還在為每一個請求開程序呢，原因很簡單，安全啊，一個請求失敗至少不會影響到全域性）；包括Java Servlet應運而生是天選之子（說出來這句話，PHP笑了，獰笑的那種）。其中裡面比較有意思的是他在第15頁提到了JSP Model1 和 JSP Model2 這兩種程式設計正規化，這本身沒什麼了，但是對於我這樣的初入web的人來說，倒算是在大腦中形成了第一個比較“系統”的概念，用JSP寫程式，就應該按照這兩種規矩來寫。這兩種模式的圖片如下：

    其中的JSP Model2 所利用的就是傳說中的MVC模式了（一談到設計模式就兩眼爍爍放光）。而在Struts構架中，Model 就是 ActionForm以及下面的類擴充套件，View就是JSP，而所謂的C，自然就是交給Action下面的擴充套件群（不知道現在寫這些話早不早）。

    翻到第二章，這裡面講了幾個問題我比較感興趣的（學過的就當複習了）：

1. HTTP請求和響應：HTTP協議的基礎模型，這也是HTTP協議本身是stateless的最大原因，普通C/S程式在給資料庫程式提交請求的時候，因為請求處理的程式碼是在客戶端執行，所以我們可以在客戶端後臺起一個查詢執行緒然後等待執行緒結束，讓執行緒主動
   通知主程式更新結束，讓主程式做下一個動作；而B/S程式就慘了，這條路走不通，因為類似的資料庫更新動作是在伺服器端進行的，而基於HTTP的伺服器是不會給瀏覽器傳送什麼請求或者通知一類的東西（除非這個更新動作在一個請求/應答流程中進行）。所以沒有辦法，瀏覽器只好定期的去查詢伺服器端，所請求的更新是不是已經做好，如果做好，就從伺服器拉回來結果更新畫面，如果沒更新好（嘿嘿），那就只好繼續等待了，這算是web程式劣於C/S的地方。哦，對了，B/S這樣的取得結果的方式書中也起了一個名字－－pull approach。
2. 作用域：Struts（準確的說應該是Servlet/JSP標準）有幾個作用域可以用於不同級別的資料共享。這是很重要的資訊：

• 請求作用域：生存在一個HTTP請求/應答的週期中，可以用於web響應一次請求中的資料共享，所以這個共享域在一次請求結束時裡面的屬性是不是被刪除掉了並不重要（反正一次應答以後這個作用域就失效了）。
• 會話作用域（Session）：我們經常可以看到很多web網站在我們登陸一次以後就好像記住了我們一樣，無論我們跳轉到哪個頁面，該網站都好像認得我們一樣。通常，這種記住使用者資訊的行為都是通過會話作用域完成的。至於原理，去想想Session id 和cookie以及url rewrite技術就知道了。
• 應用作用域（Context）：這可以說是共享級別最高的作用域，通常一個web應用啟動的時候，其配置檔案（自定義）的資訊都需要儲存在這個層次中，所以除了必須要將屬性（Attribute）放在裡面，否則輕易不要動這個作用域。

• 轉發：瀏覽器發出請求－>伺服器處理請求－>伺服器完成轉發－>伺服器返回結果－>瀏覽器接受結果。
• 重定向：瀏覽器發出請求－>伺服器處理請求－>伺服器返回給瀏覽器302並且給出重定向連線－>瀏覽器重新用新連線發出新的請求－>伺服器處理新請求並返回結果－>瀏覽器處理結果。