Subject: Review: http://www.ietf.org/id/draft-mbelshe-httpbis-spdy-00.txt

From: Mike Belshe <[email-masked]>
Date: Thu, 23 Feb 2012 13:21:38 -0800

I posted this draft for comment from all.

   http://www.ietf.org/id/draft-mbelshe-httpbis-spdy-00.txt

Best,
Mike

---

From: Willy Tarreau <[email-masked]>
Date: Sat, 25 Feb 2012 13:13:36 +0100

Hi Mike,

>    http://www.ietf.org/id/draft-mbelshe-httpbis-spdy-00.txt

First, thank you for posting this draft, it's full of very nice ideas.

I have a really major concern with header compression. I understand that
the initial reason why it is needed is that HTTP header names are quite
long, but is an issue that we should address in HTTP/2.0 instead of any
attempt to work around it by compressing them. Some header values are
quite long too. User-agent could be reduced to 16bit vendor-id + 8-bit
product-id + 8-bit product version. Cookies can be quite long but will
generally not compress much since long ones are supposed to be
unpredictable randoms.

The concern I'm having with header compression is that it makes DoS much
more trivial using low-bandwidth attacks. I've performed a test using the
dictionary provided in the draft. Using it, I can reduce 4233425 bytes of
crap headers to 7 bytes ("78 f9 e3 c6 a7 c2 ec"). Considered like this, it
looks efficient. Now see it differently : by sending a frame of 18 + 7 =
25 bytes of data, I can make the server write 4233425 bytes to memory then
parse those bytes as HTTP headers.  This is an amplification ratio of
4233425/25 = 169337. In other words, it means that with only the 256 kbps
of upstream bandwidth I have on my entry-level ADSL access, I can make an
intermediary or server have to process 43 Gbps of HTTP headers ! And even
if we did not use an initial dictionary, it's easy to achieve compression
ratios above 200 with zlib, which is still very dangerous in the case of
DDoS attacks.

Basically, it means that any low-end internet access is enough to knock
down even large sites, even those who make use of hardware-accelerated
zlib decompression. This is a major issue, especially if we consider the
rise of DDoS attacks these days.

In my opinion, in the sake of robustness, it is much better to be able
to parse the stream and stop as soon as something's wrong. This means
that the headers should be sent in the most easily parsable form. For
efficiency, we should ditch current header names and use 1-byte for the
most common ones. Possibly we could make use of a variable length encoding
for the size just as we used in WebSocket. This way, most headers could be
encoded as one byte for the length, one for the header name, and a few
bytes for the value.  Some headers could be typed as enums to save space.

For instance, if we apply this principle to the example in SPDY-Fan.pdf
(274 bytes) :

  GET /rsrc.php/v1/y0/r/Se4RZ9IhLuW.css HTTP/1.1
  Host: static.ak.fbcdn.net
  User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.8)
  Accept: text/css,*/*;q=0.1
  Accept-Language: en-us,en;q=0.5
  Accept-Encoding: gzip,deflate
  Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7

We could get down to something more or less like this with minimal effort :

   1 byte for method=GET + version=1.1
   1 byte for the Host header value length
  19 bytes for "static.ak.fbcdn.net"
  33 bytes for "/rsrc.php/v1/y0/r/Se4RZ9IhLuW.css"
   1 byte for User-Agent header name
   4 bytes for Mozilla + browser type + major version number
   1 byte for Accept
   1 byte for the number of content-types bytes
   1 byte for text/css
   1 byte for */*;q=
   1 byte for 0.1
   1 byte for Accept-Language
   1 byte for the number of accept-languauge bytes
   1 byte for en-us
   1 byte for en;q=
   1 byte for 0.5
   1 byte for Accept-Encoding
   1 byte for the number of bytes in the values
   1 byte for gzip
   1 byte for deflate        (note: both could be merged into one single)
   1 byte for Accept-Charset
   1 byte for the value length
   1 byte ISO-8859-1
   1 byte for utf-8;q=
   1 byte for 0.7
   1 byte for *;q=
   1 byte for 0.7

We're at a total of 80 bytes or 29% of the original size for a *small*
request, which was already dominated by the Host, URI and UA lengths.
And such an encoding would be as cheap to parse as it is to produce.

We also have to take intermediaries into account. Most of them touch a
few headers (eg: add/remove a cookie, etc). An encoding such as above
is much cheaper to produce than it is to decompress+recompress just to
add a cookie.

Best regards,
Willy

---

From: Mike Belshe <[email-masked]>
Date: Tue, 28 Feb 2012 14:52:53 -0800

Hi, Willy -

Thanks for the insightful comments about header compression.  I'm out of
the country for a few days, so I am slow to reply fully.

We did consider this, but ultimately decided it was mostly a non issue, as
the problem already exists.   Specifically - the same amplification attacks
exist in the data stream with data gzip encoding.  You could make an
argument that origin servers and proxy servers are different, I suppose;
but many proxy servers are doing virus scanning and other content checks
anyway, and already decoding that stream.  But if you're still not
convinced, the problem also exists at the SSL layer.  (SSL will happily
negotiate compression of the entire stream - headers & all - long before it
gets to the app layer).  So overall, I don't think this is a new attack
vector for HTTP.

We did consider some header compression schemes like what you proposed -
they are quite viable.  They definitely provide less compression, and are
less resilient to learning over time like zlib is.  They also generally
fail to help with repeated cookies, which is really where some of the
biggest gains are.  But I'm open to other compression schemes.

Note that SPDY's compressor achieves about 85-90% compression for typical
web pages.

Mike

---

From: Julian Reschke <[email-masked]>
Date: Wed, 29 Feb 2012 00:02:25 +0100

On 2012-02-28 23:52, Mike Belshe wrote:
> We did consider this, but ultimately decided it was mostly a non issue,
> as the problem already exists.   Specifically - the same amplification
> attacks exist in the data stream with data gzip encoding.  You could
> make an argument that origin servers and proxy servers are different, I
> suppose; but many proxy servers are doing virus scanning and other
> content checks anyway, and already decoding that stream.  But if you're
> still not convinced, the problem also exists at the SSL layer.  (SSL
> will happily negotiate compression of the entire stream - headers & all
> - long before it gets to the app layer).  So overall, I don't think this
> is a new attack vector for HTTP.
> ...

