The server listening on port 80 doesn't HAVE to handle multiple processes. Simple TCP daemons of elder years could only handle one connection at a time. You can emulate this behavior by having a program like netcat
listen on a specific port and try to connect two machines to it. One will get in, the other will bounce off without a connection. These daemons are mostly-useless so you never see them any more.
For something like a web-server, it's listening on the port directly. The thing to keep in mind is that it is sitting on top of the operating-system's socket library. When a new connection is established, the socket library passes the brand new socket to the web-server software. At that point, the web-server software has some options.
One possibility is that it passes the socket-object to a new thread in the same process. Whenever communication happens over this socket, this thread will handle it. The parent process mediates which threads are active at any given time, which could be a lot.
Another possibility is that it spins up a new process and passes the socket-object to the process. As I understand it, it's now up to the operating system's socket system mediate communication between these child-processes and their targets. The parent process still has some control over the processes, such as killing hung ones and other inter-process communications.
Which of these approaches is more efficient depends on the operating system. IIRC, Apache can run in either mode.
In essence, the socket library provides a level of parallel processing to the web-server. It can handle multiple simultaneous connections actively transferring data, all while accepting new connections.
For a browser that can spin up multiple connection attempts to a webserver in order to improve load times, parallelism applies on the browser end as well, this is a good and wonderful thing. The browser keeps track of the state of the page as it is loading, and the multiple connection attempts it spins up are all part of the process.