Free lesson · Computer Networking

Tcp Vs Udp When To Choose Which

Easy10 min readnetworkingcomputer-networkstcp-ip

The Most Important Transport Layer Decision

In every System Design interview that involves network communication - which is nearly all of them - you will make a transport protocol choice, whether explicitly or implicitly. When you say "the client sends an HTTP request to the server," you have chosen TCP. When you say "the video stream uses RTP," you have chosen UDP. Making this choice deliberately, with articulated reasoning, demonstrates a depth of understanding that separates strong candidates from adequate ones.

This topic provides a structured decision framework for choosing between TCP and UDP. The framework is not about memorizing rules - it is about understanding the trade-offs well enough to reason through any scenario an interviewer presents.

The Core Trade-Off

TCP and UDP sit on opposite ends of a single spectrum:

TCP optimizes for correctness. Every byte arrives, in order, verified. The cost is latency (handshake, retransmission delays), overhead (20+ byte headers, per-connection state), and inflexibility (the application cannot control what gets retransmitted or how ordering is enforced).

UDP optimizes for speed and control. Datagrams are sent immediately with minimal overhead. The cost is that the application must handle (or explicitly accept) packet loss, reordering, and congestion. UDP gives the application full control - and full responsibility.

The decision comes down to a single question: what happens when a packet is lost?

• If a lost packet means corrupted data that the application cannot recover from → TCP
• If a lost packet means slightly degraded experience that the application can tolerate → UDP
• If a lost packet means stale data that has already been superseded by newer data → UDP

The Decision Framework

When evaluating which protocol to use, work through these four questions in order:

Question 1: Does your application need every byte delivered correctly?

Yes → TCP. Web pages, API responses, database queries, file transfers, email - all require complete, correct delivery. A web page with missing bytes renders incorrectly. A database query with lost data returns wrong results. A transferred file with missing chunks is corrupted.

No → Consider UDP. If the application can tolerate or recover from occasional data loss, UDP may be appropriate.

Question 2: Does your application need data delivered in order?

Yes → TCP (or QUIC if you need independent stream ordering). Most request-response protocols need ordering - HTTP requests and responses are sequential, SQL queries return ordered result sets, message queues deliver messages in sequence.

No → UDP is strongly favored. Real-time data streams (video frames, game state updates, sensor readings) often do not need strict ordering. A position update from 200ms ago is less useful than the current position, regardless of arrival order.

Question 3: How sensitive is your application to latency?

Latency-tolerant → TCP. If adding 200ms of latency for a retransmission is acceptable (loading a web page, processing a batch job, syncing a file), TCP's reliability is worth the occasional delay.

Latency-sensitive → UDP. If 200ms of added latency is catastrophic (a video call freezes, a game stutters, a trading order misses the market), UDP's immediate delivery without retransmission delays is essential. The application can implement its own recovery (request a keyframe, interpolate position, hedge the order) faster than TCP can retransmit.

Question 4: Is your communication pattern request-response or continuous stream?

Request-response → Usually TCP. The overhead of a TCP handshake is amortized across a conversation (especially with connection pooling or HTTP/2). The reliability guarantee matches the need - you want the response to arrive complete and correct.

Continuous stream → Evaluate carefully. Continuous data streams (video, audio, telemetry, market data) often benefit from UDP because:

• New data arrives frequently, making retransmission of old data wasteful
• Flow rate is determined by the source (camera framerate, sensor sample rate), not by the network
• Occasional gaps are preferable to delayed delivery of the entire stream

graph TD
    subgraph Framework["Transport Protocol Decision Framework"]
        direction TB
        Q1["Every byte must<br/>arrive correctly?"]
        Q1 -->|"Yes"| TCP1["Strong TCP<br/>candidate"]
        Q1 -->|"No - loss<br/>tolerable"| Q2["Order matters?"]
        Q2 -->|"Yes"| Q3A["Multiplexed<br/>independent streams?"]
        Q3A -->|"Yes"| QUIC["QUIC"]
        Q3A -->|"No"| TCP2["TCP"]
        Q2 -->|"No"| Q3B["Latency-critical?"]
        Q3B -->|"Yes"| UDP1["UDP"]
        Q3B -->|"Not especially"| TCP3["TCP is probably<br/>still fine"]
    end

    style Q1 fill:#4f46e5,stroke:#4338ca,color:#fff
    style Q2 fill:#7c3aed,stroke:#6d28d9,color:#fff
    style Q3A fill:#8b5cf6,stroke:#7c3aed,color:#fff
    style Q3B fill:#8b5cf6,stroke:#7c3aed,color:#fff
    style TCP1 fill:#22c55e,stroke:#16a34a,color:#fff
    style TCP2 fill:#22c55e,stroke:#16a34a,color:#fff
    style TCP3 fill:#22c55e,stroke:#16a34a,color:#fff
    style UDP1 fill:#f59e0b,stroke:#d97706,color:#fff
    style QUIC fill:#3b82f6,stroke:#2563eb,color:#fff

