Connection-Oriented vs Connectionless Services

A surgeon doesn't choose instruments arbitrarily. Each tool—scalpel, forceps, retractor—is selected based on the specific requirements of the procedure. The choice reflects deep understanding of both the tools' capabilities and the task's demands.

Transport protocol selection follows the same principle. TCP and UDP are not interchangeable commodities but specialized tools optimized for different scenarios. Selecting the wrong protocol leads to poor performance, reliability failures, or unnecessary complexity. Selecting the right protocol makes applications robust, efficient, and maintainable.

This page provides practical protocol selection guidance. We'll examine specific application domains, analyze why certain protocols dominate those domains, and establish criteria-based selection methodology. By the end, you'll be equipped to choose transport protocols with confidence, backing your decisions with sound technical reasoning.

TCP should be your default choice. Its reliability, widespread support, and decades of optimization make it suitable for the vast majority of applications. Choose TCP when the following conditions apply:

1. Data integrity is paramount

If losing even a single byte is unacceptable, TCP is the clear choice:

• File transfers: Every byte must arrive correctly. Corrupted files are useless.
• Email: Messages must be complete. Partial emails are confusing or dangerous.
• Database transactions: ACID properties require complete, ordered delivery.
• Software updates: Corrupted patches can brick devices.
• Financial transactions: Missing or duplicate transactions have legal/financial consequences.

2. Ordered delivery is required

Applications that depend on processing data in sequence need TCP:

• Terminal sessions (SSH): Commands must execute in order.
• Document transfer: Pages must arrive in sequence.
• Transaction logs: Event ordering is semantically meaningful.
• Streaming protocols over HTTP: Video segments must play in sequence.

3. Connection semantics simplify application logic

TCP's connection model benefits applications with:

• Authentication states: Once authenticated, the connection carries identity. UDP requires per-message authentication.
• Session management: TCP connection = session. Cleanup is automatic when connection closes.
• Request-response correlation: Responses arrive on the same connection as requests. No matching required.

4. Congestion control is essential

If your application will operate on shared networks and should coexist fairly:

• Enterprise applications: Must not disrupt other network traffic.
• Cloud services: Fair resource sharing is expected.
• Consumer applications: ISPs may throttle non-TCP-friendly traffic.

5. Network environment is TCP-friendly

TCP works best when:

• Firewalls and NATs expect and handle TCP correctly
• Network provides reasonable reliability (loss < 5%)
• Latency variability is acceptable
• Connection longevity is possible (stable network)

UDP is the right choice when TCP's guarantees conflict with application requirements. The key insight: UDP isn't "TCP without reliability"—it's a fundamentally different model that's optimal for specific scenarios.

1. Real-time communication

When timeliness trumps completeness, UDP excels:

• Voice over IP (VoIP): A 200ms old audio sample is useless—play what arrived, skip what didn't.
• Video conferencing: Frame drops are preferable to frozen video waiting for retransmission.
• Live streaming: Buffering is acceptable; indefinite stalls are not.

The deadline argument:

Real-time data has a "deadline" after which it loses value:

Value
  ↑
  │███████████░░░░░░░░░░░░░
  │          deadline    time →
  │                ↓
  │         value drops
  │         to zero

TCP's retransmission can deliver data after its deadline—worse than no delivery because it disrupts subsequent data timing.

2. Query-response protocols

For simple, stateless exchanges:

• DNS: One question, one answer. Timeout + retry is sufficient reliability.
• DHCP: Discovery and configuration. Brief exchange, no session needed.
• NTP: Time synchronization. Occasional loss is tolerable.
• SNMP: Network monitoring. Stateless queries to many devices.

Why TCP overhead hurts:

For a DNS query:

• UDP: 1 RTT (query + response)
• TCP: 2+ RTT (SYN, SYN-ACK, query+ACK, response+ACK)

DNS handles millions of queries per second. Doubling RTT and connection state would be catastrophic.

3. Multicast and broadcast

When delivering to multiple receivers:

• TCP is inherently point-to-point
• UDP naturally supports one-to-many
• Applications: IPTV, financial market data, service discovery

4. High-throughput, low-overhead scenarios

When protocol efficiency matters:

• Intra-datacenter communication: Reliable networks, low latency, high throughput requirements.
• Kernel bypass networking: DPDK, RDMA—systems that avoid kernel TCP stack overhead.
• High-frequency trading: Microsecond latency requirements.

5. Custom reliability requirements

When TCP's reliability model doesn't fit:

• Selective reliability: Critical data retransmitted, non-critical best-effort.
• Application-controlled timing: Custom retransmission policies.
• Forward error correction: Recovery without retransmission delay.

Online gaming presents one of the most challenging protocol selection scenarios. Games demand low latency, predictable timing, and reliability for critical state—often simultaneously.

The gaming network challenge:

• Action games (FPS, fighting): <50ms latency required; 100ms is "laggy"
• Strategy games: More latency tolerance but long sessions
• MMOs: Mixed requirements—combat needs speed, chat needs reliability
• Mobile games: Variable network quality, battery constraints

Typical gaming network architecture:

