Could someone please explain quite clearly the difference between a port and a socket. I know that a port serves as a door into the network for an application 
process and that the application process uses a socket connection to the given port number to handle network communication but when you have multiple processes listening on a single port number, I am finding it difficult to understand the difference between the socket and the port and how they all fit together.
S is a server program: let's say it's an HTTP server, so it'll use the well-known port number for HTTP, which is 80. I run it on a host with IP address 10.0.0.4, so it will listen for connections on 10.0.0.4:80 (because that's where everyone will expect to find it).

Inside S, I'm going to create a socket and bind it to that address: now, the OS knows that connections coming into 10.0.0.4:80 should be routed to my S process via that particular socket.


netstat output once socket is bound:

$ netstat --tcp -lan
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address               Foreign Address            State
tcp        0      0 0.0.0.0:80                  0.0.0.0:*                  LISTEN


NB. the local address is all zeroes because S doesn't care how its clients reach it


Once S has this socket bound, it will accept connections - each time a new client connects, accept returns a new socket, which is specific to that client


netstat output once a connection is accepted:

$ netstat --tcp -lan
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address               Foreign Address            State
tcp        0      0 0.0.0.0:80                  0.0.0.0:*                  LISTEN
tcp        0      0 10.0.0.4:80                 10.0.0.5:55715             ESTABLISHED



10.0.0.4:80 represents S's end of the connection, and is associated with the socket returned by accept
10.0.0.5:55715 is the client's end of the connection, and is associated with the socket the client passed to connect. The client's port isn't used for anything except routing packets on this TCP connection to the right process: it's assigned randomly by the client's kernel from the ephemeral port range.



Now, S can happily go on accepting more client connections ... each one will get its own socket, each socket will be associated with a unique TCP connection, and each connection will have a unique remote address. S will track client state (if there is any) by associating it with the socket.

So, roughly:


the IP address is for routing between hosts on the network
the port is for routing to the correct socket on the host


I nearly said correct process, but it's actually possible to have multiple (usually child) processes all accepting on the same socket ...
however, each time one of the concurrent accept calls returns, it does so in only one process, each incoming connection's socket is unique to one instance of the server

the socket is the object a process uses to talk to the OS about a particular connection, much like a file descriptor


as mentioned in comments, there are plenty of other uses for sockets that don't use ports at all: for example socketpair creates a pair of sockets connected together that have no addressing scheme at all - the only way to use that pipe is by being the process which called socketpair, being a child of that process and inheriting one, or being explicitly passed one of the sockets from that process


