关于Cookie和Session补充点

一、Cookie

1、Cookie性能影响

   由于Cookie的实现机制，一旦服务器端向客户端发送了设置Cookie的意图，除非Cookie过期，否则客户端每次请求都会携带这些Cookie到服务器，一旦Cookie设置过多，将会导致报头较大。但其实大多数的Cookie并不需要带上，因为这将会造成部分带宽的浪费。在YSlow的性能优化当中有这么一条：

• 减小Cookie的大小
   比较严重的情况是，如果在域名的根结点设置Cookie，那么几乎该网站所有子路径下的请求都会带上这些Cookie，特别是静态文件最为典型，以至于造成资源的浪费。好在Cookie在设计时限定了它的域，只有域名相同时才会发送。所以YSlow中有另一种规则来避免Cookie带来的性能影响。
• 为静态组件使用不同的域名
   简而言之，为不需要Cookie的组件换个域名就可以实现减少无效cookie的传输。所以很多网站静态文件会有特别的域名，使得业务相关的Cookie不再影响静态文件。
   当然使用额外域名的好处不仅仅是这样，还可以突破浏览器下载线程数的限制，我们都知道现在主流浏览器的并发下载线程是六条，使用多一个域名那么将会多增加六条，这样算来，这样类推将会大大加快网站的加载速度。缺点就是，多一个域名的使用在每次访问的时候会多经历一次DNS解析的时间，但是我认为是完全值得的，并且现在基本主流网站也都在这样做。
• 减少DNS查询
   看起来减少DNS查询和使用不同域名是两条相互冲突的规则，但是好在现今的浏览器都会进行DNS缓存，以消弱这个副作用的影响。

二、Session

 通过Cookie，浏览器和服务器可以实现状态的记录。但是Cookie并不是完美的，其一是上文所说的体积过大，其二是Cookie在前后端都可以进行修改，因此数据就可以很容的被篡改和伪造。如果服务器有部分权限管理是根据Cookie上的isVIP字段来进行判断，那么如果一个用户将字段修改，那么就可以轻易的享受vip的服务。综上所述，Cookie对于敏感数据的保护并不有效。
为了解决这个问题Session应运而生。Session的数据储存在服务器端，客户端无法修改，这样数据的安全性得到一定的保障，数据也无需在协议当中多次传递。
 关于如何将每个客户和服务器中的数据一一相连，我们最常见的就是这样一种方式：

• 基于Cookie来实现用户和数据的映射
  虽然将所有数据放在Cookie中不可取，但是放一点无关紧要的东西还是可以的，保证它尽量小即可。因为即便Cookie当中的口令丢失，也无法修改服务器当中的数据，并且Session的有效时间通常较短，一旦过期服务端就将数据删除，因此安全性反而提升了。那么如何产生口令呢？其实每个语言都是有些不同的，但是大致缘由是一样的，上篇博客做了简单介绍，这里就不做叙述。

1、Session和内存

  在刚开始书写代码的时候我们可能会将Session数据直接储存在变量当中，因此它目前位于闪存当中。但是我们通过对内存的学习知道，这样会带来极大的隐患，如果用户过多将会极快的接触到内存的上线，内存中数据量增大，必然会引起GC垃圾回收的频繁扫描，从而引起性能问题。并且进程和进程之间是不能共享内存的。
 因此我们为了解决性能问题和Session数据无法跨进程共享的问题，常用的方案是将Session集中化，将原本可能分布在多个进程中的数据统一转移到集中的数据储存中，也就是数据库。目前常用的是Redis、Memcached等，通过这些高效的缓存，Node进程无需在内部维护数据对象，垃圾回收和内存限制的问题都可以迎刃而解，而且这些高速缓存设计的缓存过期策略更加的高效合理，比Node中自行设计缓存策略更好。
 采用第三方缓存来存储Session引起的一个问题是会引起网络访问的，理论上来说访问网络中的数据是要比访问本地磁盘中的数据更加的慢，因为涉及到握手、传输以及网络终端自身的磁盘I/O等，尽管如此但依然会采用这些高速缓存的理由有以下几条：

• Node与缓存服务保持长链接，而非频繁的短链接，握手导致的延迟只影响初始化。
• 高速缓存直接在内存中进行数据储存和访问
• 缓存服务通常和Node进程运行在相同的机器上，网络速度受到的影响较小。

2、Session与安全

 前面已经说过了，尽管我们的Session数据保存在后端可以保障一定的安全，但是还是有很多大佬可以破解Cookie当中存储的值，从而获取到Session当中的私密信息，这里主要讲的安全是让Cookie这个口令更加的安全。
 一种做法是将Cookie通过私钥加密进行签名，使得伪造的额成本较高。客户端尽管可以伪造口令值，但是由于不知道私钥值，签名信息很难伪造。因此我们只要在响应市将口令和签名进行对比，如果签名非法，我们将服务器端的数据立即过期即可。
 当然，将口令进行签名是一个不错的方案，但是如果攻击者通过某种方式获取了一个真实的口令和签名，他就能实现身份的伪装。第二种方案是将客户端的某些独有信息与口令作为原值，然后签名，这样攻击者一旦不再原始的客户端上进行访问，就会导致签名失败。这些独有信息包括用户IP和用户代理（User Agent）。
 但是原始用户与攻击者之间也存在上述信息相同的可能性，如局域网出口IP是相同的，相同的客户端信息等，纳入这些考虑能够提高安全性。通常而言，将口令存在Cookie当中不易被他人获取，但是一些别的漏洞可能导致这个口令被泄漏，典型的比如XSS漏洞。
 其实说白了，互联网时代，人人都是光屁股，你就尽量别惹到真大佬吧，在互联网上还没有什么防御系统是完全完美的，即便现在破解不了也不代表以后某天破解不了