linux - 当 tcp 服务器在执行 accept 之前绑定(bind)并 fork 时会发生什么？哪个进程将处理客户端请求？

Question

在 linux 中，我编写了一个标准的 tcp 服务器(使用 internet 套接字)，但略有不同。这是服务器的骨架

fd=socket(...);
bind(...);
listen(...);
//now do a fork
fork(); 
//this will create two processes bound to the same server listening on the same port !!

clientfd=accept(...);

当客户端通过监听端口连接到服务器时会发生什么。哪个进程将接受连接？

从程序的实际运行来看，父进程( fork 的进程)总是收到客户端请求。我想知道这背后的理论。父进程收到请求只是偶然的吗？

现在我杀死了父进程。所以只有子进程在运行。当客户端尝试连接到同一端口号上的服务器时，子进程(或唯一的幸存者)进程获得了连接。如何解释这种行为？

Answer 1

我刚刚在 Linux 3.4 上测试了这个行为，它的行为方式是内核将在所有调用 accept() 的 child 之间循环。

您可以从以下示例 Python 脚本中看到此行为:

import socket
import os

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
s.bind(('127.0.0.1', 4242))
s.listen(10)
os.fork()
os.fork()
os.fork()
while True:
   conn, addr = s.accept()
   print 'I am %d and I accepted %s' % (os.getpid(), addr)
   conn.close()

这将创建 8 个进程，全部绑定(bind)到端口 4242。然后您可以通过 nc localhost 4242 进行本地连接，并观察接受连接的 PID。

编辑:如果您在更传统的 select 循环中执行此操作，那么所有进程都会被唤醒，并且会在调用 accept() 时发生竞争，除了一个进程之外，所有进程都卡在 accept() 中(这很糟糕，因为它会阻塞选择循环)。