Am I missing something? When using SSL, the intermediate won't see the 
contents of the message anyway, right? (and yes, I'm aware of the "but", 
but that's not something we need to optimize for...)

Best regards, Julian

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 29 Feb 2012 00:52:15 +0100

Hi Mike,

> the country for a few days, so I am slow to reply fully.

No problem, don't worry :-)

> gets to the app layer).  So overall, I don't think this is a new attack

I see it differently. The other examples (SSL and content encoding) are not
mandatory for a server-side component, which is exposed to DDoS attacks.
Here we're talking about making compression a mandatory requirement for any
server-side component, which means that it would not even be an option to
disable it should this become a huge threat at some point.

> biggest gains are.  But I'm open to other compression schemes.

I'm fairly sure there will be less gain there, but we should balance the
gain and the cost. We could as well switch to LZMA to try to slightly
improve the compression ratio at an even higher cost. Also, I totally
understand why in SPDY you had to design *with* existing HTTP issues in
mind. Thus, your choices (eg: compress repeated cookies) make a lot of
sense. Now that we're designing a new HTTP version, we should first
address the original HTTP issues, one of them being duplicated headers
which has been discussed here to great extents. One of the possibilities
would be to allow anyone (including the UA) to remove duplicate headers
before folding.

> Note that SPDY's compressor achieves about 85-90% compression for typical

I'm not surprized and that's quite good. I'm not contesting the gains,
but rather the costs of reaching this gain while I think that slightly
lower ones might be achieved at a much lower cost provided that we can
rework HTTP now.

Best regards,
Willy

---

From: patrick mcmanus <[email-masked]>
Date: Tue, 28 Feb 2012 21:04:35 -0500

The  spdy compression scheme has proven itself very valuable in firefox 
testing.

Just like Mike has seen - we see 90% header reduction sizes, including 
on cookies because they are so repetitive between requests even if the 
individual cookies don't compress well. Exclusively, proscribing maps 
for well known values doesn't scale well to the value side of the n/v 
pairs and it biases strongly in favor of the status quo making it too 
difficult to deploy things like DNT in the future. I'm totally open to 
other formats as well - but this has proven itself to me with 
experience.. and right now I trust experience first, out of context data 
second, and good ideas third.

