建站
咨詢
售后
建站咨詢
新聞中心
為什么需要cookie和session
成都創(chuàng)新互聯(lián)公司主營桐城網(wǎng)站建設(shè)的網(wǎng)絡(luò)公司,主營網(wǎng)站建設(shè)方案,手機APP定制開發(fā),桐城h5小程序設(shè)計搭建,桐城網(wǎng)站營銷推廣歡迎桐城等地區(qū)企業(yè)咨詢
在Web發(fā)展史中，我們知道瀏覽器與服務(wù)器間采用的是 http協(xié)議，而這種協(xié)議是無狀態(tài)的，所以這就導(dǎo)致了服務(wù)器無法知道是誰在瀏覽網(wǎng)頁，但很明顯，一些網(wǎng)頁需要知道用戶的狀態(tài)，例如登陸，購物車等。
所以為了解決這一問題，先后出現(xiàn)了四種技術(shù)，分別是隱藏表單域，URL重寫，cookie，session，而用的最多也是比較重要的就是cookie和session了。
Cookie是什么
cookie是瀏覽器保存在用戶電腦上的一小段文本，通俗的來講就是當(dāng)一個用戶通過 http訪問到服務(wù)器時，服務(wù)器會將一些 Key/Value鍵值對返回給客戶端瀏覽器，并給這些數(shù)據(jù)加上一些限制條件，在條件符合時這個用戶下次訪問這個服務(wù)器時，數(shù)據(jù)通過請求頭又被完整地給帶回服務(wù)器，服務(wù)器根據(jù)這些信息來判斷不同的用戶。
也就是說， cookie是服務(wù)器傳給客戶端并保存在客戶端的一段信息，這個 Cookie是有大小，數(shù)量限制的!!
Cookie的創(chuàng)建
當(dāng)前 Cookie有兩個版本，分別對應(yīng)兩種設(shè)置響應(yīng)頭：“Set-Cookie”和 “Set-Cookie2”。在Servlet中并不支持Set-Cookie2，所以我們來看看Set-Cookie的屬性項：
這些屬性項，其他的都說的很清楚了，我們來看看Domain有什么用：
現(xiàn)在，我們假設(shè)這里有兩個域名：
域名A：a.b.f.com.cn 域名B：c.d.f.com.cn
顯然，域名A和域名B都是 f.com.cn的子域名
- 如果我們在域名A中的Cookie的domain設(shè)置為f.com.cn，那么f.com.cn及其子域名都可以獲取這個Cookie，即域名A和域名B都可以獲取這個Cookie
- 如果域名A和域名B同時設(shè)置Cookie的doamin為f.com.cn，那么將出現(xiàn)覆蓋的現(xiàn)象
- 如果域名A沒有顯式設(shè)置Cookie的domain方法，那么domain就為a.b.f.com.cn，不一樣的是，這時，域名A的子域名將無法獲取這個Cookie
好的，現(xiàn)在了解完了Set-Cookie的屬性項，開始創(chuàng)建Cookie
Web服務(wù)器通過發(fā)送一個稱為Set-Cookie的http消息來創(chuàng)建一個Cookie：
Set-Cookie: value[; expires=date][; domain=domain][; path=path][; secure]
這里我們思考一個問題，當(dāng)我們在服務(wù)器創(chuàng)建多個Cookie時，這些Cookie最終是在一個Header項中還是以獨立的Header存在的呢?
我們可以看到，構(gòu)建http返回字節(jié)流時是將Header中所有的項順序?qū)懗觯鴽]有進行任何修改。所以可以想象在瀏覽器在接收http返回的數(shù)據(jù)時是分別解析每一個Header項。
接著，在客戶端進行保存，如何保存呢?這里又要對Cookie進行進一步的了解
Cookie的分類
- 會話級別Cookie：所謂會話級別Cookie，就是在瀏覽器關(guān)閉之后Cookie就會失效。
- 持久級別Cookie：保存在硬盤的Cookie，只要設(shè)置了過期時間就是硬盤級別Cookie。
好的，現(xiàn)在cookie保存在了客戶端，當(dāng)我們?nèi)フ埱笠粋€URL時，瀏覽器會根據(jù)這個URL路徑將符合條件的Cookie放在請求頭中傳給服務(wù)器。
Session
Cookie是有大小限制和數(shù)量限制的，并且越來越多的Cookie代表客戶端和服務(wù)器的傳輸量增加，可不可以每次傳的時候不傳所有cookie值，而只傳一個唯一ID，通過這個ID直接在服務(wù)器查找用戶信息呢?答案是有的，這就是我們的session。
Session是基于Cookie來工作的，同一個客戶端每次訪問服務(wù)器時，只要當(dāng)瀏覽器在第一次訪問服務(wù)器時，服務(wù)器設(shè)置一個id并保存一些信息(例如登陸就保存用戶信息，視具體情況)，并把這個id通過Cookie存到客戶端，客戶端每次和服務(wù)器交互時只傳這個id，就可以實現(xiàn)維持瀏覽器和服務(wù)器的狀態(tài)，而這個ID通常是NAME為JSESSIONID的一個Cookie。
實際上，有四種方式讓Session正常工作：
- 通過URL傳遞SessionID
- 通過Cookie傳遞SessionID
- 通過SSL傳遞SessionID
- 通過隱藏表單傳遞SessionID
第一種情況：
當(dāng)瀏覽器不支持Cookie功能時，瀏覽器會將用戶的SessionCookieName(默認為JSESSIONID)重寫到用戶請求的URL參數(shù)中。格式：/path/Servlet;name=value;name2=value2?Name3=value3
第三種情況：
會根據(jù)javax.servlet.request.ssl_session屬性值設(shè)置SessionID。
注：如果客戶端支持Cookie，又通過URL重寫，Tomcat仍然會解析Cookie中的SessionID并覆蓋URL中的SessionID
Session工作原理
先看session工作的時序圖
一、創(chuàng)建session
當(dāng)客戶端訪問到服務(wù)器，服務(wù)器會為這個客戶端通過request.getSession()方法創(chuàng)建一個Session，如果當(dāng)前SessionID還沒有對應(yīng)的HttpSession對象，就創(chuàng)建一個新的，并添加到org.apache.catalina.Manager的sessions容器中保存，這就做到了對狀態(tài)的保持。當(dāng)然，這個SessionID是唯一的
二、session保存
由圖可知，session對象已經(jīng)保存在了Manager類中，StandardManager作為實現(xiàn)類，通過requestedSessionId從StandardManager的sessions集合中取出StandardSession對象。
我們來看看StandardManager時如何對所有StandardSession對象進行生命周期管理
當(dāng)Servlet容器關(guān)閉：
StandardManager將持久化沒過期的StandardSession對象(必須調(diào)用Servlet容器中的stop和start命令，不能直接kill)
當(dāng)Servlet容器重啟時：
StandardManager初始化會重讀這個文件，解析出所有session對象。
三、session的銷毀
這里有一個誤區(qū)，也是我之前的錯誤理解，就是我將session的生命周期理解成一次會話，瀏覽器打開就創(chuàng)建，瀏覽器關(guān)閉就銷毀，這樣理解是錯的!!
session的聲明周期是從創(chuàng)建到超時過期
也就是說，當(dāng)session創(chuàng)建后，瀏覽器關(guān)閉，會話級別的Cookie被銷毀，如果沒有超過設(shè)定時間，該SessionID對應(yīng)的session是沒有被銷毀的，
檢查session失效
檢查每個Session是否失效是在Tomcat的一個后臺線程完成的(backgroundProcess()方法中);除了后臺進程檢驗session是否失效外，調(diào)用request.getSession()也會檢查該session是否過期，當(dāng)然，調(diào)用這種方法如果過期的話又會重新創(chuàng)建一個新的session。
小 結(jié)
二者的異同
相同點(有關(guān)系的地方)：
Session和Cookie都是為了讓http協(xié)議又狀態(tài)而存在
Session通過Cookie工作，Cookie傳輸?shù)腟essionID讓Session知道這個客戶端到底是誰
不同點：
Session將信息保存到服務(wù)器，Cookie將信息保存在客戶端
工作流程
當(dāng)瀏覽器第一次訪問服務(wù)器時，服務(wù)器創(chuàng)建Session并將SessionID通過Cookie帶給瀏覽器保存在客戶端，同時服務(wù)器根據(jù)業(yè)務(wù)邏輯保存相應(yīng)的客戶端信息保存在session中;客戶端再訪問時上傳Cookie，服務(wù)器得到Cookie后獲取里面的SessionID，來維持狀態(tài)。
本文題目：一文徹底搞懂cookie和session
文章來源：http://m.5511xx.com/article/dhesodd.html
