标签归档：session

WEB 会话管理杂谈

1 前言

某一天，有同事在产品问题反馈大群里扔出一个问题：登录后隔两天再打开页面就需要重新登录。在查问题的过程中，我们有提到 7 天过期，老板对此也扔出了一个问题：为什么是 7 天。于是有了今天这篇文章。首先我们先看一下 WEB 会话管理的概念。

2 概念

在说 WEB 会话管理之前，我们需要先说一下 HTTP 协议。这里我们暂且不提 HTTP2.0 和 HTTP3.0，本文的 HTTP 协议主要是指现在使用最广泛，使用历史最久的 HTTP1.x 版本。

HTTP 协议是一个无连接无状态的协议。

无连接是指限制每次连接只处理一个请求，服务端处理完客户端的请求，并收到客户端的应答后，即断开连接。后面协议中增加了 Keep-Alive，这个特性使得客户端到服务器端的连接持续有效，当出现对服务端的后继请求时，Keep-Alive 功能避免了建立或者重新建立连接。
无状态是指在协议层面对于事务处理没有记忆能力，服务端不知道客户端是什么状态。当我们给服务器发送 HTTP 请求之后，服务端根据请求内容给我们返回数据，但是返回数据后，服务端不会记录任何信息。

在互联网早期，这样的协议完全能满足 WEB 应用的需要，但随着 WEB 应用复杂度的提升，识别用户是谁，记录用户的行为，有用户状态变成了刚性需求，或者说是核心功能点。此时，会话管理应运而生，会话管理是一种控制和维持用户交互状态的机制，它定义了一系列用于管理用户和 WEB 应用系统交互状态的措施。

会话管理有两个关键点，一个是怎样存储，另一个是存储什么。

3 存储方式

3.1 服务端 session

在早期的有会话管理的 WEB 应用中，会话经常存储在服务端的 session 中，常见的 WEB 编程语言都自带 session 的处理逻辑，如 PHP 和 Java 都默认带有 session 的扩展或组件，如 PHP 中的全局变量 $_SESSION。客户端存储 sessionid，通过 cookie / 隐藏的表单字段 / 重写 URL 的方式传递 sessionid，后两种方式一般在禁用 cookie 的时候启用。

服务端 seesion 的优势

安全性好，客户端与服务端保持会话状态的媒介始终只是一个 sessionid 串，我们一般会保证这个串的随机性，以防止攻击者遍历或穷举；除非通过 CSRF 或 HTTP 劫持等方式，才有可能冒充别人进行操作。最坏的情况就算是冒充成功，在服务端我们也会有一些登录凭证的验证来进行纵深的防御；
可控度高，在服务端集中存储，后台同学可以对其进行操作，比如踢下线之类的操作。

针对服务端的存储方式，就会出现了我们在前言中提到的过期问题，为什么要有过期？

为了节省服务器资源，登录态相关信息存储在服务器还是需要一定资源的，如果一直不过期，几千万上亿的用户登录态数据将是较大的一个成本，而这个成本是完全可以省下来的；
为了安全，用户长时间未操作，如果有人用了他的账号干了点别的，这样就存在较大的风险；另外在业务逻辑上可以实现抢登等逻辑以规避一些安全上的风险。

有了过期，就会有过期时间，常见的过期时间有 1 小时（ 3600 秒），2 小时( 7200 秒)，1 天， 7 天（一周），15 天，30 天（一个月）。这个过期时间更多的是经验值，或者说是一个大家认为合适的值。这个值对业务的影响，貌似没有一个客观的评价。

服务端的 seesion 的常见存储方案如下：

单机方案，存储要么是硬盘，要么是内存，二者的区别在于获取和写入的速度，对于海量的互联网应用来说，存储到内存方案更常见一些。单机存储方案是有一定上限的，其上限是单机存储的上限。
分布式方案，分布式的内存数据库如 Redis / Memecached，Tomcat 等都有现成的共享 session 方案。分布式存储方案从理论上来讲是没有存储上限的，可以给 Redis 做分布式部署。

