views:

246

answers:

7

If I understand right, applications sometimes use HTTP to send messages, since using other ports is liable to cause firewall problems. But how does that work without conflicting with other applications such as web-browsers? In fact how do multiple browsers running at once not conflict? Do they all monitor the port and get notified... can you share a port in this way?

I have a feeling this is a dumb question, but not something I ever thought of before, and in other cases I've seen problems when 2 apps are configured to use the same port.

+7  A: 

Outgoing HTTP requests don't happen on port 80. When an application requests a socket, it usually receives one at random. This is the Source port.

Port 80 is for serving HTTP content (by the server, not the client). This is the Destination port.

Each browser uses a different Source to generate requests. That way, the packets make it back to the correct application.

Justin Niessner
But what if my client/server communicate on 80... if the client receives a message on port 80 (why) won't the browser intercept it as HTTP content?
John
The client will CONNECT to port 80 on the server, but will use another port itself. Try it yourself: download a file from a server (eg a youtube video), open a prompt and type "netstat". Your own machine will use a random port (like 62123) to connect to the server on port 80.
Konerak
@John, no. The *web server* opens port 80, but the *browser* has a different, randomly-assigned port. If your app communicates on port 80 then you prevent your app from being used on the same machine as a web server, but you don't interfere at all with web browsing.
JSBangs
Furthermore, the random port chosen is guaranteed to be numbered above 1024, as the range 1-1024 is reserved for specific essential services such as HTTP(S), FTP, DNS, etc.
alastairs
A: 

A browser is a client application that you use in order to see content on a web server which is usually on a different machine. The web server is the one listening on port 80, not the browser on the client.

ob1
+2  A: 

Port 80 you're talking about here is the remote port on the server, locally browser opens high port for each connection established.

Each connection has port numbers on both ends, one is called local port, other remote port.

Firewall will allow traffic to high port for browser, because it knows that connection has been established from you computer.

vartec
"locally browser opens high port for each connection established"... how does this get through a firewall then? Do firewalls leave a specific range of ports open by default?
John
@John: generally, a firewall will detect the ports and addresses involved when the connection is first established by the client, and will allow the return traffic from the server through automatically as long as the connection is "alive".
Dave Costa
Firewalls allow outgoing connections on any port. They usually block incoming connections on most ports unless you explicitly open them.
TomA
@John The firewall monitors all the outgoing TCP connections established by clients behind the firewall, and opens a hole for responses to those connections. In practise it's likely to be more complicated than that, because most firewalls will also be performing Network Address Translation (NAT), i.e. rewriting the local IP address and port on all outgoing TCP/UDP packets to use the site's single public IP address and a new local port, in which case the reverse translation has to be applied to the remote port and IP address of the responses.
jchl
OK I get the idea though... even if you block port X, if you send a request to remote port 80 with local port X, the firewall is smart enough to let the response back through.
John
"Blocking port X" usually actually means "blocking listening on port X". Also, firewall is smart enough to only let traffic in for that port **only** from the server to which connection was established.
vartec
+2  A: 

You need to be careful in making the distinction between "listening on port 80" and "connecting to port 80".

When you say "applications sometimes use HTTP to send messages, since using other ports is liable to cause firewall problems", you actually mean "applications sometimes send messages to port 80".

The server is listening on port 80, and can accept multiple connections on that port.

Konerak
+3  A: 

It is the 5-tuple of (IP protocol, local IP address, local port, remote IP address, remote port) that identifies a connection. Multiple browsers (or in fact a single browser loading multiple pages simultaneously) will each use destination port 80, but the local port (which is allocated by the O/S) is distinct in each case. Therefore there is no conflict.

jchl
So internally, the server sends the response back to client's <local port>?
John
Right, in the response the server switches the local and remote port and local and remote IP address, so the response has local port = 80 and remote port = <client's local port>.
jchl
+2  A: 

Clients usually pick a port between 1024 and 65536. It depends on the operating system how to handle this. I think Windows Clients increment the value for each new connection, Unix Clients pick a random port no.

Some services rely on a static client port like NTP (123 UDP)

SchlaWiener
+6  A: 

There are 2 ports: a source port (browser) and a destination port (server). The browser asks the OS for an available source port (let's say it receives 33123) then makes a socket connection to the destination port (usually 80/HTTP, 443/HTTPS).

When the the web server receives the answer, it sends a response that has 80 as source port and 33123 as destination port.

So if you have 2 browsers concurrently accessing stackoverflow.com, you'd have something like this:

Firefox (localhost:33123) <-----------> stackoverflow.com (69.59.196.211:80)
Chrome  (localhost:33124) <-----------> stackoverflow.com (69.59.196.211:80)
Flavius Stef