CGI written using perl is saved with .cgi extension.

It can be -- but it doesn't have to be. Apache can be configured to run scripts in a certain directory as Common Gateway Interface scripts, which means Apache runs the scripts and sends the result back to the source of the original request.

Typically, this means that Linux/Unix looks at the first line in the file, known as the hash-bang line, and uses that to actually run the script. In our case, it's going to be something like

#!/usr/bin/perl -w
.
.
[download]

.. or even with the options Tw to turn tainting on. That means Linux/Unix will run the command

/usr/bin/perl -w $yourScript
[download]

and send the output back to the source of the original request.

How does this CGI get invoked ?

That's part of the Apache configuration -- basically it means, "If the script is in this directory and it's executable, run it (with the parameters that make up the rest of the URL) and send the output back to the source of the request.

The Apache configuration file will have something like

<Location /cgi-bin >
SetHandler cgi-script
Options +ExecCGI
</Location>
[download]

to configure Apache so that when it gets called with something like http://www.yournamehere.com/cgi-bin/foo.cgi it knows to treat foo.cgi as an executable script, and return the output of the script's run, rather than the script itself (which is what happens for static files).

When we want to execute perl file, we just write "perl filename.pl" and that file is executed. In case of cgi, if it is executed as "perl filename.cgi", will perl interpreter be able to understand .cgi extension ?

When you run a Perl script using the perl $scriptName, Perl doesn't care what the file extension is. It can be pl, perl, foobarbaz or have no extension at all. File extensions are important for the Windows operating systems, but Linux/Unix don't really rely on that; instead it relies on a combination of the hash-bang line and magic numbers to determine what a file type is.

Apache is actually a pretty simple application. It just handles requests the come from browsers (or anything, really) over the HTTP protocol, and responds with an HTTP response. The request is something like a GET or a POST, and the response is a chunk of status information (perhaps a 200 if things went well, a 302 if the resource moved, a 404 if the thing wasn't found, or a 500 if there was a server error), optionally followed by some data. The data canjust be the contents of a file, or it can be the output of a script. And either of those can contain links to additional bits like graphics, style sheets, Javascript files and so forth.

I used to think these things were magic too, but it's actually a fairly simple setup. I recommend you read lots about the subject, de-mystify it and then it will be a lot clearer for you.