the dos implications don't bother me. http headers always have an 
implementation size limit anyhow - the fact that you can detect that 
limit has been hit with fewer bytes on the wire is kind of a mixed 
result (i.e. it isn't all bad or good).

For anyone that hasn't read some of the other posts on this topic, the 
compression here is a huge win on the request side because of CWND 
interaction. spdy multiplexes requests and can therefore, especially 
when a browser needs to get all of the subresources identified on the 
page, create a little bit of a flood of simultaneous requests. If each 
request is 500 bytes (i.e. no cookies) and IW=4, that's just  12 
requests that can  really be sent simultaneously. 90% compression means 
you can send 100+, which is a lot more realistic for being able to 
capture a page full of resources.. but honestly that's not far past 
current usage patterns and cookies of course put pressure on here too. 
So it's impt to count bytes and maximize savings. (pipelines have this 
challenge too and its the primary reason a pipeline of double digit 
depth doesn't really add much incremental value.)

On 2/28/2012 5:52 PM, Mike Belshe wrote:
> Hi, Willy -
>
> Thanks for the insightful comments about header compression.  I'm out 
> of the country for a few days, so I am slow to reply fully.
>
> We did consider this, but ultimately decided it was mostly a non 
> issue, as the problem already exists.   Specifically - the same 
> amplification attacks exist in the data stream with data gzip 
> encoding.  You could make an argument that origin servers and proxy 
> servers are different, I suppose; but many proxy servers are doing 
> virus scanning and other content checks anyway, and already decoding 
> that stream.  But if you're still not convinced, the problem also 
> exists at the SSL layer.  (SSL will happily negotiate compression of 
> the entire stream - headers & all - long before it gets to the app 
> layer).  So overall, I don't think this is a new attack vector for HTTP.
>
> We did consider some header compression schemes like what you proposed 
> - they are quite viable.  They definitely provide less compression, 
> and are less resilient to learning over time like zlib is.  They also 
> generally fail to help with repeated cookies, which is really where 
> some of the biggest gains are.  But I'm open to other compression 
> schemes.
>
> Note that SPDY's compressor achieves about 85-90% compression for 
> typical web pages.
>
> Mike
>
>
> On Sat, Feb 25, 2012 at 4:13 AM, Willy Tarreau <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi Mike,
>
>      Host: static.ak.fbcdn.net <http://static.ak.fbcdn.net>
>      19 bytes for "static.ak.fbcdn.net <http://static.ak.fbcdn.net>"

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 29 Feb 2012 19:18:54 +1300

On 29/02/2012 3:04 p.m., patrick mcmanus wrote:
> The  spdy compression scheme has proven itself very valuable in 
> firefox testing.
>
> experience.. and right now I trust experience first, out of context 
> data second, and good ideas third.

I keep hearing these reduction rates as related to bytes. But no mention 
of request per second throughputs. Which are equally important and 
directly affected by the compression.
I also have to assume since there is no mention of middleware 
measurements and still a general lack of SPDY proxy implementations that 
these are all single-hop measurements from browser to server?

Challenge: Implement a SPDY proxy which simply decompresses then 
recompresses. Pass each request through 1-3 layers of this proxy. 
Measure the gains and CPU loadings.

I think you will start to see the different costing model which 
middleware has to operate with. Browser also face these same costs, but 
middleware is often an order of magnitude or more up on the traffic 
scale with less idle CPU time to do work in. Sometimes the middleware 
has to handle orders of magnitude more traffic than even the server end.

> result (i.e. it isn't all bad or good).

Squid can provide a real-world example here for impact of compression on 
HTTP. It has the behaviour of consuming 100% of a CPU before it slows 
down with a noticable turning point, which is very useful for 
identifying that capacity overload point.
   Some months ago a gzip body compression module was published and 
several networks took it up. What they mentioned was that a one-way 
compression cuts the peak req/sec rate by up to 20%. That is just for 
response bodies. Now increase that a few percent to include headers and 
all the body-less requests SPDY is asking for compression on as well. 
Then double it for the decompression work on arrival. Things are 
suddenly looking like a 50% reduction in traffic speeds is possible. 
True, sending less over the wire helps the other software sharing that 
wire and parallel connections, particularly useful if one is paying by 
the byte. But does not help the poor end users stuck with visible 
reduction in download speed, or the middleware maxing out its CPUs, or 
the networks having to deploy up to twice as much hardware.
  And I am not considering the RAM DoS issues Willy brought up.

This is somewhat of a worst-case scenario given the efficiencies of the 
software involved. But IMHO is realistic enough that it should be 
considered as a good reason to get better measurements before diving in 
and mandating compression at the transport level.

> requests that can  really be sent simultaneously. 90% compression 
> means you can send 100+, which is a lot more realistic for being able 
> to capture a page full of resources.. but honestly that's not far past 

So you just sent 100+ requests. Each of which needs to be individually 
decompressed, parsed processed, re-multiplexed re-compressed and either 
delivered or relayed onward, where the same operations happen all over 
again. How long is that going to take overall? Did you actually save any 
download waiting time by sending them in one bunch? Or will the network 
transfer time saving be wasted by time in compression at each hop?

Lets have the bandwidth savings cake, but lets not sour it by adding 
time and power costs.

AYJ

>> We did consider some header compression schemes like what you 
>> proposed - they are quite viable.  They definitely provide less 
>> compression, and are less resilient to learning over time like zlib 
>> is.  They also generally fail to help with repeated cookies, which is 
>> really where some of the biggest gains are.  But I'm open to other 
>> compression schemes.
>>

---

From: Adrien de Croy <[email-masked]>
Date: Wed, 29 Feb 2012 19:31:39 +1300

there's also the burden of TLS on top of that.

With my proxy hat on, if a proxy is to add any value to such a system, 
it has to break into the SSL stream, decompress the messages, 
demultiplex the sessions to re-assemble request-response transactions 
then add the value, such as caching, content analysis etc.

Sounds like a nightmare to me for proxy vendors.

Of all that, the decompression is the simple bit.

Adrien

On 29/02/2012 7:18 p.m., Amos Jeffries wrote:
>> Just like Mike has seen - we see 90% header reduction sizes, 
>> including on cookies because they are so repetitive between requests 
>> even if the individual cookies don't compress well. Exclusively, 
>> proscribing maps for well known values doesn't scale well to the 
>> value side of the n/v pairs and it biases strongly in favor of the 
>> status quo making it too difficult to deploy things like DNT in the 
>> future. I'm totally open to other formats as well - but this has 
>> proven itself to me with experience.. and right now I trust 
>> experience first, out of context data second, and good ideas third.
>
> I keep hearing these reduction rates as related to bytes. But no 
> mention of request per second throughputs. Which are equally important 
> and directly affected by the compression.
> measurements and still a general lack of SPDY proxy implementations 
> that these are all single-hop measurements from browser to server?
>
> middleware has to operate with. Browser also face these same costs, 
> but middleware is often an order of magnitude or more up on the 
> traffic scale with less idle CPU time to do work in. Sometimes the 
> middleware has to handle orders of magnitude more traffic than even 
> the server end.
>
>>
> Squid can provide a real-world example here for impact of compression 
> on HTTP. It has the behaviour of consuming 100% of a CPU before it 
> slows down with a noticable turning point, which is very useful for 
> response bodies. Now increase that a few percent to include headers 
> and all the body-less requests SPDY is asking for compression on as 
> well. Then double it for the decompression work on arrival. Things are 
> This is somewhat of a worst-case scenario given the efficiencies of 
> the software involved. But IMHO is realistic enough that it should be 
> considered as a good reason to get better measurements before diving 
> in and mandating compression at the transport level.
>
>
>>
>> For anyone that hasn't read some of the other posts on this topic, 
>> the compression here is a huge win on the request side because of 
>> CWND interaction. spdy multiplexes requests and can therefore, 
>> especially when a browser needs to get all of the subresources 
>> identified on the page, create a little bit of a flood of 
>> simultaneous requests. If each request is 500 bytes (i.e. no cookies) 
>> and IW=4, that's just  12 requests that can  really be sent 
>> simultaneously. 90% compression means you can send 100+, which is a 
>> lot more realistic for being able to capture a page full of 
>> resources.. but honestly that's not far past current usage patterns 
>> and cookies of course put pressure on here too. So it's impt to count 
>> bytes and maximize savings. (pipelines have this challenge too and 
>> its the primary reason a pipeline of double digit depth doesn't 
>> really add much incremental value.)
>>
>
> decompressed, parsed processed, re-multiplexed re-compressed and 
> either delivered or relayed onward, where the same operations happen 
> all over again. How long is that going to take overall? Did you 
> actually save any download waiting time by sending them in one bunch? 
> Or will the network transfer time saving be wasted by time in 
> compression at each hop?
>
>
>>> Thanks for the insightful comments about header compression.  I'm 
>>> out of the country for a few days, so I am slow to reply fully.
>>>
>>> is.  They also generally fail to help with repeated cookies, which 
>>> is really where some of the biggest gains are.  But I'm open to 
>>> other compression schemes.
>>>

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
WinGate 7 is released! - http://www.wingate.com/getlatest/

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 29 Feb 2012 07:49:29 +0100

Hi Amos,

On Wed, Feb 29, 2012 at 07:18:54PM +1300, Amos Jeffries wrote:
(...)
>  And I am not considering the RAM DoS issues Willy brought up.

Please note that I was not talking about a RAM DoS but a CPU DoS, since
by sending just a few bytes you can force the other end to process many
more bytes. Even if you decide that you refuse to decompress past 8 kB
of headers, you still have to decompress them to discover that it too
large. Also nothing prevents the attacker from sending extremely large
valid requests in just a few bytes which you have to decompress and parse
before deciding that you finally don't want to process them, or worse,
recompress then forward.

This is my real concern. I'm regularly helping people to deal with DDoSes
and I can assure you that the first thing you try to do is spot a header
value which helps discriminate between real and undesired traffic then
start to act on this. It is worth noting that not all of the DDoS traffic
is easily identified at the boundary since many requests are totally valid
and must be forwarded to the origin servers. When you receive something
like 200000 requests per second, it's not uncommon to have to forward
about 20000 per second to the server after filtering 90%. Right now with
HTTP/1.1, a properly tuned $1000 PC is totally capable of this. With
compression, I already can't even imagine compressing 20000 requests per
second, let alone decompress and parse 200000. In fact it would even be
much more than 200000 since the bandwidth would allow something like 2
million thanks to the higher compression ratio. But these 2 millions
would have to be totally decompressed before being parsed then dropped.
For instance, something I've been facing several times is dropping a
few repetitive URIs. Bots requests non-existing objects at a very high
rate. You have little processing to perform, just match the URI and drop
the connection. That's quite cheap, just as it is to drop an HTTP/1.1
requests without a Host header.

(...)
> Lets have the bandwidth savings cake, but lets not sour it by adding 

That's exactly my point too. And again, I'm not contesting the huge
savings that Patrick and Mike report, I'm even impressed.

Thanks,
Willy

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 29 Feb 2012 08:24:49 +0100

Hi Patrick,

> second, and good ideas third.

I get your point, but as I said to Mike, saving space on *existing* HTTP
implementations with compressions might have been the only way of getting
to that point. But when redesigning HTTP we should address the issues that
caused compression to be introduced.

For instance, we currently lack session-oriented headers : over a
multiplexed connection, we should be able to send requests from
various agents at the same time and isolate them in "channels". We
could then send a number of headers only once per channel. Cookies
certainly are session-oriented. User-agent too. Accept headers too.
Host maybe. By doing so, we could simply state that session headers
are valid for all the requests of a given channel in a connection.
Instead of sending these headers to the compression lib and relying
on it to deduplicate them, you just send them once with the proper
type.

> result (i.e. it isn't all bad or good).

The problem is that in order to detect you reached the limit, you first
have to process up to the limit. And it costs nothing to the sender to
push you to the limit. DDoS fighting is a matter of strength balance.
"How can I maximize your pain at a minimal cost".

> capture a page full of resources..

I totally agree with these points. That's why I've been suggesting for a
long time that we work on dramatically reducing request size.

> but honestly that's not far past 

Agreed, but please, let's try to address the issue at its root instead
of trying to cover it. What SPDY does might be optimal for HTTP/1.1, but
here we're talking about how we'd like HTTP/2.0 to address HTTP/1.1 issues.
Let's focus on this first. At least thank to Mike's work and your feedback,
we *know* there is something to do with repeated cookies for instance (eg:
per-session headers).

Regards,
Willy

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 29 Feb 2012 07:40:16 +0000

In message <[email-masked]>, Willy Tarreau writes:

>But when redesigning HTTP we should address the issues that

I fully agree.

HTTP/2.0 should be about solving problems, not about kludging them.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 29 Feb 2012 08:41:29 +0100

> certainly are session-oriented. User-agent too. Accept headers too.

No, Accept headers depend on context.

The biggest gain with respect to Accept seems to not to send it at all 
when it does not matter, which should apply to the majority of requests.

> on it to deduplicate them, you just send them once with the proper

With that we loose the ability to inspect messages in isolation. Maybe 
that's acceptable, but the downsides should be considered.

Best regards, Julian

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 28 Feb 2012 23:45:50 -0800

Please, if you have an opinion, state it once and be satisfied that it
has been heard and archived in the usual place.  It does not need to be
repeated over and over again.

If you have a better design solution, then propose it as a separate draft.
There's nothing I'd like better than a number of open proposals and a
bake-off to see which one is better (or which ones are better, if that
depends on context or traffic styles).

For example, waka is a tokenized protocol for the exact reasons that you
describe, and it is specifically designed to speed intermediate processing.
Unfortunately, having no end of potential syntaxes to choose from means
I keep changing my mind as to which one to choose.  So I have nothing
to show for it, aside from a ten year old presentation and a lot of
burned out neurons.  I should have written a draft instead.  Maybe that
will happen after HTTPbis is complete.  Maybe I'll go sane instead.

It takes a lot of time to put together a decent Internet Draft, but it
can clarify your thoughts and expose some incomplete considerations.
I encourage anyone who is interested in doing so to give it a try.
I can't guarantee that anyone will like your ideas, but it is more
effective than arguing design decisions without an alternative at hand.

Cheers,

Roy T. Fielding                     <http://roy.gbiv.com/>
Principal Scientist, Adobe Systems  <http://adobe.com/enterprise>

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 29 Feb 2012 09:11:48 +0100

Hi Roy,

> effective than arguing design decisions without an alternative at hand.

I get your point. I too have huge difficulties finding time to contribute
a draft, though I'd love to participate to one. However discussing issues
here helps rising various people's concerns that nobody would have thought
of alone in front of his keyboard (eg: what Patrick and Mike said about
repeated cookies).

Mike has proposed a draft so in my opinion it makes sense to discuss it,
as it's a solid basis for future work. At least we have something to talk
about.

Regards,
Willy

---

From: Patrick McManus <[email-masked]>
Date: Wed, 29 Feb 2012 12:15:32 -0500

Hi Amos,

> Measure the gains and CPU loadings.

I'm going to start by saying that while computational scalability of all
parts of the ecosystem (server, intermediary, browsers, embedded clients
of other sorts, etc..) is important and must be kept within reasonable
limits, it is not the top priority for me in doing transport design for
the web.

The most important thing is enabling a better user experience (and
opening up new ones) over a network where bandwidth, cpu, memory, etc
all keep scaling up but latency doesn't operate on the same scale. our
current strategies butt their head into these things all the time
whether it is just delay of a handshake or delay in the ability to
respond/sense congestion.

I'm genuinely interested in what other priorities people see, but when I
look at the problems in web transport I don't start with "per
transaction cpu cost is holding back the web." But I do see that mobile
network characteristics makes that form factor down right unusable
sometimes even as the capabilities of the handset evolve rapidly. Add to
that the traditional web screws up VOIP, and that the lack of
cancellation semantics interacts with the connection mapping of http/1
in a way to create very unresponsive interfaces, and that simple tasks
like pushing calendar updates are fraught with challenges involving
timeouts and security, etc.. Getting past those road blocks are the
things that keep me up a night.

Making it cheaper to operate implementations of all types is awesome -
let's do it where we can - but it isn't the most heavily weighted
priority for me.

So let's address those transport things and evolve what people can do
with the web in an open standards process. Spdy is a good start there
from my point of view - some parts of it have significant positive
experience (e.g. compression) which is worth a lot to me, others are
less tested and should be scrutinized harder (e.g. certificate
interaction). 

To bring this back to compression - I just took a set of 100 compressed
real headers, and passed them through a decompress/recompress filter
1000 times in 350 milliseconds on one core of a rather unimpressive i5.
Spdy would do it faster because it tends to window things smaller than
the default gzip. So that's a cpu overhead of .35ms per set of 100. The
headers were reduced from 44KB (for the set of 100) to about ~4KB.
That's probably a reduction from 31 packets to 3. IW=4 means that's a
difference of 3 rtt's of delay to send 31 packets uncompressed vs 0
delay to send 3 compressed. 

rtt varies a lot, but let's call that 300 ms of latency saved at the
cost of .35ms of cpu. Its a trade off to be sure, but imo the right one
for the net.

Other schemes are plausible (e.g. per session templates that can be
referenced per transaction) and I'm very open minded to them - but I
wanted to be clear that I haven't seen any problems with this one
accomplishing its objectives. I think its biggest weakness (though
tolerable) is that it creates a state management issue which causes some
classes of spec violations to require connection termination instead of
being localized to the transaction.

-Patrick

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 29 Feb 2012 19:03:29 +0100

Hi Patrick,

> respond/sense congestion.

I agree that focusing on limiting latency effects is quite important.

(...)
> delay to send 3 compressed. 

That's precisely what worries me a lot. You were able to compress "only"
3000 requests per second on an i5, which means only 1500 request+response
per second for a proxy or gateway. I'm processing 100 times this without
compression on the same hardware, so in the sake of scalability, we first
have to divide CPU efficiency by 100, which is not a really good starting
point in my opinion. Also, adding .35ms per request (and same for the
response) means that .7 ms of real latency will be added for every proxy
layer a request has to pass through. IPS, load balancers, caches, proxies
etc... All of them will add their own delay. At some of my customers, a
request can be forwarded through up to 12 or 13 layers last time I counted,
which means approx 10 ms of cumulative processing time. I know some sites
running at less than 100 microsecond of average response time, their
response time would be increased by an order of magnitude due to this.

Also, there is another thing to consider. The only place where compression
helps is between browsers and servers. Most of the HTTP requests are
between server-side infrastructure components since for a single browser
request, a fair number of components are sollicited. I think it would be
a major design error to force all gateways, servers, etc... to communicate
together with compressed data over low-latency links where CPU matters the
most. Think about web services too.

> cost of .35ms of cpu. Its a trade off to be sure, but imo the right one

It's not really .35ms of CPU, it's .35 ms of CPU *per browser*. When you
have 10k browsers connected on a site, you're at 3.5s of CPU for one single
clic for each of them. That's huge. Like Amos said it, the cumulated latency
caused by CPU overhead can quickly overwhelm the network latency. If my
gateway has to deal with 50000 requests per second, it needs 17 seconds
of CPU for each second of wall-clock. Variations of CPU load will quickly
add up CPU-based latency.

> being localized to the transaction.

Patrick, don't get me wrong, I'm certain that what has been achieved is
really nice, and it proves that reducing the size of a request has a major
impact on user experience. But you're mostly dealing with code running at
a rate of 1 user. Some of us are dealing with code having to support 10s
to 100s of thousands of users on similarly sized hardware. We have reasons
to be quite concerned with these CPU impacts and with the increased DoS
risks.

I'll try to find time to put a few ideas on the table to start from
something, otherwise we'll all spend our time saying that we agree but
have nothing else :-)

Regards,
Willy

---

From: Patrick McManus <[email-masked]>
Date: Wed, 29 Feb 2012 13:46:54 -0500

On Wed, 2012-02-29 at 19:03 +0100, Willy Tarreau wrote:

> 3000 requests per second on an i5, 

3000 sets of 100 http transactions per second on 1 core of an i5 with a
lame implementation. So that's 300,000 http transactions per second per
core on a chip that costs ~$50 a core. not a big factor.

> which means only 1500 request+response
> per second for a proxy or gateway. 

150,000 per second.

I'll also note that it's not a moral failing if we specify a protocol
that's good for the Internet that can be gatewayed to one that is better
for back offices, although I don't think that has to happen. I think the
work of the Internet protocol is the more important work of the IETF.

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 29 Feb 2012 20:09:20 +0100

> core on a chip that costs ~$50 a core. not a big factor.

OK sorry I understood in the text above 1000 requests of 100 headers each
in 350 ms.

> work of the Internet protocol is the more important work of the IETF. 

It's not a moral failing, but for adoption you have to ensure that you
don't multiply server-side infrastructure costs by 100 too and you don't
expose them to new risks.

Regards,
Willy

---

From: saravanakumar Annamalaisami <[email-masked]>
Date: Thu, 1 Mar 2012 00:39:12 +0530

Hello Willy,

Also, adding .35ms per request (and same for the
response) means that .7 ms of real latency will be added for every proxy
layer a request has to pass through. IPS, load balancers, caches, proxies
etc...

This is a very valid/critical point. It would even get worse,  if any of
these devices have limited number of threads/core serving the request.  The
per-header latency added by the 'header compression' would be a big thing
for a small request/response header cases.

It is not only CPU-intensive, but also requires significant amount of
memory, if it mandates a 'stateful glib compression'.  This could create
lots of scalablity issue for the intermediate devices that you have listed
and also the server.

If we are really looking at reducing the header bytes, it is
cheaper/scalable if we could address them at the HTTP/application protocol
level itself than addressing them through 'generic stateful glib
compression'.

Like for ex., in case of request, referer/user-agent/cookie/accept are few
of the headers that adds up to most of the bytes.  There could be other
headers depend on the application.  And, most of the cases, these headers
does not change during a user session.

We could define a protocol/mechanism to cache/store this information in the
server side so that the client could sent a short-form of these header
values, after the first request.

If we have a alternative way to get 'part of the benefit of the stateful
glib HTTP header compression', it is worth it.

-thanks, Saravana.

---

From: Adrien de Croy <[email-masked]>
Date: Thu, 01 Mar 2012 09:25:25 +1300

I think in the end, an "optimized" protocol is still not going to 
achieve the compression ratio of something like gzip, simply because it 
will have difficulty compressing the URI, and header values.

However, as a proxy vendor (and I think you'll notice most people with 
the biggest concerns fall into that camp), we have to look at impact on 
proxies.

The current spec basically bypasses proxies by using TLS.

Encryption / decryption will add probably as much CPU and latency as 
compression / decompression.

In the deployment scenarios Willy is talking about, with front-end load 
balancers and reverse proxies etc, it would affect scalability to force 
adoption of encryption and compression inside a trusted, high bandwidth 
low-latency environment.

So what would we do?  We can either

a) specify a different protocol for this environment
b) make the encryption and compression be optional and then just use the 
same protocol.

