Re: Stuck in a train -- reading HTTP/2 draft.

On Jun 24, 2014, at 1:09 AM, Mark Nottingham <mnot@mnot.net> wrote:

> Hi PHK,
> 
> On 23 Jun 2014, at 8:05 pm, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
> 
>> In message <0356EBBE092D394F9291DA01E8D28EC201186DF063@sem002pd.sg.iaea.org>, K
>> .Morgan@iaea.org writes:
>>> On Sunday,22 June 2014 14:36, phk@phk.freebsd.dk wrote:
>> 
>>>>> I realise I should probably clarify my thoughts on what to do if a
>>>>> single header doesn't fit in a 16K frame.  The option I like best comes
>>>>> from one of PHK's earlier posts, where one of the reserved bits in the
>>>>> frame header is used as a "jumbo frame" marker such that if it's set
>>>>> the first, say, four octets of payload space is actually an extra 32
>>>>> bits of payload length
>>>> 
>>>> I would have it be the max length of *any* frame we're willing to accept,
>>>> and the default would then obviously be the 16kbyte currently implicit in
>>> the standard.
>>> 
>>> So are you proposing the "jumbo frame" marker for all frames, not just the 
>>> HEADERS frames?  I think it's a great idea, but I know it makes a bunch of 
>>> people nervous about HOL blocking if you allow more than 16K in a DATA frame.
>> 
>> Yes, the length-extension would be available on all frames, which is why
>> we need a SETTING to limit what we'll accept in that respect.
>> 
>> For huge file transfers the 16k frames are horribly suboptimal and
>> having the receiver bang the frame size up once "Content-Length: A_LOT"
>> has been received will do wonders for performance on both ends.
>> 
>> Obviously, you can also reduce the frame size you'll accept.  16K
>> is quite large for a number of high traffic sites prone to DoS.
> 
> This has been discussed a lot over the life of the WG. The place where we left it was that the overhead of framing was quite small, considering that it's 8 bytes over 16K; TCP overheads are usually going to be bigger.
> 
> It's true that you can't use sendfile() here, but that's true with multiplexing regardless. It was felt that over time, kernel facilities specific to the use case of HTTP/2 will emerge if necessary, just as they did for HTTP/1.

I’m not sure they would. OSs tend to balk at application specific APIs and prefer reusable primitives. Even if an OS did though, it still has the cost of inserting frame headers every 16K, and that is not cheap. It also seems brittle to share the framing layer.

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat

Received on Wednesday, 25 June 2014 18:46:57 UTC