Differences between TCP and UDP ports and when to use each one

When we delve into the world of networks, sooner or later the typical question arises: What are the real differences between TCP and UDP ports? and when it's best to use one or the other. Although at first glance we only see port numbers (80, 443, 3389, 53…), underneath there are two very different ways of moving data over the Internet that impact speed. reliability and even in security.

In this article we will calmly break it down How TCP and UDP work, what role ports play, and what protocols each uses.how they affect everyday things like browsing, playing online games, making video calls or connecting via remote desktop, and what implications they have in terms of performance, ciberseguridad and firewall configuration.

TCP and UDP: two different ways to transport data

Before discussing ports, it's important to understand that TCP (Transmission Control Protocol) and UDP (User Datagram Protocol) are transport layer protocols of the TCP/IP model, and they define the style of communication between source and destination.

TCP is a connection-oriented protocolBefore sending data, it establishes a logical channel between sender and receiver using the well-known "three-way handshake" (SYN, SYN-ACK, ACK). From there, it numbers the segments, ensures they arrive in order, detects errors, requests retransmissions, and adapts the transmission speed according to the network and receiver capacity.

UDP, on the other hand, is a connectionless protocolThere is no establishment phase; the sender simply sends datagrams to the destination without waiting for confirmation or tracking. It does not order the packets, guarantee delivery, or apply flow or congestion control mechanisms. In return, it greatly reduces overhead and latency.

Based on this, the big practical difference is that TCP prioritizes data reliability and consistencyWhile UDP focuses on speed and simplicityaccepting that some of the information may be lost along the way.

What exactly is a TCP or UDP port?

A port, in both TCP and UDP, is simply a number from 0 to 65535 that identifies which service or application a data stream should reach within a device. Together with the IP address, it forms the famous "socket" (IP:port) that applications use to listen for and send traffic.

When we talk about "TCP port" or "UDP port," we're not talking about different numbers, but rather different types of transport associated with the same port numberFor example, 53/TCP and 53/UDP coexist for DNS, or 3389/TCP and 3389/UDP for RDP from certain versions onwards.

The numbering is organized in three ranks with clearly differentiated uses shared by TCP and UDP:

• Well-known ports (0-1023): reserved by IANA for standard services such as HTTP (80/TCP), HTTPS (443/TCP), FTP (21/TCP), SSH (22/TCP), DNS (53/TCP and 53/UDP), etc.
• Registered ports (1024-49151): assigned to specific applications, such as 3306/TCP for MySQL or 1194/UDP in many OpenVPN deployments.
• Dynamic or private ports (49152-65535): used temporarily by clients for ephemeral sessions; they are assigned on the fly by the operating system.

Thanks to this organization, a single server can Listen on multiple services simultaneously (web, email, database, VPN…) without the data flows getting mixed up, since each one occupies its own port.

Key features of TCP: reliability above all

TCP is designed so that the data arrives complete, without errors, and in the same order in which it was senteven over an IP network that, by design, is "best effort" and guarantees nothing.

To achieve this, TCP uses several fairly sophisticated mechanisms:

• Segment numbering and ACKEach segment carries a sequence number, and the receiver sends acknowledgments (ACKs). You can use selective ACKs to validate multiple segments at once.
• Checksums: all segments carry a checksum to detect data corruption; if it fails, the segment is discarded and requested again.
• TimersIf a certain amount of time passes without receiving an ACK from a segment, the sender assumes loss and automatically retransmits it.
• Duplicate filterIf the same segment arrives twice, TCP detects the duplicate by its numbering and discards it.

In addition, TCP implements flow control based on sliding window: the receiver announces how many bytes it can store in its buffer and the sender cannot exceed that limit until it receives new ACKs that "slide" the window.

In parallel, TCP includes a congestion control with its own window (congestion window), which attempts to prevent the network from becoming saturated. If it detects packet loss (indicative of congestion in a router), reduces its pace; when the road is clear, it increases it again in a controlled manner (slow start, congestion avoidance and stable phase phases).

With There have been appearing increasingly advanced congestion algorithms, like Tahoe and Reno in their early days, Vegas, CUBIC (very used in Linux) or BBR, designed by Google to make better use of available bandwidth without overloading the network.

Another important advantage is that TCP is full-duplex and allows multiplexingData can be sent and received simultaneously over the same channel, and a host can maintain multiple open sockets to different destinations or services simultaneously.

TCP header, MSS and overload

Each TCP segment carries a header that, at a minimum, occupies 20 bytes (more options if available)In it we find:

