6 ms·

High Performance Networking in Google Chrome

216 points by igrigorik 14y ago

eliben 14y ago
AOSA are very nice books. It's exciting that another (POSA) is coming.
- No1 14y ago
  They really need another acronym. I thought you meant another POSA[1] is coming. [1] http://www.cs.wustl.edu/~schmidt/POSA/ http://www.cs.wustl.edu/~schmidt/POSA/
  - eliben 14y ago
    Good point. I hate it when folks make up names and acronyms without checking first for existing work, at least in related areas.
ErikRogneby 14y ago
This pre-fetching behavior reminds me of Amazon Silk. However Silk leverages EC2, vs. doing all of the analytics locally.
robotmay 14y ago
Ilya always writes the best performance articles. Really nicely organised page too.
ajtaylor 14y ago
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!
- ajtaylor 14y ago
  After processing the full article, I'm completely amazed at all the extreme lengths Chrome goes employs to speed page loading. From the networking stack, with it's abundance of optimisations and resource reuse, to the massive (and slightly scary) intelligence of the predictions stack, it all combines to make one heck of a browser! Even if Chrome had only 10% of its current features, I appreciate the fact that it provided competition into the browser market and spurred innovation by _everyone_. The benefit to the internet community as a whole is tremendous.
newman314 14y ago
Great article but I wish some discussion would have been directed at the security implications of all this prefetching.
- simonw 14y ago
  Can you expand on this a little - do you know of any particular security concerns with prefetching?
  - newman314 14y ago
    IIRC, there are issues with leaking URLs just as with OCSP lookups. So it's more privacy related than security. I was in a hurry when I typed that earlier. But if you think about it, there's still a chance of sending company internal URLs to a third party which given enough data would start to build up a view of the intranet. We have no idea if google then feeds this into their crawler to get more of the hidden web and if there is a misconfiguration elsewhere would then cause results to be publicly visible. See posts about visible printers etc. in the last couple of days.
    - hobohacker 14y ago
      Chromium builds predictive models which are stored client-side. They are not uploaded to a third party server, like Google.
- easytiger 14y ago
  how is it any different that fully, manually fetching everything? Surely the only difference in psychological as per
est 14y ago
Ot here, the network might be high performance but the socket API in Chrome need some fix. https://code.google.com/p/chromium/issues/detail?id=170595 https://code.google.com/p/chromium/issues/detail?id=170595 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.
- kinlan 14y ago
  I coded that demo, it is not the Chrome Socket API that is the problem, it is that I don't error properly in the code and it blocks the port like any socket server would.
  - est 14y ago
    Thanks for the demo How to catch that error? There's no exception callback in the doc http://developer.chrome.com/apps/socket.html http://developer.chrome.com/apps/socket.html And if the port is already blocked, how to recover?
harshaw 14y ago
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.
- alyx 14y ago
  IE 10 is auto updated as part of Windows Update, is that too messy too?
  - SigmundA 14y ago
    Requires Win7 SP1 higher first. Chrome only needs WinXP SP2, while still supporting Mac and Linux. This is a big deal at least with my customers. It's just silly that Chrome has broader Windows support than IE. IE should not be so dependent on the base OS.
  - harshaw 14y ago
    I am sure IE10 support will be better but MS is burdened by their decision to limit IE9+ to windows 7 and newer. I read through the MS article on their new automatic upgrade policy and it seems mostly focused on security (for good reason). What is clear is that the chrome development organization is built to release all the time in perpetuity (just like web, mobile development). Not sure this is true for MS.
  - mbell 14y ago
    That depends - Is IE10 one of the many components in Windows that obnoxiously requires the entire system to reboot after an update?
  - arocks 14y ago
    Needing to reboot after installing an update or being nagged to death about it, that is definitely messy.
  - 14y ago
steeve 14y ago
Ilya Grigorik delivers, again.
nzonbi 14y ago
Great article. Chrome is an amazing piece of software. 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. 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?. 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.
- chipsy 14y ago
  I think the necessary reworking is going to happen, but it will take a few cycles through the "Wheel of Reincarnation" to make it fully realized - with the rendering example, we now have Canvas and WebGL; instead of relying on the browser, you can create something completely customized, with the downside being that many of the supporting features of the document-renderer paradigm are lost. But it's the right technology for certain kinds of applications, and others can be rebuilt on top of that, and eventually you'll get frameworks, and so on. At each step, not everyone will be 100% happy with how things are organized, but enough of it will work that it expands the frontier of what kinds of software can be built on the web. We've been through this before - the web has worked because its paradigms keep getting stretched beyond expectations.
jadc 14y ago
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?
- ramidarigaz 14y ago
  I don't believe he actually means the OS Kernel. It's a userspace "kernel" in that it coordinates the traffic and behavior for all of the subprocesses.
  - igrigorik 14y ago
    Right. The "browser kernel" process, which is the coordinator for all the network activity, and a dozen other things.
