What is the difference between a port and a socket?

Question

This was a question raised by one of the software engineers in my organisation. I\'m interested in the broadest definition.

Answer 1

Firsty, I think we should start with a little understanding of what constitutes getting a packet from A to B.

A common definition for a network is the use of the OSI Model which separates a network out into a number of layers according to purpose. There are a few important ones, which we'll cover here:

• The data link layer. This layer is responsible for getting packets of data from one network device to another and is just above the layer that actually does the transmitting. It talks about MAC addresses and knows how to find hosts based on their MAC (hardware) address, but nothing more.
• The network layer is the layer that allows you to transport data across machines and over physical boundaries, such as physical devices. The network layer must essentially support an additional address based mechanism which relates somehow to the physical address; enter the Internet Protocol (IPv4). An IP address can get your packet from A to B over the internet, but knows nothing about how to traverse individual hops. This is handled by the layer above in accordance with routing information.
• The transport layer. This layer is responsible for defining the way information gets from A to B and any restrictions, checks or errors on that behaviour. For example, TCP adds additional information to a packet such that it is possible to deduce if packets have been lost.

TCP contains, amongst other things, the concept of ports. These are effectively different data endpoints on the same IP address to which an Internet Socket (AF_INET) can bind.

As it happens, so too does UDP, and other transport layer protocols. They don't technically need to feature ports, but these ports do provide a way for multiple applications in the layers above to use the same computer to receive (and indeed make) outgoing connections.

Which brings us to the anatomy of a TCP or UDP connection. Each features a source port and address, and a target port and address. This is so that in any given session, the target application can respond, as well as receive, from the source.

So ports are essentially a specification-mandated way of allowing multiple concurrent connections sharing the same address.

Now, we need to take a look at how you communicate from an application point of view to the outside world. To do this, you need to kindly ask your operating system and since most OSes support the Berkeley Sockets way of doing things, we see we can create sockets involving ports from an application like this:

int fd = socket(AF_INET, SOCK_STREAM, 0); // tcp socket
int fd = socket(AF_INET, SOCK_DGRAM, 0); // udp socket
// later we bind...

Great! So in the sockaddr structures, we'll specify our port and bam! Job done! Well, almost, except:

int fd = socket(AF_UNIX, SOCK_STREAM, 0);

is also possible. Urgh, that's thrown a spanner in the works!

Ok, well actually it hasn't. All we need to do is come up with some appropriate definitions:

• An internet socket is the combination of an IP address, a protocol and its associated port number on which a service may provide data. So tcp port 80, stackoverflow.com is an internet socket.
• An unix socket is an IPC endpoint represented in the file system, e.g. /var/run/database.sock.
• A socket API is a method of requesting an application be able to read and write data to a socket.

Voila! That tidies things up. So in our scheme then,

• A port is a numeric identifier which, as part of a transport layer protocol, identifies the service number which should respond to the given request.

So really a port is a subset of the requirements for forming an internet socket. Unfortunately, it just so happens that the meaning of the word socket has been applied to several different ideas. So I heartily advise you name your next project socket, just to add to the confusion ;)