EMZETT.RST
In short: A TCP flag that aborts a connection immediately and irrevocably — unlike an orderly teardown via FIN, with no regard for data still outstanding.
In more detail: An RST is typically sent when a packet arrives for a connection that doesn’t exist (any more) on the recipient’s side — e.g. because no service is listening on the addressed port, or because the connection has already been dropped by a firewall or a crash. Unlike an orderly FIN teardown, data not yet sent or not yet acknowledged is silently discarded.
In Depth
Typical situations in which an RST occurs:
- Closed port: a client tries to establish a TCP connection to a port on which no service is listening — the target computer answers immediately with RST instead of
SYN-ACK. Port scanners such as Nmap use exactly this behaviour to distinguish closed from filtered ports: an RST means “port closed, but reachable”, while a packet that never comes back points more to a firewall dropping the traffic completely. - Connection aborted after an error: a server process crashes or is terminated while there are still active connections — the operating system then sends RST to all affected clients instead of leaving the connections “hanging”.
- Firewalls/reset injection: some firewalls or network filters actively terminate unwanted data traffic with a forged RST instead of just silently dropping packets — which immediately signals “connection ended” to the client instead of an unclear timeout.
From the application’s point of view, a received RST usually shows up as an error such as ECONNRESET (“connection reset by peer”) — a common, often hard-to-debug problem in network applications, especially when a counterpart unilaterally cuts connections via RST after a certain idle time without the other side expecting it.
$ curl https://example.local
curl: (56) Recv failure: Connection reset by peer