sparx 14y ago
awesome reading. other posts by Ilya Grigorik are great too.
boringguy 14y ago
Reading this @ FF :)
timc3 14y ago
Wonderful wonderful article. Is there somewhere I could pre-order the book (which would be the first time that I have ever done so).
ericflo 14y ago
Interesting note that the network stack is implemented "as a mostly single-threaded (there are separate cache and proxy threads), cross-platform library." 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. But that's all without really looking at the code. Maybe there's just too much Chrome-specific stuff there.
- igrigorik 14y ago
  It already exists! And works very well! Check it out: http://code.google.com/p/chromiumembedded/ http://code.google.com/p/chromiumembedded/
- hobohacker 14y ago
  This comes up periodically on chromium-dev. I've answered it here: https://groups.google.com/a/chromium.org/d/msg/chromium-dev/1Aiayto6hn0/xPb0VCSvTt8J https://groups.google.com/a/chromium.org/d/msg/chromium-dev/.... In short, we don't want to support other consumers, sorry. Feel free to do code drops, they should work fine.
IgorPartola 14y ago
Here is another optimization every browser could (and should) take advantage of, but currently does not: http://igorpartola.com/programming/how-browsers-should-connect-to-web-servers http://igorpartola.com/programming/how-browsers-should-conne... 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. 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.
- igrigorik 14y ago
  Yup! In fact, I didn't cover it in the writeup, but Chrome and other browsers already do this kind of thing on multiple layers: IPv4 and IPv6 (see Happy Eyeballs), plus to recover from lost SYN's.
  - IgorPartola 14y ago
    Interesting. One of the apps I run is split between two servers. When I was bringing everything up, if one of the severs was down there was always a 50% chance of about a 40 second blank screen before the other server was picked up. If the server that was chosen was in the DNS cache, there was a 100% chance of blank screen. Admittedly, this was about 2 years ago, so things might have changed, but the reliability properties didn't seem to be there at the time.
- hobohacker 14y ago
  We've considered this before, and the performance gains do not appear worthwhile (we've run much more extensive tests than you have on top websites to evaluate potential gains), it has extra complexity, it is more of a Hampering Eyeballs approach rather than a Happy Eyeballs approach, it has potential web compat issues (many sites will not expect you to connect to the IPs other than the first), etc etc.

216 points by igrigorik 14y ago

eliben 14y ago

AOSA are very nice books. It's exciting that another (POSA) is coming.

No1 14y ago
They really need another acronym. I thought you meant another POSA[1] is coming. [1] http://www.cs.wustl.edu/~schmidt/POSA/ http://www.cs.wustl.edu/~schmidt/POSA/
- eliben 14y ago
  Good point. I hate it when folks make up names and acronyms without checking first for existing work, at least in related areas.

ErikRogneby 14y ago

This pre-fetching behavior reminds me of Amazon Silk. However Silk leverages EC2, vs. doing all of the analytics locally.

robotmay 14y ago

Ilya always writes the best performance articles. Really nicely organised page too.

ajtaylor 14y ago

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!

ajtaylor 14y ago
After processing the full article, I'm completely amazed at all the extreme lengths Chrome goes employs to speed page loading. From the networking stack, with it's abundance of optimisations and resource reuse, to the massive (and slightly scary) intelligence of the predictions stack, it all combines to make one heck of a browser! Even if Chrome had only 10% of its current features, I appreciate the fact that it provided competition into the browser market and spurred innovation by _everyone_. The benefit to the internet community as a whole is tremendous.

newman314 14y ago

Great article but I wish some discussion would have been directed at the security implications of all this prefetching.

simonw 14y ago
Can you expand on this a little - do you know of any particular security concerns with prefetching?
- newman314 14y ago
  IIRC, there are issues with leaking URLs just as with OCSP lookups. So it's more privacy related than security. I was in a hurry when I typed that earlier. But if you think about it, there's still a chance of sending company internal URLs to a third party which given enough data would start to build up a view of the intranet. We have no idea if google then feeds this into their crawler to get more of the hidden web and if there is a misconfiguration elsewhere would then cause results to be publicly visible. See posts about visible printers etc. in the last couple of days.
  - hobohacker 14y ago
    Chromium builds predictive models which are stored client-side. They are not uploaded to a third party server, like Google.
easytiger 14y ago
how is it any different that fully, manually fetching everything? Surely the only difference in psychological as per

est 14y ago

Ot here, the network might be high performance but the socket API in Chrome need some fix. https://code.google.com/p/chromium/issues/detail?id=170595 https://code.google.com/p/chromium/issues/detail?id=170595 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.

