We are currently using an OpenVPN configuration based on the version 1 code. Back then, you had to use one port for every connection. Version 2 implemented a server mode where a single server port could deal with many different clients, authenticated by SSL certificate. The down side of our current setup is that we have to have one OpenVPN daemon running for every client. It also makes it difficult to switch between TCP and UDP.
OpenVPN does include the ability to run over both TCP and UDP. This is nice because TCP tends to work over more firewalls without special configuration. However, the drawback is that TCP doesn’t work very well for tunneling TCP traffic. There are a few pretty serious problems with tunneling TCP over TCP. In short, both the tunnel and the end applications will do packet retransmission, which eventually can lead to a “meltdown”.
Another problem with TCP is that if you lose a packet, all packets sent after it are blocked until that one successfully goes through. If you have many streams of data going on, this means that nothing moves until the logjam is cleared. Also, real-time applications like VoIP can deal much better with a single dropped packet every second, but can’t deal with these sorts of retransmissions. If you’re sending a file, you don’t want it to drop any packets. For VoIP, you can deal with a lossy channel.
UDP corrects this, but some firewalls block UDP for various reasons. UDP is not connection-oriented, so firewalls have to be more clever in how they handle allowing UDP streams. It’s extremely nice to have the choice though. Running OpenVPN on a well-used port like HTTP or SSH or DNS may allow it your VPN to get through where it otherwise would be blocked.
所以選擇UDP吧