考虑到服务器的负担和架构的复杂性，依赖于浏览器每次请求都会带上 cookie 的特性，我们可以把用户的登录凭证直接存到客户端（浏览器）中。当用户登录成功之后，把登录凭证写到 cookie 里面，并给 cookie 设置有效期，后续请求直接验证存有登录凭证的 cookie 是否存在以及凭证是否有效，即可判断用户的登录状态。当年 Rails 的默认会话存储方案是用 cookie 方案。

优点

实现了服务端的无状态化，彻底移除了服务端对会话管理的逻辑，服务端只负责创建和验证登录 cookie 即可；
不同应用间的登录态可以通过算法或密钥的一致性来保持，以实现会话共享。

缺点

cookie 有大小限制，存储不了太多数据，同时会话会占用其它业务场景的空间，从而导致 cookie 空间紧张；
cookie 在每次请求时都会带上，当会话中有较多的冗余数据时，会对性能有一些影响，并且产生一些不必要的网络带宽；
多应用时可能会有跨域问题，浏览器在发起请求时会检查所有存储的 cookie ，如果某个 cookie 所声明的作用范围大于等于将要请求的资源所在的位置，则会把该 cookie 附在请求资源的 HTTP 请求头上发送给服务器。当作用范围小了，或者交错了，则会出现跨域问题。

3.3 令牌方案

相对于前面两种方案，令牌方案是前后端分离后的常见方案，session 的概念在这个方案里面更淡一些。

在讲令牌方案之前我们先讲一下安全上两个非常重要的点：认证和授权。有时候会把这两个东西弄混，其定义如下：

认证是这样一种验证过程：通过让用户、网站、应用程序通过提供合法证书或验证方式，以证明他们符合自己所宣称的身份。
授权是指的是一个验证某用户能访问什么的过程。在授权过程中，某用户 / 应用程序的权限级别被确定后，才被允许访问特定的 APIs / 模块。通常，授权发生在用户身份被认证之后。

区别	认证	授权
作用	确定用户所宣称的身份	确定用户可访问的权限
方式	通过合法凭证校验用户	通过规则和策略校验访问
时机	早于授权	在认证成功后执行
实现	通过 ID tokens 实现	用 Access Tokens 实现

基于令牌的认证和授权是现在最流行的的一种技术，当用户在某处输入一次其用户名和密码后，作为交换会得到一个唯一生成的已加密令牌。该令牌随后会替代登陆凭证，用以访问受保护的页面或资源。当我们要进行下一步的业务操作，会通过令牌获取到用户的的信息和会话的信息，此时一般是通过进程内的缓存或者某个特定的微服务来获取，这些微服务的后端的存储因公司技术架构和服务而异。一般来说，对于海量的互联网应用来说，这里最终还是从内存中获取的数据，如前面说到的分布式 NoSQL 数据库。

一个令牌就是服务器生成的一段数据，包含了唯一性识别一个用户的信息，一般被生成为一长串随机字符和数字。

比如看起来可能像这样：bb74324734bcf34748bb08bu2842f3288 或更复杂些比如： eyJ0eXAiOiJqd3QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJ1bXMiLCJzdWIiOjY1NDA1NjI5NCwiYXVkIjoiZ2FvZGluZ3giLCJleHAiOjE2NDE5MDgzOTZ9.8MZaB55vlScSDZxBmO-N9ol9UTvYPVvgUFab7dFe6fY 这个令牌本身是无意义和无用的，但结合适当的令牌系统，就会变成保证应用安全性的重要一环。

基于令牌的实现过程一般如下：

用户通过用户名和密码（或者其它登录方式，如国内的微信扫码）请求访问；
应用验证登录凭证；
应用向客户端发放已签名的令牌；
客户端存储令牌，并将其附加在其后的每次请求中一同发送（一般是带在 cookie 中，和 sessionid 类似）；
服务器验证令牌并响应数据。

我们常用的基于令牌的方案有两个:

OAuth 2.0 (RFC 6749 and RFC 6750).
JWT (RFC 7519).

关于这两个方案的更详细的说明见：深入 OAuth2.0 和 JWT

