How HTTP/2 will make the Web Faster
-
@thecreativeone91 said:
Hopefully it's backwards compatible
Quote: The primary objective of HTTP/2 is to maintain high-level compatibility with HTTP/1.1, while decreasing latency.
-
HTTP 2 will replace SPDY as well, thankfully:
Since late 2009 Google has been developing an experimental protocol called SPDY (pronounced speedy). SPDY is a trademark of Google and not an acronym. HTTP/2 was originally based on the SPDY experiment. In fact, many SPDY core developers were involved in the development of HTTP/2. As of February 2015, Google announced support for SPDY would be deprecated in favor of HTTP/2 and then completely withdrawn in 2016.
-
-
-
HTTP 2 is stateful, which is a huge change. Something that we have really needed.
-
won't this make proxy servers harder and need more resources? Granted anymore I'd rather use lightweight dns filtering.
-
@thecreativeone91 said:
won't this make proxy servers harder and need more resources? Granted anymore I'd rather use lightweight dns filtering.
Harder, yes. Need more resources, no. Should need less.
-
Wouldn't this make things like DDOS attacks easier? Since the connection remains open for what I assume is additional content.
-
@coliver said:
Wouldn't this make things like DDOS attacks easier? Since the connection remains open for what I assume is additional content.
Harder, because the client can close the connection and refuse more. Only a little harder, but harder. Nothing can force the client to keep it open.
-
@thecreativeone91 said:
won't this make proxy servers harder and need more resources? Granted anymore I'd rather use lightweight dns filtering.
Why would you need more resources? Assuming the connection is not encrypted everything works exactly like it does today, and those that are encrypted already can't use proxies (unless you install a cert to cause a man in the middle) nor can you use caching servers... that's probably the worst part about encryption.
-
@Dashrender said:
@thecreativeone91 said:
won't this make proxy servers harder and need more resources? Granted anymore I'd rather use lightweight dns filtering.
Why would you need more resources? Assuming the connection is not encrypted everything works exactly like it does today, and those that are encrypted already can't use proxies (unless you install a cert to cause a man in the middle) nor can you use caching servers... that's probably the worst part about encryption.
More activity going on at once with http2 and more open connections.
-
This is all well and good, but surely we're going to bring back gopher right? I mean, I see all those people on SW talking about how web based apps are sort of a fad and people will want to go back to using clunky ass installers requiring libraries and also keeping all that up to date. So surely, maybe HTTP/2.0 is almost here, but the real hardcore, super serious users will want to use gopher, right? I mean it will offer "more control" over something or something.
-
@tonyshowoff said:
This is all well and good, but surely we're going to bring back gopher right? I mean, I see all those people on SW talking about how web based apps are sort of a fad and people will want to go back to using clunky ass installers requiring libraries and also keeping all that up to date. So surely, maybe HTTP/2.0 is almost here, but the real hardcore, super serious users will want to use gopher, right? I mean it will offer "more control" over something or something.
Why don't we just make all applications in Machine code while were at it. Who needs to deal with the OS or frameworks. Just manage it all.
-
@thecreativeone91 said:
Why don't we just make all applications in Machine code while were at it. Who needs to deal with the OS or frameworks. Just manage it all.
That's the way nature intended, and enough already with this damn Internet fad, BBSes had a real sense of community, so let's turn off the Internet and go back to what truly matters... and 16bit.
