UDP vs TCP how much faster is it

Question

For general protocol message exchange  which can tolerate some packet loss   How much more efficient is UDP over TCP

User · Answer

It is meaningless to talk about TCP or UDP without taking the network condition into account  If the network between the two point have a very high quality  UDP is absolutely faster than TCP  but in some other case such as the GPRS network  TCP may been faster and more reliability than UDP

User · Answer

UDP is faster than TCP  and the simple reason is because its non-existent acknowledge packet  ACK  that permits a continuous packet stream  instead of TCP that acknowledges a set of packets  calculated by using the TCP window size and round-trip time  RTT    For more information  I recommend the simple  but very comprehensible Skullbox explanation  TCP vs  UDP

User · Answer

I will just make things clear   TCP UDP are two cars are that being driven on the road  suppose that traffic signs  amp  obstacles are Errors TCP cares for traffic signs  respects everything around  Slow driving because something may happen to the car  While UDP just drives off  full speed no respect to street signs  Nothing  a mad driver  UDP doesn t have error recovery  If there s an obstacle  it will just collide with it then continue  While TCP makes sure that all packets are sent  amp  received perfectly  No errors   so   the car just passes obstacles without colliding  I hope this is a good example for you to understand  Why UDP is preferred in gaming  Gaming needs speed   TCP is preffered in downloads  or downloaded files may be corrupted

User · Answer

Each TCP connection requires an initial handshake before data is transmitted  Also  the TCP header contains a lot of overhead intended for different signals and message delivery detection  For a message exchange  UDP will probably suffice if a small chance of failure is acceptable  If receipt must be verified  TCP is your best option

User · Answer

Keep in mind that TCP usually keeps multiple messages on wire  If you want to implement this in UDP you ll have quite a lot of work if you want to do it reliably  Your solution is either going to be less reliable  less fast or an incredible amount of work  There are valid applications of UDP  but if you re asking this question yours probably is not

User · Answer

When speaking of  what is faster  - there are at least two very different aspects  throughput and latency   If speaking about throughput - TCP s flow control  as mentioned in other answers   is extremely important and doing anything comparable over UDP  while certainly possible  would be a Big Headache tm   As a result - using UDP when you need throughput  rarely qualifies as a good idea  unless you want to get an unfair advantage over TCP    However  if speaking about latencies - the whole thing is completely different  While in the absence of packet loss TCP and UDP behave extremely similar  any differences  if any  being marginal  - after the packet is lost  the whole pattern changes drastically    After any packet loss  TCP will wait for retransmit for at least 200ms  1sec per paragraph 2 4 of RFC6298  but practical modern implementations tend to reduce it to 200ms   Moreover  with TCP  even those packets which did reach destination host - will not be delivered to your app until the missing packet is received  i e   the whole communication is delayed by  200ms  - BTW  this effect  known as Head-of-Line Blocking  is inherent to all reliable ordered streams  whether TCP or reliable ordered UDP  To make things even worse - if the retransmitted packet is also lost  then we ll be speaking about delay of  600ms  due to so-called exponential backoff  1st retransmit is 200ms  and second one is 200 2 400ms   If our channel has 1  packet loss  which is not bad by today s standards   and we have a game with 20 updates per second - such 600ms delays will occur on average every 8 minutes  And as 600ms is more than enough to get you killed in a fast-paced game - well  it is pretty bad for gameplay  These effects are exactly why gamedevs often prefer UDP over TCP   However  when using UDP to reduce latencies - it is important to realize that merely  using UDP  is not sufficient to get substantial latency improvement  it is all about HOW you re using UDP  In particular  while RUDP libraries usually avoid that  exponential backoff  and use shorter retransmit times - if they are used as a  reliable ordered  stream  they still have to suffer from Head-of-Line Blocking  so in case of a double packet loss  instead of that 600ms we ll get about 1 5 2 RTT - or for a pretty good 80ms RTT  it is a  250ms delay  which is an improvement  but it is still possible to do better   On the other hand  if using techniques discussed in http   gafferongames com networked-physics snapshot-compression  and or http   ithare com udp-from-mog-perspective  low-latency-compression   it IS possible to eliminate Head-of-Line blocking entirely  so for a double-packet loss for a game with 20 updates second  the delay will be 100ms regardless of RTT     And as a side note - if you happen to have access only to TCP but no UDP  such as in browser  or if your client is behind one of 6-9  of ugly firewalls blocking UDP  - there seems to be a way to implement UDP-over-TCP without incurring too much latencies  see here  http   ithare com almost-zero-additional-latency-udp-over-tcp   make sure to read comments too

User · Answer

with loss tolerant   Do you mean  with loss tolerance     Basically  UDP is not  loss tolerant   You can send 100 packets to someone  and they might only get 95 of those packets  and some might be in the wrong order   For things like video streaming  and multiplayer gaming  where it is better to miss a packet than to delay all the other packets behind it  this is the obvious choice  For most other things though  a missing or  rearranged  packet is critical  You d have to write some extra code to run on top of UDP to retry if things got missed  and enforce correct order  This would add a small bit of overhead in certain places   Thankfully  some very very smart people have done this  and they called it TCP   Think of it this way  If a packet goes missing  would you rather just get the next packet as quickly as possible and continue  use UDP   or do you actually need that missing data  use TCP   The overhead won t matter unless you re in a really edge-case scenario

