前后端分離以及token的使用

• 為什么使用前后端分離：

首先說一下jsp的工作原理：

jsp實際上也是是一個繼承自Servlet接口的java類，實際上它就是一個Servlet，JSP的頁面渲染是在后端完成的，經過tomcat的處理后，把jsp轉為html后，再統一發送給前端（瀏覽器）顯示出來

那現在手機移動端app這么普及，那我怎么寫一份后端代碼，即又可以顯示在手機app上面，又可以在pc端跑呢？

手機app不是瀏覽器，他不可以顯示 html 跟 jsp 哦 , 而且手機跟瀏覽器不一樣，是不是需要把數據交給前端，讓前端來渲染數據才可以解決問題

前后端通過json格式交互數據

主流前端框架MVVM

vm層（視圖模型層）通過接口從后台m層（model層）請求數據，vm層繼而和v（view層）實現數據的雙向綁定。

• token（令牌）

  token與Session的區別

    SESSION 是服務器通過 Key-Value 對來保存數據的一種機制，比如 APP 的登錄狀態可以用 SESSION 來保存。
    TOKEN 翻譯過來叫令牌，令牌是什么意思？可以拿現實中的令牌對比，現實中的令牌起到通行證的作用，而這在服務端也是一樣的。我們在登錄后，服務端使用 SESSION 保存我們的登錄狀態，並把 SESSION 的 Key 返回給客戶端，那么這個 Key 就成為我們的令牌（TOKEN），我們以后再訪問數據，就直接把這個 TOKEN 隨着請求一起發送給服務端，這樣服務端通過這個 TOKEN 在 SESSION 中查找數據，如果有就說明 TOKEN 有效（就像你去旅游，關口認可你的通行證），並取出你的登錄數據，利用你的用戶信息（保存在登錄數據內）查出你想要的內容。
  

  為什么使用token不用Session

  Session的原理：

  當用戶第一次通過瀏覽器使用用戶名和密碼訪問服務器時，服務器會驗證用戶數據，驗證成功后在服務器端寫入session數據，向客戶端瀏覽器返回sessionid，瀏覽器將sessionid保存在cookie中，當用戶再次訪問服務器時，會攜帶sessionid，服務器會拿着sessionid從服務器獲取session數據，然后進行用戶信息查詢，查詢到，就會將查詢到的用戶信息返回，從而實現狀態保持
  

​ Session的弊端：

1、服務器壓力增大

通常session是存儲在內存中的，每個用戶通過認證之后都會將session數據保存在服務器的內存中，而當用戶量增大時，服務器的壓力增大。

2、CSRF跨站偽造請求攻擊

session是基於cookie進行用戶識別的, cookie如果被截獲，用戶就會很容易受到跨站請求偽造的攻擊。

3、擴展性不強

如果將來搭建了多個服務器，雖然每個服務器都執行的是同樣的業務邏輯，但是session數據是保存在內存中的（不是共享的），用戶第一次訪問的是服務器1，當用戶再次請求時可能訪問的是另外一台服務器2，服務器2獲取不到session信息，就判定用戶沒有登陸過。

token實現原理

   Token 是在服務端產生的。如果前端使用用戶名/密碼向服務端請求認證，服務端認證成功，那么在服務端會返回 Token 給前端。前端可以在每次請求的時候帶上 Token 證明自己的合法地位。如果這個 Token 在服務端持久化（比如存入數據庫），那它就是一個永久的身份令牌。

token 有很多種實現方式，這里以jwt為例子：

 JWT ： 是一種基於JSON，用於在網絡上聲明某種主張的令牌（token），jwt通常有三部分組成：頭部信息(header) 消息體， 和簽名

頭部信息：指定了該JWT使用的簽名算法

消息體：包含JWT中儲存的信息
簽名：通過密鑰跟算法生成簽名

token與Session的不同點：

  token與session的不同主要在
  1，認證成功后，會對當前用戶數據進行加密，生成一個加密字符串token，返還給客戶端（服務器端並不進行保存）

2，瀏覽器會將接收到的token值存儲在Local Storage中，（通過js代碼寫入Local Storage，通過js獲取，並不會像cookie一樣自動攜帶）

3，再次訪問時服務器端對token值的處理：服務器對瀏覽器傳來的token值進行解密，解密完成后進行用戶數據的查詢，如果查詢成功，則通過認證，實現狀態保持，所以，即時有了多台服務器，服務器也只是做了token的解密和用戶數據的查詢，它不需要在服務端去保留用戶的認證信息或者會話信息，這就意味着基於token認證機制的應用不需要去考慮用戶在哪一台服務器登錄了，這就為應用的擴展提供了便利，解決了session擴展性的弊端。

一，登錄：

二，業務請求：

三，token過期，刷新token