
HTTP/2: The Long-Awaited Sequel - mattparlane
http://blogs.msdn.com/b/ie/archive/2014/10/08/http-2-the-long-awaited-sequel.aspx
======
zaptheimpaler
Check out the IETF draft[1], and this awesome book[2] for more details on
HTTP/2.

Some of the coolest stuff I saw was streams and server push. Streams allow
multiplexing multiple logical streams of data onto one TCP connection. So
unlike the graphs you typically see in chrome network inspector where one
resource request ends and another begins, frames (the unit of data) from
multiple streams are sent in parallel. So this means only one connection
(connects are persistent by default) is needed between server and client, and
there are ways to prioritize streams and control flow so it gives devs more
opportunities for performance gains.

Also headers are only sent in deltas now. Client/server maintain header tables
with previous values of headers (which persist for the connection), so only
updates need to be sent after the first request. I think this will be a
consistent 40-50 byte saved per request for most connections where headers
rarely change.

[1] [http://tools.ietf.org/html/draft-ietf-httpbis-
http2-14](http://tools.ietf.org/html/draft-ietf-httpbis-http2-14)

[2]
[http://chimera.labs.oreilly.com/books/1230000000545/ch12.htm...](http://chimera.labs.oreilly.com/books/1230000000545/ch12.html)

~~~
monstermonster
I don't get this.

TCP has steams. TCP has connection mux. TCP has flow and congestion control.
HTTP has keepalive. Why build another stack on OSI layer 7?

Also now we have to keep state to work out what the diffs are. State is evil.

Whilst I'm sure this will have some minor performance advancements, I'm not
sure that it justifies the new protocol stack.

Not sending 2Mb of JavaScript and crappy HTML down the connection to display
the front page probably has higher gains.

~~~
jws
You'll need to call a meeting of all the internet's firewall administrators
who block TCP ports by default but allow 80 and 443 through. If you can get
them to agree to stop breaking the internet then we can use TCP. Until then we
will need to build a new internet on top of HTTP, inside encryption so they
can't meddle with it.

~~~
monstermonster
I don't understand your point.

80 and 443 are "well known ports"[1] which is fine.

What does this have to do with ports? TCP is connection based so a client can
create as many connections as it likes to a port on a host.

If someone does indeed build a new "internet" built on top of HTTP which is
tunnelled through well known ports with different services with the intention
of circumventing the firewall then they will not be allowed through my
firewall at all.

[1]
[https://www.ietf.org/rfc/rfc1700.txt](https://www.ietf.org/rfc/rfc1700.txt)

~~~
dcsommer
The problem is that opening new connections is horribly inefficient. The 2-3
round trips (TCP + SSL) required to set up a new connection and the ensuing
slow start phase significantly delay the request, and thus the response. It is
_much_ more performant to use a single, well-utilized connection in congestion
avoidance. The only way to avoid the ugliness of repeated flow control is to
build on top of UDP (see QUIC), but there are practical issues with network
connectivity and firewalls there.

EDIT: why do you want to block HTTP/2 by the way? You know that HTTP/1.1 can
be used to tunnel other protocols too, right?

~~~
monstermonster
That's not horribly inefficient. That's the cost of doing business with HTTP.

In fact you're going to have to go to the same effort to establish a TCP
connection that your HTTP/2 is going to run over, then still have to do a key
exchange. That channel then has the same advantages of a persistent HTTP/1.1
channel plus the ability to provide multiple streams.

The multiple streams can be resolved simply by making more than one connection
to the server defensively. Perhaps a mechanism to schedule that client-side
would work. Oh wait, we already have one (connection limits and keep-alive).

Then again, all of this is moot as once you've loaded the static resources
(images/css/js etc) via HTTP, you should only be seeing one request
periodically when an operation takes place or at an interval if polling or
kept alive for server-push so maximum two connections from a client to a
server.

If you need to do anything more than that, you're probably using the wrong
technology both on the server and client.

HTTP/1.1 tunnelling I understand. In fact I use it most of the day (RDP over
terminal services gateway) which is RPC over HTTP.

The rationale I have is that effectively managing HTTP/2.0 at the firewall
requires packet and protocol inspection rather than merely understanding what
connections have been made and where from and where to. This has a significant
complexity and tooling cost and effort. Plus there is a significant
opportunity to mask illegitimate traffic as legitimate traffic. For those of
us who deal with end user network security, this is a major problem.

------
mmastrac
HTTP/2 is certainly not a clean separation of concerns like HTTP/1.x was, but
it's something of a pragmatic approach to protocol design.

HTTP/1.x was neatly layered on TCP with an easy-to-parse text format. This in
turn ran neatly on IP4/6, which ran on top of Ethernet and other myriad
things. This separation of concerns gave us the benefit of being very easy to
understand and implement, while also allowing people to subvert the system,
adding things like half-baked transparent proxies to networks that would munge
streams and couldn't agree where HTTP headers started. We ended up having to
design WebSockets to XOR packets just to fix other people's broken
deployments.

HTTP/1.x also became so pervasive that it became the overwhelmingly most
popular protocol on top of TCP, even to the point where a system administrator
could block everything but ports 80 and 443 and probably not hear anything
back from their userbase. This is the reason we ended up with earlier
monstrosities like SOAP and XML-RPC: by that point HTTP had become the most
prevalent transport that it was assumed incorrectly in many cases that it was
the _only_ transport.

Perhaps the IETF should be pushing a parallel version of HTTP that pushes many
of these concerns into SCTP. The problem here is that it'll take forever to
get that rolled out and we need something to improve things now. Look at how
long it's taking to roll out IPv6: something we _actually need_ to fix now.

~~~
meowface
>We ended up having to design WebSockets to XOR packets just to fix other
people's broken deployments.

I was unaware of this and became intrigued. If anyone else is curious, this is
the explanation from the RFC:
[http://tools.ietf.org/html/rfc6455#section-10.3](http://tools.ietf.org/html/rfc6455#section-10.3)

Basically it's to prevent an attacker from cache poisoning an HTTP proxy (like
one on a corporate network) that doesn't properly support WebSockets.
WebSockets look a lot like HTTP over the wire, so without masking the wire
data in some way a proxy could be tricked into believing a faked
"HTTP"-looking request and response are real, and thus cache whatever an
attacker supplies.

This would technically be a bug in the proxies, but it's nice to see IETF
accounted for this and put in countermeasures before it inevitably became a
DEFCON talk.

------
tagrun
> Why is Internet Explorer leading with HTTP/2 implementation?

 _Leading?_ Firefox and Chrome already support HTTP/2 already (and SPDY, the
basis for HTTP/2, for a long time now), just not enabled by default.

~~~
nextw33k
You are right and given that its a tech preview, this is Microsoft catching
up.

Their real problem of course is IIS. We'll probably have to wait for IIS9
which I cannot see happening for another two years. IIS8.5 appeared 12 months
ago in Windows Server 2012 R2.

------
codeka
Also, Chrome has experimental support for HTTP/2 in Canary[1] as well as
Firefox since version 34 (if I'm reading [2] correctly).

It seems unusual for Microsoft to disable SPDY support entirely, at least
until support for HTTP/2 is more widely deployed...

[1]: [http://www.chromium.org/spdy/http2](http://www.chromium.org/spdy/http2)

[2]:
[https://wiki.mozilla.org/Networking/http2](https://wiki.mozilla.org/Networking/http2)

~~~
UnoriginalGuy
HTTP/2 is based on SPDY:
[http://en.wikipedia.org/wiki/HTTP/2#Genesis_in_and_later_dif...](http://en.wikipedia.org/wiki/HTTP/2#Genesis_in_and_later_differences_from_SPDY)

So if they leave SPDY in place along with HTTP 2.0, they could wind up with
strange incompatibilities occurring or site operators feeling like they need
to support both SPDY and the HTTP 2.0 standard (rather than just the HTTP 2.0
standard).

Looking at it, it actually seems more progressive to dump SPDY and move to the
SPDY-based HTTP 2.0 at this stage. Then ten years down the road hopefully SPDY
will be dead and there will just be HTTP/1.1 and HTTP/2.0.

------
Animats
You can probably get a comparable, if not greater, improvement in performance
by using ad and tracker blocking. Most of those extra TCP streams opened when
displaying a web page are for ads and trackers. Those are the ones opening a
TCP connection to send their one-pixel GIF.

~~~
meowface
A modern web browser will not block page loading when making a request for an
image, though. I don't think blocking ads will necessarily improve perceptible
page load time, though obviously it will reduce network traffic.

This does not apply for ad code that's implemented as <script
src="..."></script>, which will indeed block page loading.

~~~
burnte
Try it, the change can be dramatic. Ads have a lot of JS these days.

~~~
meowface
>Ads have a lot of JS these days.

A lot of the ad JS I see is in the form of inline script tags, which generally
should not block anything (the JS usually asynchronously constructs another
script tag, which shouldn't impact performance).

>Try it, the change can be dramatic.

I've been using AdBlock Plus, and now uBlock, for at least 8 years. So I'm
definitely not arguing against it.

It's just that in _theory_ , an ad tracker (like a 1 pixel image) does not
necessarily have to impact performance. Also note that some ad blockers add
performance overhead themselves.

~~~
gsnedders
>A lot of the ad JS I see is in the form of inline script tags, which
generally should not block anything (the JS usually asynchronously constructs
another script tag, which shouldn't impact performance).

Well, it does impact performance, even if it's async. The pipe is only a
finite width (especially on mobile).

------
based2
[https://github.com/netty/netty/tree/master/example/src/main/...](https://github.com/netty/netty/tree/master/example/src/main/java/io/netty/example/http2)

[https://wiki.mozilla.org/Networking/http2](https://wiki.mozilla.org/Networking/http2)

------
josephagoss
Will this affect the way we do AJAX requests? Or the speed of them? Or has
this no impact on websites talking back to the server? My knowledge of
networking at the HTTP level is limited and I am trying to find some context.

~~~
liviu
From source:

"What does this mean for developers?

HTTP/2 was designed from the beginning to be backwards-compatible with
HTTP/1.1. That means developers of HTTP libraries don't have to change APIs,
and the developers who use those libraries won't have to change their
application code. This is a huge advantage: developers can move forward
without spending months bringing previous efforts up to date."

------
Achshar
Why is it limited to operating system version? Shouldn't it be a browser
feature?

~~~
pionar
(Disclaimer: I don't work for MS, so this may not be entirely accurate
anymore.)

It's probably because IE is really just a UI wrapper around system
libraries[0]. The changes for HTTP/2 would be made not in IExplorer.exe, but
instead in WinInet.dll (and possibly URLMon.dll).

This is because IE isn't the only application that will use these new
features.

EDIT: I should add that you don't just go changing system libraries in a patch
Tuesday, you'd wait and throw them in a new version, hence the 10 preview.

[0] [http://msdn.microsoft.com/en-
us/library/aa741312.aspx](http://msdn.microsoft.com/en-
us/library/aa741312.aspx)

------
SFjulie1
DDOS future blackmailers are happy: a new leverage for amplification :)

I want that so bad. Coding is hard, DDoSing is so easy.

Thank you architects for making black hats life so easy. HTTPS by default?
YEESS even more leverage.

I love progress.

Next great idea: implementing ICMP, UDP, routing on top of an OSI layer 7
protocol, because everybody knows religion forbid to open firewall for
protocols that do the jobs, or we could even create new protocols that are not
HTTP. But HTTP for sure is the only true protocol since devs don't know how to
make 3 lines of code for networking and sysadmins don't know how to do their
jobs.

And HTTP is still stateless \o/ wonderful, we still have this wonderful hack
living, cookies, oauth and all these shitty stuff. Central certificate are now
totally discredited, but let's advocate broken stuff even more.

Why not implement a database agnostic layer on top?

When are we gonna stop this cowardly headless rush of stacking poor solutions
and begin solving the root problems?

We are stacking the old problems of GUI (asynch+maintainability+costs) with
the new problem of doing it all other HTTP.

I have a good solution that now seems viable: let's all code in vanilla
Tk/Tcl: it has GUI, it can do HTTP and all, and it works on all environment,
and it is easy to deploy.

Seriously, Tk/Tcl now seems sexy.

------
betimd
It looks to interesting to see Microsoft adopting standards as earliest player
in the field

------
rkrzr
Could somebody elaborate how server push relates to web sockets (if at all)?
Are they completely independent and will both be supported or does one build
on the other?

Given that the web is becoming more and more real-time this seems pretty
interesting.

~~~
wolf550e
server push just means that when a server sees a request for index.html, it
can serve index.html and also index.js and index.css without those being
requested, and when your browser parses the html and discovers it needs the js
and css, they are already in cache and are fresh enough to use, which saves
the round trip latency and might enable a mobile radio to go to sleep earlier.

~~~
0x0
What if the browser already has those in the client cache? Will it have to
abort the pushes, and will it even be able to do so in time on a high
bandwidth high latency network like 3g/4g?

Is there a risk that cellular data usage will increase from this?

~~~
dcsommer
Yes there is. Knowing when a client has a resource cached already is an
important part of server push. There is indeed a risk of over pushing.

------
ck2
Is there a http/2 test page out there that shows if you are connecting with
it?

Found this project but nothing live

[https://github.com/molnarg/http2-testpage](https://github.com/molnarg/http2-testpage)

------
josteink
So this terrible NIHy Rube Goldberg contraption does actually get to see the
light of day.

I'm saddened. The days of good internet protocols are clearly behind us.

~~~
dcsommer
What in particular is bad about HTTP/2? Complexity can arise in protocols for
multiple reasons. In this case, security and correctness are more culpable
than anything else. That is, if you want to design something similarly
performant, you are going to run into a lot of the same issues (flow control
and priorities for fairness, issues with gzip compression, and so on).

~~~
josteink
_What in particular is bad about HTTP /2?_

At the risk of sounding too blunt: Everything? All of it? Its mere existence?

It fucks up responsibilities by addresses network-layering issues at the
application layer. It takes a simple & stateless text-mode protocol and
converts it into a binary & state-full mess.

It has weird micro-optimizations decided to ensure that Google's front-page
and any Google-request with its army of 20000 privacy-invading tracking
cookies should fit within one TCP-packet using American ISPs MTU packet-size,
to ensure people are not inconvenienced when their privacy is being eaten away
at. Which I'm sure is useful to Google, but pretty much nobody else.

The list goes on.

It does a lot of things which is not needed nor asked for by the majority of
the internet, and yet the rest of the internet is asked to pay the cost of it
through a mindboggling increase in complexity, and I'm sure a source of a
million future vulnerabilities.

I'm not aware of a single thing in there which I want, and if I'm wrong and
find one, I'm unwilling to accept that this is the cost I have to pay for that
feature.

Any web-browser I will use in the future will be one where HTTP/2 can be
disabled.

~~~
geographomics
> _It has weird micro-optimizations decided to ensure that Google 's front-
> page and any Google-request with its army of 20000 privacy-invading tracking
> cookies should fit within one TCP-packet using American ISPs MTU packet-
> size, to ensure people are not inconvenienced when their privacy is being
> eaten away at. Which I'm sure is useful to Google, but pretty much nobody
> else._

Could you elaborate on this, please?

~~~
magicalist
I assume josteink is decrying the fact that header compression is used, which
is a pretty ridiculous complaint.

------
ape4
Its way more complicated. But I guess it has to happen.

~~~
angersock
No, it really doesn't _have_ to happen. Some people are just pushing it
through because ~reasons~.

~~~
dcsommer
Reasons being increased performance and security.

~~~
angersock
Security? You mean, like the trusted proxy stuff? Or the increased
performance, which doesn't benefit you so much if you include lots of random
shit from other domains (like most people do anyways)? C'mon.

------
n0body
Do not want

