Well, as with most things in computers, it's a lot of relatively simple concepts stitched together. To understand it fairly deeply (but not EE-deep, since I don't go there), you could start by learning these networking concepts:
- TCP/IP - since it's how the various players will talk to each other; you could learn Ethernet too - since you are likely on an Ethernet network, but that falls further into EE world. The OSI model may be a useful primer if you're not familiar with it already.
- DNS - since it's how what the user types in gets translated to IP addresses for the TCP/IP calls. Circularly enough, it's also implemented in IP - which is why it's second. It's the application layer in the OSI model.
- HTTP - since it's the application layer (there's that OSI model again) that will be used between the client and the web server.
- HTTP variations and standards, for the proxy server and hacker issues
For things like these (general Internet standards), the actual RFCs are gold. They can be dry, they can be vague, and they may not 100% reflect shipping products - but they are the best general technical resource IMO.
As usual, Wikipedia is a great first-level resource for all of this as well. It'll tell you the basics, and generally link you to the correct RFCs (RFCs have a habit of being updated, superseded, not implemented, etc. so the quick Google searches I did are likely to be somewhat incorrect).
The OS side is a bit harder. Since it's not a "standard", there's no published reference to any of it. And, even better, different OS will do things slightly differently. I'm mainly a Windows guy - I learn this type of stuff from blogs; Mark Russinovich and Raymond Chen are the 2 best guys I know of to give you this seriously technical stuff.
- OS execution - terribly complicated, you could spend years on this topic. For the purpose of web apps, it's probably enough to know the basics of memory models and maybe a little bit of assembly language to understand how the web server and browser will do their jobs.
- Pick a webserver, and it's processing model. I'm a Windows guy, so here's IIS. Since every webserver will have an extension model, it's likely that what's happening after the initial request is that it's passed to another program. So, you'll have the transfer of the request, and then you can dive into the extensions processing model. At the end of the day, they'll all buffer up a string of HTML to send back over HTTP to the client.
Speaking of HTML, now you need to know the rules for that (and CSS) so that you know what the browser does to parse it into visual elements. Oh - and since this all shows in a GUI program, you can now start down the road of message loops and input handling. It really never ends - one of the greatest (and worst) things about this profession.