When it comes to Internet protocols, TCP has been the dominant protocol used across the web to form connections. TCP helps computers communicate by breaking large data sets into individual packets, transmitting them, and then reforming the packet in the original order once the data set has been received. But as file sizes grew and latency became an issue, User Datagram Protocol (UDP), gained more popularity. UDP picks up the slack by offering faster speeds with the ability to transmit much larger files, something that TCP isn’t capable of.
When comparing the architecture of the two protocol tools, the main difference is that UDP sends the packets without waiting for each connection to go through, which means lower bandwidth overhead and latency. TCP, on the other hand, sends the packets one at a time, in order, waiting to make sure each connection goes through before starting the next. To better understand the pros and cons of each protocol, below is a basic comparison of the two:
|
Feature
|
TCP | UDP |
| Connection | Connection-Oriented: messages navigate the internet one connection at a time | Connectionless: a single program sends out a load of packets all at once. |
| Usage | Used for application needing high reliability, where time is less relevant | Used when applications need fast transmission |
| Used by other protocols | HTTP, HTTPS, FTP, SMTP, Telnet | DNS, DHCP, TFTP, SNMP, RIP, VOIP |
| Reliability | All transferred data is guaranteed to arrive in order specified. | No guarantee of arrival and ordering has to be managed by the application layer |
| Header Size | 20 bytes | 8 bytes |
| Data Flow Control | Does flow control, requiring three packets to set up a socket connection before user data can be sent | Does not have an option for flow control |
| Error Checking | Yes | Yes, but no recovery options |
| Acknowledgments | Yes, required before next transfer will take place | No, allows for quicker speed |
There’s a clear tradeoff between the two when it comes to speed versus reliability, but as developments have been made with UDP, it’s become more and more trustworthy as a leading protocol tool. Recently, Google announced that they use their open source Google QUIC UDP-based protocol to run 50% of their Chrome traffic, with that percentage expecting to increase in the coming years. So as the market shifts and advancements continue to be made with the source code, UDP is quickly becoming the file transfer tool of the future. So what UDP should you use?
Choosing a UDP
When it comes to choosing a UDP there are two main options—buy it from a commercial service or install it for open source software. Given the immaturity of most open source software, it may not be as user friendly, but there are many options out there, so paying developers to manage and configure your UDP is not necessary.
Currently, there are six main UDP file transfer tools available as open source.
- Tsunami UDP Protocol: Uses TCP control and UDP data for transfer over high speed long distance networks. It was designed specifically to offer more throughput than possible with TCP over the same networks.
- UDT UDP-based Data Transfer: Designed to support global data transfer of terabyte sized data sets, using UDP to transfer the bulk of its data with reliability control mechanisms.
- Enet: Main goal is to provide a thin, simple and robust network communication layer on top of UDP with reliable and ordered delivery of packets, which they accomplish by stripping it of higher level networking features.
- UFTP: Specializes in distributing large files to a large number of receivers, especially when data distribution takes place over a satellite link, making TCP communication inefficient due to the delay. They have been used widely by The Wall Street Journal to send WSJ pages over satellite to their remote printing plants.
- GridFTP: Unlike all others, GridFTP is based on FTP and is not UDP, but it can be used to solve the same problems experienced when using TCP.
- Google QUIC: An experimental UDP-based network protocol designed at Google to support multiplexed connections between two endpoints, provide security protection equivalent to TSL/SSL, and reduce latency and bandwidth usage.
Below is a features comparison chart to better help you understand the side by side differences each system supports.
|
Tsunami |
UDT |
ENet |
UFTP |
GridFTP |
Google QUIC |
|
| Multi-Threaded | No | No | Yes | No | Yes | Yes |
| Protocol Overhead | 20% | 10% | NA | ~10% | 6-8%, same as TCP | NA |
| Encryption | No | No | No | Yes | Yes | Yes |
| C++ source code | Yes | Yes | Yes | Yes | Yes | Yes |
| Java Source Code | No | Partial | No | No | No | No |
| Command Line | No | No | No | Yes | Yes | Yes |
| Distribution Packets | Source code only | Source code only | Source Only | Yes | Yes | Yes |
| UDP based point-to-point | Yes | Yes | Yes | Yes | No | Yes |
| Firewall Friendly | No | Partial, no auto-detection | No | Partial, no auto-detection | No | No, has had issues with stateful firewalls |
| Congestion Control | Yes | Yes | NA | Yes | Yes, using TCP | Yes |
| Automatic retry and resume | No | No | Yes | No, manual resume yes | Yes | Yes |
| Jumbo Packets | No | Yes | No | Yes, up to 8800 bytes | Yes | NA |
| Support for Packet Loss | No | No | Yes | No | Yes | Yes |
Conclusion
When deciding what UDP tool to use, you have several factors to keep in mind. Many of issues arise when dealing with packet loss and recovery. For instance, UDT has been known to fail completely if even the slightest packet loss is reported, whereas Google QUIC has made significant advancements in addressing this issue. GridFTP might also not be the most user friendly, since it requires a much larger framework and orchestration to run, since it is not UDP-based. Considering all these factors intandem, hopefully you’ll be able to make a more informed decision when implementing UDP file transfer tools on your network.
