其他分享
首页 > 其他分享> > 重新认识cookie与session

重新认识cookie与session

作者：互联网

思维导图：

图片

就从夏洛特烦恼的一个名场面开始引出本文话题：

这大爷也确实没在"状态"！

图片

 

理清概念

无状态

HTTP 是没有状态的Web服务器，什么是无状态呢？

就像夏洛特烦恼中的拿着扇子的大爷一样，一次对话完成后下一次对话完全不知道上一次对话发生了什么。

如果说Web服务器只是用来管理静态文件还好说，对方是谁其实不重要，把文件从磁盘中读取出来发出去即可,客户端与服务器连接就会关闭，再次交换数据需要建立新的连接。这时候服务器无法从连接上跟踪会话。。但是随着网络的不断发展，比如电商中的购物车只有记住了用户的身份才能够执行接下来的一系列动作。所以此时就需要我们无状态的服务器记住一些事情;

会话跟踪

会话，就是用户登录网站后的一系列动作，比如浏览商品添加到购物车并购买。Session跟踪是 Web 程序里常用的技术，用来跟踪用户的整个会话；常用的会话跟踪技术是Cookie与Session。

遇到问题

马上就面临一个问题，那就是如果管理会话，必须记住哪些人登录系统， 哪些人往自己的购物车中放商品， 也就是说我必须把每个人区分开，这也是一个不小的挑战，因为 HTTP请求是无状态的，所以想出的办法就是给大家发一个会话标识 (session id) , 说白了就是一个随机的字串，每个人收到的都不一样， 每次大家向我发起HTTP请求的时候，把这个字符串给一并捎过来， 这样我就能区分开谁是谁了呀；

这样客户端是嗨皮了，但是服务器就不嗨皮了，每个人只需要保存自己的 session id，而服务器要保存所有人的session id ！如果访问服务器多了， 就得由成千上万，甚至几十万个。

尝试改变

这对服务器说是一个巨大的开销 ， 严重的限制了服务器扩展能力，

比如说我用两个机器组成了一个集群， 小F通过机器A登录了系统， 那 session id 会保存在机器A上， 假设小F的下一次请求被转发到机器B怎么办？机器B可没有小F的 session id啊。

有时候可以用一点小伎俩：session sticky ， 就是让小F的请求一直粘连在机器A上， 但是这也不管用， 要是机器A挂掉了， 还得转到机器B去。

那只好做session 的复制了， 把 session id 在两个机器之间搬来搬去， 快累死了。图片后来有个叫Memcached的人想到个办法：那不如把 session id 集中存储到一个地方， 所有的机器都来访问这个地方的数据， 这样一来，就不用复制了， 但是也增加了单点失败的可能性， 要是那个负责 session 的机器挂了， 所有人都得重新登录一遍， 估计得被人骂死。图片也尝试把这个单点的机器也搞出集群，增加可靠性， 但不管如何， 这小小的 session 对我来说是一个沉重的负担

心理斗争

于是有人就一直在思考， 我为什么要保存这可恶的session呢， 只让每个客户端去保存该多好？

可是如果不保存这些 session id, 怎么验证客户端发给我的session id 的确是我生成的呢？如果不去验证，我们都不知道他们是不是合法登录的用户， 那些不怀好意的家伙们就可以伪造 session id , 为所欲为了。

嗯，对了，关键点就是验证 ！

得到方法

比如说， 小F已经登录了系统， 我给他发一个令牌(token)， 里边包含了小F的 user id， 下一次小F 再次通过 Http 请求访问我的时候， 把这个 token 通过Http header 带过来不就可以了。

不过这和session id没有本质区别啊， 任何人都可以可以伪造， 所以我得想点儿办法， 让别人伪造不了。

那就对数据做一个签名吧， 比如说我用 HMAC-SHA256 算法，加上一个只有我才知道的密钥， 对数据做一个签名， 把这个签名和数据一起作为token ， 由于密钥别人不知道， 就无法伪造token了。图片这个 token 我不保存， 当小F把这个 token 给我发过来的时候，我再用同样的 HMAC-SHA256 算法和同样的密钥，对数据再计算一次签名， 和token 中的签名做个比较， 如果相同， 我就知道小F已经登录过了，并且可以直接取到小F的 user id, 如果不相同， 数据部分肯定被人篡改过， 我就告诉发送者：对不起，你没有认证；图片Token 中的数据都是用明文保存的，虽然我会用Base64做下编码，但请注意那不是加密， 还是可以被别人看到的哦， 所以我不能在其中保存像密码这样的敏感信息。

