Streaming with a Web Server

Posting and Hosting
Deploying streaming media content with the Web server approach is actually only a small evolutionary step away from the download-and-play model. Uncompressed audio and video is first compressed into a single "media file" for delivery over a specific network bandwidth such as a 28.8 kilobits per second (Kbps) modem. This media file is then placed on a standard Web server. Next, a Web page containing the media file's URL is created and placed on the same Web server. This Web page, when activated, launches the client-side player and downloads the media file. So far, the actions are identical to those in the download-and-play case. The difference lies in how the client functions.

Data Delivery
Unlike the download-and-play client, the streaming client starts playing the audio or video while it is downloading, after only a few seconds wait for buffering, the process of collecting the first part of a media file before playing. This small backlog of information, or buffer, allows the media to continue playing uninterrupted even during periods of high network congestion. With this delivery method, the client retrieves data as fast as the Web server, network and client will allow without regard to the bit-rate parameter of the compressed stream. Only certain media file formats support this type of "progressive playback". Microsoft's Advanced Streaming Format (ASF) is one of the most popular.

Web server streaming uses the Hyper Text Transport Protocol (HTTP), the standard Web protocol used by all Web servers (such as Microsoft^® Internet Information Server) and Web browsers (such as Microsoft Internet Explorer) for communication between the server and the client. HTTP operates on top of the Transmission Control Protocol (TCP), which handles all the data transfers. Optimized for non-real-time applications such as file transfer and remote log-in, TCP's goal is to maximize the data transfer rate while ensuring overall stability and high throughput of the entire network. To achieve this, using an algorithm called slow start, TCP first sends data at a low data rate, and then gradually increases the rate until the destination reports packet loss. TCP then assumes it has hit the bandwidth limit or network congestion, and returns to sending data at a low data rate, then gradually increases, repeating the process. TCP achieves reliable data transfer by re-transmitting lost packets. However, it cannot ensure that all resent packets will arrive at the client in time to be played in the media stream.