Simple remote support software, remote access and presentations.
Follow SimpleHelpLtd on Twitter SimpleHelp Ltd RSS Feed

Ports vs Protocols, 80 and 443

| 16 Comments

When people are running their own server (like SimpleHelp) they inevitably need to understand ports in some sense.  At a minimum they need to understand that:

  • ‘Ports’ exist
  • They are a number
  • Servers run on them

Most of the time thats really all that is necessary.  You launch the server, it turns up on a port and you use that port when you are connecting to it.  If you’re using Amazon EC2 then things are even simpler – you just fire it up and it is ready to go like a website.

There are however some caveats, with complications arising around ports 80 and 443, and around HTTP and HTTPS.  Some common points of confusion are:

  • If its running on port 80 and its serving web pages, I can run it forwarded from another web server, right?
  • If its running on port 443, why can’t I access it over HTTPS?
  • If its going to do SSL/HTTPS then surely I need to run it on port 443?
  • Its running HTTP, but where do I set the HTTPS port?

All of these are perfectly valid assumptions and stem (I think anyway) from the fact that HTTP and HTTPS are well known protocols that run on well known ports: HTTP is synonymous with 80 and HTTPS is equally synonymous with 443.  It’s not very often that you come into contact with any web page that isn’t running on port 80 or any HTTPS website that isn’t running on port 443.

There is even a very good reason why you don’t come into contact with many websites running on non-standard ports too – because if you did your browser wouldn’t know where to find it.

If you already know all about TCP, HTTP, UDP, ports and protocols then you can skip to the end section to find out why this matters to SimpleHelp and what we’re trying to do about it (‘How we make it simpler, and more confusing’) but if you don’t then I’ve tried to pick out the crucial bits, condense it and go through it here to fill in the blanks.

IPs and Ports

If you’re not already clear on it all then this is likely all getting a bit confusing, so I’ll backtrack a bit.

Ports exist.  HTTP exists. HTTP runs on port 80.  Simple… but not entirely true.

Ports exist and are part of TCP and UDP.  TCP and UDP are layered on top of IP (Internet Protocol) – a medium for sending messages between computers.  That means that when your computer needs to speak to another computer it can (amongst other methods) either open a TCP connection or start sending UDP packets.  In both of these cases it needs two things:

  1. an IP address, and
  2. a port.

The IP address tells TCP and  UDP where to send the packets.  All the intermediaries in the network layer, like routers, need that IP address to know where to send your data.  A good analogy here is a phone number.  Knowing the IP address is like knowing somebody elses phone number – you can dial it and start talking.

But if computers had only one phone line they would only be able to talk to one computer at a time.  That wouldn’t be much use and here is where ports come to the rescue.  Along with your IP address you also always need to specify a port.

This is like dialling the phone number for a company but also having to dial an extension.  You don’t just get to speak to one person now, you can speak to hundreds or thousands, even though they are all at the same place. Applications running on a computer can listen for connections or messages coming in on any port from 1 to 65535 or they can make outgoing connections or send data to other computers on any port from 1 to 65535.

As you’re probably aware, to make life simpler for humans, there is a service called DNS where, if you know the DNS server’s IP address (like its phone number), you can ask for a particular website by name (e.g. www.simple-help.com) and it will give you the IP address so you can talk direct to it.  Now we can enter in the website name into the browser instead of an IP address. DNS though doesn’t tell you the port, and this is where protocols and default ports come in.

Protocols

When computers communicate, they send each other data – blocks of ones and zeroes that both sides know how to turn into something else – numbers, text, pictures, etc. They know how to do this because they are based on agreed upon standards. ASCII text for example explains how bytes map to letters.

Computers are capable of transmitting text and numbers, but need a way to know how they should communicate so that they don’t get into a mess.  This is where protocols and HTTP comes in.  HTTP is in reality pretty simple, James Marshall’s page HTTP Made Really Easy is a great in depth explanation but essentially it goes like this:

Your browser says (“Get me the root page or folder for www.simple-help.com, I am using HTTP version 1.1), like this:

GET / HTTP/1.1
Host: www.simple-help.com

The web browser reads that and responds with (“OK (code 200 means OK), its a web page, its 1020 bytes long, here it is”):

HTTP/1.1 200 OK
Content-type: text/html
Content-length: 1020
<html>...(1020 bytes of HTML)

Now your browser can speak to the web server and communicate with it, asking for pages, showing them to you, asking for other pages when you click on links and hey presto – the web is here.

