TCP vs UDP: The Complete Guide to Network Protocols

TCP vs UDP: the quick answer

TCP and UDP are transport protocols carried above IP. Calling them transport protocols is more precise than describing them broadly as network protocols because the IP layer handles packet addressing and routing, while TCP and UDP provide process-to-process transport through ports.

UDP is not inherently faster for every workload. Its header and base protocol are simpler, and it avoids TCP connection establishment, but useful performance depends on the complete system. A poorly paced UDP application can cause loss or congestion, while a well-tuned TCP implementation can efficiently transfer large amounts of data. Choose according to the semantics the application requires, not according to a universal claim that one protocol is faster.

How TCP works

TCP is specified by RFC 9293, the current TCP base specification. It superseded the original RFC 793 specification. Additional standards define important behavior such as TCP congestion control and selective acknowledgment. TCP runs above IP and identifies communicating applications through transport ports.

The service TCP provides is a full-duplex byte stream. If an application writes two buffers, the receiver might read them as one larger block, several smaller blocks, or another grouping. The receiving program cannot infer application messages from individual TCP segments or individual write calls. Applications need framing such as a length field, delimiter, fixed-size record, or protocol-defined structure.

Connection establishment

A normal active TCP connection begins with a three-way handshake. The exchange verifies two-way reachability at that moment and synchronizes each endpoint's initial sequence-number space. TCP options supported by both endpoints can also be negotiated during connection establishment.

This is the usual sequence, not a claim that every possible TCP state transition looks identical. TCP also defines behavior for cases such as simultaneous open. Extensions can allow data in connection-establishment exchanges, so the handshake is best understood as connection-state and sequence-number synchronization rather than an absolute prohibition on application data.

Reliability, flow control, and congestion control

Head-of-line blocking

If a TCP segment carrying an earlier part of the stream is missing, later bytes cannot be delivered past that gap as part of the ordered stream, even if those later bytes have reached the receiver. This transport-level head-of-line blocking matters when unrelated logical operations are multiplexed over one connection.

HTTP/2 multiplexes application streams over one TCP connection, but a missing TCP byte can temporarily hold up data for multiple HTTP/2 streams whose bytes follow that gap. This limitation helped motivate QUIC's stream-aware transport design. TCP remains appropriate when a single reliable ordered stream is exactly what the application needs.

Connection shutdown

TCP supports independent shutdown in each direction. A common graceful close includes a FIN and acknowledgment for one direction followed by a FIN and acknowledgment for the other. It is often illustrated as four segments, but four separate messages are not mandatory. An ACK can be combined with a FIN, one direction can remain open during a half-close, and an abortive shutdown can use a reset. The observed exchange depends on endpoint state, application behavior, and timing.

How UDP works

UDP is defined by RFC 768. Its header contains source port, destination port, length, and checksum fields. Unlike TCP, UDP preserves message boundaries. One application send normally creates one UDP datagram, although IP may fragment the resulting packet along the path.

UDP does not establish a transport connection before sending. That avoids TCP's connection-state machinery, but it does not make delivery immediate or assured. Routing, queues, firewalls, network address translation, radio conditions, receiver load, and application processing still affect latency and loss. Datagrams can be dropped, duplicated, delayed, or reordered.

Datagram boundaries and receive-buffer truncation

A successful datagram receive operation obtains one UDP datagram, not an arbitrary portion of a continuous stream. That statement describes message boundaries, but it does not mean every receive buffer is automatically large enough. If the application supplies a buffer smaller than the received datagram, many socket APIs copy only the portion that fits and discard the remaining bytes from that datagram. A later receive does not normally return the discarded remainder as though it were the next part of a stream.

The exact indication differs by operating system, programming language, and receive function. An API may return a truncation flag, report the original datagram length, return only the copied length, or signal an error. Applications must consult their socket API, allocate an appropriate maximum buffer, inspect truncation indicators where available, and reject incomplete messages. UDP's transport-level preservation of a datagram boundary does not guarantee that an application using an undersized receive buffer obtains the entire payload.

UDP checksums on IPv4 and IPv6

The UDP checksum covers the UDP header and payload plus an IP-derived pseudo-header. With IPv4, a transmitted checksum field of zero indicates that the sender omitted the UDP checksum. With IPv6, ordinary UDP usage requires a nonzero checksum. Narrow exceptions exist for specifically defined IPv6 tunnel scenarios, but general applications should not assume that the IPv6 UDP checksum is optional.

Like the TCP checksum, the UDP checksum is an error-detection mechanism rather than encryption, message authentication, or peer authentication. Sensitive traffic still needs a secure protocol with appropriate confidentiality and integrity protection.

Datagram size, fragmentation, and congestion

