共计 3211 个字符，预计需要花费 9 分钟才能阅读完成。
背景
网络延迟是网络上的主要性能瓶颈之一。在最坏的情况下，客户端打开一个链接需要 DNS 查询（1 个 RTT），TCP 握手（1 个 RTT），TLS 握手（2 个 RTT），以及最后的 HTTP 请求和响应，可以看出客户端收到第一个 HTTP 响应的首字节需要 5 个 RTT 的时间，而首字节时间对 web 体验非常重要，可以体现在网站的首屏时间，直接影响用户判断网站的快慢，所以首字节时间（TTFB）是网站和服务器响应速度的重要指标，下面我们来看影响 SSL 握手的几个方面：
TCP_NODELAY
我们知道，小包的载荷率非常小，若网络上出现大量的小包，则网络利用率比较低，就像客运汽车，来一个人发一辆车，可想而知这效率将会很差，这就是典型的 TCP 小包问题，为了解决这个问题所以就有了 Nigle 算法，算法思想很简单，就是将多个即将发送的小包，缓存和合并成一个大包，然后一次性发送出去，就像客运汽车满员发车一样，这样效率就提高了很多，所以内核协议栈会默认开启 Nigle 算法优化。Night 算法认为只要当发送方还没有收到前一次发送 TCP 报文段的的 ACK 时，发送方就应该一直缓存数据直到数据达到可以发送的大小（即 MSS 大小），然后再统一合并到一起发送出去，如果收到上一次发送的 TCP 报文段的 ACK 则立马将缓存的数据发送出去。虽然效率提高了，但对于急需交付的小包可能就不适合了，比如 SSL 握手期间交互的小包应该立即发送而不应该等到发送的数据达到 MSS 大小才发送，所以，SSL 握手期间应该关闭 Nigle 算法，内核提供了关闭 Nigle 算法的选项：TCP_NODELAY，对应的 tengine/nginx 代码如下：
需要注意的是这块代码是 2017 年 5 月份才提交的代码，使用老版本的 tengine/nginx 需要自己打 patch。
TCP Delay Ack
与 Nigle 算法对应的网络优化机制叫 TCP 延迟确认，也就是 TCP Delay Ack，这个是针对接收方来讲的机制，由于 ACK 包是有效 payload 比较少的小包，如果频繁的发 ACK 包也会导致网络额外的开销，同样出现前面提到的小包问题，效率低下，因此延迟确认机制会让接收方将多个收到数据包的 ACK 打包成一个 ACK 包返回给发送方，从而提高网络传输效率，跟 Nigle 算法一样，内核也会默认开启 TCP Delay Ack 优化。进一步讲，接收方在收到数据后，并不会立即回复 ACK，而是延迟一定时间，一般 ACK 延迟发送的时间为 200ms（每个操作系统的这个时间可能略有不同），但这个 200ms 并非收到数据后需要延迟的时间，系统有一个固定的定时器每隔 200ms 会来检查是否需要发送 ACK 包，这样可以合并多个 ACK 从而提高效率，所以，如果我们去抓包时会看到有时会有 200ms 左右的延迟。但是，对于 SSL 握手来说，200ms 的延迟对用户体验影响很大，如下图：
9 号包是客户端的 ACK，对 7 号服务器端发的证书包进行确认，这两个包相差了将近 200ms，这个就是客户端的 delay ack，这样这次 SSL 握手时间就超过 200ms 了。那怎样优化呢？其实只要我们尽量少发送小包就可以避免，比如上面的截图，只要将 7 号和 10 号一起发送就可以避免 delay ack，这是因为内核协议栈在回复 ACK 时，如果收到的数据大于 1 个 MSS 时会立即 ACK，内核源码如下：
知道了问题的原因所在以及如何避免，那就看应用层的发送数据逻辑了，由于是在 SSL 握手期间，所以应该跟 SSL 写内核有关系，查看 openssl 的源码：
默认写 buffer 大小是 4k，当证书比较大时，就容易分多次写内核，从而触发客户端的 delay ack。
接下来查看 tengine 有没有调整这个 buffer 的地方，还真有（下图第 903 行）：
那不应该有 delay ack 啊……
无奈之下只能上 gdb 大法了，调试之后发现果然没有调用到 BIO_set_write_buffer_size，原因是 rbio 和 wbio 相等了，那为啥以前没有这种情况现在才有呢？难道是升级 openssl 的原因？继续查 openssl-1.0.2 代码：
openssl-1.1.1 的 SSL_get_wbio 有了变化：
原因终于找到了，使用老版本就没有这个问题。就不细去看 bbio 的实现了，修复也比较简单，就用老版本的实现即可，所以就打了个 patch：
重新编译打包后测试，问题得到了修复。使用新版 openssl 遇到同样问题的同学可以在此地方打 patch。
Session 复用
完整的 SSL 握手需要 2 个 RTT，SSL Session 复用则只需要 1 个 RTT，大大缩短了握手时间，另外 Session 复用避免了密钥交换的 CPU 运算，大大降低 CPU 的消耗，所以服务器必须开启 Session 复用来提高服务器的性能和减少握手时间，SSL 中有两种 Session 复用方式：
- 服务端 Session Cache
大概原理跟网页 SESSION 类似，服务端将上次完整握手的会话信息缓存在服务器上，然后将 session id 告知客户端，下次客户端会话复用时带上这个 session id，即可恢复出 SSL 握手需要的会话信息，然后客户端和服务器采用相同的算法即可生成会话密钥，完成握手。
这种方式是最早优化 SSL 握手的手段，在早期都是单机模式下并没有什么问题，但是现在都是分布式集群模式，这种方式的弊端就暴露出来了，拿 CDN 来说，一个节点内有几十台机器，前端采用 LVS 来负载均衡，那客户端的 SSL 握手请求到达哪台机器并不是固定的，这就导致 Session 复用率比较低。所以后来出现了 Session Ticket 的优化方案，之后再细讲。那服务端 Session Cache 这种复用方式如何在分布式集群中优化呢，无非有两种手段：一是 LVS 根据 Session ID 做一致性 hash，二是 Session Cache 分布式缓存；第一种方式比较简单，修改一下 LVS 就可以实现，但这样可能导致 Real Server 负载不均，我们用了第二种方式，在节点内部署一个 redis，然后 Tengine 握手时从 redis 中查找是否存在 Session，存在则复用，不存在则将 Session 缓存到 redis 并做完整握手，当然每次与 redis 交互也有时间消耗，需要做多级缓存，这里就不展开了。核心的实现主要用到 ssl_session_fetch_by_lua_file 和 ssl_session_store_by_lua_file，在 lua 里面做一些操作 redis 和缓存即可。
- Session Ticket
上面讲到了服务端 Session Cache 在分布式集群中的弊端，Session Ticket 是用来解决该弊端的优化方式，原理跟网页的 Cookie 类似，客户端缓存会话信息（当然是加密的，简称 session ticket），下次握手时将该 session ticket 通过 client hello 的扩展字段发送给服务器，服务器用配置好的解密 key 解密该 ticket，解密成功后得到会话信息，可以直接复用，不必再做完整握手和密钥交换，大大提高了效率和性能，（那客户端是怎么得到这个 session ticket 的呢，当然是服务器在完整握手后生成和用加密 key 后给它的）。可见，这种方式不需要服务器缓存会话信息，天然支持分布式集群的会话复用。这种方式也有弊端，并不是所有客户端或者 SDK 都支持（但主流浏览器都支持）。所以，目前服务端 Session Cache 和 Session Ticket 都会存在，未来将以 Session Ticket 为主。
Tengine 开启 Session Ticket 也很简单：
ssl_session_tickets on;
ssl_session_timeout 48h;
ssl_session_ticket_key ticket.key; #需要集群内所有机器的 ticket.key 内容（48 字节）一致 （全文完）
本文作者：金九
阅读原文
本文为云栖社区原创内容，未经允许不得转载。
