複習：Cookie 和 Session 的區別

第一層樓

Cookie：瀏覽器cookie，是服務器發送到用戶瀏覽器並存在本地的一小塊數據，它會在瀏覽器下次向同一服務器再發送請求時被攜帶併發送到服務器上。一般告知服務器兩個請求是否來自同一瀏覽器，入保持用戶的登陸狀態。Cookie使基於無狀態的HTTP協議記錄穩定的狀態信息成爲了可能。

Cookie主要用於如下三個方面：

　　會話狀態管理（如用戶登陸狀態、購物車、遊戲分數或其它須要記錄的信息）

　　個性化設置（如用戶自定義設置、主題等）

　　瀏覽器行爲跟蹤（如跟蹤分析用戶行爲等）

Session表明着服務器和客戶端一次會話的過程。Session對象存儲特定用戶會話所需的屬性及配置信息。這樣，當用戶在應用程序的Web頁之間跳轉時，存儲在Session對象中的變量將不會丟失，二是在整個用戶會話中一直存在下去。當客戶端關閉會話或者Session超時失效時會話結束。

第二層樓

Cookie和Session有什麼不一樣？

　　做用範圍不用，Cookie保存在客戶端（瀏覽器）Session保存在服務器端

　　存儲方式不一樣，Cookie只能保存ASCII，Session能夠存任意數據類型，通常狀況下，咱們能夠在Session中保持一些經常使用變量信息，好比說UserId等。

　　有效期不一樣，Cookie可設置爲長時間保持，好比咱們常用的默認登陸功能，Session通常失效時間較短，客戶端關閉或者Session超時都會失效。

　　隱私策略不用，Cookie存儲在客戶端，比較容易遭到不法獲取，早期有人將用戶的登陸名和密碼存儲在Cookie中致使信息被竊取，Session存儲在服務端，安全性相對Cookie要好一些。

　　存儲大小不一樣，單個Cookie保存的數據不能超過4K，Session可存儲數據遠高於Cookie.

第三層樓

　　爲何須要Cookie和Session，他們有什麼關聯？

　　提及來爲何須要Cookie，這就須要從瀏覽器開始提及，咱們都知道瀏覽器是沒有狀態的（HTTP協議無狀態），這就意味着瀏覽器並不知道是張三仍是李四和服務器打交道。這個時候就須要有一個機制來告訴服務端，本次操做用戶是否登陸是哪一個用戶在執行的操做，那這套機制的實現就須要Cookie和Session的配合。

那麼Coookie和Session是如何配合的呢？

　　

用戶第一次請求服務器的時候，服務器根據用戶提交的相關信息，建立對應的Session，請求返回時將此Session的惟一標識信息SessionId返回給瀏覽器，瀏覽器接收到服務器返回的SessionID信息後，會將此信息存入到Cookie中，同事Cookie記錄此SessionID屬於哪一個域名。

當用戶第二次訪問服務器的時候，請求會自動判斷此域名下是否存在Cookie信息，若是存在自動將Cookie信息也發送給服務端，服務端會從Cookie中獲取SessionID，再根據SessionID查找對應的Session信息，若是沒有找到說明用戶沒有登陸或者登陸失效，若是找到SessionID是連接Cookie的Session的一道橋樑，大部分系統也是根據此原理驗證用戶的登陸狀態。

第四層樓

　　既然服務端是根據Cookie中的信息判斷用戶是否登陸，那麼若是瀏覽器中禁止了Cookie，若是保障整個機制的正常運轉。

　　第一種方案：每次請求中都攜帶一個SeesionID的參數，也能夠Post的方式提交，也能夠在請求的地址後面拼接xxx?SessionID=12345....

　　第二種方案：Token機制，Token機制多用於App客戶端和服務器交互的模式，也能夠用於Web端作用戶狀態管理。Token的意思是"令牌"，是服務端生成的一串字符串，做爲客戶端進行請求的一個標識。Token機制和Cookie和Session的使用機制比較相似。

當用戶第一次登陸後，服務器根據提交的用戶信息生成一個Token，響應時將Token返回給客戶端，之後客戶端只需帶上這個Token前來請求數據便可，無需再次登陸驗證。

　　第五層樓

　　如何考慮分佈式Session問題？

　　在互聯網公司爲了能夠支撐更大的流量，後端每每須要多臺服務器共同來支撐前端用戶請求，那若是用戶在A服務器登陸了，第二次請求跑到服務B就會出現登陸失效問題。

　　分佈式Session通常會有如下幾種解決方案：

　　Nginx ip_hash策略，服務端使用Nginx代理，每一個請求按訪問IP的hash分配，這樣來自同一IP固定訪問一個後臺服務器，避免了在服務器A建立Session，第二次分發到服務器B的現象。

　　Session賦值，任何一個服務器上的Session發生改變（增刪改），該節點會把這個Session的全部內容序列化，而後廣播給全部其餘節點。

　　共享Session，服務端無狀態話，將用戶的Session等信息使用緩存中間件來統一管理，保障分發到每個服務器的響應結果都一致。（建議採用這個方案）

　　第六層樓

　　

如何解決跨域請求？Jsonp 跨域的原理是什麼？

提及跨域請求，必需要了解瀏覽器的同源策略，同源策略/SOP（Same origin policy）是一種約定，由 Netscape 公司 1995年引入瀏覽器，它是瀏覽器最核心也最基本的安全功能，若是缺乏了同源策略，瀏覽器很容易受到 XSS、CSFR 等攻擊。所謂同源是指"協議+域名+端口"三者相同，即使兩個不一樣的域名指向同一個 ip 地址，也非同源。

解決跨域請求的經常使用方法是：

• 經過代理來避免，好比使用 Nginx 在後端轉發請求，避免了前端出現跨域的問題。

• 經過 Jsonp 跨域

• 其它跨域解決方案

重點談一下 Jsonp 跨域原理。瀏覽器的同源策略把跨域請求都禁止了，可是頁面中的 <script><img><iframe>標籤是例外，不受同源策略限制。Jsonp 就是利用 <script>標籤跨域特性進行跨域數據訪問。

JSONP 的理念就是，與服務端約定好一個回調函數名，服務端接收到請求後，將返回一段 Javascript，在這段 Javascript 代碼中調用了約定好的回調函數，而且將數據做爲參數進行傳遞。當網頁接收到這段 Javascript 代碼後，就會執行這個回調函數，這時數據已經成功傳輸到客戶端了。

JSONP 的缺點是：它只支持 GET 請求，而不支持 POST 請求等其餘類型的 HTTP 請求。