I have a real-time application (C++ using websockets) that has to communicate through a congested LAN. Because it's realtime, delays can't be tolerated. Will UDP perform better than TCP in this case?
I cannot tolerate packet loss, but can address it through retries if using UDP.
In a congested network UDP will send its packets faster than TCP. This is because TCP actively tries to avoid overloading the network using a mechanism called congestion control. UDP has no such mechanism; its send speed is limited only by the resources of the sender.
If your first priority is to just send the packets, then UDP is the way to go. However, your probably also want them to arrive at the other end, which is a separate problem.
Sending UDP packets into a congested network at a high rate will only cause it to become more congested, leading to long delays and packet loss.
The problem here is neither TCP nor UDP - but the congested network. If the road is congested, it doesn't matter whether you're driving a car or a bus, you'll be late either way.
So, it doesn't matter all that much which protocol you choose. To send something quickly over a congested network you need a solution at the network level, possibly some QoS mechanism to prioritize some packets over others. QoS can give you the network equivalent of bus lanes that allow buses to quickly pass congested roads at the expense of other traffic.
TCP has a greater computation overhead to ensure reliable delivery of packets. But, since modern networks are fast, is there any scenario in which performance of UDP outweighs the reliability of TCP?
Is there any other particular advantage of UDP over TCP?
I can see two cases, where UDP would have an upper hand over TCP.
First, one of the attractive features of UDP is that since it does not need to retransmit lost packets nor does it do any connection setup, sending data incurs less delay. This lower delay makes UDP an appealing choice for delay-sensitive applications like audio and video.
Second, multicast applications are built on top of UDP since they have to do point to multipoint. Using TCP for multicast applications would be hard since now the sender would have to keep track of retransmissions/sending rate for multiple receivers.
It depends on your usage. If your application is time sensitive, like Voice over IP, then you don't care about missing packets. What you care about is the delay in that case.
You should have a look at this answer: What are examples of TCP and UDP in real life?
You could also look at the Wikipedia related section: http://en.wikipedia.org/wiki/User_Datagram_Protocol#Comparison_of_UDP_and_TCP
Applications that require constant data flow, bulk data and which require fastness than reliability uses UDP over TCP.
udp provides better application level control over what data is sent....since the data is packaged in a udp segment and immediately passed over to the network layer......hence no-frills segment delivery service is observed.
There is no need for connection establishment hence no delay(unlike tcp...which requires handshaking before the actual data transfer)
There is no need to maintain connection state in the end systems(ie no need for send and receive buffers,congestion control parameters and sequence and acknowledgement number parameters)..hence more active clients could be supported
Small packet header overhead for udp(only 8 bytes) where as tcp has 20 bytes of header
Facebook uses UDP connections instead of TCP/IP to connect to theirs Memcached Servers
There are couple of differences of UDP over TCP.
First, TCP is connection-based whereas UDP is connectionless.
Connection-based: Make sure that all messages will arrive and arrive in the correct order.
Connectionless: It does not guarantee order or completeness.
Second, Here is why UDP is faster over TCP:
UDP does not require ACK message back
UDP has no flow control
No duplication verification at the receiving end
Shorter header
I know pretty the differences between UDP and TCP in general (eg. http://www.onsip.com/about-voip/sip/udp-versus-tcp-for-voip)
Question is, in what circumstances would using TCP as the transport have advantages specifically under SIP VOiP communications?
A lot of people would generally associate UDP with voip and probably leave it at that, but in simple terms there are two parts to voip - connection and voice data transfer.
SIP is a very light weight protocol, once the connections is established it's effectively left idle until the infrequent event of someone making a phone call. TCP (unlike UDP) will actually reduce traffic to the server by eliminating need to;
Re-register every few minutes
Refresh/ping server
You can run SIP over TCP and then use (as is recommended) UDP for RTP.
I couldn't help but also point out the obvious things that I have looked over. Eg. number of devices connecting to the server. As the number grows, the equation tilts in UDPs favor. But then you also have to consider SIP User Agents expanding to cover multiple codecs, multimedia, video and screen-sharing. The INVITE packets can start to grow large and potentially run over the UDP single datagram size thereby tilting the equation again in favor of TCP.
All that being said I hope you have enough information to answer the question you were looking to answer.
Hope this helps.
Credit: The wonderful discussion at onSip: https://www.onsip.com/blog/sip-via-udp-vs-tcp
SIP over TCP has a significant advantage over UDP for mobile devices. The reason is due to the use of NAT, and how NAT table entries in a wireless router or a cell providers' router are generally timed out much quicker for UDP vs TCP. Since keeping the same NAT table entry is necessary to be able to reliably receive calls, SIP must periodically send out keep-alives to maintain the NAT table entry. The required frequency of keep-alives is much higher for UDP (maybe every 30 seconds) vs TCP (maybe every 15 minutes) thus resulting in noticeably higher mobile device battery usage. Often when you see someone complaining about how their battery usage takes a major hit when using a VOIP client, it's because the client is using UDP.
So, TCP wins out over UDP hands down for mobile devices.
Note that the above assumes you want to be able to reliably receive calls on your mobile device. If all you want to do is be able to make calls, then it's a different story.
If a message is large (within 200 bytes of MTU size), RFC 3261 section 18.1.1 mandates use of TCP (to be precise, it mandates use of a "congestion controlled transport protocol, such as TCP"). I've hit that in practice when sending an initial INVITE with lots of headers and a complex Request URI.
You cannot reliably assemble an audio stream from a TCP based protocol. In audio it is far better to lose a packet than to have a packet retransmitted because of a packet drop. Audio does not work if there is excessive jitter in the packet timing. Audio is real-time and requires a protocol like UDP to work correctly. Packet loss does not break audio, it only reduces the quality. TCP's perfect delivery does not help audio in any way, there can be no quality if you get 100% of the packets, but they are not in real time. In audio it is the timing (latency, jitter) that determine quality more than data integrity.
This sip works BEST when signal and control are over TCP but voice data is over UDP.
I have been working with transmission of digital voice over network protocols since I designed one of the first smartphones in 1987 for the newly emerging digital cellular network in Japan. Since 1987, the only aspect of digital voice transmission that has not changed is what I describe here. The real-time nature of audio (voice) transmission and how that impacts system design is still exactly the same as it was in the dinosaur days I come from.
TCP can get through with perfect clarity on a lossy connection, when UDP may not be understandable. You get lower latency with UDP, but that doesn't help you if you can't understand what is being said.
I was told that for a High Frequency Trading (HFT) system that requires low-latency, TCP is used over UDP. I was told that with TCP you can make point to point connections, whereas you cannot with UDP, however from my understanding you can send UDP packets to specific IP/port.
There are several arguments used in this article as to why UDP > TCP for gaming but I can see relevance for HFT.
Why would TCP be a better protocol to use for HFT?
(Admins: My previous post of this question was silently removed with no explanation. If I am violating terms of use please alert me of this instead of silently removing the question)
UDP is superior to TCP if you don't need some of the features TCP provides. Every feature has a cost, and so if you don't need features, you are paying that cost for no reason.
In an HFT application, you need pretty much every feature TCP requires. So if you picked UDP, you'd have to implement those features yourself. That means you'd have to implement connection establishment, connection teardown, retransmissions, transmit pacing, windows, and so on.
If there was a way to do all those things that was better than the way TCP was doing it, TCP would be doing it that way. You'd have one hand tied behind your back because TCP is heavily optimized by some of the best minds on the planet and implemented in/with the kernel.
There's no reasons to expect a stream of data over an already-established TCP connection would be slower than the same data over UDP, plus you get checksumming, retries, and all the other TCP goodness. UDP mainly wins in cases where you can afford to discard the reliability or where the overhead of many TCP handshakes would be too expensive, such as with common DNS queries.
TCP is faster for when using a few connections, the important difference is that modern NICs perform significant amounts of acceleration on TCP and not really that much for UDP. This means there is more overhead to process each UDP packet and as such they cannot compete unless you need to send to multiple recipients simultaneously.
However the UDP multicast route still suffers the same problems as unicast UDP per datagram overheads. Therefore many HFT systems use hardware accelerated systems that can multiplex the streams across many NICs via TCP, example Solace.
These days though you want to completely bypass the kernel with say a userspace IP stack such as by Solarflare or Mellanox, or even skip both the kernel and IP stack with RDMA.
Quite simply, if you need connection reliability (ensuring that every byte of data transmitted is received), you should be using TCP regardless.
As you mentioned, UDP is more suitable for games, where 100% accurate real-time tracking of every object would use quite a large amount of bandwidth and is unnecessary (this is where slow connections encounter lag).
There is no special difference between a TCP port and a UDP port, beyond the type of connection being used (send the packet and forget it, UDP style, or negotiate a connection and sustain it, TCP style) and the service listening on the server side. e.g. TCP/25 would usually reveal a SMTP server, whereas UDP/25 would not.
Basically, modern TCP implementations are going to be just as fast as UDP, if you're keeping the connection alive. If TCP is having to resend a packet, you'd need to resend it in UDP too. Plus for UDP you're going to end up implementing the same reliability code (retransmission of dropped packets) that TCP has already implemented.
What is the difference between TCP and UDP?
I know that TCP is used in the case of non-time critical applications, and UDP is used for games or applications that require fast transmission of data. I know that TCP is used for HTTP, HTTPs, FTP, SMTP, and Telnet. I know that UDP is used for DNS and DHCP.
But why? What characteristics of TCP and UDP make it useful for their respective use cases?
TCP is a connection oriented stream over an IP network. It guarantees that all sent packets will reach the destination in the correct order. This imply the use of acknowledgement packets sent back to the sender, and automatic retransmission, causing additional delays and a general less efficient transmission than UDP.
UDP is a connection-less protocol. Communication is datagram oriented. The integrity is guaranteed only on the single datagram. Datagrams reach destination and can arrive out of order or don't arrive at all. It is more efficient than TCP because it uses non ACK. It's generally used for real time communication, where a little percentage of packet loss rate is preferable to the overhead of a TCP connection.
In certain situations UDP is used because it allows broadcast packet transmission. This is sometimes fundamental in cases like DHCP protocol, because the client machine hasn't still received an IP address (this is the DHCP negotiaton protocol purpose) and there won't be any way to establish a TCP stream without the IP address itself.
From the Skullbox article:
TCP (Transmission Control Protocol) is the most commonly used protocol on the Internet.
The reason for this is because TCP offers error correction. When the TCP protocol is used there is a "guaranteed delivery." This is due largely in part to a method called "flow control." Flow control determines when data needs to be re-sent, and stops the flow of data until previous packets are successfully transferred. This works because if a packet of data is sent, a collision may occur. When this happens, the client re-requests the packet from the server until the whole packet is complete and is identical to its original.
UDP (User Datagram Protocol) is anther commonly used protocol on the Internet. However, UDP is never used to send important data such as webpages, database information, etc; UDP is commonly used for streaming audio and video. Streaming media such as Windows Media audio files (.WMA) , Real Player (.RM), and others use UDP because it offers speed! The reason UDP is faster than TCP is because there is no form of flow control or error correction. The data sent over the Internet is affected by collisions, and errors will be present. Remember that UDP is only concerned with speed. This is the main reason why streaming media is not high quality.
1) TCP is connection oriented and reliable where as UDP is connection less and unreliable.
2) TCP needs more processing at network interface level where as in UDP it’s not.
3) TCP uses, 3 way handshake, congestion control, flow control and other mechanism to make sure the reliable transmission.
4) UDP is mostly used in cases where the packet delay is more serious than packet loss.
Think of TCP as a dedicated scheduled UPS/FedEx pickup/dropoff of packages between two locations, while UDP is the equivalent of throwing a postcard in a mailbox.
UPS/FedEx will do their damndest to make sure that the package you mail off gets there, and get it there on time. With the post card, you're lucky if it arrives at all, and it may arrive out of order or late (how many times have you gotten a postcard from someone AFTER they've gotten home from the vacation?)
TCP is as close to a guaranteed delivery protocol as you can get, while UDP is just "best effort".
Reasons UDP is used for DNS and DHCP:
DNS - TCP requires more resources from the server (which listens for connections) than it does from the client. In particular, when the TCP connection is closed, the server is required to remember the connection's details (holding them in memory) for two minutes, during a state known as TIME_WAIT_2. This is a feature which defends against erroneously repeated packets from a preceding connection being interpreted as part of a current connection. Maintaining TIME_WAIT_2 uses up kernel memory on the server. DNS requests are small and arrive frequently from many different clients. This usage pattern exacerbates the load on the server compared with the clients. It was believed that using UDP, which has no connections and no state to maintain on either client or server, would ameliorate this problem.
DHCP - DHCP is an extension of BOOTP. BOOTP is a protocol which client computers use to get configuration information from a server, while the client is booting. In order to locate the server, a broadcast is sent asking for BOOTP (or DHCP) servers. Broadcasts can only be sent via a connectionless protocol, such as UDP. Therefore, BOOTP required at least one UDP packet, for the server-locating broadcast. Furthermore, because BOOTP is running while the client... boots, and this is a time period when the client may not have its entire TCP/IP stack loaded and running, UDP may be the only protocol the client is ready to handle at that time. Finally, some DHCP/BOOTP clients have only UDP on board. For example, some IP thermostats only implement UDP. The reason is that they are built with such tiny processors and little memory that the are unable to perform TCP -- yet they still need to get an IP address when they boot.
As others have mentioned, UDP is also useful for streaming media, especially audio. Conversations sound better under network lag if you simply drop the delayed packets. You can do that with UDP, but with TCP all you get during lag is a pause, followed by audio that will always be delayed by as much as it has already paused. For two-way phone-style conversations, this is unacceptable.
One of the differences is in short
UDP : Send message and dont look back if it reached destination, Connectionless protocol
TCP : Send message and guarantee to reach destination, Connection-oriented protocol
TCP establishes a connection before the actual data transmission takes place, UDP does not. In this way, UDP can provide faster delivery. Applications like DNS, time server access, therefore, use UDP.
Unlike UDP, TCP uses congestion control. It responses to the network load. Unlike UDP, it slows down when network congestion is imminent. So, applications like multimedia preferring constant throughput might go for UDP.
Besides, UDP is unreliable, it doesn't react on packet losses. So loss sensitive applications like multimedia transmission prefer UDP. However, TCP is a reliable protocol, so, applications that require reliability such as web transfer, email, file download prefer TCP.
Besides, in today's internet UDP is not as welcoming as TCP due to middle boxes. Some applications like skype fall down to TCP when UDP connection is assumed to be blocked.
Run into this thread and let me try to express it in this way.
TCP
3-way handshake
Bob: Hey Amy, I'd like to tell you a secret
Amy: OK, go ahead, I'm ready
Bob: OK
Communication
Bob: 'I', this is the first letter
Amy: First letter received, please send me the second letter
Bob: ' ', this is the second letter
Amy: Second letter received, please send me the third letter
Bob: 'L', this is the third letter
After a while
Bob: 'L', this the third letter
Amy: Third letter received, please send me the fourth letter
Bob: 'O', this the forth letter
Amy: ...
......
4-way handshake
Bob: My secret is exposed, now, you know my heart.
Amy: OK. I have nothing to say.
Bob: OK.
UDP
Bob: I LOVE U
Amy received: OVI L E
TCP is more reliable than UDP with even message order guaranteed, that's no doubt why UDP is more lightweight and efficient.
The Law of Leaky Abstractions
by Joel Spolsky
http://www.joelonsoftware.com/articles/LeakyAbstractions.html
Short and simple differences between Tcp and Udp protocol:
1) Tcp - Transmission control protocol and Udp - User datagram protocol.
2) Tcp is reliable protocol, Where as Udp is a unreliable protocol.
3) Tcp is a stream oriented, where as Udp is a message oriented protocol.
4) Tcp is a slower than Udp.
This sentence is a UDP joke, but I'm not sure that you'll get it. The below conversation is a TCP/IP joke:
A: Do you want to hear a TCP/IP joke?
B: Yes, I want to hear a TCP/IP joke.
A: Ok, are you ready to hear a TCP/IP joke?
B: Yes, I'm ready to hear a TCP/IP joke.
A: Well, here is the TCP/IP joke.
A: Did you receive a TCP/IP joke?
B: Yes, I **did** receive a TCP/IP joke.
TCP and UDP are transport layer protocol, Layer 4 protocol in OSI(open systems interconnection model). The main difference along with pros and cons are as following.
TCP
PROS:
Acknowledgment
Guaranteed Delivery
Connection based
Ordered packets
Congestion control
CONS:
Larger Packet
More bandwidth
Slower
Statefull
Consume memory
UDP
PROS:
Packets are smaller
Consume less bandwidth
Faster
Stateless
CONS:
No acknowledgment
No guaranteed delivery
Connectionless
No congestion control
No order packet
TLDR;
TCP - stream-oriented, requires a connection, reliable, slow
UDP - message-oriented, connectionless, unreliable, fast
Before we start, remember that all disadvantages of something are a continuation of its advantages. There only a right tool for a job, no panacea. TCP/UDP coexist for decades, and for a reason.
TCP
It was designed to be extremely reliable and it does its job very well. It's so complex because it accomplishes a hard task: providing a reliable transport over the unreliable IP protocol.
Since all TCP's complex logic is encapsulated into the network stack, you are free from doing lots of laborious, error-prone low-level stuff in the application layer.
When you send data over TCP, you write a stream of bytes to the socket at the sender side where it gets broken into packets, passed down the stack and sent over the wire. On the receiver side packets get reassembled again into a continous stream of bytes.
Maintaining this nice abstraction has a cost in terms of complexity and performance. If the 1st packet from the byte stream is lost, the receiver will delay processing of subsequent packets even those have already arrived (the so-called "head of line blocking").
In addition, in order to be reliable, TCP implements this:
TCP requires an established connection, which requires 3 round-trips ("infamous" 3-way handshake)
TCP has a feature called "slow start" when it gradually ramps up the transmission rate after establishing a connection to allow a receiver to keep up with data rate
Every sent packet has to be acknowledged or else a sender will stop sending more data
And on and on and on...
All this is exacerbated in slow unreliable wireless networks because TCP was designed for wired networks where delays are predictable and packet loss is not so common. In addition, like many people already mentioned, for some things TCP just doesn't work at all (DHCP). However, where relevant, TCP still does its work exceptionally well.
Using a mail analogy a TCP session is similar to telling a story to your secretary who breaks it into mails and sends over a crappy mail service to a publisher. On the other side another secretary assembles mails into a single piece of text. Some mails get lost, some get corrupted, so a very complex procedure is required for reliable delivery and your 10-page story can take a long time to reach your publisher.
UDP
UDP, on the other hand, is message-oriented, so a receiver writes a message (packet) to the socket and then it gets transmitted to a receiver as-is, without any splitting/assembling in the transport layer.
Compared to TCP, its specification is very straightforward. Essentially, all it does for you is adding a checksum to the packet so a receiver can detect its corruption. Everything else must be implemented by you, a software developer. Now read the voluminous TCP spec and try thinking of re-implementing even a small subset of it.
Some people went this way and got very decent results, to the point that HTTP/3 uses QUIC - a protocol based on UDP. However, this is more of an exception. Common applications of UDP are audio/video streaming and conferencing applications like Skype, Zoom or Google Hangout where loosing packets is not so important compared to a delay introduced by TCP.
Simple Explanation by Analogy
TCP is like this.
Imagine you have a pen-pal on Mars (we communicated with written letters back in the good ol' days before the internet).
You need to send your pen pal the seven habits of highly effective people. So you decide to send it in seven separate letters:
Letter 1 - Be proactive
Letter 2 - Begin with the end in mind...
etc.
etc..Letter 7 - Sharpen the Saw
Requirements:
You want to make sure that your pen pal receives all your letters - in order and that they arrive perfectly. If your pen pay receives letter 7 before letter 1 - that's no good. if your pen pal receives all letters except letter 3 - that also is no good.
Here's how we ensure that our requirements are met:
Confirmation Letter: So your pen pal sends a confirmation letter to say "I have received letter 1". That way you know that your pen pal has received it. If a letter does not arrive, or arrives out of order, then you have to stop, and go back and re-send that letter, and all subsequent letters.
Flow Control: Around the time of Xmas you know that your pen pal will be receiving a lot of mail, so you slow down because you don't want to overwhelm your pen pal. (Your pen pal sends you constant updates about the number of unread messages there are in penpal's mailbox - if your pen pal says that the inbox is about to explode because it is so full, then you slow down sending your letters - because your pen pal won't be able to read them.
Perfect arrival. Sometimes while you send your letter in the mail, it can get torn, or a snail can eat half of it. How do you know that all your letter has arrived in perfect condition? Well your pen pal will give you a mechanism by which you can check whether they've got the full letter and that it was the exactly the letter that you sent. (e.g. via a word count etc. ). a basic analogy.