I realized today that I fundamentally don't understand how port communication works.

If I fire up an instance of a webserver listening on port 80, it can respond to many requests from many different browser tabs, all communicating over port 80.

However, I cannot start up two instances of the server, both listening on port 80, as it results in a port conflict.

I've always taken this as a given, (only one process can bind to a specific port at any given time) without ever really thinking it through -- aren't there multiple processes communicating on port 80? (ie., each of the tabs running in the browser?)

5 Answers 5


Basically, only one process can LISTEN on a port at a time (technically, one socket is dedicated to listening). But, a port can handle many sockets transferring data, a socket is a combination of local IP / port and remote IP address / remote port. In that way, once the server accepts the incoming connection while LISTENing it opens a new socket dedicated to that conversation and hands the processing off to something else, then goes back to LISTENing.

More detail here.

  • Actually you can have multiple processes listening on the same port. If you do that with multiple udp readers for example, you'll get load-balancing on the kernel level. First open the socket for listening, then fork and try to recv() in each process.
    – viraptor
    Commented Aug 2, 2011 at 12:45
  • 5
    @viraptor: True, but as UDP is connectionless, there's not really a distinction between "listening" and "receiving". Commented Aug 2, 2011 at 14:44
  • Same idea works with TCP, forking process with listening socket and accepting() on both.
    – viraptor
    Commented Aug 3, 2011 at 12:55
  • Actually, a socket is only one "endpoint" for communication. I guess what you meant to say is that a connected socket is a combination of local IP / port and remote IP / address / remote port. The word socket is so often used that it was hard for me to figure out what it's actual description is
    – westoque
    Commented Sep 19, 2016 at 16:44

Browser connects from a random high (i.e. > 1024) port on your computer to a remote server's port 80. Therefore there's no port conflict on your machine.

If you use many tabs to connect to the same remote server (or there are many users connecting to the server) they all go to the same port and are serviced by the same process (i.e. the web server of the site).

  • 2
    This is the correct answer. TCP connections have a port number on both ends. Both computers involved can distinguish between the connection website:80 <-> browser:12397 and the different connection website:80 <-> browser:22958.
    – pjc50
    Commented Aug 2, 2011 at 12:12

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.

  • +1 for being right in so many ways :) Commented Aug 2, 2011 at 12:35

There are, effectively, two "types" of stream sockets. One has a wild-card "other end", one has a specific host:port for the other end.

No two sockets can (or, rather, should ever) have the same "this end" and "other end" identifiers. The socket that is "listened to" (accepting incoming connections) is the one that has a wild-card "other end", so only one at a time can exist. As connections arrive, an accept is done, returning a socket with a host:port tuple for the other end.


Your question reminds me of myself a few years back before Cisco CCNA - had the same doubts :)

First off, establishing multiple HTTP connections isn't necessarily tied to the amount of tabs you have open in your browser. When visiting a site with ads or google analytics code for example, you will be connecting to multiple sites despite only being in one tab.

Anyway, when your browser communicates with the webserver, the destination port of the traffic sent to the webserver, is port 80, while the source port is a random number. The source port is to let the webserver know which port he should communicate back to you at. Each http established connection will have it's own port open on your computer. Try running netstat with a few websites open and you will immediately see what I mean.

You might laugh but this book is a great & fast way to get the basics down of TCP/IP. It helped me a lot.

Not the answer you're looking for? Browse other questions tagged .