当然， 如果一个人的 token 被别人偷走了， 那我也没办法， 我也会认为小偷就是合法用户， 这其实和一个人的 session id 被别人偷走是一样的。

这样一来， 我就可以不保存 session id 了， 我只是生成token , 然后验证token ， 我用我的CPU来计算时间获取了我的 session 存储空间 ！

解除了session id这个负担， 可以说是无事一身轻， 我的集群现在可以轻松地做水平扩展， 用户访问量增大， 直接加机器就行。这种无状态的感觉实在是太好了！

Cookie

前面说过 http 是无状态的协议，浏览器和服务器不可能凭协议的实现就可以辨别请求的上下文的。于是 cookie 登场，既然协议本身不能分清链接，那我就在请求头部手动带些上下文信息吧，好像还是有些虚：图片

我们去旅游的时候，到了景区可能我们需要放行李，被大包小包压着总感觉不爽。在存放行李后，服务员会给你一个牌子，上面写着你的行李放在哪个格子，离开时，你就能凭这个牌子和上面的数字对应起来就成功取出行李。cookie 这个牌子做的正是这么一件事，旅客就像客户端，寄存处就像服务器，凭着写着数字的牌子，寄存处（服务器）就能分辨出不同旅客（客户端），就这么简单。

cookie 是一个非常具体的东西，指的就是浏览器里面能永久存储的一种数据，仅仅是浏览器实现的一种数据存放功能。

过程

cookie由服务器生成，发送给浏览器，浏览器把 cookie 以 kv 形式保存到某个目录下的文本文件内，下一次请求同一网站时会把该 cookie 发送给服务器。由于cookie 是存在客户端上的，所以浏览器加入了一些限制确保cookie不会被恶意使用，同时不会占据太多磁盘空间，所以每个域的 cookie 数量是有限的。

Cookie中的参数设置

图片接下来我们用代码演示一下服务器是如何生成，可以自己搭建一个后台服务器，这里我用的是 SpringBoot 搭建的，并且写入 SpringMVC 的代码：

@RequestMapping("/testCookies")
public String cookies(HttpServletResponse response){
    response.addCookie(new Cookie("testUser","xxxx"));
    return "cookies";
}

项目启动以后我们输入路径http://localhost:8005/testCookies，然后查看发的请求。可以看到下面那张图使我们首次访问服务器时发送的请求，可以看到服务器返回的响应中有Set-Cookie 字段。而里面的 key=value 正是我们服务器中设置的值。图片

接下来我们再次刷新这个页面可以看到在请求体中已经设置好了 Cookie 字段，并且将我们的值也带过去了。这样服务器就能够根据 Cookie中的值 记住我们的信息了。图片

接下来我们换一个请求呢？那是不是 Cookie 也会带过去呢？接下来我们输入路径http://localhost:8005请求。我们可以看到 Cookie 字段还是被带过去了。图片

那么浏览器的 Cookie 是存放在哪呢？如果是使用的是 Chrome 浏览器的话，那么可以按照下面步骤。

在计算机打开Chrome 在右上角，一次点击更多图标->设置 在底部，点击高级 在隐私设置和安全性下方，点击网站设置 依次点击 Cookie->查看所有 Cookie 和网站数据 然后可以根据域名进行搜索所管理的Cookie数据。所以是浏览器替你管理了 Cookie 的数据，如果此时你换成了 Firefox 等其他的浏览器，因为 Cookie 刚才是存放在 Chrome 里面的，所以服务器又蒙圈了，不知道你是谁，它就会给 Firefox 再次贴上小纸条。图片

下面我就简单演示一下这几个参数的用法及现象。

Path

设置为cookie.setPath("/testCookies")，接下来我们访问http://localhost:8005/testCookies，我们可以看到在左边和我们指定的路径是一样的，所以Cookie才在请求头中出现，接下来我们访问http://localhost:8005，我们发现没有Cookie 字段了，这就是 Path 控制的路径。图片

Domain设置为cookie.setDomain("localhost")，接下来我们访问http://localhost:8005/testCookies我们发现下图中左边的是有Cookie的字段的，但是我们访问http://172.16.42.81:8005/testCookies，看下图的右边可以看到没有 Cookie 的字段了。这就是 Domain 控制的域名发送Cookie。图片接下来的几个参数就不一一演示了，相信到这里大家应该对Cookie有一些了解了。

那么Cookie是谁产生的呢？Cookies是由服务器产生的。接下来我们描述一下Cookie产生的过程

