東子作為目前傳統(tǒng)電商三巨頭之一（其他還有阿里巴巴和拼多多），其面試題的難度也中規(guī)中矩，總體來說沒有其他兩家面試難度高，當然薪資也沒有其他兩家薪資高。

其中拼多多的薪資最為離譜，尤其是前幾年，聽說挖同行的開發(fā)人員，薪資可以開到原來薪資的兩到三倍，真是變態(tài)（但是我喜歡）。

東子的面試題如下：

圖片

其中大部分面試題可以在我的網(wǎng)站上找到答案（www.javacn.site），這里就不再贅述了。咱們今天只聊：Cookie、Session 和 Token 的區(qū)別？

1.Cookie、Session 和 Token 有什么區(qū)別？

Cookie、Session 和 Token 通常都是用來保存用戶登錄信息的技術(shù)，但三者有很大的區(qū)別，簡單來說 Cookie 適用于簡單的狀態(tài)管理，Session 適用于需要保護用戶敏感信息的場景，而 Token 適用于狀態(tài)無關的身份驗證和授權(quán)。

Token 狀態(tài)無關性解析：在傳統(tǒng)的基于會話的認證方式中，服務器需要在后端保存用戶的會話狀態(tài)，通過 Session ID 進行會話的管理。而 Token 機制不需要在服務器上保存任何關于用戶的狀態(tài)信息，只需要在登錄成功時，服務器端通過某種算法生成一個唯一的 Token 值，之后再將此 Token 發(fā)送給客戶端存儲（存儲在 localStorage 或 sessionStorage 中），注意此時服務端是不存儲這個 Token 值的，服務器端只進行效驗而不保存此 Token，這就叫“狀態(tài)無關性”。這樣就可以減輕服務器存儲和管理會話狀態(tài)的負擔，所以它比較適用于大型系統(tǒng)和分布式系統(tǒng)。

具體來說，Cookie、Session 和 Token 的區(qū)別主要有以下幾點區(qū)別：

1. 存儲位置不同：Cookie 存儲在客戶端，即瀏覽器中的文本文件，通過在 HTTP 頭中傳遞給服務器來進行通信；Session 是服務器端的存儲方式，通常存儲在服務器的內(nèi)存或數(shù)據(jù)庫中；Token 也是存儲在客戶端，但是通常以加密的方式存儲在客戶端的 localStorage 或 sessionStorage 中。
2. 數(shù)據(jù)安全性不同：Cookie 存儲在客戶端，可能會被竊取或篡改，因此對敏感信息的存儲需要進行加密處理；Session 存儲在服務器端，通過一個 Session ID 在客戶端和服務器之間進行關聯(lián)，可以避免敏感數(shù)據(jù)直接暴露；Token 通常使用加密算法生成，有效期較短且單向不可逆，可以提供較高的安全性。
3. 跨域支持不同：為了防止安全事故，因此 Cookie 是不支持跨域傳輸?shù)?，也就是不同域名下?Cookie 是不能相互訪問的；而 Session 機制通常是通過 Cookie 來保存 Session ID 的，因此 Session ID 默認情況下也是不支持跨域的；但 Token 可以輕松實現(xiàn)跨域，因為 Token 是存儲在客戶端的 localStorage 或者作為請求頭的一部分發(fā)送到服務器的，所以不同的域名 Token 信息傳輸通常是不受影響的。
4. 狀態(tài)管理不同：Cookie 是應用程序通過在客戶端存儲臨時數(shù)據(jù)，用于實現(xiàn)狀態(tài)管理的一種機制；Session 是服務器端記錄用戶狀態(tài)的方式，服務器會為每個會話分配一個唯一的 Session ID，并將其與用戶狀態(tài)相關聯(lián)；Token 是一種用于認證和授權(quán)的一種機制，通常表示用戶的身份信息和權(quán)限信息。

2.Cookie 和 Session 有什么關系？

準確來說 Cookie 的實現(xiàn)和 Session 是沒有任何關系的，但 Session 的實現(xiàn)需要借助于 Cookie。

Session 機制的實現(xiàn)流程如下：

