cookie默认有效期多长_HTTP会话（COOKIE、SESSION）

1、HTTP

HTTP协议是什么，不多说，百度都能找到一堆，其经典的过程如下（摘抄自百度百科）：

• 客户端与服务端建立连接（TCP）
• 客户端向服务端发起请求
• 服务端接受请求，并根据请求参数返回响应内容
• 客户端与服务端关闭连接

即使你一次请求多次，其中的每个请求也基本是这个过程。

在HTTP1.1中提供了KEEP-ALIVE来实现一次连接，多次请求并响应，但是时间上这个多次请求是串行的

在HTTP2中提供了多路复用，引入二进制数据帧和流的概念，可以实现多个请求并行执行，并且请求方会按照帧的数据标识对收到的响应内容进行合并，避免数据错乱，更多信息可以自行查阅相关资料。

HTTP是无状态协议，这里的无状态是指HTTP服务端并不保留与客户交互时的任何状态（常指多个请求之间）。不过我们仍然能在网络上冲浪的时候，很愉快的一直处于登录状态，是因为很多WEB应用都基于HTTP COOKIES或者隐藏变量（比如APP的请求TOKEN，或动态，或周期内静态）实现了服务端SERVER SIDE SESSION。

2、COOKIE

HTTP Cookie（也叫Web Cookie或浏览器Cookie）是服务器发送到用户浏览器并保存在本地的一小块数据，它会在浏览器下次向同一服务器再发起请求时被携带并发送到服务器上。通常，它用于告知服务端两个请求是否来自同一浏览器，如保持用户的登录状态。Cookie使基于无状态的HTTP协议记录稳定的状态信息成为了可能。

加入你此刻正使用Chrome浏览器访问知乎，按F12，点击network，任点一个左侧HTML类型的请求，然后在右边的Headers tab里，你可以看到Response Headers中有一栏

 set-cookie: KLBRSID=xxxxxxxxxxxxxxxxxxxxx|1587804082|1587799676; Path=/

你也可以看到Request Headers里有一栏，可能会很长

 cookie: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

你可以在Cookies tab里，直接查看有哪些COOKIE值，你也可以等看完文章后清除COOKIE然后刷新页面试试。

COOKIE主要的属性有：name，value，domain，path，expires，max-age，secure，HttpOnly，意如其名。

如果你的COOKIE暴露了，被别人拿到了会如何？

3、SESSION

本意是会话控制，指服务端用于存储当前用户会话数据的一整套完整机制。要么基于COOKIE，要么基于特殊的隐藏变量，工作原理大致如下：

• 客户端请求服务端
• 服务端开启会话，并下发一个特殊的COOKIE（会话的唯一标识符），服务端将会话数据存储在指定位置
• 客户端收到服务端响应内容，并且保存这个COOKIE
• 客户端在下一次请求服务端时带上这个COOKIE，服务端根据这个唯一标识符读取相关会话数据，恢复会话的状态

3.1、SESSION创建（php为例）

服务端总是要以

 <?php
 session_start();
 $session = $_SESSION;

来开启一个会话（当然，你也可以在php.ini中配置自动开启会话），如下所示，此时服务端的响应中会下发一个cookie，name为PHPSESSID，value为26个小写16进制字符组成的字符串

 session.auto_start = 1

当然你也可以基于自己的规则来生成这个PHPSESSID，然后在启用session前指定PHPSESSID

 <?php
 session_id(get_session_id_by_your_rule());
 session_start();
 // your code

3.2、SESSION数据的存储（php为例）

PHP中session数据的默认存储位置为系统的临时目录，你也可以通过session_set_save_handler来设置会话数据的存储位置。

 <?php
 class RedisSessionHandler
 {
     public function open(){}
     public function close(){}
     public function read(){}
     public function write(){}
     public function destory(){}
     public function gc(){}
 }
 $handler = new RedisSessionHandler();
 session_set_save_handler(
     [$handler, 'open'],
     [$handler, 'close'],
     [$handler, 'read'],
     [$handler, 'write'],
     [$handler, 'destory'],
     [$handler, 'gc']
 );

关于上述行为更准确的定义，如果是PHP开发者可以自行查看最新版手册

3.3、SESSION销毁（php为例）

