非阻塞Socket到达EOF时的阻塞行为及EWOULDBLOCK含义咨询

首先明确结论：完全可能出现你描述的第一种调用序列——即先调用read()返回-1且errno为EWOULDBLOCK或EAGAIN，后续调用read()直接返回0（表示到达EOF）。EWOULDBLOCK/EAGAIN仅表示当前没有数据可读，并不保证后续一定会有新数据到来，当文件描述符再次变为可读时，也可能是触发了EOF条件。

具体场景举例 #

• TCP半关闭场景：对方调用shutdown(SHUT_WR)关闭发送端，但仍保留接收能力。此时如果你的socket当前没有未读取的数据，调用非阻塞read()会返回EWOULDBLOCK/EAGAIN；当对方的FIN包到达你的系统后，socket会变为可读状态，此时调用read()就会返回0，触发EOF。
• 延迟FIN包场景：对方发送完最后一批数据后直接关闭连接，但FIN包因网络延迟暂时未到达。此时你读完现有数据后，调用read()会返回EWOULDBLOCK/EAGAIN；等FIN包到达后，再次调用read()就会返回0。

关于调用序列的误区 #

你提到的第二种调用序列（EWOULDBLOCK → 读到数据 → EOF）并不是“一定”的，它只是一种常见情况，但不是唯一合法的流程。非阻塞socket的read()返回EWOULDBLOCK/EAGAIN仅代表当前无数据，后续的可读事件可能对应新数据，也可能对应EOF。

在处理非阻塞socket时，必须同时处理两种可读情况：读到数据（返回值>0），以及到达EOF（返回值=0），不能假设EWOULDBLOCK/EAGAIN之后必然会有新数据。

内容的提问来源于stack exchange，提问作者user877329