我们首先了解以下前提知识:
http是一种无状态性的协议。
我们无法仅从http层了解到某个请求是源自于哪一个用户。
结合到实例里:
假如我们在浏览器里登录一个系统,点击登录,网站友好的提示:登陆成功。
那么我们进行下一个操作,比如,点击打开个人中心,服务器懵了,究竟应该打开谁的个人中心呢?
刚才我们确实登录了系统,可是这次我们是发送了另外一个http请求,仅从http层,服务器无法判断,前面的登录请求和这里的打开个人中心请求,是否来自同一个浏览器窗口。
cookie是用来辨识客户端的一种方式,Session是另一种。
一个简单的例子:
- 当用户登录时,我们可以将用户名及密码存在cookie里,用户在该页面再次操作时,该页面存放的cookie将随着URL请求发送到服务器,服务器得到用户名和密码,就能得到该http请求的用户信息。
cookie遇到了问题:
- cookie不仅可以存放用户的登录信息,还可以存放用户的其他信息,存放的信息较多的时候,每个URL请求都携带了一个巨大的cookie,给服务器带宽带来了很大的压力。
我们有了解决办法:
解决办法就是session。
为什么一定要用用户名和密码来判断用户呢?
对的,当一个用户登录成功之后,我们可以在服务器生成一个特殊的ID(比如我们可以把用户名和时间戳加一起进行MD5),然后把该ID返回给客户端,客户端放在cookie里,服务器本地也保存一份,接下来,用户再次向服务器发送请求的时候,cookie里就只有这个ID,服务器拿到这个ID,就知道了是哪一个用户发送的请求了。
好像还有点问题没有解决:
我们现在通过session可以知道用户是谁了,可是原来保存在cookie里的其他信息怎么办?
我们可以在服务器上给用户一点储存空间。
我们把原来要保存在cookie里的信息全部放在服务器上。比如说,我们创建一个user文件夹,里面再按session的ID创建一些文件夹,每个文件夹里面放用户原来要保存的信息(这里只是为了形象,具体实现不是这么做的)。
这样,用户拿着他的sessionID,就能在服务器上找到他的”cookie”。
还有更多的问题:
session好像完美解决了cookie的弱点,那他有什么缺点呢?
现在的大型网站都是分布式服务器,session如何在多服务器之间传递?如何处理大量session碎片给服务器带来的负荷?
在这些问题下,cookie好像又成了最佳的解决方案,所以还是应了那句话:没有最好的编程语言,只有最会运用的程序设计人员。