Do web browsers use different outgoing ports for different tabs?

57

36

In a web browser that supports having multiple tabs, such as Firefox, do different tabs that go to different website domains use a dedicated port for each domain?.

Or does the browser use a single port for managing all tabs and therefore all domains?.

yoyo_fun

Posted 2016-03-20T20:32:03.687

Reputation: 1 443

Browsers use 2 ports when connecting to websites, 80 is for http connections, 443 is for https connections. https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers

– Moab – 2016-03-20T20:43:32.450

7I know the ports used to connectto the server, but I was wondering about the port numbers used to connect from the client (host computer). – yoyo_fun – 2016-03-20T20:49:26.897

2I think that the term, "outgoing ports," is imprecise. Ports are bi-directional. Maybe you could say. "local ports," instead. The local ports are used as source (outgoing) ports for sending requests, and destination (incoming) ports for receiving responses. – Ron Maupin – 2016-03-20T20:53:57.063

6Ports are assigned by the OS and each new connection is assigned a new local port to make it distinct from all other open connections. – Ex Umbris – 2016-03-21T01:51:17.460

1@ExUmbris: That may be a sensible and simple strategy, but TCP connections are identified by the quad { local IP, local port, remote IP, remote port}. Local port isn't necessary for uniqueness, which is a good thing: the webserver cannot use its local port at all for uniqueness. And from the webserver's perspective, remote IP isn't unique either as multiple users may be located behind a single gateway/proxy. – MSalters – 2016-03-21T14:57:44.257

Answers

55

Do browsers use different ports to connect to different websites?

Yes, they do.

Here is an example, showing my current Firefox connections (I have 9 open tabs) on Windows 7:

enter image description here

Notes:

  • You can see that the local ports are all different.

  • The remote ports are usually 80 (HTTP), 443 (HTTPS) or 8080 (HTTP Alternate).

  • The full process of rendering a web page is described below. See in particular steps 5, 6, 13 and 15 (which are in bold):

    • In general rendering a single web page uses multiple connections, not all of which will be to the same remote address.

    • This is because web pages often include resources hosted elsewhere (javascript files, etc).

  • Multiple connections to the same website (eg stackoverflow.com) also have different local ports (because they are separate connections in different tabs rendering different pages).


Rendering a web page – step by step

Note:

  • Steps 5, 6, 13 and 15 (which are in bold) are directly relevant to the question.

Have you ever thought about what happens when you surf the web? It’s not as simple as it seems:

  1. You type an URL into address bar in your preferred browser.
  2. The browser parses the URL to find the protocol, host, port, and path.
  3. It forms a HTTP request (that was most likely the protocol)
  4. To reach the host, it first needs to translate the human readable host into an IP number, and it does this by doing a DNS lookup on the host
  5. Then a socket needs to be opened from the user’s computer to that IP number, on the port specified (most often port 80)
  6. When a connection is open, the HTTP request is sent to the host
  7. The host forwards the request to the server software (most often Apache) configured to listen on the specified port
  8. The server inspects the request (most often only the path), and launches the server plugin needed to handle the request (corresponding to the server language you use, PHP, Java, .NET, Python?)
  9. The plugin gets access to the full request, and starts to prepare a HTTP response.
  10. To construct the response a database is (most likely) accessed. A database search is made, based on parameters in the path (or data) of the request
  11. Data from the database, together with other information the plugin decides to add, is combined into a long string of text (probably HTML).
  12. The plugin combines that data with some meta data (in the form of HTTP headers), and sends the HTTP response back to the browser.
  13. The browser receives the response, and parses the HTML (which with 95% probability is broken) in the response
  14. A DOM tree is built out of the broken HTML
  15. New requests are made to the server for each new resource that is found in the HTML source (typically images, style sheets, and JavaScript files). Go back to step 3 and repeat for each resource.
  16. Stylesheets are parsed, and the rendering information in each gets attached to the matching node in the DOM tree
  17. Javascript is parsed and executed, and DOM nodes are moved and style information is updated accordingly
  18. The browser renders the page on the screen according to the DOM tree and the style information for each node
  19. You see the page on the screen
  20. You get annoyed the whole process was too slow.

Source Rendering a web page – step by step

DavidPostill

Posted 2016-03-20T20:32:03.687

Reputation: 118 938

64

Each connection to a website uses a different socket with default destination TCP port 80 for plain HTTP and 443 for HTTPS. For the socket to be unique, the combination of the source IP address, source TCP port, destination IP address and destination TCP port must be different.

