What are ports and protocols really?

Question

I hear people talk about ports and protocols (in relation to computer networking), and they often provide analogies for them (for example: "a port is much like a shipping port, it sends and receives data like a shipping port sends and receives goods from other ports") and things like that.

I understand what this all means, but only at a very artificial level. Basically, I know what a port and I understand what protocols are, but what are they really?

Are these ports physical objects? Are they something built into part of my computer? How many ports are there? Can I increase or decrease the number of ports? Are they even something physical? Or written in code? Where is this code? The operating system? What truly is a port?

What are protocols? I'd imagine they're some sort of code.... Can you create your own protocol? How do you get a specific port to run a specific protocol? What language do you use to create a protocol? How do you define or invent a new protocol?

Answer 1

Futher to Hello71s answer, it might help to visualise a port by thinking about the structure of an address in a packet. A packet being a unit of data passed around a network. TCP is an example of a transport layer protocol that uses ports, and is commonly used over IP.

So IP has two addressing components - the source IP and the destination IP. TCP adds to this by using a source port and a destination port. It is the ports that enables the recieving machine to differentiate traffic destined for the same IP address - ie, if you have a server that recieves both web requests and email on a single IP address, then you need to determine which application should recieve the data - the email service or the web service. So they may look like this if a single user was to carry out a web request and an email request to the same server:

Source IP    Source Port       Dest IP       Dest Port       Service
10.1.1.10    23434             192.168.1.1   80              web
10.1.1.10    34343             192.168.1.1   25              incoming email

The web service owns port 80 and the email service owns port 25 - they "listen" on their respective ports, which enables the traffic to end up in the right place.

The source port is "ephemeral" - in that is it made up at the time the packet is sent. However, it still serves a useful purpose. It enables both ends of the connection to keep track of separate conversations. Consider if our user sent two simultanous web requests:

Source IP    Source Port       Dest IP       Dest Port       Service
10.1.1.10    23232             192.168.1.1   80              web request 1
10.1.1.10    23234             192.168.1.1   80              web request 2

This lets the web service know that these are separate requests, but also, the return traffic from the webserver - the web pages - are sent back to the respective source ports, which enables the browser to know which request the server is responding to.

Note that this all refers to port numbers, from a TCP/IP perspective, the actual data being moved across these ports could be anything. It doesn't care or have any awareness of applications, so if you had web traffic on port 25 and email on port 80, it would be none-the-wiser.

It is up to the sending and receiving application to ensure the data is the right structure, and this is where application protocols come in. HTTP is an example of an application protocol that web browsers use to communicate with web servers. It is a well defined protocol that ensure that the browser will send requests to any web server and that webserver will understand and respond sensibly. But what it doesn't include in its definition is anything about how packets get from A to B - that is the responsibility of the preceding layers - the transport, internet and link layers.

Answer 2

Hm. I would think that the best place to start would be to look at the IP Suite, aka the TCP/IP model. (Ignoring the other layers of the OSI model for purposes of simplicity.)

Basically, it's a series of layers:

Application Layer - HTTP, FTP, POP, SSH, etc.
Transport Layer - TCP, UDP, etc.
Internet Layer - IP, ICMP, etc.
Link Layer - Ethernet, etc.

Ports are, for the most part, implemented at the transport layer (layer 4 - Yes, the numbering is correct.)

The majority of TCP and/or UDP stacks implemented in OSes use a basic system of assigning ports to programs and simply raising events in these programs as packets come in over the network. However, any implementation could theoretically work; there may even by hypothetical alternative stacks pondered in academia.

TCP has been defined as having a total of 65535 ports, which any program can use to do whatever they want with (although many OSes limit the use of ports under 1024, giving them an ad hoc special status). Although there are some limited lists, there is no real standard for defining who gets what port and what port runs what program. A port is, thus, more or less a random number that different implementations of a program decide to agree to communicate on. Of course, the designers of such programs try to avoid ports that other popular programs have chosen already.

Granted that it's in no way required to run using TCP. Some protocols run on the bare internet layer, or even the bare link layer, mainly for purposes of efficiency, or because these protocols were invented before even TCP or IP existed. Of course, when doing so, you trade away the simplicity and the extensive bug-checking of OS networking libraries.

For more details, check the Wikipedia pages on the OSI model, TCP, and IP.