(a) makes no sense.  (b) gives rise to new class of product, such as 
front-end SSL and gzip layer.  It then becomes an administrative 
decision whether to use crypt and comp on a connection.

It also means then clients can talk uncompressed and unencrypted to 
local proxies which can then decide whether to make encrypted and 
compressed connections or not.

The problem with making SSL/TLS optional is that currently that's the 
mechanism used to negotiate use of SPDY in the first place.  Without 
that, you'd need to tell the client (e.g..in the hyperlink URIs) what 
protocol to use / is in use at that site, which would mean hyperlinks 
wouldn't be http://www.example.com any more, but something else like 
spdy://www.example.com.  What port it was on would depend on deployment, 
since you couldn't easily share http and spdy native on the same port.  
Unless of course something was built in to allow both types of server to 
discriminate... without redeployment of existing http servers.... so 
actually I think you'd end up having to use a new port number.

But I generally prefer explicit to implied information, so I don't know 
if I would have a problem with this.

Adrien

---

From: Henrik Nordström <[email-masked]>
Date: Wed, 29 Feb 2012 21:41:33 +0100

> it has to break into the SSL stream, decompress the messages, 

Yes, or put differently, for user-agent delegated proxies to work the
TLS needs to be hop-by-hop, not end-to-end.

Regards
Henrik

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 29 Feb 2012 20:50:42 +0000