But there is one last thing missing.  We know the IP address of the computer because DNS told us where to find it, we know how to talk to the web server to get pages and images, but we don’t know its extension – we don’t know what port it is going to be on on the remote computer.  Except we do, because the HTTP specification specifies a default port: port 80.

Magically disappearing ports – 80 and 443

This is really the last piece in the puzzle and if we think back to the original issue it becomes clear why you hardly ever see websites on non-standard ports.  DNS can’t tell you what port a web server is on, only the IP address, so  your browser always has to assume that the web browser is going to be there on port 80.  When  you have another protocol like HTTPS, it specifies its own default port (443) so that means when you use HTTPS to connect to a website your browser is again always going to have to just assume its going to be there on port 443.

This also explains why you can’t run more than one web server on port 80 and 443.  If a connection or packet comes in – who does it go to? the first web server? or the second?

If you’re running multiple web sites from one computer they have to all be served from one web server application (like Apache or IIS), because then all connections go to that one application, and it can look for the website domain being asked for (e.g. www.simple-help.com) in the HTTP request and it knows which website the request is for.

It also explains why you never see any port when you look in a browser address bar.  Instead you see:

http://www.simple-help.com/

No port? But thats just because  your browser doesn’t want to complicate life for you by sticking “:80″ on the end:

http://www.simple-help.com:80/

or in the case of HTTPS, “:443″

https://www.simple-help.com:443/

How we make it simpler, and more confusing

But port 80 is just a default port.  There is no reason why you can’t talk HTTP over port 81, or talk HTTP over port 443, or talk HTTPS over port 9999, it is just that if you did, most browsers wouldn’t know where to find it.  In fact, browsers and web servers are perfectly happy talking over other ports, they just need to be told what port it is to use.  If you had a web server on port 1234 that could somehow speak HTTP and HTTPS then your browser could easily cope with either of those:

http://www.simple-help.com:1234/
https://www.simple-help.com:1234/

When a connection came in it would just be up to the web server to figure out whether the browser was trying to start a conversation with HTTP or HTTPS.

In fact, if the web server could distinguish between the protocols, you could speak all kinds of different protocols over the one port.  You could do file transfers, HTTP, HTTPS, remote desktop, TCP and UDP at the same time, all over the one port.

Just like SimpleHelp…

Yes.  This is why it can get a bit confusing when about why you don’t need to open up port 443 for SimpleHelp to enable HTTPS and SSL and why even though you can point your browser at SimpleHelp and get a web page, it’s not a good idea to set up a reverse proxy. Or why you don’t even need to specify an ‘HTTPS port’ separately from the ‘HTTP’ port, because normally, if you run a web server on port 80 thats what you get and all you get – a web server.  Its speaking HTTP, maybe HTTPS and that is it, and it doesn’t try to distinguish between the protocols because it doesn’t have to, it knows HTTPS connections are coming in on 443 and HTTP on 80.  When you run SimpleHelp on port 80 though, its doing a lot lot more than just that over the one port.

It makes it easier for SimpleHelp users to get through firewalls and NAT and it means SimpleHelp can serve up web pages, serve up secure SSL web pages, do secure SSL connections, get through HTTP proxies in a number of different ways, do UDP connections do other kinds of  uncluttered, faster TCP connections all with the user just having to think about one port.

There is no concept of an HTTP port in SimpleHelp, or a HTTPS port – we do everything over all the ports.  If you want to use HTTPS, no problem. In fact its already there on whatever port you have already congiured.  You don’t need to specify a particular port for it and it doesn’t need to use port 443 but I think it unnerves some people when you tell them either they can add port 443 and do:

https://yourwebsite.com

or they can just leave it as it is and do:

https://yourwebsite.com:80

because the server will usually be linked to from your website or embedded in it anyway, so the link will tell the browser what port to use and the customer / technician doesn’t have to.

It also means that occasionally someone assumes that because SimpleHelp is a web server, it can be reverse-proxied to from some other web server instead of just running it on another port.  In reality though, when the connection comes in to Apache or IIS before it is forwarded on, the servers will understand HTTP, but all the other protocols we do over that port is going to be lost on them.  It will work because we can do everything over HTTP if necessary, but it is a restriction that slows things down quite a bit it.

These aren’t the common case. Most people get set up fine and never come into contact with any of this, but when we get a question like “where do I set the HTTPS port?” or “how can I set Apache/IIS up to forward connections to SH?” we know we are probably in for a few more emails.

Like everything we do though, we want to make it simpler and better, so in SimpleHelp 3.12 we’ll be adding UDP support which, amongst other things, will allow us to often get a better connection even where we are being forwarded through another web server, and we have also replaced the session graph with a connection info button that gives you the lowdown on how you got connected and what you can do to tweak it and make it better.

