

Making the Web Faster with HTTP 2 Protocol - rvavruch
http://www.phpclasses.org/blog/post/182-Making-the-Web-Faster-with-HTTP-2-Protocol.html

======
viraptor
With all the buzz already surrounding SPDY and the number of existing
implementations out there... what are the chances that HTTP-2.0 will simply
never get the traction it needs for real applications?

I mean SPDY is here and almost every server can handle it already. (where can
!= is configured to by default) If google pulls features from HTTP-2.0 into
SPDY-1.x in the next couple of months, what would be the benefit of anyone
doing HTTP-2.0?

~~~
pilif
It is my understanding that it's very likely that HTTP 2.0 will be SPDY -
maybe with some added extensions, but the basis will be SPDY.

A clear case where a working and apparently perfectly well backwards
compatible vendor-specific implementation worked so well that it actually
might get to be an official standard.

Now if only we could have SSL with name based virtual hosts or much wider use
of IPv6 so that SPDY will actually be useful for a wide range of server
administrators.

~~~
aaronblohowiak
We wouldn't need SSL with name-based virtual hosts if web browsers could use
SRV records (and thus connect to different ports, so the server would know
which cert to cough up without requiring the name.)

~~~
kelnos
This doesn't really scale. Every SSL-protected vhost then needs its own port
on the server. In current practice there are probably plenty of free ports,
but it just seems like a poor choice overall.

(Regardless, as I mentioned above, name-based vhosts work just fine with
HTTPS, using SNI. Much easier to fill in the gaps in browser support for SNI
than to get everyone to adopt SRV records.)

------
dmak
"Another aspect of concern is the implementation of server push of resources
that were already cached by the browsers. Mobile applications may also not
want to retrieve some resources that the server may assume they want to
download. So the criticism is that preemptive server push may end up being an
undesirable thing."

Why is it "preemptive"? It seems more like a nonpreemptive push, right?

------
chime
> If the user closes the browser tab and no other pages from the same site are
> opened, the browser may send an explicit request to end the connection, so
> it does not keep tying the server.

Does this mean keeping a background tab open uses a remote server's resources
indefinitely? How can I as the server dev prevent unintentional DDOS?

~~~
mtigas
Haven't looked at the SPDY spec[1] too closely, but I think each side of the
SPDY (or underlying TCP) connection would be able to idle-disconnect after a
timeout or during a high-load situation. (i.e. to prevent idle connections
from consuming ports/file descriptors)

So in the case you quoted, the server would _also_ be able to explicitly tell
the browser to start a new connection later. (It's not just a browser-to-
server signal.)

Generally, most HTTP 1.1 (keepalive-aware) servers have a default timeout for
those "persistent" connections[2][3] so this isn't actually a new problem
specific to SPDY.

(Aside: simply consuming leaving open an idle TCP connection for later re-use
doesn't necessarily imply that idle users will "DDOS" a server. Depending on
the server software and OS, the cost-per-socket is low enough that many idle
connections isn't actually a problem until you get to port and file descriptor
limits — which, again, is already well-dealt with in plenty of other HTTP/TCP
applications by using timeouts _at all_.)

[1]: <http://www.chromium.org/spdy/spdy-protocol> [2]:
<http://wiki.nginx.org/HttpCoreModule#keepalive_timeout> [3]:
[https://httpd.apache.org/docs/2.2/mod/core.html#keepalivetim...](https://httpd.apache.org/docs/2.2/mod/core.html#keepalivetimeout)

------
zafriedman
I was so close to not opening this because the source is a website with the
name 'PHP' in it... but I'm glad I did, nice article.

