When is it appropriate to use UDP instead of TCP

Question

Since TCP guarantees packet delivery and thus can be considered  reliable   whereas UDP doesn t guarantee anything and packets can be lost  What would be the advantage of transmitting data using UDP in an application rather than over a TCP stream  In what kind of situations would UDP be the better choice  and why   I m assuming that UDP is faster since it doesn t have the overhead of creating and maintaining a stream  but wouldn t that be irrelevant if some data never reaches its destination

User · Answer

We have web service that has thousands of winforms client in as many PCs  The PCs have no connection with DB backend  all access is via the web service  So we decided to develop a central logging server that listens on a UDP port and all the clients sends an xml error log packet  using log4net UDP appender  that gets dumped to a DB table upon received  Since we don t really care if a few error logs are missed and with thousands of client it is fast with a dedicated logging service not loading the main web service

User · Answer

UDP does have less overhead and is good for doing things like streaming real time data like audio or video  or in any case where it is ok if data is lost

User · Answer

UDP is perfect for VoIP addressed where data packet has to be sent regard less its reliability    Video chatting is an example of UDP  you can check it by wireshark network capture during any video chatting    Also TCP doesn t work with DNS and SNMP protocols  UDP does not have any overhead while TCP have lots of Overhead

User · Answer

This is one of my favorite questions  UDP is so misunderstood   In situations where you really want to get a simple answer to another server quickly  UDP works best  In general  you want the answer to be in one response packet  and you are prepared to implement your own protocol for reliability or to resend  DNS is the perfect description of this use case  The costs of connection setups are way too high  yet  DNS does support a TCP mode as well    Another case is when you are delivering data that can be lost because newer data coming in will replace that previous data state  Weather data  video streaming  a stock quotation service  not used for actual trading   or gaming data comes to mind   Another case is when you are managing a tremendous amount of state and you want to avoid using TCP because the OS cannot handle that many sessions  This is a rare case today  In fact  there are now user-land TCP stacks that can be used so that the application writer may have finer grained control over the resources needed for that TCP state  Prior to 2003  UDP was really the only game in town   One other case is for multicast traffic  UDP can be multicasted to multiple hosts whereas TCP cannot do this at all

User · Answer

You want to use UDP over TCP in the cases where losing some of the data along the way will not completely ruin the data being transmitted  A lot of its uses are in real-time applications  such as gaming  i e   FPS  where you don t always have to know where every player is at any given time  and if you lose a few packets along the way  new data will correctly tell you where the players are anyway   and real-time video streaming  one corrupt frame isn t going to ruin the viewing experience

User · Answer

There are already many good answers here  but I would like to add one very important factor as well as a summary  UDP can achieve a much higher throughput with the correct tuning because it does not employ congestion control  Congestion control in TCP is very very important  It controls the rate and throughput of the connection in order to minimize network congestion by trying to estimate the current capacity of the connection  Even when packets are sent over very reliable links  such as in the core network  routers have limited size buffers  These buffers fill up to their capacity and packets are then dropped  and TCP notices this drop through the lack of a received acknowledgement  thereby throttling the speed of the connection to the estimation of the capacity  TCP also employs something called slow start  but the throughput  actually the congestion window  is slowly increased until packets are dropped  and is then lowered and slowly increased again until packets are dropped etc  This causes the TCP throughput to fluctuate  You can see this clearly when you download a large file   Because UDP is not using congestion control it can be both faster and experience less delay because it will not seek to maximize the buffers up to the dropping point  i e  UDP packets are spending less time in buffers and get there faster with less delay  Because UDP does not employ congestion control  but TCP does  it can take away capacity from TCP that yields to UDP flows   UDP is still vulnerable to congestion and packet drops though  so your application has to be prepared to handle these complications somehow  likely using retransmission or error correcting codes   The result is that UDP can    Achieve higher throughput than TCP as long as the network drop rate is within limits that the application can handle  Deliver packets faster than TCP with less delay  Setup connections faster as there are no initial handshake to setup the connection Transmit multicast packets  whereas TCP have to use multiple connections  Transmit fixed size packets  whereas TCP transmit data in segments  If you transfer a UDP packet of 300 Bytes  you will receive 300 Bytes at the other end  With TCP  you may feed the sending socket 300 Bytes  but the receiver only reads 100 Bytes  and you have to figure out somehow that there are 200 more Bytes on the way  This is important if your application transmit fixed size messages  rather than a stream of bytes     In summary  UDP can be used for every type of application that TCP can  as long as you also implement a proper retransmission mechanism  UDP can be very fast  has less delay  is not affected by congestion on a connection basis  transmits fixed sized datagrams  and can be used for multicasting

