为什么要优化 Ngin HTTPS 提早
Nginx 常作为最常见的服务器，常被用作负载平衡 (Load Balancer)、反向代理 (Reverse Proxy)，以及网关 (Gateway) 等等。一个配置切当的 Nginx 服务器单机应该能够冀望接受住 50K 到 80K 左右每秒的申请，同时将 CPU 负载在可控范畴内。
但在很多时候，负载并不是须要首要优化的重点。比方对于卡拉搜寻来说，咱们心愿用户在每次击键的时候，能够体验即时搜寻的感觉，也就是说，每个搜寻申请必须在 100ms – 200ms 的工夫内端对端地返回给用户，能力让用户搜寻时没有“卡顿”和“加载”。因而，对于咱们来说，优化申请提早才是最重要的优化方向。
这篇文章中，咱们先介绍 Nginx 中的 TLS 设置有哪些与申请提早可能相干，如何调整能力最大化减速。而后咱们用优化卡拉搜寻 Nginx 服务器的实例来分享如何调整 Nginx TLS/SSL 设置，为首次搜寻的用户提速 30% 左右。咱们会具体探讨每一步咱们做了一些什么优化，优化的动机和成果。心愿能够对其它遇到相似问题的同学提供帮忙。
TLS 握手和提早
很多时候开发者会认为：如果不是相对在意性能，那么理解底层和更细节的优化没有必要。这句话在很多时候是失当的，因为很多时候简单的底层逻辑必须包起来，能力让更高层的利用开发复杂度可控。比如说，如果你就只须要开发一个 APP 或者网站，可能并没有必要关注汇编细节，关注编译器如何优化你的代码——毕竟在苹果或者安卓上很多优化在底层就做好了。
那么，理解底层的 TLS 和应用层的 Nginx 提早优化有什么关系呢？
答案是少数状况下，优化网络提早其实是在尝试缩小用户和服务器之间的数据传输次数，也就是所谓的 roundtrip。因为物理限度，北京到云南的光速流传差不多就是要跑 20 来毫秒，如果你不小心让数据必须屡次往返于北京和云南之间，那么必然提早就下来了。
因而如果你须要优化申请提早，那么理解一点底层网络的上下文则会大有裨益，很多时候甚至是你是否能够轻松了解一个优化的要害。本文中咱们不深刻探讨太多 TCP 或者 TLS 机制的细节，如果有趣味的话请参考 High Performance Browser Networking[4] 一书，能够收费浏览。
举个例子，下图中展现了如果你的服务启用了 HTTPS，在开始传输任何数据之前的数据传输状况。
能够看到，在你的用户拿到他须要的数据前，底层的数据包就曾经在用户和你的服务器之间跑了 3 个来回。
假如每次来回须要 28 毫秒的话，用户曾经等了 224 毫秒之后才开始接收数据。
同时这个 28 毫秒其实是十分乐观的假如，在国内电信、联通和挪动以及各种简单的网络情况下，用户与服务器之间的提早更不可控。另一方面，通常一个网页须要数十个申请，这些申请不肯定能够全副并行，因而几十乘以 224 毫秒，页面关上可能就是数秒之后了。
所以，原则上如果可能的话，咱们须要尽量减少用户和服务器之间的往返程 (roundtrip)，在下文的设置中，对于每个设置咱们会探讨为什么这个设置有可能帮忙缩小往返程。
Nginx 中的 TLS 设置
那么在 Nginx 设置中，怎么调整参数会缩小提早呢？
开启 HTTP/2
HTTP/2 规范是从 Google 的 SPDY 上进行的改良，比起 HTTP 1.1 晋升了不少性能，尤其是须要并行多个申请的时候能够显着缩小提早。在当初的网络上，一个网页均匀须要申请几十次，而在 HTTP 1.1 时代浏览器能做的就是多开几个连贯（通常是 6 个）进行并行申请，而 HTTP 2 中能够在一个连贯中进行并行申请。HTTP 2 原生反对多个并行申请，因而大大减少了程序执行的申请的往返程，能够首要思考开启。
如果你想本人看一下 HTTP 1.1 和 HTTP 2.0 的速度差别，能够试一下：https://www.httpvshttps.com/。我的网络测试下来 HTTP/2 比 HTTP 1.1 快了 66%。
在 Nginx 中开启 HTTP 2.0 非常简单，只须要减少一个 http2 标记即可
listen 443 ssl;
# 改为
listen 443 ssl http2;
如果你放心你的用户用的是旧的客户端，比方 Python 的 requests，临时还不反对 HTTP 2 的话，那么其实不必放心。如果用户的客户端不反对 HTTP 2，那么连贯会主动降级为 HTTP 1.1，放弃了后向兼容。因而，所有应用旧 Client 的用户，依然不受影响，而新的客户端则能够享受 HTTP/2 的新个性。
如何确认你的网站或者 API 开启了 HTTP 2
在 Chrome 中关上开发者工具，点开 Protocol 之后在所有的申请中都能够看到申请用的协定了。如果 protocol 这列的值是 h2 的话，那么用的就是 HTTP 2 了
当然另一个方法是间接用 curl 如果返回的 status 前有 HTTP/2 的话天然也就是 HTTP/2 开启了。
➜ ~ curl --http2 -I https://kalasearch.cn
HTTP/2 403
server: Tengine
content-type: application/xml
content-length: 264
date: Tue, 22 Dec 2020 18:38:46 GMT
x-oss-request-id: 5FE23D363ADDB93430197043
x-oss-cdn-auth: success
x-oss-server-time: 0
x-alicdn-da-ups-status: endOs,0,403
via: cache13.l2et2[148,0], cache10.l2ot7[291,0], cache4.us13[360,0]
timing-allow-origin: *
eagleid: 2ff6169816086623266688093e
调整 Cipher 优先级
尽量筛选更新更快的 Cipher，有助于缩小提早:
# 手动启用 cipher 列表
ssl_prefer_server_ciphers on; # prefer a list of ciphers to prevent old and slow ciphers
ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';
启用 OCSP Stapling
在国内这可能是对应用 Let’s Encrypt 证书的服务或网站影响最大的提早优化了。如果不启用 OCSP Stapling 的话，在用户连贯你的服务器的时候，有时候须要去验证证书。而因为一些不可知的起因（这个就不说穿了）Let’s Encrypt 的验证服务器并不是十分通顺，因而能够造成有时候数秒甚至十几秒提早的问题，这个问题在 iOS 设施上特地重大
解决这个问题的办法有两个：
- 不应用 Let’s Encrypt，能够尝试替换为阿里云提供的收费 DV 证书
- 开启 OCSP Stapling
开启了 OCSP Stapling 的话，跑到证书验证这一步能够省略掉。省掉一个 roundtrip，特地是网络情况不可控的 roundtrip，可能能够将你的提早大大减少。
在 Nginx 中启用 OCSP Stapling 也非常简单，只须要设置：
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /path/to/full_chain.pem;
如何检测 OCSP Stapling 是否曾经开启？
能够通过以下命令
openssl s_client -connect test.kalasearch.cn:443 -servername kalasearch.cn -status -tlsextdebug < /dev/null 2>&1 | grep -i "OCSP response"
来测试。如果后果为
OCSP response:
OCSP Response Data:
OCSP Response Status: successful (0x0)
Response Type: Basic OCSP Response
则表明曾经开启。
调整 ssl_buffer_size
ssl_buffer_size 管制在发送数据时的 buffer 大小，默认设置是 16k。这个值越小，则提早越小，而增加的报头之类会使 overhead 会变大，反之则提早越大，overhead 越小。
因而如果你的服务是 REST API 或者网站的话，将这个值调小能够减小提早和 TTFB，但如果你的服务器是用来传输大文件的，那么能够维持 16k。
如果是网站或者 REST API，倡议值为 4k，然而这个值的最佳取值显然会因为数据的不同而不一样，因而请尝试 2 – 16k 间不同的值。在 Nginx 中调整这个值也非常容易
ssl_buffer_size 4k;
启用 SSL Session 缓存
启用 SSL Session 缓存能够大大减少 TLS 的重复验证，缩小 TLS 握手的 roundtrip。尽管 session 缓存会占用肯定内存，然而用 1M 的内存就能够缓存 4000 个连贯，能够说是十分十分划算的。同时，对于绝大多数网站和服务，要达到 4000 个同时连贯自身就须要十分十分大的用户基数，因而能够释怀开启。
# 这里 ssl_session_cache 设置为应用 50M 内存，以及 4 小时的连贯超时敞开工夫 ssl_session_timeout
# Enable SSL cache to speed up for return visitors
ssl_session_cache shared:SSL:50m; # speed up first time. 1m ~= 4000 connections
ssl_session_timeout 4h;
卡拉搜寻如何缩小 30% 的申请提早
卡拉搜寻是国内的 Algolia，致力于帮忙开发者疾速搭建即时搜寻性能 (instant search)，做国内最快最易用的搜寻即服务。
开发者接入后，所有搜寻申请通过卡拉 API 即可间接返回给终端用户。为了让用户有即时搜寻的体验，咱们须要在用户每次击键后极短的工夫内（通常是 100ms 到 200ms）将后果返回给用户。因而每次搜寻须要能够达到 50 毫秒以内的引擎解决工夫和 200 毫秒以内的端对端工夫。
咱们用豆瓣电影的数据做了一个电影搜寻的 Demo，如果感兴趣的话欢送体验一下即时搜寻，尝试一下搜寻“无间道”或者“大话西游”体验一下速度和相关度：https://movies-demo.kalasearc…
对于每个申请只有 100 到 200 毫秒的提早估算，咱们必须把每一步的提早都思考在内。
简化一下，每个搜寻申请须要经验的提早有
总提早 = 用户申请达到服务器 (T1) + 反代解决 (Nginx T2) + 数据中心提早 (T3) + 服务器解决 (卡拉引擎 T4) + 用户申请返回 (T3+T1)
在上述提早中，T1 只与用户与服务器的物理间隔相干，而 T3 十分小能够忽略不计。
所以咱们能管制的大抵只有 T2 和 T4，即 Nginx 服务器的解决工夫和卡拉的引擎解决工夫。
Nginx 在这里作为反向代理，解决一些平安、流量管制和 TLS 的逻辑，而卡拉的引擎则是一个在 Lucene 根底上的倒排引擎。
咱们首先思考的第一个可能性是：提早是不是来自卡拉引擎呢？
在下图展现的 Grafana 仪表盘中，咱们看到除了几个时不时的慢查问，搜寻的 95% 服务器解决提早小于 20 毫秒。比照同样的数据集上 benchmark 的 Elastic Search 引擎的 P95 搜寻提早则在 200 毫秒左右，所以排除了引擎速度慢的可能。
而在阿里云监控中，咱们设置了从全国各地向卡拉服务器发送搜寻申请。咱们终于发现 SSL 解决工夫时常会超过 300 毫秒，也就是说在 T2 这一步，光解决 TLS 握手之类的事件，Nginx 曾经用掉了咱们所有的申请工夫估算。
同时查看之后咱们发现，在苹果设施上搜寻速度分外慢，特地是第一次拜访的设施。因而咱们大抵判断应该是因为咱们应用的 Let’s Encrypt 证书的问题。
咱们依照上文中的步骤对 Nginx 设置进行了调整，并将步骤总结进去写了这篇文章。在调整了 Nginx TLS 的设置后，SSL 工夫从均匀的 140ms 升高到了 110ms 左右（全国所有省份联通和挪动测试点），同时苹果设施上首次拜访慢的问题也隐没了。
在调整过后，全国范畴内测试的搜寻提早升高到了 150 毫秒左右。
总结
调整 Nginx 中的 TLS 设置对于应用 HTTPS 的服务和网站提早有十分大的影响。本文中总结了 Nginx 中与 TLS 相干的设置，具体探讨各个设置可能对提早的影响，并给出了调整倡议。
起源：https://kalasearch.cn/blog/hi…