Session Info (Connection Tuning)

Session Info (Connection Tuning)

This blog post is more than long enough though, time for a cup of tea.

16 Comments

  1. Will 3.12 have the option to join simplehelp to a secondary IP and port?
    Right now in version 3.11 and previous versions, you are limited. Although you can specify a port, it applys to all IP addresses. So if I run simplehelp using port 80 or 443 and I have a webserver on my primary IP I end up with a conflict, because although simplehelp maybe working on my secondary address, it keeps trying to join to my primary making my webserver very unhappy.

    • Hi Darrell, this is actually possible in the current version of SimpleHelp. If you log in as the admin and go to the Administration tab then under Server, Server Configuration you can set the port etc. There is also a field ‘IPs to bind to’ where you can have SimpleHelp bind to one or more specific IPs. Once you apply it should rebind to the new configuration without you having to restart the server but you will likely lose your connection and have to re-login.

      • I forgot one important part of my description, although you are correct.
        I need to separate what port runs on what IP. Unfortunately my setup requires 2 ips with 2 DIFFERENT ports. This is where my problem is.

        If you choose a port to bind you can not choose what specific IP to bind it too if you have more then 1 IP.

        I put this in as a feature request awhile back and I know you all are working hard, was just wondering if this ended up in this version.

        For the sake of simplicity what you have now is awesome, but for those of us that have to have a more complicated setup, its a bit difficult.
        Even if I had to manually edit a config file to make it work I would be happy.

        Thanks again for all your hard work and a wonderful product. All of us at work here love it.

        • Yes, I see your email from a while back… I think you said you have a service already running on one IP/port combination so you had to use a different port on that IP but the same port (as the existing service) on another IP? This is actually super easy for us to do technically its just the work required to sort out the configuration UI and make sure that people’s existing settings port over OK that has held it back. I’ll have a look though and see if I can do it without much UI change, then maybe I can squeeze it into the 3.12 beta ready for release…

        • This is in the 3.12 beta now and will be out with the 3.12 release. You can choose to either bind to ports A,B,C on all available IPs or you can specify exact IP:Port combinations to bind to. All previous configurations will still work OK and will be ported to exact combinations where necessary.

          • Very cool. Thank You very much for taking the time to listen to your customers and implement changes like this.
            We really appreciate it. That is one thing we love about your company.

  2. Can you run both http and https on the same server using the same IIS installation? For some users we need them to connect to the website with HTTP and others need HTTPS.

    • Hi Janice,

      In the normal case HTTP will run on port 80 and HTTPS will run on port 443 so you can run them both at the same time, this is a pretty standard thing to do with a web server so IIS will support it, I wouldn’t know where to tell you to look for configuring it though.

      thanks

      Antony

  3. What do you believe would be the result of installing and con figuring a web server to “listen on ports other than 80 and 443?

    • Hi Tammie. The result would be exactly what you expect: the web server would no longer respond to incoming requests on port 80 or 443, but instead would only accept connections on its configured port. It would still serve the same content in the same manner, just on a different port.

  4. Hi, I am trying to setup so that https://somesite.com:883 URL is functional. My thinking is that I need to setup a site with TCP Port 883 and some SSL port but that SSL port has to be opened. My network administrator disagrees and says that I only need port 883 open. However, I think they need to open 2 ports – one for TCP port and the other one for SSL port. Is my thinking correct?

    • Hi Leena. It might depend on your server, but strictly speaking you only need a single port open. HTTPS is build on top of TCP here, so by listening on port 883 you are listening for TCP connections (which, in your case, are also SSL encrypted).

  5. If I want to use a different port number other than 443, say 1010, for SSL configurations in IBM HTTP Server, in my url the port number is also has to be given with the domain name. In this case what configurations do I need to do so that my url contains only the domain name and not the domain name with port number.

    Thanks.

    • The URL will have to contain the port number if the port that the server is listening on is not the default for the specified protocol. For example, http://domain will default to port 80 because this is the standard http port. https://domain will default to 443 for the same reason. If the server is listening on a non-standard port then the port will need to be included in the URL.

  6. Proof-reading comment:
    The following paragraph in the blog article should be deleted;
    “Now your browser can speak to the web server and communicate with it, asking for pages, showing them to you, asking for other pages when you click on links and hey presto – the web is here.”
    Reason; a duplicate of the paragraph exists, immediately following it (two exact
    same paragraphs).

Leave a Reply

Required fields are marked *.