- From: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Date: Sat, 31 Mar 2012 07:30:12 +0000
- To: Willy Tarreau <w@1wt.eu>
- cc: Roberto Peon <grmocg@gmail.com>, Mark Watson <watsonm@netflix.com>, Mike Belshe <mike@belshe.com>, "William Chan (?????????)" <willchan@chromium.org>, "<ietf-http-wg@w3.org>" <ietf-http-wg@w3.org>
In message <20120331071333.GL14039@1wt.eu>, Willy Tarreau writes:
>> Framing is just the wrong place to spend complexity... it makes far more
>> sense to spend it on features that improve performance, latency, or
>> security, at least in my opinion.
Framing done badly hurts performance.
What we're looking for is the highest-performance HTTP protocol
we can imagine. HTTP scaled from 10Mbit/s to 10Gbit/s so far,
HTTP/2.0 will have to do at least 1Tbit/s in its lifetime.
If we imagine the perfectly optimal behaviour from the network
stack, and perfectly optimal HTTP message from the other end, the
perfect protocol scenario looks like this:
[length of head]
[head]
[length of body]
[body]
Under utterly perfect circumstanses, just three socket reads will
get you the head and body into memory chosen, sized, aligned &
allocated perfectly for the purpose:
READ(length header) ->len buffer
(allocate workspace)
READV(head + next length header) -> (workspace, len buffer)
(allocate bodyspace)
READ(body) -> bodyspace
Any protocol which by design requires more work to move the bits from
the TCP connection, through the socket API and into the applications
memory, is not a high-performance protocol, worthy of HTTP/2.0
consideration.
Notice that just doing:
READ(1GB)
might get you the same data into memory, but you can not optimally
place it in memory without memcpy'ing it around.
Notice that at this point we have not talked about compression,
TLS, integrity or anything else, we are only talking about how we
pull a byte stream out of the TCP socket API, into memory of our
desire.
Likewise, adding other overhead to the [length] header, proto-id,
compression indicators, sequence numbers, session ids and so on,
may or may not make sense, but does not affect the analysis.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
Received on Saturday, 31 March 2012 07:30:37 UTC