Understanding TCP and UDP
A TCP port and a UDP port with the same number are two separate endpoints, because a port number is only meaningful when paired with a protocol. TCP (Transmission Control Protocol, RFC 9293, which supersedes the classic RFC 793) is connection-oriented and reliable: it opens a connection with a three-way handshake, guarantees that every byte arrives once and in order, and retransmits anything that gets lost. UDP (User Datagram Protocol, RFC 768) is connectionless and fast: it fires datagrams with no handshake, no acknowledgments, and no delivery guarantee. So "TCP 53" and "UDP 53" are handled by different parts of the operating system's network stack — which is exactly how DNS uses UDP 53 for lookups and TCP 53 for zone transfers at the same time.
That's the summary an AI Overview gives you. Here is what it can't show you: the actual packet choreography that makes TCP "reliable" and UDP "fast," a decision matrix that tells you which protocol to pick for a specific workload, the exact firewall trap that breaks HTTP/3, and the commands to prove which protocol a port is really using. The diagram below animates the difference — three packets of setup before TCP sends any data, versus UDP shouting into the void.
The port number alone doesn't determine protocol. TCP port 80 (HTTP) is different from UDP port 80. A service listening on TCP port 3306 (MySQL) is different from a hypothetical service on UDP port 3306.
TCP: Reliable Connection-Oriented Communication
TCP establishes a connection between two endpoints before data exchange. This connection-oriented approach ensures reliability:
Three-Way Handshake: Before data transmission, TCP performs a handshake:
- Client sends SYN (synchronization request)
- Server responds with SYN-ACK
- Client sends ACK (acknowledgment)
This handshake establishes the connection.
Guaranteed Delivery: TCP ensures packets arrive in order and without loss. If packets are dropped, TCP resends them. If packets arrive out of order, TCP reorders them.
Flow Control: TCP manages transmission speed based on receiver capacity. If the receiver can't process data quickly, TCP slows transmission.
Error Detection: TCP includes checksums ensuring data integrity. Corrupted packets are detected and retransmitted.
Connection Closure: TCP provides orderly connection termination, ensuring both endpoints know the connection is complete.
This reliability comes at a cost: TCP has overhead from handshakes, acknowledgments, and error detection.
UDP: Fast Connectionless Communication
UDP sends data without establishing a connection. Datagrams are sent immediately without handshakes or connection tracking.
No Handshake: UDP immediately sends data without connection establishment.
Best-Effort Delivery: UDP makes no guarantee that packets arrive, arrive in order, or arrive without duplication. This is acceptable for applications tolerating occasional loss.
No Flow Control: UDP sends data at the application's desired rate regardless of receiver capacity.
Minimal Overhead: UDP has minimal header information and no connection management, making it faster than TCP.
Fire and Forget: UDP sends data and doesn't track delivery or retransmission.
This simplicity makes UDP fast but unreliable—appropriate for applications where speed matters more than perfection.
Key Differences at a Glance
| Characteristic | TCP | UDP |
|---|---|---|
| Connection | Established (connection-oriented) | Not established (connectionless) |
| Reliability | Guaranteed delivery, in-order | Best-effort, no guarantees |
| Speed | Slower due to overhead | Faster, minimal overhead |
| Ordering | Packets arrive in order | No ordering guarantee |
| Handshake | 3-way handshake required | No handshake |
| Error Checking | Comprehensive | Basic |
| Flow Control | Yes | No |
| Broadcasting | No | Yes (also multicast) |
| Header size | 20 bytes minimum (up to 60) | 8 bytes fixed |
| Specification | RFC 9293 (obsoletes RFC 793) | RFC 768 |
Decision Matrix: Which Should You Use?
The comparison table tells you how they differ; this matrix tells you which to pick. Match your workload's dominant requirement to the recommended protocol.
| If your workload… | Loss tolerance | Latency need | Use | Why |
|---|---|---|---|---|
| Serves web pages / APIs (HTTP/HTTPS) | Zero | Medium | TCP (or QUIC/HTTP-3 over UDP) | Content must arrive complete and in order |
| Transfers files (FTP/SFTP/SMB) | Zero | Low | TCP | A single missing byte corrupts the file |
| Sends email (SMTP/IMAP/POP3) | Zero | Low | TCP | Messages can't be lost or reordered |
| Runs remote shells (SSH/RDP) | Zero | Medium | TCP | Keystrokes and output must stay ordered |
| Handles payments / database writes | Zero | Medium | TCP | Correctness is non-negotiable |
| Streams live video/audio | High | Very high | UDP | A dropped frame beats a stalled buffer |
| Carries voice / VoIP | High | Very high | UDP | Retransmitted audio arrives too late to use |
| Runs real-time multiplayer games | High | Very high | UDP | Fresh state matters more than old-but-complete state |
| Resolves names (DNS) | Medium | High | UDP first, TCP fallback | Small queries fit one datagram; large answers/zone transfers use TCP |
| Discovers hosts / assigns IPs (DHCP, mDNS) | Medium | High | UDP | Broadcast/multicast needs UDP; retries handle loss |
| Needs UDP speed and reliability | Zero | Very high | QUIC (UDP-based) | Rebuilds TCP guarantees on UDP with faster setup |
Rule of thumb: default to TCP. Reach for UDP only when late data is worthless — real-time media and games — or when the protocol design already expects loss and retries (DNS, DHCP, NTP).
TCP Applications: When Reliability Matters
TCP is appropriate when data accuracy and order matter more than speed:
Email (SMTP/POP3/IMAP): You can't afford to lose email messages or have them arrive out of order.
File Transfer (FTP/SFTP): File corruption from missing packets is unacceptable.
Web Traffic (HTTP/HTTPS): Web content must be transmitted accurately and completely.
SSH: Secure shell sessions require reliable, ordered communication.
Database Connections: Database queries must be executed accurately without data loss.
Instant Messaging: While individual messages might tolerate occasional loss, users expect messages to arrive reliably.
Banking/Financial: Financial transactions absolutely require reliability.
UDP Applications: When Speed Matters
UDP is appropriate when speed is critical and occasional loss is acceptable:
Video Streaming: Modern video streaming uses UDP. Losing one frame in a video stream is acceptable; the video continues smoothly. Waiting for TCP retransmissions would cause buffering.
Audio Streaming: Similar to video, losing occasional audio packets is acceptable for real-time communication. The slight audio glitch is preferable to TCP delays.
Online Gaming: Games prioritize real-time responsiveness. Occasional packet loss (slightly jerky player movements) is preferable to TCP latency.
Voice over IP (VoIP): Real-time voice communication needs minimal latency. Losing one voice packet affects quality minimally.
DNS Queries: DNS lookups are typically done over UDP for speed. If a query is lost, the client retries.
Network Time Protocol (NTP): Time synchronization can tolerate occasional loss.
DHCP: Dynamic host configuration can use UDP for speed.
Port Number Overlap
The same port number can be used by both TCP and UDP simultaneously for different purposes:
-
Port 53: Used for DNS over both TCP and UDP
- UDP 53: Primary DNS queries
- TCP 53: DNS zone transfers, larger queries
-
Port 80: Primarily TCP for HTTP, but theoretically UDP could use it
-
Port 3306: MySQL primarily uses TCP, but UDP could theoretically use it
Understanding the protocol (TCP vs. UDP) is as important as understanding the port number. Our port reference tool lists which protocol each well-known port actually uses, so you can confirm whether a service expects TCP, UDP, or both before you write a firewall rule.
Network Configuration and Firewalls
Firewalls must configure TCP and UDP ports separately:
Allow TCP on port 443 (HTTPS)
Allow UDP on port 53 (DNS)
Block everything else
A firewall rule allowing TCP port 443 doesn't automatically allow UDP port 443. Administrators must configure each protocol separately.
The modern gotcha — QUIC and HTTP/3: HTTP/3 runs over QUIC, which uses UDP port 443, not TCP. If your firewall or proxy allows only TCP 443, QUIC connections fail silently and browsers fall back to TCP-based HTTP/2. That fallback usually works, so the misconfiguration hides in plain sight — you just lose HTTP/3's faster connection setup and better loss recovery. If you want HTTP/3, add an explicit UDP 443 allow rule; if you want to block it (some enterprises do, to keep traffic inspectable), block UDP 443 and clients will cleanly fall back to TCP.
Performance Implications
TCP overhead: Connection management, handshakes, and acknowledgments add latency. A TCP connection typically involves 3 packets just for handshake before data transmission.
UDP efficiency: UDP sends data immediately with minimal overhead, enabling lower latency.
Bandwidth: TCP acknowledgments consume bandwidth. UDP avoids this overhead.
For latency-sensitive applications (gaming, video calls), UDP's lower overhead significantly improves user experience.
Hybrid Approaches
Modern applications sometimes use both TCP and UDP:
- Video streaming: Primary data over UDP (video), control information over TCP
- Gaming: Game state over UDP (speed), login/authentication over TCP (reliability)
- QUIC protocol: Modern protocol using UDP for speed while providing TCP-like reliability
This hybrid approach captures benefits of both protocols.
Protocol Selection Considerations
When choosing between TCP and UDP, consider:
Data Criticality: Will data loss cause problems? If yes, TCP. If occasional loss is acceptable, UDP.
Latency Sensitivity: Is real-time delivery critical? If yes, UDP. If slight delays are acceptable, TCP.
Ordering: Is packet order critical? If yes, TCP. If not, UDP.
Broadcasting: Do you need to send to multiple recipients? UDP supports broadcasting; TCP doesn't.
Simplicity: Is protocol simplicity important? UDP is simpler; TCP is more complex.
Existing Protocols: Some protocols (HTTP requires TCP, DNS primarily uses UDP) have established protocol defaults.
Troubleshooting TCP vs. UDP
List TCP and UDP listeners (Linux — ss is the modern replacement for netstat):
ss -tuln
The t flag shows TCP listeners, u shows UDP listeners, l limits to listening sockets, and n skips DNS resolution for speed. The older netstat -tuln produces equivalent output.
Checking a specific port's protocol:
ss -tuln | grep :443
Shows whether port 443 is bound by TCP, UDP, or both. On Windows, use netstat -ano -p tcp and netstat -ano -p udp separately.
TCPdump capturing traffic:
tcpdump -i eth0 -n udp port 53
Captures DNS traffic over UDP.
Understanding which protocol a connection uses helps troubleshoot connectivity and performance issues.
Modern Developments
QUIC: A new protocol running over UDP but providing TCP-like reliability and ordering. It's becoming standard for modern web applications.
DNS-over-HTTPS: DNS queries increasingly use HTTPS (TCP) instead of UDP for privacy and security.
Modern gaming: Games increasingly use proprietary UDP-based protocols optimized for real-time communication.
Conclusion
TCP and UDP are fundamentally different protocols serving different purposes. TCP provides reliable, ordered, connection-oriented communication at the cost of added overhead. UDP provides fast, connectionless communication at the cost of reliability. TCP is appropriate for applications where data accuracy matters (email, file transfer, web, banking). UDP is appropriate for real-time applications where speed matters more than perfection (video, audio, gaming, DNS). Many modern applications use both, selecting the protocol appropriate for each type of communication. Understanding the differences enables proper network configuration, troubleshooting, and application design.