Return to Answer

On every packet we receive after the lost packet, we'll send a DupAck, and after the 3rd DupAck the sender will retransmit the lost packet. So the time TCP requires to initiate the retransmit is 3 packets, plus the time it takes for the last DupAck to arrive at the sender. Then we need to wait for the retransmission to arrive, so in total we wait 3 packets + 1 roundtrip latency. The roundtrip latency is typically 0-1 ms on a local network and 50-200 ms on the internet. 3 packets will typically arrive in 25 ms if we send 120 packets per second, and in 150ms if we send 20 packets per second.

On every packet we receive after the lost packet, we'll send a DupAck, and after the 3rd DupAck the sender will retransmit the lost packet. So the time TCP requires to initiate the retransmit is 3 packets, plus the time it takes for the last DupAck to arrive at the sender. Then we need to wait for the retransmission to arrive, so in total we wait 3 packets + 1 roundtrip latency. The roundtrip latency is typically 0-1 ms on a local network and 50-200 ms on the internet. 3 packets will typically arrive in 25 ms if we send 120 packets per second, and in 150ms if we send 20 packets per second.

With TCP things get messier if we also need to consider Nagle (if the developer forgets to turn off send coalescing, or can't disable delayed ACK), network congestion avoidance, or if packet loss is bad enough that we have to account for multiple packet losses (including lost Ack and DupAck). With UDP we can easily write faster code because we quite simply don't care about being a good network citizen like TCP does.

With TCP things get messier if we also need to consider Nagle (if the developer forgets to turn off send coalescing, or can't disable delayed ACK), network congestion avoidance, or if packet loss is bad enough that we have to account for multiple packet losses (including lost Ack and DupAck). With UDP we can easily write faster code because we quite simply don't care about being a good network citizen like TCP does.

If you send 2 updates on TCP, and a packet of the first update gets lost, you will not see the second update until:

It doesn't matter how fast this is done in TCP, because with UDP you simply discard the first update and use the second, newer one, right now.

TCP creates an abstraction in which all network packets arrive, and they arrive in the exact order in which they were sent. To implement such an abstraction on a lossy channel, it must implement retransmissions and timeouts, which consume time. If you send 2 updates on TCP, and a packet of the first update gets lost, you will not see the second update until:

It doesn't matter how fast this is done in TCP, because with UDP you simply discard the first update and use the second, newer one, right now. Unlike TCP, UDP does not guarantee that all packets arrive and it does not guarantee that they arrive in order.