>(a) makes no sense.

Actually, I think (a) makes a lot of sense.

That it one of the main reasons why I think we should not focus on
SPDY, but rather on getting a clean and modular transport/semantics
split which will allow us to have multiple transport protocols with
different properties.

There is an ocean between the desired protocol properties for a
porn site, a news media, a daytrader and a webbank site.

Trying to use a once-size-fits-nobody model to bridge that span is
exactly why we are talking about HTTP/2.0 in the first place.

At the very minimum, there is a need for two different transport
protocols:

1. Bulk (focus on bw/latency/load)

2. Cryptographically protected (focus on auth/priv/ident)

Which is why we have HTTP and HTTPS today.

SPDY tries to be both, and adds server push and various other bells
and whistles on top, and as others have commented, Moores law is
not enough to make that feasible for high-volume sites.

I think any attempt to have just one transport protocol runs into
so many conflicting demands that implementing X.40? in INTERCAL
will seem like a nice project to relax with, and a successful
transition period only slightly longer than IPv6 is almost guaranteed.

I think HTTP/2.0 should expect to have at least four transport
protocols:

a) HTTP/1.x for backwards compatibility

b) HTTP/2.0 Bulk mode (smaller headers, possibly mux/pipeline)

c) HTTP/2.0 Crypto (or possibly HTTPS unchanged to avoid recertification)

