阿里云「飞天发布时刻」2024来啦!新产品、新特性、新能力、新方案,等你来探~ 了解详情
写点什么

NGINX 应用性能优化指南(第六部分):连接优化

  • 2016-05-08
  • 本文字数:1860 字

    阅读完需:约 6 分钟

【编者的话】本文是“NGINX 应用性能优化指南”系列文章的第六篇,主要介绍了如何从连接优化方面实现 NGINX 应用性能优化。

注:本文最初发布于 MaxCDN 博客,InfoQ 中文站在获得作者授权的基础上对文章进行了翻译。

正文

RFC 7413 定义了 TCP Fast Open(TFO)——一种对 TCP 协议的扩展,允许在 TCP 握手期间的 TCP-SYN 和 TCP-SYN/ACK 数据包中夹带数据,这样就减少了一个 RTT。

在原有 TCP 连接的基础上,客户端生成一个TFO cookie,并将其放进 TCP-SYN 数据包作为一个 TCP 选项。稍后,当客户端再次连接时,它会在 TCP-SYN 数据包中再次发送同样的 cookie,同数据一起——可能是一个 HTTP 请求或者一个 TLS ClientHello。如果服务器识别出这个 cookie,那么它立即就会转换为已连接状态,并接收在 TCP-SYN 数据包中找到的数据。

虽然服务器可以使用 TCP-SYN/ACK 数据包中的数据回复,但更可能(从时间角度),TCP 栈会在 a 应用程序数据跟随到来之前发出 TCP-SYN/ACK 数据包。不管哪一种情况,数据较少的 TCP 握手往返现在可以用于发送和接收数据了,节省了一次往返。

这有益于加速 HTTP 请求,改善流媒体的首字节时间(TTFB)。实现 TFO 的核心以及 NGINX 所需要的所有东西就是listen指令的fastopen参数。

自 3.7 版本开始,在 IPv4 上支持 TFO 已经合并进 Linux 内核主干上(可以使用uname -r查看内核版本)。如果你运行着 3.13 或更好版本的内核,TFO 很可能已经默认启用。可以使用下面的命令(Linux)检查 TFO 是否启用:

复制代码
$ cat /proc/sys/net/ipv4/tcp_fastopen

0 值表明它被禁用了;位 0 对应客户端操作,而位 1 对应服务器操作。把tcp_fastopen设为 3 可将两者同时启用。

大多数可下载 NGINX 程序包都不包含TFO 支持,因为 TCP_FASTOPEN 并不一定在tcp.h中定义——即使内核提供了支持。你可以通过源代码构建 NGINX,并将编译时将限定-DTCP_FASTOPEN=23添加到 NGINX 的配置脚本中(--with-cc-opt)。

相关教程:在 CentOS 7 上启用 TFO for NGINX

证书验证

在 TLS 协商期间,客户端必须验证服务器的证书,以确信那个服务器就是它实际上请求的服务器。

验证通常包括生成一个 OCSP 请求,并发送给证书认证中心(CA),这意味着生成一个 DNS 查询和一个新的 TCP 连接。所有这些步骤都延长了同服务器进行 TLS 协商的时间。

OCSP Stapling 概念将 OCSP 查询的负担从客户端移到了服务器。结果是,服务器将 CA 的时限应答“钉合(stapling)”到服务器的证书上,这样一来就简化了客户端的证书验证步骤。

NGINX 通过ssl_stapling及相关指令来支持 OCSP Stapling。

TLS 会话恢复

有两种机制可以用于让后续 TLS 连接(下面会讨论)少一次往返:

  1. TLS 会话 ID
  2. TLS 会话票证

需要注意的是,TLS 会话恢复在服务器端会泄露 TLS 会话信息,破坏“完全前向保密(perfect forward secrecy)”。因此,如果需要 PFS,就不应该用它。另一方面,通过在一个 TLS 隧道中复用多个请求,HTTP/2 提供了同TLS 会话恢复一样的 RTT 优化,而且不用牺牲 PFS。

