The socket interface is the application-visible API for communicating through the operating system’s network stack. An application uses it to hand messages to the kernel or retrieve messages the kernel has received. The kernel handles lower-level protocol processing and uses a device driver to interact with the network interface card (NIC). section 3.3.1 section 7.5.3
Sending an HTTP request
An application creates a socket. For a stateful protocol such as TCP, it calls connect() to establish a connection, prepares the HTTP request, and calls sendmsg() to hand it to the OS. The OS may queue the message and transmit it asynchronously. Returning from sendmsg() therefore does not mean the network stack has finished its work. section 7.5.3
On the receive path, recvmsg() or a similar call checks kernel data structures for arrived messages. Packets can arrive at any time, so kernel background processing also handles reception and protocol work. NIC interrupts and work that continues after a send call can add latency or interfere with an application thread. For latency-sensitive systems, examine the whole packet path rather than timing only the socket call. section 3.3.1 section 7.5.3
Figure 3.3 Packets traversing the network stack
Follow packets through the network stack to locate the socket API relative to the NIC, device driver, and protocol processing. section 3.3.1
The usual socket path places TCP/IP processing in the kernel. Latency-sensitive designs may instead use a NIC TCP offload engine or a userspace kernel-bypass approach to reduce software overhead. Those alternatives change where protocol work happens; they do not make the cost of that work irrelevant. section 3.3.2