d) HTTP/2.0 Bells&Whistles (server push, websockets, RPC etc.)

SPDY may be a candidate for d), but it sure as hell isn't for b).

To what extent c) and d) can be combined I will not venture an opinion.
I will note that deployment of a HTTPS replacement involves a lot of
paperwork and in some cases regulatory action.

So can we please stop this one-eyed focus on SPDY, and start looking
at how we accomodate multiple transport protocols in a sensible manner ?

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 29 Feb 2012 22:07:56 +0100

Hi Adrien,

On Thu, Mar 01, 2012 at 09:25:25AM +1300, Adrien de Croy wrote:
(...)
> spdy://www.example.com.

Using the Upgrade mechanism would solve this issue. It will also
make Roy feel happy to have insisted a lot that after a 101, the
server must send a final response to the request. what I mean is
that a client should simply send the first request in HTTP/1.1
with an Upgrade header for HTTP/2.0. If the server ignores Upgrade
and only replies in 1.1 the server is not 2.0 compliant. If the
server responds with 101 Switching Protocol with Upgrade: 2.0
then the protocol switches to 2.0 and the server responds in 2.0
language. From this point, everything is 2.0 between both sides.

And using Upgrade really offers a very smooth transition path
between 1.1 and 2.0.

Regards,
Willy

---

From: Mike Belshe <[email-masked]>
Date: Wed, 29 Feb 2012 15:00:58 -0800

> savings that Patrick and Mike report, I'm even impressed.

Hey Willy -

Overall, I'm not sure how much to worry about DoS.  In the end, I think its
something you figure out how to mitigate in implementations - just like
we've done it before at every level from DNS to TCP to SSL to HTTP.

I don't think its as dire as you've made it out to be.  It's not like this
amplification attack is difficult to mitigate.  A server wanting to limit
it, would probably do the following:

   a) First off, because SPDY tries to limit connections to one-per-domain,
there is a new element of information at the transport layer which can be
used for DoS countermeasures.  This needs some experimentation, and I bet
it will be useful.

   b) Also note that for SPDY over SSL, you've got DoS countermeasures from
the SSL layer at your disposal.  These are certainly going to slow down
many attackers.  (It will also make some sites nervous - especially those
that haven't hardened port 443 yet!)

   c) If they get through both of those layers, the amplification attack is
easy to detect, and not a consumption of massive memory, bandwidth, or CPU
on the server; an implementation looking to conservatively block DoS could
check for expansions of 2-4KB and probably thwart most everything right
there.  Cheap.

Overall, I just don't see how DoS is a silver-bullet against the zlib
compressor.  Almost any new feature has DoS potential (e.g. we haven't even
talked about frame flooding or syn_streams yet :-)

If the bar for acceptance is "no new DoS potential", then I'm not sure
there is room to change very much in HTTP/2.0 ever.

Mike

---

From: Mike Belshe <[email-masked]>
Date: Wed, 29 Feb 2012 15:14:24 -0800

On Wed, Feb 29, 2012 at 11:09 AM, saravanakumar Annamalaisami <
[email-masked]> wrote:

> We could define a protocol/mechanism to cache/store this information in
> the server side so that the client could sent a short-form of these header