浏览器第一次访问服务端时，服务器此时肯定不知道他的身份，所以创建一个独特的身份标识数据，格式为 key=value，放入到 Set-Cookie 字段里，随着响应报文发给浏览器。图片Set-Cookie格式如下：

Set-Cookie: value[; expires=date][; domain=domain][; path=path][; secure]

浏览器看到有 Set-Cookie 字段以后就知道这是服务器给的身份标识，于是就保存起来，下次请求时会自动将此key=value值放入到Cookie字段中发给服务端。图片

服务端收到请求报文后，发现Cookie字段中有值，就能根据此值识别用户的身份然后提供个性化的服务。

接下来我们用代码演示一下服务器是如何生成，我们自己搭建一个后台服务器，这里我用的是SpringBoot搭建的，并且写入SpringMVC代码如下:

@RequestMapping("/testCookies")
public String cookies(HttpServletResponse response){
    response.addCookie(new Cookie("testUser","xxxx"));
    return "cookies";
}

项目启动以后我们输入路径http://localhost:8005/testCookies，然后查看发的请求。可以看到下面那张图使我们首次访问服务器时发送的请求，可以看到服务器返回的响应中有Set-Cookie 字段。而里面的 key=value 值正是我们服务器中设置的值。

cookie被偷咋办

cookie 这也会被偷吗？确实会，这就是一个经常被提到的网络安全问题——CSRF。

cookie 诞生初似乎是用于电商存放用户购物车一类的数据，但现在前端拥有两个storage（local、session），两种数据库（websql、IndexedDB），根本不愁信息存放问题，所以现在基本上 100% 都会在连接上证明客户端的身份。例如登录之后，服务器给你一个标志，就存在 cookie 里，之后再连接时，都会自动带上 cookie，服务器便分清谁是谁。另外，cookie 还可以用于跟踪一个用户，这就产生了隐私问题，于是也就有了“禁用 cookie”这个选项（然而现在这个时代禁用 cookie 是挺麻烦的事情）。

客户端请求服务器时，如果该服务器需要记录该用户状态，就使用 response 向客户端浏览器发送一个cookie，客户端会将 cookie 保存起来。当浏览器再次请求该网站时，浏览器把请求和该 cookie 一起提交给服务器。服务器检查该cookie，以此来辨认用户状态。

cookie只是实现 session 的其中一种方案。虽然是最常用的，但并不是唯一的方法。禁用cookie后还有其他方法存储，比如放在 url 中; 现在大多都是Session + Cookie，但是只用session不用cookie，或是只用cookie，不用session在理论上都可以保持会话状态。可是实际中因为多种原因，一般不会单独使用;

用session只需要在客户端保存一个id，实际上大量数据都是保存在服务端。如果全部用cookie，数据量大的时候客户端是没有那么多空间啦，奥图片如果只用 cookie 不用 session，那么账户信息全部保存在客户端，一旦被劫持，全部信息都会泄露。并且客户端数据量变大，网络传输的数据量也会变大！

小结

简而言之, session 有如用户信息档案表, 里面包含了用户的认证信息和登录状态等信息. 而cookie 就是用户通行证：

为什么有了cookie，还需要session呢？cookie 存在于客户端 将用户信息通过网络发送到客户端是极不安全的 且cookie大小不能超过 4K所以就出现了服务器端的机制——session

所以当用户和服务器连接时，就建立了一个 session，服务器为之分配了一个唯一的sessionID。很多时候 session 是和 cookie 共同使用的，客户端将请求和cookie发送至服务器，session根据唯一sessionID和cookie辨别用户。这样既增加了安全机制，也可以方便用户操作。

Session

Cookie是存储在客户端方，Session是存储在服务端方，客户端只存储SessionId

在上面我们了解了什么是Cookie，既然浏览器已经通过 Cookie 实现了有状态这一需求，前面已经提到过为啥有 session , 再详细点说，这里我们想象一下，如果将账户的一些信息都存入Cookie中的话，一旦信息被拦截，那么我们所有的账户信息都会丢失掉。所以就出现了Session，在一次会话中将重要信息保存在Session中，浏览器只记录 SessionId一个SessionId 对应一次会话请求:图片

@RequestMapping("/testSession")
@ResponseBody
public String testSession(HttpSession session){
    session.setAttribute("testSession","this is my session");
    return "testSession";
}


@RequestMapping("/testGetSession")
@ResponseBody
public String testGetSession(HttpSession session){
    Object testSession = session.getAttribute("testSession");
    return String.valueOf(testSession);
}

