HTTP in the kernel

May 11, 2010 10:45

Here's an interesting thought in passing: HTTP stacks in our kernels, for clients and for servers, with appropriate syscalls. If TCP is in there, why not HTTP? It's fast becoming a "baseline" protocol underneath applications.

First question: where do you draw the line? What atomic unit of work would you like the kernel to do? A full HTTP parsing, every time, of every header? Construction of response headers from a data structure like you might hand to sendmsg()? Depending on the context, you often don't want or need everything, and parsing is slow. E.g., if there is a Location header present, clients generally only care that the code is not 4xx or 5xx, but not what it actually is. HTTP messages and their deconstruction (parsing) don't much resemble TCP or UDP packets and their deconstruction (mostly mapping things from network to host order). This argues for userland libraries that can be chosen to fit the situation.

What if the protocol, or chunks of it, could end up more uniform and fixed, requiring less parsing and more mere deconstruction? SPDY is a step in that direction. One could definitely imagine a set of system calls dealing with SPDY streams and frames.
Previous post Next post
Up