Why ports can be confusing

When you run your own server, such as SimpleHelp, you need to know a little about ports. At a minimum, you need to know that:

ports exist
each port is a number
servers listen for connections on them.

Most of the time, that is all you need. You start the server, it listens on a port, and you use that port to connect to it.

Ports 80 and 443, and the HTTP and HTTPS protocols, are where the questions start. Common points of confusion include:

If a server runs on port 80 and serves web pages, can I put it behind another web server?
If a server runs on port 443, why can't I reach it over HTTPS?
If I want HTTPS, do I have to use port 443?
The server runs HTTP, so where do I set the HTTPS port?

These are reasonable assumptions. HTTP and HTTPS are well-known protocols with well-known default ports: 80 for HTTP and 443 for HTTPS. Most websites you visit use those defaults, so it is easy to treat each port and protocol as the same thing.

If you already know how IP addresses, ports and protocols fit together, skip to How SimpleHelp uses its ports.

IP addresses and ports

Ports are part of TCP and UDP, the transport protocols that run on top of IP (Internet Protocol). When one computer talks to another, it can open a TCP connection or send UDP packets. Either way, it needs two things:

an IP address, which identifies the computer
a port, which identifies the application on that computer.

Routers and other network devices use the IP address to deliver data to the right computer. A phone number is a useful comparison: knowing it lets you call the right building.

The port is like an extension number. A company has one main number, but each extension reaches a different person or department. In the same way, many applications on one computer can each listen on their own port. Ports are numbered from 1 to 65535.

People rarely type IP addresses. DNS turns a name such as www.example.com into an IP address, so you can enter the name in your browser. That gives the browser the computer to contact, but for an ordinary web address it still needs to know which port to use. This is where protocols and default ports come in.

Protocols

Computers exchange data as bytes. Both sides can only make sense of that data if they follow the same agreed rules. A protocol is that set of rules: it defines who speaks first, what each message looks like and what the reply should be.

HTTP, the protocol behind web pages, is simple at its core. Your browser asks the web server for a page:

GET / HTTP/1.1
Host: www.example.com

This means "get the home page of www.example.com, using HTTP version 1.1". The web server replies with a status, some headers describing the content, a blank line and then the content itself:

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1020

<html>... (1020 bytes of HTML)

Status code 200 means OK. The browser displays the page, requests any images or styles it needs, and asks for new pages when you click links.

HTTPS is HTTP sent inside an encrypted TLS connection. The browser and server first set up the secure connection, then exchange the same kind of HTTP messages through it.

Default ports: 80 and 443

The browser knows the IP address and how to speak HTTP, but it still needs a port. Each protocol solves this with a default: port 80 for HTTP and port 443 for HTTPS. If the address doesn't include a port, the browser uses the default for that protocol.

That is why you rarely see a port in the address bar. These two HTTP addresses are the same:

http://www.example.com/
http://www.example.com:80/

And so are these two HTTPS addresses:

https://www.example.com/
https://www.example.com:443/

A server can use a different port, but the address must then include it, for example https://www.example.com:8443/ . Without the port number, the browser would try the default and miss the server.

Only one application can normally listen on a given IP address and port at a time. When a connection arrives on port 443, it goes to that one application. This is why a computer hosting several websites usually runs a single web server application, such as Apache, IIS or nginx. It receives every request and uses the requested domain name to decide which site to serve.

Default ports are conventions

A port number doesn't decide which protocol is used. Defaults are agreements that let software find a service without being told the port. You can run HTTP on port 8080, or HTTPS on port 9443, as long as the address includes the port.

Whether a server accepts HTTP, HTTPS or both on a port depends on how that server is built and configured. A conventional web server on port 80 normally expects HTTP, and one on port 443 normally expects HTTPS, so it doesn't need to tell them apart.

A server that can recognise which protocol a new connection is using can accept several protocols on the same port. SimpleHelp works this way.

How SimpleHelp uses its ports

SimpleHelp is a complete server in its own right, not a site or add-on for another web server. It serves web pages to browsers and also runs the other connection types used by technicians and remote machines, over TCP and UDP, on the ports it is configured to use.

SimpleHelp accepts HTTP and HTTPS on the same configured TCP listening ports. There is no separate HTTPS listening-port setting, and HTTPS does not require port 443. A self-signed certificate is generated automatically, so HTTPS is available before you install a publicly trusted certificate. Browsers will normally display a certificate warning until a certificate trusted by the browser and valid for the server hostname is installed.

If you restrict the traffic a port accepts, that port may not allow every request or connection type.

For example, if your SimpleHelp server listens on port 8080 and has a trusted certificate for support.example.com , both of these reach it, and the HTTPS address opens without a certificate warning:

http://support.example.com:8080/
https://support.example.com:8080/

If you want HTTPS addresses without a port number, such as https://support.example.com/ , SimpleHelp needs to listen on port 443, because that is where browsers look by default.

On first installation, SimpleHelp tries to use ports 80 and 443 when available, and tries alternative ports if necessary. View and change the listening ports in the Technician Console under Administration → Network Settings. Ports 80 and 443 are often open on the proxies your customers connect through, so using them can make connections easier.

For a standard installation, allow inbound TCP and UDP on every configured listening port, including through any firewall or NAT router.

HTTP reverse proxies

We recommend running SimpleHelp directly on its configured listening ports. Its HTTP and HTTPS encapsulated connections, including FDHTTP, may work through an HTTP reverse proxy, but compatibility depends on the proxy's streaming behaviour, limits and timeouts. This does not carry SimpleHelp's native TCP and UDP transports, and we do not recommend reverse proxying as the standard setup.

Quick answers

Where do I set the HTTPS port in SimpleHelp?

There isn't a separate one. SimpleHelp accepts HTTP and HTTPS on the same configured listening ports, and HTTPS is available from the start using the self-signed certificate SimpleHelp generates. Installing a trusted certificate removes browser warnings; it isn't needed to turn HTTPS on.

Do I need port 443 for HTTPS?

No. HTTPS can run on any port, as long as the address includes it. You only need port 443 if you want HTTPS addresses without a port number.

My server runs on port 443. Why can't I reach it over HTTPS?

Selecting port 443 doesn't enable HTTPS in software that doesn't already offer it: the server itself must accept HTTPS on that port. SimpleHelp already offers HTTPS on its listening ports, but your browser may show a certificate warning. That is a separate question of trust. The self-signed certificate SimpleHelp generates isn't invalid, but browsers don't trust it, so the warning remains until you install a certificate that browsers trust and that is valid for your server's hostname, for example by uploading one or requesting one from Let's Encrypt.

Can I run SimpleHelp behind Apache or IIS?

Some HTTP reverse-proxy configurations may work using SimpleHelp's HTTP and HTTPS encapsulated connections, but require separate compatibility testing. We recommend running SimpleHelp directly on its own listening ports.

Run SimpleHelp on your own server

Choose your ports, add your certificate and connect to your own machines. Every feature, free for 30 days.

Try SimpleHelp free for 30 days

Protocols vs Ports

Antony Miguel