If you have multiple connections to the same website (assuming the website uses only 1 IP address) from the same computer, a different source TCP port must be used. This way, each connection is unique.

However, it should be noted that as of HTTP 1.1, all connections are persistent for a given period of time (unless declared otherwise). This means that the same connection can be reused by your browser if multiple resources from the same website are requested (e.g. css/js files). This also applies if you have multiple instances of the same website in your browser.

If you are on Windows, the netstat -no -p TCP command will show you all active TCP sockets and their corresponding process ID, including those of your browser:

enter image description here

If you are on Unix/Linux (Debian in this case), you can use the netstat -ntp or ss -t command:

enter image description here

Egon Olieux

Posted 2016-03-20T20:32:03.687

Reputation: 673

4Note that netstat will also show non-browser connections, for example email connections for an email client, news connections for a news reader. These connections will be on different remote ports. – DavidPostill – 2016-03-20T20:55:02.503

Unless I'm missing something, it seems like you are making the assumption that the asker is using Windows, although he hasn't mentioned an operating system. It's also good to list what OS you are referring to whenever providing console commands. – user45623 – 2016-03-21T06:50:57.757

9@user45623: Although the screenshot is a Windows screenshot, netstat -n should work in most operating systems, including Linux and Mac OS. – Heinzi – 2016-03-21T07:29:54.037

1

On Windows (maybe other OSs too) you can use netstat -n -o to see which process created which connection. Or you can run SysInternal's tcpview to see the list in a GUI, with process names and icons and all.

– Jonathan – 2016-03-21T08:55:09.053

Now the question is, do web browsers reuse connections from different tabs if they lead to the same server? – John Dvorak – 2016-03-21T16:48:45.337

@user45623 Added example for both Windows and Unix/Linux – Egon Olieux – 2016-03-21T17:06:54.540

@Jan Dvorak Included persistent connections for more clarification – Egon Olieux – 2016-03-21T17:15:03.450

@EgonOlieux Does "Each connection to a website uses a different socket.." mean that if browser invoking five API request uses five different ports at the clilent machine for single webpage..? – Abhi – 2019-04-29T12:22:55.190

@Abhi Originally that was the default using HTTP 1.0, yes. But since HTTP 1.1 the connection is kept alive by default for multiple requests to the same origin for a period of time. – Egon Olieux – 2019-04-29T13:09:17.320

11

As regards tabs to different websites, there is nothing in TCP that requires the local port to be different, as long as the tuple {local IP, local port, target IP, target port} is unique. For tabs to the same website, the situation is much more complex.

The browser, like any other piece of client software, uses a different local port per outgoing connection to the same target. In general it will form multiple connections to any given website, to fetch embedded resources such as images, CSS, JavaScript, etc. It will also pool those connections for possible reuse.

It isn't possible to say whether different tabs to the same website, will use distinct connections, because (a) there usually isn't a single connection per tab anyway, and (b) depending on the timing and authentication, connections may be reused between tabs; and as it isn't possible to identity the connections it therefore isn't possible to identify the local ports either.

user207421

Posted 2016-03-20T20:32:03.687

Reputation: 214

Thanks. What does "pooling" a connection mean? – yoyo_fun – 2016-03-20T21:56:47.863

Instead of closing it, return it to a pool, and only closing it if it stays there idle for some timeout interval; and looking in the pool first before creating a new connection to that target. This is how HTTP keep-alive is implemented. – user207421 – 2016-03-20T22:00:04.090

So a pool is a data structure in the memory that stores opened and not yet closed connections? – yoyo_fun – 2016-03-20T22:04:59.247

That's correct, typically a map keyed by target IP:port. – user207421 – 2016-03-20T22:06:04.887

2@EJP: Note that for HTTPS, it is not secure to key the map by target IP and port; you also need to distinguish between connections to different hostnames even though they happen to resolve to the same IP and port. Arguably a browser also should keep connections for different tabs separate if at least one tab is in incognito mode. – hmakholm left over Monica – 2016-03-20T22:24:51.387

@HenningMakholm Thank you, I mis-spoke, I'll amend that to 'typically a map keyed by target hostname:port'. A browser should use distinct connections whenever the associated authentication is distinct. – user207421 – 2016-03-20T22:52:34.200

@Henning Makholm I do not understand exactly why does this happen? Do you mean the case where two users login to the same website from a single browser? – yoyo_fun – 2016-03-21T09:30:37.347

