2015/5/1 （一）session和cookie

        如今越学下去，便越以为基础非常重要，对于底层的东西更是须要弄懂。

        SESSION和COOKIE     

        这两个东西通常是用来标识客户端身份的固然也可用来存储全局变量。

         先说说session,照个人理解，它是从服务器端产生的内存标记。就是脚本启动session后，经过浏览器发出请求，此时，服务器端便会自动生成一个独有的session id,便经过响应，以Set-Cookie:PHPSESSID=********,的形式传回到浏览器，其后，每一次浏览器的请求中，都会在请求头中以  Cookie: PHPSESSID=*******,格式发送到服务器，而后服务端会根据客户端传送的PHPSESSID与自身存在的PHPSESSID进行匹配，从而获取与该ID相对应的信息。这就是一个会话机制的工做流程。

        session有多种存储方式，能够存放在内存、数据库、或是文件中，固然，存放到数据库和文件实际上都是存放到硬盘里，可是，获取硬盘信息是经过I/O，O操做的效率是远远低于操做内存的数据，因此这个能够次级考虑。而内存的读取速度是远高于硬盘的，因此能够优先考虑，其实现方式能够经过，redis或memcached来解决。

        而cookie，以前个人不求甚解，对其想法就仅仅停留在cookie是保存在浏览器的这么一个说法。如今看来，cookie和session是一个依赖的关系，这个能够从上面的会话机制的工做流程能够看出来。因为cookie是由浏览器来进行管理的（并非由编程语言直接操做，而是经过浏览器），因此一旦浏览器禁用cookie，那么session就不能正常工做了。在此，有两个解决方案：

    一、URL重写，便是把PHPSESSID经过url传输到服务端，这个有安全隐患问题，应加密处理发送。

    二、经过表单隐藏发送，这个天然也是有必定的操做难度，不怎么建议使用。

    不管是session和cookie，都是因为http无状态的产物，下面摘自于网咯的一些说法；

‍‍HTTP的无状态是由其历史使命而决定的。但随着网络技术的蓬勃发展，人们不再知足于死板乏味的静态HTML，他们但愿web应用能动起来，因而客户端出现了脚本和DOM技术，HTML里增长了表单，而服务端出现了CGI等等动态技术。

‍‍而正是这种web动态化的需求，给HTTP协议提出了一个难题：一个无状态的协议怎样才能关联两次连续的请求呢？也就是说无状态的协议怎样才能知足有状态的需求呢？‍‍

此时有状态是必然趋势而协议的无状态性也是木已成舟，所以咱们须要一些方案来解决这个矛盾，来保持HTTP链接状态，因而出现了cookie和session。

‍‍对于此部份内容，读者或许会有一些疑问，笔者在此先谈两点：

‍‍1.   无状态性和长链接‍‍‍‍

可能有人会问，如今被普遍使用的HTTP1.1默认使用长链接，它仍是无状态的吗？

‍‍链接方式和有无状态是彻底没有关系的两回事。由于状态从某种意义上来说就是数据，而链接方式只是决定了数据的传输方式，而不能决定数据。长链接是随着计算机性能的提升和网络环境的改善所采起的一种合理的性能上的优化，通常状况下，web服务器会对长链接的数量进行限制，以避免资源的过分消耗。‍‍

2.   无状态性和session‍‍‍‍

‍‍        Session是有状态的，而HTTP协议是无状态的，两者是否矛盾呢？‍‍

    Session和HTTP协议属于不一样层面的事物，后者属于ISO七层模型的最高层应用层，前者不属于后者，前者是具体的动态页面技术来实现的，但同时它又是基于后者的。在下文中笔者会分析Servlet/Jsp技术中的session机制，这会使你对此有更深入的理解；‍‍‍‍

‍‍ ‍‍   ‍‍‍‍上‍‍面提到解决HTTP协议自身无状态的方式有cookie和session。两者都能记录状态，前者是将状态数据保存在客户端，后者则保存在服务端。‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

        SESSION在php.ini配置的一些说明：（来自网络）

