Linux3.9中 SO_REUSEPORT 对高并发服务器的改进

背景

在传统网络编程模型中，为了实现高并发的服务器， 通常采用的做法是Master进程创建一个Listen socket，然后fork出来N个worker进程，这N个worker进程同时侦听这个socket。

然而这种模式仅仅是做到了进程级的可扩展性，即一个进程在忙时，其它进程可以介入帮忙处理，底层的socket句柄其实是同一个！简单点说，这是一个沙漏模型：

这种模型在处理同一个socket的时候，必须互斥，同时内核必须防止潜在的惊群效应，因为互斥的要求，有且仅有一个进程可以处理特定的请求。这就对编程造成了极大的干扰。

 

SO_REUSEPORT解决了什么问题

然而非常幸运的是，Linux 3.9 中SO_REUSEPORT出现后，模型彻底变成了桶状：

SO_REUSEPORT支持多个进程或者线程绑定到同一端口，提高服务器程序的性能，解决的问题：

• 允许多个套接字 bind()/listen() 同一个TCP/UDP端口
  • 每一个进程/线程拥有自己的服务器套接字
  • 在服务器套接字上没有了锁的竞争
• 内核层面实现负载均衡
• 安全层面，监听同一个端口的套接字只能位于同一个用户下面

其核心的实现主要有三点：

• 扩展 socket option，增加 SO_REUSEPORT 选项，用来设置 reuseport。
• 修改 bind 系统调用实现，以便支持可以绑定到相同的 IP 和端口
• 修改处理新建连接的实现，查找 listener 的时候，能够支持在监听相同 IP 和端口的多个 sock 之间均衡选择。

有了SO_RESUEPORT后，每个进程可以自己创建socket、bind、listen、accept相同的地址和端口，各自是独立平等的。让多进程监听同一个端口，各个进程中accept socket fd不一样，有新连接建立时，内核只会唤醒一个进程来accept，并且保证唤醒的均衡性。

来自于多个客户端的TCP/UDP连接会被均匀地分配给上层的sock 处理，同一个客户端的数据总是分配给同一个 sock。这种模式彻底解决了socket的瓶颈问题，这样我们在写 sock server 的时候，可以fork出多个进程同时监听scoket，每个进程读写自己的 socket而不用加锁， 也没有之前的惊群现象，比多个进程读写同一个  socket 提高了很多效率。