Your Chrome browser might not be using HTTP anymore | Hacker News Reader

Your Chrome browser might not be using HTTP anymore

igvita.com

214 pointstsycho51 comments

The transparency with which Chrome did this was actually a problem for me. Google Docs/GMail did not work for months on my school's ethernet connection until I read about SPDY being implemented; sure enough, launching Chrome with SPDY disabled fixed the issue, and that requires a command line option. I wish Chrome were less transparent about this and added a few Preferences options, at least.

I don't mean to be pedantic, but the word "transparent", in this context, means "easily perceived or detected". I believe you're using it to mean the opposite.

  > the word "transparent", in this context, means "easily perceived or detected"

This definition doesn't make much sense to me. Transparent objects are less easily perceived/detected than opaque objects. In technology, transparent proxies/compression/encryption are designed to have little/no impact on their contained data.

I think this word uses the assumption that between you and them is an object. If the object is transparent, you can see what they are doing. If it is not, and it is a cloak of some sort, you cannot see what they are doing.

Agreed: "this feature works so transparently that I didn't even know it was there"

Not knowing was a bad thing in this case.

My team often speaks of operating transparently, and by this we mean that management can easily see what we're doing and why. So think about the transparency if actions rather than some object.

Indeed, that is how tiles used the word:

The transparency with which Chrome did this

(but meant the opposite)

This has actually tripped me up a lot. In many figurative contexts, like "transparent government" for instance, transparent means the mechanisms are apparent or not hidden. However, when talking about computer processes or interfaces, it always means quite the opposite, "invisible to the user". So tiles used it correctly when he commented on how SPDY usage was transparent because he (the user) was unaware of it.

Indeed. It's a word that can be perceived in two ways, with radically different meanings. Better to use another one.

Auto-antonyms! http://en.wikipedia.org/wiki/Auto-antonym

Depends. tiles used:

  > The transparency with which Chrome did this
  > was actually a problem for me

"with which Chrome did this" -- to me -- inferred that he was referring to the development group when he said "Chrome" (and also was referring to the process with which they executed said upgrade). This would imply transparency in the 'apparent or not hidden' sense being applied to the Chrome development group and/or the process that they were using.

Just sayin'. The choice of words was a little ambiguous in that it could be taken either way, and that wildly changes the meaning of the word 'transparent.'

Not to be pedantic, but your message should read, "I know I'm being very pedantic, but ..."

commenting on the linguistics here. the reason why this is confusing is that you refer to the way Google did it. transparent behaviour means accountable behaviour.

if you had instead said that "the transparent implementation was a problem for me" people would have been less confused.

Could you please give details about how this broke? What's special about your school internet connection? I tried hard to make SPDY upgrade not break anything and we've had very few reports of problems so I'm very interested in what when wrong in your case.

Email sent; I'll be happy to provide logging information where I can.

For the record, this may reflect my particular Ubuntu installation, or my room's ethernet port, as no other students have had this problem. Good to know I'm an edge case here.

I didn't receive it I'm afraid, not even in spam. Sorry to be a bother. agl at chromium dot org should work. Thanks.

I don't have the same issue as the original poster, but I also experience some issues with SPDY that don't seem to be a problem with HTTP:

For example, my ISP here in Austria drops my IP connection each 8 hours. After reconnecting a new dynamic IP gets assigned to my modem. In addition, the internal network is a NAT and the modem might have some default firewall rules that filter some types of packets.

After a new IP gets assigned to my modem Google applications like GMail typically hang for something like 10-15 minutes. I suspect that Chromium does not recognize that the TCP connection is essentially death and that control information that might tell Chromium that this is the case (TCP Reset replies?) are either not sent by Google or are filtered by my modem.

I have not experienced this issue with other websites yet, although a similar issue should occur when persistent TCP connections are used. Maybe the timeout for persistent TCP connections is lower or it was just a coincidence because I didn't yet surf on a given website will my connection was reset.

If interested I can try to provide some more debugging information or a login to a box within the internal network. See the link in my profile for contact details.

You can peek into your Chrome'ss current SPDY connections (and other interesting internals) in their internal pages:

chrome://net-internals/#events&q=type:SPDY_SESSION%20is:active

Really annoying that they didn't just use SCTP. One commenter on the page points out that it works on top of TCP, which is supported by most routers. This, however, is an entirely artificial limitation. It is a sad fact that this type of artificial restrictions are imposed, and i say that we should fight against them. Having all inet services running over port 80 and TCP does not make the net any safer or better. We as hackers should fight for making people aware of and remove such restrictions, not accept and worsen the crippled situation by working around the problem. This is one of the key problems in the digital world today, too few actually makes an effort to fix the underlying problems. Here Google could play a crucial role, and I must say that I am dissapointed by their choice.

I'm afraid I don't understand this. SCTP is a transaction-level protocol, whilst SPDY works at the application layer, does it not? These choices are orthogonal, not mutually-exclusive, as near as I can tell.

HTTP over SCTP would bring many of the same advantages as HTTP over SPDY over TCP.

Right, that was the part I did understand :-) What I didn't get was why the parent comment was disappointed that Google didn't choose SCTP over SPDY, since no either-or choice is required here. Couldn't SPDY be run over SCTP as well (leaving aside the problems with SCTP that you brought up in your previous comment), albeit with some redundant functionality?