User · Answer

We know that the UDP is a connection-less protocol  so it is   suitable for process that require simple request-response communication  suitable for process which has internal flow  error control suitable for broad casting and multicasting   Specific examples    used in SNMP used for some route updating protocols such as RIP

User · Answer

It s not always clear cut   However  if you need guaranteed delivery of packets with no loss and in the right sequence then TCP is probably what you want   On the other hand UDP is appropriate for transmitting short packets of information where the sequence of the information is less important or where the data can fit into a single packet   It s also appropriate when you want to broadcast the same information to many users   Other times  it s appropriate when you are sending sequenced data but if some of it goes missing you re not too concerned  e g  a VOIP application    Some protocols are more complex because what s needed are some  but not all  of the features of TCP  but more than what UDP provides  That s where the application layer has to implement the additional functionality   In those cases  UDP is also appropriate  e g  Internet radio  order is important but not every packet needs to get through    Examples of where it is could be used 1  A time server broadcasting the correct time to a bunch of machines on a LAN  2  VOIP protocols 3  DNS lookups 4  Requesting LAN services e g  where are you  5  Internet radio 6  and many others     On unix you can type grep udp  etc services to get a list of UDP protocols implemented today    there are hundreds

User · Answer

I work on a product that supports both UDP  IP  and TCP IP communication between client and server   It started out with IPX over 15 years ago with IP support added 13 years ago   We added TCP IP support 3 or 4 years ago   Wild guess coming up   The UDP to TCP code ratio is probably about 80 20   The product is a database server  so reliability is critical   We have to handle all of the issues imposed by UDP  packet loss  packet doubling  packet order  etc   already mentioned in other answers   There are rarely any problems  but they do sometimes occur and so must be handled   The benefit to supporting UDP is that we are able to customize it a bit to our own usage and tweak a bit more performance out of it   Every network is going to be different  but the UDP communication protocol is generally a little bit faster for us   The skeptical reader will rightly question whether we implemented everything correctly   Plus  what can you expect from a guy with a 2 digit rep   Nonetheless  I just now ran a test out of curiosity   The test read 1 million records  select   from sometable    I set the number of records to return with each individual client request to be 1  10  and then 100  three test runs with each protocol    The server was only two hops away over a 100Mbit LAN   The numbers seemed to agree with what others have found in the past  UDP is about 5  faster in most situations    The total times in milliseconds were as follows for this particular test    1 record   IP   390 760 ms TCP   416 903 ms  10 records   IP   91 707 ms TCP   95 662 ms  100 records   IP   29 664 ms TCP   30 968 ms    The total data amount transmitted was about the same for both IP and TCP   We have extra overhead with the UDP communications because we have some of the same stuff that you get for  free  with TCP IP  checksums  sequence numbers  etc     For example  Wireshark showed that a request for the next set of records was 80 bytes with UDP and 84 bytes with TCP

User · Answer

The key question was related to  what kind of situations would UDP be the better choice  over tcp    There are many great answers above but what is lacking is any formal  objective assessment of the impact of transport uncertainty upon TCP performance   With the massive growth of mobile applications  and the  occasionally connected  or  occasionally disconnected  paradigms that go with them  there are certainly situations where the overhead of TCP s attempts to maintain a connection when connections are hard to come by leads to a strong case for UDP and its  message oriented  nature   Now I don t have the math research numbers on this  but I have produced apps that have worked more reliably using and ACK NAK and message numbering over UDP than could be achieved with TCP when connectivity was generally poor and poor old TCP just spent it s time and my client s money just trying to connect  You get this in regional and rural areas of many western countries

User · Answer

