我們來看一個瀏覽器 console 下面的 http 請求報文信息：

image.png

請求頭：

GET /users/c55c7a9c8de6/collections_and_notebooks?slug=c55c7a9c8de6 HTTP/1.1
Host: www.lxweimin.com
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
Accept: application/json
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36
Referer: http://www.lxweimin.com/u/c55c7a9c8de6
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8
Cookie: read_mode=day; default_font=font1; locale=zh-CN; Hm_lvt_0c0e9d9b1e7d617b3e6842e85b9fb068=1535007755,1535007759,1535007763,1535513728; remember_user_token=W1sxMjMzMzU2XSwiJDJhJDEwJHpFMmtGazRnbmh4NGM1TEdyeUF5Sy4iLCIxNTM1OTUzODAwLjk0NDY0MzUiXQ%3D%3D--4ab87bf885e8a9bdbda1b093767fa0fb7411a3ca; _m7e_session=c26b9432859e34aa1b2b4e0e189d92f4; Hm_lpvt_0c0e9d9b1e7d617b3e6842e85b9fb068=1536031042; sensorsdata2015jssdkcross=%7B%22distinct_id%22%3A%221233356%22%2C%22%24device_id%22%3A%2216329fd1006146-0b58f4b8ef8644-33627f07-1296000-16329fd1007493%22%2C%22props%22%3A%7B%22%24latest_traffic_source_type%22%3A%22%E7%9B%B4%E6%8E%A5%E6%B5%81%E9%87%8F%22%2C%22%24latest_referrer%22%3A%22%22%2C%22%24latest_referrer_host%22%3A%22%22%2C%22%24latest_search_keyword%22%3A%22%E6%9C%AA%E5%8F%96%E5%88%B0%E5%80%BC_%E7%9B%B4%E6%8E%A5%E6%89%93%E5%BC%80%22%2C%22%24latest_utm_source%22%3A%22weibo%22%2C%22%24latest_utm_medium%22%3A%22writer_share%22%2C%22%24latest_utm_campaign%22%3A%22maleskine%22%2C%22%24latest_utm_content%22%3A%22note%22%7D%2C%22first_id%22%3A%2216329fd1006146-0b58f4b8ef8644-33627f07-1296000-16329fd1007493%22%7D

響應頭：

HTTP/1.1 200 OK
Date: Tue, 04 Sep 2018 03:17:22 GMT
Server: Tengine
Content-Type: application/json; charset=utf-8
Transfer-Encoding: chunked
X-Frame-Options: DENY
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
ETag: W/"41b415323302b70884ab0f19102e0c42"
Cache-Control: max-age=0, private, must-revalidate
Set-Cookie: locale=zh-CN; path=/
Set-Cookie: _m7e_session=c26b9432859e34aa1b2b4e0e189d92f4; path=/; expires=Tue, 04 Sep 2018 09:17:22 -0000; secure; HttpOnly
X-Request-Id: 231219ce-62c9-4cd3-8114-70d037c558d9
X-Runtime: 0.296158
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Content-Encoding: gzip
X-Via: 1.1 PSgdhzdx6bv55:7 (Cdn Cache Server V2.0), 1.1 xingdianxin14:6 (Cdn Cache Server V2.0)
Connection: keep-alive

那么 Cookie 跟 Session 我們都看到了嗎？

Stateless applications

Web application servers are generally "stateless":

• Each HTTP request is independent; server can't tell if 2 requests came from the same browser or user.
• Web server applications maintain no information in memory from request to request (only information on disk survives from one request to another).
• Statelessness not always convenient for application developers: need to tie together a series of requests from the same user.

Browser cookies

Cookie basics:
The first time a browser connects with a particular server, there are no cookies.

When the server responds it includes a Set-Cookie: header that defines a cookie.

Each cookie is just a name-value pair.

In the future whenever the browser connects with the same server, it includes a Cookie: header containing the name and value, which the server can use to connect related requests.

What's in a cookie?
Name and data.
Data size limited by browsers (typically < 4 KB).

A server can define multiple cookies with different names, but browsers limit the number of cookies per server (around 50).

Domain for this cookie: server, port (optional), URL prefix (optional). The cookie is only included in requests matching its domain.

Expiration date: browser can delete old cookies.

Sessions

Cookies are used by the server to implement sessions:

A pool of data related to an active connection (one browser instance).
Typically the cookie for an application contains an identifier for a session.
Web frameworks like Spring，Rails.etc do most of the work of managing sessions and cookies.

