参考链接
《 https://blog.csdn.net/javajiawei/article/details/51331768 》
HTTPS的过程是在TCP三次握手之后会进行SSL的四次握手，如果一个业务请求包含多条的加密流，反复的握手请求势必会导致较高的延迟。SSL的设计者们在尽量减少握手次数方面也是做了一定的考虑的。具体就是Session ID和Session ticket的应用。
流关联的一种形式是Session ID，可以去了解一下原理。而本文所述的Sessionticket，是流关联的另外一种应用场景。
无论是Session ID还是Session ticket都是为了复用已有的加密参数，诸如秘钥以及加密算法等，进而减少SSL的握手次数，目的是提高有效数据的响应效率。
Session ID的思想就是服务器端为每一次的会话生成并记录一个ID号并发送给客户端，在重新连接的时候（多次短连接场景），客户端向服务器发送该ID号，服务器查找自己的会话记录，匹配之后，重用之前的加密参数信息。
而Sessionticket的思想类似于cookie，是由服务器将ticket数据结构发由客户端管理，ticket中是包含了加密参数等连接信息。当需要重连的时候，客户端将ticket发送给服务器。这样双方就得到了重用的加密参数。
Session ticket较之Session ID优势在于服务器使用了负载均衡等技术的时候。Session ID往往是存储在一台服务器上，当我向不同的服务器请求的时候，就无法复用之前的加密参数信息，而Session ticket可以较好的解决此类问题，因为相关的加密参数信息交由客户端管理，服务器只要确认即可。
发表评论