||This article includes a list of references, but its sources remain unclear because it has insufficient inline citations. (June 2010) (Learn how and when to remove this template message)|
FastCGI is a binary protocol for interfacing interactive programs with a web server. FastCGI is a variation on the earlier Common Gateway Interface (CGI); FastCGI's main aim is to reduce the overhead associated with interfacing the web server and CGI programs, allowing a server to handle more web page requests at once.
CGI is a protocol for interfacing external applications to web servers. CGI applications run in separate processes, which are created at the start of each request and torn down at the end. This "one new process per request" model makes CGI programs very simple to implement, but limits efficiency and scalability. At high loads, the operating system process creation and destruction overhead becomes significant. In addition, the CGI process model limits resource reuse techniques (such as reusing database connections, in-memory caching, etc.).
To address the scalability shortcomings of CGI, Open Market developed FastCGI and first introduced it in their webserver product in the mid-1990s. Open Market originally developed FastCGI in part as a competitive response to Netscape's proprietary, in-process API (NSAPI) for developing Web applications.
Although initially developed by Open Market, FastCGI was implemented by a number of other webserver makers. The FastCGI approach, however, competed against other techniques which also aimed to speed and simplify server-subprogram communications. Apache modules such as mod_perl and mod_php appeared around the same time, and they also quickly gained popularity. Today, all of these various approaches (including CGI) remain in common use.
Instead of creating a new process for each request, FastCGI uses persistent processes to handle a series of requests. These processes are owned by the FastCGI server, not the web server. 
To service an incoming request, the web server sends environment information and the page request itself to a FastCGI process over either a Unix domain socket, a named pipe or a TCP connection. Responses are returned from the process to the web server over the same connection, and the web server subsequently delivers that response to the end-user. The connection may be closed at the end of a response, but both the web server and the FastCGI service processes persist.
Each individual FastCGI process can handle many requests over its lifetime, thereby avoiding the overhead of per-request process creation and termination. Processing of multiple requests simultaneously can be achieved in several ways: by using a single connection with internal multiplexing (i.e. multiple requests over a single connection); by using multiple connections; or by a combination of these techniques. Multiple FastCGI servers can be configured, increasing stability and scalability.
Web site administrators and programmers can find that the separation of web applications from the web server in FastCGI has many advantages over embedded interpreters (mod_perl, mod_php, etc.). This separation allows server and application processes to be restarted independently – an important consideration for busy web sites. It also enables the implementation of per-application / hosting service security policies, which is an important requirement for ISPs and web hosting companies. Different types of incoming requests can be distributed to specific FastCGI servers which have been equipped to handle those particular types of requests efficiently.
None of the audio/visual content is hosted on this site. All media is embedded from other sites such as GoogleVideo, Wikipedia, YouTube etc. Therefore, this site has no control over the copyright issues of the streaming media.
All issues concerning copyright violations should be aimed at the sites hosting the material. This site does not host any of the streaming media and the owner has not uploaded any of the material to the video hosting servers. Anyone can find the same content on Google Video or YouTube by themselves.
The owner of this site cannot know which documentaries are in public domain, which has been uploaded to e.g. YouTube by the owner and which has been uploaded without permission. The copyright owner must contact the source if he wants his material off the Internet completely.