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:

1. SYN - Client says "I want to connect"
2. SYN-ACK - Server replies "I'm ready"
3. 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:

1. Your machine sends an ICMP Echo Request to the destination
2. The destination sends back an ICMP Echo Reply
3. 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:

1. Find your server's LAN IP and set it as static via DHCP reservation
2. Access your router admin panel (usually 192.168.1.1 or 192.168.0.1)
3. Find the Port Forwarding / NAT / Virtual Server section
4. Create a rule: external port, internal IP, internal port, protocol
5. 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.

Conclusion

• TCP: choose it when data must arrive complete, ordered, and error-free
• UDP: choose it when speed matters more than perfect delivery
• ICMP: not TCP or UDP - a diagnostic protocol with no ports
• Port forwarding: maps an external router port to an internal IP:port

---

References

Original article: TCP vs UDP Explained - Key Differences, Use Cases & When to Use Each (2026) - DevToolLab
https://devtoollab.com/blog/tcp-vs-udp

DevToolLab Blog: https://devtoollab.com/blog

DevToolLab Tools: https://devtoollab.com/tools