This decision tree shows the transport protocol selection framework. First: does every byte need to arrive correctly? If yes, TCP is a strong candidate. If loss is tolerable, ask whether order matters. If order matters and you have multiplexed independent streams, choose QUIC. If order matters without multiplexing, choose TCP. If order does not matter, ask whether the application is latency-critical. If yes, choose UDP. If not especially latency-critical, TCP is probably still fine.

Concrete Examples With Reasoning

Web Application (HTTP API) → TCP

A REST API endpoint that returns JSON data. Every byte matters - a truncated JSON response causes a parse error. Order matters - HTTP request and response are sequential. Latency tolerance is moderate - 200ms retransmission delay is acceptable for most web applications. The pattern is request-response. TCP is the clear choice, and in practice this is delivered via HTTPS (TCP + TLS).

Video Conferencing (Zoom, Google Meet) → UDP (RTP/SRTP)

A real-time video call with two participants. Loss tolerance is high - a dropped frame causes a brief visual glitch but the call continues. Order does not matter at the transport level - the application can reorder frames using RTP sequence numbers. Latency sensitivity is extreme - a 200ms retransmission delay causes visible freezing and audio desync. The pattern is continuous stream. UDP is the clear choice, with RTP handling sequencing and RTCP providing quality feedback.

Live Video Streaming (Twitch, YouTube Live) → It depends

Live streaming has a subtlety: there is a buffer. Unlike video conferencing (which has near-zero tolerance for delay), live streams typically have a 2-10 second buffer. This buffer can absorb TCP retransmission delays without the viewer noticing. For this reason, many live streaming platforms use TCP-based protocols (HLS over HTTP/TCP, DASH over HTTP/TCP) - the buffer provides enough headroom for retransmission while maintaining visual quality.

Ultra-low-latency streaming (sub-second latency for interactive broadcasts) uses UDP-based protocols (WebRTC, SRT) because the buffer is too small to absorb TCP delays.

DNS Resolution → UDP (with TCP fallback)

A DNS query is a single small request (typically under 512 bytes) expecting a single response. Loss tolerance is moderate - the application can retry. Order does not matter - each query is independent. Latency sensitivity is high - DNS resolution is in the critical path of every connection. The pattern is single request-response. UDP is the choice, avoiding the TCP handshake overhead. DNS falls back to TCP only when responses exceed 512 bytes (rare) or for zone transfers.

Database Queries (PostgreSQL, MySQL) → TCP

Database queries demand complete, correct, ordered results. A query that returns 999 of 1,000 rows is wrong, not "close enough." Latency tolerance is moderate - connection pooling amortizes handshake costs. The pattern is request-response within a persistent connection. TCP is the only reasonable choice. No production database uses UDP for client queries.

Online Multiplayer Game (FPS) → UDP (with selective reliability)

A fast-paced multiplayer game sends player position updates 30-60 times per second. Loss tolerance is high for position data - a missed position update is instantly superseded by the next one. But loss tolerance is zero for critical events (player death, score changes, chat messages). The pattern is continuous stream with occasional critical messages.

UDP is the base, but the game implements selective reliability on top: critical events are acknowledged and retransmitted by the application, while position updates are fire-and-forget. This hybrid approach gives the application the latency benefits of UDP for the common case while ensuring critical data is delivered reliably - something TCP cannot do because it retransmits everything indiscriminately.

Chat Application (WhatsApp, Slack) → TCP

Text messages must arrive completely, in order, and reliably. A missing message is unacceptable. Latency tolerance is moderate - a 200ms delay on message delivery is imperceptible to users. The pattern is bidirectional messaging over a persistent connection. TCP is the choice, typically via WebSocket over TCP or HTTP/2 server-sent events.

The Interview Framing

Interview: When an interviewer asks you to design a system, the transport protocol decision is an opportunity to demonstrate depth. Here is how to frame it:

"Design a video streaming system." - "For the video data delivery to the client, I would use an adaptive bitrate streaming protocol like HLS or DASH over HTTP/TCP. The client maintains a playback buffer of several seconds, which absorbs TCP retransmission delays. For ultra-low-latency streaming where sub-second latency is needed, I would switch to WebRTC or SRT over UDP, accepting occasional frame drops in exchange for minimal delay."

"Design a real-time chat system." - "Chat messages require reliable, ordered delivery - a missing or out-of-order message is a bug. I would use TCP via persistent WebSocket connections. The messages are small and infrequent enough that TCP's overhead is negligible, and the reliability guarantee is exactly what the application needs."

"Design an online multiplayer game." - "Player state updates are sent at 60Hz over UDP - losing one position update every few seconds is invisible because the next update arrives 16ms later. Critical game events like scoring and player elimination are sent with application-level reliability: the sender retransmits until acknowledged. This selective reliability approach gives us UDP's latency benefits for the common case while guaranteeing delivery of events that matter."

The key is to state the protocol choice explicitly, then justify it with the specific characteristics of your workload. Interviewers are looking for deliberate reasoning, not a memorized answer.

