Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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?)

share|improve this question
add comment

closed as off topic by womble, SvW, Ward, Scott Pack, Iain Aug 6 '11 at 13:35

Questions on Server Fault are expected to relate to professional server, networking, or related infrastructure administration within the scope defined by the community. Consider editing the question or leaving comments for improvement if you believe the question can be reworded to fit within the scope. Read more about reopening questions here.If this question can be reworded to fit the rules in the help center, please edit the question.

5 Answers

up vote 21 down vote accepted

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.

share|improve this answer
    
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 Aug 2 '11 at 12:45
5  
@viraptor: True, but as UDP is connectionless, there's not really a distinction between "listening" and "receiving". –  Adam Robinson Aug 2 '11 at 14:44
    
Same idea works with TCP, forking process with listening socket and accepting() on both. –  viraptor Aug 3 '11 at 12:55
add comment

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).

share|improve this answer
1  
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 Aug 2 '11 at 12:12
add comment

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.

share|improve this answer
    
+1 for being right in so many ways :) –  Michael Lowman Aug 2 '11 at 12:35
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.