巨集觀概括
1.Cookie和Session都是常用的會話跟蹤技術。
2.Session是在服務端儲存的一個數據結構，用來跟蹤使用者的狀態，這個資料可以儲存在叢集、資料庫、檔案中。
3.Cookie是客戶端瀏覽器儲存使用者資訊的一種機制，用來記錄使用者的一些資訊，也是實現Session的一種方式。

1.Cookie

• 機制
  如果伺服器需要記錄登陸使用者的狀態，則使用response向客戶端瀏覽器頒發一個Cookie。當瀏覽器再請求該網站時，瀏覽器就會將請求網址和Cookie一同提交給伺服器。
  通俗解釋：由於HTTP無狀態，伺服器無法從網路連線中獲取客戶身份，怎麼辦呢？那就給客戶端們頒發一個通行證吧，每人一個，無論誰訪問都必須攜帶自己的通行證。這樣伺服器就能從通行證上確認客戶身份了。這就是Cookie的工作原理。

• 存在位置
  客戶端瀏覽器。因此Cookie技術需要瀏覽器的支援。

• 儲存形式
  key-value屬性對的形式。一個Cookie物件儲存一個屬性對。 因為一個使用者有多個屬性，所以一個使用者狀態應該包含多個Cookie物件。
  注意：一個response或者request同時使用多個Cookie。
• 不可跨域名性
  
  • Cookie受瀏覽器管理。瀏覽器能保證Google只會操作Google的Cookie，從而保證使用者的隱私安全。
  • 瀏覽器f**判斷一個網站是否能操作另一個網站Cookie的依據：域名**
• 儲存內容的編碼問題
  
  • 中文：UTF-8編碼，因為中文屬於Unicode字元，不編碼會亂碼
  • 英文：不需要編碼
  • 儲存內容不宜過多，因為瀏覽器每次請求伺服器都會攜帶Cookie，過長會影響速度
• 可設定的Cookie屬性
  
  • String name
    該Cookie的名稱。Cookie一旦建立，名稱便不可更改
  • Object value
    該Cookie的值。如果值為Unicode字元，需要為字元編碼。如果值為二進位制資料，則需要使用BASE64編碼
  • int maxAge
    該Cookie失效的時間，單位秒。如果為正數，則該Cookie在maxAge秒之後失效。如果為負數，該Cookie為臨時Cookie，關閉瀏覽器即失效，瀏覽器也不會以任何形式儲存該Cookie。如果為0，表示刪除該Cookie。預設為–1。失效的Cookie會被瀏覽器從Cookie檔案or記憶體中刪除。
  • boolean secure
    該Cookie是否僅被使用安全協議傳輸。安全協議。安全協議有HTTPS，SSL等，在網路上傳輸資料之前先將資料加密。預設為false
  • String path
    該Cookie的使用路徑。如果設定為“/sessionWeb/”，則只有contextPath為“/sessionWeb”的程式可以訪問該Cookie。如果設定為“/”，則本域名下contextPath都可以訪問該Cookie。注意最後一個字元必須為“/”
  • String domain
    可以訪問該Cookie的域名。如果設定為“.google.com”，則所有以“google.com”結尾的域名都可以訪問該Cookie。注意第一個字元必須為“.”
  • String comment
    該Cookie的用處說明。瀏覽器顯示Cookie資訊的時候顯示該說明
  • int version
    該Cookie使用的版本號。0表示遵循Netscape的Cookie規範，1表示遵循W3C的RFC 2109規範
    說明：瀏覽器提交Cookie時，只是提交name和value屬性，其它屬性對於客戶端來說都是不可讀的
• 永久登入實現方式分析
  
  • 使用者名稱＋密碼，都儲存到Cookie中。
    危險行為，一般密碼等重要資訊不能儲存到Cookie中。
  • 使用者名稱＋加密的密碼，儲存到Cookie
    下次訪問時，解密並與資料庫做對比。
  • 使用者名稱＋登入時間戳，儲存到Cookie和資料庫
  • 賬號＋金鑰，對二者進行MD1(MD5等)演算法進行加密，儲存到Cookie中—-推薦方式
    
    • 只在登入時查詢一次資料庫，以後訪問驗證登入資訊時不再查詢資料庫。
    • 此加密機制最重要的2部分：演算法＋金鑰。由於MD1演算法的不可逆性，即使使用者知道了賬號和加密後的字串，但是也不能得到金鑰。因此，只要保護好演算法和金鑰，則該機制就是安全的。

2.Session

• 機制
  伺服器端使用的一種記錄客戶端狀態的機制。使用比Cookie簡單，增加了伺服器儲存壓力.
• 被儲存過程
  客戶端瀏覽器訪問伺服器時，伺服器把客戶端資訊以某種形式記錄在伺服器上。這就是Session。
  通俗的講，Session是通過查詢伺服器上的“客戶明細表”來確認客戶身份的
• Session的生命週期
  
  • 存在於記憶體中。
  • Session在使用者第一次訪問非靜態資源時，自動建立。
  • Session超時時間可以自定義。超時後，自動從記憶體刪除。也可以在Web.xml中設定。
• HttpSession的常用方法
  
  • void setAttribute(String attribute, Object value)
    設定Session屬性。value引數可以為任何Java Object。通常為Java Bean。value資訊不宜過大
  • String getAttribute(String attribute)
    返回Session屬性
  • Enumeration getAttributeNames()
    返回Session中存在的屬性名
  • void removeAttribute(String attribute)
    移除Session屬性
  • String getId()
    返回Session的ID。該ID由伺服器自動建立，不會重複
  • long getCreationTime()
    返回Session的建立日期。返回型別為long，常被轉化為Date型別，例如：Date createTime = new Date(session.get CreationTime())
  • long getLastAccessedTime()
    返回Session的最後活躍時間。返回型別為long
  • int getMaxInactiveInterval()
    返回Session的超時時間。單位為秒。超過該時間沒有訪問，伺服器認為該Session失效
  • void setMaxInactiveInterval(int second)
    設定Session的超時時間。單位為秒
  • boolean isNew()
    返回該Session是否是新建立的
  • void invalidate()
    使該Session失效

• Tomcat判定客戶端瀏覽器是否支援Cookie依據

  • 請求中是否含有Cookie。
  • 注意：儘管客戶端可能會支援Cookie，但是由於第一次請求時不會攜帶任何Cookie（因為並無任何Cookie可以攜帶），URL地址重寫後的地址中仍然會帶有jsessionid。當第二次訪問時伺服器已經在瀏覽器中寫入Cookie了，因此URL地址重寫後的地址中就不會帶有jsessionid了。
  • 預設超時時間：30分鐘。

• 仍然需要瀏覽器的支援

• URL地址重寫
  
  • 是對客戶端不支援Cookie的解決方案。
  • 原理: 是將該使用者Session的id資訊重寫到URL地址中。伺服器能夠解析重寫後的URL獲取Session的id。這樣即使客戶端不支援Cookie，也可以使用Session來記錄使用者狀態。