Question

访问https网站session何时产生

Answer 1

作者：凡柯
链接：https://www.zhihu.com/question/52320264/answer/130042542
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

ssl会话复用
先说明一下，利用https来通信时，其增加的主要消耗和时延在SSL握手阶段。在这个阶段客户端和服务器需要协商一些参数，比如双方支持的加解密套件等，最终会生成一个会话密钥。
这个过程是非对称的加密过程，主要是为了保护会话密钥的生成。
由于非对称加密的过程非常耗时计算密度大，此后的通信都是对称加密了，比如用AES－128等加上会话密钥来进行加密通信。
这个协商会话密钥的过程是主要的开销。为了避免每次会话都会有这种开销，会话复用由此而来。
现阶段支持两种会话复用机制：session id 和session ticket机制。session id机制由服务器端来存储主要信息，session ticket由客户端来存储主要信息。
session id机制： 如果客户端想要复用会话，会在client hello报文中会传送一个session id号，这个id号对应着现前某一次的会话信息，比如说premaster secret,master secret 以及会话密钥等需要经过“昂贵的”握手阶段才能重新协商好的一些信息。如果服务器支持客户端的想法，它会根据这个session id号在本地查询该id号对应的现前的会话信息，如果查找到了这些信息，比如会话密钥，那么就在serverhello中回送给客户端的报文中带上通用的session id字段，表明我支持你的此次id复用。然后两人就绕过了重新协商会话密钥的过程，直接复用了现前的会话密钥，达到了会话复用的目的。
可以看到这种机制的特点：服务器需要保存id和会话状态的字典，可当客户端一多，这种情况就极大地加重了服务器的压力，不具有可扩展性。而且，如果是服务器集群的话，那么session id复用的成功率也会降低，因为可能客户端第二次通信时的服务器没有存储这个id号，导致复用失败，还是需要重新握手。
在这种情况下，可以讲id和session状态存储到一个公用的存储介质上（比如redis／memcached），这样所有服务器节点就能查询到这些id对应的状态，提高复用率，我们公司目前采用了redis来存储。
session ticket机制：由于session id的不可扩展的缺点，后来由了ticket的复用机制，它将存储压力放到了客户端。即：新的会话后，服务器通过一个自由自己知道的密钥ticket key 将本次的会话状态加密后生成一个ticket，然后发送给客户端，客户端保存着这个ticket。下次客户端再和服务器建立ssl连接的时候，将此ticket发送给服务器，由于这个ticket只有服务器能够解开，且ticket key没有外泄，安全性有一定的保障。服务器解开这个ticket后，拿出里面的会话状态（包括会话密钥等），然后就开始用这个会话密钥进行加密通信，（客户端当然也是知道现前的这个会话密钥的）。
这种方式同样达到了会话复用的目的，且将所有的存储压力都转移到客户端，具有可扩展性。现阶段机会所有主流的浏览器都首先支持ticket的复用方式。
但是，这种方式仍然有一定的缺陷：即所有的服务器集群中的节点都必须使用同一个ticket key，时间久了也会不安全。所有需要对这个ticket key进行轮转变化，不过重点是在轮转的过程中需要兼容老的ticket key，用新的ticket key进行加解密，用老的ticket key只进行解密，最终慢慢淘汰掉老的ticket key。从而安全的复用效果。
目前有较多的方法来轮转这个ticket key。我们公司目前采用的是cloudflare公司开源出来的轮转方式，每小时轮转一次。具体代码在github上面可以找到。