2021-02-19 分類: 網(wǎng)站建設(shè)
曾經(jīng)問過很多朋友這個問題: Cookie 和 Session 有什么區(qū)別呢?大部分的面試者應(yīng)該都可以說上一兩句,比如:什么是 Cookie?什么是 Session?兩者的區(qū)別等。
但如果再往深入探討的話,就慢慢有一些朋友不太了解了,談起原理時就很少有朋友全部回答準(zhǔn)確。今天和大家一起深入聊聊有關(guān) Cookie 和 Session 的話題 。
第一層樓
什么是 Cookie 和 Session ?初級程序員高頻面試題。
什么是 Cookie
HTTP Cookie(也叫 Web Cookie或瀏覽器 Cookie)是服務(wù)器發(fā)送到用戶瀏覽器并保存在本地的一小塊數(shù)據(jù),它會在瀏覽器下次向同一服務(wù)器再發(fā)起請求時被攜帶并發(fā)送到服務(wù)器上。通常,它用于告知服務(wù)端兩個請求是否來自同一瀏覽器,如保持用戶的登錄狀態(tài)。Cookie 使基于無狀態(tài)的 HTTP 協(xié)議記錄穩(wěn)定的狀態(tài)信息成為了可能。
Cookie 主要用于以下三個方面:
什么是 Session
Session 代表著服務(wù)器和客戶端一次會話的過程。Session 對象存儲特定用戶會話所需的屬性及配置信息。這樣,當(dāng)用戶在應(yīng)用程序的 Web 頁之間跳轉(zhuǎn)時,存儲在 Session 對象中的變量將不會丟失,而是在整個用戶會話中一直存在下去。當(dāng)客戶端關(guān)閉會話,或者 Session 超時失效時會話結(jié)束。
第二層樓
Cookie 和 Session 有什么不同?
前兩層樓內(nèi)容,絕大部分同學(xué)都可以準(zhǔn)確回答
第三層樓
為什么需要 Cookie 和 Session,他們有什么關(guān)聯(lián)?
說起來為什么需要 Cookie ,這就需要從瀏覽器開始說起,我們都知道瀏覽器是沒有狀態(tài)的(HTTP 協(xié)議無狀態(tài)),這意味著瀏覽器并不知道是張三還是李四在和服務(wù)端打交道。這個時候就需要有一個機制來告訴服務(wù)端,本次操作用戶是否登錄,是哪個用戶在執(zhí)行的操作,那這套機制的實現(xiàn)就需要 Cookie 和 Session 的配合。
那么 Cookie 和 Session 是如何配合的呢?我畫了一張圖大家可以先了解下。
用戶第一次請求服務(wù)器的時候,服務(wù)器根據(jù)用戶提交的相關(guān)信息,創(chuàng)建創(chuàng)建對應(yīng)的 Session ,請求返回時將此 Session 的唯一標(biāo)識信息 SessionID 返回給瀏覽器,瀏覽器接收到服務(wù)器返回的 SessionID 信息后,會將此信息存入到 Cookie 中,同時 Cookie 記錄此 SessionID 屬于哪個域名。
當(dāng)用戶第二次訪問服務(wù)器的時候,請求會自動判斷此域名下是否存在 Cookie 信息,如果存在自動將 Cookie 信息也發(fā)送給服務(wù)端,服務(wù)端會從 Cookie 中獲取 SessionID,再根據(jù) SessionID 查找對應(yīng)的 Session 信息,如果沒有找到說明用戶沒有登錄或者登錄失效,如果找到 Session 證明用戶已經(jīng)登錄可執(zhí)行后面操作。
根據(jù)以上流程可知,SessionID 是連接 Cookie 和 Session 的一道橋梁,大部分系統(tǒng)也是根據(jù)此原理來驗證用戶登錄狀態(tài)。
三層樓的內(nèi)容,大部分同學(xué)可以講清楚。
第四層樓
既然服務(wù)端是根據(jù) Cookie 中的信息判斷用戶是否登錄,那么如果瀏覽器中禁止了 Cookie,如何保障整個機制的正常運轉(zhuǎn)。
第一種方案,每次請求中都攜帶一個 SessionID 的參數(shù),也可以 Post 的方式提交,也可以在請求的地址后面拼接 xxx?SessionID=123456...。
第二種方案,Token 機制。Token 機制多用于 App 客戶端和服務(wù)器交互的模式,也可以用于 Web 端做用戶狀態(tài)管理。
Token 的意思是“令牌”,是服務(wù)端生成的一串字符串,作為客戶端進行請求的一個標(biāo)識。Token 機制和 Cookie 和 Session 的使用機制比較類似。
當(dāng)用戶第一次登錄后,服務(wù)器根據(jù)提交的用戶信息生成一個 Token,響應(yīng)時將 Token 返回給客戶端,以后客戶端只需帶上這個 Token 前來請求數(shù)據(jù)即可,無需再次登錄驗證。
四層樓的內(nèi)容,一部分同學(xué)可以講清楚。
第五層樓
如何考慮分布式 Session 問題?
在互聯(lián)網(wǎng)公司為了可以支撐更大的流量,后端往往需要多臺服務(wù)器共同來支撐前端用戶請求,那如果用戶在 A 服務(wù)器登錄了,第二次請求跑到服務(wù) B 就會出現(xiàn)登錄失效問題。
分布式 Session 一般會有以下幾種解決方案:
建議采用第三種方案。
第六層樓
如何解決跨域請求?Jsonp 跨域的原理是什么?
說起跨域請求,必須要了解瀏覽器的同源策略,同源策略/SOP(Same origin policy)是一種約定,由 Netscape 公司 1995年引入瀏覽器,它是瀏覽器最核心也最基本的安全功能,如果缺少了同源策略,瀏覽器很容易受到 XSS、CSFR 等攻擊。所謂同源是指"協(xié)議+域名+端口"三者相同,即便兩個不同的域名指向同一個 ip 地址,也非同源。
解決跨域請求的常用方法是:
重點談一下 Jsonp 跨域原理。瀏覽器的同源策略把跨域請求都禁止了,但是頁面中的
鏈接:https://juejin.im/post/5cd9037ee51d456e5c5babca
當(dāng)前名稱:Cookie 和 Session 有什么區(qū)別?
路徑分享:http://www.rwnh.cn/news17/101867.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供電子商務(wù)、移動網(wǎng)站建設(shè)、微信公眾號、品牌網(wǎng)站建設(shè)、云服務(wù)器、商城網(wǎng)站
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時需注明來源: 創(chuàng)新互聯(lián)
猜你還喜歡下面的內(nèi)容