3 ms·

HTTP/2 based on the work of SPDY is upcoming protocol. http://en.wikipedia.org/wiki/HTTP/2 http://en.wikipedia.org/wiki/HTTP/2 HTTP/2 a binary protocol whereas

by frik 11y ago

HTTP/2 based on the work of SPDY is upcoming protocol. http://en.wikipedia.org/wiki/HTTP/2 http://en.wikipedia.org/wiki/HTTP/2 HTTP/2 a binary protocol whereas all other major internet protocols are text based (HTTP0.x, HTTP1.x, POP3, SMTP, IMAP, etc.). https://docs.google.com/presentation/d/1r7QXGYOLCh4fcUq0jDdDwKJWNqWK1o4xMtYpKZCJYjM/present https://docs.google.com/presentation/d/1r7QXGYOLCh4fcUq0jDdD... HTTP/2 requires an SSL certificate. HTTP/2 specification contains a "prioritisation" of data as a hint for the server, instead of the idea of caching data on the client. With the reoccurring "net neutrality" debates, let's hope this protocol cannot be misused/used to prioritize certain packets for parties who pay extra. I am not into this debates, but it would be certainly a disadvantage for startups over established parties. Given the many problems with SSL (heartbeat, broken/outdated certs, hijacked cert vendors) an HTTP/2 without SSL would be a nice fallback scenario - wildcard certs for new startups are still a bit expensive, especially if one will have to replace (=costs) the certs every few months due security concerns. Even the largest commerce website Amazon.com only uses HTTPS for a tiny little fraction, the payment dialog page (which requires with its separate login). It seems HTTP/2 is good for big companies that operate centralized services to save traffic. Whereas the current HTTP 0.x and HTTP 1.x is proven to be good enough for everyone. There is a threat that some popular web services might get HTTP/2-only access in a few years. Maybe the Firefox forks Iceweasel/Fennec/etc and Chromium forks can make the HTTP/2 protocol support an opt-in (and not the other way around).

quonn 11y ago
> With the reoccurring "net neutrality" debates, let's hope this protocol cannot be misused/used to prioritize certain packets for parties who pay extra FUD. There is nothing like that in HTTP/2 and indeed that can't be, because packet routing happens several layers below. If anything, the fact that it's encrypted makes deep packet inspection and content-based routing decisions more difficult. By the way, Amazon.com fully supports HTTPS. I'm using a browser extension to enforce this whenever possible and have browsed Amazon HTTPS-only for years.
- frik 11y ago
  FUD is on your side. Check slide 37 and 38: https://docs.google.com/presentation/d/1r7QXGYOLCh4fcUq0jDdDwKJWNqWK1o4xMtYpKZCJYjM/present?slide=id.gae999cde7_0_86 https://docs.google.com/presentation/d/1r7QXGYOLCh4fcUq0jDdD... "With HTTP/2 browsers prioritize requests based on type/context, and immediately dispatch the request as soon as the resource is discovered. The priority is communicated to the server as weights + dependencies. [...] Responsibility is on the server to deliver the bytes in the right order!" With HTTP/2 a malicious website may send you the advertisement and tracking code first, then wait and later send you the actual content data. With HTTP/1 a browser plugin can decide to not download a advertisement related tracking JS file, simple and effective. Correct me if I am wrong or misunderstood HTTP/2 - but with constructive arguments and sources. Edit: I believe in ads sponsored websites. Ads about the topic of websites are great, though like many I dislike personalized invasive ads that follow me around websites about things I already bought anyway or never will. I would like an "fair"-AdBlocker that only blocks invasive ads and allow the good ads.
  - frankchn 11y ago
    Well, any website today can have some JavaScript that verifies that ads and tracking cookies are loaded and executed before actual content loads. If the advertisement is not shown successfully, then the script can refuse to load the content too. I am also not sure how stream prioritization will affect Ghostery, AdBlock or other browser plugins. Is there any evidence that these plug-ins are not able to do things in HTTP/2 (e.g. blocking URLs, domains, preventing DOM elements from showing up, deleting cookies, etc...) that they could in HTTP/1? I would be interested to know.
  - quonn 11y ago
    Yes, you have completely misunderstood this. HTTP/2 provides you with a mechanism to optimize traffic _within your own connection_. This is not at all related to the net neutrality debate where your ISP determines a priority _between different connections_. Furthermore, ad blockers currently work with blacklisted hostnames. Even with HTTP 1.1 the data could be sent from the main server, but usually it is sent from 3rd-party servers, which makes blocking easier. This is the same for HTTP/2 and completely unrelated.
frankchn 11y ago
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.

by frik 11y ago

quonn 11y ago

> With the reoccurring "net neutrality" debates, let's hope this protocol cannot be misused/used to prioritize certain packets for parties who pay extra FUD. There is nothing like that in HTTP/2 and indeed that can't be, because packet routing happens several layers below. If anything, the fact that it's encrypted makes deep packet inspection and content-based routing decisions more difficult. By the way, Amazon.com fully supports HTTPS. I'm using a browser extension to enforce this whenever possible and have browsed Amazon HTTPS-only for years.

frik 11y ago
FUD is on your side. Check slide 37 and 38: https://docs.google.com/presentation/d/1r7QXGYOLCh4fcUq0jDdDwKJWNqWK1o4xMtYpKZCJYjM/present?slide=id.gae999cde7_0_86 https://docs.google.com/presentation/d/1r7QXGYOLCh4fcUq0jDdD... "With HTTP/2 browsers prioritize requests based on type/context, and immediately dispatch the request as soon as the resource is discovered. The priority is communicated to the server as weights + dependencies. [...] Responsibility is on the server to deliver the bytes in the right order!" With HTTP/2 a malicious website may send you the advertisement and tracking code first, then wait and later send you the actual content data. With HTTP/1 a browser plugin can decide to not download a advertisement related tracking JS file, simple and effective. Correct me if I am wrong or misunderstood HTTP/2 - but with constructive arguments and sources. Edit: I believe in ads sponsored websites. Ads about the topic of websites are great, though like many I dislike personalized invasive ads that follow me around websites about things I already bought anyway or never will. I would like an "fair"-AdBlocker that only blocks invasive ads and allow the good ads.
- frankchn 11y ago
  Well, any website today can have some JavaScript that verifies that ads and tracking cookies are loaded and executed before actual content loads. If the advertisement is not shown successfully, then the script can refuse to load the content too. I am also not sure how stream prioritization will affect Ghostery, AdBlock or other browser plugins. Is there any evidence that these plug-ins are not able to do things in HTTP/2 (e.g. blocking URLs, domains, preventing DOM elements from showing up, deleting cookies, etc...) that they could in HTTP/1? I would be interested to know.
- quonn 11y ago
  Yes, you have completely misunderstood this. HTTP/2 provides you with a mechanism to optimize traffic _within your own connection_. This is not at all related to the net neutrality debate where your ISP determines a priority _between different connections_. Furthermore, ad blockers currently work with blacklisted hostnames. Even with HTTP 1.1 the data could be sent from the main server, but usually it is sent from 3rd-party servers, which makes blocking easier. This is the same for HTTP/2 and completely unrelated.

frankchn 11y ago

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.