In some cases  which others have highlighted  guaranteed arrival of packets isn t important  and hence using UDP is fine  There are other cases where UDP is preferable to TCP   One unique case where you would want to use UDP instead of TCP is where you are tunneling TCP over another protocol  e g  tunnels  virtual networks  etc    If you tunnel TCP over TCP  the congestion controls of each will interfere with each other  Hence one generally prefers to tunnel TCP over UDP  or some other stateless protocol   See TechRepublic article  Understanding TCP Over TCP  Effects of TCP Tunneling on End-to-End Throughput and Latency

User · Answer

I m a bit reluctant to suggest UDP when TCP could possibly work   The problem is that if TCP isn t working for some reason  because the connection is too laggy or congested  changing the application to use UDP is unlikely to help   A bad connection is bad for UDP too   TCP already does a very good job of minimizing congestion     The only case I can think of where UDP is required is for broadcast protocols   In cases where an application involves two  known hosts  UDP will likely only offer marginal performance benefits for substantially increased costs of code complexity

User · Answer

Only use UDP if you really know what you are doing  UDP is in extremely rare cases today  but the number of  even very experienced  experts who would try to stick it everywhere seems to be out of proportion  Perhaps they enjoy implementing error-handling and connection maintenance code themselves   TCP should be expected to be much faster with modern network interface cards due to what s known as checksum imprint  Surprisingly  at fast connection speeds  such as 1Gbps  computing a checksum would be a big load for a CPU so it is offloaded to NIC hardware that recognizes TCP packets for imprint  and it won t offer you the same service

User · Answer

If a TCP packet is lost  it will be resent  That is not handy for applications that rely on data being handled in a specific order in real time   Examples include video streaming and especially VoIP  e g  Skype   In those instances  however  a dropped packet is not such a big deal  our senses aren t perfect  so we may not even notice  That is why these types of applications use UDP instead of TCP

User · Answer

UDP when speed is necessary and the accuracy if the packets is not  and TCP when you need accuracy   UDP is often harder in that you must write your program in such a way that it is not dependent on the accuracy of the packets

User · Answer

UDP is a connection-less protocol and is used in protocols like SNMP and DNS in which data packets arriving out of order is acceptable and immediate transmission of the data packet matters   It is used in SNMP since network management must often be done when the network is in stress i e  when reliable  congestion-controlled data transfer is difficult to achieve   It is used in DNS since it does not involve connection establishment  thereby avoiding connection establishment delays   cheers

User · Answer

Network communication for video games is almost always done over UDP   Speed is of utmost importance and it doesn t really matter if updates are missed since each update contains the complete current state of what the player can see

User · Answer

Video streaming is a perfect example of using UDP

User · Answer

UDP can be used when an app cares more about  real-time  data instead of exact data replication   For example  VOIP can use UDP and the app will worry about re-ordering packets  but in the end VOIP doesn t need every single packet  but more importantly needs a continuous flow of many of them   Maybe you here a  glitch  in the voice quality  but the main purpose is that you get the message and not that it is recreated perfectly on the other side   UDP is also used in situations where the expense of creating a connection and syncing with TCP outweighs the payload   DNS queries are a perfect example   One packet out  one packet back  per query   If using TCP this would be much more intensive   If you dont  get the DNS response back  you just retry

User · Answer

The  unreliability  of UDP is a formalism   Transmission isn t absolutely guaranteed   As a practical matter  they almost always get through   They just aren t acknowledged and retried after a timeout   The overhead in negotiating for a TCP socket and handshaking the TCP packets is huge   Really huge   There is no appreciable UDP overhead   Most importantly  you can easily supplement UDP with some reliable delivery hand-shaking that s less overhead than TCP   Read this  http   en wikipedia org wiki Reliable User Datagram Protocol  UDP is useful for broadcasting information in a publish-subscribe kind of application   IIRC  TIBCO makes heavy use of UDP for notification of state change   Any other kind of one-way  significant event  or  logging  activity can be handled nicely with UDP packets   You want to send notification without constructing an entire socket   You don t expect any response from the various listeners   System  heartbeat  or  I m alive  messages are a good choice  also   Missing one isn t a crisis   Missing half a dozen  in a row  is

