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

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.

Is there something else behind "horribly suboptimal" here? Can you give some numbers?

Cheers,


--
Mark Nottingham   https://www.mnot.net/

Received on Tuesday, 24 June 2014 06:10:21 UTC