The design splits the job. IP gets a packet from one address to another across any number of networks, by whatever route the routers along the way choose, and makes no promise that it arrives, arrives once, or arrives in order. That is not a weakness; it is what lets the internet survive a failed link by sending the next packet another way. TCP, running on the two end machines, turns that into what applications want: it numbers the bytes, acknowledges what arrived, retransmits what did not, slows down when the network is congested, and presents the receiver with an ordered stream that looks like a pipe. UDP skips all of it and hands the application raw packets, which is exactly right when a late packet is worth less than a fast one.
| Property | TCP | UDP |
|---|---|---|
| Connection | Set up with a three-step handshake, torn down explicitly | None; packets are sent |
| Delivery | Guaranteed, in order, without duplicates | Whatever arrives, in whatever order |
| Cost | Handshake latency, acknowledgements, retransmission delay | Almost none |
| Congestion | Backs off when packets are lost | Sends regardless; the application must cope |
| Used by | Web pages, email, file transfer, anything that must be complete | Voice and video calls, games, DNS lookups, anything where late costs more than lost |
Port numbers are how one machine offers many services: the address gets the packet to the host, the port gets it to the process, and the well-known ports are conventions rather than rules, which is why a web server can listen on any port it likes and why firewalls that filter by port alone are fooled by anything that borrows a common one. The exams live here. The vendor-neutral networking paper asks which protocol a described application should use and why; the entry security paper asks which ports a service uses and what an attacker learns from an open one; the Cisco associate exam asks you to read a capture and say what the handshake reveals about a failed connection.