Well it's good you're aware of processes and ports, because that's the key thing. Then I would focus more on how they relate to each other, and to the outside w

Well it's good you're aware of processes and ports, because that's the key thing. Then I would focus more on how they relate to each other, and to the outside world. Server processes bind to a port, and then run some code to handle inbound messages. For a web server, the inbound messages are string key/value pairs. By convention, there is special support for file access in HTTP, which is the path section of the URL. Webapps use the path just as an ordinary string. There are really two parts to understanding the system: first, configuring all the processes and spinning them up in the right order. Second, once it's running, how messages flow through those processes. A reverse proxy is terrible jargon for a server process that listens on one port and forwards the traffic to another (usually local) port. (It's called a reverse proxy because forward proxies are used by clients connecting out to servers). You might have 4 server processes. Nginx, Apache/PHP, Rails (RVM) and MySQL. The first three can all listen on port 80, but we pick Nginx to serve that role, and configure it to do so and forward to Apache and the RVM, which are configured for arbitrary higher ports. Meanwhile, you've probably configured Apache and RVM to be able to talk to MySQL (with 'drivers') and configured them to know about your running MySQL instance. All 4 of these processes are probably emitting logs to disk somewhere, too. Interestingly, in the absence of a request, all of these processes just sit there. They do nothing, and use precisely 0 of your CPU. It is only when a client process presents Nginx on port 80 with a new string that they all come to life: nginx first, then PHP (say), then, if the stars align, MySQL. The confirmation bubbles back up a distributed call chain and out to the client. Yay, CRUD.