写给前端工程师的理论基础(1)--Cookies与Session

今天，有个入行不太长时间的前端工程师朋友，问我什么是什么是Cookie，我当时很惊讶，作为一个前端工程师不能连Cookie都懂呀。考虑到，现在很多前端工程师、JAVA工程师等都不一定是科班出身，而培训机构老师只讲业务代码，或者说在大学学习的内容与生产实际存在一定的差距，这也没有办法，当前国情是这样的，为了让更多的后来者获得一些业务代码之外的知识，尝试着写一个系列，献给更多的后来者。

我们从以下几点切入，如果明白了就掠过，方便快速阅读:

1.HTTP协议
我们知道，HTTP协议是一种不是常连接的协议，可以设想这样一个情景，服务器(Server)需要对多个发起请求的客户端(Client)进行服务，而这种请求是一种请求数据，发送完毕就可以结束了的情景，如果长时间连接，反而没有什么作用，同时，又会消耗很多的系统资源，而对于服务器来讲，这样的客户端越多，系统资源开销也越大，服务器就越可能不稳定。所以，在HTTP 1.1版本中(如果我没记错的话)，将HTTP协议从常连接改为发送完数据，立即断开的机制。
2.Cookies
这里面我用了一个复数，Cookies代表有很多的Cookie，因为你的浏览器中记录的Cookie确确实实有很多。
刚刚我们说过，HTTP协议不是常连接协议，对于常连接协议来讲，当然，HTTP协议是基于TCP协议的，直接往建立握手的数据流中写入数据就可以实现双向通信了，很EZ.
但是，不是常连接协议(发完数据，立即断开)如何来判定访问者的身份？
这时候，Cookie就排上用场了。
设想这样一个场景：
用户C访问网站S，进入登录页面，输入账户和密码后就可以访问S网站中的内容了，S网站也知道这就是用户C，而不是用户B，这种情景，就是Cookie来实现的。
当用户C输入用户名、密码访问完网站S后，网站S向用户C的浏览器中写入一个唯一的字符串(当然，Cookie就是一个字符串)，这个字符串是一个Key-Value的形式，什么是Key-Value呢？周所周知的JSON结构就是一种K-V对形式。

user=wotchinLoginTime=2017-7-13……

这种一一对应的结构就是Key-Value结构，就相当于C语言中的数组中的数组下标改成了一个字符串，不用数字来表示了而已。
那么，下次，当C用户访问S网站的时候，S用户获取user字段，发现是wotchin，网站S认为，很好，在我的网站数据库中，能够检索到wotchin这个内容，就会认为我就是wotchin。
当然，实际不可能是这么简单，不然，我随便改一个user岂不是想变成谁就变成谁了，这个Cookie的内容往往都是加密的，而明文存储的Cookie往往都是一些无关紧要的内容，譬如登陆时间balabal..
3.Session
刚刚我们讲到了Cookie，现在我们说说Session，注意，敲黑板划重点了，如果你准备入职，但是不知道Session，你要注意听了，这是面试的重点。
Cookie是存储在本地的，Session是存储在服务器的，他们的本质功能都是相同的，都是为了表明客户的身份。
那么问题来了，如果只有服务器存储了一个Session，是不是本地的客户机的浏览器就可以不去存储Cookie了呢？当然不是，如果只有服务器存储Session，客户端不存储Cookie，服务器仍然不知道你是谁啊。
那么Session还有什么用呢？
问得很好，你注意观看刚刚说到的Cookie，上面我们说到了，网站从浏览器中取回Cookie的键值，然后去数据库中比对是否存在这样一条记录。那么Session的出现就很好解释了，Session代替了数据库的功能，提供了一种临时的数据存储，用Session的好处是网站后端程序猿可以省不少事情，不用去设计数据库，不用写SQL语句去查询数据库了，省了好多行代码，可以节约时间陪老婆了。
Session存储在哪？存在服务器上的Session专有的目录下。
Session会不会存太多了造成服务器存不下了？有这个可能，不过Session的寿命很短，对于Java服务器来讲，一般是25-30分钟，PHP一般是20-30分钟，到期就自动清除，所以，如果不是存的太多太多，一般不至于存不下。
Session会不会造成性能问题？当然会！！
Session毕竟是一种缓存在硬盘上的存储方式，而且不像关系型数据库那样，有比较高效的数据结构(咳咳，一般是B+树、B-树的索引)和搜索算法，毕竟是业余选手，存储得多了，必然会造成性能问题，所以说Session的使用情景是临时的、少量的、不是那种高并发、高流量的情景。
对于大型的高可用、HA的网站，一般都用Cookie和数据库搭配使用，Session使用的情景应该慎重考虑。