1. 會話創(chuàng)建：通常情況下，當用戶登錄成功后，服務器會為該用戶創(chuàng)建一個新的會話。在創(chuàng)建會話過程中，服務器會為該會話生成一個唯一的標識符，通常稱為 Session ID。
2. Session ID 傳遞：服務器將生成的 Session ID 通過響應的方式發(fā)送給客戶端，使用 SetCookie 命令，將用戶的 Session ID 保存在 Cookie 中，通常是一個名為 JSESSIONID 的 Cookie。
3. Session 數(shù)據(jù)存儲：在服務器端，Session 數(shù)據(jù)會被存儲在一個能夠關聯(lián) Session ID 的數(shù)據(jù)結(jié)構(gòu)中（例如內(nèi)存、數(shù)據(jù)庫或者文件存儲等）。常用的方式是將 Session ID 作為鍵，與對應的 Session 用戶身份數(shù)據(jù)進行關聯(lián)。
4. Session ID 驗證與檢索：當用戶發(fā)送一個新的請求時，客戶端會將之前存儲的 Session ID 攜帶在請求的 Cookie 或請求頭中發(fā)送給服務器。服務器會根據(jù) Session ID 找到對應的 Session 數(shù)據(jù)，從而獲得用戶的狀態(tài)信息。
5. Session 數(shù)據(jù)使用：服務器在獲取到 Session 數(shù)據(jù)后，可以根據(jù)具體需求讀取、修改或刪除其中保存的狀態(tài)信息。服務器可以通過 Session 來管理用戶的登錄狀態(tài)、購物車內(nèi)容、用戶配置等。
6. Session 過期與銷毀：Session 有一個有效期限，一般通過設置一個固定的時間，或者在一定時間內(nèi)沒有用戶活動時會將 Session 標記為過期。當 Session 過期時，服務器會銷毀對應的 Session 數(shù)據(jù)，釋放內(nèi)存或其他資源。

所以默認情況下，Session 是借助 Cookie 來完成身份標識的傳遞的，這樣服務器端才能根據(jù) Session ID 和保存的會話信息進行關聯(lián)，用于找到某個具體登錄的用戶，所以說：默認情況下，Session 機制是依賴 Cookie 實現(xiàn)的。

3.禁用 Cookie 之后 Session 還能用嗎？

通過上文我們知道，默認情況下 Session 機制是依賴 Cookie 實現(xiàn)的，那么是不是禁用了 Cookie 之后，Session 機制也就無法使用了呢？其實不然。

除了默認情況下，我們可以使用 Cookie 來傳遞 Session ID 之外，我們可以通過一些特殊的手段來自行傳遞 Session ID，以此來擺脫禁用 Cookie 之后 Session 無法使用的情況，例如以下兩種實現(xiàn)手段：

1. URL Rewriting：可以在每個請求的 URL 中附加 Session ID 參數(shù)。服務器在接收到請求時，解析 URL 中的 Session ID，并與對應的 Session 數(shù)據(jù)進行關聯(lián)。這種方式適用于沒有禁用地址欄中的參數(shù)傳遞的情況。
2. 隱藏表單字段：可以將 Session ID 作為隱藏表單字段的方式傳遞給服務器。當用戶提交表單時，Session ID 將隨著表單數(shù)據(jù)一起發(fā)送給服務器，服務器據(jù)此建立與當前會話的關聯(lián)。

通過以上手段都可以將 Session ID 傳遞到服務器端（雖然麻煩點），然后在服務器端，我們再對以上傳遞的 Session ID 進行獲取和映射，這樣就手動完成了傳遞和匹配登錄用戶的工作了，Session 機制也得已繼續(xù)使用了。

小結(jié)

Cookie、Session 和 Token 通常都是用來保存用戶登錄信息的技術(shù)，但三者的區(qū)別很大：Cookie 適用于簡單的狀態(tài)管理，Session 適用于需要保護用戶敏感信息的場景，而 Token 適用于狀態(tài)無關的身份驗證和授權(quán)。默認情況下 Session 使用了 Cookie 機制來傳遞 Session ID，但在禁用 Cookie 的情況下，使用特殊的手段依然可以傳遞 Session ID，依然可以繼續(xù)使用 Session 機制。而 Token 是不在服務器端保存會話信息的，因此更適用于大型項目和分布式項目。