Most programs use either UDP or TCP for communications. TCP is the more sophisticated of the two protocols, providing reliable, connection-oriented delivery. First, TCP ensures that the receiving computer is ready to accept data. It uses a three-packet handshake in which both the sender and receive agree that they are ready to communicate. To do so, a TCP packet uses packet state flags to let each host communicate the current state (i.e., beginning, ending, ongoing) of transmission. (TCP traffic is stateful.) Second, TCP makes sure that data gets to its destination. If the receiver doesn't acknowledge a particular packet, TCP automatically retransmits the packet—typically three times. If necessary, TCP can also split large packets into smaller sizes so that data can travel reliably between source and destination. TCP drops duplicate packets and rearranges packets that arrive out of sequence.
UDP, which isn't connection-oriented, is more appropriate for sending limited amounts of data per packet. UDP has no self-checking mechanism to ensure that data is received or received in order. However, the application that uses UDP will often perform that check, so the application can send a request to the source computer to retransmit missing information. UDP is also stateless; therefore, UDP offers no setup handshake and a UDP packet doesn't have state flags.
Some programs use both UDP and TCP. For example, a RealNetworks RealAudio server uses port TCP 7070 to initiate a download connection to a RealAudio Player client. After the session is established, the RealAudio server streams the data over UDP ports 6970 through 7170. In another example, Microsoft DNS uses UDP 53 for communication between DNS servers. If one DNS server establishes that the other DNS server is also a Microsoft DNS server, it might decide to switch the network connection to 53 TCP so that it can send larger amounts of domain naming data.
