阅读 1014

面试官可能会问:Cookie为什么会越来越大?

1,Cookie在前端是怎么用的?

Cookie的常用场景,好无疑问,就是做登陆状态的维护的。也就是我们在前端的cookie中,写入了服务端的session,然后通过sesstion来和服务端的接口保持会话状态。

2,cookie会导致http请求变慢吗?

那就会有人问了,为什么很多人会强调做cookie优化?cookie会导致http请求变慢吗?

我们会想到,一个小网站而已,怎么可能导致http的请求变慢?也就一个sesstion而已,可能这个sesstion也就是十几位长度的字符串而已。

3,我们假设这个cookie非常大,存储的信息可能有几十条

在这个假设下,每次请求携带cookie,这时候的http负担就比较重了,几十条信息有多大?有可能导致带宽是平常请求的几倍,甚至几十倍。有可能导致一个http请求,每次在1秒以上的延时。

4、那么,cookie储存几十条信息的可能性有多少?

在一个小公司,我们的主要产品,可能就那么两三个,这些应用都在同一个域名下,就算每一个应用,都有自己的账号系统,我们的cookie也就维护三五个sesstion状态,确实不会很大!

但是,假如这个公司是头条,阿里这样的公司呢?公司底下的应用,可能几百个,甚至上千个。。如果使用cookie,维护自己的账号系统,就非常可能变的cookie的臃肿了。

有些人觉得,那我不在一个域名下不就好了?当然,这是一种解决方案,不过,一个企业可能这么解决问题吗?当项目一直在扩展,域名也要扩展?

5、这个时候怎么办呢?

聪明的人,可能想到了,我们为什么要一个应用,就各自实现一套账号系统呢?现在业界不是有单点登陆吗?我们所有的应用,都用一套账号不就可以了。

是的,这个解决了登陆状态维护的问题!不过新的问题又产生了,不同的项目,业务不同,同一个账号虽然解决了登陆态的问题,但是没办法解决不同业务下,同一个账号的权限问题,或者换一种说法,同一个账号,在不同的业务下,扮演的角色是不一样的。

比如淘宝店主,他自己的账号登陆,他是卖方,使用的是淘宝的某个服务系统,但是他自己也有购物的需求,他自己又得使用淘宝的账号去购买商品,很显然,这种由于业务的割裂感,就算账号打通了也没有意义,淘宝这个域名下,还是要解决这种不同角色引起的权限问题。

这个时候,又有什么其他方案呢?

其实是有的,我们可以使用同一套登陆系统,但是在不同的业务中,我们可以给它绑定不同的角色。比较具有代表性的一个例子就是Boss直聘这个App,你可以是招聘者,也可以是求职者,随意切换,代表着不同的业务。

6、那么,到底我们得到了什么样的结论?

其实我的结论,就是一句空话:在不同的业务场景下,使用合适的方案。

比如我们每天的办公系统,什么gitlab、wiki、jira、rap、jenkens等等,如果都部署在同一个域名下,没必要各自搞一套登陆系统,直接使用单点登陆就行。

假如对于两个不同的业务,比如公司的摊子铺得很大,做外卖业务,也做其他不相干的比如线上购物的业务,其实真的没必要账号相互打通。

那不相干的业务账号真的打通没意义吗?也不全是,比如微信和京东,一个做金融,一个做线上购物,把微信定位为流量服务,把京东定义为用户的真实购物需求,这样直接用导流的方式实现价值突变,也挺好的。

7,假如cookie真的很大,如何做优化?

以上所介绍的东西,就是证明cookie这个东西,是可以变得很大的,和我们平时想到的,只存储一个sesstion的情况是不同的,它真的是可以变得很大,这是实实在在的存在的问题。

那么,如何优化?

可以从两个思维上解决问题:

1、不携带cookie,我们的登陆状态的维护,可以在header中添加字段来解决问题。这个解决了http请求的问题。

2、资源请求,托管cdn,不在同一个域名下加载资源。这个解决了资源加载速度的问题。