IP (Internet Protocol) guarantees absolutely nothing. Packets can be duplicated, delayed, delivered out of order, or simply dropped entirely. TCP's primary job is to create the illusion of a perfect, orderly byte stream on top of this chaos.
To do this, TCP assigns a Sequence Number to every single byte of data it sends. If you send a 100-byte packet starting at Sequence Number 1000, the packet covers bytes 1000 to 1099.
When the receiver gets that packet, it doesn't say "I got packet 1". Instead, it sends an ACK (Acknowledgment) with the number 1100. This means: "I have successfully received all bytes up to 1099. I am expecting byte 1100 next."
Because ACKs are cumulative, if a sender transmits 3 packets and only the ACK for the 3rd one arrives, the sender knows all 3 packets arrived safely. But what happens if a packet is lost?
Click "Send Data" to transmit 100 bytes. Try clicking "Drop Next Packet". Notice how the sender keeps a copy of the unacknowledged data in memory and starts a Retransmission Timeout (RTO) timer. When the timer expires without an ACK, it resends.
The time the sender waits before retransmitting (the RTO) is dynamically calculated. If the network is generally fast, the RTO is short. If the network is slow, the RTO is long. If a packet is lost, the sender retransmits and doubles the RTO for the next try. This exponential backoff prevents the sender from spamming an already overwhelmed network.
If you send packet 1 (bytes 0-99) and packet 2 (bytes 100-199), and packet 1 is delayed while packet 2 arrives first, what does the receiver do?
The receiver buffers packet 2 in memory but cannot hand it to the application yet, because the application expects a perfect stream. It also replies with an ACK for byte 0: because that's still the next byte it expects in contiguous order. Once packet 1 finally arrives, the receiver can immediately ACK 200, acknowledging both packets at once.