Feature Comparison at a Glance

This table should be internalized, not memorized. The important thing is understanding why each cell is what it is - the reasons flow from the fundamental design decisions of each protocol.

Hybrid Protocol Patterns

Real-world systems often use both TCP and UDP within the same application:

WebRTC uses UDP (via DTLS/SRTP) for audio and video streams while using TCP (via WebSocket or HTTP) for signaling - the setup and control messages that establish the call. The signaling must arrive reliably (it contains the session description, ICE candidates, and cryptographic parameters), but the media must arrive with minimal latency.

Modern games use UDP for gameplay state (positions, actions, physics) and TCP for ancillary systems (authentication, matchmaking, chat, leaderboards, microtransaction purchases). The gameplay state is latency-critical and loss-tolerant. The ancillary systems are latency-tolerant and loss-intolerant.

IoT platforms use UDP (CoAP) for constrained devices that send small sensor readings infrequently, and TCP (MQTT over TCP) for devices with more resources that need guaranteed delivery of commands and configurations.

CDN and streaming platforms use TCP (HTTPS) for the control plane (manifest files, DRM license requests, analytics) and may use UDP-based protocols (QUIC/HTTP/3) for data delivery to take advantage of connection migration and reduced HOL blocking on mobile networks.

Understanding these hybrid patterns demonstrates architectural maturity in System Design interviews. Real systems are not "TCP or UDP" - they are "TCP for this, UDP for that, and here is why."

Common Mistakes in Protocol Selection

Mistake 1: "Real-time means UDP." Not always. Many real-time applications (live stock tickers, real-time dashboards, collaborative editing) use TCP-based WebSockets because the data must arrive completely and correctly, and the "real-time" requirement is human-scale (sub-second) rather than media-scale (sub-frame).

Mistake 2: "UDP is faster than TCP." UDP has lower latency for the first message (no handshake) and eliminates retransmission delays. But for sustained throughput on a reliable network, TCP with its congestion control can achieve higher throughput than a naive UDP sender that does not implement its own congestion management.

Mistake 3: "We will add reliability on top of UDP." This is a valid approach (QUIC does it), but it is also a massive engineering investment. If you need reliability, ordering, flow control, and congestion control, you are essentially reimplementing TCP. Unless you have a specific reason why TCP's implementation is insufficient (HOL blocking, connection migration, ossification), use TCP.

graph LR
    subgraph Spectrum["The TCP—UDP Spectrum in Practice"]
        direction LR
        TCP_PURE["Pure TCP<br/>HTTP, databases,<br/>email, SSH"]
        TCP_STREAM["TCP + Buffering<br/>HLS/DASH video,<br/>live streaming"]
        QUIC_MID["QUIC<br/>HTTP/3, UDP-based<br/>with reliability"]
        UDP_REL["UDP + Selective<br/>Reliability<br/>Gaming, custom"]
        UDP_PURE["Pure UDP<br/>DNS, NTP, DHCP,<br/>syslog"]
    end

    style TCP_PURE fill:#22c55e,stroke:#16a34a,color:#fff
    style TCP_STREAM fill:#86efac,stroke:#22c55e,color:#000
    style QUIC_MID fill:#3b82f6,stroke:#2563eb,color:#fff
    style UDP_REL fill:#fbbf24,stroke:#f59e0b,color:#000
    style UDP_PURE fill:#f59e0b,stroke:#d97706,color:#fff

This diagram shows the spectrum between pure TCP and pure UDP in practice. At the TCP end: HTTP, databases, email, and SSH use pure TCP. TCP with buffering is used by HLS and DASH video streaming. In the middle, QUIC provides UDP-based transport with built-in reliability for HTTP/3. UDP with selective application-level reliability is used by gaming and custom real-time protocols. At the UDP end, pure UDP is used by DNS, NTP, DHCP, and syslog.

What Comes Next

The next topic covers QUIC - the protocol that sits in the middle of the TCP-UDP spectrum. QUIC provides TCP's reliability guarantees on top of UDP's speed and flexibility, with per-stream independence that neither TCP nor raw UDP offers. QUIC is the transport behind HTTP/3 and represents the future of internet transport.

Exercise: Starter: For each of the following systems, decide TCP or UDP and write one sentence of justification: (a) email sending, (b) weather station sending temperature readings every second, (c) file backup to cloud storage, (d) a stock trading order submission, (e) a live sports score ticker.

Intermediate: Design the transport layer for a collaborative document editor (like Google Docs). Users type in real-time and see each other's cursors. Should cursor position updates use TCP or UDP? Should document content changes use TCP or UDP? Can you use different protocols for different types of data within the same application?

Advanced: Research how Discord handles voice and video. Discord uses WebRTC (UDP-based) for voice/video but WebSocket (TCP-based) for chat messages and presence updates. Why the split? How does Discord handle the transition when a user's UDP connectivity is blocked by a firewall? What is Discord's fallback mechanism, and what quality trade-offs does it involve?

Back to Computer Networking