Ports: Directing Traffic to the Right Application
Reading 1 explained how packets travel from one device to another across the Internet. But when packets arrive at their destination, a new question arises: which application on that device should receive them?
A single server might be running a web server, a mail server, a DNS server, and several other applications all at the same time. When a packet arrives, the transport layer needs to know which of these applications is the intended recipient. IP addresses identify the device — but not the application running on it.
The solution is port numbers. A port number is a numeric label appended to a message's address that identifies which application on the destination device should handle it. Think of the IP address as the street address of a building, and the port number as the apartment number — the IP address gets the message to the right building; the port number gets it to the right door inside.
Not to be confused with hardware ports: Port numbers in networking are a software concept — they are numbers in a message header, not physical connectors on a device. This is a different use of the word "port" from the USB and HDMI ports discussed in Topic 2d.
Well-Known Port Numbers
Most users never need to think about port numbers because common Internet
applications use universally agreed-upon port numbers that software handles
automatically. When your browser sees http:// in a URL, it
automatically connects to port 80 on the web server. When it sees
https://, it connects to port 443. These assignments are
standardized so that any browser can connect to any web server without
configuration.
| Port Number | Application / Protocol | Used For |
|---|---|---|
80 |
HTTP | Standard (unencrypted) web traffic |
443 |
HTTPS | Secure (encrypted) web traffic |
25 |
SMTP | Sending email between mail servers |
53 |
DNS | Domain name lookups |
22 |
SSH | Secure remote access to servers |
Port numbers also appear in the URL when a non-standard port is in use. If
you ever see a URL like http://example.com:8080/page.html, the
:8080 is an explicit port number — the server is listening
on port 8080 rather than the default port 80.
TCP and UDP: Two Ways to Send Data
Reading 1 described the transport layer's job: breaking messages into packets and reassembling them at the destination. But there are actually two different transport layer protocols, and they take very different approaches to that job. They are TCP (Transmission Control Protocol) and UDP (User Datagram Protocol).
Together, TCP and IP form the foundation of Internet communication — which is why the Internet's protocol suite is called TCP/IP. But TCP is not the only option. Understanding why both exist requires understanding what each one offers and what it costs.
TCP: Reliable but Careful
TCP is designed around one core commitment: every message will arrive completely and correctly, or the sender will know it did not. TCP achieves this through several mechanisms:
Connection Establishment
Before sending any data, a TCP transport layer contacts the transport layer at the destination and establishes a connection — confirming that the destination is reachable and ready to receive. Only then does it begin sending the actual message. This is called a connection-oriented protocol.
Acknowledgments and Retransmission
As packets arrive, the destination's TCP layer sends acknowledgments back to the sender confirming receipt. If a packet is lost or arrives corrupted and no acknowledgment comes back, the sender retransmits that packet. This continues until every packet has been successfully delivered.
Flow Control and Congestion Control
TCP also manages the rate of transmission. If the destination is receiving data faster than it can process it, TCP slows down the sender to avoid overwhelming it. If the network between sender and destination is congested, TCP reduces its transmission rate to help alleviate the congestion.
All of this makes TCP extremely reliable — but it also adds overhead. Establishing a connection, sending acknowledgments, and handling retransmissions all take time and consume bandwidth. For applications where every byte of data must arrive correctly, that overhead is worth it.
TCP in everyday use: When you load a webpage, send an email, or download a file, TCP is almost certainly involved. These applications need every piece of data to arrive correctly. A missing packet in a webpage would result in broken layout or missing content. A corrupted byte in a downloaded file could make it unusable.
UDP: Fast but Informal
UDP takes the opposite philosophy. It sends packets to the destination address without establishing a connection first, without waiting for acknowledgments, and without retransmitting lost packets. It simply fires the data into the network and moves on. For this reason, UDP is called a connectionless protocol, and it is described as unreliable — not because it is broken, but because it makes no guarantees about delivery.
That sounds like a weakness. In some contexts it is. But for many applications, UDP's lack of overhead is exactly what makes it the right choice.
When UDP Is the Better Choice
Consider a live video call. Video frames arrive at 30 frames per second. If one frame is lost in transit, the worst outcome is a brief glitch. Waiting for TCP to detect the loss, request a retransmission, and receive the retransmitted frame would take far longer than the glitch itself — and by the time the retransmitted frame arrived, it would be too late to use. The conversation has moved on. Dropping the lost frame and continuing is far better than pausing the entire call to recover it.
DNS lookups are another good fit for UDP. A DNS request is a tiny message asking a simple question. The response is equally small. The round trip should take milliseconds. Using TCP's connection establishment handshake for such a brief exchange would double or triple the time required. UDP's "fire and forget" approach is much more efficient — and if a DNS response is lost, the application simply asks again.
TCP vs. UDP: A Summary
| TCP | UDP | |
|---|---|---|
| Connection | Establishes a connection before sending | No connection — just sends |
| Reliability | Guarantees delivery; retransmits lost packets | No guarantees; lost packets are simply lost |
| Speed | Slower due to overhead | Faster — minimal overhead |
| Use when | Every byte must arrive correctly | Speed matters more than perfection |
| Common uses | Webpages, email, file downloads | Video calls, live streaming, DNS lookups, online gaming |
The key insight is that we need both because different applications have different requirements. An email that loses data is useless — use TCP. A video call that pauses to recover lost frames is worse than one that occasionally glitches — use UDP. The Internet's protocol suite provides both options, and applications choose the one that fits their needs.
A useful analogy: TCP is like sending a certified letter — you get a receipt, you know it arrived, and if it did not, you send it again. UDP is like dropping a flyer in a mailbox — fast and easy, but you have no idea whether it was received. For a legal document, you want the certified letter. For a neighborhood announcement, the flyer is fine.
Connecting to Your Classroom
Students who use video conferencing tools daily have lived experience with both protocols in action, even if they do not know it. When a Zoom call glitches briefly and then continues, UDP lost a packet and kept going. When a file download pauses and resumes or restarts after a connection problem, TCP detected a failure and is handling recovery.
Port numbers also surface in classroom technology contexts more than teachers might expect. School network firewalls — which block certain types of traffic — work largely by blocking specific port numbers. When a student cannot connect to a particular service on the school network, the likely explanation is that the firewall is blocking the port that service uses. Understanding ports helps teachers interpret these common frustrations rather than treating them as unexplainable mysteries.