TLS,DTLS session恢复机制

为啥

证书交互其实很耗费性能及流量,作为高连接的情况下,要支持会话恢复,减少TLS的握手信息,会大大提高性能.

基于sessionId 会话恢复

每次对话都有一个唯一的Id,sessionId, 由服务端证书交互后,给客户端,如果会话重新发起,在客户端clientHellow的时候,再次带上来这个sessionId,如果服务器有,就可以认为可以恢复这个会话,不用进行握手了. 客户端只要存一个sessionId就行了,其他的东西都在服务器端.

基于session ticket恢复

服务端和客户端握手完成后, 会将加密后的sessionticket 发送给客户端, 客户端来存储这个东西,等再次握手的时候发送这个sessionticket,服务器解密并获取session,建立连接.

具体使用场景

以上的两个场景其实就是存储的地方不同:
– sessionId是存在客户端,加重了服务端的资源使用,而且一般情况下适合单机恢复, 如果要在分布式场景下使用,得把会话加入分布式存储中,使用sessionId来做查找,具体思路为: 使用sessionId 当成key,把会话转成sessionTicket,使用redis等分布式缓存,使用sessionId恢复的时候,就找到对应的sessionTicket 来恢复会话.

  • sessionTicket,保存在客户端,因此天然支持分布式.但是每次你重新握手就重传sessionTicket 也是一个不小的量呀,看具体的业务具体实现吧,而且为了防止会话伪装,sessionticket要加密,服务器解密的方法还有很多东西可以探讨.

具体场景具体使用吧,


评论

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注