I think my question is fairly clear. I was reading this article to understand how sockets work, and it mentions the terms socket and buffer interchangeably :

Assuming the packet is in sequence, the data payload is then copied into the socket’s receive buffer. At this point the kernel will wake up any processes doing a blocking read(2), or that are using an I/O multiplexing system call like select(2) or epoll_wait(2) to wait on the socket.

Do the terms mean the same thing? If there is a difference, what is it that distinguishes a socket and a buffer?

  • 2
    The socket has a buffer. It also has lots of other things.
    – DavidPostill
    Apr 8, 2020 at 17:09
  • So when TCP sends an ACK to the sender, is the ACK sent once the packet is delivered to the buffer or when the packet is delivered to the application?
    – akellas
    Apr 8, 2020 at 17:18
  • Please go find an implementation and read the source code.
    – DavidPostill
    Apr 8, 2020 at 17:19

1 Answer 1


A socket is a broader concept than a buffer. A socket has two buffers and some other information associated with it.

In the context of sockets programming, a socket is your app's interface to one TCP connection (or UDP flow). Your app doesn't read/write data from/to the network interface card (NIC) directly, it goes through the kernel's network stack. Socket buffers are the short queues of packets the kernel holds on behalf of your app, as it's shuffling data between the NIC and your app's memory space.

A send buffer or write buffer is the queue of packets your app has handed off to the network stack to send, and a receive buffer or read buffer is the queue of packets the kernel's network stack has received on your app's behalf, that it's waiting for your app to read (that is, it's stored in kernel space, waiting for your app/process to ask for it to be copied into your app's memory).

On the sender side, for best performance, your app must call write() often enough, with enough data, to make sure the kernel's send buffer never runs out of data to send. We call this "keeping the pipe full". But to minimize latency, your app shouldn't load up the kernel's send buffer with too much data.

On the receiver side, for best performance, your app must call read() often enough to try to keep the kernel's receive buffer empty. Otherwise, if the receive buffer doesn't have enough free space, the network stack will signal to the sender that its receive buffer is filling up, causing the sender to slow down the rate at which it's sending data.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .