以前就知道“http请求是无状态的”，然后有人发明Cookie为http打了个补丁，解决“无状态”的问题。Cookie可以记录用户的身份喜好，但是却不能取代用户的账号密码功能，不过又可以用Cookie存储账号密码......如果面试官问，这些我都会说都知道。但其实自己并不理解，也就是“知其然不知其所以然”，今天感觉理解了，这里记录下。
首先，怎么理解“http请求是无状态的”？这可以理解为“http请求是无记忆的”，就是说如果浏览器向服务端发起一个http请求一个html页面，然后又刷新再请求相同页面，服务器并不会说“刚刚不是给你了吗？”，而是对方请求多少次，服务器就返回多少次页面，即使这些请求的内容都是一样的，这既浪费流量又浪费时间。这就叫“http请求是无状态的”。
不过实际上，如果用户不断刷新一个页面，请求相同的内容，服务器并不会真的每次又再给一个相同的页面返回，而是返回一个304状态码，翻译下就是：“刚刚才给你了，自己去找”，然后浏览器就会到本地缓存中把之前访问过的页面找出来，显示给用户。之所以http请求能这样，是因为引入了Cookie机制。
Cookie机制就像便条，http请求就像村里开小卖部但记性又极差的张伯，而且记忆是差到人脸都记不住的程度。张伯(http)在不会用便条(Cookie)时，做生意概不赊账，一手交钱一手交货。但是村里很多人出门不喜欢带钱，买小件东西喜欢赊账攒到一定额度一次性付清。结果就是这些人会觉得照顾张伯的生意很麻烦，张伯也少赚了一份钱。
张伯是怎么用便条的呢？因为记性差到人脸都记不住，所以他不光要自己记，还有写一张便条给买东西的人(Set-Cookie)。他会给买东西的人起个不会跟别人重复的名字(SESSID)，自己记着，让买东西的人也记着。以后想赊账的人，每次买东西就出示便条，张伯一核对，看便条上记录的是自己起的名字(SESSID)，二话不说就赊账。第一次来没有便条也不要紧，张伯现取一个(Set-Cookie)，一回生二回熟。综上所述，这就是Cookie对无状态的http发挥的作用。
可是问题又来了，既然Cookie可以识别用户，记录用户信息，那干嘛还要用户注册账号，登录时输入密码？主要有2个原因：1、Cookie机制本身有安全隐患；2、Cookie存储容量有限，存储时间有限。两个原因也可以理解成一个，因为正是Cookie的安全隐患，所以在设计上将其存储能力限制得很小，并且要设置过期时间，且允许用户主动删除。
Cookie的安全隐患和现实中便条的安全隐患是一样的。为了方便，便条总是贴在最显眼最容易让自己看到的地方，但自己方便看的同时，别人也方便看了，且因为能记录的地方太小，也记不了太多太复杂的事，又因为是临时粘在某个地方，时间一久也很容易脱落。这时商家如果想长期保存用户的喜好操作配置，为用户提供长期的定制化服务，Cookie显然不能升任了。
Cookie有安全隐患，记不了太多东西又记不久，干嘛不干脆禁止了，统一用账号密码机制？因为Cookie方便，且以最低的成本解决了http无状态的问题。Cookie的使用和发挥作用，对用户一方基本是透明无感知的，无任何使用成本，但是账号密码机制要求用户花时间精力填写注册表并提交，在提交成功后才有效，并且再次访问还有输入账号密码等待验证通过。相比Cookie繁琐很多。
简而言之，Cookie机制是便条，账号密码机制就是账本，便条可以记录一些简单的短期的信息，直接贴在最显眼的地方，有被偷窥的风险，但一般因为也不会记录太敏感的信息，且通常很快会被撕掉或自然脱落，所以虽然有风险基本无伤大雅。账本会记录非常详细的信息，且是长期的跟踪数据，但它一般是由专人保管，要保存在专门的档案室或档案柜中，所以安全系数高，同时它的使用成本也很高，拿出来，翻阅记录，放回都很麻烦。
Cookie机制和账号密码机制各有长短，二者的结合就可以取长补短，兼顾方便与安全。
最后，如何理解在Cookie中存账号密码的行为呢，也就是很多网站的“点击直接登录”功能？这就好比会计为了方便把档案柜的钥匙贴在工位的便条上，你说风险有多大，其实也不那么大，因为一般情况下会计的办公场所相对独立隔绝，进出人员有限且熟悉，但是如果严谨的考虑，无关人员有意无意造访会计办公场所，看到钥匙并偷拿的风险是确实存在的，所以谨慎的会计肯定会私下妥善保管档案柜的钥匙。Cookie也是一样，它在用户访问网站时被存在访问者的电脑中，上面就算记录了你网站的账号密码，但是一般谁能动你的个人电脑呢？不过如果严谨考虑，要是别人通过网络攻击，窃取Cookie怎么办？如果你是在别人电脑登录的网站怎么办？
这里采用了很多隐喻来帮助理解，但隐喻永远只能停留在感性认识上，感性认识就意味着肤浅与片面，有时甚至包含错误。要真正理解一个东西必须要上升到理性认识，但理性认识又不可能直接到达，必须经过感性认识的阶段，这就是这篇文章的意义吧。
