|
This information has been provided
courtesy of the Microsoft web site. We sell a Microsoft-based streaming
server solution and this is their white paper explaining the advantages
of using a streaming server over a traditional non-Microsoft web
server. Please inquire for pricing and more details about our streaming
solutions.
Web Server vs. Streaming
Server
Abstract
There are two major methods of delivering streaming audio and video
content over the Web. The first method uses a standard Web server
to deliver the audio and video data to a media player. The second
method uses a separate streaming media server specialized to the
audio/video streaming task. This paper shows that, while Web server
streaming can be an effective interim solution, a streaming server
is more efficient and flexible and provides a better user experience.
Introduction
Until recently, audio and video on the Web was
primarily a download-and-play technology. You had to first download
an entire media file before it could play. It was like pouring milk
into a glass and then drinking it. But because media files are usually
very large and take a long time to download, the only content found
on the Web was short 30-second clips—often even shorter. Even
these files could take 20 minutes or longer to download. In other
words, it took a long time to pour the milk, and then it would barely
quench your thirst.
Watching audio and video files that stream is more like drinking
straight from the carton; streaming media files begin playing almost
immediately, while the data is being sent, without having to wait
for the whole file to download. Other than a few seconds of delay
before the file starts to play, you don't have to wait to start
watching, no matter if the file lasts 30 seconds or 30 minutes.
As audio and video streaming over the Internet has become more popular,
two primary methods for streaming content have emerged. The first
method is the Web server approach, in which a standard Web server
is used to supply data to the client. The second method is the streaming
media server approach, in which a specialized streaming server delivers
the data to the client. Both methods have advantages that we will
discuss, but first let's take a look at the way each process works.
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.
Streaming with a Streaming Media Server
Posting and Hosting
In the streaming media server approach, the initial steps are similar
to the Web server approach, except that the compressed media file
is produced and copied to a specialized streaming media server (such
as Microsoft Windows Media Services) instead of a Web server. Then
a Web page with a reference to the media file is placed on a Web
server. Windows Media Services and the Web server may run on the
same computer.
Data Delivery
The rest of the streaming media server delivery process differs
significantly from the Web server approach. In contrast to the passive
burst methodology employed in Web server streaming, the data is
actively and intelligently sent to the client, meaning that it delivers
the content at the exact data rate associated with the compressed
audio and video streams. The server and the client stay in close
touch during the delivery process, and the streaming media server
can respond to any feedback from the client.
While streaming media servers can use the HTTP/TCP protocols used
by Web servers, they can also use specialized protocols such as
the User Datagram Protocol (UDP) to greatly improve the streaming
experience. Unlike TCP, UDP is a fast, lightweight protocol without
any re-transmission or data-rate management functionality. This
makes UDP an ideal protocol for transmitting real-time audio and
video data, which can tolerate some lost packets. As a bonus, because
of the back-off policies implicit in the TCP protocol, UDP traffic
gets higher priority than the TCP traffic on the Internet. And instead
of the blind retransmission scheme employed by TCP, streaming media
servers such as Microsoft's Windows Media Services use an intelligent
retransmission scheme on top of UDP. Windows Media Services' UDP
Resend feature ensures that the server only retransmits lost
packets that can be sent to the client in time to get played.
The differences between the Web server and streaming
media server solutions translate into clear distinctions in both
ease of implementation, ease of management, and quality of user
experience. For the remainder of this white paper, the comparison
will be between a generic Web server and Microsoft's streaming media
server, Windows NT Server Windows Media Services (hereafter referred
to as a Windows Media server).
Streaming with a Web Server: the Advantages
There is really only one major advantage to streaming
with a Web server rather than with a streaming media server—utilizing
existing infrastructure. Because the Web server approach uses only
the standard Web server--that presumably already exists in the organization—no
new software infrastructure need be installed or managed. The Windows
Media server approach, on the other hand, requires the content producer
and/or the systems administration staff to install and manage additional
server software. This can result in incremental training and staffing
costs to learn and manage the more complex, but also more powerful,
Windows Media server environment.
It is important to note that the increased load that Web server-based
streaming puts on existing Web server infrastructure often results
in the need for additional Web server hardware to service the client
requests. Choosing Web server streaming over a dedicated streaming
media server based on hardware cost alone usually does not result
in any financial savings.
Streaming with a Windows Media Server: the
Advantages
Designed specifically for the task of delivering live or on-demand
streaming media rather than many small HTML and image files, a Windows
Media server offers many advantages over standard Web servers.
- More Efficient Network Throughput.
We've already mentioned one of the main advantages of Windows
Media server streaming—the ability to use UDP, the specialized
protocol optimized for live and on-demand streaming. The TCP-based
transfer used in Web server streaming is designed to repeatedly
drive the slowest network link (likely the 28.8 Kbps modem link)
to packet loss. This wastes bandwidth by: (i) re-transmitting
data to replace the lost packets; and (ii) under-utilizing the
network link while re-estimating the throughput that can be supported
by the network connection.
The UDP protocol allows higher bandwidth to be delivered to the
client (resulting in better video quality), even when assuming
the same network connectivity between server and client and the
same level of congestion on the Internet. By having a specialized
streaming media server, we know what rate the data is going to
be consumed, based on headers of the compressed media file. The
Windows Media server sends data to the client (Windows®
Media Player) only at this required bit-rate, and it doesn't drive
the bottleneck network link to loss. Thus the network throughput
is better, resulting in better quality audio and video for the
client.
- Better Audio and Video Quality to the
User. Better network throughput is only one of several ways
that a Windows Media server delivers superior audio and video
quality for users. Here are two more examples:
- Because the Windows Media server and
the Windows Media Player remain in contact throughout the
play interval, the server can dynamically respond to client
feedback. If network congestion is allowing only 22 Kbps of
data to reach the client (instead of 28.8 Kbps), the server
can decide to retain the audio quality but slightly lower
the frame rate of the video stream so that it doesn't overshoot
the available 22 Kbps. This ability is not possible with the
Web server approach. In a Web server scenario, with no feedback
from the client and no ability to dynamically prioritize audio
over video, the audio/video delivered by a Web server would
be stop-and-go at the client, causing the insidious "rebuffering"
delays common to early implementations of streaming media.
In contrast, the Windows Media server provides a continuous,
smooth stream with barely perceptible changes in video frame
rate during periods of network congestion.
- Streaming with a Windows Media server
takes advantage of UDP's inherent higher priority over HTTP
traffic to give the streaming audio and video data higher
priority than file and Web page transfers. This increases
the likelihood of uninterrupted viewing.
- Support for Advanced Features. The
Windows Media server approach supports such advanced features
as detailed reporting of streams played, VCR controls (seek, fast-forward,
rewind), live video delivery, and delivery of multiple streams
to the client. With Web server streaming such features, if they
are even possible, are difficult to implement and inefficient
to support.
- Cost Effective Scalability to Large
Number of Users. In the early days of streaming media, deployments
often needed to serve only a small number of users simultaneously,
making Web server streaming an adequate solution. But as delivery
of audio and video has increased, sites often serve hundreds or
thousands of simultaneous users. In these situations, two key
capabilities of the Windows Media server provide increasing advantages
over a Web server:
- Specialization. In the Web server
approach, the Web server is used to deliver the media files
to the client. Web servers, however, are optimized for delivering
lots of small HTML files, not large media files. With high
volumes of file requests, a Windows Media server greatly improves
performance by optimizing how media files are read from the
disk, buffered in main memory, and streamed onto the network.
A Windows Media server can easily improve scalability by a
factor of 2 to 3 over a Web server.
- Multicast Support. One way to
get live or stored audio and video to large audiences with
minimum network congestion is to use multicast networking
technology. Multicast allows a single media stream to be played
simultaneously by multiple clients, drastically reducing bandwidth
use. Only a specially designed streaming media server, such
as a Windows Media server, has this capability.
- Protection of Content Copyright.
Because Web server streaming creates a local cached copy of every
media file played, there is no way to prevent end users from copying
the files to a personal directory for later viewing. This hurts
content providers who have a pay-per-view business model, or who
have an advertisement-based revenue model, as the end users need
not visit their site repeatedly. With a Windows Media server,
users can only stream data and are prevented from downloading
the file directly to their hard disk. As data packets are received
over the network, they are delivered directly to the client application
with no easy way for the end user to intervene and make a copy.
- Multiple Delivery Options. With
a Windows Media server, the media may be streamed with the optimal
UDP or Multicast protocols when possible, and streamed with the
TCP protocol when necessary. This enables corporate users to view
Internet content without compromising firewall security and ensures
that all users on all networks can access all streaming media
content. The Windows Media server implements its own version of
the HTTP protocol to enable streaming through a firewall or proxy
server while still retaining most of the advantages a Windows
Media server.
Windows Media Services support four different
protocol configurations, each offering specific benefits.
- UDP – As detailed in the
Windows Media server section, UDP provides the most efficient
network throughput and can have a very positive impact on
the user (player) experience. The only downside to UDP is
that many network administrators close their firewalls to
UDP traffic, limiting the potential audience of UDP-based
streams
- TCP – As detailed in the
Web server section, TCP provides an adequate, though not necessarily
efficient, protocol for delivering streaming media content
from a server to a client. As customers often open the TCP
ports in their firewalls, Windows Media Services can use the
TCP protocol enable streaming media to flow through these
firewalls, which often block UDP traffic.
- HTTP + TCP – The Windows
Media server can also support HTTP-based control commands
along with TCP-based data delivery. This combination has the
benefit of working with all firewalls that let Web traffic
through (port 80) and provides much more control (fast forward,
rewind, etc) than a standard Web server, but also adds some
overhead to the raw TCP stream that decreases scalability.
- Multicast – The Windows
Media server can also support IP Multicast protocols to allow
very efficient delivery of streaming content to large numbers
of users. Multicast enables hundreds or thousands of users
to play a single stream, but will only work on networks with
Multicast-enabled routers. Multicast is becoming prevalent
on corporate networks, but is still very rare on the Internet.
The Windows Media server will automatically switch to the appropriate
protocol so no client-side configuration is necessary. The server
will initially attempt to transmit files using the optimal UDP
or Multicast protocols. If unable, the server will then attempt
to send first via the raw TCP protocol, then via TCP with HTTP-based
control.
Conclusion
This paper has evaluated the two primary methods for streaming media
content to users. The first, the Web server approach, uses a standard
Web server and the associated HTTP and TCP protocols to request and
deliver the content for the client. The second approach uses a streaming
media server specialized to the audio/video-streaming task. The specialization
takes many forms, including optimized routines for reading the huge
media files from disk, the flexibility to choose any of UDP/TCP/Multicast
protocols to deliver data, and the option to exploit continuous contact
between client and server to dynamically improve content delivery
to the client.
The primary advantage of the Web server approach is that it requires
one less software component (the streaming media server) to learn
and manage. This method can be an effective first step in developing
a streaming solution.
The streaming media server approach, using Microsoft Windows NT Server
Windows Media Services, has these advantages:
- More efficient use of the network bandwidth.
- Better audio and video quality to the user.
- Advanced features like detailed reporting
and multi-stream multimedia content.
- Supports large number of users.
- Multiple delivery options.
- Content copyright protection.
The tradeoffs clearly indicate that, for virtually all providers of
streaming media content, the Windows Media server approach is the
superior solution.
Back to the top |