The advantage of using them instead of simply distributing audio or video files is twofold. First, if a web browser encounters an audio or video file, it needs to download the entire file before playing it. This can mean a long and extremely boring wait if the file is eventually going to play for more than a few seconds. Few people are willing to hang around watching a transfer progress meter move for 20 minutes in order to watch a 10-second movie. Second, because the files are downloaded, users are not only able to make their own copies, they're encouraged to do so; once they've waited the 20 minutes, they're certainly not going to delete the local copy of the file! If you want to keep track of who's watching the file when, and you don't want copies of it floating around, this is extremely undesirable.

Protocols for distributing audio and video tend to based on UDP because people are more tolerant of having small amounts of data lost than of having pauses. With TCP, if a packet is lost, there will be a wait for retransmission, which is much more annoying than just going on to the next packet. Audio and video protocols also tend to use multiple ports in order to maximize efficiency. Because of these characteristics, these protocols tend to be difficult to support through firewalls.