If we're going to talk about server scalability, we should talk about the
entire protocol, not just small parts of it.  The bigger win in server
scalability is likely the reduction in connections-per-site with SPDY.  A
typical web page can drop the number of connections it uses by a factor of
at least 6, sometimes more.  SSL is another factor, of course.  And both of
these are far more invasive than the compressor.

I'd really rather hear from servers implementing SPDY that can demonstrate
a real scalability problem rather than just theory.

Mike

---

From: Mike Belshe <[email-masked]>
Date: Wed, 29 Feb 2012 15:16:22 -0800

> And using Upgrade really offers a very smooth transition path

The problem with upgrade is that it costs a round trip of latency.

Mike

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 29 Feb 2012 15:43:47 -0800

> the SSL layer at your disposal.  These are certainly going to slow down many
> attackers.  (It will also make some sites nervous - especially those that
> haven't hardened port 443 yet!)

Can you elaborate on what you have in mind in terms of SSL DoS countermeasures?

-Ekr

---

From: Henrik Nordström <[email-masked]>
Date: Thu, 01 Mar 2012 00:50:25 +0100

> The problem with upgrade is that it costs a round trip of latency.

Only if you are pipelining and then only on the second request, and
pipelining on the first request is generally a bad idea anyway. So no.

It's just means that the initial request (not it's response) is limited
to HTTP/1.x wire format and that you can't pipeline if the protocol
change means pipelined requests can not be properly parsed after the
protocol change.

And if HTTP/2.x preserve initial request-line structure compatibility
with HTTP/1.x like it should then future requests to the same server
should be able to assume the server is HTTP/2.x capable from start,
until rejected, and you can even pipeline during the protocol upgrade if
desired.

Regards
Henrik

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 29 Feb 2012 23:53:34 +0000

In message <[email-masked]>, Henrik =?ISO-8859-1?Q?Nord
>pipelining on the first request is generally a bad idea anyway. So no.

There is of course an incredible evil way to indicate what protocol
you want, without expending a RTT:

Have the server send a TCP option in the SYN+ACK packet that tells
you what it can do on this TCP connection.

/me <- ducks

---

From: Adrien de Croy <[email-masked]>
Date: Thu, 01 Mar 2012 13:09:29 +1300

On 1/03/2012 12:53 p.m., Poul-Henning Kamp wrote:
> In message<[email-masked]>, Henrik =?ISO-8859-1?Q?Nord
> str=F6m?= writes:

Heh..  I was just about to suggest a TCP option.

I don't think stack support is that good for such things though.

> /me<- ducks

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 29 Feb 2012 16:20:04 -0800

> I don't think stack support is that good for such things though.

No doubt this is why SPDY uses a TLS extension (NPN).

-Ekr

---

From: Henrik Nordström <[email-masked]>
Date: Thu, 01 Mar 2012 01:31:44 +0100

> you want, without expending a RTT:

Which RTT?

> you what it can do on this TCP connection.

We can't assume such detail TCP transport. Might be running over SOCKS
or any other intermediary protocol abstracting away any such details.

Regards
Henrik

---

From: Adrien de Croy <[email-masked]>
Date: Thu, 01 Mar 2012 13:36:02 +1300

> or any other intermediary protocol abstracting away any such details.

similar could happen for SPDY with SSL as well, if an intermediary mitms 
the connection, unless they pass on the option negotiation, it's gone.

Adrien

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 01 Mar 2012 00:37:37 +0000

In message <[email-masked]>, Henrik =?ISO-8859-1?Q?Nord

>or any other intermediary protocol abstracting away any such details.

Well, in that case you'll have to waste an RTT doing a UPGRADE.

Just because somebody cannot support this indication, doesn't mean
that it would not be beneficial to have it for a large swatch of
webservices.

---

From: Mike Belshe <[email-masked]>
Date: Wed, 29 Feb 2012 16:39:39 -0800

If the protocol is allowed to be slower than HTTP/1.1, then you could do
this.  But, a lot of server operators that care about performance aren't
going to want to take that hit.

Also, if the browser records that your server was HTTP/2.0 in the past, and
now it downgrades to a non HTTP/2.0 response, the failure detection needs
to be quick.  If the frame format is different, depending on the way the
bytes flow, this could lead to a devastating timeout (30+ seconds for the
user to wait!)

It all comes down to perf, though.  The upgrade round trip is sure death.

mike

2012/2/29 Henrik Nordström <[email-masked]>

---

From: Henrik Nordström <[email-masked]>
Date: Thu, 01 Mar 2012 02:22:01 +0100

ons 2012-02-29 klockan 16:26 -0800 skrev Mike Belshe:

> If the protocol is allowed to be slower than HTTP/1.1, then you could
> do this.  But, a lot of server operators that care about performance
> aren't going to want to take that hit.

Why on earth would it be slower than HTTP/1.1?

The only possible penalty compared to HTTP/1.1 is a request header more
in the initial request asking for upgrade.

> Also, if the browser records that your server was HTTP/2.0 in the
> past, and now it downgrades to a non HTTP/2.0 response, the failure
> detection needs to be quick.

It's one RTT if done right.

> It all comes down to perf, though.  The upgrade round trip is sure

There is no round-trip penalty in Upgrade as long as the request
semantics you need can fit in HTTP/1.1. And if it can't then we are most
likely not talking about HTTP.

GET / HTTP/1.1
Host: www.example.com
Upgrade: HTTP/2.0

101 Switching Protocols
Upgrade: HTTP/2.0

HTTP/2.0 200 OK
Content-Type: text/html
Boundary: ====END===

<H1>Hello</H1>
====END====
GET /img HTTP/2.0
....

And a downgrade from HTTP/2.0 sent to a HTTP/1.1 server is

GET / HTTP/2.0
...

HTTP/1.1 505 HTTP Version Not Supported
....

GET / HTTP/1.1
...

There is a roundtrip in Upgrade if using it for STARTTLS, but then
because one maybe do not want to send the initial request ouside the TLS
wrapper so the initial request is may be a dummy one such as OPTIONS *.
If there is no need to secure the content of the initial request then
there is no RTT penalty for TLS upgrade either.

Regards
Henrik

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 01 Mar 2012 14:40:54 +1300

On 01.03.2012 13:39, Mike Belshe wrote:
> do

