Session ticket关联TLS流方法分析

  HTTPS的过程是在TCP三次握手之后会进行SSL的四次握手，如果一个业务请求包含多条的加密流，反复的握手请求势必会导致较高的延迟。SSL的设计者们在尽量减少握手次数方面也是做了一定的考虑的。具体就是Session ID和Session ticket的应用。本文主要就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可以较好的解决此类问题，因为相关的加密参数信息交由客户端管理，服务器只要确认即可。

  下图是 Session ticket的一个报文。

 

  可以看到，这里面应用了Sessionticket，其原因就是我们刚才提到的。

  需要注意的是sessionID支持比较广泛，而Sessionticket支持相对少一些；对于服务器端，这两种中技术都是支持的，但是浏览器端来说Session ticket只有chrome和firefox支持，对于支持Session ticket的软件，都会有相应的处理机制。不仅如此，我看了一下，曾经分析过的Spotify，美拍等应用均是采用Session ticket，可见其应用广泛。这里面并没有抓到client hello发送的Session ticket，后续抓到之后再补上。

  更多内容请参见：sessionID RFC 5246；sessionticket RFC 5077