TLS 会话 ID

在最初的 TLS 握手期间,服务器会生成一个 TLS 会话 ID,并通过 ServerHello 消息发送给客户端——这在 Wireshark 跟踪文件中可以看到:

对于后续的 TLS 握手,客户端可能会在其 ClientHello 消息中发送会话 ID。这就使得服务器可以恢复缓存的 TLS 上下文,在一次 TLS 握手中省掉两次往返。

NGINX 通过ssl_session_cachessl_session_timeout指令支持 TLS 会话 ID。

TLS 会话票证

TLS 会话票证TLS 会话 ID的概念类似,不过存储会话信息的负担由服务器端转移到了客户端。

在一次普通的 TLS 握手期间,服务器会加密其 TLS 会话信息,并将结果票证发送给客户端。虽然客户端无法解码票证,但它可以在下次想要建立 TLS 连接时将其发回服务器。

TLS 会话 ID一样,这会减少一次往返——但服务器不必维护 SSL 缓存。不过,服务器必须维护一个用于加密票证的密钥(ssl_session_ticket_key),并要确保它的安全。

找到属于自己的理想 NGINX 设置

按照设计,NGINX 是完全开放的。它是一辆装有光面轮胎的赛车,而且驾驶它的是一个疯狂的司机。所以大家一起尽情地玩,尝试一些东西,让我们知道你能让它多快。此外,如果你认为有什么东西应该加入到这份指南中,请告诉我们。我们会在第二个版本中补充和修正。

查看英文原文: NGINX Application Performance Optimization:Connection Optimizations


感谢郭蕾对本文的策划和审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ @丁晓昀),微信(微信号: InfoQChina )关注我们。

2016-05-08 18:064529
用户头像

发布了 1008 篇内容, 共 374.2 次阅读, 收获喜欢 341 次。

关注

评论

发布
暂无评论
发现更多内容

Android | 资源冲突覆盖的一些思考

哈利迪

android 团队

大型网站技术架构

LEAF

第 4 周 - 学习总结

大海

架构师训练营-W4-20200701

丁亚宁

极客大学架构师训练营 week4

Week4 总结

Coder

极客大学架构师训练营

第4周 系统架构:系统架构知识是架构师的常识而不是能力

陆不得

架构师训练营第四周 - 总结

Eric

极客大学架构师训练营

大型网站架构问题

新世界

架构师训练营 -W4-20200701-学习总结

丁亚宁

学习 极客大学架构师训练营 week4

week04作业一

uangguan

架构 0 期 -week3- 学习总结

陈俊

极客大学架构师训练营

架构师训练营 week4

devfan

week4-典型大型互联网应用系统使用技术方案和手段

暖丶冬

架构师训练营-第四周-命题作业

sljoai

极客大学架构师训练营 第四周作业

架构师训练营week4作业1

平淡人生

第四周作业

考尔菲德

架构 0 期 -week3- 命题作业

陈俊

极客大学架构师训练营

第四周作业

nihuihua

互联网系统应用的技术方案

王麒宇

第四周总结

LEAF

一个典型的大型互联网应用系统使用了哪些技术方案和手段

张瑞浩

互联网应用系统的技术方案和手段

鲁米

大型互联网应用系统技术方案

Thrine

week04总结

uangguan

架构师训练营第四周作业

养乐多

一周信创舆情观察(6.22~6.28)

统小信uos

大数据 新基建 舆情

【荒于嬉】Redis持久化漫谈

luojiahu

redis 持久化

架构师训练营 第四周 个人感想

且听且吟

架构师训练营 week4 - 学习总结

devfan

【架构师训练营】第4周作业

花生无翼

极客大学架构师训练营

架构师训练 第四周 作业

LiJun

极客大学架构师训练营

NGINX应用性能优化指南(第六部分):连接优化_后端_谢丽_InfoQ精选文章