IP, TCP, and UDP

Every message you send online gets chopped into packets, small chunks of data that can travel independently and even take different routes to the same destination. IP, the Internet Protocol, handles addressing: it stamps each packet with where it came from and where it is going, then lets routers pass it along, hop by hop, toward that destination. IP does not care about order or loss. It just gets packets moving.

TCP builds reliability on top of that. It numbers every packet before sending, so the receiving end can put them back in order even if they arrive scrambled. If a packet never shows up, the receiver notices a gap in the numbering and the sender resends that missing piece. This back-and-forth of acknowledgments is why a file download always arrives byte-for-byte complete, even if it takes longer. UDP skips all of that. It sends packets with no numbering checks and no resending, which makes it faster and lighter, but it means dropped packets just stay dropped.

That tradeoff explains why a video call rides on UDP while a file transfer rides on TCP. A call that paused every time one packet got lost would be unusable; a little static or a skipped frame is better than constant freezing. A downloaded file with missing bytes, though, is just broken. Neither protocol is a wire or a chip. Both are rules that software follows, running on top of whatever hardware carries the actual signal.