3 ms·

I don't see how the stream priority feature of HTTP/2 affects "net neutrality" at all, since it only affects stream prioritization behavior within one TCP conne

I don't see how the stream priority feature of HTTP/2 affects "net neutrality" at all, since it only affects stream prioritization behavior within one TCP connection. If ISPs decided to slow down or speed up certain traffic, they would just modify the QoS for the entire TCP connection based on source and destination IPs -- no need for Layer 7 parsing. Also, since HTTP/2 requires TLS, ISPs can't read the stream priority (or anything else within the stream) even if they wanted to. Also, HTTPS costs should be minimal for startups (in fact, they should be more significant if you are the size of Amazon). For instance, if you use Amazon Cloudfront, the price difference between serving one million requests over HTTPS vs one million requests over regular HTTP is at most 60 cents in any AWS region.

frik 11y ago
Binary HTTP/2 headers can be parsed a lot faster than plain text (HTTP0.x/1.x), so the packets can be prioritized depending on the content. Sure the routing has happened in another OSI layer, but nowadays a lot of packet inspection is done by certain ISPs & co. Not an argument for or against it, but we know from the news that for example Google has to pay ISPs in France for their Youtube traffic, the same goes for Netflix. But I don't want to start a discussion about that topic, it was just one of many arguments about HTTP/2. We should stay on topic and write about HTTPS-only or HTTP/2 which requires an SSL certificate.
- frankchn 11y ago
  But if HTTP/2 requires TLS, then ISP can't read the traffic in any case right? I don't think parsing is a main concern here. Also, If the Google.fr deal is anything similar to the Comcast-Netflix deal here in the United States, then it has nothing to do with protocols, TLS or even (by some definitions) net neutrality. Basically, Comcast asked (and got!) money from Netflix to install (additional?) peering connections between Comcast and Netflix. Comcast doesn't even need to throttle packets deliberately (i.e. explicitly violate net neutrality) to ensure that its customers have a bad experience, the congestion at the then-existing peering points would have guaranteed that. At the end of the day, it doesn't matter what protocol we use, if you have many many bits to deliver to lots of people on somebody else's network, that middleman who owns the destination network might price-gouge you.
- rakoo 11y ago
  > so the packets can be prioritized depending on the content No they can't because HTTP/2 frames are unreadable (they're encrypted). An ISP can prioritize whole streams, but not individual frames inside the stream.
- pdkl95 11y ago
  > Binary HTTP/2 headers can be parsed a lot faster than plain text Any advantage in parsing speed that binary has is going to be so small that it won't matter. On modern out-of-order, speculatively executing hardware, wasted CPU times usually mis-predicted branches and waiting for data to be loaded into the L1 cache. The handful of extra instructions to convert an integer from ASCII to a register-sized-int is minimal, and can be "free" if it fits in the L1 cache. > (HTTP0.x/1.x) There's you're problem - HTTP/1.x was not designed to be fast; it was designed to allow simple implementations (most headers can be ignored) and arbitrary ad-hoc extensions. It is entirely possible to make a replacement for HTTP that is much faster to parse than HTTP/1.1. A protocol being "text base" is orthogonal to that protocol allowing annoying-to-parse arbitrary size fields. A binary protocol can be just as slow to parse if it is badly designed.

frik 11y ago

Binary HTTP/2 headers can be parsed a lot faster than plain text (HTTP0.x/1.x), so the packets can be prioritized depending on the content. Sure the routing has happened in another OSI layer, but nowadays a lot of packet inspection is done by certain ISPs & co. Not an argument for or against it, but we know from the news that for example Google has to pay ISPs in France for their Youtube traffic, the same goes for Netflix. But I don't want to start a discussion about that topic, it was just one of many arguments about HTTP/2. We should stay on topic and write about HTTPS-only or HTTP/2 which requires an SSL certificate.

frankchn 11y ago
But if HTTP/2 requires TLS, then ISP can't read the traffic in any case right? I don't think parsing is a main concern here. Also, If the Google.fr deal is anything similar to the Comcast-Netflix deal here in the United States, then it has nothing to do with protocols, TLS or even (by some definitions) net neutrality. Basically, Comcast asked (and got!) money from Netflix to install (additional?) peering connections between Comcast and Netflix. Comcast doesn't even need to throttle packets deliberately (i.e. explicitly violate net neutrality) to ensure that its customers have a bad experience, the congestion at the then-existing peering points would have guaranteed that. At the end of the day, it doesn't matter what protocol we use, if you have many many bits to deliver to lots of people on somebody else's network, that middleman who owns the destination network might price-gouge you.
rakoo 11y ago
> so the packets can be prioritized depending on the content No they can't because HTTP/2 frames are unreadable (they're encrypted). An ISP can prioritize whole streams, but not individual frames inside the stream.
pdkl95 11y ago
> Binary HTTP/2 headers can be parsed a lot faster than plain text Any advantage in parsing speed that binary has is going to be so small that it won't matter. On modern out-of-order, speculatively executing hardware, wasted CPU times usually mis-predicted branches and waiting for data to be loaded into the L1 cache. The handful of extra instructions to convert an integer from ASCII to a register-sized-int is minimal, and can be "free" if it fits in the L1 cache. > (HTTP0.x/1.x) There's you're problem - HTTP/1.x was not designed to be fast; it was designed to allow simple implementations (most headers can be ignored) and arbitrary ad-hoc extensions. It is entirely possible to make a replacement for HTTP that is much faster to parse than HTTP/1.1. A protocol being "text base" is orthogonal to that protocol allowing annoying-to-parse arbitrary size fields. A binary protocol can be just as slow to parse if it is badly designed.