这里我们写一个新的方法来测试Session是如何产生的，我们在请求参数中加上HttpSession session，然后再浏览器中输入http://localhost:8005/testSession进行访问可以看到在服务器的返回头中在Cookie中生成了一个 SessionId。然后浏览器记住 SessionId下次访问时可以带着此Id，然后就能根据此Id找到存储在服务端的信息了。图片

此时我们访问路径http://localhost:8005/testGetSession，如图发现得到了我们上面存储在 **Session **中的信息:图片

那么 Session 什么时候过期呢？图片

既然我们知道了Session是在服务端进行管理的，那么或许你们看到这有几个疑问，Session 是在在哪创建的？Session是存储在什么数据结构中？接下来带领大家一起看一下Session是如何被管理的。

Session的管理是在 容器 中被管理的，什么是容器呢？Tomcat、Jetty 等都是容器。接下来我们拿最常用的Tomcat为例来看下Tomcat是如何管理Session的。在ManageBase的createSession是用来创建Session用的。

@Override
public Session createSession(String sessionId) {
    //首先判断Session数量是不是到了最大值，最大Session数可以通过参数设置
    if ((maxActiveSessions >= 0) &&
            (getActiveSessions() >= maxActiveSessions)) {
        rejectedSessions++;
        throw new TooManyActiveSessionsException(
                sm.getString("managerBase.createSession.ise"),
                maxActiveSessions);
    }

    // 重用或者创建一个新的Session对象，请注意在Tomcat中就是StandardSession
    // 它是HttpSession的具体实现类，而HttpSession是Servlet规范中定义的接口
    Session session = createEmptySession();


    // 初始化新Session的值
    session.setNew(true);
    session.setValid(true);
    session.setCreationTime(System.currentTimeMillis());
    // 设置Session过期时间是30分钟
    session.setMaxInactiveInterval(getContext().getSessionTimeout() * 60);
    String id = sessionId;
    if (id == null) {
        id = generateSessionId();
    }
    session.setId(id);// 这里会将Session添加到ConcurrentHashMap中
    sessionCounter++;
    
    //将创建时间添加到LinkedList中，并且把最先添加的时间移除
    //主要还是方便清理过期Session
    SessionTiming timing = new SessionTiming(session.getCreationTime(), 0);
    synchronized (sessionCreationTiming) {
        sessionCreationTiming.add(timing);
        sessionCreationTiming.poll();
    }
    return session
}

到此我们明白了Session是如何创建出来的，创建出来后Session会被保存到一个ConcurrentHashMap中。可以看 StandardSession 类。

protected Map<string, session> sessions = new ConcurrentHashMap&lt;&gt;();

到这里大家应该对Session有简单的了解了。

Session是存储在 Tomcat的容器中，所以如果后端机器是多台的话，因此多个机器间是无法共享Session的，此时可以使用Spring提供的分布式 Session 的解决方案，是将Session放在了Redis中。

Token

token 也称作令牌，由uid+time+sign[+固定参数]；

token 的认证方式类似于临时的证书签名, 并且是一种服务端无状态的认证方式, 非常适合于 REST API 的场景. 所谓无状态就是服务端并不会保存身份认证相关的数据。

组成

token在客户端一般存放于localStorage，cookie，或sessionStorage中。在服务器一般放在数据库里面；

Session是将要验证的信息存储在服务端，并用 SessionId 和数据进行对应，SessionId 由客户端存储，在请求时将SessionId也带过去，因此实现了状态的对应。而 Token 是在服务端将用户信息经过 Base64Url 编码过后传给在客户端，每次用户请求的时候都会带上这一段信息，因此服务端拿到此信息进行解密后就知道此用户是谁了，这个方法叫做JWT(Json Web Token);

JWT的结构 实际的JWT大概长下面的这样，它是一个很长的字符串，中间用.分割成三部分图片

JWT是有三部分组成的

Header 是一个Json对象，描述JWT的元数据，通常是下面这样子的

{
  "alg": "HS256",
  "typ": "JWT"
}

上面代码中，alg属性表示签名的算法（algorithm），默认是 HMAC SHA256（写成 HS256）；typ属性表示这个令牌（token）的类型（type），JWT 令牌统一写为JWT。最后，将上面的 JSON 对象使用 Base64URL 算法转成字符串就行；简直就是：

图片

JWT 作为一个令牌（token），有些场合可能会放到 URL（比如 api.example.com/?token=xxx）。Base64 有三个字符+、/和=，在 URL 里面有特殊含义，所以要被替换掉：=被省略、+替换成-，/替换成_ 。这就是 Base64URL 算法。

token认证流程

token 的认证流程与 cookie 很相似

