Awesome article. I feel like the most game changing part of chrome is that Google turned it into a web app, that is it is always up to date and you never have to install anything (compared to the mess that is IE 7-10). Everyone gets the next network improvements / security fixes. It is so simple and mind boggling at the same time. I know this isn't the main point of the article, but dealing with microsoft stuff recently really hammers this point home.
Here is another optimization every browser could (and should) take advantage of, but currently does not: <a href="http://igorpartola.com/programming/how-browsers-should-connect-to-web-servers" rel="nofollow">http://igorpartola.com/programming/how-browsers-should-conne...</a><p>Basically, if there are multiple IP's behind a hostname, connect a non-blocking socket to each, then do a select/poll/epoll/kqueue on all of them. Then, once at least one returns, immediately close the rest and use the newly established connection.<p>This has three nice side-effects. First, if one of the hosts is down, it will never be selected, unlike now when there is a 1 in N chance that you'll be stuck waiting for a very long time. Second, you don't need to explicitly check whether the IPv4 vs IPv6 stacks are operational. A connection that is returned to you is the one that works, regardless of the underlying protocol. Third, this provides crude load balancing. Presumably the host that connected the fastest is also the fastest to process your request. The my blog post for some numbers.
Ilya has never disappointed me with any of his articles. They are always top notch, and this one is no exception. As a Chrome user, seeing how things work behind the scenes (and why) is fascinating!
Interesting note that the network stack is implemented "as a mostly single-threaded (there are separate cache and proxy threads), cross-platform library."<p>I wonder if someone could extract that lib into its own project. It would be great to have a version of AFNetworking or Python's requests library built on top of this -- in order to take advantage of the advanced socket reuse and late binding stuff that he describes in the article.<p>But that's all without really looking at the code. Maybe there's just too much Chrome-specific stuff there.
Great article. Chrome is an amazing piece of software.<p>Talking about web browsers, I can't wait for the next big step. Mozilla and Google are already moving ahead: When web browsers become the whole OS. With web apps becoming fully capable, and with native apps increasingly network integrated, the distinction is becoming meaningless.<p>In that vision of web browsers as OSs, there is a big limitation. More than some still incomplete APIs, or a few ones still missing, the problem is the whole development story. Web development is still a chaos. The web platform, is a soup with far too many ingredients. Why we still have to develop application's UIs, using a document markup engine?.<p>The web is rich. There are all kinds of resources. It is non-sense to express all of these resources, with a single development paradigm: html-css-javascript. Native development, is more flexible. There is the possibility of choosing the right tool for the job. I hope that one day not so far away, browsers will gain similar capabilities. Support for multiple separated, specialized development environments.
Ot here, the network might be high performance but the socket API in Chrome need some fix.<p><a href="https://code.google.com/p/chromium/issues/detail?id=170595" rel="nofollow">https://code.google.com/p/chromium/issues/detail?id=170595</a><p>the chrome.socket API is really awesome, it can listen to tcp/udp connections, works like a mini NodeJS. It's a shame they didn't make it more stable.
I am wondering about the kernel piece. Does Chrome on Windows have any code that is loaded in the kernel? I'd be quite surprised if they did. Any Chrome expert know?