UDP is a "best-effort" protocol. Each packet is sent without worring about if it reaches or not. The packet delivery and the acknowledgments are handled by the upper layers. TCP handles the connection, the successful delivery and the throughput as well. UDP could be useful for sensor networks and packet-oriented applications where data streaming and real time applications are not required.

UDP and TCP are used in different situations for different applications. Applications requiring high reliability such as a 1GB file transfer are done by ftp using TCP. As now if  some packets are lost the whole 1GB transfer will be useless as it will end up in a corrupt file. UDP is unreliable and connection less which suits real time applications such as VOIP and streaming. Packet loss upto certain limit in these applications are not as critical as in a file transfer. Because even if a few packets are lost  you will fee glitches in your streaming or VOIP but still you will be able to run your video or voice.  Secondly TCP has many variants depending upon how they react to packet loss by controling its window size. You also need to consider that behavior when evaluating it. 

Dear Sudhakar Mishra,

I don't know which tool did you use to make the experiment. However, I encourage you to try the iperf tool.

https://iperf.fr/

http://sourceforge.net/projects/iperf/

Best regards.

Using UDP it is possible to get a performance as good as allowed by the supplied QoS. Datagrams loses must be handed by the application because UDP don’t care of it, offering a Best-effort service.

TCP performance depends strongly on the congestion mechanisms that slows down the segment transmission when a segment is lost. Throughput in segments is modeled approximately in Reno by the inverse square formula X(p)=(1/RTT)*Sqrt[ 3/(2*p)] where p is the probability of missing a segment. Greater values of p and RTT result in smaller throughput consequently low performance.

TCP has been under optimizing recent years. For example, TCP congestion control RENO has been replaced by CUBIC, which has shown much better performance in high bandwidth large delay networks, in Linux and FreeBSD. Also TSO and similar offloading have improved CPU usage. Google's Youtube uses TCP for streaming, which demonstrates TCP's robustness over UDP. As in my knowledge, UDP adoption starts to be falling behind TCP as over 90% of Internet traffic is TCP.

In an empty, or non-congested network, UDP is more efficient than TCP and offers a better throughput. However, as soon as packets can be lost, TCP is optimised to recover the lost information whereas UDP leaves it to the application, which may be less efficient than TCP. If the throughput is computed at application level, this could explain your results.

In theory, UDP is more efficient for two types of applications:

- applications that send very small amount of information sporadically (typically sensors), as setting up a TCP connection takes time and is useless if the message can be carried in a single IP packet

- stream like applications, which request a bitrate set by the application (e.g. VoIP or VoD stream). In that case, some small losses can be supported by the application especially if it implements FEC

In practice, UDP is not systematically used for stream like applications as it may be blocked at Firewalls. In particular, advanced methods such as http streaming are currently used, over TCP, to support VoD applications.

TCP is a data transport protocol designed for reliable delivery of data end-to-end. The cost for the reliable delivery of data is loss in goodput in contrast to UDP which does not guarantee delivery as the expense of throughput.

you are right depending on the simulation you considered you may get more throughput in UDP over TCP.  This is because Tcp has congestion control.algorithms in built into it. So wheneber there is congestion in the network TCP connections will slow down their rate and bring the network out of the congested state.  Moreover if a packet gets dropped due to congestion or channel error TCP retransmits the packet and reduces its congestion window or rate to half.  This is ti provide reliabolity of data transfer and emsure the network does not go into congrested state. However in TCP even if the data loss is due to chsnnel error and not congestion  TCP is not able to distinguish and rate is decreased  

Hence TCP somerimes give less throughput than UDP. it is not as such because of header overhead UDP overhread or header is less than TCP.   In case of UDP it does not bother about network state or packet error. it judt transmits the packets.  If the packets are received fine else they are just

TCP is connection orientated (ref: three-way handshake) with priority for reliability - leading to issues of delay.

UDP is connectionless orientated most suited for real-time usage - e.g., live streaming 

I am assuming throughput as number of bytes travelling per second on a link at a given point

In case of Delay UDP is Better than TCP because it works on fire and forget (Send and forget)concept and there is no ACK policy in UDP, but in case of Packet loss TCP is better than UDP because it works with the ACK policy.