App 开发者应该知道的 cookie 和 session

现在的移动端的 App 已经基本被 Android 和 iOS 两者瓜分天下，我们知道： Android 应用目前使用 Android/Kotlin 开发，iOS 应用使用 Object-C / Swift 开发。它们的共同点都是调用手机原生组件，这样的方式能充分利用手机原有性能。无论从界面美观性方面，还是从使用流畅性方面，相比 React-Native 方式开发的应用都有很大的优势。它们的发展又同时在 PC 端之后，为了方便地对 PC 端页面进行兼容，都具有特定的组件用来加载网页: Andriod 中使用 WebView, iOS 中使用 UIWebView/WKWebView。所以作为移动端的开发者，对传统网页的前端请求/后台响应的实现流程，需要有基本了解。

前端缓存cookie_前端缓存问题前端缓存cookie_前端缓存问题


前端缓存cookie_前端缓存问题


前端缓存cookie_前端缓存问题


我们知道一个完整的请求流程包括请求/响应两个过程：

步 PC 端发送请求，通过请求行、请求头和请求体来发送详细的请求；第二步收到对请求进行处理，根据请求的具体内容来响应。在这样的 PC 端和服务端对话中，想要管理会话，需要解决以下两个问题：

1 如何标识不同的 PC ？

2 如何标识服务端的不同请求？

问题 1 是为了识别客户端。如为会话的客户端定义了 ID 身份标识，那么就能对该客户端进行个性化服务。这就像一个人去一家新的理发厅理发，那么理发厅开始时只能按照对待新人的既定流程提供服务：比如 “极力的办卡”、“询问你喜欢哪种发型” 等。但是如果你成为了该理发店的 VIP ，拥有了会员卡 (有了身份标识)，那么该理发店就能根据对你的服务记录来提供服务，比如你喜欢的发型、询问你对上次理发的感受等。

实际网络请求中解决的方式和上面的流程很相似，通过 cookie 来作为标识客户端的 ID 。次网络请求会话过程中，端定义标识客户端的 cookie ，返回给客户端并存放在客户端的缓存中。客户端再次发送请求时，会把自身的 cookie 传递给，被识别后就能定制化提供响应。比如我们浏览时常常看到的上一次浏览时间、还有在购物网站看到的历史浏览记录等，都是基于 cookie 来实现。下面是通过 google 开发者工具在访问时生成的 cookie :

cookie 具有以下特点：

1 具有有效期, 就像理发卡里面的余额，过期就失效了；

2 同一个请求也可以设置多个 cookie ，类似一个人可以在一家理发店办理

多个 VIP，来享受不同的服务类型；

3 同一个 PC 端可以有不同的 cookie，来对应不同的；

问题 2 中服务端通过 session 来实现区别不同的网络请求。就像一个人去理发店后，店长（）安排一个理发师（网络请求）来为他服务。所以 session 和 cookie 一一对应，二者都是有服务端创建、定义。不同的是 session 存放在服务端，而 cookie 由服务端创建后存储在客户端，使用 session 同样能达到 cookie 实现的效果。存放在

服务端的 session 能够避免信息存储在客户端后被用户手动清除的问题，但是从另一方面来说，也增务端的存储压力。

综上，cookie / session 是一个网络请求中相互对应的标识符。cookie 用在客户端，session 存储在服务端。利用 cookie / session 服务端能实现对一个网络请求的定制响应。

可以利用 IDEA 来模拟一个 PC 端网页请求/响应的流程。需要以下环境：

1 Tomcat ；

2 以 Ja Servlet 作为后台服务程序；

3 InliJ IDEA 作为 IDE ;

如果不知道如何用 InliJ IDEA 配置 Tomcat 和 Ja Servlet ，请参考我的上篇文章： 基于 InliJ IDEA 模拟 Servlet 网络请求

前端登陆实现

四种方式

