http/https–Cookie與Session

一、用戶端與服務端請求響應的關系

USER（用戶端） 請求 tomcat（伺服器）, 屬于HTTP請求。http請求是無狀态的,即每次服務端接收到用戶端的請求時，都是一個全新的請求，伺服器并不知道用戶端的曆史請求記錄；是以當使用者從用戶端請求一次登入後，登入成功，再次進行請求時，因為tomcat不能識别這兩次會話都是來自同一個浏覽器，即服務端不知道用戶端的曆史請求記錄；就會再次彈出登入對話框。

為了解決用戶端與服務端會話同步問題。這便引出了下面幾個概念：cookie、session。

于是，我們便把伺服器中産生的會話sessionID存儲到用戶端浏覽器cookie中去。在用戶端存在周期為浏覽器關閉時，消失。這樣便解決了用戶端請求服務端會話不同步問題。

二、cookie是什麼

一個HTTP cookie的（網絡Cookie，浏覽器cookie）是一小片資料的一個伺服器發送到使用者的網絡浏覽器。浏覽器可以存儲它并将其與下一個請求一起發送回同一伺服器。通常，它用于判斷兩個請求是否來自同一個浏覽器 - 例如，保持使用者登入。它記住無狀态 HTTP協定的有狀态資訊。

三、session是什麼

用戶端請求服務端，服務端（Tomcat）會為這次請求開辟一塊記憶體空間，這個對象便是Session對象， 存儲結構為ConcurrentHashMap。

session的目的：彌補HTTP無狀态特性，伺服器可以利用session存儲用戶端在同一個會話期間的一些操作記錄。

四、HTTP是無狀态的

在同一連接配接上連續執行的兩個請求之間沒有連結。對于試圖與某些頁面連貫地互相作用的使用者而言，這立即存在問題，例如，使用電子商務購物籃。但是，雖然HTTP本身的核心是無狀态，但HTTP cookie允許使用有狀态會話。使用标頭可擴充性，HTTP Cookie被添加到工作流中，允許在每個HTTP請求上建立會話以共享相同的上下文或相同的狀态。

五、session的實作機制

1、伺服器如何判斷用戶端發送過來的請求屬于同一個會話？

用session id區分；session id 相同即認為是同一個會話；

1

​ 在tomcat中session id中用JSESSIONID來表示；

2、伺服器、用戶端如何擷取sessionID?SessionID在期間是如何傳輸的？

​ 伺服器第一次接收到請求時，開辟了一塊Session空間（建立了Session對象），同時生成一個Session id，并通過響應頭的Set-Cookie：“JSESSIONID=XXXXXXX”指令，向用戶端發送要求設定cookie的響應； 用戶端收到響應後，在本機用戶端設定了一個JSESSIONID=XXXXXXX的cookie資訊，該cookie的過期時間為浏覽器會話結束；

接下來用戶端每次向同一個網站發送請求時，請求頭都會帶上該cookie資訊（包含Session id）； 然後，伺服器通過讀取請求頭中的Cookie資訊，擷取名稱為JSESSIONID的值，得到此次請求的Session id；

​ 注意：伺服器隻會在用戶端第一次請求響應的時候，在響應頭上添加Set-Cookie：“JSESSIONID=XXXXXXX”資訊，接下來在同一個會話的第二第三次響應頭裡，是不會添加Set- Cookie：“JSESSIONID=XXXXXXX”資訊的； 而用戶端是會在每次請求頭的cookie中帶上JSESSIONID資訊；

cookie與session的差別：

cookie資料儲存在用戶端，session資料儲存在伺服器端。

簡 單的說，當你登入一個網站的時候，如果web伺服器端使用的是session,那麼所有的資料都儲存在伺服器上面，用戶端每次請求伺服器的時候會發送 目前會話的sessionid，伺服器根據目前sessionid判斷相應的使用者資料标志，以确定使用者是否登入，或具有某種權限。由于資料是存儲在伺服器 上面，是以你不能僞造，但是如果你能夠擷取某個登入使用者的sessionid，用特殊的浏覽器僞造該使用者的請求也是能夠成功的。sessionid是服務 器和用戶端連結時候随機配置設定的，一般來說是不會有重複，但如果有大量的并發請求，也不是沒有重複的可能性。

如果浏覽器使用的是 cookie，那麼所有的資料都儲存在浏覽器端，比如你登入以後，伺服器設定了 cookie使用者名(username),那麼，當你再次請求伺服器的時候，浏覽器會将username一塊發送給伺服器，這些變量有一定的特殊标記。服 務器會解釋為 cookie變量。是以隻要不關閉浏覽器，那麼 cookie變量便一直是有效的，是以能夠保證長時間不掉線。如果你能夠截獲某個使用者的 cookie變量，然後僞造一個資料包發送過去，那麼伺服器還是認為你是合法的。是以，使用 cookie被攻擊的可能性比較大。如果設定了的有效時間，那麼它會将 cookie儲存在用戶端的硬碟上，下次再通路該網站的時候，浏覽器先檢查有沒有 cookie，如果有的話，就讀取該 cookie，然後發送給伺服器。如果你在機器上面儲存了某個論壇 cookie，有效期是一年，如果有人入侵你的機器，将你的 cookie拷走，然後放在他的浏覽器的目錄下面，那麼他登入該網站的時候就是用你的的身份登入的。是以 cookie是可以僞造的。當然，僞造的時候需要主意，直接copy cookie檔案到 cookie目錄，浏覽器是不認的，他有一個index.dat檔案，存儲了 cookie檔案的建立時間，以及是否有修改，是以你必須先要有該網站的 cookie檔案，并且要從保證時間上騙過浏覽器，曾經在學校的vbb論壇上面做過試驗，copy别人的 cookie登入，冒用了别人的名義發文章，完全沒有問題。