┌──────────────┐                    ┌──────────────┐
│   Client 1   │──┐                 │              │
├──────────────┤  │   UDP (game)    │              │
│   Client 2   │──┼─────────────────│  Game Server │
├──────────────┤  │   TCP (chat)    │              │
│   Client 3   │──┘                 │              │
└──────────────┘                    └──────────────┘

UDP for game state:

• Player positions, actions, world state
• High frequency (20-60 updates/second)
• Loss is recoverable (next update arrives soon)
• Latency is critical (old state is wrong state)

TCP for peripheral systems:

• Chat messages (must be complete)
• Matchmaking, leaderboards
• Authentication, account management
• Patches and updates

Game networking patterns:

1. State synchronization (UDP)

The server is authoritative; clients receive state snapshots:

• Server sends position/state at fixed intervals
• Lost packets are obsolete when next update arrives
• Clients interpolate/extrapolate between updates
• No retransmission—always send latest state

2. Reliable events (UDP + ACK)

Critical one-time events need confirmation:

• Player fired weapon, collected item, died
• Sender maintains retry queue until ACK received
• Sequence numbers prevent duplicate processing
• Custom timeout/retry logic (faster than TCP)

3. Client-side prediction

Mask latency with local simulation:

• Client predicts own movement immediately
• Server validates and corrects
• Smooth correction hides network latency
• Requires game-specific reconciliation logic

Modern game networking libraries:

• ENet: UDP with optional reliability channels
• RakNet: UDP with reliability, security, voice
• GameNetworkingSockets (Valve): UDP with encryption, P2P
• Photon: Cloud service with UDP/TCP options

These libraries implement reliable UDP patterns so game developers don't reinvent the wheel.

Media streaming spans a spectrum from live broadcasts requiring minimal latency to video-on-demand where buffering enables reliability. Protocol selection depends on where the application falls on this spectrum.

The streaming paradox:

Video is large and must be complete (dropouts are visible). It's also time-sensitive (buffering frustrates users). This creates tension:

• Reliability → TCP → potential stalls
• Timeliness → UDP → potential dropouts

Modern resolution: Adaptive Bitrate Streaming (ABR)

┌─────────────────────────────────────────────────┐
│              HTTP/TCP (over the internet)       │
├─────────────────────────────────────────────────┤
│  Client ←── Segment 1 ←── Segment 2 ←── ...    │
│              │               │                  │
│              ▼               ▼                  │
│         [Play Buffer] [Adjust Quality]          │
└─────────────────────────────────────────────────┘

ABR (HLS, DASH) uses TCP/HTTP but with clever engineering:

• Video is divided into 2-10 second segments
• Client downloads segments over HTTP (TCP)
• Buffer of several segments absorbs network variations
• If bandwidth drops, switch to lower quality
• If segment is late, quality degrades; playback continues

Why HTTP/TCP dominates general streaming:

1. Ubiquity: Firewalls pass HTTP; CDNs understand it; caching works.
2. Simplicity: No special infrastructure; standard web servers work.
3. ABR effectiveness: Buffering + quality adaptation handles most networks.
4. Security: HTTPS provides encryption; no protocol-specific security needed.
5. CDN compatibility: Edge caching reduces latency and origin load.

Where UDP streaming wins:

1. Ultra-low latency (<1 second)

Interactive streaming (auctions, gambling, live events where delay = spoilers):

• WebRTC: <500ms latency, P2P or server-relayed
• SRT (Secure Reliable Transport): Professional broadcasting, <1s latency
• RIST: Reliable Internet Stream Transport, industry standard for contribution

2. Intranet/controlled environments

When network is reliable and controlled:

• RTSP/RTP: Surveillance systems, IPTV
• Multicast IPTV: Efficient one-to-many in managed networks

3. Voice/video conferencing

Two-way real-time communication:

• WebRTC: The standard for browser-based RTC
• UDP-based with DTLS (security) and SRTP (media)

Internet of Things (IoT) devices present unique constraints: limited power, constrained memory, unreliable connectivity, and massive scale. These constraints dramatically influence protocol selection.

IoT constraints:

• Power: Battery-operated devices must minimize radio activity
• Memory: Embedded systems may have KB, not MB, of RAM
• Bandwidth: Low-power radio links offer kbps, not Mbps
• Connectivity: Wireless links are lossy; devices may sleep for hours
• Scale: Millions of devices connecting to centralized infrastructure

Why TCP is challenging for IoT:

1. Connection overhead: Handshake consumes power and time
2. Keepalives: Maintaining connections drains batteries
3. Buffer requirements: TCP buffers exceed device memory
4. Timeout behavior: Exponential backoff is inappropriate for constrained networks
5. State at server: Millions of connections exhausts server resources

IoT-optimized protocols:

CoAP (Constrained Application Protocol):

• UDP-based, REST-like semantics
• Designed for constrained devices
• Optional reliability via confirmable messages
• Small header (4 bytes minimum)
• Proxy integration for internet bridging

MQTT (Message Queuing Telemetry Transport):

• Publish/subscribe pattern
• Runs over TCP (MQTT) or UDP-like (MQTT-SN)
• Quality of Service levels: 0 (fire-and-forget), 1 (at-least-once), 2 (exactly-once)
• Persistent sessions survive disconnection

