Winsock, AFD, and kernel boundaries

The TCP/IP stack does its work in kernel mode. Application code calling socket APIs runs in user mode. This chapter is about the bridge between them — and about a detail that matters a great deal for anyone building genuinely high-throughput networked software.

Winsock: the application-facing API

Winsock is the API surface applications actually call — socket, connect, send, recv, and the rest of the familiar sockets programming interface. Like nearly every other user-mode API this course covers, Winsock doesn't itself implement networking logic; it's a well-documented, stable contract that routes down into the actual kernel-mode transport implementation, following the same general user-to-kernel transition pattern described in Ntdll & the user/kernel boundary.

AFD.sys: the driver in the middle

The specific kernel-mode component most Winsock traffic routes through is AFD.sys — the Ancillary Function Driver for Winsock. It's the piece of plumbing that actually exposes socket-style semantics (connection state, buffering, blocking/non-blocking behavior) to user mode, sitting between Winsock's user-mode API surface and the transport protocol implementation (the TCP/IP stack) underneath. A very large share of ordinary application networking activity passes through AFD.sys, even though almost no application developer interacts with it directly or even knows its name.

WSK: an alternative for kernel-mode components

Not every network-aware component on a Windows machine runs in user mode. Kernel-mode drivers and system components that need networking — certain security and filtering products, for instance — have their own interface: WSK (Winsock Kernel), letting them perform socket-style I/O directly, without needing to cross the user/kernel boundary at all. This matters because a full user-mode-to-kernel-mode round trip carries real, measurable overhead (the same mode-transition cost discussed in Ntdll & the user/kernel boundary); WSK exists specifically to let kernel-mode components avoid paying that cost for networking they need to do entirely within kernel mode anyway.

Why this matters for high-throughput software

Software built for genuinely high connection counts or high throughput — a scalable server handling many thousands of simultaneous connections — has to think carefully about exactly where buffering happens and where boundaries introduce overhead along this path: how much data copying happens crossing from user mode into AFD.sys, how efficiently the stack batches or coalesces work across many connections, and whether a given design pattern (one thread per connection, versus asynchronous I/O completion models) matches how the underlying kernel machinery is actually built to scale. This isn't abstract internals trivia for this kind of software — it's the direct explanation for why certain I/O patterns scale dramatically better than others that look, at the application-code level, almost equivalent.

A common mistake

Treating "the TCP/IP stack" as a single undifferentiated box that Winsock calls into directly skips over a real, meaningful layer: Winsock (user mode, application-facing API) and AFD.sys (kernel mode, socket-semantics plumbing) are genuinely separate components with a real boundary crossing between them, and that boundary is exactly where a lot of real-world performance work in high-scale networked software actually happens. Understanding it as one box makes several classes of throughput and latency behavior look mysterious that are, in fact, directly explained by exactly where the user/kernel boundary sits.

Where this connects

• The TCP/IP stack is what AFD.sys ultimately hands work to, once a socket operation crosses into kernel mode.
• Ntdll & the user/kernel boundary covers the general mode-transition mechanism this chapter's user/kernel boundary is a specific instance of.