服务端主动关闭，客户端继续写，会发生什么？

1、四次挥手

下图显示了一次典型的TCP四次挥手的过程，以及主动关闭方和被动关闭方的状态变化。在图中是客户端主动断开了连接，这里只是举个例子，服务端一样可以主动断开连接。

为什么是四次挥手，因为如果只进行了1、2次。由于TCP是全双工的，可以处于Half-Close状态，此时就是处于Half-Close状态，客户端到服务器的通道已经关闭，服务器到客户端的通道还没关闭，所以需要第三次和第四次来完全关闭连接。

客户端主动关闭

如果客户端主动关闭连接，那就是正常的关闭了。首先客户端发起关闭连接的请求，服务端收到后，先发送ACK给客户端表示已收到关闭请求，然后客户端到服务端的连接就可以关闭了。此时服务端不会立刻关闭连接，服务端会将还没发完的数据发送到客户端。
此时客户端只是不能向服务端发送数据，但是可以接受数据，这就是TCP的半关闭。此时客户端处于FIN_WAIT2，服务端处于CLOSE_WAIT(如果服务端不关闭连接，将会一直处于该状态，如果连接很多，这将会浪费大量的socket资源)。
服务端在发送完数据后再向客户端发起关闭连接的请求，客户端收到后确认关闭，此时TCP全双工连接就关闭了。

服务端主动关闭

如果是服务端主动发起关闭，此时四次挥手的顺序会颠倒。那么此时客户端再向服务端发送数据时，根据TCP协议的规定，认为它是一个异常终止连接，客户端将会收到一个RST复位响应(而不是ACK响应)，如果客户端再次向服务端发送数据，系统将会发送一个SIGPIPE信号给客户端进程，告诉客户端进程该连接已关闭，不要再写了。系统给SIGPIPE信号的默认处理是直接终止收到该信号的进程，所以此时客户端进程会被极不情愿地终止。
如果不希望客户端进程被终止，可以自定义一个该信号处理的函数，通过调用函数signal(SIGPIPE, handler)实现对信号的处理，其中handler就是可以自定义的函数。
所以说当服务端主动关闭，客户端继续写两次将会导致客户端进程被终止(服务端并不能接收)，客户端不能向服务器写入数据。

链接：https://juejin.cn/post/6844904088501485581