User · Answer

One of the best answer I know of for this question comes from user zAy0LfpBZLC8mAC  at Hacker News  This answer is so good I m just going to quote it as-is      TCP has head-of-queue blocking  as it guarantees complete and in-order   delivery  so when a packet gets lost in transit  it has to wait for a   retransmit of the missing packet  whereas UDP delivers packets to the   application as they arrive  including duplicates and without any   guarantee that a packet arrives at all or which order they arrive  it   really is essentially IP with port numbers and an  optional  payload   checksum added   but that is fine for telephony  for example  where it   usually simply doesn t matter when a few milliseconds of audio are   missing  but delay is very annoying  so you don t bother with   retransmits  you just drop any duplicates  sort reordered packets into   the right order for a few hundred milliseconds of jitter buffer  and   if packets don t show up in time or at all  they are simply skipped    possible interpolated where supported by the codec       Also  a major part of TCP is flow control  to make sure you get as   much througput as possible  but without overloading the network  which   is kinda redundant  as an overloaded network will drop your packets    which means you d have to do retransmits  which hurts throughput   UDP   doesn t have any of that - which makes sense for applications like   telephony  as telephony with a given codec needs a certain amount of   bandwidth  you can not  slow it down   and additional bandwidth also   doesn t make the call go faster       In addition to realtime low latency applications  UDP makes sense for   really small transactions  such as DNS lookups  simply because it   doesn t have the TCP connection establishment and teardown overhead    both in terms of latency and in terms of bandwidth use  If your   request is smaller than a typical MTU and the repsonse probably is    too  you can be done in one roundtrip  with no need to keep any state   at the server  and flow control als ordering and all that probably   isn t particularly useful for such uses either       And then  you can use UDP to build your own TCP replacements  of   course  but it s probably not a good idea without some deep   understanding of network dynamics  modern TCP algorithms are pretty   sophisticated       Also  I guess it should be mentioned that there is more than UDP and   TCP  such as SCTP and DCCP  The only problem currently is that the    IPv4  internet is full of NAT gateways which make it impossible to   use protocols other than UDP and TCP in end-user applications

User · Answer

Look at section 22 4 of Steven s Unix Network Programming   When to Use UDP Instead of TCP    Also  see this other SO answer about the misconception that UDP is always faster than TCP   What Steven s says can be summed up as follows    Use UDP for broadcast and multicast since that is your only option   use multicast for any new apps   You can use UDP for simple request   reply apps  but you ll need to build in your own acks  timeouts and retransmissions Don t use UDP for bulk data transfer

User · Answer

Comparing TCP with UDP  connection-less protocols like UDP assure speed  but not reliability of packet transmission   For example in video games typically don t need a reliable network but the speed is the most important and using UDP for games has the advantage of reducing network delay

User · Answer

UDP has lower overhead  as stated already is good for streaming things like video and audio where it is better to just lose a packet then try to resend and catch up   There are no guarantees on TCP delivery  you are simply supposed to be told if the socket disconnected or basically if the data is not going to arrive   Otherwise it gets there when it gets there   A big thing that people forget is that udp is packet based  and tcp is bytestream based  there is no guarantee that the  tcp packet  you sent is the packet that shows up on the other end  it can be dissected into as many packets as the routers and stacks desire   So your software has the additional overhead of parsing bytes back into usable chunks of data  that can take a fair amount of overhead   UDP can be out of order so you have to number your packets or use some other mechanism to re-order them if you care to do so   But if you get that udp packet it arrives with all the same bytes in the same order as it left  no changes   So the term udp packet makes sense but tcp packet doesnt necessarily   TCP has its own re-try and ordering mechanism that is hidden from your application  you can re-invent that with UDP to tailor it to your needs   UDP is far easier to write code for on both ends  basically because you do not have to make and maintain the point to point connections   My question is typically where are the situations where you would want the TCP overhead   And if you take shortcuts like assuming a tcp  packet  received is the complete packet that was sent  are you better off   you are likely to throw away two packets if you bother to check the length content

[networking] When is it appropriate to use UDP instead of TCP?

Examples related to networking

Examples related to tcp

Examples related to udp