[服务端]

session.save_handler = files
默认为file，定义session在服务端的保存方式，file意为把sesion保存到一个临时文件里，若是咱们想自定义别的方式保存（好比用数据库），则须要把该项设置为user；

session.save_path = "D:/APMServ5.2.0/PHP/sessiondata/"
定义服务端存储session的临时文件的位置。

session.auto_start = 0
如置1，则不用在每一个文件里写session_start(); session自动start ：）

session.gc_probability = 1
session.gc_divisor    = 100
session.gc_maxlifetime = 1440
这三个配置组合构建服务端session的垃圾回收机制
session.gc_probability与session.gc_divisor构成执行session清理的几率，理论上的解释为服务端按期有必定的几率调用gc函数来对session进行清理，清理的几率为：gc_probability/gc_divisor 好比：1/100  表示每个新会话初始化时，有1%的几率会启动垃圾回收程序，清理的标准为session.gc_maxlifetime定义的时间。

[客户端]

session.use_cookies = 1
sessionid在客户端采用的存储方式，置1表明使用cookie记录客户端的sessionid，同时，$_COOKIE变量里才会有$_COOKIE[‘PHPSESSIONID’]这个元素存在；

session.use_only_cookies = 1
也是定义sessionid在客户端采用的存储方式，置1表明仅仅使用 cookie 来存放会话 ID。通常来讲，如今客户端都会支持cookie，因此建议设置成1，这样能够防止有关经过 URL 传递会话 ID 的攻击。

session.use_trans_sid = 0
相对应于上面那个设置，这里若是置1，则表明容许sessionid经过url参数传递，同理，建议设置成0；

session.referer_check =  
这个设置在session.use_trans_sid = 1的时候才会生效，目的是检查HTTP头中的"Referer"以判断包含于URL中的会话id是否有效，HTTP_REFERER必须包含这个参数指定的字符串，不然URL中的会话id将被视为无效。因此通常默认为空，即不检查。  

session.name = PHPSESSID
定义sessionid的名称，即变量名，因此经过浏览器http工具看到的http头文件里的PHPSESSID=##############；

session.hash_function = 0
选择session_name的加密方式，0表明md5加密，1表明sha1加密，默认是0，可是听说用sha1方式加密，安全性更高；

session.hash_bits_per_character = 4
指定在session_name字符串中的每一个字符内保存多少位二进制数，这些二进制数是hash函数的运算结果。
4   bits:   0-9,   a-f  
5   bits:   0-9,   a-v  
6   bits:   0-9,   a-z,   A-Z,   "-",   "," 

url_rewriter.tags = "a=href,area=href,frame=src,input=src,form=,fieldset="
指定重写哪些HTML标签来包含sid(session_id)（仅在"session.use_trans_sid"打开的状况下有效），URL重写器将添加一个隐藏的"<input>"，它包含了本应当额外追加到URL上的信息。  

session.cookie_lifetime = 0
保存sessionid的cookie文件的生命周期，如置0，表明会话结束，则sessionid就自动消失，常见的强行关闭浏览器，就会丢失上一次的sessionid；

session.cookie_path = /
保存sessionid的cookie文件在客户端的位置；

session.cookie_domain = /
保存sessionid的cookie的域名设置，这跟cookie容许的域名的访问权限设置有关，通常来讲想让本身网站全部的目录都能访问到客户端的cookie，就应该设置成“/”如须要详细了解，能够看下setcookie()函数的domain参数相关设置和使用方法；

session.bug_compat_42 = 1
session.bug_compat_warn = 1
这两个能够说几乎是快要被废弃的设置，是为了老版本的php服务的，主要是针对 session_register函数，由于php5的register_global默认是关闭状态，因此在php5里根本用不到 session_register这个函数；而且php6就要废除这个设置，直接定义为关闭，因此不必研究这两个了；