This post is for anyone who has ever been a bit confused about IP ports. Whilst most people I deal with have no problem understanding what they are and what they do, there have been a few cases recently where it would have been useful for me to refer to a post like this for background.
If you want to read about layered networks or IP in detail there are loads of resources - like here for example. I'm just going to deal with some of the practical aspects folk who work in IT support have to deal with.
TCP/IP is what is referred to as connection-orientated. That basically means it's for connecting computers together...
...except that this is not quite true. It's really for connecting applications running on computers together. And computers have more than one application running, which is one of the reasons that we have Ports.
Starting at the Beginning
You will have seen IP addresses - 126.96.36.199 for example. You also probably know that machines have names, and that names 'resolve' into IP addresses. For example 'ping zephod' might resolve into 'ping 188.8.131.52' (there is usually a server sitting somewhere on your network that takes names and returns IP addresses by doing a simple look-up from a list).
You are probably also familiar with either using an IP address to 'connect' two applications together. You might do this for example when you set-up your email client software to read your emails at home - one of the things you specify is the Name or IP address of the email server. Get that right, and the chances are you can access your email.
This IP address allows your email client software to 'talk' using TCP to your email server, allowing the two to exchange useful information because the email server is 'listening' for requests from email clients, and returning useful data back.
Ports Connect Applications
But consider this problem. That email server whose IP address you entered doesn't just run an email server. It almost certainly runs a web server as well which is also listening for requests from clients (browsers), it probably also has a database running called MySQL that also is listening for requests, and so on. In fact, if you count all of the different applications listening it may well count over 20, with the possibility of having even more.
So this begs the question: when your email client program wants to send a request to the email server application running at the IP address you specified, how does it avoid sending the data to the web server instead?
The answer is Ports
Imagine a large high-rise building with 120 flats (apartments). The address of the apartment building is 100 High St, Livingston. If you want to send a letter to a Mr Joe Bloggs who lives there, you'll need more than 'Mr Joe Bloggs, 100 High St, Livingston' because the postman won't know which of the 120 mailboxes to put the letter into. The correct address is 'Mr Joe Bloggs, Flat 25, 100 High St, Livingston'. In this example, the 100 High St part of the address is equivalent to the IP address, and 'Flat 25' is the Port number: the final piece of the jigsaw. If you don't specify a flat, or specify the wrong flat number, the chances are your letter will not be delivered.
Why don't I need to specify, or know, the Port number when I enter the IP address into my email client software?
The answer is because of convention. By convention, certain types of programs always use the same Port. So email programs typically know what Port to use. Some common standards are below:
What about Ports used for Sending Data?
Ports are also used for sending data, but unlike applications that listen for data (like server applications of all kinds) the send Port is usually not significant. The reason is simple: when you send your request to the server application, you will send both your IP address and the Port you send the data from, meaning it's easy for the server to send a reply using this information.
(Thanks to DuncanD for his help with this)