linux - 套接字、TCP 状态和写入系统调用

Question

我一直在使用一个简单的服务器，它每 30 秒向客户端发送一个心跳数据包，然后客户端使用心跳回复数据包确认心跳。当我通过发送 SIGKILL、SIGSEGV 粗暴地终止服务器时，客户端很容易通过 select() 和 read() 系统调用发现了这一点。然后我开始想知道当你在客户端写入心跳回复数据包之前这样做会发生什么，所以我在客户端代码中休眠了 20 秒并同时终止了服务器，但发现客户端写入仍然成功。之后立即尝试第二次写入会触发预期的 SIGPIPE 信号并写入返回的 EPIPE。据我所知，这是正常行为，但是，出于好奇，我打印了客户端 tcp 状态。结果是:

1. TCP_ESTABLISHED - 在发送服务器 SIGKILL 之前。
2. TCP_CLOSE_WAIT - 在第一次客户端写入之前的服务器端 SIGKILL 之后。
3. TCP_CLOSE - 在第一次和第二次写入尝试之后。

所以我的问题是:

1. 为什么第一次写入不引发 SIGPIPE 并返回 EPIPE？
2. 我能否得出结论:如果在第一次写入后 TCP 状态为 TCP_CLOSE，则表明与服务器的连接已断开，或者我是否必须再次发送数据才能确定？

根据我的理解，目前正在发生的事情的图表:

                       server                               client

          [ESTABLISHED]  |                                     | [ESTABLISHED] 
 SIGKILL or close () --> |                                     |  
          [FIN_WAIT_1]   |------------FIN M------------------->| [CLOSE_WAIT] 
                         |                                     |            ---\
          [FIN_WAIT_2]   |<-----------ACK M+1------------------|               |  
                         |                                     |               |   a read performed after a
          [TIME_WAIT]    |<-----------FIN N--------------------| [LAST_ACK?]   |-- serverside SIGKILL returns 0
                         |                                     |               |   but write succeeds
                         |------------ACK N+1----------------->| [CLOSE]       |
                         |                                     |            ---/
                         |                                     | 
                         |                                     |            ---\
                         |                                     | [CLOSE]       |   After the first write returns
                         |                                     |               |   the TCP/IP state is CLOSED 
                         |                                     | [CLOSE]       |   but even so only the a second 
                         |                                     |               |   returns EPIPE and raises SIGPIPE.
                         |                                     | [CLOSE]       |   
                         |                                     |               v 

Answer 1

Why does the first write not raise SIGPIPE and return EPIPE?

TCP 是异步的。您的 write 仅将数据复制到套接字缓冲区并返回。 TCP 栈在后台接管并发送数据。也就是说，当send/sendmsg/write返回时，并不代表数据已经发送完毕。

当服务器被终止时，内核会为您关闭套接字，发送未完成的数据，然后发送FIN，这会将您的客户端套接字置于TCP_CLOSE_WAIT 状态。它是半开连接状态，客户端仍然可以发送数据，前提是服务器需要它。

您的客户端发送更多数据，但服务器操作系统以 RST 响应，因为没有处理传入数据的进程。这会将您的客户端套接字放入 TCP_CLOSE。

can I conclude that if the TCP state is TCP_CLOSE after the first write that the connection to the server is down or do I have to resend the data one more time to be sure?

TCP_CLOSE 是最终的 TCP 状态。不确定您到底在问什么，但是如果您需要确保其他对等点接收并处理了您的数据，则需要发回一些应用程序级消息。