TCP vs UDP: The Difference for Troubleshooting

The call drops, the firewall log shows nothing, and the rule you wrote last week allows port 5060 exactly as the vendor asked. Whether that rule works depends on one word you may not have typed: the protocol. This guide covers how TCP differs from UDP, what each one promises, and how that difference shows up in a packet capture, a firewall rule and a ticket.

TL;DR

• The difference. TCP sets up a connection, numbers every byte, confirms delivery and resends what was lost. UDP sends a datagram and forgets it, with no connection, no ordering and no retry.
• The cost. TCP pays for its guarantees in round trips and in waiting for lost data. UDP pays in silence: when a packet is gone, nothing tells the sender.
• Who uses which. File transfer, email, web pages and remote shells ride TCP. DNS, VoIP, video, NTP, DHCP and most VPN tunnels ride UDP, and several services use both.
• For troubleshooting. A TCP problem shows up as a failed handshake or retransmissions. A UDP problem shows up as one-way traffic, a timeout or a firewall that never sees a reply.

What TCP Guarantees, and What UDP Does Not

Both protocols sit on top of IP and do the same basic job: they get data from a program on one machine to a program on another, using port numbers to say which program. What separates them is the list of promises each one makes.

TCP, defined today in RFC 9293, promises a connection. Before any data moves, the two ends agree on starting sequence numbers. Every byte after that is numbered, the receiver acknowledges what arrived, and the sender retransmits anything that is not acknowledged in time. Segments that arrive out of order are put back in order before the application sees them. The receiver also advertises a window, which tells the sender how much it can accept, so a fast server cannot flood a slow client.

UDP, defined in RFC 768, promises almost nothing. The whole header is eight bytes: source port, destination port, length and a checksum. The RFC itself says delivery and duplicate protection are not guaranteed, and that applications needing ordered, reliable delivery should use TCP. On IPv4 the checksum is optional: a zero means the sender did not compute one.

That is the entire difference. Everything else in this post is a consequence of it. TCP is the protocol for data that has to arrive complete, in order, no matter how long that takes. UDP is the protocol for data where waiting for a retransmission is worse than losing the packet, and for anything that wants to build its own rules on top of a blank slate.

PowerCert's animated comparison covers the same ground in five minutes, and it is the one to send a junior tech before the capture review:

The Three-Way Handshake, Packet by Packet

A TCP connection starts with three packets, and each one tells you something when a connection fails.

The client sends a SYN with its starting sequence number. The server, if it is listening on that port, answers with a SYN-ACK: its own sequence number plus an acknowledgment of the client's. The client replies with an ACK, and both sides are in the ESTABLISHED state. Data can ride on that third packet. RFC 9293 lays the exchange out line by line, and the reason it exists is to stop an old, delayed SYN from opening a connection nobody asked for.

Read the handshake as a diagnostic and three failure shapes appear:

When a connection closes, each side sends a FIN and the side that closed first sits in TIME-WAIT for two maximum segment lifetimes, so late packets from the old connection cannot be mistaken for a new one. That is why a server under heavy short-lived load shows thousands of TIME-WAIT entries in netstat. It is normal, not a leak.

UDP has none of this. A client sends a datagram to port 53 and either an answer comes back or it does not. There is no state on the wire to inspect, which is why a UDP failure in a capture looks like a request with no reply, and why finding the cause takes a different set of tools.

This r/networking thread is the handshake failure in the wild: SYN goes out, nothing comes back, retries at one, two and four seconds, while UDP and ICMP to the same address work fine. The poster's guess, a stateful device treating TCP differently for certain source prefixes, is the right place to look.

Which Services Use Which, and Why

Protocol designers choose TCP or UDP based on one question: is a late packet still useful? For a file, yes. For a voice sample from 400 milliseconds ago, no.

The IANA service registry is where these assignments live, and it lists both transports for many names, including 3389 and 445. That is a hint for firewall rules: registration is not the same as use. SMB listens on TCP 445 only, while Remote Desktop uses both when it can.

The practical rule for a technician is to never assume. A vendor doc that says "open port 5060" is incomplete. Ask which protocol, and if the answer is both, write two rules.

Why "Faster" Is the Wrong Question

Ask whether UDP is faster than TCP and the answer is yes, no and it depends, which is why the question is unhelpful. The useful version is: what does each protocol do when a packet is lost?

TCP waits. The receiver holds everything after the gap until the missing segment is retransmitted, and the application sees nothing in the meantime. That is head-of-line blocking, and on a lossy link it turns a 1% loss rate into visible stalls. TCP also starts slow by design: congestion control ramps up the sending rate and backs off on loss, which is what keeps a shared link usable but makes TCP look sluggish on a short transfer.

UDP does not wait, because it does not know. The lost packet is gone, the next one is delivered the moment it arrives, and the application decides what to do about the hole. A VoIP codec conceals a missing 20 millisecond sample. A game interpolates a missing position update. A DNS resolver resends the query after a timeout.

So UDP has less overhead: no handshake before the first byte, no acknowledgments, an eight-byte header instead of twenty or more. On a clean network the two feel the same for bulk data, because TCP's extra packets are small. On a lossy network UDP stays smooth while TCP stutters, and the price is that UDP delivered less of the data. "Faster" is the wrong word for that trade. "Chooses timing over completeness" is the right one.