If SPDY were designed to run (only) over SCTP, presumably the redundant functionality wouldn't have been designed in the first place, saving Google's time and yielding a more elegant protocol. At least that's my interpretation.

Network protocols are fractal. Similar but not-quite-identical problems appear at each layer of the stack and wind up being solved in not-quite-identical ways.

Windows doesn't support SCTP. SCTP doesn't pass through any home NATs, and there's no practical way to fix that. Google wants their improvements to actually be used, and SCTP wouldn't be.

(Whatever you do, don't look at the WebSocket handshake...)

If you want to see your SPDY sessions and an abundance of other related information, browse to about:net-internals from a new Chrome tab.

For those interested in playing with SPDY, ruby parser and generator: https://github.com/igrigorik/spdy

An SPDY implementation was recently added to the development version of Go's standard library.

(Not surprising given that agl is also part of the Go team at Google.)

It's a good improvement over HTTP 1.1 and it's nice how they did it in a completely transparent way. Now it's time for the other browsers to support it and to implement way to hint the usage of spdy (maybe a <link rel="" in the first HTTP request, or an extra header in the HTTP request).

Now it's time for the other browsers to support it

Nope, that time would be when there is an RFC

Well, you've plenty of documentation at http://www.chromium.org/spdy just need to push to the IETF.

and get it through the standard process: http://www.ietf.org/about/standards-process.html

No, now is the time to make it an option, not ram it down our throats.

As developers, we need to be able to see things exactly as the people we're developing for who do not always have the luxury of using the latest and greatest browsers.

This is the piss poor attitude that kept us stuck on IE6 for 10 years...

This is the piss poor attitude that makes HN a better place. Not that the other comment was the most clever thing I ever read, but please.

Your comment makes little sense; if my piss poor attitude makes HN a better place than why the downvote and snide remark? What is so clever about yours?

You're suggesting that IE6 gave the user options?

Staying there, wallowing in the mud, is an option, though most of us here wouldn't call it a good one.

Fuck them. Why should I suffer because some people don't know how to use their computers?

Hey, Jonathan, learn to read. I said "optional" and I meant it. A dev needs to be able to turn certain "features" on and off to model how various types of users are going to experience a site. How difficult would it have been to implement that, instead of just forcing down our throats?

Pretty much. Looking at it, there's a lot of things that need to be fleshed out before it's actually ready.

EDIT: The main concern I have over this is that it basically forces a state into an already stateless protocol. Streams need to be established, which means that they need a state(up/down/in-between), and both the server and client(browser, in this case) needs to maintain it.

For example:

1. Should the protocol allow browsers to combine streams? I.e. if a user is accessing 3 different youtube videos in HTML5 mode, can the browser do 1 stream for the various static elements on the page, and 3 or more streams for the video and other content?

This can make the browser feel faster even when loading non-cached pages, so it's definitely desirable. However, it's a lot more work on both the browser and the server to maintain it.

2. What rules are there for streams? The draft states that 1 HTTP request and response should be used per stream, but would it make sense to allow the browser and server to assign streams? How are browser-instantiated streams different from server instantiated ones? Do those need any additional rules?

3. Should SPDY be content agnostic(where a stream is a stream), or would it make sense to have several QoS levels assigned to them(i.e. high for video or other streaming data, medium for control, low for static elements)?

4.(related to 3) Does HTML, CGI, etc. need to be extended to handle this, or should it be left up to the server/browsers to implement it?

Waiting for nginx to support it too.

The link tag is part of HTML, not HTTP. Lots of things besides HTML are transmitted via HTTP.

So what? There's a long history of <link> elements being used for such things, along with the http-equiv attribute for <meta> elements.

Switch to SPDY needs to be done on lower level than HTML, and HTTP/1.1 even happens to have dedicated feature for such case: the `Upgrade` header:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14...

Have you not followed any of the development of the WebSockets protocol and its eventual retraction? It was originally fairly simple and used the Upgrade header that was specified for exactly this sort of thing. Unfortunately, since nobody really used it before, broken implementations in proxies are widespread making it impossible to use without opening up security vulnerabilities.

Sure, http-equiv could be parsed out by the webserver or a proxy and transformed into real headers, but since none of them bothered to do that, the browsers parse them. The end result to the user is largely the same (just that you're unlikely to successfully get a 304). Expecting proxies to do anything intelligent is what's "fundamentally incompatible", not http-equiv.

Right, I forgot that `Upgrade` header requires reuse of the same TCP/IP connection.

It looks like SPDY designers knew what they were doing when they picked custom `Alternate-Protocol` header.

Still, an HTTP header for advertisement seems to me a much better solution than tying protocol negotiation to a markup language (what if I have image-serving CDN or JSON-spitting API?)

I see in spdy-dev archives that SRV DNS records were also considered.

The protocol belongs in the URL like spdy://google.com but this is not backwards compatble.

The Alternate-Protocol HTTP response header indicates that a server supports SPDY. Then on the second request the client will use SPDY instead of HTTP.

http://google.com/search?q=site%3Aycombinator.com+spdy

Does Apache support SPDY?

http://code.google.com/p/mod-spdy/

Reply on news.ycombinator.com