token可以抵抗csrf，但是cookie+session不行

假如用户正在登陆银行网页，同时登陆了攻击者的网页，并且银行网页未对 csrf攻击 进行防护。攻击者就可以在网页放一个表单，该表单提交src为http://www.bank.com/api/transfer，body为count=1000&to=Tom。倘若是session+cookie，用户打开网页的时候就已经转给Tom1000元了.因为form 发起的 POST 请求并不受到浏览器同源策略的限制，因此可以任意地使用其他域的 Cookie 向其他域发送 POST 请求，形成 CSRF 攻击。在post请求的瞬间，cookie会被浏览器自动添加到请求头中。但token不同，token 是开发者为了防范csrf而特别设计的令牌，浏览器不会自动添加到headers里，攻击者也无法访问用户的token，所以提交的表单无法通过服务器过滤，也就无法形成攻击了！

图片

session

Token相比较于Session的优点在于，当后端系统有多台时，由于是客户端访问时直接带着数据，因此无需做共享数据的操作。

Token的优点

分布式情况下的session和token

我们已经知道 session 时有状态的，一般存于服务器内存或硬盘中，当服务器采用分布式或集群时，session 就会面对负载均衡问题。

负载均衡多服务器的情况，不好确认当前用户是否登录，因为多服务器不共享session。这个问题也可以将 session 存在一个服务器中来解决，但是就不能完全达到负载均衡的效果。当今的几种解决 session 负载均衡的方法。

而token是无状态的，token字符串里就保留所有的用户信息：

Payload

Payload部分也是一个Json对象，用来存放实际需要传输的数据，JWT官方规定了下面几个官方的字段供选用。

{
  "name": "xiaoMing",
  "age": 14
}

默认情况下 JWT 是不加密的，任何人只要在网上进行Base64解码就可以读到信息，所以一般不要将秘密信息放在这个部分。这个Json对象也要用 Base64URL 算法转成字符串;

Signature

Signature部分是对前面的两部分的数据进行 签名，防止数据篡改。

首先需要定义一个秘钥，这个秘钥只有服务器才知道，不能泄露给用户，然后使用Header中指定的签名算法(默认情况是 HMAC SHA256)，算出签名以后将Header、Payload、Signature三部分拼成一个字符串，每个部分用.分割开来，就可以返给用户了。

HS256可以使用单个密钥为给定的数据样本创建签名。当消息与签名一起传输时，接收方可以使用相同的密钥来验证签名是否与消息匹配。

图片

20

Java中如何使用Token

上面我们介绍了关于JWT的一些概念，接下来如何使用呢？首先项目中引入Jar包

compile('io.jsonwebtoken:jjwt:0.9.0')

然后编码如下:

// 签名算法 ，将对token进行签名
SignatureAlgorithm signatureAlgorithm = SignatureAlgorithm.HS256;
// 通过秘钥签名JWT
byte[] apiKeySecretBytes = DatatypeConverter.parseBase64Binary("SECRET");
Key signingKey = new SecretKeySpec(apiKeySecretBytes, signatureAlgorithm.getJcaName());
Map<string,object> claimsMap = new HashMap&lt;&gt;();
claimsMap.put("name","xiaoMing");
claimsMap.put("age",14);
JwtBuilder builderWithSercet = Jwts.builder()
        .setSubject("subject")
        .setIssuer("issuer")
        .addClaims(claimsMap)
        .signWith(signatureAlgorithm, signingKey);
System.out.printf(builderWithSercet.compact());

发现输出的Token:

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJzdWJqZWN0IiwiaXNzIjoiaXNzdWVyIiwibmFtZSI6InhpYW9NaW5nIiwiYWdlIjoxNH0.3KOWQ-oYvBSzslW5vgB1D-JpCwS-HkWGyWdXCP5l3Ko

此时在网上随便找个Base64解码的网站就能将信息解码出来：图片

总结

相信大家看到这应该对Cookie、Session、Token有一定的了解了，接下来再回顾一下重要的知识点：

Cookie 是存储在客户端的

Session 是存储在服务端的，可以理解为一个状态列表。拥有一个唯一会话标识SessionId。可以根据SessionId在服务端查询到存储的信息。

Session会引发一个问题，即后端多台机器时Session共享的问题，解决方案可以使用Spring提供的框架。Token 类似一个令牌，无状态的，服务端所需的信息被Base64编码后放到Token中，服务器可以直接解码出其中数据；

标签：重新认识,Session,session,cookie,Cookie,服务器,客户端
来源： https://blog.csdn.net/dreamgetting/article/details/118300658