TIME_WAIT Is a Promise with a Price
Track 1 promised that every actively-closed connection lingers in TIME_WAIT for TWO_MSL ticks before its port is free again. What does that promise cost when you try to open connections fast?
Open Session 01Protocol in Code · Track
TIME_WAIT, SYN cookies, Nagle/delayed-ACK, and the backlog as connection-lifecycle housekeeping
Sessions
Track 1 promised that every actively-closed connection lingers in TIME_WAIT for TWO_MSL ticks before its port is free again. What does that promise cost when you try to open connections fast?
Open Session 01When the SYN queue is full and the server refuses to remember a half-open connection, how does it still recognize a real client's ACK three steps later?
Open Session 02Nagle's algorithm and delayed ACK are each a reasonable optimization on their own. Run them together against the same write pattern, and where does the 200ms stall actually come from?
Open Session 03If a TCP connection goes silent and neither side sends a FIN or RST, who notices it is dead, and how long does that take?
Open Session 04"The listen backlog" sounds like one number — so why does a single listening socket actually keep two separate queues, and what happens when each one fills up?
Open Session 05None of TIME_WAIT, keepalive, or the backlog is the protocol itself — so what does one object look like whose entire job is running that housekeeping over a scripted day of connection churn?
Open Session 06