• Port of origin and destination (Source Port, Destination Port).
• Sequence number y acknowledgment number (ACK).
• Flags such as SYN, ACK, FIN, RST, URG, etc.
• Reception window sizevital for flow control.
• Checksums and possible options (for example, window scaling).

The maximum segment size is determined by the MSS (Maximum Segment Size), defined at the transport level. It is usually calculated as: MSS = MTU − IP header − TCP headerIn a typical Ethernet network (MTU 1500) and minimal headers, we are talking about 1460 bytes of useful data.

Although this relatively large header increases overhead, it allows TCP integrate all those control mechanisms which gives it its high level of reliability.

Establishing and closing TCP connections: 3-way handshake and END

To begin exchanging data with TCP, you first need to Establish a logical connection between client and serverThe classic process is the 3-way handshake:

1. The client sends a segment with the flag SYN and an initial sequence number.
2. The server responds with SYN-ACK, indicating their own sequence number and confirming the customer's.
3. The client sends a final segment with ACK From there, both sides can start sending data bidirectionally.

This negotiation of sequence numbers makes it difficult for an attacker from outside to easily spoof an already established TCP connectionHowever, if it is in the middle (MitM) it can still manipulate traffic.

To close the session, one of the parties sends a segment with FINThe other side responds with ACK and usually also sends its own FIN, which must be acknowledged. In some cases, a "half-open" connection can remain, where one side has closed the connection but the other continues to send data.

TCP-related attacks and vulnerabilities

Precisely because of that connection, TCP is susceptible to SYN flood denial-of-service attacksThe attacker sends a large number of fake SYN segments, leaving the server with lots of half-open connections that consume resources.

To mitigate these attacks, measures such as the following are usually applied: limit the number of simultaneous connections (global or by IP), filter by trusted address ranges or use techniques such as SYN cookies, which delay the actual reservation of resources until reliable confirmation is obtained.

Another classic attack is the TCP sequence number predictionIf an attacker can guess the values ​​a legitimate host will use, they can inject fake packets that appear to be part of the connection. To achieve this, they typically first eavesdrop on the traffic between two trusted computers, estimate the numbering pattern, and sometimes launch denial-of-service attacks against the real host to "silence" it while they spoof its session.

Once the connection is established, the attacker can inject arbitrary dataThis can lead to session termination or unexpected behavior in the target application. Older, unpatched systems and devices are often the easiest targets for these techniques.

What is UDP and why is it so fast?

UDP was designed with a different philosophy: send datagrams with the least possible overheadleaving almost all control to the upper layers. It does not establish a pre-connection, reorder, retransmit, or regulate the transmission rate.

The sender simply sends UDP datagrams to the destination port, assuming the receiver has an open socket listening. If there is congestion, if the receiver is slower, or if a router decides to drop packets, UDP does absolutely nothing to correct it.

Its headboard is very small, only 8 bytes, with four basic fields:

• Port of origin.
• port of destination.
• Datagram length.
• Checksums (for header and data).

Thanks to this simplicity, Most of the package is dedicated to payload.This greatly improves efficiency, especially in real-time communications and in environments where minimizing latency is a priority.

However, since there is no flow or congestion control, if a transmitter is much faster than the receiver or the networkDatagrams will begin to be lost, and the responsibility for managing that loss falls entirely on the application.

Practical advantages and disadvantages of TCP and UDP

In short, we could say that TCP is slower but very reliable, and UDP is faster but less reliableLet's bring this down to real-world use cases.

TCP is the ideal option when data integrity is critical: email, web browsing, file transfer, remote administration, databases… In all these cases, it makes no sense to receive corrupt or incomplete information, even if it takes us a few milliseconds longer.

UDP shines in environments where immediacy is the priority, such as online gamesVoIP, video calls, live streaming, DNS, DHCP… Here it is preferable to lose a packet and have the video pixelate for a moment, rather than stop playback to wait for a retransmission.

In terms of data consumption, TCP also has more overhead than UDP.Its headers are larger and generate additional traffic from acknowledgments and retransmissions. In real-world tests with VPN It is observed that OpenVPN over TCP can consume several percentage points more data than over UDP for the same useful information.

In terms of pure security, neither protocol is designed to encrypt or authenticate on its own, although The TCP structure makes malicious traffic injection a little more difficult Thanks to sequence tracking and ACKs. In practice, when we use TLS, VPNs, or encrypted tunnels, both TCP and UDP rely on higher layers to protect the content.

