8 ms·

HTTP/2: The Long-Awaited Sequel

142 points by mattparlane 12y ago

mmastrac 12y ago
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 12y ago
  >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.
- bigbango 12y ago
  > and we need something to improve things now I disagree. Nothing is needed now, HTTP/1 is not broken and it works well enough. There should be time enough to come up with a clean design. Even if it requires designing a new transport protocol. Rolling out a new transport protocol like SCTP takes a lot less time than rolling out a new network protocol like IPv6. Transport protocols only runs on the endpoints, not on the routers in the network. Except for firewalls and NAT'ing home routers, but if HTTP/1 over SCTP would result in a faster better browsing experience the problem would solve itself.
betimd 12y ago
It looks to interesting to see Microsoft adopting standards as earliest player in the field
SFjulie1 12y ago
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.
josephagoss 12y ago
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 12y ago
  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."
- wolf550e 12y ago
  The javascript programmer sees no change, but things work faster. Multiplexing allows many requests in parallel to the same server over a single socket, with the requests completing in the order they are ready, not the order they were requested, which should reduce latencies but might lower your effective bandwidth if you only got that bandwidth because your browser opened many separate connections to the server.
codeka 12y ago
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 12y ago
  HTTP/2 is based on SPDY: http://en.wikipedia.org/wiki/HTTP/2#Genesis_in_and_later_differences_from_SPDY http://en.wikipedia.org/wiki/HTTP/2#Genesis_in_and_later_dif... 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.
- deleted 12y ago
  [deleted]
zaptheimpaler 12y ago
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.html http://chimera.labs.oreilly.com/books/1230000000545/ch12.htm...
- vidarh 12y ago
  > 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. Connections are already processed in parallel whenever they can. That is, when the browser knows what to request, and it fits in the execution model. If there's a huge number of assets on a single hostname, this has been a limiting factor because the browsers have limited the number of requests to a single hostname to avoid overloading the server. But that will remain an issue even if the requests are multiplexed over a single connection. Most of the time when I see graphs in the network inspector that aren't massively parallel it's because nobody have spent time optimizing where/how assets are requested in ways that will make them just as bad with connection multiplexing. There certainly can be benefits to reap from it, but the worst offenders are already ignoring best practices.
  - youngtaff 12y ago
    Multiple parallel connections increases the likelihood of packet loss due to network congestion, is also imposes a larger load on servers and intermediate proxies. A TCP handshake has to take place for each connection and this isn't cost free, and there's the SSL negotiations on top (though techniques like OCSP stapling help) Going massively parallel isn't free - Will Chan of Chrome did a good write up here: https://insouciant.org/tech/network-congestion-and-web-browsing/ https://insouciant.org/tech/network-congestion-and-web-brows...
rkrzr 12y ago
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 12y ago
  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 12y ago
    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 12y ago
      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.
Achshar 12y ago
Why is it limited to operating system version? Shouldn't it be a browser feature?
- jokoon 12y ago
  I'd guess because it's a low level optimization, but I'm not sure.
- spydum 12y ago
  Because they want to entice people to use the windows 10 preview
- pionar 12y ago
  (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
based2 12y ago
https://github.com/netty/netty/tree/master/example/src/main/java/io/netty/example/http2 https://github.com/netty/netty/tree/master/example/src/main/... https://wiki.mozilla.org/Networking/http2 https://wiki.mozilla.org/Networking/http2
ape4 12y ago
Its way more complicated. But I guess it has to happen.
- tkinom 12y ago
  A lot of work for just half of HTTP.
- angersock 12y ago
  No, it really doesn't have to happen. Some people are just pushing it through because ~reasons~.
  - dcsommer 12y ago
    Reasons being increased performance and security.
    - angersock 12y ago
      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.
ck2 12y ago
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
Animats 12y ago
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 12y ago
  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 12y ago
    Try it, the change can be dramatic. Ads have a lot of JS these days.
    - meowface 12y ago
      >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 12y ago
        >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).
josteink 12y ago
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.
- monstermonster 12y ago
  Unfortunately yes. However there were may other bad protocols that died through lack of use. You can still vote with your feet. A vendor will not maintain a protocol stack if people don't use it.
