I recall it blew my fiancée’s mind that I could unplug her ethernet cable, move it around an obstacle, plug it back in and all her connections were still alive. It’s designed to have bombs dropped on it.
Depends on OS settings these days. Lots of OSes want to help and detect link down and reset all your connections. Kind of a pain when you just want to move a cable.
.. on Linux. If you do that on Windows the MAC will detect the loss of link pulses, report the interface as down, and Windows will "helpfully" reset all your TCP connections.
I remember there was a (now rather obscure) patch floating around in the days of Win9x/2K that gave you the Linux behaviour, with an associated option to extend the timeout to very large values.
It's a tradeoff between robustness to transient errors and reporting errors quickly. "Most errors are transient" is a widely applicable rule of thumb. But both approaches have merit.
With timeouts. You can’t unplug it for an hour and have this happen. But a few seconds is exactly what this is designed for. As another commenter pointed out, your OS could also try to be “helpful”.
If packets were sent while you were disconnected, they'll be gone, but if you're disconnected for only part of the burst, duplicate ACKing will trigger retransmits.
If you were gone for the whole burst, you'll get put right by timer based retransmits.
If you're gone for long enough, most peers will timeout on unacknowledged data (although that's not in the TCP RFC), and if there's no outstanding data, most peers eventually have some sort of periodic ping and timeout (tcp keep-alives is a reasonable fallback IMHO, if your application protocol doesn't have someything, although the default of IIRC 2 hours feels long in todays world of lots of NATs and much shorter timeouts).
It may be your local gateway. Seeing no packets from your host. Attempting to refresh your MAC address via ARP. Getting no response. Generating an ICMP message as a result.