Cookie 機制

Cookies是服務器在本地機器上存儲的小段文本并隨每一個請求發送至同一個服務器。IETF RFC 2965 HTTP State Management Mechanism 是通用cookie規范。網絡服務器用HTTP頭向客戶端發送cookies，在客戶終端，瀏覽器解析這些cookies并將它們保存為一個本地文件，它會自動將同一服務器的任何請求縛上這些cookies 。

具體來說cookie機制采用的是在客戶端保持狀態的方案。它是在用戶端的會話狀態的存貯機制，他需要用戶打開客戶端的cookie支持。cookie的作用就是為了解決HTTP協議無狀態的缺陷所作的努力。

正統的cookie分發是通過擴展HTTP協議來實現的，服務器通過在HTTP的響應頭中加上一行特殊的指示以提示瀏覽器按照指示生成相應的cookie。然而純粹的客戶端腳本如JavaScript也可以生成cookie。而cookie的使用是由瀏覽器按照一定的原則在后臺自動發送給服務器的。瀏覽器檢查所有存儲的cookie，如果某個cookie所聲明的作用范圍大于等于將要請求的資源所在的位置，則把該cookie附在請求資源的HTTP請求頭上發送給服務器。

cookie的內容主要包括：名字，值，過期時間，路徑和域。路徑與域一起構成cookie的作用范圍。若不設置過期時間，則表示這個cookie的生命期為瀏覽器會話期間，關閉瀏覽器窗口，cookie就消失。這種生命期為瀏覽器會話期的cookie被稱為會話cookie。會話cookie一般不存儲在硬盤上而是保存在內存里，當然這種行為并不是規范規定的。若設置了過期時間，瀏覽器就會把cookie保存到硬盤上，關閉后再次打開瀏覽器，這些cookie仍然有效直到超過設定的過期時間。存儲在硬盤上的cookie可以在不同的瀏覽器進程間共享，比如兩個IE窗口。而對于保存在內存里的cookie，不同的瀏覽器有不同的處理方式。

而session機制采用的是一種在服務器端保持狀態的解決方案。同時我們也看到，由于采用服務器端保持狀態的方案在客戶端也需要保存一個標識，所以session機制可能需要借助于cookie機制來達到保存標識的目的。而session提供了方便管理全局變量的方式 。

session是針對每一個用戶的，變量的值保存在服務器上，用一個sessionID來區分是哪個用戶session變量,這個值是通過用戶的瀏覽器在訪問的時候返回給服務器，當客戶禁用cookie時，這個值也可能設置為由get來返回給服務器。

就安全性來說：當你訪問一個使用session 的站點，同時在自己機子上建立一個cookie，建議在服務器端的session機制更安全些，因為它不會任意讀取客戶存儲的信息。

Session 機制

session機制是一種服務器端的機制，服務器使用一種類似于散列表的結構（也可能就是使用散列表）來保存信息。

當程序需要為某個客戶端的請求創建一個session時，服務器首先檢查這個客戶端的請求里是否已包含了一個session標識（稱為session id），如果已包含則說明以前已經為此客戶端創建過session，服務器就按照session id把這個session檢索出來使用（檢索不到，會新建一個），如果客戶端請求不包含session id，則為此客戶端創建一個session并且生成一個與此session相關聯的session id，session id的值應該是一個既不會重復，又不容易被找到規律以仿造的字符串，這個session id將被在本次響應中返回給客戶端保存。

保存這個session id的方式可以采用cookie，這樣在交互過程中瀏覽器可以自動的按照規則把這個標識發揮給服務器。一般這個cookie的名字都是類似于SEEESIONID。但cookie可以被人為的禁止，則必須有其他機制以便在cookie被禁止時仍然能夠把session id傳遞回服務器。

經常被使用的一種技術叫做URL重寫，就是把session id直接附加在URL路徑的后面。還有一種技術叫做表單隱藏字段。就是服務器會自動修改表單，添加一個隱藏字段，以便在表單提交時能夠把session id傳遞回服務器。

Cookie與Session都能夠進行會話跟蹤，但是完成的原理不太一樣。普通狀況下二者均能夠滿足需求，但有時分不能夠運用Cookie，有時分不能夠運用Session。下面經過比擬闡明二者的特性以及適用的場所。

1、存取方式的不同

