TCP vs UDP: differences, examples, and when to use each protocol

Published on 2026-10-20 by frfrand

TCP entrega un flujo fiable y ordenado; UDP envía datagramas sin esas garantías. Entendé la diferencia con ejemplos de web, juegos, DNS y QUIC.

TCP and UDP are transport protocols used to send data between applications over a network. TCP provides a reliable and ordered byte stream; UDP sends datagrams without guaranteeing by itself that they arrive, that they arrive only once, or that they arrive in the same order.

This does not mean that TCP is always better. Each protocol solves different needs. To understand them, imagine that you need to send information between two computers.

With TCP, the transport confirms receipt, recovers losses, and presents the bytes in order. With UDP, you send individual messages and the application decides what to do if any are lost.

There is an important detail: TCP does not preserve message boundaries. If you send two blocks, the receiver could read them together or in several parts. The application must define how to separate them. UDP does preserve the boundary of each datagram, although it does not promise its delivery.

How TCP works?

Before exchanging data, the endpoints establish a connection. TCP uses sequence numbers, acknowledgments, retransmissions, and flow and congestion control mechanisms.

Thanks to that, an application receives an ordered stream even if some segments are lost along the way. Recovery has a cost: when data is missing, the application cannot simply treat it as received.

TCP is common in SSH, many database connections, and HTTP/1.1 or HTTP/2 over TLS.

TCP by itself does not encrypt content. When confidentiality is needed, security layers such as TLS are used. That is why a reliable transport should not be confused with a secure connection.

How does UDP work?

UDP allows sending datagrams without TCP's connection establishment phase. Its header is smaller and leaves it up to the application to decide what to do in case of losses, delays, or duplicates.

That does not mean UDP is always faster or less secure. An application can build authentication, encryption, congestion control, and loss recovery on top of UDP.

An important example is QUIC, used by HTTP/3. QUIC runs over UDP and adds connection, security, and reliable delivery mechanisms when appropriate.

That is why it is incorrect to say that "all websites use TCP": HTTP/3 uses a different transport, even though the browser continues to display a normal web page.

TCP vs UDP: a quick comparison

| Question | TCP | UDP | |---|---|---| | How does it deliver data? | Continuous stream of bytes | Individual datagrams | | Does it guarantee delivery and order? | Provides reliable and ordered delivery mechanisms while the connection operates | Does not provide those guarantees by itself | | Does it need to establish a connection? | Yes | No, although an application over UDP can do so | | Does it include native encryption? | No | No | | Where does it appear? | SSH, several databases, HTTP/1.1 and HTTP/2 | DNS queries, certain real-time applications, QUIC |

The practical question is not which one is "more modern," but what guarantee your application needs. If you transfer a document, it usually matters to receive it complete. If you send dozens of positions per second in a video game, it may be preferable to receive the most recent update rather than waiting for an older one. Even so, each application can add its own logic over either transport.

What changes when configuring the firewall?

TCP and UDP use port numbers, but they are distinct protocols. Allowing 443/tcp is not the same as allowing 443/udp. A website serving HTTP/3 may require UDP on the corresponding port; another that only uses HTTP/2 may work with TCP.

Before opening ports, check the protocols your server actually uses. Having both open "just in case" is not a security policy. And even if a port is allowed in the firewall, that does not prove that a service is listening behind it.

You can expand the explanation in what is a firewall in Linux, where network rules are described with examples.

Example: multiplayer video games

In an action game, receiving the player's position 200 milliseconds ago may be less useful than receiving their current position. Some applications send frequent updates and tolerate occasional losses, so UDP can be a good basis.

This does not mean that all traffic in a game should be UDP. Movements, chat, purchases, and important events may require different strategies.

Example: DNS queries

DNS frequently uses UDP for traditional queries, but it can also use TCP and other transports depending on the operation and protocol used.

The phrase "DNS only uses UDP" leads to incomplete network configurations. An administrator must check what transport their service actually needs.

Three common mistakes

"UDP is always faster." Final performance depends on the application, the network, and the guarantees you need.

«TCP avoids all errors». TCP recovers losses while the connection is working, but it does not replace data validation or failure handling.

«UDP is only for streaming». It is used in DNS, games, and modern protocols such as QUIC.

How does it relate to ArduMaker?

In ArduMaker, when deploying an application on a VPS, it is also necessary to know whether the service uses TCP, UDP, or both. Port configuration depends on the actual protocol of the application.

In summary: choose TCP when you need a reliable and ordered flow provided by the transport. Consider UDP when you work with datagrams and want to manage times, losses, or guarantees in another way, as QUIC does.

Official sources: TCP, RFC 9293 · UDP, RFC 768 · QUIC, RFC 9000 · HTTP/3, RFC 9114.