Can't find my SharePoint Web page on IIS?

Coming from a background of ASP.net, we are used to going to the IIS Manager and locating a web page file. In SharePoint, try finding it. You will be surprised. We usually map the URL relative to the Application directory of the WFE.
When you create a new Web Application in SharePoint it creates an entry in the IIS with the application by default being hosted on the Physical Directory C:\inetpub\wwwroot\wss\VirtualDirectories\ 
All Standard Pages/Pages that you created in the SharePoint Console, ideally should have been placed in this directory, but, instead SharePoint stores them in the Content database.


Then you must be wondering how SharePoint manages to find the correct page through the URL. 
ASP.Net came up with a new concept of VirtualPathProvider. To allow users to implement custom storage of the files (web pages) without affecting the way users access web pages. SharePoint has provided a custom implementation through SPVirtualPathProvider that connects the URL with the appropriate page from the Content Database.
The SPVirtualPathProvider class works together with another class named the SPPageParserFilter to supply processing instructions to the ASP.NET page parser. For example, the SPPageParserFilter component controls whether the ASP.NET page parser compiles the ASP.NET page into an assembly DLL or whether it processes the page in a no-compile mode that is introduced with ASP.NET 2.0

Not all standard pages come from SharePoint Content database. Some pages are hosted within the SharePoint root folder. C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\
SPVirtualPathProvider will know from where a particular page has to be picked up from (File System vs. Database). These kinds of pages are called as Ghosted Pages. The pages that come from Content database are called UnGhosted pages. These are customized pages of the standard pages.


SharePoint version of the life cycle is depicted in the below image. They integrate with the ASP.Net runtime seamlessly by adding the SPHttpApplication (HttpApplication replacement for the ASP.net) containing a Module SPRequestModule with a couple of common ASP.Net modules. This finally uses the SPHttpHandler (SharePoint implementation of HttpHandler) to process requests.

Global.asax would contain a directive as 

<@Application Inherits="Microsoft.SharePoint.ApplicationRuntime.SPHttpApplication" >

Http Module and Http Handers will be registered with the application through the Web.Config.

A quick view of the IIS brings us to a couple of Virtual Directories of a SharePoint web application. If you follow the Physical path of these they point to the Root folder.

Note: The image is from the MOSS. However, they are pretty much the same with a few additions in SharePoint 2010.

• _vit_bin : Provides Windows SharePoint Services with a way to expose DLLs and .asmx Web service files at a path within the URL space of a Web application. 
• _controltemplates : Provides a repository for deploying ASP.NET user controls that can be used within pages. 
• _wpresources : Provides a repository for resource files that are deployed along with Web Parts.
• layouts :  Provides the repository for application pages. 

There is only one version of an application page scoped at the farm level, it can be compiled into a single DLL and loaded into memory once for each Web application. 

An application page, such as settings.aspx, can be accessed by adding its relative path within the _layouts directory to the end of a site’s URL

http://Litwareinc.com/_layouts/settings.aspx 
http://Litwareinc.com/sites/Vendors/_layouts/settings.aspx  
http://Litwareinc.com:1001/sites/Accounting/_layouts/settings.aspx 

Reference: http://msdn.microsoft.com/en-us/library/bb892189.aspx