• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

VPN. TCP or UDP?

John Connor

John Connor

Lifer
I have a VPN and the connection software offers either a TCP connection or UDP connection. Which would be better to use? What is really the difference?
 
Look up the differences between UDP and TCP. The benefits for either for VPN is the same. TCP is slower and generally more overhead both CPU and Network (stack) but has a guarantee of delivery. UDP is faster, less overhead but you have to hope the packets arrive. Errors are left up to the VPN device handle.
 
dave_the_nerd said:
So... if you get charged by the byte, use TCP, otherwise, use UDP?
Click to expand...

It would be the reverse. UDP is less overhead / less "bytes."

The big difference is the TCP is connection oriented and UDP isn't. TCP verifies packets arrive and handles resends, send acknowledgements and the like. UDP doesn't. It fires and forgets. It expects something higher up the stack to handle it.

So assuming that the connection is solid, UDP will transmit faster with less overhead. TCP however will help keep a crappy connection sorted.
 
Last edited:
imagoon said:
It would be the reverse. UDP is less overhead / less "bytes."
Click to expand...
Oh, okay.

2url8gi.jpg


Got it.
 
The protocols that run inside the tunnel will already, usually, be TCP based.

What happens when the tunnel (running in TCP mode) doesn't receive an ACK to the last TCP segment, it asks for a re transmit. While we are waiting for the tunnel to re transmit the data, the application actually sending the data through the tunnel doesn't receive it's ACK and it asks for the data to be re transmitted. The tunnel still wants the initial request to transfer data fulfilled even though the application is just going to ask for it to be sent again anyway.

You want your tunnel to behave as much like an Ethernet connection as possible, and Ethernet is connection-less, and relies on the layers above to provide reliability.

So to agree with everyone else, you want UDP.
 
Yep you want UDP as most of the protocols inside will probably be TCP anyway and have the proper protections.

TCP does not use compression it just has more overhead due to the handshakes and stuff. (simply put)
 
John Connor said:
Just tried UDP and the speed went down using speedtest.net. I assume UDP doesn't use compression and TCP does?
Click to expand...

Compression is irrelevant to both protocols.

Slower speeds on UDP likely indicates that the UDP side is overloaded or the connection is crap and the packet loss is causing the VPN app to keep resending.
 
UDP is about 4x as fast with my OpenVPN server. With TCP i get around 2MB/s and with UDP i get 8MB/s

However i run it on port 443 TCP as that's very rarely blocked by firewalls 😉
 
I'm at work now VPNed at home so was curious and did a speedtest too (UDP) this is what I get:



My home connection is 50/30 but I guess being VPNed a download is technically an upload and an upload is a download but technically it's doing both since the data has to go to my home network then to me so I get capped by my upload. Still pretty decent though. I would not have dreamed of such VPN speeds a year ago before the FTTH service came.

Don't want to mess with my settings remotely to test TCP though. 😛 Might kill my session.
 
John Connor said:
That's what I have configured and for UDP its port 53.
Click to expand...
Thats a good idea.

I resolve DNS with works internal DNS server. Only 80 and 443 are allowed through the firewall on the office network. So I had to run it on one of those 🙁
 
Last edited:
You must log in or register to reply here.

TRENDING THREADS

Back
Top