Lastly, UDP enables multicasting and broadcasting naturally, which makes it easier to send the same flow to many receivers at once (videoconferences, streaming to multiple clients, discovery protocols), something that TCP, being strictly point-to-point, cannot do.

How TCP and UDP fit into VPNs

VPN services rely on TCP or UDP to create the encrypted tunnel between client and server. In practice, Most modern VPN protocols prefer UDP because it reduces latency and better supports scenarios of moderate packet loss.

In OpenVPN, for example, you can choose between TCP or UDP tunnelWhen using UDP, much of the reliability is delegated to the applications inside the tunnel (usually TCP again, such as HTTP/HTTPS), avoiding a double layer of error control that would only add delay.

This means that an OpenVPN tunnel over UDP It might lose some packets, but if HTTP traffic (which uses TCP) is traveling inside, it will be that internal TCP that requests retransmission when necessary. The practical result is a secure connection, reliable at the application level, but much faster at the transport level.

WireGuard goes a step further and It uses UDP exclusively as its transport mechanism.All the complexity is moved to its own cryptographic and control logic, achieving minimal setup times and very fast roaming when we change networks (for example, from Wi-Fi to 4G) without the VPN being noticeable.

However, in environments where firewalls are very restrictive with UDP (some corporate networks), many VPNs are forced to Dropping to TCP to bypass filters and proxies, at the cost of slightly increasing latency.

TCP vs UDP on the web and the evolution towards QUIC

Nowadays, HTTP and HTTPS almost always rely on TCPClassic HTTP normally uses port 80/TCP and HTTPS uses 443/TCP, adding TLS to encrypt communications.

Up to HTTP/2 the picture was clear: The entire website ran over TCP, with its reliability advantages but dragging along certain problems of latency and header blocking in high-loss connections.

HTTP/3 enters the scene QUIC, a transport protocol built on top of UDP It integrates features of TCP (congestion control, error correction, flow ordering) and TLS (encryption required). QUIC allows multiplexing several independent streams over the same connection, reducing the impact of packet loss on any one part of the communication.

Thanks to that, HTTP/3 over QUIC typically offers faster loading times, Especially in mobile networks or high-jitter connections. Furthermore, by using UDP, it better overcomes certain bottlenecks in legacy infrastructure designed solely for TCP.

TCP and UDP ports in real-world services: examples and table

The combination of transport type and port number defines which application layer protocol is being usedSome very common examples:

• 80 / TCPHTTP (unencrypted web).
• 443 / TCP: HTTPS (web encrypted with TLS).
• 21/TCP and 20/TCPFTP (control and data).
• 22 / TCP: SSH and SFTP.
• 25/TCP, 587/TCPSMTP for sending email.
• 110/TCP, 995/TCP: POP3 and POP3S.
• 143/TCP, 993/TCP: IMAP and IMAPS.
• 53/UDP and 53/TCP: DNS (fast queries via UDP, zone transfers via TCP).
• 67/UDP and 68/UDPDHCP client/server.
• 123/UDPNTP, time synchronization.
• 161/UDP: SNMP.
• 445 / TCPMicrosoft SMB/CIFS for file sharing.
• 554/TCP/UDP: RTSP for stream control.
• 631/TCP/UDP: IPP (network printing).

The complete list of well-known and registered ports is very extensive, but it serves to show that TCP usually dominates in critical and transaction-oriented applicationsWhile UDP rules in discovery, streaming, or lightweight control protocols..

RDP: TCP, UDP, or both?

El Remote Desktop Protocol (RDP) Microsoft's service allows you to connect to another computer as if you were sitting in front of its screen. Internally, it sends a compressed desktop image from the remote host to the client and receives keyboard and mouse input in the opposite direction.

Traditionally, RDP has used the port 3389/TCP as the primary transport, leveraging the reliability of TCP to ensure that every screen update, click, and control packet arrives correctly and in order.

Since RDP 8.0, the protocol can also use 3389/UDP to optimize performanceNormally, the client will first try to establish a UDP channel (due to its lower latency and higher bandwidth) and, if this is not possible due to network restrictions, will fall back on the classic TCP channel.

This hybrid approach allows RDP send the bulk of the graphic data via UDPwhere the loss of a few frames is barely noticeable, and TCP can be reserved for strictly critical information if necessary. In networks with high latency or signal loss, the improvement in performance can be very significant.

How to open TCP and UDP ports for RDP on Windows

For an RDP session from outside to work, the host's firewall must allow incoming traffic on port 3389Both TCP and UDP are necessary if we want to take advantage of modern optimizations; if there are problems, it's advisable to review the network policies that block RDP.

