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.

  • 9
    Port is a physical address, while socket is an object. – superM Oct 29 '12 at 12:26
  • 14
    If a packet hits a pocket on a socket on a port... – user16764 Oct 29 '12 at 23:58

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, so it will listen for connections on (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 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        *                  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        *                  LISTEN
    tcp        0      0                    ESTABLISHED
    • represents S's end of the connection, and is associated with the socket returned by accept
    • 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
  • 1
    @Useless It's worth mentioning sockets do not need to be IP based as the answer indicates. It's not exactly relevant to the OP but an explanation of the socket families would help round out this answer. – hafichuk Oct 30 '12 at 14:06
  • Good point - I was already getting concerned about scope creep when I started writing about multi-process servers. Feel free to edit it in, and if you don't, I'll get round to it at some point ... – Useless Oct 30 '12 at 14:10
  • 10
    this is not useless at all – l--''''''---------'''''''''''' Oct 30 '12 at 16:36
  • I try to understand socket in electronics, a server bind a socket to a port number is like put a socket on a wall waiting for some electronical devices to plugin for charging battery. But when accepted, a new socket is returned? Why? A new socket is put one the wall? Please help me make sense out of it by some analogy. – Aaron Shen Apr 15 '15 at 6:32
  • 3
    The problem here is that your analogy is wrong. Forget what a socket means in the physical world - it's not a metaphor for something else, just a technical term for a specific technical software concept. It isn't even strongly related to physical network ports or sockets - you just have to understand it, in this domain, as a concept on its own terms. – Useless Apr 15 '15 at 10:07

Think of your machine as an apartment building:

  • A port is an apartment number.

  • A socket is the door of an apartment.

  • An IP address is the street address of the building.

  • 3
    I like this analogy although now I'm thinking of being inside that apartment looking at an endless corridor with lots of doors. I cannot get out. I cannot get out! :) – Daniel Hollinrake Oct 30 '12 at 22:13
  • 1
    @Caleb A socket is the door of an apartment. But couldn't there be numerous sockets open at one port? – Suhail Gupta May 31 '16 at 12:57
  • 3
    @suhail Sometimes an apartment has more than one door. They all have the same apartment number, but they're different doors. – Caleb May 31 '16 at 13:21

A port is part of the address in the TCP and UDP protocols. It is used to help the OS identify which application should get the data that is received. An OS has to support ports to support TCP and UDP because ports are an intrinsic part of TCP and UDP.

A socket is part of the interface the OS presents to applications to allow them to send and receive network data. Most socket implementations support many protocols beyond TCP and UDP, some of which have no concept of ports. An OS does not have to support sockets to support TCP or UDP; it could provide a different interface for applications to use. A socket is simply one way of sending and receiving data on a specific port.

  • A socket is essentially a 4 tuple made up of: Source IP:Port-Dest IP:Port. – Tony The Lion Oct 30 '12 at 13:07
  • you mean that port exists only in TCP and UDP protocols??? What about http and other protocols? – H. Aqjn Oct 16 '16 at 6:46
  • HTTP is an application layer protocol that runs on top of transport layer protocols like TCP or UDP. It doesn't have its own concept of ports, it inherits them from the underlying transport layer protocol. – Dirk Holsopple Oct 18 '16 at 1:29

A computer has an IP address that identifies it as a separate entity on the network. We add an additional number to that to allow us to differentiate between connections to that computer. This is the port number. On the OS side of the connection you need buffers, connection state, etc. This logical object is the socket.


A socket is a communication path to a port. When you want your program to communicate over the network, you have given it a way of addressing the port and this is done by creating a socket and attaching it to the port. Basically, socket = IP + ports Sockets provide access to the port+ip


An IP address identifies the device ie the address to the particular device, when you reached the machine using IP now port defines to which process in that machine to communicate.

So for actual communication to take place you need both port+IP which is called socket.

protected by gnat Jun 28 '14 at 6:57

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.