Very little. UDP has ports, data length and a checksum. The checksum is perhaps redundant in the context of the checksums provided by other layers (and can, indeed be omitted), but the ports are essential to distinguish multiple services on a single host. The length is again not really needed, but helps the layer independence. All the other functionality of UDP is provided by the IP layer.
Easiest example is DNS. Lost: timeout and resend. Duplicate: ignore as the content will the same.
Video and radio streaming. Lost: normally a few seconds' worth of sound is buffered up so it can resend and get the data before it is missed. Sometimes the player will attempt to interpolate lost data, usually not very successfully. This causes freezes or blockiness in video and clicks or other noise in sound. Duplicate: again ignored.
See /etc/services or IANA.
Pro: no fixed port means the service can move and avoid, say, blocking by firewalls or ISPs. If a service is not running it does not block the use of any port. A service will be hidden to some extent from unauthorised users who don't know the current port (a very weak form of security).
Con: no fixed port means the service can move and avoid, say, blocking by firewalls or ISPs. Some extra means must be provided to determine which port a service is currently using (e.g., portmapper for NFS).
The original RFC for TCP (protocol 6) was RFC793 (1981), while UDP (protocol 17) appeared in RFC768 (1980), but the ideas for TCP arose in a paper by Cerf and Kahn in 1974 which became the Transmission Control Program (note the slight difference in name) in RFC675 (1974).
This TCP was the only protocol on the Internet, but after a revision (v2) it was realised that the functionalities of reliability and routing would be better split into separate layers, namely TCP and IP (v3, 1977/78). By the next version (v4, 1980) these became TCP and IP as we understand them.
About the same time it was realised that not every application wants the costs of reliability and the splitting into TCP+IP allows the replacement of TCP by the "unreliable" UDP, thus keeping the features (like routing) of IP.
UDP-Lite (protocol 136) starts with the observation that some applications would prefer damaged data to no data at all (e.g., audio). However, the UDP checksum either checks all the data or none of the data (when the checksum field is not filled in). If anything fails to check, the entire datagram is rejected and must be resent (where necessary).
UDP-Lite replaces the length field with a checksum coverage field. The length can be recovered from the IP header. The coverage field tells us how much of the header and data should be checked (all of the header is always checked). So this allows us to have checked and unchecked areas of data, e.g., header and data sections for a chunk of sound. The header could be checked, while errors in the data would be allowed.
This gives the network much better throughput as we don't have to resend when we don't care about data errors.
You should see the SYNs and FINs as described and should be able to follow the count of bytes in the ACKs. Take care if the dump contains the traces of several simultaneous connections, as is likely.
Straightforward. Again, take care to separate out the several simultaneous connections.
There are still a few unreliable connections about, particularly those including wireless links.
You would expect to see the features as described, such as congestion control, fast retransmit and recovery and even ECN.
TCP typically uses a lot of optional headers, particularly timestamps in data packets and MSS, SACK and window scales in SYN packets.
UDP is pretty straightforward: just send a packet to an open port. If you are careful you might want to forge the source IP address (in case the application is checking).
TCP is somewhat harder. There are several fields that must be got right, including the source IP address, the source and destination ports and the sequence number. If you can sniff the traffic, you might be able to get these correct, if not, it is a lot harder.
This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 License.