socket so_reuseport

简单说下SO_REUSEPORT的应用场景, 为什么会用他? 然而在讲解SO_REUSEPORT之前,需要先说下我们常用的网络模型。

在多核时代,一般主流的web服务器都使用 SO_REUSEADDR模式。 以下是比较典型的多进程/多线程服务器模型。


socket so_reuseport_第1张图片

首先需要单线程/单进程listen一个端口上,然后由多个工作进程/线程去accept()在同一个服务器套接字上。

简单说就是,一个linten, 多个accept

性能瓶颈:

第一个性能瓶颈,单线程listener,在处理高速率海量连接时,一样会成为瓶颈

第二个性能瓶颈,多线程访问server socket锁竞争严重。

那么怎么解决? 这里先别扯什么分布式调度,集群xxx的 , 就拿单机来说问题。在Linux kernel 3.9带来了SO_REUSEPORT特性,她可以解决上面(单进程listen,多工作进程accept() )的问题.


socket so_reuseport_第2张图片

多个listen.每个对应一个accept. 由内核去负载均衡将链接分不到具体的一个服务器socket上。

看图说话,对比SO_REUSADDR的模型,我想你应该看懂SO_REUSEPORT是个什么东西了。SO_REUSEPORT是支持多个进程或者线程绑定到同一端口,提高服务器程序的吞吐性能,具体来说解决了下面的几个问题:

          允许多个套接字 bind()/listen() 同一个TCP/UDP端口

          每一个线程/进程拥有自己的服务器套接字

          在服务器套接字上没有了锁的竞争,因为每个进程一个服务器套接字

          内核层面实现负载均衡

          安全层面,监听同一个端口的套接字只能位于同一个用户下


我这边用python做了一个关于pythonSO_REUSEPORT服务端测试.  测试之前,已经要确定你的linux内核版本是3.9, 在mac下进行so_reuseport测试,貌似不会提示端口被绑定,但是后启动的进程会阻塞.

file:pythonreuseport.py


socket so_reuseport_第3张图片

nohup   pythonreuseport.py&

nohup   pythonreuseport.py&

nohup   pythonreuseport.py&

nohup   pythonreuseport.py&

nohup   pythonreuseport.py&


有些文章说,在python下多进程绑定同一个端口,也就是有人常说的prefork,他其实也是单个进程去listen监听端口,剩余的worker去accept获取用户请求而已.  如果想用python实现真正的多进程绑定在多一个端口,那只能是用so_reuseport模式 。

你可能感兴趣的:(socket so_reuseport)