TinyHttpd | TinyHttpd是一个运行于Android上轻量且高效的Http服务器组件

The behavior you observed is a standard socket behavior.

If data received from a peer has not been read by the application and the application calls close on the socket then OS does not do the usual TCP connection finalization. It resets the connection immediately instead finalization. If application really wants gracefully close the connection when there is unread data in the received buffer then it must call shutdown(socket, SHUT_WR) before calling close.

And why is the socket API implemented that way? Because this handling can avoid dos attacks. If close executes normal TCP session finalization then following attack is possible:

• A malicious client opens a TCP connection
• The server accepts the connection and starts receiving data
• The client sends a continuous stream of let say random data
• The server quickly detects that received data is wrong and calls close on the socket.
• close just sends a FIN and then waits for the peer close. Server resources remain allocated because normal FIN just close the direction towards the client. The client still may send data and the recv buffer would not be freed.

But when the close initiates connection reset then resources related to this TCP connection is freed immediately. A dos attack is then a bit more complicated.

See https://www.spinics.net/lists/linux-c-programming/msg01345.html for more details.