Why isn't it sensible to dedicate more than one TCP/IP port to http? Although admittedly naive, isn't it intuitive to think that server performance could somehow be increased?
asked Jun 20, 2013 at 14:14
-
21You are absolutely correct. I changed my web servers default port from 80 to 90,91,92 & 93. The load on the server has dropped drastically.– David HoudeCommented Jun 22, 2013 at 10:57
-
17...perhaps because no clients can find the server any more?– Marcos GonzalezCommented Jun 22, 2013 at 14:49
-
580 is just the port used for http. When you say "something.com"; (or even "something.com") the browser completes it to be a request to "something.com:80"; (on port 80, as it's the default well-known http port). Same for https on 443. If you decide to change it, you'll have to say it in the URL: "myserver.com:1280"; otherwise the browser will try on port 80 and will not find it. A list can be seen on wikipedia– Olivier DulacCommented Jun 24, 2013 at 13:09
-
7Sorry Marcos, that was a poor attempt at humor. I've never been good at it.– David HoudeCommented Jun 25, 2013 at 23:38
-
3@DavidHoude, time for a refresher on emoticons for you. :-) cs.cmu.edu/~sef/sefSmiley.htm– generalnetworkerrorCommented Jun 30, 2013 at 8:17
|
Show 3 more comments
10 Answers
Port 80 is a well-known port, which means it is well-known as the location you'll normally find HTTP servers. You can find it documented in the HTTP/1.1 RFC.
Having a default is useful precisely because you don't have to type it into your web browser with the URI. If you run an HTTP server (or in fact any service) on a non-standard port, you force the client to remember which arbitrary 16-bit number you chose and type it in.
In addition to this unfriendliness, there is no performance benefit: a port is just one part of the (dst ip:port, src ip:port) 4-tuple which uniquely identifies a TCP connection. If two connections share a dst ip:port, that doesn't mean they share some system resource - they can reside in different threads, or different processes.
Now, if you have logically different services which both happen to use HTTP, there is no problem with running them on different ports. It just makes the URI a little uglier.
-
9That's it! Port 80 is not a resource! It's just part of a tuple! Thank you for putting it so clearly. Commented Jun 20, 2013 at 17:03
-
2It's also worth nothing that even for different services, the actual HTTP connection is usually received on port 80 by a system-wide driver which performs initial protocol analysis and then hands it off to the correct service, thus allowing totally different services in different processes to share the same port. Commented Jun 21, 2013 at 7:04
-
1
The server doesn't waste resources by handling connections in one or more ports. Server resources are allocated to handle connections, and the port number is just a way to connect a specific program to a specific connection.
For example: the HTTP server knows that he'll listen to connections that come in the port 80. And the server knows that anytime he receives some request on port 80, he'll handle it to the http server. After that, the http server will handle the communication and then will consume resources.
answered Jun 20, 2013 at 15:24
-
8I would add to this answer that port 80 isn't consumed by a user sending their request to it. This is why only using port 80 (or whatever well-known port for the incoming protocol you are looking at) isn't a bottleneck for scalability. Commented Jun 20, 2013 at 16:47
-
1That is exactly what I didn't quite understand. Even 100,000 users connecting simultaneously to www.example.com:80 won't consume port 80. Thank you for the clarification. I find @Useless' information below also very enlightening. Commented Jun 20, 2013 at 17:01
-
Some webservers software have Limits per instances and/or process. Sometime it can be a good idea to run multiple instances, but doing so on the same machine requires another listening port, the first (TCP80/443) being forwarding connections to the first instance. Commented Jun 20, 2013 at 17:21
You seem to think of ports as something real; its just a 16-bit unsigned number (0-65535) that's a label in the header of an IP packet. This helps with application-level multiplexing. When an incoming packet arrives at a network card, the OS gets a notification. It checks what port the incoming packet was directed to, and then forwards the packet to only the right application. If you are running your webserver (nginx) to listen on port 80, only nginx gets packets sent to port 80.
When a client (IP: 100.200.100.200) makes an HTTP request to server (55.55.55.55), they make that request to destination port 80 on the server (55.55.55.55:80), but the source port is randomly chosen by the OS for the web browser (something like 45490). The HTTP response from the web server then comes from (55.55.55.55:80), but sent to the destination (your IP) (100.200.100.200:45490). Your computer's OS knows that incoming packets on port 45490 (from 55.55.55.55:80) need to be given to the web browser that made the request. As each unique connection to a web site from the client gets a unique random port, so you can have multiple web browsers connecting to the same web site and when a page is reloaded in one browser the other windows aren't affected.
Each IP packet has both the source and destination IP addresses and port available to it in the header. The OS and application (web browser or web server) can use both to figure out the appropriate action on how to process the packet.
-
2
Port 80 & 443 are the "default" ports for HTTP/HTTPS
This means that you do not have to specify the port (http://www.example.com:80, https://www.example.com:443) when using a web browser.
If you want to have a webserver listening on any other ports, the users have to manually add the port to the URL, or it has to be encoded in any link to that particular port.
Also, most Proxies and Firewalls will not let connections to those ports unless specifically configured to do so (Without configuration, Outgoing proxies won't be listening to non-default ports, hence will not forward the request to the webservers, while Firewalls would simply block non-TCP80/443 connections attempts)
All of this limits what can be done at the TCP/IP level
One way of boosting performance would be by having a load balancing device/service listening to TCP80/443 which would then redirect the request to servers on different ports and/or ip (Local Balancing) or even different remote sites (Global Balancing). But this is another topic altogether
-
Thank you for introducing me to the concept of "load balancing". Commented Jun 20, 2013 at 17:42
-
1If you want to have some "pseudo" hands-on and ideas on some load balancing concepts, F5 has some free online training at university.f5.com Registration is free and it gives you access to LTM (Local Traffic Manager - their local balancer) training, where you can see what it looks like and learn some load balancing concepts (ex: Real IP, Virtual IP, Pools, health-check, etc...) Commented Jun 20, 2013 at 18:08
-
Adding extra ports does not add extra bandwidth or anything like that, a port is more of a label than a pipe, it can "grow" as wide as you need it to without getting any slower due to the pipe being full.
If a server receives too many requests, the server will of course slow down, however this is not the type of issue that can be fixed by adding another port number.
-
s/label then/label than/ - I would edit, but it seems only one character is not an acceptable edit. Commented Jun 22, 2013 at 21:50
If you used random ports, the user would have to add the correct port numbers each time they went to your site. i.e. www.example.com:80; www.example.com:81; www.example.com:82 etc
It would not increase performance to use more ports. The source ports for each connection an ephemeral ports and so different anyway
Each TCP/IP connection has a sourceIP:sourcePort and a destinationIP:destinationPort.
When you initiate a connection, you would always use 80 as the destination port (which makes sense since the Server needs to only listen on port 80 for HTTP and not on several ports). The trick is that the sourcePort is dynamic for each connection.
Example:
user1: 1.1.1.1:29999 to 2.2.2.2:80
user2: 1.1.1.2:45333 to 2.2.2.2:80
Don't mistake a different port for a different physical connection or a higher network bandwidth or server processing performance. What the server gets are TCP or UDP packets, which happen to have a port number as part of the address. They still come over the same wires, go through the same network interface hardware and driver, and so on.
If you were to send two packets to a server, in terms of resources the server expends to process these two packets it doesn't matter if one of the two have different port numbers or the same port numbers associated with them, the internal handling will be close to identical.
Therefore, this is not a method to increase performance in any way.
The only possible exception to this is if you were to associate two different demons (or two copies of the same) running at the same time to the two different port numbers, and if each of these demons would scale up extremely badly with load. Which is typically not the case.
As Remi mentioned, Port 80 & 443 are the "default" ports for HTTP/HTTPS.
Most networks and firewalls don't block traffic going through this ports. So using this ports is easier as most of the time you may not need to worry about firewalls blocking your service else you may have to go through reconfiguring firewall rules and getting approvals from compliance/security for same.
-
1Amen, websites using nonstandard ports are the bane of any security administrator's existence, one user on your nedwork needs to use one website with weird port = proxy change, FW change, security review etc. Commented Jun 22, 2013 at 12:45
As everyone else on here has said, it is basically pointless to host a web server on any port other than port 80... unless you're hosting it from home. Many ISPs throttle outbound TCP/UDP ports 80 and 443 (IANA defines as HTTP and HTTPS, respectively), and in this case, using those ports will detract from site loading speeds, etc. However, IANA has assigned 3 HTTP-ALT ports for both TCP and UDP. These are: 591, 8008 and 8080. Using these ports is also acceptable, but you will be making the life of server admins hell.
Source of port numbers: https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml
