zero-copy I/O (sendfile, splice)

Suppose you want to move a parcel from one truck to another. The wasteful way is to carry it into the warehouse office, set it on a desk, then carry it back out to the second truck - two extra trips for no reason. The direct way hands it truck-to-truck. Ordinary I/O is the wasteful way: serving a file over a socket normally copies the bytes from the kernel into your program's buffer and then copies them right back into the kernel to send. Zero-copy I/O is the direct way - move the data inside the kernel without ever dragging it through user space.

Walk through the normal path for a static file server: read() copies disk-cache bytes from kernel to your buffer (copy 1), then write()/send() copies them from your buffer back to the socket's kernel buffer (copy 2), plus two mode switches each way. The kernel offers shortcuts. sendfile(out_fd, in_fd, ...) tells the kernel to move bytes from a file descriptor straight to a socket descriptor with no user-space buffer at all. splice() moves data between a file or socket and a pipe inside the kernel, letting you build copy-free pipelines. A memory-mapped file (mmap) lets you treat file contents as memory and hand pointers to it rather than copying. And MSG_ZEROCOPY on send() lets the kernel transmit directly from your user buffer's pages, notifying you when it is safe to reuse them. Each removes one or both copies and some mode switches.

Why it matters: for bulk transfer - file servers, video streaming, proxies - the redundant copies dominate CPU and memory-bandwidth cost, so zero-copy can multiply throughput. The honest caveats: 'zero-copy' is often really 'fewer-copy,' it shines mainly for large transfers (tiny payloads see little gain and added complexity), MSG_ZEROCOPY is asynchronous so your buffer must stay untouched until the kernel says it is done, and these interfaces are largely Linux-specific with their own constraints on which descriptor types and offsets are allowed.