1. HTTP本身無連接無狀態, 如何在不同請求間識別用戶以支持需要多個請求才能完成的業務?
其它所有問題都是這個問題的某種解決方案引入的. 這個論斷有一個推論,
就是不需要識別用戶的Web應用是最簡單的Web應用.
一種方案是所有的業務都設計成一次請求就可以完成, 比如讓用戶每次都輸入用戶名密碼, 填寫所有的表單,
然后一次性提交. 從用戶體驗的角度顯然不可行...
狀態保存
需要保存狀態的原因是要在無連接的協議上模擬有連接的用戶體驗
狀態保存的地點無非是客戶端或者服務端, 以及URL本身
客戶端一般是cookie, 類似Hash的鍵值對. 存放小塊數據, 通常是真正狀態的某種標識,
可加密, 可設置有效期及適用的域, 由瀏覽器每次請求時發送給服務端. cookie的問題在于, 有些用戶在瀏覽器中禁止了對cookie的支持,
然而實際上有什么類型的網站需要考慮/考慮了這類用戶? 以及安全性(可被拷貝偷走放在自己機器上以假冒其他用戶用).
可對cookie加密或摘要來保證數據的機密性和完整性
服務端存儲有內存和外部存儲. 一般把跨越多次請求維護特定客戶端的狀態數據的場所叫做Session.
Session并不是HTTP本身的概念, 而是各開發包實現者提供的概念和實現, 通過唯一的session
id(通常通過cookie保存)在不同的請求間關聯數據.
Session放在內存中的問題是無法適應負載平衡和可靠性的需求, 優點是性能; 外部存儲恰好相反;
各種不同的開發包對Session的實現一般都支持存儲可配置, 對應用"透明"(實際上無法完全透明, 比如如果需要持久化Session到外部存儲,
則需要內存對象支持某種形式的可序列化, 而如果只是放在內存里則無此需求)
URL本身可攜帶數據, 問題是應用程序開發者需要仔細維護URL的產生和解析. 開發包提供了支持,
可定義URL到對應處理程序的映射, 解碼URL中攜帶的數據并作為參數傳遞給處理程序.
-
URL和cookie都適合存放小片數據. 那么什么類型的數據適合放進URL,
什么數據適合放進cookie呢? 從URL的語義上來說, 編碼進URL的數據應該是所請求資源的某種屬性, 而cookie一般存放用戶的某種標識數據.
也就是URL應該是業務相關數據, cookie應該是應用相關數據. 當瀏覽器禁用cookie時, 開發包支持把session
id之類的數據編碼進URL.
-
Session存放需要頻繁用到的數據, 用戶相關而業務無關的.
關鍵的業務數據要及時持久化到外部存儲. 業務相關數據一般按需存取...
狀態清除
狀態清除是由狀態保存引入的問題, 確切的說是對保存狀態的資源的回收和重利用.
另外是減少安全性方面的隱患.
客戶端cookie有過期時間, 也可在用戶登出的時候主動設置其過期來刪除
服務端Session可在用戶登出的時候主動刪除, 開發包也會檢測同樣的Session ID訪問間隔,
如果超過某個設定的時間沒有包含某個Session ID的cookie被送到服務端, 則自動清除對應Session數據. 這時候表現為如果用戶長時間不操作,
下次操作時將被開發包重定向到登錄頁面.
業務數據的傳遞
數據的輸入和處理發生在不同的主機上, 是Web應用的天然特質. HTML的Form和隱藏字段,
HTTP Post專為此設計. 另外URL本身也可以承載一些業務數據(HTTP Get)
跨頁面的業務數據傳遞, 一般通過持久化到外部存儲的方式來共享. 應用數據則可以通過Session,
一些細分的概念如臨時數據,
只用一次的數據等,
開發包都有支持, 一般也是背后通過Session實現
2. 客戶端狀態更新
HTTP的無連接帶來的第二個問題是服務端無法主動把信息推給客戶端,
另一個原因是客戶端通常沒有public的IP. 客戶端只能使用按需請求或輪詢模型. 此題無解. 如果是企業內部系統集成, 考慮使用消息隊列等方式.
3. 并發
并發是要處理的第三個本質問題. 對并發(背后是狀態一致性與完整性)的解決會帶來事務,
事務會帶來性能問題, 對性能的解決會帶來Cache等方案, Cache則會引入狀態一致性與完整性問題...回到起點.
最終是狀態的一致性與完整性和性能之間的某種折衷.
Cache的一種實現是將動態頁面轉化為一段時間內的靜態頁面, 交給Web服務器直接處理,
減輕應用服務器的負擔.
應用服務器內的Cache一般是key value pair. key一般是url, 查詢語句,
對象ID等.
Cache的實現要考慮的問題主要是Cache的生命周期, 是請求內, 會話內, 還是應用程序范圍.
以及同步問題, 何時刷新, 如何刷新.
-
HTTP Request范圍內的Cache, 和通常的事務策略配合良好.
事務通常不會超出一次請求, 隔離級別是可讀到其它事務提交后的內容, 不會讀到其它事務提交前的改動(?). 這類Cache邊界清晰,
幾乎不會有失效刷新的需求, 基本不需要考慮多線程的問題(每個請求一般獨占一個處理線程). 缺點是對性能提高有限,
如果一次請求范圍內對同一資源的訪問很少超過一次的話.
-
Session范圍內的Cache...什么類型的數據適合放到Session級別的Cache呢?
Session通常包含多個事務, 如果放業務數據到Cache, 毫無疑問要經常刷新, 失去Cache的意義. 刷新時有多線程的問題,
尤其對AJAX應用. 如果是不經常變化的應用數據, 通常放到應用程序級別的Cache. Session內的數據基本可看作已經是某種緩存...
-
Application范圍內的數據, 一般存放不經常變化的配置數據, 數據字典等.
刷新可以是定時輪詢, 及各種基于事件的手段: HTTP Get/Post, 消息隊列等
4. 驗證
這里說的驗證是Validation, 不是Authentication.
Authentication/Authorization并非Web特定問題, 其它類型的應用面臨同樣的問題, 有相似的解決方案
Validation則是Web相關, 蓋因輸入與處理發生在不同的主機上,
驗證邏輯發生的位置和時機都是需要考慮的因素
-
一條底線是在數據被正式接受之前, 比如存到數據庫之前, 用來進行業務計算之前, 進行驗證,
以確保數據的合法性. 這在大多數情況下都是必要的. 然而從用戶體驗的角度講, 時間有點晚, 并且驗證產生的錯誤信息可能更偏向于實現,
而不是用戶能理解的業務含義, 并不必要的向用戶暴露實現細節. 所以需要其它的驗證手段作為補充
-
一種方式是在客戶端用JavaScript進行驗證, 不必讓數據到服務器走一個來回,
帶來的問題是部分驗證邏輯在客戶端和服務端用不同的語言寫兩遍.
-
一個改進是利用AJAX即時驗證, 既改善了用戶體驗,
又避免了用JavaScript重寫驗證邏輯
即時的驗證一般關注于基礎合法性的驗證, 比如格式, 必填字段等.
數據的業務合法性則一般在提交后由服務端進行全面驗證
5. 開發效率
開發包對Web問題的各種解決方案進行了封裝, 分離關注點, 使開發人員更關注業務邏輯,
開發包處理了所有與Web相關的應用邏輯
為使這一切對開發者透明, 結合Web應用的Request/Response模型,
開發包一般采用管道和過濾器模式來動態的,可配置的將各種服務插入到數據的處理流程中.
比如Session的管理, 包括通過cookie識別特定客戶端和清除過期數據等邏輯,
都透明的發生在請求經過的路徑上. Session數據本身的存儲位置, 也都是可配置的. 其它的例子包括頁面緩存和用戶驗證等.
-
封裝HTTP協議字節流到特定開發平臺的對象, 通常是能以key-value
pair的形式訪問的接口. 更有細粒度的對象如Cookie等概念的封裝
-
封裝URL到對應處理程序的映射, 包括組裝URL, 將URL參數解析成具有業務含義的數據.
開發者可定制映射規則
-
封裝Form/Request數據到業務對象的轉換, 通常稱之為Binder
-
通過MVC分離視圖邏輯和業務邏輯, 并且通過模板視圖技術支持UI開發者和業務開發者的分工協作
-
提供了過濾器接口, 可以自定義驗證, 授權, 錯誤處理等邏輯