Session是由應用伺服器維持的一個伺服器端的存儲空間，使用者在連接配接伺服器時，會由伺服器生成一個唯一的SessionID,用該SessionID 為辨別符來存取伺服器端的Session存儲空間。而SessionID這一資料則是儲存到用戶端，用Cookie儲存的，使用者送出頁面時，會将這一 SessionID送出到伺服器端，來存取Session資料。這一過程，是不用開發人員幹預的。是以一旦用戶端禁用Cookie，那麼Session也會失效。

伺服器也可以通過URL重寫的方式來傳遞SessionID的值，是以不是完全依賴Cookie。如果用戶端Cookie禁用，則伺服器可以自動通過重寫URL的方式來儲存Session的值，并且這個過程對程式員透明。

可以試一下，即使不寫Cookie，在使用request.getCookies();取出的Cookie數組的長度也是1，而這個Cookie的名字就是JSESSIONID，還有一個很長的二進制的字元串，是SessionID的值。

三：Session與Cookie差別和聯系：

Cookies是屬于Session對象的一種。但有不同，Cookies不會占伺服器資源，是存在客服端記憶體或者一個cookie的文本檔案中；而“Session”則會占用伺服器資源。是以，盡量不要使用Session，而使用Cookies。但是我們一般認為cookie是不可靠的，session是可靠地，但是目前很多著名的站點也都以來cookie。有時候為了解決禁用cookie後的頁面處理，通常采用url重寫技術，調用session中大量有用的方法從session中擷取資料後置入頁面。

Cookies與Session的應用場景：

Cookies的安全性能一直是倍受争議的。雖然Cookies是儲存在本機上的，但是其資訊的完全可見性且易于本地編輯性，往往可以引起很多的安全問題。是以Cookies到底該不該用，到底該怎樣用，就有了一個需要給定的底線。

先來看看，網站的敏感資料有哪些。

登陸驗證資訊。一般采用Session(“Logon”)＝true or false的形式。

使用者的各種私人資訊，比如姓名等，某種情況下，需要儲存在Session裡

需要在頁面間傳遞的内容資訊，比如調查工作需要分好幾步。每一步的資訊都儲存在Session裡，最後在統一更新到資料庫。

當然還會有很多，這裡列舉一些比較典型的

假如，一個人孤僻到不想碰Session，因為他認為，如果使用者萬一不小心關閉了浏覽器，那麼之前儲存的資料就全部丢失了。是以，他出于好意，決定把這些用Session的地方，都改成用Cookies來存儲，這完全是可行的，且基本操作和用Session一模一樣。那麼，下面就針對以上的3個典型例子，做一個分析

很顯然，隻要某個有意非法入侵者，知道該網站驗證登陸資訊的Session變量是什麼，那麼他就可以事先編輯好該Cookies，放入到Cookies目錄中，這樣就可以順利通過驗證了。這是不是很可怕？

Cookies完全是可見的，即使程式員設定了Cookies的生存周期（比如隻在使用者會話有效期内有效），它也是不安全的。假設，使用者忘了關浏覽器 或者一個惡意者硬性把使用者給打暈，那使用者的損失将是巨大的。

這點如上點一樣，很容易被它人竊取重要的私人資訊。但，其還有一個問題所在是，可能這些資料資訊量太大，而使得Cookies的檔案大小劇增。這可不是使用者希望所看到的。

顯然，Cookies并不是那麼一塊好啃的小甜餅。但，Cookies的存在，當然有其原因。它給予程式員更多發揮程式設計才能的空間。是以，使用Cookies改有個底線。這個底線一般來說，遵循以下原則。

不要儲存私人資訊。

任何重要資料，最好通過加密形式來儲存資料（最簡單的可以用URLEncode，當然也可以用完善的可逆加密方式，遺憾的是，最好不要用md5來加密）。

是否儲存登陸資訊，需有使用者自行選擇。

長于10K的資料，不要用到Cookies。

也不要用Cookies來玩點讓客戶驚喜的小遊戲。

四、cookie最典型的應用是：

（一）：判斷使用者是否登陸過網站，以便下次登入時能夠直接登入。如果我們删除cookie，則每次登入必須從新填寫登入的相關資訊。

（二）：另一個重要的應用是“購物車”中類的處理和設計。使用者可能在一段時間内在同一家網站的不同頁面選擇不同的商品，可以将這些資訊都寫入cookie，在最後付款時從cookie中提取這些資訊，當然這裡面有了安全和性能問題需要我們考慮了。

參考https://blog.csdn.net/qq_28296925/article/details/80921585

https://blog.csdn.net/duan1078774504/article/details/51912868