What's the difference between VPN over TCP vs UDP?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.