A bunch of people have asked me what I work on at Google these days. When I joined Google last July in the Cambridge office, I worked with the team that runs Google’s content delivery network, which is responsible for caching a vast amount of (mostly video) content at many sites around the world. It is a fantastic project with some great people. My own work focused on building tools to measure and evaluate wide-area network performance and detect performance problems. This was a great “starter project,” and I got to build and deploy some pretty large systems that now run on Google’s worldwide fleet.
Now that I’m in Seattle, I am heading my own team with the charter to make the mobile web fast. By “mobile web”, I mean the entire web as accessed from all mobile devices, not just Google services and not just Android. While Android is a big focus of our work, we care a lot about improving performance for all mobile devices. This project is an outgrowth of Google’s broader make the web faster initiative, which has (to date) largely been focused on desktop web. The parent project has been involved with the Chrome browser, the SPDY protocol (a replacement for HTTP), the WebP image format, numerous network stack enhancements, and more. I see mobile as the next big frontier for the web and there are some huge opportunities to make impact in this space.
This is a hugely exciting project since it touches on many different platforms and cuts across layers. Everyone knows that mobile web usage is taking off: the growth of the mobile web is much, much faster than the growth of the desktop web was back during the dot-com boom. At the same time, the mobile web is painfully slow for most sites and most users. And of course, not everyone has the benefit of using a bleeding-edge 4G phone with LTE network speeds of 25 Mbps, like I do (my current phone is an HTC Thunderbolt, and it’s awesome). For the vast majority of Internet users, a mobile phone will be the only device they ever interact with.
So what are we working on? At a high level we are planning to tackle problems in three broad areas: The mobile devices themselves; the services they connect to; and the networks that connect them. On the device side, we are looking at a wide range of OS, network stack, and browser enhancements to improve performance. On the service side, we are looking at better ways to architect websites for mobile clients, providing tools to help web developers maximize their performance, and automatic optimizations that can be performed by a site or in a proxy service. Finally, at the network layer we are looking at the (sometimes painful) interactions between different layers of the protocol stack and identifying ways to streamline them. There is a huge amount of work to do and I am really fortunate to work with some amazing people, like Steve Souders and Arvind Jain, on this effort.
Our goal is to share solutions with the broader web development community -- we hope to release most of our code as open source, as many other Google projects have done. I also plan to maintain strong ties with the academic research community, since I feel that there is a great opportunity to open up new avenues for mobile systems research, as well as leverage the great work that universities are doing in this space.
I think Google is in a unique position to solve this problem. And, of course, we are hiring! Drop me a line if you are interested in joining our team.
Now that I’m in Seattle, I am heading my own team with the charter to make the mobile web fast. By “mobile web”, I mean the entire web as accessed from all mobile devices, not just Google services and not just Android. While Android is a big focus of our work, we care a lot about improving performance for all mobile devices. This project is an outgrowth of Google’s broader make the web faster initiative, which has (to date) largely been focused on desktop web. The parent project has been involved with the Chrome browser, the SPDY protocol (a replacement for HTTP), the WebP image format, numerous network stack enhancements, and more. I see mobile as the next big frontier for the web and there are some huge opportunities to make impact in this space.
This is a hugely exciting project since it touches on many different platforms and cuts across layers. Everyone knows that mobile web usage is taking off: the growth of the mobile web is much, much faster than the growth of the desktop web was back during the dot-com boom. At the same time, the mobile web is painfully slow for most sites and most users. And of course, not everyone has the benefit of using a bleeding-edge 4G phone with LTE network speeds of 25 Mbps, like I do (my current phone is an HTC Thunderbolt, and it’s awesome). For the vast majority of Internet users, a mobile phone will be the only device they ever interact with.
So what are we working on? At a high level we are planning to tackle problems in three broad areas: The mobile devices themselves; the services they connect to; and the networks that connect them. On the device side, we are looking at a wide range of OS, network stack, and browser enhancements to improve performance. On the service side, we are looking at better ways to architect websites for mobile clients, providing tools to help web developers maximize their performance, and automatic optimizations that can be performed by a site or in a proxy service. Finally, at the network layer we are looking at the (sometimes painful) interactions between different layers of the protocol stack and identifying ways to streamline them. There is a huge amount of work to do and I am really fortunate to work with some amazing people, like Steve Souders and Arvind Jain, on this effort.
Our goal is to share solutions with the broader web development community -- we hope to release most of our code as open source, as many other Google projects have done. I also plan to maintain strong ties with the academic research community, since I feel that there is a great opportunity to open up new avenues for mobile systems research, as well as leverage the great work that universities are doing in this space.
I think Google is in a unique position to solve this problem. And, of course, we are hiring! Drop me a line if you are interested in joining our team.
Wow, sounds like fun! So, were you involved in launching SPDY for all users of Chrome when they connect to Google servers?
ReplyDeletehttp://groups.google.com/group/spdy-dev/browse_thread/thread/4c2396ecbc36b1c4
My jaw dropped when I saw that. Very aggressive and very cool.
Greg - I had nothing to do with that, but I do think it's very cool too.
ReplyDeleteThis comment has been removed by the author.
ReplyDeleteHi, Matt, I am greatly interested in your project.
ReplyDeleteOne general question, it seems that Google will do a lot of optimization of whole network stack, like making your customized TCP protocol? how to inter operate with other standard TCP, will it have negative impact on those standard TCP?(one example from the public , you increase TCP Initial Congestion Window, it will inevitably affect other TCPs)
Thanks for your post.Hope it will not touch some business/tech secret.
BTW, Can I directly give my resume to you:)Seems you are hiring manager. or at least we can discuss via email?
ReplyDeleteWebcraft - my email address is easy to find :-)
ReplyDeleteIn terms of TCP optimizations, there are many things that can be done that do not adversely affect other TCP implementations. There are many timing parameters in TCP that were set in the 1980's and have never been revisited in light of moden network architectures, for example.
Thanks, Matt. I think I know what you means. so basically you'd like to keep the TCP basic scheme, and adjust the parameters(RTO timer for instance). Dose google design its own TCP? like C-TCP by MS or CUBIC by linux?
ReplyDeleteI've quickly browsed SPDY, great job! Since your title is about "mobile web", Will you consider mobile link's characteristic? Or just treating it as a lossy/low BW link?
There is a lot of works going on to re-think TCP on data center network and mobile. But there seems no work to combine them together although it may be major traffic type in future. What is the general idea of Google about this?
Final question, will you still touch WSN in Google? How is Google's thinking in this field.
thanks in advance
Webcraft -- I can't comment too much on Google's internal projects, but since Google runs Linux in its datacenters, most of what we do is building off of Linux. Of course, on the Internet-facing end, any changes to the network stack have to be compatible with generic TCP implementations since we have to talk to literally everything in the world.
ReplyDeleteI'm not working on wireless sensor networks at Google. I am not sure whether there are active projects in that space or not.
Hi, Matt. I have 2 questions about the Android browser setting.
ReplyDelete1. Why is the browser cache so small? (4MB on Froyo)
2. Why is the number of concurrent connections so small? (4 connections are allowed overall. )
I think those 2 settings can impact web performance greatly...
Michael - I don't know why those parameters have those values, but my understanding is that future versions of Android have significantly increased them. I don't recall the values for Gingerbread or Honeycomb off the top of my head but worth taking a look....
ReplyDeleteWell, actual browser cache is not 4MB. An Android browser has two caches: disk and memory. Memory caches are limited to 32MB and this amount is open for customization anything below 32MB, so it may change from phone to phone. But disk cache is not limited to this size.
ReplyDeleteMatt, there is a pretty cool old paper on improving mobile web performance over GPRS (link: http://www.usenix.org/event/mobisys03/tech/full_papers/chakravorty/chakravorty.pdf) I've often wondered how their numbers would have changed with 4G/LTE.
ReplyDelete