在令牌的生命周期中存在两个较大的安全薄弱环节：

会话令牌生成过程中的薄弱环节，令牌的生成依赖于用户通过用户名/邮箱或密码生成，这里存在较大的泄漏风险；
所有处理会话令牌的薄弱环节，如传输过程中（没有加密的链路或被劫持等），日志记录中等。

4 存储内容

会话从本质上来讲是一种缓存，一种强关联用户的缓存，所以与用户相关的一些常用数据可以放在会话里面，如头像、用户名、真实姓名、积分等等。这些缓存数据都只读，当要更新时还是需要从数据库中获取后再次更新写入，而不是依赖于会话的数据。

除了常用数据我们经常还会把购物车或者菜单、权限等写入会话中，此时除了用户属性，还带上了业务属性，我们可以称之为业务会话。业务会话一般是指某个业务场景中需要临时缓存起来的数据，而且这部分数据大多数是要落库的，当用户会话过期重新登录后这部分数据还是要从数据库重新获取，加载到会话中。

5 小结

最后这个问题的原因是业务逻辑里面针对不同的渠道有抢登的业务逻辑，而这个逻辑在某个时候是不需要触发的。此外，老板最后在群里问了一个触及灵魂的问题：

我们做一件事情的时候是依着惯性做事，还是基于深度思考后的决策？

自我反省中~~

这篇文章墨迹了几周，一直不知道如何写好，总觉得写得有点不如人意，如果往协议本身来写，好像也没有想写的，就这样吧。

6 参考资料

https://juejin.cn/post/6844904000811171847
https://www.cnblogs.com/lyzg/p/6067766.HTML
https://blog.csdn.net/tennysonsky/article/details/44562435

除了眼前的苟且,还有架构与远方。

介绍创业路上的技术选型和架构、大型网站架构、高性能高可用可扩展架构实现，技术管理等相关话题，紧跟业界主流步伐。

关于Cookie

发表回复

Cookie是什么

在wiki中Cookie的定义为: Cookie（复数形态Cookies），中文名称为小型文本文件或小甜饼（貌似这只是一个中文翻译，平时还是直接读的英文），指某些网站为了辨别用户身份而储存在用户本地终端上的数据。

Cookie是服务器在本地机器上存储的小段文本并随每一个请求发送至同一个服务器，是客户端与服务器保持会话的主要手段，其内容总是保存在客户端中，按在客户端中的存储位置，可分为内存Cookie和硬盘Cookie。内存Cookie由浏览器维护，保存在内存中，浏览器关闭后就消失了，其存在时间是短暂的。硬盘Cookie保存在硬盘里，有一个过期时间，除非用户手工清理或到了过期时间，硬盘Cookie不会被删除，其存在时间是长期的。所以，按存在时间，可分为非持久Cookie和持久Cookie。

Cookie被浏览器默认发送到服务器，通过HTTP协议，请求头中以Cookie字段存储客户端的Cookie值，应答头中以Set-Cookie字段应答，当服务器需要有多个cookie字段写到客户端，则在应答头中将包含多个Set-Cookie字段。 Cookie的使用非常简单，以PHP为例，在脚本中使用setcookie函数设置对应的key,value值，通过全局变量$_COOKIE直接读取客户端发送过来的Cookie值。

Cookie简单，但是存在一些问题:

安全，明文传输内容，容易被篡改。和HTTP一样，只能说看如何使用了，看你存储的是什么了
增加网络流量，加重整个网络的负载。默认浏览器在发送请求时会将本地Cookie的内容通过Cookie字段传输到服务器。所以经常我们会独立静态图片或资源的域名，使其Cookie为空。
大小限制。各浏览器对于单个cookie的大小限制为4096个字节左右，超过大小的内容将被忽略。每个域名下可以存储有30~50个cookie，不同的浏览器，不同的版本这些值不同。为什么会有大小限制，因为cookie会默认发送，当cookie太大时，可能会导致服务器响应出错等。

Cookie的历史