User · Answer

In some applications TCP is faster  better throughput  than UDP   This is the case when doing lots of small writes relative to the MTU size   For example  I read an experiment in which a stream of 300 byte packets was being sent over Ethernet  1500 byte MTU  and TCP was 50  faster than UDP     The reason is because TCP will try and buffer the data and fill a full network segment thus making more efficient use of the available bandwidth   UDP on the other hand puts the packet on the wire immediately thus congesting the network with lots of small packets   You probably shouldn t use UDP unless you have a very specific reason for doing so   Especially since you can give TCP the same sort of latency as UDP by disabling the Nagle algorithm  for example if you re transmitting real-time sensor data and you re not worried about congesting the network with lot s of small packets

User · Answer

The network setup is crucial for any measurements  It makes a huge difference  if you are communicating via sockets on your local machine or with the other end of the world    Three things I want to add to the discussion    You can find here a very good article about TCP vs  UDP in the context of game development   Additionally  iperf  jperf enhance iperf with a GUI  is a very nice tool for answering your question yourself by measuring  I implemented a benchmark in Python  see this SO question   In average of 10 6 iterations the difference for sending 8 bytes is about 1-2 microseconds for UDP

User · Answer

UDP is slightly quicker in my experience  but not by much  The choice shouldn t be made on performance but on the message content and compression techniques   If it s a protocol with message exchange  I d suggest that the very slight performance hit you take with TCP is more than worth it  You re given a connection between two end points that will give you everything you need  Don t try and manufacture your own reliable two-way protocol on top of UDP unless you re really  really confident in what you re undertaking

User · Answer

Which protocol performs better  in terms of throughput  - UDP or TCP - really depends on the network characteristics and the network traffic  Robert S  Barnes  for example  points out a scenario where TCP performs better  small-sized writes   Now  consider a scenario in which the network is congested and has both TCP and UDP traffic  Senders in the network that are using TCP  will sense the  congestion  and cut down on their sending rates  However  UDP doesn t have any congestion avoidance or congestion control mechanisms  and senders using UDP would continue to pump in data at the same rate  Gradually  TCP senders would reduce their sending rates to bare minimum and if UDP senders have enough data to be sent over the network  they would hog up the majority of bandwidth available  So  in such a case  UDP senders will have greater throughput  as they get the bigger pie of the network bandwidth  In fact  this is an active research topic - How to improve TCP throughput in presence of UDP traffic  One way  that I know of  using which TCP applications can improve throughput is by opening multiple TCP connections  That way  even though  each TCP connection s throughput might be limited  the sum total of the throughput of all TCP connections may be greater than the throughput for an application using UDP

User · Answer

If you need to quickly blast a message across the net between two IP s that haven t even talked yet  then a UDP is going to arrive at least 3 times faster  usually 5 times faster

User · Answer

People say that the major thing TCP gives you is reliability  But that s not really true  The most important thing TCP gives you is congestion control  you can run 100 TCP connections across a DSL link all going at max speed  and all 100 connections will be productive  because they all  sense  the available bandwidth  Try that with 100 different UDP applications  all pushing packets as fast as they can go  and see how well things work out for you   On a larger scale  this TCP behavior is what keeps the Internet from locking up into  congestion collapse     Things that tend to push applications towards UDP    Group delivery semantics  it s possible to do reliable delivery to a group of people much more efficiently than TCP s point-to-point acknowledgement  Out-of-order delivery  in lots of applications  as long as you get all the data  you don t care what order it arrives in  you can reduce app-level latency by accepting an out-of-order block   Unfriendliness  on a LAN party  you may not care if your web browser functions nicely as long as you re blitting updates to the network as fast as you possibly can    But even if you care about performance  you probably don t want to go with UDP      You re on the hook for reliability now  and a lot of the things you might do to implement reliability can end up being slower than what TCP already does  Now you re network-unfriendly  which can cause problems in shared environments  Most importantly  firewalls will block you    You can potentially overcome some TCP performance and latency issues by  trunking  multiple TCP connections together  iSCSI does this to get around congestion control on local area networks  but you can also do it to create a low-latency  urgent  message channel  TCP s  URGENT  behavior is totally broken

User · Answer

There has been some work done to allow the programmer to have the benefits of both worlds   SCTP  It is an independent transport layer protolol  but it can be used as a library providing additional layer over UDP  The basic unit of communication is a message  mapped to one or more UDP packets   There is congestion control built in  The protocol has knobs and twiddles to switch on   in order delivery of messages automatic retransmission of lost messages  with user defined parameters   if any of this is needed for your particular application   One issue with this is that the connection establishment is a complicated  and therefore slow process   Other similar stuff   https   en wikipedia org wiki Reliable User Datagram Protocol   One more similar proprietary experimental thing   https   en wikipedia org wiki QUIC   This also tries to improve on the triple way handshake of TCP and change the congestion control to better deal with fast lines

[networking] UDP vs TCP, how much faster is it?

Examples related to networking

Examples related to tcp

Examples related to udp