A large UDP datagram can exceed the usable packet size on a path. It may be fragmented by IP where fragmentation is supported, or fail when it is not. Losing one fragment prevents reassembly of the complete datagram. Robust UDP protocols therefore use conservative payload sizes and path-aware strategies rather than assuming that every network accepts the same large message.

UDP has no built-in congestion control. Internet applications using UDP should pace traffic and respond to signs of congestion. The IETF's UDP usage guidelines in RFC 8085 describe responsibilities for application designers, including congestion control, message sizing, reliability, checksums, and middlebox behavior.

QUIC is an important example of the distinction between UDP itself and a protocol built above it. QUIC uses UDP packets but adds acknowledgments, loss detection, reliable streams, flow control, and congestion control. Choosing UDP is not permission to transmit without regard for network capacity.

When to use TCP, UDP, or both

Start with application semantics. If an application consumes a reliable ordered stream and older data remains useful, TCP is often the straightforward choice. If messages are independently useful, stale messages quickly lose value, or the application requires IP multicast or broadcast on a local network, UDP may fit better. Building safe reliability, pacing, and congestion response above UDP is substantially more involved than simply sending datagrams.

Common TCP-oriented workloads

Traditional remote shells, many database wire protocols, mail transfer, file transfer, and HTTP/1.1 or HTTP/2 usually expect TCP semantics. Their records, requests, and responses must arrive in the correct byte order. TLS can secure protocols running over TCP, but TCP by itself does not encrypt traffic or authenticate either endpoint.

Common UDP-oriented workloads

Interactive media, some game-state updates, telemetry, service discovery, and certain request-response protocols can benefit from independent datagrams. This does not mean every game, media service, or sensor system always uses UDP. Designs vary, and many applications combine reliable control traffic with time-sensitive media or state traffic.

Using both transports

An application can use TCP and UDP for different functions, but those functions do not necessarily share a port. A system might use a reliable TCP control channel on one port and UDP media datagrams on another. Other protocols are intentionally designed to accept TCP and UDP on the same numeric port.

Localtonet supports TCP, UDP, and combined UDP/TCP tunnel categories. Use a combined tunnel only when the service actually listens for both transports at the same local IP address and port. If the application uses different local ports, configure tunnels that match its real protocol and port arrangement instead of treating a combined tunnel as a way to merge unrelated endpoints.

DNS, QUIC, HTTP/3, WebRTC, and SCTP

Modern DNS transport behavior

DNS is not accurately summarized as “UDP until a response exceeds 512 bytes.” Traditional DNS commonly uses UDP, but EDNS, specified by RFC 6891, lets endpoints advertise a larger supported UDP payload size. Operators often choose conservative sizes because fragmented responses can be unreliable across real networks.

If a UDP DNS response carries the truncation indication, a resolver can retry using TCP. Current guidance for DNS over TCP appears in RFC 7766. Conventional full zone transfers also use TCP. Encrypted DNS introduces further transport choices:

• DNS over TLS, or DoT, carries DNS over a TLS-protected connection as defined by RFC 7858.
• DNS over HTTPS, or DoH, carries DNS through HTTP as defined by RFC 8484. Its underlying transport depends on the negotiated HTTP version.
• DNS over QUIC, or DoQ, carries DNS directly over QUIC according to RFC 9250.

When exposing a DNS implementation for testing, verify every transport the implementation claims to support. A UDP-only tunnel cannot test TCP fallback, DoT, or an HTTPS endpoint. Public recursive DNS also creates significant abuse risk and should not be exposed without strict controls and an intentional security design.

QUIC and HTTP/3 are separate standards

QUIC is standardized in RFC 9000. Its use of TLS is specified in RFC 9001, while RFC 9002 covers loss detection and congestion control. HTTP/3 is standardized separately in RFC 9114 as the mapping of HTTP semantics onto QUIC. QUIC is therefore not another name for HTTP/3.

QUIC uses UDP as its substrate but adds secure connection establishment, acknowledgments, loss detection, reliable streams, flow control, and congestion control. A gap in one QUIC stream does not by itself prevent another stream from delivering data that is ready. The complete behavior is more nuanced than saying one lost packet affects only one stream. A packet can carry frames for multiple streams or connection-level state, and connection-wide congestion response can influence every stream sharing the connection.

WebRTC, RTP, DTLS, and signaling

The W3C WebRTC specification defines browser APIs used for real-time communications, while the full system relies on multiple IETF protocols for connectivity, media, security, and data channels. Interactive media commonly uses RTP, originally defined in RFC 3550, with SRTP protection. DTLS-SRTP, specified by RFC 5764, establishes keying material for protected media.

