从效率考虑：cookie > memcache > 数据库
cookie对服务器端负载没影响，如果加密、解密会多消耗一点点cpu。带宽倒是会消耗得多一点，同域名下的所有http request header都会附带cookie，所以在大流量下，把js、css、图片放到另外一个域名下会节约掉这部分流量。memcache会占用一些服务器内存数据库连接本来就是典型的瓶颈，能免则免
从安全性考虑：memcache/数据库 > cookie
cookie存放在客户端，需要考虑的安全性比较多一点memcache、数据库都在服务器端，相对cookie来说会稍微安全点从服务器可扩展性考虑：cookie > memcache/数据库
如果有多台后端服务器，就需要共享session数据memcache、数据库都可以做到在多台服务器之间共享session，但是容易形成单点瓶颈，大负载下需要考虑存储路由之类cookie完全不需要在服务器端共享session数据，与REST无状态风格暗合，REST无状态风格见下面。可扩展性这个点也不是绝对，如果用nginx的ip_hash方式组织多个后端upstream就不需要共享session，但这些都需要后端架构上的考虑和设计，而cookie则完全没有这方面的扩展性问题增补：cookie其实也不是在扩展性上没有任何问题需要考虑，说“完全没有”有点绝对了，可扩展性这种事情，复杂度比较高，需要实际问题实际分析。在比较简单理想的情况下，cookie的可扩展性会比较好点。 为什么在请求中传递SessionID被普遍认为是unRESTful的，而将用户的credentials包含在每个请求里又是一种非常RESTful的做法无状态指的是任意一个Web请求必须完全与其他请求隔离，当请求端提出请求时，请求本身包含了相应端为相应这一请求所需的全部信息。REST无状态风格RESTful架构对于state的两个不同的解释: 应用状态(Application State)和资源状态(Resource State)。应用状态：指的是与某一特定请求相关的状态信息资源状态：则反映了某一存储在服务器端资源在某一时刻的特定状态，该状态不会因为用户请求而改变，任何用户在同一时刻对该资源的请求都会获得这一状态的表现（Representation）。RESTful架构要求服务器端不保有任何与特定HTTP请求相关的资源，所以应用状态必须由请求方在请求过程中提供。在Session ID可以被认为是一个用来标识某一会话状态的Key，将其传递给服务器端意味着这样一个请求：“请帮我取出这个状态信息”，也就是说这个请求假设响应方保有着状态信息。由于与某一特定请求相关的状态属于应用状态，而RESTful架构要求任何此类状态由请求方负责提供，所以传递Session ID被认为是unRESTful的做法。反过来，user credential作为一种应用状态，是被期望由请求方提供的，所以在请求中传递user credentials（姑且忽略安全性问题）是符合RESTful架构规范的 nginx的ip_hash方式：每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的共享问题。 对于cookie保存验证码，仍旧不能杜绝机器的攻击，机器可以通过将通过种cookie的方式，然后在请求中发送对应的验证码来访问，这样服务的对验证码的判断，一直都是正确的。可能有一种办法是验证码拼上时间戳的方式，再加密来种到cookie中，可是就算有了时间戳，也不能避免在你时间戳有效的范围内的攻击。session的文件保存
session机制，在服务端session_start()之后，就会在响应头里面发送一个Set-Cookie字段，下次请求时，cookie中就会带上PHPSESSID，然后服务端根据PHPSESSID找到对应的保存session的文件。所以涉及到session的有效期就分为客户端和服务器端。客户端session.cookie_lifetime=0时，关闭浏览器session就会失效服务器端session.gc_maxlifetime//session的有效期session.gc_probabilitysession.gc_divisorsession.gc_divisor 与 session.gc_probability 合起来定义了在每个会话初始化时启动 gc（garbage collection 垃圾回收）进程的概率。此概率用 gc_probability/gc_divisor 计算得来。例如 1/100 意味着在每个请求中有 1% 的概率启动 gc 进程。当gc_probability/gc_divisor=1的时候意味着，每次请求来调用session_start()都会执行一次垃圾回收机制，将磁盘过期的session文件删除。亲试。如果单独修改了gc_maxlifetime，即使session已经失效，但是如果没有触发垃圾回收机制，当请求再次过来时，session还是可以使用的。所以session做的登录，就可能会由于客户端保留了PHPSESSID导致过了几天再次访问还是登录状态