My VPN provider gives me the option between using UDP and TCP for connections. According to this site UDP is faster over short distances. I'm on the same continent as my server, is that considered short distance? Is there a test I can run to compare the two?

  • Adding to the question what will happen if send tcp traffic over UDP VPN tunnel?
    – Ali Ahmad
    Jan 10, 2013 at 6:44

5 Answers 5


A VPN is for wrapping raw IP packets into some kind of "tunnel" between two sites (one of the site being possibly reduced to one computer, i.e. yours). TCP is a protocol which sits on top of IP, and uses IP packets (which are "unreliable": they can get lost, duplicated, reordered...) to provide a reliable two-directional channel for data bytes, where bytes always reach the receiver in the order they were sent. TCP does that by using a complex assortment of metadata with explicit acknowledges and reemissions. Thus, TCP incurs a slight network overhead.

If the VPN uses TCP, then your own TCP connections will use IP packets sent through the VPN, so you end up paying the TCP overhead twice. An UDP-based VPN thus has the potential for slightly better performance. On the other hand, the cryptographic protection of the VPN requires some state management, which may be harder for the VPN implementation when using UDP, hence it is possible that the UDP-based VPN has an extra overhead to contend with.

Therefore, the performance situation is not clear, and you should measure.

  • I didn't get your point of "paying up TCP overhead twice" in the case of VPN using TCP connections. Can you please expand on it a little bit?
    – Geek
    Nov 14, 2014 at 14:24
  • 5
    TCP provides a bidirectional tunnel for data, but relies on packets, so there will be some "administrative" packets, e.g. acknowledges: this is the TCP overhead. For instance, if machine A sends 10 MB to machine B, machine B will also send some packets to A confirming reception. When you do a VPN over TCP, the VPN has its own TCP-based overhead, and transports the administrative packets for any connection within the VPN -- this is the "pay twice" thing. Nov 14, 2014 at 14:27
  • 4
    Here's a pair of pictures for the visually-inclined. They're probably not quite correct and perhaps a bit simplified but they should give you the idea. HTTP request over TCP VPN and HTTP request over UDP VPN. Note the extra back-and-forth between the VPN client and VPN server down the middle: that's your extra overhead (the VPN server has to ACK the encapsulated packets from the client and vice versa -- including the SYN/ACK packets between the client and destination server)
    – Doktor J
    Jul 24, 2017 at 14:31

You could try downloading a file via either method and seeing if the download speeds are drastically different.

The trade-offs between TCP and UDP (regardless of VPN usage) is always the same: You sacrifice speed for reliability as UDP is connectionless and the server sending the data theoretically (depending on the implementation) doesn't care if it reaches the destination or not. This is fine in things like Internet gaming where each packet might be a movement by a user, but in things like encryption where missing bits of data means that an entire message may need to be re-sent, TCP would be more welcome as the time gained by using UDP might be lost by having to re-send an entire message.

Being on the same continent is not generally considered a short distance. I would consider being in the same building, perhaps in the same city as a short distance but not much further than that. The more hops a packet has to go through, the more likely it will be corrupted at some point along the way. If you want to see how many hops it takes to get to your destination, try running a "trace route" command.

Hope I've helped.

  • 1
    Disagree that you're trading speed against reliability. Firstly for a TCP stream it needs reliable delivery - it doesn't matter if it's implemented directly on the underlying network or if it's tunelld in UDP packets - if packets go astray they must be resent in order to process the stream. But sometimes the congestion control methods in TCP are counter productive. On a high BDP network, it can take a very long time to recover after a couple of dropped packets. Running out of space...short answer is it depends on your network, it's not as simple as that page says. You have to test Ur network
    – symcbean
    Jan 10, 2013 at 23:53

UDP is perferred for VPNs, the overhead is lower. This discussion about unreliability of UDP is moot. Since we're tunelling, there's no difference between a TCP datagram lost on the open internet and a TCP datagram lost in a TCP tunnel or a TCP datagram lost in a UDP tunnel. All will be retransmitted.

A problem with UDP tunnels are that they're stateless, this makes it harder to secure at the firewall. Reply packets are no different than source packets. From a security perspective, TCP tunnels are easier.


This is really the same as TCP and UDP normally are. TCP is a system where by every packet is guaranteed to arrive in order. If a packet is received out of order, it is stored and if a packet doesn't show up to fill in a gap, it is re-requested. This ensures a complete stream with no data lost, but it means that a connection may be held up by one missed packet while the information is requested again.

UDP on the other hand makes no such guarantee and information will arrive in whatever order it arrives and be processed as such. I'm not sure about the security implications exactly, but you would likely still get a similar delay in UDP if using a non-parallelizable chaining stream cipher since it would need all the packets to arrive in order, but this could also be overcome by using an encryption mode that supports parallel decryption.

So basically, the only thing that VPN adds to the typical TCP/UDP mix is that it limits the nature of which encryption modes can be used a little, but is otherwise the typical trade off.

  • I'll ask my typical question about why the downvote? I know the TCP/UDP part is accurate. Was there something I missed about the implications for a VPN? Jan 11, 2013 at 4:19

Actual physical point to point distance means nothing in the internet world, it all depends on ISP inter-connections. One time I pinged a server in the rack next to me and it had a 300ms delay because the packets were routed across the pacific and back because that was how the ISPs were connected to each other. If the servers had been directly connected the delay would have been in the microseconds. The servers were inches away from each other but the actual distance that the packets traveled round-trip over all the hops was on the order of 25,000 miles! That is an extreme example, but it illustrates that you can't trust distance.

Rather than distance you need to look at latency, that is the round trip time it takes for an echo sent to the VPN destination to be replied to. As for what round trip time would make UDP a better choice than TCP I do not know, and it isn't that simple as there are other factors:

  • packet loss and jitter: UDP is very sensitive to packet loss and jitter (out of order packet) and it has no built-in correcting mechanism like TCP does. Any latency or jitter will erode any benefit of using UDP over TCP
  • OS IP stack efficiency: the VPN application will be using the operating system's TCP/IP stack, which will also process UDP packets. Much of the relative efficiency of TCP versus UDP will be down to how well the OS (and any packet filtering or firewalls in the way) processes TCP versus UDP
  • Application coding: The VPN application's quality will make a big difference, as will the VPN software on the device you are connecting to. For instance, how does it recover from lost UDP packets? Can it request re-transmissions or does it rely on the upstream applications to request retransmissions?

There are too many factors to give you a definitive answer as it depends on too many factors. You'll simply have to try both methods and see.

  • 1
    It won't re-request the UDP packets but it will re-request the tunneled TCP packet by tunneling that request within a new UDP packet. Of course, TCP-within-TCP means that both will be re-requested.
    – Ladadadada
    Jan 11, 2013 at 8:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .