本文详细介绍了Linux内核中的REUSEPORT特性，该特性允许在同一台服务器上多个进程绑定并监听同一端口，解决了端口不可重复使用的限制。从2013年的3.9版本开始，Linux内核通过内部分配机制实现负载均衡，避免了锁竞争，提升了服务器性能。文章通过实践操作演示了如何启用和验证REUSEPORT特性，并讨论了其安全性验证。
【好文推荐】
大家好，我是Linux吴彦祖！
开篇我先考大家一个小问题，如果你的服务器上已经有个进程在 listen 6000 这个端口号了。那么该服务器上其它进程是否还能 bind 和 listen 该端口呢？
我相信一定会有一部分同学会答说是不能的。因为很多人都遇到过“Address already in use”这个错误。而这个错误产生的原因就是端口已经被占用。
但其实在 Linux 3.9 以上的内核版本里，是允许多个进程绑定到同一个端口号上。这就是我们今天要说的 REUSEPORT 新特性。
本文中咱们将阐述 REUSEPORT 是为了解决什么问题而产生的。如果有多个进程复用同一个端口，当用户请求到达时内核是如何选一个进程进行响应的。学习完本文，你将深刻掌握这一提升服务器端性能的利器！
一、 REUSEPORT 要解决的问题
我觉得理解一个技术点的很重要的前提是要弄明白这个问题产生的背景，弄明白了背景再理解起技术点来就会容易许多。
关于 REUSEPORT 特性产生的背景其实在 linux 的 commit 中提供的足够详细了（参见：https://github.com/torvalds/linux/commit/da5e36308d9f7151845018369148201a5d28b46d）。
我就在这个 commit 中的信息的基础上给大家展开了说一说。
大家有过服务器端开发的经验的同学都知道，一般一个服务是固定监听某一个端口的。比如 Nginx 服务一般固定监听 80 或 8080，Mysql 服务固定监听 3306 等等。
在网民数量还不够多，终端设备也还没有爆炸的年代里，一直是在使用的是端口不可重复被监听的模式。但是到了 2010 年之后，Web 互联网已经发展到了一个高潮，移动端的设备也开始迎来了大发展。这个时候端口不能重用的性能瓶颈就暴露出来了。
应对海量流量的主要措施就是应用多进程模型。在端口不可被重复 bind 和 listen 的年代里，提供海量服务的多进程 Server 提供一般是采用如下两种进程模型来工作。
第一种是专门搞一个或多个进程服务 accept 新连接，接收请求，然后将请求转给其它的 worker 进程来处理。
这种多进程模型有两个问题，首先第一个是 dispatcher 进程并不处理任务，需要转交给 worker 进程来处理和响应。这会导致一次额外的进程上下文切换的开销。第二个问题是如果流量特别大的时候 dispatcher 进程很容易成为制约整个服务 qps 提升的瓶颈。
还有另一种多进程模型是多个进程复用一个 listen 状态的 socket，多个进程同时从一个 socket 中 accept 请求来处理。Ng
最低0.47元/天 解锁文章
75
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
