Moksh Gupta

Posted on May 29

TCP vs UDP: Key Differences, Ports, and When to Use Each

#beginners #networking #tutorial

If you've set up a server, debugged a firewall rule, or tried to share a local game with friends, you've run into TCP and UDP. They're the two core transport protocols - but they work in fundamentally different ways. This guide breaks down each protocol, when to use which one, what ICMP ping actually is, and how to set up port forwarding correctly.

TCP vs UDP - The Core Difference

TCP (Transmission Control Protocol) guarantees your data arrives in order, complete, and without errors. It establishes a connection before sending anything and retransmits lost packets automatically.

UDP (User Datagram Protocol) is a fire-and-forget protocol. It sends packets as fast as possible without confirming they arrived - trading reliability for raw speed.

Key differences at a glance:

TCP requires a 3-way handshake; UDP has no connection setup
TCP retransmits lost packets; UDP does not
TCP ensures ordered delivery; UDP packets may arrive out of order
TCP has flow and congestion control; UDP has neither
TCP header is 20-60 bytes; UDP header is a fixed 8 bytes
UDP supports broadcast and multicast; TCP does not

How TCP Works - The 3-Way Handshake

Before TCP sends a single byte, it establishes a connection:

SYN - Client says "I want to connect"
SYN-ACK - Server replies "I'm ready"
ACK - Client confirms "Let's go"

After this, every packet gets an acknowledgement. If an ACK doesn't arrive in time, TCP retransmits. This is why TCP is reliable but adds overhead - and why lost packets create delays.

Closing a TCP connection is a 4-step process (FIN, ACK, FIN, ACK) to ensure both sides finish sending data before disconnecting.

How UDP Works - Fire and Forget

UDP skips the handshake entirely. It wraps your data in a tiny 8-byte header and sends it - no connection state, no acknowledgements, no retransmission.

Why use an "unreliable" protocol? Because the application handles reliability itself, or simply doesn't need it:

Video streaming: a dropped frame is better than a half-second freeze
Online gaming: stale position data from 200ms ago is useless anyway
DNS lookups: a single small packet - if it drops, just re-send it
VoIP: a dropped 20ms audio slice sounds like a slight crackle, not a pause

Which Protocol Should You Use?

Use TCP when:

Data integrity is critical (HTTP/HTTPS, databases, file transfers, email)
You need confirmation that data arrived (API calls, authentication)
Packets must arrive in order (loading a web page, reading a file)

Use UDP when:

Speed matters more than perfection (live video, VoIP, gaming)
You can tolerate some packet loss
You're sending small, frequent messages (DNS, DHCP, IoT sensors)
You need broadcast or multicast (service discovery, mDNS)
You're building a custom transport (QUIC, used by HTTP/3, builds reliability on top of UDP)

ICMP - The Ping Protocol (No Ports)

One of the most common networking misconceptions: ping does not use a port number.

Ping uses ICMP - Internet Control Message Protocol - a Layer 3 protocol separate from TCP and UDP. ICMP has no concept of ports because it's a diagnostic protocol, not a transport protocol.

How ping works:

Your machine sends an ICMP Echo Request to the destination
The destination sends back an ICMP Echo Reply
Your machine measures the round-trip time

When developers say "ping port 80," they actually mean test a TCP connection to port 80. The right tools for testing specific ports are nc, telnet, or curl.

traceroute (Linux/Mac) and tracert (Windows) also use ICMP - they reveal each hop's IP and latency by sending packets with incrementally increasing TTL values.

If ping fails, don't assume the server is down. Firewalls commonly block ICMP. Use a TCP-based check instead.

Well-Known Ports Reference

Ports fall into three ranges:

Well-Known (0-1023): Assigned by IANA, require root/admin to bind
Registered (1024-49151): Assigned to specific apps, no root required
Dynamic/Ephemeral (49152-65535): Temporary client ports

Common ports every developer should know:

22 TCP - SSH
53 TCP/UDP - DNS
80 TCP - HTTP
443 TCP - HTTPS
3306 TCP - MySQL
5432 TCP - PostgreSQL
6379 TCP - Redis
27017 TCP - MongoDB
3000 TCP - React/Next.js/Node.js dev server
5173 TCP - Vite dev server
8000 TCP - Django/FastAPI
9200 TCP - Elasticsearch

Port Forwarding

Port forwarding lets you expose a server inside your local network to the public internet. Without it, your router's NAT blocks all incoming connections.

Your router has one public IP but assigns private IPs to your devices. Outbound connections work fine, but for incoming connections, the router needs a forwarding rule telling it which device to send traffic to.

Basic steps:

Find your server's LAN IP and set it as static via DHCP reservation
Access your router admin panel (usually 192.168.1.1 or 192.168.0.1)
Find the Port Forwarding / NAT / Virtual Server section
Create a rule: external port, internal IP, internal port, protocol
Test from outside your network (mobile data, not the same Wi-Fi)

Common problems:

Server bound to 127.0.0.1 instead of 0.0.0.0 - won't accept external traffic
Server-side firewall blocking the port even after router forwarding
ISP blocking ports 80/443 on residential lines - try port 8080
CGNAT making port forwarding impossible - use Cloudflare Tunnel or ngrok instead

TCP vs UDP in Real Applications

HTTP/1.1 and HTTP/2 use TCP. HTTP/3 uses QUIC over UDP, avoiding TCP's head-of-line blocking for significantly faster modern web apps.

DNS uses UDP port 53 for most queries but falls back to TCP for large responses and zone transfers.

Online games use UDP for game state updates - a dropped packet means a slightly stale frame, which is fine. A retransmitted packet would cause unplayable lag. They use TCP separately for reliable data like match results and auth.

VoIP apps use UDP for real-time audio. A dropped 20ms slice causes a slight crackle. TCP retransmission would cause jarring pauses.

WebSockets run over TCP and are ideal for chat, live dashboards, and collaborative editing.

Security Considerations

TCP SYN Flood: Attackers send thousands of SYN packets without completing the handshake, filling the server's connection table. Mitigations: SYN cookies, rate limiting.

UDP Amplification Attacks: Attackers spoof the source IP in small UDP requests to DNS/NTP servers, which send much larger responses to the victim. Mitigations: rate limiting, BCP38 validation.

Port scanning is standard for security auditing. Keep only necessary ports open and firewall everything else.