@yoyo_fun: No, I mean cases where the user deliberately opens an incognito window and, in that, logs into a website with a different account that the one he's logged into in his main tabs. Then the browser shouldn't mix requests from the two accounts on a single connection, thereby furnishing the website with direct proof that the two accounts are the same person. Of course, the website can still see that the two logins come from the same IP, which is circumstantial evidence that they're the same -- but still that could be caused by shared NATs or proxies. – hmakholm left over Monica – 2016-03-21T11:02:20.180

@Henning Makholm , Thanks. So if the website receives another login request from incognito and the browser would not change the port then I guess the website would log out the user from the other tabs and would reset the session variables so that the user will be logged in with the same name in every tab even in the incognito tabs which is not what the user wants. – yoyo_fun – 2016-03-21T11:18:34.070

@yoyo_fun: Not necessarily -- properly written webservers should not attach meaning to which connection a request arrives on. I'm only talking about the privacy implications of revealing to the websitethat two simultaneous sessions happen in the same browser (rather than two different computers that share a NAT or proxy). – hmakholm left over Monica – 2016-03-21T11:26:30.347

@Henning Makholm, but then how does a server knows which user is logged in if a request comes from a computer, except if the connection comes from different ports? The HTTP is stateless. The server receives a request and must respond to it. The information it has is the TCP connection IP and port. What other way there is to see how the server should respond to that request (what user is logged). – yoyo_fun – 2016-03-21T11:53:22.090

@yoyo_fun: Typically the server sets a cookie in the browser, which the browser includes in every request it sends to the server. – hmakholm left over Monica – 2016-03-21T11:58:27.753

Let us continue this discussion in chat.

– yoyo_fun – 2016-03-21T12:01:36.630

@Henning Makholm So cookies can be specific to tabs? Because otherwise from every tab the user would be logged from the same account, except incognito tab, where theoretically cookies should be separate or not sent at all. – yoyo_fun – 2016-03-21T12:18:34.587

@yoyo_fun: No, usually all non-incognito tabs share the same cookie store. (And in Firefox at least it seems that all incognito tabs share a single temporary cookie store too). That is consistent with the usual experience that a login in one tab will work if you navigate to the website in a fresh tab, too. – hmakholm left over Monica – 2016-03-21T12:20:13.347

@yoyo_fun You both seem to have missed my remark above about authentication. If the authentication is the same, the same socket can be used, otherwise it can't. It isn't confined to anonymous/non-anonymous connections. – user207421 – 2016-03-21T23:48:27.477

6

Yes. No. Maybe. It depends.

First, a browser may use any of these strategies for connections:

  1. Single connection (unlikely for any browser more recent than 1995)
  2. One connection per tab (basically same as #1, just very slightly better)
  3. One connection per resource (naive, but doesn't work so bad)
  4. Pool of connections with keep-alive, re-using connections
  5. Something different (read as: weird stuff)

You don't have a way of knowing which strategy a browser will use, although using a pool of connections (and re-using connections) is a reasonable assumption.

Second, the way TCP works, you have a source port, and a destination port for every connection. The pair of source and destination address/port defines the connection.
You always[1] use a well-known port (such as 80 or 443) to connect to the server (to which it listens on its advertized address), but the other port is randomly chosen. Thus, depending on from which side you look at a connection, it either has one or many possible ports.

Thus, the same tab may (and usually will) use several different ports on its end, but in principle different tabs might (if connections are pooled and different resources in different tabs are loaded from the same server) use the same port.

Since the question explicitly mentions outgoing, in the "normal" case, the port numbers would be the same regardless which tab they're in, or one of two possible ports (80 and 443). Although of course it is possible to explicitly ask for a different port (like 8080) in an URL. That's kind of rare, though.


[1] Well, not always... but let's not complicate it too much.

Damon

Posted 2016-03-20T20:32:03.687

Reputation: 4 002

One other factor... the client-side port is typically chosen by the OS, not the browser; and the client-side port that the server sees might be different than what the browser sees, if the connection goes through a NAT device. Most OSes allocate either linearly or randomly within a (configurable) ephemeral port range, but a browser could request the same source-port across multiple connections to different servers. (And the OP is asking about client ports, not server ports.) – david – 2016-03-22T17:24:00.087

@david: It's hard to tell which one is right (or what to answer) since the Q is a tidbit ambiguous, hence my somewhat lengthy cover-all excursion. The OP is asking about the outgoing port on the client. "Client" suggests that we're talking about the source port (in TCP terms) which is the one that is freely or randomly chosen (by the implementation), but "outgoing" suggests it's really the destination port we are talking about. Which is much better described as "port on server" in layman words. Your comment on NAT is correct as seen from the server, but doesn't affect the client. – Damon – 2016-03-23T11:19:15.490