TCP vs UDP for Web Services: Reliability, Latency, and Failure Modes

Transport layer in hosting: what you actually feel when it breaks

For web services, the transport layer is where “it works” becomes “it’s slow,” “it times out,” or “it randomly drops.” Most hosting incidents that look like “network” are really transport symptoms caused by filtering, overloaded servers, misbehaving middleboxes, or packet loss. The key is to recognize the patterns TCP and UDP produce on the wire and map them to likely causes.

TCP: connection-oriented reliability (and the failure modes it creates)

TCP three-way handshake

TCP starts with a handshake to establish state on both ends. This is why TCP can fail before any application data is exchanged.

• SYN: client asks to start a connection (includes client initial sequence number).
• SYN-ACK: server acknowledges and proposes its own initial sequence number.
• ACK: client acknowledges; connection is established and data can flow.

In hosting, the handshake is where you detect: “Is the server reachable?”, “Is the port allowed?”, and “Is something listening?”

Sequencing and ACKs (how TCP proves delivery)

TCP numbers bytes in the stream with sequence numbers. The receiver sends acknowledgments (ACKs) indicating the next byte it expects. If the sender does not receive ACKs in time, it assumes loss and retransmits. This is why TCP can deliver reliably over imperfect networks, but also why loss shows up as latency and throughput collapse.

• Sequence numbers: identify where each segment’s payload fits in the byte stream.
• ACK number: “I have received everything up to byte N-1; send me N next.”
• Window: receiver’s advertised capacity; affects how much can be in-flight.

Retransmissions (reliability that feels like slowness)

When packets are dropped, TCP retransmits. Retransmission is not free: it adds delay and reduces effective throughput. In web hosting, intermittent slowness is often TCP doing its job in a lossy path.

Continue in our app.

You can listen to the audiobook with the screen off, receive a free certificate for this course, and also have access to 5,000 other free online courses.

Or continue reading below...

Download the app

Common causes of loss/retransmits in hosting environments:

• Congested links (oversubscribed uplinks, noisy neighbors, saturated NAT gateways).
• Packet drops due to firewall/ACL rate limits or DDoS protection thresholds.
• Bad MTU/PMTUD interactions (blackholed ICMP leading to fragmentation issues and repeated retransmits).
• Server overload causing delayed ACKs or dropped packets at the host NIC/stack.

Connection teardown (FIN vs RST)

TCP connections end either gracefully or abruptly.

• FIN/ACK (graceful close): one side says “I’m done sending,” the other ACKs; both sides close cleanly after both directions finish.
• RST (reset): immediate abort. Often indicates “no socket,” “application crashed,” “middlebox rejected,” or “policy says stop.”

In hosting, RSTs are a major clue: they usually mean a device or host actively rejected the connection, not that packets were lost in transit.

UDP: connectionless, low overhead, and easy to break silently

UDP characteristics

UDP sends independent datagrams with no handshake, no built-in retransmission, and no ordering guarantees. That makes it fast and lightweight, but it also means the application must tolerate loss, duplication, and reordering (or implement its own reliability).

• No connection state at the transport layer.
• No ACKs or retransmission by default.
• Lower overhead and often lower latency when the network is healthy.
• Harder to troubleshoot because “no response” could be loss, filtering, or the server not replying.

Typical UDP uses you’ll see in hosting

• DNS queries: many queries use UDP for speed; retries may happen at the application level if no response arrives.
• Monitoring/metrics: some telemetry protocols use UDP to avoid backpressure (dropping is acceptable).
• Real-time traffic: voice/video/game streams often prefer timely delivery over perfect delivery.

Practical implication: UDP failures often look like “random missing responses” rather than “slow but eventually works.” If UDP is filtered, clients may retry over TCP (for DNS) or simply fail (for many monitoring/real-time flows).

Symptom-to-cause mapping for web services

SYN timeouts: “I can’t connect” with no explicit refusal

A SYN timeout means the client sent SYNs but did not complete the handshake. You typically see repeated SYN retransmissions from the client, with no SYN-ACK returning.

Most likely causes:

• Firewall/ACL silently dropping inbound SYNs or outbound SYN-ACKs (common in security groups, NACLs, host firewalls).
• Routing/path issue preventing return traffic (asymmetric routing, wrong default route, missing return route, broken NAT state).
• Server not reachable at L3 (instance down, wrong IP, wrong VIP mapping).

Less likely but possible:

• Server overload so severe that SYN-ACKs are not sent in time (SYN backlog exhaustion can cause drops).
• DDoS mitigation or rate limiting dropping SYNs.

Connection resets (RST): “It actively refused or aborted”

An RST indicates an endpoint (or middlebox) is explicitly terminating the TCP connection.

Common hosting interpretations:

• Immediate RST after SYN: often “port closed” (no process listening) or a firewall configured to reject instead of drop.
• RST after some data: application crash, reverse proxy closing, idle timeout on load balancer/NAT, or firewall terminating long-lived flows.
• RST from an intermediate device: some firewalls inject RSTs to enforce policy.

Intermittent slowness: loss, retransmits, and head-of-line waiting

When TCP retransmits, application requests can stall. A single lost segment can delay subsequent data delivery because TCP must deliver bytes in order to the application. Symptoms include:

• Web pages that “hang” mid-load, then suddenly continue.
• API calls with variable latency spikes.
• Large transfers with inconsistent throughput.

On packet captures, you may see duplicate ACKs, retransmissions, and increasing round-trip times. The root cause is often congestion or drops on a specific segment of the path, or MTU issues causing repeated loss of larger packets.

Practical step-by-step: how to reason from a simplified packet flow

Step 1: Identify the transport and direction

Ask: is this TCP or UDP? For TCP, do you see a handshake? For UDP, do you see a request and a response?

Step 2: For TCP, classify the failure phase

• Handshake never completes: think filtering or routing/return path.
• Handshake completes, then immediate close: think application behavior, proxy policy, TLS mismatch at higher layers (but transport shows close/reset).
• Data transfers but stalls: think loss/retransmits, MTU, congestion, or server overload.

Step 3: Look for “drop” vs “reject” behavior

• Drop: timeouts, repeated SYNs, no response.
• Reject: RST (TCP) or ICMP unreachable (sometimes for UDP), fast failure.

Step 4: Decide which domain owns the fix

• Routing/path: no return traffic, asymmetric routing, wrong NAT, unreachable networks.
• Firewall policy: drops/rejects on specific ports, rate limits, state timeouts.
• Server listening state: port closed, service down, bound to wrong interface, backlog exhausted.
• DNS-related: client connects to wrong IP, stale record, wrong load balancer target (transport symptoms appear against the “wrong” destination).

Exercises: interpret packet flows and pick the most likely cause

Exercise 1: SYN timeout to a web port

Client (198.51.100.10) -> Server (203.0.113.20:443)  SYN  seq=1000  (t=0.0s) Client -> Server  SYN  seq=1000  (t=1.0s) Client -> Server  SYN  seq=1000  (t=3.0s) Client -> Server  SYN  seq=1000  (t=7.0s) (No SYN-ACK seen)

Question: Is this more likely routing, firewall policy, server listening state, or DNS?

Answer guidance: This pattern strongly suggests firewall policy or routing/return-path. A server that is reachable and not listening often responds with RST (reject) rather than silence. If you are confident the destination IP is correct, prioritize checking security group/NACL/host firewall and return routing/NAT. DNS is only implicated if the IP itself is unexpected.

Exercise 2: Immediate refusal

Client -> Server:80   SYN  seq=5000 (t=0.0s) Server -> Client      RST,ACK ack=5001 (t=0.01s)

Question: What is the most likely cause?

Answer guidance: Server listening state (nothing is listening on port 80) or a firewall configured to reject rather than drop. Routing is unlikely because you got an immediate response. DNS is unlikely unless you connected to the wrong host due to a bad record.

Exercise 3: Handshake succeeds, then reset during request

Client -> Server:443  SYN (t=0.0s) Server -> Client  SYN-ACK (t=0.02s) Client -> Server  ACK (t=0.03s) Client -> Server  PSH,ACK  (TLS ClientHello...) (t=0.04s) Server -> Client  RST,ACK (t=0.05s)

Question: Which category fits best?

Answer guidance: Most often server listening/application behavior (service misconfigured, proxy closing, crash) or firewall policy that terminates connections after inspection. Routing is unlikely because the handshake completed. DNS could be involved if you hit the wrong backend that resets unexpected SNI/hostnames, but the transport symptom alone points first to app/proxy/firewall.

Exercise 4: Intermittent slowness with retransmissions

Client -> Server  PSH,ACK seq=10000 len=1460 (t=0.0s) Server -> Client  ACK ack=11460 (t=0.03s) Client -> Server  PSH,ACK seq=11460 len=1460 (t=0.04s) (No ACK) Client -> Server  Retransmission seq=11460 len=1460 (t=0.30s) Server -> Client  ACK ack=12920 (t=0.33s)

Question: Which category is most likely?

Answer guidance: This points to routing/path quality issues (loss/congestion) or firewall policy/rate limiting causing drops. Server listening state is unlikely because the connection is established and ACKs are flowing. DNS is unrelated to mid-connection retransmissions.

Exercise 5: UDP request with no response (DNS-like pattern)

Client -> Resolver:53  UDP query id=0x1234 (t=0.0s) Client -> Resolver:53  UDP query id=0x1234 (retry) (t=1.0s) Client -> Resolver:53  UDP query id=0x1234 (retry) (t=2.0s) (No UDP response seen)

Question: Is this routing, firewall policy, server listening state, or DNS?

Answer guidance: For UDP, “no response” is commonly firewall policy (UDP/53 blocked) or routing/return-path. “Server listening state” is less directly observable with UDP because there is no handshake; a resolver might simply not respond. DNS as a category here means “wrong resolver IP configured” or “query sent to a non-resolver,” which effectively becomes a server-side non-response. If the resolver IP is unexpected, treat it as a DNS/config issue; otherwise check filtering and reachability.

Quick decision table (mental checklist)

• Repeated SYNs, no SYN-ACK → drop: firewall/ACL or routing/return path.
• SYN then RST → reject: port closed, service not listening, or rejecting firewall.
• Handshake OK, then RST → app/proxy/firewall terminating after accept/inspection.
• Duplicate ACKs/retransmissions → loss/congestion/MTU/rate limiting causing intermittent slowness.
• UDP retries with no response → UDP filtered, return path broken, or wrong destination service.