既然SESSION是存储在服务端的，如何清除呢？有人说浏览器关闭了就清除了，其实完全不准确，浏览器关闭也只是可能删除原本存储于浏览器端上的COOKIE（也只是可能，因为COOKIE的有效期可能会设置得很长）。服务端并不知道浏览器端发生的任何事情，所以，服务端清除SESSION数据，总是基于过期时间来处理的，比如PHP就有session数据的gc机制，这个机制发生的概率有php.ini的配置决定

 session.gc_probability = 1
 session.gc_divisor = 1000

如上默认值代表着请求有1/1000的概率触发SESSION过期数据的清除动作，对于像 RedisSessionHandler 这种存储于KV NoSQL中的会话数据，在存储的时候会设置有效期，当有更新的时候会自动刷新有效期，自然也就无需GC的清除了。

4、基于COOKIE、SESSION能做什么？

有了COOKIE，我们能存储SESSION在浏览器端的唯一标识，能存储其他各种不敏感的数据。

有了SESSION，我们能对同一个用户的连续访问行为进行识别，用户可以避免重复登录的烦恼，比如你在PC上登录天猫，就能很欢乐的连续买买买，而不用买一件登录一次。

5、分布式怎么处理（php为例）

前面说了，PHP默认的SESSION数据存储在服务器所在的临时文件目录中，但是如果这是一个繁忙的站点，不仅仅一个服务器在对外提供服务，而是多台机器在对外提供服务，这个时候怎么保证会话的连续性呢？如下例子：

• 浏览器端发起登录请求，服务器A接受并处理登录请求，返回PHPSESSID
• 浏览器收到PHPSESSID，发起个人中心的请求，并带上PHPSESSID，但是这个请求由服务器B接受并处理，此时服务器B并不认识这个服务器A颁发的PHPSESSID，所以重新生成了一个新的PHPSESSID，并要求客户重新登录

这不就把用户吓跑了吗，当然，你也可以说，我这两台服务器的SESSION文件目录相互async可不可以？可以，不过代价有点大。这个时候可以通过session_set_save_handler保存在一个服务器A、B均能访问的存储介质中，比如Redis中。具体过程不表。

6、XSS（Cross Site Scripting）跨站脚本攻击（为什么不叫CSS?应该很好理解）

最常见的XSS就是盗取COOKIE，并以此窃取敏感信息，常见于未对用户输入进行合法转移的服务端程序而言，简单的原型，假设有一个网站的某个程序存在未对javascript进行合理转义的行为：

 <?php
 $description = $_GET['description'];
 echo $description;

这个时候如果请求 "http://xxxx.com/demo.php?description=this is a product"，一切都很健康。可是如果时候这个是访问 "http://xxxx.com/demo.php?description=<script>some evil code to steal cookies</script>"，就能轻轻松松的把本地的COOKIE数据发送到第三方服务器上了，你的信息也就泄露了。如果存在这种漏洞的网站没有及时修复，并且在被某些人使用并造成广泛传播的话，后果也就很严重。

对输入进行有效检查或转义，或者对用户的输入进行输出时增加转义，都能轻松避免此类漏洞。

7、重新审视凭证

不管COOKIE还是SESSION，其本质只是为了实现一种凭证，有了这个凭证，服务端便能知道是谁在发起当前的这个请求，以便进行相关的业务处理，知道了这个原理之后，浏览器不支持COOKIE又如何？服务端不支持SESSION又如何？不是可以轻轻松松的构建一个会话机制吗？其通用过程如下：

• 浏览器端发起登录请求
• 服务端收到登录请求，并进行登录处理，登录成功后，将相关的数据存储到一个指定地方（文件也好，REDIS也好，MySQL也行），没人拦你，在存储数据的时候会有一个唯一的KEY
• 服务端将KEY通过响应返回给客户端，是放在response body里呢，还是response headers里呢，随意
• 客户端收到这个KEY之后，保存起来，下一次请求的时候带上，服务端便知道是谁了。

可是每次请求都发送这个KEY，是不是很不安全啊，万一数据被监听导致KEY泄漏怎么办？

上HTTPS呀，

什么没办法上HTTPS？

那就上动态签名呀？ 这也是很多API与其他API，APP与服务端进行交互的鉴权机制。

由此还衍生出OAUTH，JWT等各种签名的机制，其实本质上都是“凭证”，无非都是在证明谁是谁，如何证明谁是谁，谁帮谁证明谁是谁，以及这个证明的有效期问题。

完。