1993年3月，这样一个春光明媚，面朝大海，春暖花开的时节，现在的网景公司前雇员，当时的NB的网景公司员工Lou Montulli灵光一闪，Cookie华丽丽的出生了。 Cookie第一次被正式定义是在RFC2109，嗯，这是1997年2月的一天，也许那时还有些冷。在RFC中，Cookie被称为HTTP State Management Mechanism（HTTP 状态管理机制）。 RFC2109在2000年10月被RFC2965过时，而在2011年4月，最新的刚刚火热出炉的RFC6265将RFC2965过时，可谓是长江后浪推前浪，前浪死在沙滩上。另外，RFC2964记录了使用Cookie的最佳实践。

换句话说:Cookie经过了Netscape标准、RFC2109、RFC2965和RFC26265四个标准：

Netscape标准：Netscape是最原始的Cookies规范，同时也是RFC2109的基础。尽管如此，还是在很多重要的方面与RFC2109不同，可能需要特定服务器才可以兼容。
RFC2109： RFC2109是W3C组织第一次推出的官方Cookies标准。理论上，所有使用版本Cookies的服务端都应该使用此标准。HttpClient已经将此标准设定为默认。遗憾的是，许多服务端不正确的实现了标准或者仍然使用Netscape标准。所有有时感到此标准太多于严格。
RFC2965：RFC2965定义了版本2并且尝试去弥补在版本1中Cookie的RFC2109标准的缺点。RFC2965是，并规定RFC2965最终取代RFC2109. 发送RFC2965标准Cookies的服务端，将会使用Set-Cookie2 header添加到Set-Cookie Header信心中，RFC2965 Cookies是区分端口的。
RFC6265：RFC6265主要是干掉了RFC2965，在9.3和9.4小节。另外，增加了HttpOnly字段，指定HttpOnly的Cookie不能被客户端读写，仅供HTTP传输使用，或者就服务器可以读写，浏览器作为客户端需要确保其不能读写。

Cookie和Seesion

Cookie和Session都用来保存状态信息，做会话处理，都是保存客户端状态的机制，它们都是为了解决HTTP无状态的问题而所做的努力。 Session存储在服务器，一般通过Cookie来存储其生成的唯一ID（seesionID），当Cookie被禁用时，通常用URL回写的机制来替换Cookie。

Cookie和Session有一些不同：

存储位置的不同：Cookie将状态保存在客户端，Session将状态保存在服务器端；
与HTTP协议的关系不同：Cookie需要通过网络传输，依赖于HTTP协议，Session并没有在HTTP的协议中定义；
可用性不同：相对于Cookie，Session在客户端禁用Cookie后还可以通过URL回写机制实现Session会话机制。
安全性不同：因为存储的位置不同，Cookie更容易被篡改，存储在服务器的Session相对来说则安全一些，客户不能随意读取这些内容，除非获到其它用户的了sessionID，这也是XSS攻击会关注的地方。

同源策略

说到WEB的安全问题就不得不提同源策略。浏览器的同源策略是 Web 安全的基础，所有的主流浏览器都会有相应的实现。同源策略中“源”是一个包含主机名、协议和端口号的三元组，则同源表示：同协议，同域名和同端口，三者都相同。同源策略的出发点是它认为自任何站点装载的信赖内容是不安全的。在同源策略的限制下，浏览器只允许网页中的脚本（如 JavaScript 或 VBScript）访问与之同源的 HTTP 请求和 Cookie。对于Cookie来说，同源策略就限制了网站间的Cookie读写操作。即使在服务器使用setcookie（PHP）函数对其它域名执行Cookie写操作也是无效的。 setcookie的域名是用来指向当前域名或根域名之类的用的,设置Cookie时，如果不指定domain的值，默认就是本域。

参考资料：

http://wiki.apache.org/HttpComponents/ReferenceMaterials
http://www.cnblogs.com/shepherd2012/archive/2012/08/03/2621797.html
http://zh.wikipedia.org/wiki/Cookie
http://curl.haxx.se/rfc/cookie_spec.html
http://tools.ietf.org/html/rfc6265

PHP源码阅读笔记三十七：PHP中的SESSION实现

1条回复

