c - accept() 返回的新连接套接字是否总是绑定(bind)到与监听套接字相同的端口？

Question

我通过创建新连接在我的机器上测试了这个直到失败。在我的机器上，新的 connect()/accept() 请求在接近 700 个套接字连接 (SOCK_STREAM) 时失败*；分别在客户端/服务器上，在环回 IP 地址上。然而，到目前为止，accept() 返回的套接字文件描述符始终绑定(bind)到与监听套接字相同的端口。

我的问题是 - 如果此行为对所有机器都是正确的，那么为什么 accept() 通过创建仅绑定(bind)到与监听套接字相同端口的连接套接字来限制连接？如果新套接字绑定(bind)到随机端口(如 connect() 那样)，服务器可以建立的连接数不能大大增加吗？

此外，为什么 accept(sock_fd, NULL, NULL) 失败并显示 “EFAULT - 地址参数不在用户地址空间的可写部分。”在同一调用的近 700 次成功迭代之后？

同样，为什么 connect() 失败并显示 “EFAULT - 套接字结构地址在用户地址空间之外。” 在相同的近 700 次成功迭代之后打电话？

* EFAULT - 错误地址(在 accept()/connect() 之后)。

Answer 1

当您正在监听时，所有连接在连接的接受端都将具有相同的端口(即最初用作标识符以建立连接的端口)。

如果没有用 bind() 定义，连接部分的本地端口号可以是任何东西。对于本地主机设备，数字可能在某些操作系统上可以非常快速地回收，因为没有真正需要 TCP 的延迟状态。

当涉及到同时拥有许多连接时，可能的连接数量受操作系统中每个进程的资源限制。对于 Unix/Linux，可以调整此限制，如果使用 select()，不建议使 FD 的数量高于默认值，因为 FDSET 的 libc 大小通常与每个进程可用的文件描述符的默认数量相匹配。解决这个问题的一个技巧是创建套接字，派生子对象并让子对象调用 accept()。然后每个 child 可以有很多连接(apache 和 squid 使用这种模型)，增加同一服务器端口上可能的连接总数。