Cookie 出现的原因： HTTP 协议是无状态的，每次请求都会建立一个新的链接，请求结束就会断开链接，优点就是可以节省链接资源，缺点就是无法保存用户状态。Cookie 的出现就是为了解决这个问题。

Cookie 是存储在浏览器中的，可以通过 Js 和 set-cookie 这个响应字段来进行设置。

cookie 的限制：

有了 cookie 之后，服务端就可以从客户端获取到信息，如果需要对信息进行验证，那么还需要 session

服务端在收到客户端的请求之后，会在中开辟一片内存空间来存放 session

次登陆之后，下次再访问的时候就会携带这个 cookie，服务端就可以根据 sessionId 进行验证用户是否登陆（判断这个 sessionId 和服务端保存的 sessionId 是否一致，是否有这个 sessionId 的记录或者记录是否有效）

客户端浏览器访问的时候，把客户端信息以某种形式记录在上。这就是 Session。客户端浏览器再次访问时只需要从该 Session 中查找该客户的状态就可以了。

Token 是 生成的一个字符串，作为客户端请求的一个令牌。次登陆之后，会生成一个 Token 返回给客户端，客户端后续访问的时候，只需带上这个 Token 进行身份认证

缺点

JWT（Json Web Token）

服务端不需要存储 Token 那么服务端是怎么验证客户端传递过来的 Token 是否有效的呢？

：

Token 并不是杂乱无章的字符串，而是通过多种算法拼接而成的字符串

header 部分指定了这个 Token 所使用的签名算法

payload 部分表明了这个 JWT 的意图

signature 部分为 JWT 的签名，主要是为了让 JWT 不被随意的篡改

签名的部分有两个步骤

一：

二:

的 Token 计算如下：

单点登陆指的是公司会搭建一个公共的认证中心，公司里的所有产品的认证都可以在这个认证中心中完成，一个产品在认证中心认证之后，再去访问其他产品时就不需要再次认证

这个时候，由于 存在已登录的 Cookie 信息，所以端直接认证成功。

这个时候由于认证中心存在之前登陆过的 cookie，所以不需要再输入账号密码，直接从第四步开始执行

目前我们已经完成了单点登录，在同一套认证中心的管理下，多个产品可以共享登录态。现在我们需要考虑退出了，即：在一个产品中退出了登录，怎么让其他的产品也都退出登录？

原理也不难，其实就是在携带 ticket 去请求认证中心的时候，再去请求一下认证中心的退出登陆的 api 即可

当某个产品 c 退出登陆时

sso 就是一个集中地验证系统。你项目内请求时，向 sso 发一个请求，他给你个 token 你扔到游览器缓存里，请求的时候放在请求头里带着。和其他验证接口一样。 他好就好在，一个账号在不同系统里都可以登录，因为不同项目可以共用这个 token。并且通过 sso 集中管理一些用户信息，你可以方便的拿用户信息。

以微信为例子

说一下前端数据存储方式（cookies，localstorage，sessionstorage，indexedDB）的区别？

Cookie初是在客户端用于存储会话信息的，其要求对任意HTTP请求发送Set-CookieHTTP头作为响应的一部分。cookie

以name为名称，以value为值，名和值在传送时都必须是URL编码的。浏览器会存储这样的会话信息，在这之后，通过为每个请求添加Cookie

HTTP头将信息发送回。

localstorage

存储方式：

以键值对(Key-Value)的方式存储，存储，失效，除非手动删除。

sessionstorage

HTML5 的本地存储 API 中的 localStorage 与 sessionStorage 在使用方法上是相同的，区别在于 sessionStorage 在关闭页面后即被清空，而 localStorage 则会一直保存。

IndexedDB

索引数据库(IndexedDB) API（作为 HTML5 的一部分）对创建具有丰富本地存储数据的数据密集型的离线 HTML5 Web 应用程序很有用。同时它还有助于本地缓存数据，使传统在线 Web 应用程序（比如移动 Web 应用程序）能够更快地运行和响应。