En Windows, basic setup from the Firewall of Windows Defender is:

1. Walk into Control Panel > System and Security > Windows Defender Firewall and open the advanced settings.
2. Create new inbound rule of type "Port", select TCP and specify 3389 as the specific local port.
3. Select "Allow connection", apply to the necessary profiles (domain, private, public) and give a descriptive name, for example "RDP TCP 3389".
4. Repeat the process to UDP on the same port 3389, with another name such as "RDP UDP 3389".
5. Verify that both rules are enabled and test the connection from a remote client.

In terms of security, in addition to opening ports, it is vital Use strong passwords, Activate Network Level Authentication (NLA) to ensure that only validated users can log in to the graphical session, limit which accounts have remote access permission, and keep the system always up-to-date to prevent vulnerabilities in the RDP service.

TCP ports: security, risks and best practices

Any TCP port exposed to the Internet becomes a possible attack vectorAttackers automate scans of entire IP ranges looking for open ports (using tools like Nmap) and, once detected, test for known vulnerabilities or brute-force attacks.

Highly sensitive services such as SSH (22/TCP), RDP (3389/TCP), SMB (445/TCP) or databases These are priority targets, since a failure there could give direct access to the internal network or critical data.

To reduce the attack surface, it is advisable to apply the principle of minimum privilege in ports: only open those strictly necessary, restrict access by IP or VPN when possible, and close or filter everything that is not used.

It's also a good idea segment the network into zones (user LAN, server DMZ, management network, etc.) and use internal firewall rules to isolate critical services. This way, even if an attacker compromises one machine, it will be more difficult for them to move laterally to other sensitive systems.

The use of monitoring and logging tools It allows the detection of anomalous patterns in ports (scans, massive failed attempts, connections from unusual countries), triggering alerts before the incident escalates.

Finally, it is advisable to carry out periodic port audits Use external and internal scanners and document which service is listening on each one. This helps identify outdated applications, forgotten services, or dangerous default settings that should be disabled.

Performance differences between TCP and UDP ports

When we compare traffic traveling over TCP ports versus UDP, what we are really measuring is the behavior of both transport protocols under different network conditions.

TCP, with its error and congestion control, tends to slow down when it detects loss or saturationprioritizing that everything arrives correctly rather than quickly. In congested networks or with high latency, this can translate into longer loading times or downloads less agile.

UDP doesn't let congestion stop it: If the path is congested, routers simply drop packetsSince there is no automatic relay, communication remains fluid, but with information gaps that the application will have to manage (for example, with buffering or its own error correction).

In tests with VPNs and large geographical distances, it is observed that OpenVPN over UDP is usually significantly faster than over TCPThe difference becomes more pronounced as network conditions worsen. This is due both to the smaller header and the absence of continuous ACKs and retransmissions.

There is also an impact on the data consumptionBetween heavier headers and additional control messages, TCP uses more bandwidth for each useful MB transferred. On mobile connections with gigabyte limits, this can make a difference at the end of the month.

Other transport protocols beyond TCP and UDP

Although in practice almost all of the Internet works with TCP and UDP as a baseThere are other transport protocols designed for specific use cases.

One of them is SCTP (Stream Control Transmission Protocol)It combines features of TCP and UDP: it offers reliable and ordered transmission, but allows multiple independent flows within the same connection. It is widely used in advanced telecommunications and VoIP signaling, where it reduces latency compared to traditional TCP.

Another one is DCCP (Datagram Congestion Control Protocol), which maintains UDP's offline style but incorporates integrated congestion controldesigned for real-time multimedia where losing packets is preferable to introducing too much latency.

Also RDP (Reliable Data Protocol), with a focus on military and scientific environments, and, as already mentioned, HERE C, which relies on UDP but implements reliability, multiplexing and encryption in a single layer, being the basis of HTTP/3.

Despite its technical advantages, the reality is that The mass adoption of new protocols is complicated: the entire ecosystem of routers, firewalls, OS Applications are optimized for TCP and UDP, and changing that foundation involves effort, cost, and risk. Furthermore, many firewalls block rare protocols by default, while TCP 80/443 traffic and a significant amount of UDP are almost always allowed.

Understand well How TCP and UDP ports work, what services rely on each, and what implications they have for performance and security. This is what allows us to make sensible decisions: when it's worth sacrificing some speed to gain reliability, when it's advantageous to use UDP to reduce latency, which ports to open or close in a firewall, or which parameters to adjust in a VPN or server to ensure our network runs smoothly and is as unobstructed as possible to attacks.