PHP源码阅读笔记三十七：PHP中的SESSION实现
源码版本：php5.3.1
环境:VS2008
本文包括PHP中SESSION用到的COOKIE管理，缓存限制，序列化
【COOKIE管理】
在浏览器未关闭cookie的情况下，我们可以看到当有session id生成并返回给发送请求的客户端时，会有一些cookie信息写入到浏览器。其实现代码在session.c 1191行开始。

/* *********************
   * Cookie Management *
   ********************* */
 
#define COOKIE_SET_COOKIE "Set-Cookie: "
#define COOKIE_EXPIRES	"; expires="
#define COOKIE_PATH	"; path="
#define COOKIE_DOMAIN	"; domain="
#define COOKIE_SECURE	"; secure"
#define COOKIE_HTTPONLY	"; HttpOnly"
 
static void php_session_send_cookie(TSRMLS_D) /* {{{ */
{
	smart_str ncookie = {0};
	char *date_fmt = NULL;
	char *e_session_name, *e_id;
 
	if (SG(headers_sent)) {
		char *output_start_filename = php_get_output_start_filename(TSRMLS_C);
		int output_start_lineno = php_get_output_start_lineno(TSRMLS_C);
 
		if (output_start_filename) {
			php_error_docref(NULL TSRMLS_CC, E_WARNING, "Cannot send session cookie - headers already sent by (output started at %s:%d)", output_start_filename, output_start_lineno);
		} else {
			php_error_docref(NULL TSRMLS_CC, E_WARNING, "Cannot send session cookie - headers already sent");
		}
		return;
	}
 
	/* URL encode session_name and id because they might be user supplied */
	e_session_name = php_url_encode(PS(session_name), strlen(PS(session_name)), NULL);
	e_id = php_url_encode(PS(id), strlen(PS(id)), NULL);
 
	smart_str_appends(&ncookie, COOKIE_SET_COOKIE);
	smart_str_appends(&ncookie, e_session_name);
	smart_str_appendc(&ncookie, '=');
	smart_str_appends(&ncookie, e_id);
 
	efree(e_session_name);
	efree(e_id);
 
	if (PS(cookie_lifetime) > 0) {
		struct timeval tv;
		time_t t;
 
		gettimeofday(&tv, NULL);
		t = tv.tv_sec + PS(cookie_lifetime);
 
		if (t > 0) {
			date_fmt = php_format_date("D, d-M-Y H:i:s T", sizeof("D, d-M-Y H:i:s T")-1, t, 0 TSRMLS_CC);
			smart_str_appends(&ncookie, COOKIE_EXPIRES);
			smart_str_appends(&ncookie, date_fmt);
			efree(date_fmt);
		}
	}
 
	if (PS(cookie_path)[0]) {
		smart_str_appends(&ncookie, COOKIE_PATH);
		smart_str_appends(&ncookie, PS(cookie_path));
	}
 
	if (PS(cookie_domain)[0]) {
		smart_str_appends(&ncookie, COOKIE_DOMAIN);
		smart_str_appends(&ncookie, PS(cookie_domain));
	}
 
	if (PS(cookie_secure)) {
		smart_str_appends(&ncookie, COOKIE_SECURE);
	}
 
	if (PS(cookie_httponly)) {
		smart_str_appends(&ncookie, COOKIE_HTTPONLY);
	}
 
	smart_str_0(&ncookie);
 
	/*	'replace' must be 0 here, else a previous Set-Cookie
		header, probably sent with setcookie() will be replaced! */
	sapi_add_header_ex(ncookie.c, ncookie.len, 0, 0 TSRMLS_CC);
}
/* }}} */

第1195~1200行定义常量宏，这些定义的内容我们可以通过查看http协议的应答头中可以看到，Set-Cookie是字段名，其余的为此字段中可以包含的变量，我们可以通过与PHP自带的setcookie操作函数的参数比对进行学习，此函数的定义如下:

1	bool setcookie ( string $name [, string $value [, int $expire = 0 [, string $path [, string $domain [, bool $secure = false [, bool $httponly = false ]]]]]] )