WebRTC does not define one universal signaling protocol. Applications exchange offers, answers, and connectivity candidates through an application-defined path such as HTTPS, WebSocket, SIP, or another mechanism. DTLS protection for media does not automatically secure this external signaling path. The signaling application must secure its own transport and authenticate participants.

ICE coordinates connectivity checks using candidates gathered from local interfaces and services such as STUN and TURN. Direct UDP connectivity may be preferred, but relay and fallback behavior depend on the deployment. A generic UDP tunnel is not a replacement for the complete ICE, TURN, identity, and media-security design.

SIP and RTP have different roles

SIP is a signaling protocol used to establish, modify, and end communication sessions. It is not itself the voice or video media stream. RTP and RTCP commonly carry and monitor media after signaling negotiates a session. A voice deployment can consequently use several protocols and ports. Inspect the actual server configuration before designing tunnels or firewall rules.

SCTP and WebRTC data channels

SCTP, currently specified by RFC 9260, is a message-oriented transport that supports reliable delivery, multiple streams within an association, and multihoming capabilities. Independent streams reduce delivery blocking between streams, although congestion and path behavior still operate at broader scopes.

Direct SCTP deployment on the public internet can encounter middlebox compatibility constraints. WebRTC data channels use SCTP carried over DTLS according to the WebRTC data channel protocol in RFC 8831, avoiding a requirement for browsers to expose native SCTP directly to the public network.

Prerequisites and Localtonet client installation

Localtonet exposes a service reachable from your device through a public host and port. The Localtonet client establishes an outbound connection to our relay, so the tunnel itself does not require inbound router port forwarding, a public IP address, firewall changes, or a separate VPN setup.

The current Localtonet download and installation documentation provides clients for Windows 64-bit, 32-bit, ARM, and ARM64 systems; Linux 64-bit, ARM, ARM64, and corresponding MUSL builds; macOS 64-bit and ARM64; Docker; and Android. It also documents a Termux ARM64 console-client option for Android and experimental OpenWrt packages for supported x64 and ARM64 firmware versions. Choose a build that matches the operating system and processor architecture of the device that can reach your service.

Desktop, Docker, Android, and other installation paths

For Windows and macOS, download the build matching the operating system and processor architecture, install or extract it as directed by the current download page, and run the client on the machine that can reach the target service. Linux users can choose the appropriate standalone architecture build or use the maintained DEB and RPM package workflow described below. Docker is available when a containerized client fits the deployment, but the container must have network reachability to the local target.

The Android application is a supported client path. For ARM64 Android devices that need the console client, the documentation also provides Termux ZIP and DEB packages. OpenWrt support is marked experimental and is limited to the listed x64 and ARM64 packages. OpenWrt package format and firmware version must match, and MIPS, MIPSEL, and ARMv7 are not supported by those packages. Check available storage, memory, architecture, and the current package instructions before installing on a router.

Linux DEB and RPM requirements

Installable DEB and RPM packages are available for x64 and ARM64. They require systemd 247 or newer and OpenSSL 3. Documented examples of suitable platforms include Debian 12, Ubuntu 22.04 or newer, and RHEL 9. Confirm these prerequisites before using the package workflow. If the host does not meet them, select another currently supported build rather than forcing an incompatible package.

Download the package for the machine's architecture, open a terminal in the directory containing it, and install it with the appropriate package manager. Use the filename that matches the downloaded architecture.

# Debian or Ubuntu, x64
sudo apt install ./localtonet-linux-x64.deb

# Debian or Ubuntu, ARM64
sudo apt install ./localtonet-linux-arm64.deb

# Fedora or RHEL, x64
sudo dnf install ./localtonet-linux-x64.rpm

# Fedora or RHEL, ARM64
sudo dnf install ./localtonet-linux-arm64.rpm

Configure and protect the Linux authentication-token file

After installing the package, edit /etc/localtonet/auth-token as root. Replace the package's placeholder with the actual device authentication token on one line. Do not include the real token in a shell history, article, screenshot, repository, or support message.

Restrict the file to its owner, then run the documented configuration check. The check should succeed before the system service is started.

sudo chmod 600 /etc/localtonet/auth-token
sudo localtonet --headless --authtoken-file /etc/localtonet/auth-token --check-config

Start the Linux service and inspect logs

Once the configuration check succeeds, enable and start the standard Localtonet service. Then inspect its journal to confirm that the client starts correctly. This service is for the regular Localtonet client used by TCP, UDP, and UDP/TCP tunnels. VPN Manager has a separate service workflow and is not required for a standard port tunnel.

sudo systemctl enable --now localtonet.service
sudo journalctl -u localtonet.service

The journal command displays service output. Use the normal journal controls on the host to follow or limit output when troubleshooting, and avoid copying sensitive content into public reports. Confirm that the intended device connects before creating or starting a tunnel.

