本文为 UPYUN 翻译内容，欢迎转载，但须标明来源

英文原文链接： http://t.cn/RLoaZAx

NGINX 1.9.1 发布版本中引入了一个新的特性 —— 允许套接字端口共享，该特性适用于大部分最新版本的操作系统，其中也包括 DragonFly BSD 和内核 3.9 以后的 Linux 操作系统。套接字端口共享选项允许多个套接字监听同一个绑定的网络地址和端口，这样一来内核就可以将外部的请求连接负载均衡到这些套接字上来。（对于 NGINX Plus 的用户来说，该特性将会在年底发布的版本 7 中得到支持）

实际上很多潜在的用户希望使用端口重用功能。其他服务也可以简单的进行热更新升级「 NGINX 支持 多种方式（ http://nginx.org/en/docs/control.html#upgrade ）的热更新」。对于 NGINX 来说，打开该选项可以通过在特定场景下减少连接锁竞争而提高性能。

如下图所示，在该选项没有生效的前提下，一个单独的监听套接字会通知所有的工作进程，每个进程则会试图争抢接管某个连接：

当该选项生效时，这个时候对于每个网络地址和端口就会有多个监听套接字，每个工作进程对应一个套接字，内核会决定由哪个监听套接字（也就是决定哪个工作进程）接管进来的连接。这个特性可以减少进程与进程之间为接收连接产生的锁竞争而提高多核系统的性能。但是，如果当一个工作进程处于阻塞操作时，这个时候不仅会影响已经被该进程接收的连接，还会阻塞由系统准备分配给该进程的连接请求：

配置套接字共享

如下面配置所示，可以通过在 listen 指令后添加新的参数 reuseport 来为 HTTP 或者 TCP （流模块）打开套接字端口共享功能：

对于套接字来说，添加 reuseport 参数也就等于禁止了 accept_mutex（ http://nginx.org/en/docs/ngx_core_module.html#accept_mutex ）指令了，因为 mutex 对于 reuseport 来说是多余的，不过对于那些不希望使用套接字端口共享特性的端口来说，我们则有必要设置 accept_mutex 。

reuseport 性能压力测试

我通过运行 wrk （ https://github.com/wg/wrk ）压测工具来压测一个跑在 36 核亚马逊实例上并开启 4 个工作进程的 NGINX 。为了减少网络对于测试结果的影响，我们的客户端和 NGINX 都是运行在本地的，并且 NGINX 只返回 OK 字符串而不返回文件。我对比了三个不同的配置，一个是默认的（等同于 accept_mutex on ），另一个是 accept_mutex off ，还有一个则是 reuseport 。正如下图所示，使用 reuseport 后每秒能处理的请求数比其他的两个增加了 2-3 倍，并且同时减少了平均延迟和平均延迟的标准差。

我还尝试客户端和 NGINX 分别运行在不同的主机上跑相关的压力测试，但这一次 NGINX 返回的是一个 HTML 文抗投诉服务器件。正如下表所示，与上图的结果类似，使用端口重用能减少请求的处理延迟，并且延迟标准差减少的更加明显（大概是 10 倍）。其他结果（并没有在下表中显示）则更加让人欣喜。通过端口重用，请求的压力被各个工作进程均衡掉，而在默认条件下（也就是 accept_mutex 打开），一些工作进程会得到比较高的负载，而在 accept_mutex 关闭的时候，所有的进程都会显示负载比较高。

在上述的压力测试中，请求的频率很高但是每个请求并不需要复杂的处理。其他一些初步的测试也表明端口重用特性在网络流量匹配的时候最能提高性能。（该参数并不能在邮件模块的上下文监听指令中生效，因为邮件的网络流量并不能匹配这个特性）。我们建议你在使用 reuseport 这个指令前先在你的 NGINX 实例上进行性能测试，而不是全部的 NGINX 实例都使用。对于测试 NGINX 的一些小提示，可以参考 Konstantin Pavlov 在 2014 NGINX 大会上的演讲.（ http://v.qq.com/page/b/u/l/b0160ces5ul.html ）

致谢

感谢在英特尔工作的卢英奇和 Sepherosa Ziehau ，他们每个人各自贡献了使得套接字端口共享生效的解决方案。 NGINX 开发小组合并了他们俩的想法从而创造出目前看来比较理想的解决方案。

---

本文为 UPYUN “ Deep down ” 技术征文计划稿件，来源： CDN 开发工程师 其实不想走（译者）

查看更多该计划精选文章请关注 UPYUN 微信公众号 （ upaiyun ），并回复 关键字“ deepdown ”

本计划长期对内外征求高质量技术、产品类专题稿件，咨询或者投稿请公众号后台留言，或者发邮件到 [email protected]

---

Thx!

其实我更关心什么时候能拿到稳定版的 HTTP/2 支持……

我用了一下 Nginx 的 HTTP/2 ，还有不少问题。还是切回 H2O 了。
https://www.imququ.com/post/nginx-http2-patch.html
（我的博客正在关站备案中，请用 OSX 、 Android 、 iOS 、 Linux 访问）

你列的我一个都没有，毅然拿出手机，竟然打开了…

你的手机是 Android ，我列了呀。

现在访问 www.imququ.com 是阿里云的默认提示页面了

iPad 打开是 404 …

然而我并没有安卓手机。

尝试一下 nghttp2 ，为 nginx 添加 HTTP/2 和 SPDY/3.1 支持。

加 https ， https://www.imququ.com 就不会被阿里云拦截了。
你看你之前的回复，确实 via Android 。
多谢反馈，我加一个。

然而这是台挪鸡鸭，我用的是 Edge 。

看了一眼，似乎是反代吧。还是期望原生支持。

然后移动版 Edge 的 UA 是这样：
Mozilla/5.0 (Windows Phone 10.0; Android 4.2.1; DEVICE INFO ) AppleWebKit/537.36 (KHTML, like Gecko ) Chrome/42.0.2311.135 Mobile Safari/537.36 Edge/12.

果然是披着 WP 的安卓（不对

Caddy 那東西爛到我不會再用了（
至於 h2o 現在有 FastCGI support 能直接對接 PHP-FPM 之類的東西了
所以是目前最成熟的吧
至於那個 patch 不是說會犧牲 SPDY 麼
這樣在不 SUP HTTP2 的瀏覽器底下不就也沒 SPDY 了(然而這種情況的比率佔多數...)

你觉得 Nghttp2 如何？我初步试了一下，也都提供 H/2 和 SPDY 的，就是不知道性能如何。