That is what bothers me about all the arguments against Upgrade: based 
on extra RTT and lag.

  today: HTTP/1.1 request + HTTP/1.1 response   == 1 RTT

versus

  tomorrow: HTTP/1.1 request /w Upgrade header + XYZ response /w 200 
status prefix   == 1 RTT

Assuming that native XZY is more efficient than HTTP/1.1. Where is the 
_loss_?
  All I see here is a gain of one responses XZY benefits.

> past, and

What type of server accepts an invalid format then does not reply?
  This is where a response in some supported format, at HTTP or TCP 
layer gets sent back immediately. There is no timeout.

Could this perhapse be a side effect of using TLS and compression in 
SPDY? both of those would mask the internal syntax invalidity somewhat.

> It all comes down to perf, though.  The upgrade round trip is sure 

What RTT?

AYJ

---

From: Brian Pane <[email-masked]>
Date: Wed, 29 Feb 2012 19:52:04 -0800

On Wed, Feb 29, 2012 at 5:40 PM, Amos Jeffries <[email-masked]> wrote:
> That is what bothers me about all the arguments against Upgrade: based on
> extra RTT and lag.
>
>  tomorrow: HTTP/1.1 request /w Upgrade header + XYZ response /w 200 status
> prefix   == 1 RTT

I use a different comparison:

HTTP/1.1 today:
    TCP handshake: 1 RTT
    HTTP/1.1 request for resource 1: 1 RTT
    Total == 2 RTT
...meanwhile, the same thing happens on m-1 other connections that the
browser is using in parallel

HTTP/1.1 with Upgrade to 2.0:
    TCP handshake: 1 RTT
    HTTP/1.1. request for resource 1: 1 RTT
    HTTP/2.0 requests for resources 2, ..., n-1, n: 1 RTT
    Total == 3 RTT

More generally, the minimum number of round trips to fetch n small
objects in current HTTP/1.1 usage is:
  1+ CEILING(n/m) RTT
where m is the number of concurrent connections the client uses
(typically 6 or 8 for current-generation browsers.)  If a client used
an initial HTTP/1.1 request to negotiate an upgrade to HTTP/2.0, the
minimum number of round trips would be:
  2 + n

For n<=2*m, the Upgrade-based approach would mean more round trips
than are required today.

The Upgrade approach also would require more round trips than current
SPDY usage:

SPDY today:
    TCP handshake: 1 RTT
    TLS handshake, including NPN: 2 RTT
    SPDY requests for resources 1, 2, ..., n-1, n: 1 RTT
    Total = n resources in 4 RTT

Initial HTTP/1.1 request + Upgrade:
    TCP handshake: 1 RTT
    TLS handshake: 2 RTT
    HTTP/1.1 request w/Upgrade + response x/ 200 status: 1 RTT
    SPDY requests for resources 2, ..., n-1, n  = 1 RTT
    Total = n resources in 5 RTT

In terms of sending an initial HTTP/1.1 request to upgrade to HTTP/2.0
looks like a step backwards compared to current deployments of both
HTTP/1.1 and SPDY.

-Brian

---

From: Adrien de Croy <[email-masked]>
Date: Thu, 01 Mar 2012 17:00:16 +1300

need to add a few more RTTs for TLS.

Adrien

On 1/03/2012 4:52 p.m., Brian Pane wrote:
> On Wed, Feb 29, 2012 at 5:40 PM, Amos Jeffries<[email-masked]>  wrote:

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 1 Mar 2012 08:18:33 +0100

> The problem with upgrade is that it costs a round trip of latency.

Not for the first request since the server responds to this request.
And since in HTTP you need the first request anyway to fetch the page
to discover the objects you'll have to request next, it's not an issue
for the first request of the keep-alive connection.

Regards,
Willy

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 1 Mar 2012 08:30:42 +0100

Hi Mike,

> check for expansions of 2-4KB and probably thwart most everything right

I disagree on exactly this point, because in order for the server to know
that it doesn't want to process this 4 kB request, it first has to decompress
it. Using plain old HTTP, in order for the server to reject a 4 kB request,
the attacked had to upload it, which would have limited its ability to knock
the server down. Now with just a few bytes an attacker can build a 4 kB request
that the server will have to parse before deciding to reject it. A 4kB request
would fit in 6 bytes from what I've seen, maybe less. This means that by
filling the pipe with 6-bytes requests, a client can make a server parse 800
times that amount of traffic. Filling a pipe at 1 Mbps means the server has
to process 800 Mbps of requests it will decide to drop in the end. This is
my precise concern. And more importantly, I doubt that a 4kB limit will last
long. I've used 4kB as a request size limit in haproxy 10 years ago, and I
quickly had to push it to 8kB to satisfy most sites. In enterprise, it's
worse, sometimes people configure it up to 32 kB but that's another story.

> compressor.

Note that I'm not trying to find a silver buller against zlib, I'm worried
about zlib making DoS much easier. I have a great respect for all the work
you have done in optimizing the use of zlib for header compression and I
don't want to dismiss any of your findings. I just think that one point has
been overlooked and this point in my opinion is a real problem.

> Almost any new feature has DoS potential (e.g. we haven't even

Every design choice that makes DoS easier needs to be addressed even if
it slightly reduces optimizations. DoS is far too common these days, we
should focus on protecting the internet *before* making it faster for
mobile users.

Regards,
Willy

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 1 Mar 2012 08:40:34 +0100

>     HTTP/2.0 requests for resources 2, ..., n-1, n: 1 RTT

No this one above is wrong. You're still at 2 RTT for HTTP/2.0 with
Upgrade :

 HTTP/1.1 with Upgrade to 2.0:
     TCP SYN ----------------------->
             <----------------------- TCP SYN/ACK           => 1 RTT
     HTTP/1.1 GET+Upgrade ---------->
              <---------------------- HTTP/1.1 101+Upgrade
              <---------------------- HTTP/2.0 200 response => 1 RTT

Total = 2 RTT. Doesn't change anything compared to 1.1.
To be precise, the only difference is that the sender has
to emit "Upgrade: HTTP/2.0" in the first request and that
the server prepends an intermediate response "HTTP/1.1 101"
followed by "Upgrade: HTTP/2.0". It's just a few extra bytes
in the first connection setting up.

Regards,
Willy