- dcsommer 12y ago
  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 12y ago
    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.
tagrun 12y ago
> 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 12y ago
  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.
n0body 12y ago
Do not want

142 points by mattparlane 12y ago

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 12y ago
>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.
bigbango 12y ago
> and we need something to improve things now I disagree. Nothing is needed now, HTTP/1 is not broken and it works well enough. There should be time enough to come up with a clean design. Even if it requires designing a new transport protocol. Rolling out a new transport protocol like SCTP takes a lot less time than rolling out a new network protocol like IPv6. Transport protocols only runs on the endpoints, not on the routers in the network. Except for firewalls and NAT'ing home routers, but if HTTP/1 over SCTP would result in a faster better browsing experience the problem would solve itself.

betimd 12y ago

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

SFjulie1 12y ago

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.

josephagoss 12y ago

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 12y ago
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."
wolf550e 12y ago
The javascript programmer sees no change, but things work faster. Multiplexing allows many requests in parallel to the same server over a single socket, with the requests completing in the order they are ready, not the order they were requested, which should reduce latencies but might lower your effective bandwidth if you only got that bandwidth because your browser opened many separate connections to the server.

codeka 12y ago

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 12y ago
HTTP/2 is based on SPDY: http://en.wikipedia.org/wiki/HTTP/2#Genesis_in_and_later_differences_from_SPDY http://en.wikipedia.org/wiki/HTTP/2#Genesis_in_and_later_dif... 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.
deleted 12y ago
[deleted]

zaptheimpaler 12y ago

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.html http://chimera.labs.oreilly.com/books/1230000000545/ch12.htm...

vidarh 12y ago
> 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. Connections are already processed in parallel whenever they can. That is, when the browser knows what to request, and it fits in the execution model. If there's a huge number of assets on a single hostname, this has been a limiting factor because the browsers have limited the number of requests to a single hostname to avoid overloading the server. But that will remain an issue even if the requests are multiplexed over a single connection. Most of the time when I see graphs in the network inspector that aren't massively parallel it's because nobody have spent time optimizing where/how assets are requested in ways that will make them just as bad with connection multiplexing. There certainly can be benefits to reap from it, but the worst offenders are already ignoring best practices.
- youngtaff 12y ago
  Multiple parallel connections increases the likelihood of packet loss due to network congestion, is also imposes a larger load on servers and intermediate proxies. A TCP handshake has to take place for each connection and this isn't cost free, and there's the SSL negotiations on top (though techniques like OCSP stapling help) Going massively parallel isn't free - Will Chan of Chrome did a good write up here: https://insouciant.org/tech/network-congestion-and-web-browsing/ https://insouciant.org/tech/network-congestion-and-web-brows...

rkrzr 12y ago

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 12y ago
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 12y ago
  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 12y ago
    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.

Achshar 12y ago

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

jokoon 12y ago
I'd guess because it's a low level optimization, but I'm not sure.
spydum 12y ago
Because they want to entice people to use the windows 10 preview
pionar 12y ago
(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

based2 12y ago

https://github.com/netty/netty/tree/master/example/src/main/java/io/netty/example/http2 https://github.com/netty/netty/tree/master/example/src/main/... https://wiki.mozilla.org/Networking/http2 https://wiki.mozilla.org/Networking/http2

ape4 12y ago

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

tkinom 12y ago
A lot of work for just half of HTTP.
angersock 12y ago
No, it really doesn't have to happen. Some people are just pushing it through because ~reasons~.
- dcsommer 12y ago
  Reasons being increased performance and security.
  - angersock 12y ago
    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.

ck2 12y ago

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

Animats 12y ago

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 12y ago
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 12y ago
  Try it, the change can be dramatic. Ads have a lot of JS these days.
  - meowface 12y ago
    >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 12y ago
      >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).

josteink 12y ago

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.

monstermonster 12y ago
Unfortunately yes. However there were may other bad protocols that died through lack of use. You can still vote with your feet. A vendor will not maintain a protocol stack if people don't use it.
dcsommer 12y ago
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 12y ago
  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.

tagrun 12y ago

> 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 12y ago
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.

n0body 12y ago

Do not want