kinlan 14y ago
I coded that demo, it is not the Chrome Socket API that is the problem, it is that I don't error properly in the code and it blocks the port like any socket server would.
- est 14y ago
  Thanks for the demo How to catch that error? There's no exception callback in the doc http://developer.chrome.com/apps/socket.html http://developer.chrome.com/apps/socket.html And if the port is already blocked, how to recover?

harshaw 14y ago

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.

alyx 14y ago
IE 10 is auto updated as part of Windows Update, is that too messy too?
- SigmundA 14y ago
  Requires Win7 SP1 higher first. Chrome only needs WinXP SP2, while still supporting Mac and Linux. This is a big deal at least with my customers. It's just silly that Chrome has broader Windows support than IE. IE should not be so dependent on the base OS.
- harshaw 14y ago
  I am sure IE10 support will be better but MS is burdened by their decision to limit IE9+ to windows 7 and newer. I read through the MS article on their new automatic upgrade policy and it seems mostly focused on security (for good reason). What is clear is that the chrome development organization is built to release all the time in perpetuity (just like web, mobile development). Not sure this is true for MS.
- mbell 14y ago
  That depends - Is IE10 one of the many components in Windows that obnoxiously requires the entire system to reboot after an update?
- arocks 14y ago
  Needing to reboot after installing an update or being nagged to death about it, that is definitely messy.
- 14y ago

steeve 14y ago

Ilya Grigorik delivers, again.

nzonbi 14y ago

Great article. Chrome is an amazing piece of software. 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. 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?. 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.

chipsy 14y ago
I think the necessary reworking is going to happen, but it will take a few cycles through the "Wheel of Reincarnation" to make it fully realized - with the rendering example, we now have Canvas and WebGL; instead of relying on the browser, you can create something completely customized, with the downside being that many of the supporting features of the document-renderer paradigm are lost. But it's the right technology for certain kinds of applications, and others can be rebuilt on top of that, and eventually you'll get frameworks, and so on. At each step, not everyone will be 100% happy with how things are organized, but enough of it will work that it expands the frontier of what kinds of software can be built on the web. We've been through this before - the web has worked because its paradigms keep getting stretched beyond expectations.

jadc 14y ago

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?

ramidarigaz 14y ago
I don't believe he actually means the OS Kernel. It's a userspace "kernel" in that it coordinates the traffic and behavior for all of the subprocesses.
- igrigorik 14y ago
  Right. The "browser kernel" process, which is the coordinator for all the network activity, and a dozen other things.

sparx 14y ago

awesome reading. other posts by Ilya Grigorik are great too.

boringguy 14y ago

Reading this @ FF :)

timc3 14y ago

Wonderful wonderful article. Is there somewhere I could pre-order the book (which would be the first time that I have ever done so).

ericflo 14y ago

Interesting note that the network stack is implemented "as a mostly single-threaded (there are separate cache and proxy threads), cross-platform library." 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. But that's all without really looking at the code. Maybe there's just too much Chrome-specific stuff there.

igrigorik 14y ago
It already exists! And works very well! Check it out: http://code.google.com/p/chromiumembedded/ http://code.google.com/p/chromiumembedded/
hobohacker 14y ago
This comes up periodically on chromium-dev. I've answered it here: https://groups.google.com/a/chromium.org/d/msg/chromium-dev/1Aiayto6hn0/xPb0VCSvTt8J https://groups.google.com/a/chromium.org/d/msg/chromium-dev/.... In short, we don't want to support other consumers, sorry. Feel free to do code drops, they should work fine.

IgorPartola 14y ago

Here is another optimization every browser could (and should) take advantage of, but currently does not: http://igorpartola.com/programming/how-browsers-should-connect-to-web-servers http://igorpartola.com/programming/how-browsers-should-conne... 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. 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.

igrigorik 14y ago
Yup! In fact, I didn't cover it in the writeup, but Chrome and other browsers already do this kind of thing on multiple layers: IPv4 and IPv6 (see Happy Eyeballs), plus to recover from lost SYN's.
- IgorPartola 14y ago
  Interesting. One of the apps I run is split between two servers. When I was bringing everything up, if one of the severs was down there was always a 50% chance of about a 40 second blank screen before the other server was picked up. If the server that was chosen was in the DNS cache, there was a 100% chance of blank screen. Admittedly, this was about 2 years ago, so things might have changed, but the reliability properties didn't seem to be there at the time.
hobohacker 14y ago
We've considered this before, and the performance gains do not appear worthwhile (we've run much more extensive tests than you have on top websites to evaluate potential gains), it has extra complexity, it is more of a Hampering Eyeballs approach rather than a Happy Eyeballs approach, it has potential web compat issues (many sites will not expect you to connect to the IPs other than the first), etc etc.