Making the Web Faster with HTTP 2 Protocol
phpclasses.org
Making the Web Faster with HTTP 2 Protocol
1–10 of 20 posts
Re: Making the Web Faster with HTTP 2 Protocol
#2With 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?
Re: Making the Web Faster with HTTP 2 Protocol
#3With 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…
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.
Re: Making the Web Faster with HTTP 2 Protocol
#4With 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…
I understood the article said that SPDY would be the next version of HTTP 2.0, just standarized and not in control of Google (in theory). Which makes a lot of sense, for both server and browser implementors, and Google. I guess they wouldn't want to be the next Microsoft, not on purpose at least.
Re: Making the Web Faster with HTTP 2 Protocol
#5I 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.
Re: Making the Web Faster with HTTP 2 Protocol
#6With 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…
SPDY is overrated and only has traction because Google decided to make it. So far the data shows that the severely limited gains it provides, it provides at the cost of significant complexity.
I sure as hell could appreciate a new HTTP-standard, which was brought to the field by having professionals (maybe even IETF!) work together and reason about things publically, not just have Google hijack the process, dump shit out, saying "that's what we have implemented. if you want to compete with us, you will have to take this package", and then after the fact release some docs and claim it's open.
You know. SPDY just smells bad wherever you look. I'd like for the new HTTP protocol to be something you can trust
Re: Making the Web Faster with HTTP 2 Protocol
#7> 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?
Re: Making the Web Faster with HTTP 2 Protocol
#8With 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…
HTTP 2.0 has been in the works for a long time. It's picked up again recently, after the HTTP-NG working group disbanded in 1998. The working group will take some features that SPDY has shown to be useful and stable and integrate them into the spec. They are also looking at parts of Microsoft's "Speed and Mobility" protocol.
Re: Making the Web Faster with HTTP 2 Protocol
#9> 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?
Maybe close the connection when it hasn't been used for a while?
Re: Making the Web Faster with HTTP 2 Protocol
#10With 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…
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…
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.)