Http程序代码&使用者登入
刚开始基础http协定的爸爸妈妈，一般单厢听到两个词汇，叫“无状况”（经常在复试中，提及http协定，很多校友会能回答这2点：如前所述TCP；无状况。看来http的无状况优点，如果是各种课程表里单厢强调的），那么，到底那个无状况，是甚么个意思呢，以及由此带出的其他概念，比如说 session、cookie-based session、JWT又是是不是回事。
Http无状况
简单理解在我看来，所谓无状况，是没有梦境功能，如果想像成两个人，那那个人是无法梦境，他讲错他们认识的人，做过甚么事。
或者，举个B2C的，比如说有一家B2C公司叫“有啊”(晓得那个老师的如果有些年纪了:))，你在中文网站上，重新加入了10件货品到科季夫，创下网页，辨认出科季夫空荡荡(Ossun还以为他们中了那种移走科季夫的神券……)，布季夫科季夫都有bug，这还是不是融洽的剁手呢？“有啊”的技师也辨认出了那个难题，决意想个方式，化解http的无状况难题。
session(程序代码)
那是不是能读懂每一使用者加了甚么样货品到科季夫呢？技师想，门口的度娘烧烤店，每天都是老板娘度娘拿了原稿，食客自助餐的时候，她就在原稿上翻看不同的食客，分别点了甚么样菜，B2C中文网站是不是也能这么搞。
于是，技师在server(服务器)端，写了几段标识符，给每人来访者，都在笔记本电脑上以两个文档(session)，来历史记录他重新加入的所有货品。嗯，轻松，现在能历史记录下每一食客的科季夫内容了。
cookie-based session
技师A完稿标识符，积极主动轻松的他，给技师B递交了 merge request ，准备起身去泡一碗生津润。还没顾得上起程，技师B遍跑了过来，说那个方案存有严重难题，虽然在服务端有session来历史记录使用者的科季夫货品，但还是没化解，使用者创下网页后，服务端不晓得创下网页其间，是同一人(应用程序client)的难题，毕竟 Http是无状况的！
A思索了一会儿，服务端无法界定创下网页其间是同一应用程序(client)的难题，那我就加两个甚么东西，在服务端session文档聚合后，把那个文档方向(session id)，传回给应用程序，应用程序把那个方向存有应用程序邻近地区(cookie)，先期每天都把那个方向传回给我，我就能找到那次的session文档了。
A再次轻松的化解了眼前的难题。
上线运行几段时间以后，运维C跑来找到小A说，你那个逻辑有难题，在服务器上聚合了太多的文档，快把磁盘空间占满了！小A心想，这是个难题，每天都聚合两个新的session文档，即使磁盘便宜，长久也hold不住啊。那干脆给这些session文档加个过期时间，到了过期时间后，就自动(或者被动)删除，这样不就减轻了服务器空间压力了么。
运维C听完，万一哪天短时间爆发大量请求，还是可能会把服务器磁盘打满，到时候还得给小A擦屁股；初次之外，先期准备服务端进行集群化部署，在多台服务器之间共享session也是难题。正巧最近听到个时髦的词汇叫 JWT ，不妨叫小A去瞅瞅能无法化解那个难题。
JWT(JSON Web Tokens)
小A看了几篇JWT的文章，觉得JWT 很好很强大，直接干掉了服务端创建的session文档，直接把session文档内容发给应用程序，反正他们在里面有签名，也不怕恶意使用者篡改数据，轻松！说干就干，小A拉上一两个切网页的(也可能是小A他们，毕竟有全干技师的存有)，cookie都干掉，其间端使用JWT进行使用者认证，前端用 localStorage 或者 sessionStorage 存有应用程序里，空间还比cookie大，简直轻松，还能顺手化解那些甚么 CORS 的前端安全难题，perfect！一切都很轻松，直到……
有一天，使用者打电话给“有啊”客服，他们手机被盗，要求客服把他们之前登入的设备都退出登入态又有一天，安全组辨认出某个使用者访问异常，需要晓得某个使用者在多少设备处于登入态
总结
OK，扯了这么多废话，还是简单的总结下吧
Http程序代码总结：
Http无状态，每一请求都是独立的，你在同一应用程序里连续2次访问两个中文网站，http不晓得2次访问都是同一人(或者应用程序)实际生活中，我们是需要有状况的，即使能维持几段时间也很有意义(就像阿米尔汗的电影《未知死亡》里的15秒梦境男主那样)为了达到“有状况”，前人发明了 session 来代表依次程序代码，为了在应用程序(应用程序)和服务器之间保持(识别)session，发明了 cookie 。在 cookie 里保存两个 session id ，服务端根据那个session id就能找到对应的程序代码数据后来又出来一批大神，说 session 增加了服务端的复杂度，比如说在后端集群之间共享 session ，分布式的 session 存储也是一大挑战，于是，JWT 应运而生。不在服务端保存 session 数据(个人感觉大多数场景还是不免不了)，把程序代码数据都发给应用程序，加上两个签名，秘钥只在服务端有，这样在保证一定安全的基础上，大大降低了服务端复杂度、减少服务端资源。当然了，正如上面提及的JWT 方案也存有一些难题……除此之外，还有各种自定义的所谓 token ，其原理基本都上面的 cookie-based session 或者 JWT 一样
使用者登入总结
有点尴尬的是，本文题目里包含了“使用者登入”，好像写到这里了，才辨认出没有讲使用者登入的内容。不过，如果你能够比较好的理解上面的内容，使用者登入在我看来就简单了。
通常后端会提供两个登入接口，前端发送使用者名、密码之类的，后，主要的工作是存储使用者已经登入的标记，那个标记，你能有以下方式来存储：
通常不管使用者是否登入，我们单厢有两个 session 数据。那我们当然能这样，在使用者登入后，直接就在普通的session 里，加上当前登入使用者的ID之类的。先期请求到达server端时，只需要检查 session 里是否有使用者ID，就能判断使用者是否已登入(这种方案，通常我在做一些内部系统的时候这样实现，毕竟实现简单)有的中文网站，普通session 和使用者登入状况，有不同的过期时间；或者为了更高的安全性，比如说涉及使用者登入的 cookie ，单独设置 httpOnlysecuresamesite 等属性。因此，需要单独和普通的session区别开，单独设置两个登入的cookie，也是一种方式，不过实现起来，会比第一种方案复杂一点点JWT ，登入后就把使用者ID放到 JWT 里，发给前端。我个人不建议在 JWT里包含使用者的权限等信息；我认为JWT里如果尽量少的存储数据，毕竟那个是公开的(虽然你能加密)，而且也会增加http请求头大小。
相关资料
JWT官网阮一峰JWT入门教程Session vs Token Based Authentication
时2021-07-2622:25:00竣工于成都
