To keep data in order, TCP holds back every packet that arrived after a lost one until the lost packet is received again.
Why One packet goes missing → Effect The packets behind it have arrived but wait in the receive buffer → On screen Everything stops, then releases all at once: fast-forward
Primary owner Game team (Server development) · Also Game team (Client development)
Game team action items
Server: send real-time positions over UDP, use reliable delivery only for what truly needs it, split traffic into multiple streams. Client: change network handling to match the server (UDP, separate channels).
Ballpark numbers
Losing one packet stalls things for at least one round-trip time plus a little more; if the retransmission is lost too, the stall lasts hundreds of ms to several seconds.
On the graph
Gap then burst · Bytes received per connection, retransmissions
Where to look
Retransmitted packets and the gaps around them on that player’s connection in a server-side packet capture (tcpdump, Wireshark); for the whole server, the increase in TcpRetransSegs from nstat -az
Confirmed if
Each stall starts with the retransmission of a single packet, and right after the retransmitted packet arrives, the backlog is processed all at once (bytes received sit at 0, then surge)
Ruled out if
Games that talk over UDP: not applicable. Stalls with no retransmissions: look at the server tick (“Tick overrun”)