Cookie中只能保管ASCII字符串，假如需求存取Unicode字符或者二進制數據，需求先進行編碼。Cookie中也不能直接存取Java對象。若要存儲略微復雜的信息，運用Cookie是比擬艱難的。

而Session中能夠存取任何類型的數據，包括而不限于String、Integer、List、Map等。Session中也能夠直接保管Java Bean乃至任何Java類，對象等，運用起來十分便當。能夠把Session看做是一個Java容器類。

2、隱私策略的不同

Cookie存儲在客戶端閱讀器中，對客戶端是可見的，客戶端的一些程序可能會窺探、復制以至修正Cookie中的內容。而Session存儲在服務器上，對客戶端是透明的，不存在敏感信息泄露的風險。

假如選用Cookie，比較好的方法是，敏感的信息如賬號密碼等盡量不要寫到Cookie中。最好是像Google、Baidu那樣將Cookie信息加密，提交到服務器后再進行解密，保證Cookie中的信息只要本人能讀得懂。而假如選擇Session就省事多了，反正是放在服務器上，Session里任何隱私都能夠有效的保護。

3、有效期上的不同

使用過Google的人都曉得，假如登錄過Google，則Google的登錄信息長期有效。用戶不用每次訪問都重新登錄，Google會持久地記載該用戶的登錄信息。要到達這種效果，運用Cookie會是比較好的選擇。只需要設置Cookie的過期時間屬性為一個很大很大的數字。

由于Session依賴于名為JSESSIONID的Cookie，而Cookie JSESSIONID的過期時間默許為–1，只需關閉了閱讀器該Session就會失效，因而Session不能完成信息永世有效的效果。運用URL地址重寫也不能完成。而且假如設置Session的超時時間過長，服務器累計的Session就會越多，越容易招致內存溢出。

4、服務器壓力的不同

Session是保管在服務器端的，每個用戶都會產生一個Session。假如并發訪問的用戶十分多，會產生十分多的Session，耗費大量的內存。因而像Google、Baidu、Sina這樣并發訪問量極高的網站，是不太可能運用Session來追蹤客戶會話的。

而Cookie保管在客戶端，不占用服務器資源。假如并發閱讀的用戶十分多，Cookie是很好的選擇。關于Google、Baidu、Sina來說，Cookie或許是唯一的選擇。

5、瀏覽器支持的不同

Cookie是需要客戶端瀏覽器支持的。假如客戶端禁用了Cookie，或者不支持Cookie，則會話跟蹤會失效。關于WAP上的應用，常規的Cookie就派不上用場了。

假如客戶端瀏覽器不支持Cookie，需要運用Session以及URL地址重寫。需要注意的是一切的用到Session程序的URL都要進行URL地址重寫，否則Session會話跟蹤還會失效。關于WAP應用來說，Session+URL地址重寫或許是它唯一的選擇。

假如客戶端支持Cookie，則Cookie既能夠設為本瀏覽器窗口以及子窗口內有效（把過期時間設為–1），也能夠設為一切閱讀器窗口內有效（把過期時間設為某個大于0的整數）。但Session只能在本閱讀器窗口以及其子窗口內有效。假如兩個瀏覽器窗口互不相干，它們將運用兩個不同的Session。（IE8下不同窗口Session相干）

6、跨域支持上的不同

Cookie支持跨域名訪問，例如將domain屬性設置為“.biaodianfu.com”，則以“.biaodianfu.com”為后綴的一切域名均能夠訪問該Cookie。跨域名Cookie如今被普遍用在網絡中，例如Google、Baidu、Sina等。而Session則不會支持跨域名訪問。Session僅在他所在的域名內有效。

僅運用Cookie或者僅運用Session可能完成不了理想的效果。這時應該嘗試一下同時運用Cookie與Session。Cookie與Session的搭配運用在實踐項目中會完成很多意想不到的效果。

Session是保存在服務端的，有一個唯一ID標識。通常在內存數據庫中存儲。例如，Redis 集群。

現代 web 框架都有了非常便利的集成，例如：Spring Boot 使用 Redis 共享 Session。（參考《Spring Boot 開發實戰》 第15章 使用Spring Session集成Redis實現Session共享 273頁）

新書上架：《Spring Boot 開發實戰》

— 基于 Kotlin + Gradle + Spring Boot 2.0 的企業級服務端開發實戰

京東下單鏈接

https://item.jd.com/31178320122.html

天貓下單鏈接

https://detail.tmall.com/item.htm?id=574928877711