1.单个进程监听多个端口
单个进程创建多个 socket 绑定不同的端口,TCP, UDP 都行
2.多个进程监听同一个端口
方式1:通过 fork 创建子进程的方式可以实现,其他情况下不行。
当连接到来时,子进程、父进程都可以 accept, 这就是著名的“惊群”问题(thundering herd problem)。
由于所有子进程都继承了父进程的 sockfd,那么当连接进来时,所有子进程都将收到通知并“争着”与它建立连接,这就叫“惊群现象”。大量的进程被激活又挂起,只有一个进程可以accept() 到这个连接,这当然会消耗系统资源。
NGINX 的 master/work 处理方法:
Flow of an NGINX worker process
可以设置 ffd 的 close-on-exec flag 避免子进程继承 fd.
方式2:我们都知道socket是网络上两个进程之间的双向通信链路, 即
socket = 《A进程的IP地址:端口号,B进程的IP地址:端口号》
那么有个问题就很有意思了,不同的进程可以监听在同一个IP地址:端口号么?
根据Unix网络编程中的知识可知,服务端监听一个端口会经历:
1、根据套接字类型(Ipv4,Ipv6等)创建套接字socket
2、将套接字bind绑定到具体的网络地址和端口号
3、调用listen开始在这个套接字上进行监听。
Unix提供了一个接口setsockopt()可以在bind之前设置套接字选项,其中就包括REUSEADDR这个选项,表明可以多个进程复用bind函数中指定的地址和端口号。
由此可知多个应用(进程),包括同一个应用多次,都是可以绑定到同一个端口进行监听的。对应地C++、NET等高级语言也都提供了对应的接口。
从一些例子也可以看出,比如有时候你在服务器上执行netstat -ano可能会发现同一个应用程序在同一个端口上有多个监听,这是因为一些服务端应用程序可能会异常退出或者没有完全释放套接字,但是需要在重新启动时还能够再次监听同一个端口,所以需要能够具备重复监听同一个端口的能力,因此也出现上述情形。