相关参数说明请参考：http://docs.php.net/manual/zh/function.setcookie.php
第1208~1218行关于是否已经发送了cookie应答的情况处理
第1221~1222行使用PHP中的函数urlencode的C程序实现，以防止人为添加的session name和session id出现混乱
第1224~1227行将Set-Cookie字段名，session name和session id的值添加到将要发送的cookie字符串中。
第1232~1245行 cookie的过期时间处理
第1247~1250行 cookie的路径处理
第1252~1255行 cookie的域名处理
第1257~1259行 cookie是否仅仅通过安全连接(https)发送cookie。
第1261~1263行 cookie是否在cookie中添加httpOnly标志(仅允许HTTP协议访问)的处理
最后通过sapi_add_header_ex函数将生成的字符串添加到应答头中。
【缓存限制器】
缓存限制器的结构定义：

typedef struct {
	char *name;	
	void (*func)(TSRMLS_D);
} php_session_cache_limiter_t;

如上所示代码，一个限制器包括一个名称和一个处理函数。
缓存限制器的实现原理
从其代码实现看，所谓的缓存限制器是通过返回不同的http请求的缓存控制字段内容达到缓存控制的目的。
默认情况下，session.cache_limiter = nocache
即使用CACHE_LIMITER_FUNC(nocache)
其中关于缓存控制器总共有4种方案，分别为：

static php_session_cache_limiter_t php_session_cache_limiters[] = {
	CACHE_LIMITER_ENTRY(public)
	CACHE_LIMITER_ENTRY(private)
	CACHE_LIMITER_ENTRY(private_no_expire)
	CACHE_LIMITER_ENTRY(nocache)
	{0}
};

其调用代码在session.c1180 行，如下：

	for (lim = php_session_cache_limiters; lim->name; lim++) {
		if (!strcasecmp(lim->name, PS(cache_limiter))) {
			lim->func(TSRMLS_C);
			return 0;
		}
	}

以上代码为一个遍历缓存控制器所在数组，并判断其方案名与PS(cache_limiter)是否一致，如果一致则执行此缓存控制，并返回。

【序列化实现】
PHP的session存放的都是序列化后的数据。
默认情况下使用session.serialize_handler = php
在源码中默认给出了两种序列化的实现。其最多可以有11种序列化的方法，相关代码如下：

#define MAX_SERIALIZERS 10
#define PREDEFINED_SERIALIZERS 2
 
static ps_serializer ps_serializers[MAX_SERIALIZERS + 1] = {
	PS_SERIALIZER_ENTRY(php),
	PS_SERIALIZER_ENTRY(php_binary)
};

ps_serializer结构定义如下：

#define PS_SERIALIZER_ENCODE_ARGS char **newstr, int *newlen TSRMLS_DC
#define PS_SERIALIZER_DECODE_ARGS const char *val, int vallen TSRMLS_DC
 
typedef struct ps_serializer_struct {
	const char *name;
	int (*encode)(PS_SERIALIZER_ENCODE_ARGS);
	int (*decode)(PS_SERIALIZER_DECODE_ARGS);
} ps_serializer;

序列化通过调用php_session_register_serializer函数实现序列化的注册过程
php_session_register_serializer函数遍历ps_serializers数组，并判断数组元素的name属性是否为NULL,如果为NULL,则将新的序列化函数添加到ps_serializers数组。

【其它维度的文章】
PHP5 Session 浅析I
PHP5 Session 浅析II
作者从另外一个维度分析了session的一些原理，值得学习一下。

潘锦的空间

SaaS SaaS架构团队管理技术管理技术架构 PHP 内核扩展项目管理

标签归档：session

WEB 会话管理杂谈

1 前言

2 概念

3 存储方式

3.1 服务端 session

3.3 令牌方案

4 存储内容

5 小结

6 参考资料

PHP源码阅读笔记三十七：PHP中的SESSION实现

1 前言

2 概念

3 存储方式

3.1 服务端 session

3.2 客户端 cookie 方案

3.3 令牌方案

4 存储内容

5 小结

6 参考资料

Cookie是什么

Cookie的历史

Cookie和Seesion

同源策略

参考资料：