Where this bites in practice is the VPN tunnel. Running a tunnel over TCP means the inner TCP sessions and the outer TCP session both detect loss and both retransmit, and the two timers fight. That is why OpenVPN defaults to UDP and WireGuard supports nothing else, and why a VPN that was switched to TCP 443 to get through a hotel firewall feels slow even on a good connection.

Reading TCP and UDP in netstat and Wireshark

The first tool on a Windows box is netstat. netstat -ano lists every TCP connection with its state, and every UDP endpoint with no state at all, because there is none to show. A TCP line reads ESTABLISHED, LISTENING, TIME_WAIT or SYN_SENT. A UDP line reads an address and a port, and nothing else. The PowerShell equivalents are Get-NetTCPConnection, which filters by state, and Get-NetUDPEndpoint, which cannot, for the same reason. Our list of useful PowerShell commands has both sorted by the ticket you are on.

A SYN_SENT line that never changes is the netstat view of a dropped SYN. A LISTENING line that is bound to 127.0.0.1 instead of 0.0.0.0 is the netstat view of a service that answers locally and refuses everyone else.

In Wireshark, the handshake is the first thing to filter for. tcp.flags.syn == 1 && tcp.flags.ack == 0 shows every connection attempt; add tcp.flags.reset == 1 to see which ones the far end refused. Wireshark's TCP analysis marks a segment as a retransmission when the sequence number is behind what it expected and the segment carries data or a SYN or FIN, and it marks duplicate ACKs and zero-window conditions the same way. Those flags, filtered with tcp.analysis.flags, turn a 50,000 packet capture into the 40 packets that matter.

UDP gives Wireshark less to work with. There is no sequence number to compare, so the capture cannot tell you a datagram was lost. What it can show is asymmetry: requests to a port with no replies, or replies arriving from a different port than the request went to, which is how some NAT and firewall problems look. For DNS, the resolver's own timeout is often the only error you get, and our guide to a DNS server not responding walks through that case.

A quick way to remember the two views: TCP problems leave a trail, UDP problems leave a gap.

Firewall Rules: The Protocol Is Part of the Rule

A firewall rule is not "port 5060". It is "UDP port 5060" or "TCP port 5060", and a rule written for the wrong one matches nothing. The Windows firewall makes this explicit: New-NetFirewallRule takes a -Protocol parameter alongside -LocalPort, and a rule with the protocol left out applies to any protocol, which is rarely what the vendor meant.

The second trap is state. A stateful firewall tracks TCP connections precisely, because the handshake and the flags tell it exactly when a session starts and ends. For UDP it has to guess: it records the outbound datagram and allows replies for a short window, then forgets. A SIP registration that goes quiet for a few minutes can find its return path closed, and the symptom is a phone that makes calls but never rings. The post on stateful firewalls covers that pseudo-state and the timers behind it.

The r/sysadmin thread below is the same lesson from the proxy side: a call-center app that needs UDP for STUN and RTP, behind a web proxy that only speaks TCP, and calls with no audio as the result.

The third trap is testing. Test-NetConnection tests TCP ports only; its port parameter is a TCP port, and Microsoft's reference lists the common values as SMB, HTTP, RDP and WINRM. A green result from it proves nothing about UDP. For UDP use PortQry, which Microsoft documents as reporting LISTENING or FILTERED when a UDP port does not answer, then sends a service-specific probe to tell the two apart. Nmap's -sU scan does the same job from any platform. If you need to confirm the rule works end to end, run the real client, not a port tester.

For inbound rules on a router, the same protocol choice applies to each port forwarding entry: a forward for TCP 3389 leaves the UDP half of Remote Desktop on the outside, and the session falls back to TCP alone, which works but drops the smoother transport.

One line for fleet work: OpenFrame can run a Get-NetTCPConnection and Get-NetUDPEndpoint export as a script across a client's devices and collect the output, so a listening-port inventory does not mean a remote session to each box.

QUIC: UDP With TCP's Guarantees Added Back

Since 2021, a growing share of web traffic has used neither TCP nor plain UDP. QUIC, published as RFC 9000, is a transport that runs inside UDP datagrams and rebuilds the things TCP provides: reliable delivery, ordering within a stream, flow control and congestion control. It adds what TCP cannot easily do: several independent streams in one connection, so one lost packet stalls one stream rather than all of them, and TLS built into the handshake, so a connection and its encryption come up in fewer round trips. HTTP/3 is HTTP carried over QUIC.

For a technician, QUIC changes two assumptions. First, UDP 443 is now ordinary web traffic, not an anomaly. Second, a firewall that blocks UDP 443 does not break browsing, because every major browser falls back to HTTP/2 over TCP, but it does move that traffic onto the path your inspection rules were written for. Some teams block UDP 443 on purpose for exactly that reason. Either way it should be a decision, not an accident of an old rule set.

The pattern QUIC follows is the one to remember when a vendor says its product "uses UDP for speed". UDP is not fast on its own; it is empty. Anything that needs reliability has to build it, and the question for the vendor is what they built.

The Short Version

TCP numbers, acknowledges, orders and retransmits. UDP sends and forgets. Services pick TCP when every byte matters and UDP when timing matters more, and a few, including DNS and Remote Desktop, use both. In a capture, TCP failures show up in the handshake and the analysis flags, while UDP failures show up as requests with no reply. In a firewall, the protocol is half the rule, and the testing tool has to match it.

If the rule is right and the handshake completes but the session still stalls, the next stop is the network itself. Start with how to check bandwidth usage when the graph looks fine, and work out from there.