Upgrade a Linux package installation

To upgrade, download and install the new package through the same package manager. The documented package workflow preserves the configuration. Restart the standard service after installation so the new version is running:

sudo systemctl restart localtonet.service

After restarting, inspect the service journal and confirm device connectivity before relying on an existing tunnel. An upgrade does not remove the need to verify the local application, client connection, and tunnel running state.

How to create and run a TCP, UDP, or UDP/TCP tunnel

The tunnel category must match what the local application listens for. A TCP client cannot communicate with a UDP-only service merely because both use the same numeric port, and the reverse is also true. The shared documented workflow for these raw-port tunnels is to run the client, choose the tunnel type, select the connected device token and relay server, provide the local target, and start the tunnel.

Configure the remote application with the public host and port assigned to the running tunnel. When access is no longer required, stop the tunnel. Delete it if the configuration will not be reused. Stopping and deleting are distinct lifecycle actions: stopping removes current availability while retaining the saved configuration, and deleting removes the configuration.

Choosing a safe local bind address

If the service and Localtonet client run on the same machine, binding the service to loopback can reduce unnecessary LAN exposure. If the service runs inside a container, virtual machine, or another local device, the Localtonet client needs a target address it can actually reach. Do not change a service to listen on every interface unless necessary and protected by appropriate host and application controls.

Container networking deserves particular attention. A loopback address inside one container refers to that container, not automatically to the host or another container. Verify connectivity from the environment where the Localtonet client runs and use the reachable address established by the container or virtual-network configuration.

Verify operation and troubleshoot failures

Verify TCP locally and publicly

First connect to the local TCP target from the Localtonet client device using the application's normal client. A successful socket connection is only the first check. Send a valid protocol request, authenticate where required, and confirm that the expected response arrives.

After starting the tunnel, repeat the same application-level test from a separate external network using the assigned public host and port. A generic connection probe can show whether TCP opens, but it cannot prove that the application protocol is healthy. TLS-based services should also be checked for the expected certificate, hostname handling, and protocol negotiation.

nc -vz PUBLIC_HOST PUBLIC_PORT

This is a generic example for systems with a compatible Netcat implementation. Replace the placeholders with the values assigned to the tunnel. Netcat options vary across operating systems, so use the platform's equivalent connection tester where necessary.

Verify UDP locally and publicly

UDP verification must be protocol-aware because UDP has no connection handshake. A generic sender may report success merely because the local operating system accepted a datagram for transmission. That result does not prove that the remote application received it, processed it, or replied.

Use the service's native client to send a valid request and confirm an expected response, state change, log entry, or packet capture. Test locally first, then test the public endpoint from another network. If the protocol is intentionally one-way, use receiver logs or a packet capture to confirm arrival. Do not treat the absence of an immediate socket error as proof of delivery.

Verify combined UDP/TCP services

Test TCP and UDP independently. A successful TCP connection does not verify the UDP path, and a UDP response does not verify the TCP listener. Confirm that both local listeners use the same intended address and port before attributing a failure to the tunnel.

Routine operation

Keep the application, Localtonet client, and tunnel under intentional operational control. Monitor the application's own logs for authentication failures, malformed requests, resource exhaustion, and unexpected clients. If the local target changes after a restart or network reconfiguration, update the tunnel target and verify it again.

Stop tunnels when a maintenance task, demonstration, or test ends. Deleting an unused configuration reduces the chance that someone later starts an obsolete endpoint pointing at the wrong service. If a device token might have been disclosed, treat it as a credential incident and replace or revoke it through the current account workflow.

Security guidance for public TCP and UDP exposure

A public host and port can be discovered, scanned, and tested by arbitrary internet clients. A tunnel changes reachability, not the security model of the application behind it. Raw TCP and UDP services do not automatically gain user authentication or application-level encryption merely because they are tunneled.

Special risks for UDP services

A publicly reachable UDP service can be abused if it sends a response much larger than an unauthenticated request, particularly when attackers can spoof source addresses elsewhere in the path. DNS and other request-response services require careful anti-abuse configuration. Avoid exposing an unrestricted recursive resolver or another reflection-capable service.

UDP applications also need resource controls. Rate limiting, validation, bounded queues, conservative message sizes, and congestion-aware sending help reduce accidental overload and malicious packet floods. Authenticate messages when the protocol supports it and reject malformed input before allocating expensive resources.

Protect the Localtonet device token

A Localtonet authentication token identifies the client device that can run a tunnel. Do not place it in a repository, container image, screenshot, chat message, shell example, or published tutorial. On packaged Linux installations, keep the documented token file restricted to mode 600. If a token is exposed, rotate or revoke it instead of relying on deletion from one visible location.

Frequently asked questions