LwM2M (Lightweight M2M):

• Device management protocol
• Built on CoAP
• Standardized device resources
• Firmware update, bootstrapping

Hybrid patterns for IoT:

Pattern 1: UDP for regular telemetry, TCP for critical

Sensor → UDP → Gateway → MQTT/TCP → Cloud
                 ↓
            Aggregation/buffering

Pattern 2: CoAP with block transfer

• Split large payloads into blocks
• Each block confirmed individually
• Reassembly at receiver
• Provides TCP-like reliability for occasional large transfers

Pattern 3: Store-and-forward with opportunistic connectivity

• Device stores data locally when offline
• Bulk upload via TCP when connectivity available
• Acceptable for non-time-critical telemetry

Enterprise applications prioritize reliability, security, maintainability, and integration with existing infrastructure. These priorities strongly favor TCP in most scenarios.

Enterprise requirements:

• Reliability: Business processes cannot tolerate data loss
• Security: Encryption and authentication are mandatory
• Auditability: Transactions must be traceable
• Integration: Must work with firewalls, proxies, load balancers
• Support: Protocols must be well-documented and understood by IT staff

Why TCP dominates enterprise:

1. Built-in reliability: Transactions complete or fail cleanly
2. TLS integration: Standard encryption, well-understood
3. Firewall friendliness: TCP ports are commonly allowed; UDP often restricted
4. Load balancer support: HTTP/TCP load balancing is mature
5. Debugging tools: Wireshark, tcpdump, netstat understand TCP

Where UDP appears in enterprise:

1. Unified Communications (VoIP, Video)

Real-time media requires UDP:

• RTP for media streams
• SRTP for encrypted media
• TCP for signaling (SIP over TCP/TLS)

Enterprise firewalls must be configured to allow UDP for these applications.

2. VPN and tunneling

Some VPN protocols use UDP:

• IPSec ESP: Native UDP (protocol 50) or NAT-T (UDP 4500)
• WireGuard: UDP only
• OpenVPN: UDP preferred, TCP fallback

UDP is preferred for VPN because encapsulating TCP in TCP causes pathological behavior (TCP meltdown).

3. Network services

Infrastructure protocols:

• DNS: UDP with TCP fallback
• NTP: UDP for time sync
• DHCP: UDP for address assignment
• SNMP: UDP for monitoring

Enterprise UDP challenges:

• Firewall traversal: UDP ports often blocked by default
• NAT timeout: UDP NAT mappings expire (often 30-60 seconds)
• DDoS vulnerability: UDP amplification attacks target open UDP services
• Troubleshooting: Less visibility into UDP flows

Recommendation:

For enterprise applications, default to TCP/HTTPS unless specific requirements demand UDP. Even real-time applications can often use WebRTC (which handles NAT traversal and fallback to TCP relay when UDP fails).

The binary TCP vs UDP choice is increasingly outdated. Modern protocols offer hybrid characteristics, and understanding these options expands your toolkit.

QUIC: The Modern Hybrid

┌────────────────────────────────────────────┐
│              Application (HTTP/3)          │
├────────────────────────────────────────────┤
│   QUIC (reliability, multiplexing, TLS)   │
├────────────────────────────────────────────┤
│                    UDP                     │
├────────────────────────────────────────────┤
│                     IP                     │
└────────────────────────────────────────────┘

QUIC (Quick UDP Internet Connections) combines:

• UDP transport (firewall traversal, user-space implementation)
• Stream multiplexing without head-of-line blocking
• Built-in TLS 1.3 encryption
• Connection migration (survives IP address changes)
• 0-RTT connection establishment for repeat connections

When to consider QUIC:

• HTTP/3 adoption (becoming standard for web)
• Mobile applications (connection migration)
• Latency-sensitive reliable applications
• When TCP's head-of-line blocking is problematic

SCTP (Stream Control Transmission Protocol):

SCTP offers unique features:

• Message boundaries preserved (like UDP)
• Reliable delivery (like TCP)
• Multi-homing: Multiple IP addresses per endpoint for failover
• Multi-streaming: Independent streams without head-of-line blocking

Limitations: Limited NAT traversal, firewall support. Often tunneled over UDP.

WebRTC:

WebRTC is a comprehensive real-time communication framework:

• ICE for NAT traversal and connectivity checking
• DTLS for key exchange and encryption
• SRTP for encrypted media
• SCTP over DTLS for data channels

Ideal for: Browser-based video conferencing, P2P data exchange, gaming.

Selection considerations for modern protocols:

Implementation reality:

Modern protocols often require library support:

• QUIC: quiche, msquic, picoquic
• WebRTC: libwebrtc, Pion
• SCTP: lksctp, usrsctp

Evaluate library maturity, performance, and maintenance before committing.

We've explored protocol selection across multiple domains, providing practical guidance for choosing the right transport for your applications.

Looking ahead:

We've covered the fundamental paradigms (connection-oriented, connectionless), trade-offs, and protocol selection. The final page examines application requirements—how specific application characteristics drive protocol choices, providing a synthesis of everything we've learned.