TCP vs UDP and when to use each

Topic: Networking basics

TCP is connection-oriented and reliable; UDP is connectionless and low-overhead. Learn the trade-offs so you can choose the right transport, debug timeouts vs packet loss, and configure firewalls and services correctly. Use this when designing or troubleshooting protocols and ports.

Intent: How-to

Quick answer

  • TCP: connection-oriented, reliable delivery, in-order, flow control, and congestion control; use for HTTP, SSH, database connections, and anything that must not lose data.
  • UDP: no connection, no delivery guarantee, no order guarantee; use for DNS, real-time voice/video, and when low latency matters more than reliability.
  • Firewalls and NAT often treat TCP and UDP separately; open or allow both when a service uses both (e.g. DNS can use TCP for large responses).

Steps

  1. Understand TCP guarantees

    TCP establishes a connection (three-way handshake), retransmits lost segments, reorders at the receiver, and uses flow and congestion control. Applications see a reliable byte stream.

  2. Understand UDP behavior

    UDP sends datagrams with no connection setup; no retransmission or ordering. Packets can be lost, duplicated, or reordered; the application must handle that if needed.

  3. Choose by application needs

    Need reliability and order (file transfer, SSH, HTTP)? Use TCP. Need low latency and can tolerate loss (DNS, gaming, streaming)? Prefer UDP when the protocol allows.

  4. Apply to operations

    When opening a port or allowing traffic, specify TCP or UDP (or both); many services use one only (e.g. SSH is TCP 22); DNS uses UDP 53 by default and TCP for large replies.

Summary

TCP provides a reliable, ordered byte stream over a connection; UDP provides minimal, connectionless datagram delivery. Choosing the right one affects reliability, latency, and how you configure firewalls and NAT. Use this when designing services or troubleshooting connectivity and timeouts.

Prerequisites

  • None; this is a foundation concept.

Steps

Step 1: Understand TCP guarantees

TCP uses a three-way handshake to establish a connection. It assigns sequence numbers, retransmits lost segments, and delivers data in order to the application. Flow control and congestion control limit send rate to match the receiver and network. The result is a reliable, in-order byte stream.

Step 2: Understand UDP behavior

UDP has no connection state: each datagram is independent. There is no retransmission, no ordering guarantee, and no flow or congestion control. Packets can be lost, duplicated, or reordered; the application or higher-layer protocol (e.g. DNS retries, QUIC) must cope.

Step 3: Choose by application needs

  • TCP: HTTP/HTTPS, SSH, TLS, database protocols, file transfer—whenever data must not be lost and order matters.
  • UDP: DNS (primary), real-time media, gaming, some streaming—when latency matters and the app or protocol handles loss.

Step 4: Apply to operations

When you allow or open a port, specify TCP, UDP, or both. Example: SSH is TCP 22 only; DNS is usually UDP 53 and sometimes TCP 53. Firewall and NAT rules often treat TCP and UDP separately.

Verification

  • You can state the main difference (reliable connection vs best-effort datagrams) and name at least two protocols that use TCP and two that use UDP.

Troubleshooting

Connection timeout — Often TCP: handshake or segment loss; check path, firewall (both directions), and NAT; ensure the service is listening and reachable.

UDP “not working” — UDP has no built-in feedback; use application-level checks or packet capture to confirm packets are sent and received; firewall must allow UDP for that port.

Next steps

Continue to