tcp - 当我们说 "listen to a port"时会发生什么？

Question

当我们启动一个服务器应用程序时，我们总是需要指定它监听的端口号。但是这种“监听机制”是如何在幕后实现的呢？

我现在的想象是这样的:

操作系统将端口号与某个缓冲区相关联。服务器应用程序的职责是监视这个缓冲区。如果此缓冲区中没有数据，则服务器应用程序的监听操作将只是 区块应用程序。

当一些数据从线路到达时，操作系统将 知道 然后检查数据，看看它是否针对这个端口号。然后它将填充 对应 缓冲。然后操作系统将通知被阻止的服务器应用程序，服务器应用程序将获取数据并继续运行。

问题是:

如果上述情况是正确的，操作系统如何知道 有来自电线的数据吗？它不可能是繁忙的投票。它是某种基于中断的机制吗？

如果到达的数据太多，缓冲区不够大，会不会有数据丢失？

“监听端口”操作真的是阻塞操作吗？

非常感谢。

Answer 1

虽然其他答案似乎正确解释了事情，但让我给出一个更直接的答案:您的想象力是错误的。

没有应用程序监视的缓冲区。相反，应用程序会在某个时刻调用 listen()，操作系统会从那时起记住该应用程序对该端口号的新连接感兴趣。任何时候只有一个应用程序可以表明对某个端口的兴趣。

监听操作不会阻塞。相反，它会立即返回。可能阻塞的是 accept() .系统积压了传入连接(缓冲已接收的数据)，并在每次调用 accept 时返回其中一个连接。 accept 不传输任何数据；然后应用程序必须对接受的套接字执行 recv() 调用。

至于你的问题:

正如其他人所说:硬件中断。 NIC 将数据报完全断开，中断并在内存中分配一个地址以将其复制到。

对于 TCP，不会有数据丢失，因为在通信过程中总是有足够的内存。 TCP 有流量控制，发送方会在接收方没有更多内存之前停止发送。对于 UDP 和新的 TCP 连接，可能会丢失数据；发送者通常会得到一个错误指示(因为系统保留内存只接受一个数据报)。

见上:listen 本身不会阻塞；接受是。