Let me preface this by saying this is extremely generic and simplified view of what happens.
Web server software (like Apache or IIS) does not interpret any code; it doesn't know how to. All it knows how to do is take a request, look it up in some location on the filesystem, and then send the item requested back to the browser. That's all it does - at a very simple level. This is why when you install Apache and add some php file to the DocumentRoot, you don't get the executed PHP result; just the file back.
The first step in getting the server to do something other than serve files is to add code that tells it to do something else when a specific file is requested; otherwise all it will do is try to serve the file according to its default mime type (which is usually text/plain). This is why when you have an incorrectly configured server, and you request index.php, you see the source code for the file instead of the intended result.
So to get a web server to "understand" PHP, you have to tell it what to do when a request for a file with the .php extension comes in. This is where mod_php comes in. This module offloads the request to a PHP interpreter (how it does that can be configured), which then reads the file, executes the code, compiles the results; and sends the results back to the server, which in turn delivers the results to the client. You then configure the webserver so that all files that have .php in the end should be handled by mod_php.
This basic workflow is applied with other languages as well; the only difference is what the server 'offloads' the request to.
The case for PHP is explained above, there is similarly mod_python, and fastcgi, wsgi and other established protocols on offloading requests that a web server is not designed to handle.
Most common implementations have a long running process that waits for a request on a specific port (or socket). The web server is then configured as a proxy, so that it passes any requests that match a specific pattern to this long-running process and then read the results back.
This is how ruby on rails (rack), python scripts (with wsgi) work.
This is also why simple proxy-like web servers like nginx are very popular. They only do the very basic tasks of a traditional web server - serve the "static" files, and are very good at offloading requests to other proxy servers to handle things like PHP, Python, ASP, et. al.
So in the end you have the web server - which takes care of the static files, anything that doesn't need processing.
You have another process, which knows how to deal with your code (for example, a process that runs the PHP interpreter, or a uWSGI server). This sits and waits for requests from the web server.
Finally, you have systems like upstart and supervisor that manage these processes for you.
Hope this clarifies the matter.
