Blog of our latest news, updates, and stories for developers

Let's make TCP faster

Monday, January 23, 2012
Share on Twitter Share on Facebook
Google
Labels: faster web

48 comments :

  1. Rich JonesJanuary 23, 2012 at 12:14 PM

    This is awesome work. I'm glad that Google is putting their vast engineering resources to such good use.

    Rich, Gun.io

    ReplyDelete
    Replies
      Reply
  2. Clemens HartenJanuary 23, 2012 at 12:24 PM

    It is impressive to see how simple changes (justified by extensive research) can lead to a great improvement of the protocol. Well done!

    ReplyDelete
    Replies
      Reply
  3. IamienJanuary 23, 2012 at 12:33 PM

    It would be nifty if someone with the know how made an opensource exe or msi that set all of these settings that are able to be set client-side.

    ReplyDelete
    Replies
    1. Michael AdamsJanuary 24, 2012 at 12:38 AM

      I wrote a program that you're now requesting a few months back: for the Microsoft stuff anyway. The Google stuff would have to be developed into a driver for Windows to work properly.

      http://unquietwiki.com/programming/ (look for NetToggle)

      Delete
      Replies
        Reply
    2. Reply
  4. Nathaniel BorensteinJanuary 23, 2012 at 12:34 PM

    I'd be interested in hearing if these experiments have been reproduced in less-privileged connectivity situations, such as 3G, satellite, or even dial-up. As one who still, of necessity, lives in that environment most of the time, it's my impression that researchers often operate under the assumption that these constraints are rapidly going away, but they remain the only options in many rural areas even in the US today. It's all too easy to imagine that what optimizes the high-bandwidth experience, such as shortening the initial timeout from 3 seconds to 1, might actually make things worse for those of us who already have it worst.

    ReplyDelete
    Replies
    1. La LuzJanuary 24, 2012 at 3:20 PM

      Thats thinking outside the box....(I concur)

      Delete
      Replies
        Reply
    2. Nandita DukkipatiJanuary 24, 2012 at 11:20 PM

      Great question. We do take into account the impact of our changes to TCP on users with low access bandwidth, such as dial-up. A couple of examples: In the IW10 work we explicitly analyzed the large-scale experiment results for dial-up and mobile users. This is in addition to also doing more controlled testbed experiments to reproduce what we were observing in our cluster wide experiments. A second and more recent example, is the experiments with proportional rate reduction (PRR) in India datacenters where bandwidth is typically on lower end.

      Delete
      Replies
        Reply
    3. Reply
  5. mcrJanuary 23, 2012 at 12:58 PM

    What Nathanial said. We need default algorithms in stations which respond to conditions that they experience, and remember this system wide for a period of time. (HappyEyeBalls is an example of this, but is browser specific, not system specific). TCP Fast Open (what happened to TTCP?) likely fails HORRIBLY on bank's CISCO PIX firewalls.
    And it's not just connectivity which is an issue, but also the fact that TCP now runs on very small devices, where these things are not relevant, and things have to work. How does TCP Fast Open fail when the responder does not get it?

    ReplyDelete
    Replies
      Reply
  6. John MoehrkeJanuary 23, 2012 at 1:03 PM

    These are not too new of items. What is needed is a tool that will automatically discover the best settings given the users current context. As Nathanial indicates not everyone is on a high-bandwidth link. What this likely is made up of is code that looks at the current connnections to tweek future connections settings. Generally each connection starts with some configured default value. Where the default values are static. I suggest the default settings should be close to a current-consensus.

    ReplyDelete
    Replies
      Reply
  7. David BondJanuary 23, 2012 at 1:05 PM

    Any thoughts on putting payload into the SYNACKs? (server and client both) This would be the ultimate speed-up...

    ReplyDelete
    Replies
      Reply
  8. the stealth masterJanuary 23, 2012 at 1:26 PM

    The buffer bloat issue needs to be resolved first, otherwise you will be wasting a lot of time.

    http://en.wikipedia.org/wiki/Bufferbloat

    ReplyDelete
    Replies
      Reply
  9. harjuoJanuary 23, 2012 at 1:31 PM

    David, either participant still could not pass the data to the socket client before the handshake was complete. They would have to buffer the data, and that would just amplify the severity of syn flood attacks.

    ReplyDelete
    Replies
      Reply
  10. HaapiJanuary 23, 2012 at 1:33 PM

    I can agree that those initiatives are positive things, but ISP's buffer bloat, which is defeating the TCP's existing congestion algorithms and introducing latency, make them moot. One may consider buffer bloat orthogonal to these issues, but ISPs do it for a reason. Hearing these initiatives phrased in a manner so that ISPs see solutions to their problem (that is poorly solved by buffering) would be useful.

    ReplyDelete
    Replies
      Reply
  11. TinctoriusJanuary 23, 2012 at 2:15 PM

    Have you looked at UDT? There must be some lessons that can be taken from it...

    ReplyDelete
    Replies
      Reply
  12. ychengJanuary 23, 2012 at 2:21 PM

    Thanks for the questions and comments.

    @Nathaniel/mcr: compatibility is the key part of Fast Open design. Our draft has more details to deal with firewalls/syn-data drops: http://www.ietf.org/id/draft-cheng-tcpm-fastopen-02.txt

    @John: tuning the initial parameters based on history is certainly helpful. we are working on this now.

    @DavidBond: Fast Open allows data in SYN-ACK packet as well.

    @harjuo: Both our paper and draft discuss a new socket interface and the syn-flood issue extensively:
    http://www.ietf.org/id/draft-cheng-tcpm-fastopen-02.txt
    http://research.google.com/pubs/pub37517.html

    @stealth/haapl: we are experimenting new algorithms to lower the queuing delay of TCP connections. Please stay tuned for more updates.

    ReplyDelete
    Replies
      Reply
  13. layer3switchJanuary 23, 2012 at 3:24 PM

    Please allow my ignorance, but how will aes block cypher help mitigating man in the middle tfo cookie interception? wouldn't stream cypher make better sense with short-time live cookie exchange after 2nd phase?

    ReplyDelete
    Replies
      Reply
  14. Ryan BonnellJanuary 23, 2012 at 4:44 PM

    Interesting article on Bufferbloat. There has been a trend towards Layer3 switches with reduced buffers so I am surprised that this issue has been getting worse. I hope we can use these enhancements on load balancers quickly once the tech is finalized. Using generic Linux servers as load balancers works up to a point. :-)

    ReplyDelete
    Replies
      Reply
  15. IlyaJanuary 23, 2012 at 6:20 PM

    Are there instructions or a patch I can apply to my Ubuntu and my servers to adjust these settings? If so, I can apply it to my servers.

    ReplyDelete
    Replies
      Reply
  16. nmJanuary 23, 2012 at 7:46 PM

    This comment has been removed by the author.

    ReplyDelete
    Replies
      Reply
  17. nmJanuary 23, 2012 at 7:50 PM

    Are there kernel patches available for the items listed above?

    I've been able to find/backport for #1 and #4 but have not seen any code anywhere for #2 or #3.
    #2 could be a simple one-liner change but IIRC that leads to other issues.

    https://github.com/vrv/linux-microsecondrto
    http://www.pdl.cmu.edu/PDL-FTP/Storage/sigcomm147-vasudevan.pdf

    For #3, code was promised but I have not seen it publicly posted anywhere..

    ReplyDelete
    Replies
    1. ychengJanuary 24, 2012 at 3:21 PM

      Linux kernel versions of the changes were applied:

      1. Initial Congestion Window of 10 packets: 2.6.39-rc1
      2. Initial Retransmission Timeout of 1sec: 3.1-rc1
      3. Proportional Rate Reduction: 3.2-rc1
      4. Fast Open: not yet. It's the most complicated change. We are still testing the patches internally and will upstream when it's ready.

      Delete
      Replies
        Reply
    2. Gauthier DelacroixJanuary 25, 2012 at 10:01 AM

      Page 14 of this page says Fast Open is in kernel 2.6.34 : http://conferences.sigcomm.org/co-next/2011/slides/Radhakrishnan-TCP_Fast_Open.pdf

      Is it the same "Fast Open" ?...I think it is...

      Delete
      Replies
        Reply
    3. Reply
  18. BenJanuary 23, 2012 at 8:06 PM

    Do you have any statistics yet for what the combined effect of implementing all of these changes might be for the "average" internet user?

    You would probably get a lot more attention and be more likely to see your changes adopted in the TCP standard if you published a post that said "Google Researchers Discover Way To Speed Up Internet By 30%".

    Such a headline would lose some specificity, but since most people don't know what TCP is, it would be an effective way to spread the news and promote change.

    ReplyDelete
    Replies
      Reply
  19. Olivier BonaventureJanuary 24, 2012 at 2:47 AM

    Another work on improving TCP is the development of Multipath TCP that is being finalized within the IETF. See http://www.ietf.org/id/draft-ietf-mptcp-multiaddressed-05.txt for the latest draft. The Linux kernel patch developed at UCLouvain is completely functional and provides good performance on servers and in lab environments. We'd love to be able to perform more tests in real wireless networks where Multipath TCP would provide many benefits as well. See http://mptcp.info.ucl.ac.be/

    ReplyDelete
    Replies
    1. ychengJanuary 24, 2012 at 3:25 PM

      Multipath TCP is on our radar. Google has in fact sponsored some of the projects through Google Research grant.

      Delete
      Replies
        Reply
    2. Reply
  20. Joe BowmanJanuary 24, 2012 at 7:02 AM

    Is it really time to attack TCP? Especially since the way the article is worded it seems like HTTP is a driving factor for establishing results.

    The reason I ask is maybe focus should continue to be on ideas like SPDY, which sort of turns HTTP into a reusable persistent connection type protocol instead of the current stateless beast it is now. There's also still the idea of turning the entire web to ssl that's been floated about. That suddenly makes securing sessions easier, especially when combined with SPDY if developed with those technologies in place.

    Then, once you have the more optimized and secure higher level protocols in place, then tune TCP for them. What's the risk of decisions made now.

    Also, item 2 on the timeout. I think you might be generalizing a bit. I personally work for an organization where we literally have to support that office on the island with a satellite uplink that only works for 12 hours a day. It has high latency, low bandwidth and I bet if you cut timeouts by 2/3 their experience will be degraded. Sure, the current way TCP is designed it probably isn't optimial for 99.9% of the internet, but that doesn't mean the world is ready to lose that .1%.

    ReplyDelete
    Replies
    1. ychengJanuary 24, 2012 at 3:17 PM

      Actually the core developer of SPDY, Mike Belshe, is the major driver to our TCP changes. See his comments about TCP/SPDY at:
      1. http://www.ietf.org/proceedings/80/slides/tsvarea-0.pdf
      2. http://www.ietf.org/mail-archive/web/tcpm/current/msg06121.html

      Delete
      Replies
        Reply
    2. AutoRevitJanuary 25, 2012 at 12:34 AM

      Are there any guidelines for working with WebSockets? What should I use when working with Google Protocol Buffers - HTTP, SPDY, HTTP+WebSocket, TCP? I'm talking about massively multiplayer online game.

      Delete
      Replies
        Reply
    3. Reply
  21. JamesJanuary 24, 2012 at 7:47 AM

    What about offloading the transmission control to software? I've used software that does this and I've seen 100% increases in throughput.

    ReplyDelete
    Replies
      Reply
  22. Iljitsch van BeijnumJanuary 24, 2012 at 8:28 AM

    Did you guys look at losses in the last 3 packets that can't be recovered from using SACK? IMO that is a big reason why HTTP sessions hang.

    ReplyDelete
    Replies
    1. Matt MathisJanuary 24, 2012 at 5:27 PM

      Early Retransmit did not help as much as we expected.   See the PRR paper for details.   Given the relative complexity of the changes and the limited gain, other TCP improvements were higher priority.

      Delete
      Replies
        Reply
    2. Nandita DukkipatiJanuary 24, 2012 at 11:43 PM

      If the last three packets get lost, the only way to recover is via an RTO. We do find that a significant portion of the retransmissions from short HTTP responses are due to RTOs (as opposed to fast recovery). We are working on solutions to address the issue of long latency due to timeouts in short flows.

      Delete
      Replies
        Reply
    3. Reply
  23. cyber8607January 24, 2012 at 10:44 AM

    and how can i change these values of " Increase TCP initial congestion window to 10 (IW10)" and "Reduce the initial timeout from 3 seconds to 1 second" on Windows 7?

    ReplyDelete
    Replies
    1. MahmoudJanuary 24, 2012 at 2:33 PM

      you can't do that in windows 7. the article is about "Server Configuration" which where administrators can reduce the execution time or even add database configuration settings, read about web.conig and asp.net :)

      Delete
      Replies
        Reply
    2. Reply
  24. j.engJanuary 24, 2012 at 1:52 PM

    Why don't you actually work on SCTP? With its ability to carry multiple independent substreams, multiple HTTP could be issued with a single connection.

    ReplyDelete
    Replies
    1. Matt MathisJanuary 24, 2012 at 5:29 PM

      Yep, all very true.  Google also sponsors SCTP research. All of our changes (or similar algorithms) can be ported to SCTP when the need arises.

      Delete
      Replies
        Reply
    2. Reply
  25. MahmoudJanuary 24, 2012 at 2:30 PM

    well,I would love to add that (using None Post back strategies) can indeed reduces the amount the page takes to be served to the client, for example... using a server side code, will hold the page till the server side code is fully compiled... which may cause time out or even a deadlock in the database may happen!!! in this case you have no business reducing the page execution time out to 1 second...

    instead...
    1-Enhance your database performance and always rebuild and reorganize your indexes.
    2-Always Maintain your code so the execution time is shorter/faster.
    3-Cash your pages.
    4-Use AJAX :)
    that will indeed maximize your webpage performance and will keep your users happy.... that's how I do it anyway.

    ReplyDelete
    Replies
      Reply
  26. cearnerJanuary 24, 2012 at 6:03 PM

    Wouldn't it be wiser to implement this as a separate protocol with a distinct IP Protocol Number value? You could call it Google Transport Protocol rather than TCP.

    There are a lot of TCP stacks out there, some of them in embedded systems. If even one of them is badly written all kinds of unpleasant havoc could occur if that stack interacts with your new version of TCP.

    The main reason I suggest this is that you can't just update the stack in an embedded application. It's frequently burned into ROM.

    ReplyDelete
    Replies
      Reply
  27. echo9January 25, 2012 at 3:54 AM

    LOL.. you guys should've seen UDT's performance.

    Go chk it out; its on sourceforge :)

    ReplyDelete
    Replies
    1. QuuxJanuary 25, 2012 at 7:10 PM

      It is better on long connections. But on quick - is not.

      Delete
      Replies
        Reply
    2. Reply
  28. QuuxJanuary 25, 2012 at 7:17 PM

    "An RTT of 3 seconds was appropriate a couple of decades ago, but today’s Internet requires a much smaller timeout"

    bad advice. what if my clients are using slow internet connection? perhaps, from 3rd world country through mobile operator, even excellent ISP can have some problems sometimes, or may be user is downloading something heavy, etc... what will they think about my service? It is not so critical to choose 3 sec instead of 1 sec, but it will be a better service.

    ReplyDelete
    Replies
      Reply
  29. teabagsumJanuary 26, 2012 at 3:20 AM

    Yuchung, I've seen similar behavior in wireless adhoc networks, where the impact of bigger window sizes is a much better improvement than here.

    As for the timeout reduction, I would argue that the 21st century is not about big centralized systems but decentralization. And I'm not so sure that increasing the timeout in mesh networks is in fact such a good idea.

    ReplyDelete
    Replies
      Reply
  30. zdig1January 26, 2012 at 4:17 AM

    before this you must working on new independent structure of the network ,we refuse to another sopa or pipa or other censorship like megaup

    ReplyDelete
    Replies
      Reply
  31. mercurialmadnessmanJanuary 26, 2012 at 9:59 PM

    Where's the RFC? :)

    ReplyDelete
    Replies
      Reply
  32. drbaltazarJanuary 27, 2012 at 3:35 PM

    there are reason ms hardcode now!cause in the past silly people like google and a lot of other messed with standard without the whole picture!the web sadly isnt just google server or microsoft if it was trust me microsoft would have adopted way better solution but compromise had to be made so overall web was smooth,instead google should ask for variable.

    ReplyDelete
    Replies
      Reply
  33. Hao ZhuangFebruary 10, 2012 at 12:19 PM

    i agree that most of the items listed in this article are the pains in the neck for todays TCP implementations. that said, TCP optimization is a bigger problem than merely tweaking the parameters. we, www.appexnetworks.com, have been working for years on that. besides the points listed here, there are issues such as how to improve the accuracy in detecting a packet loss from, say, reordering; how to filter out bogus signals from crappy real-world TCP implementations (you'd be surprised to see how some TCP reacts, esp thru the filter of some 'intelligent' firewalls). and most importantly, you dont want to contribute to the chances of congestion, on both directions, even if your traffic is mostly unidirectional. and there are more.

    we've done most of it, though not all of it. for linux and windows, if you'd like to try, you are welcome to get it from our download site.

    ReplyDelete
    Replies
      Reply
  34. UnknownJanuary 24, 2013 at 4:08 AM

    did you try to test this improvements in combination with other web improvement protocols like SPDY ?

    ReplyDelete
    Replies
      Reply
  35. UnknownJanuary 24, 2013 at 4:14 AM

    have you thought about effects of these improvements when they combined with other web improvement protocols like SPDY ?

    ReplyDelete
    Replies
      Reply
Add comment
Load more...

  

Labels


  • .app
  • .dev
  • #30DaysOfFlutter
  • #AIY
  • #CSEdWeek
  • #devfest18 #devfeststories #gdg #googledevelopers #developers #community
  • #freeandopen
  • #GDC20
  • #GooglePlay #AndroidDevStory #PlayStore #DeveloperConsole #StoreListingExperiments
  • #growwithgoogle
  • #io12
  • #io13
  • #io14
  • #io15
  • #io16
  • #io17
  • #io18
  • #io2012
  • #io2013
  • #io2014
  • +1
  • 20% project
  • 3d
  • 3D face mesh
  • about.com
  • accelerator
  • Access
  • accessibility
  • Account Linking
  • actions
  • Actions Builder
  • Actions console
  • actions on google
  • Actions SDK
  • actionsongoogle
  • activity
  • Administrative APIs
  • AdMob
  • adobe
  • Adobe Creative Cloud
  • Adobe Creative Cloud Libraries
  • Ads
  • adsense
  • advanced
  • advogato
  • AdWords
  • africa
  • agency program
  • agpl
  • AI
  • AI Principles
  • AIY
  • AIY Projects
  • AIYProjects
  • ajax
  • ajax apis
  • ajax search
  • ajax search books news apis
  • Alfred Camera
  • all for good
  • amarok
  • AMP
  • AMP Cache
  • analytics
  • and Assistant
  • android
  • Android App Development
  • Android Developer
  • android developer certification
  • android developers
  • Android Development
  • Android Studio
  • Android Things
  • Android Tools
  • Android TV
  • android wear
  • android11
  • androidstudio
  • animation
  • Announcement
  • announcements
  • apache
  • api
  • API.AI
  • apis
  • apis console
  • apis explorer
  • apis. charts
  • app
  • app design
  • App dev
  • App Development
  • app engine
  • app indexing
  • app indexing api
  • App Invites
  • apple
  • Application Development
  • apps
  • apps script
  • AR
  • ARCore
  • area 120
  • artifact management
  • Artificial Intelligence
  • asia
  • assistant
  • atom publishing protocol
  • Audio
  • augmented faces
  • Augmented images
  • augmented reality
  • australia
  • Auth
  • authentication
  • authsub
  • automatic speech recognition
  • AutoML
  • awards
  • axsjax
  • barcodes
  • beacon
  • beacons
  • Belarus
  • bespin
  • best practices
  • beta
  • bigquery
  • bitcoin
  • Black Consciousness Day
  • Blockly
  • blogger
  • Bluetooth
  • book search
  • books API
  • bootcamp
  • braintree
  • Brazil
  • british english
  • Brotli
  • browser
  • Build Out
  • building ajax apps
  • BuildOut
  • Bulgaria
  • business
  • business console
  • buzz
  • c++
  • Cache
  • caja
  • caldav
  • calendar
  • camino
  • campfire one
  • caption
  • cardboard
  • CardDAV
  • cast
  • Cast Connect
  • celebrating
  • Certification
  • certification award
  • channel
  • chinese
  • chrome
  • chrome apps
  • chrome dev summit
  • chrome devtools
  • chrome experiment
  • chrome extensions
  • chrome os
  • Chrome OS IO
  • Chrome OS IO19
  • chrome web store
  • Chromebooks
  • chromecast
  • chromium
  • chronoscope
  • cifs
  • classes
  • classroom api
  • client libraries
  • closure tools
  • cloud
  • Cloud anchor
  • Cloud Anchors
  • Cloud Computing
  • cloud datastore
  • Cloud Functions
  • cloud functions for firebase
  • Cloud Next
  • cloud platform
  • cloud portability
  • cloud services
  • cloud sql
  • cloud storage
  • Cloud Study Jam
  • cms
  • coca cola
  • CocoaPods
  • code for educators
  • code jam
  • code review
  • code-in
  • codeedu
  • codelabs
  • coding
  • coffee with a googler
  • Colaboratory
  • collada
  • color
  • Colt McAnlis
  • commerce
  • community
  • community connectors
  • compatibility
  • competition
  • Compilers
  • compression
  • compressorhead
  • computer science
  • Computer Science Education Week
  • computer vision
  • computing heritage
  • conference
  • conferences
  • Console
  • contacts api
  • Containers
  • contest
  • contextual gadgets
  • conversation design
  • conversations
  • Coral
  • Coral updates
  • Core ML
  • couchdb
  • countdown to I/O 2012
  • country support
  • courses
  • COVID
  • COVID-19
  • COVID19DetectProtect
  • CPU
  • crash course
  • Crash Reporting
  • crashlytics
  • creative commons
  • cricket
  • crisis response
  • Croatia
  • Crostini
  • cryptocurrency
  • cryptography
  • css
  • css3
  • Custom Elements
  • custom search
  • custom search api
  • Czechia
  • DA
  • danish linux forum
  • dart
  • Data Compression
  • Data science
  • Data Visualization
  • database
  • Databases
  • Dataset
  • Datasets
  • datastore
  • dataviz
  • Daydream
  • deprecation
  • Depth
  • design
  • desktop
  • desktop apps
  • Dev Tools
  • devart
  • develop
  • developer
  • Developer Advocate
  • Developer Communities
  • Developer Culture
  • developer expert
  • developer features
  • Developer Keynote
  • Developer Preview
  • developer relations
  • developer student clubs
  • developers
  • developers. meetup
  • Development
  • devfest
  • devfest developer chrome maps social wave apps
  • DevFest18
  • DevFestStories
  • Device
  • DFP
  • Dia da Consciência Negra
  • dialogflow
  • differential privacy
  • discovery service
  • diversity
  • diversity-and-inclusion
  • django
  • dns
  • do-it-yourself
  • Docker
  • docs
  • documentation
  • documents list api
  • dojo
  • domain
  • domains
  • doodles
  • dot net
  • doubleclick
  • dreamweaver
  • Drive
  • drupal
  • dsc
  • dynamic links
  • earn
  • earth
  • Ebay
  • eclipse
  • eclipsecon
  • eddystone
  • Edge AI
  • Edge TPU
  • Edge TPU Accelerator
  • Edge TPU Dev Board
  • educatio
  • education
  • email
  • EMEA
  • endpoints
  • enterprise
  • Entity Extraction
  • entrepreneurs
  • Error logging
  • Estimator
  • Estimators
  • estonia
  • Ethics
  • Europe
  • event
  • events
  • evolution
  • execution api
  • extensions
  • Fabric
  • face detection
  • Fairness
  • fairness in machine learning
  • faster web
  • FCM
  • FCP
  • featured
  • feeds
  • finance
  • fintech
  • Firebase
  • Firebase Analytics
  • Firebase Cloud Messaging
  • Firebase Dynamic Links
  • firebug
  • firefox
  • firestore
  • firevox
  • firstbeta
  • fitness
  • flutter
  • Flutter 1.2
  • Flutter 1.5
  • Flutter 1.9
  • Flutter at IO
  • Flutter Clock
  • Flutter Create
  • Flutter for desktop
  • Flutter for web
  • Flutter Interact
  • Flutter Live
  • flutter release preview 1
  • flutter release preview 2
  • Follow Us
  • font api
  • Fonts
  • fosdem
  • founders
  • freebsd
  • freenet
  • Fridaygram
  • fusion tables
  • G Suite
  • G Suite Developer
  • G+
  • gadgets
  • Game Developers Conference
  • games
  • gaming
  • gcc
  • gci
  • GCP
  • GDA
  • gdata
  • GDC 2020
  • GDC17
  • GDD
  • gdd07
  • gdd08
  • gdd09
  • GDD11
  • GDE
  • gdg
  • gdl
  • gdl weekly
  • gears
  • geo
  • geolocation
  • geoserver
  • GET
  • getpaid
  • ghop
  • Gigster
  • git
  • github
  • GKE
  • Glass
  • gmail
  • Gmail Add-on
  • Gmail API
  • Gmail APIs
  • GMTC
  • gnome
  • gnome women's summer outreach program
  • Go
  • golang
  • goo.gl
  • Google
  • Google AI
  • Google Analytics
  • Google APIs
  • google apps
  • google apps api
  • google apps for your domain
  • google apps marketplace
  • Google AR
  • google assistant
  • Google Assistant Bluetooth
  • Google Assistant Developer Day
  • Google Assistant IO
  • Google Assistant IO19
  • google assistant sdk
  • Google Brain
  • google buzz
  • Google Cardboard
  • google cast
  • google certification
  • google chart api
  • Google Charts
  • google checkout
  • google chrome
  • Google Cloud
  • Google Cloud Messaging
  • Google Cloud Platform
  • google cloud storage
  • Google Cloud Talks
  • google code
  • google code project hosting
  • google code search
  • google code university
  • google compute engine
  • Google Coral
  • google data apis
  • google data protocol
  • Google Data Studio
  • google developer day
  • google developer days
  • Google Developer Experts
  • Google Developer Groups
  • Google Developer Scholarship
  • google developers
  • Google Developers Academy
  • google developers certification
  • google developers community groups
  • Google Developers Groups
  • Google Developers Live
  • Google Developers site
  • Google Developers University Consortium
  • google docs
  • Google Docs Add-on
  • Google Docs API
  • google doctype
  • google domains
  • Google Drive
  • Google Drive SDK
  • google earth
  • google fit
  • Google Fonts
  • Google For Games
  • google for startups
  • google friend connect
  • google gadgets
  • google gears
  • google grants
  • Google Groups Settings
  • google health
  • Google Home Hub
  • Google I/O
  • Google Identity Platform
  • Google in Asia
  • google io
  • Google IOS Android
  • Google Maps
  • Google Maps Platform
  • google mashup editor
  • Google Noto fonts
  • google pay
  • google pay account
  • google pay api
  • google pay business
  • Google Pay Developers
  • Google Pay India
  • google pay integration
  • google pay support
  • google photos
  • google platform
  • Google Play
  • Google Play Developer API
  • google play services
  • Google Registry
  • google scholarships
  • Google Science Fair
  • Google sheets
  • Google Sheets Add-on
  • Google Sheets API
  • Google Slides
  • Google Slides Add-on
  • Google Slides API
  • google space
  • Google Spreadsheets API
  • google storage
  • google summer of code
  • Google tech talk
  • Google technology
  • google technoloy user groups
  • google tv
  • google visualization api
  • google wallet
  • Google Wave
  • google web elements
  • google web toolkit
  • Google Workspace
  • Google Workspace Add-ons
  • Google Workspace Developer
  • google.org
  • google+
  • GoogleAssistant
  • googlecast
  • googledevelopers
  • googleio
  • googlenew
  • GooglePlay
  • GooglePlay AndroidDev
  • googlewebelements googleio
  • GPE
  • GPGS C++ Games
  • GPT
  • Gradle
  • green linux
  • Groovy
  • Groups API
  • grow
  • grow with google
  • gsoc
  • GSuite
  • gtags
  • gtug
  • guest post
  • guice
  • gulp
  • GWSOP
  • gwt
  • gzip
  • hackathon
  • hacking
  • hackthon
  • hamilton
  • Handwriting
  • hangouts
  • Hangouts Chat
  • Hangouts Chat API
  • haproxy
  • Headset
  • hg
  • hibernate
  • howto
  • hpux
  • html
  • html5
  • http
  • I/O
  • I/O 17
  • I/O 2017
  • I/O Extended
  • I/O Live
  • ical
  • ICYMI
  • identity
  • ietf
  • ignite
  • igoogle
  • iguanas
  • iiw
  • Image Compression
  • image search
  • Imara
  • In-app billing
  • in-app payments
  • in-app purchase
  • incubator
  • India
  • indie
  • Indie Games Accelerator
  • information visualization
  • Instagram
  • integration status
  • intelligentwire
  • interactive music
  • International Women’s Day
  • internationalization
  • internet explorer
  • internet of things
  • internship
  • interviews
  • IO
  • IO17
  • io18
  • IO19
  • IO19 Flutter
  • IO2017
  • ios
  • iOS SDK
  • IoT
  • ipad
  • iphone
  • iPhone Development
  • israel
  • Issue Tracker
  • IWD 2020
  • jaiku
  • japanese
  • java
  • javascript
  • jetpack
  • joomla
  • joomladayus2007
  • joomladayusa
  • JS
  • json
  • karaoke
  • KDE
  • KDE 4.0
  • Keras
  • kernel
  • kernel summit
  • keynote
  • khronos
  • kids
  • kids coding
  • kids coding team
  • kml
  • korean
  • Kotlin
  • Krakow
  • Kubernetes
  • labs
  • lanchpad
  • language
  • languages
  • laptop apps
  • laptops
  • latam accelerator
  • LatAm startups
  • Latest
  • Latin America
  • latitude
  • latvia
  • launch
  • launchpad
  • launchpad accelerator
  • launchpad studio
  • LaunchShow
  • lca
  • Leadership
  • Learning
  • lens
  • lessons
  • licenses
  • linux
  • linux foundation
  • Linux on Chrome OS
  • Linux on Chromebooks
  • linux summit
  • linux virtual server
  • linuxconf eu
  • lithuania
  • Local Home
  • Local Home SDK
  • localization
  • Location
  • LoCo
  • Logging
  • london
  • mac
  • MacFuse
  • Machine
  • machine intelligence
  • machine learning
  • machine learning accelerator
  • Mainframe Migration
  • maker
  • Makers
  • malware
  • maps
  • maps apis
  • Marketplace
  • material
  • material components
  • material design
  • MDL
  • MediaPipe
  • meetup
  • mercurial
  • Mexico startups
  • Micronaut
  • Microservices
  • MIT CSAIL
  • MIT Media Lab
  • ml
  • ML Kit
  • MLCC
  • mobile
  • Mobile App Development
  • mobile design
  • Mobile Development
  • mobile performance
  • mobile sites
  • mobile speed
  • mobile UX
  • Mobile web
  • Mobile World Congress
  • mod_pagespeed
  • Moderator
  • monetize
  • Monthly roundup
  • MOOC
  • mozilla
  • multi-platform
  • mylar
  • myspace
  • MySQL
  • mythtv
  • named
  • narratives
  • native ads
  • native client
  • nearby
  • Nest
  • Nest WiFi
  • netbsd
  • Next Billion Users
  • non-profit
  • nonsense
  • nosql
  • notifications
  • Noto Serif CJK
  • NPM
  • nss
  • nvidia
  • NYT
  • O3D
  • oauth
  • OAuth playground
  • OAuth2
  • Object Detection and Tracking
  • objective-c
  • OCaml
  • Occlusion
  • ocr
  • ODF
  • office hours
  • oha
  • online payments
  • OOXML
  • open data
  • open source
  • open source blog
  • open source releases
  • open web
  • open-source
  • openajax alliance
  • opengl
  • openid
  • opensocial
  • openssh
  • openssl
  • Optimization
  • oreilly
  • orkut
  • oscon
  • oscon2007
  • osi
  • oss devs
  • ossjam
  • osx
  • pactester
  • page speed
  • PageSpeed
  • palette
  • payment handler
  • payment request api
  • payment web standard
  • payments
  • paypal
  • Peer bonus program
  • performance
  • persistence
  • persistent AR
  • phone
  • photos
  • picasa
  • picasa web
  • places API
  • play services
  • playground
  • plone
  • plone sprint
  • podcast
  • poland
  • Poly
  • polymer
  • Polymer Summit
  • portugal
  • Pose Detection
  • Pose Estimation
  • posix
  • POST
  • PowerMeter API
  • prediction api
  • Prerender
  • preview
  • privacy
  • prizes
  • processing
  • production access
  • products - slides
  • programmers
  • programming
  • Progressive Web App
  • Project Connected Home over IP
  • project hosting
  • Project Loon
  • Project Tango
  • prototype
  • proximity
  • pubsubhubbub
  • PWA
  • py3k
  • python
  • python sprint
  • Qualcomm
  • Qualcomm Google
  • rails
  • random hacks of kindness
  • Rasberry Pi
  • React
  • reader
  • releases
  • Remote Config
  • research
  • reserve seats
  • Resources
  • Responsible AI
  • REST
  • result snippets
  • Reto Meier
  • review process
  • Rewarded Ads
  • Rewarded Video Ads
  • rhino
  • Saatchi
  • Safety & Security
  • safety and security
  • salesforce
  • samba
  • Sample dialogs
  • sandbox
  • Santa Tracker
  • Scala
  • scalability
  • scale-ups
  • Sceneform
  • schedule
  • scholarship
  • scholarships
  • scopes
  • Scratch
  • screencast
  • sdk
  • sdks
  • search
  • security
  • Selfie Segmentation
  • Serbia
  • serif
  • Serverless
  • service worker
  • sessions
  • seurat
  • shape
  • Sheets
  • Sheets API
  • shindig
  • shopping
  • Shoreline Amphitheatre
  • shortcuts
  • showcase
  • sidewiki
  • sign-in
  • silverstripe
  • SIMD
  • sitemaps
  • sites api
  • sixapart
  • sketchup
  • Slides API
  • small business
  • small businesses
  • small-business
  • Smart Home
  • Smart Lock for Passwords
  • soap search api
  • soc
  • social
  • social graph
  • solaris
  • solutions challenge
  • souders
  • spa2007
  • Space
  • spdy
  • speakers
  • speech
  • speed
  • speed tracer
  • Spring
  • spyware
  • Stable release
  • Stackdriver
  • standards
  • startup
  • Startup accelerator
  • startup africa roadtrip
  • startups
  • Static Sites
  • STEM
  • storage
  • stories
  • Street View
  • Strobe
  • student programs
  • students
  • stuff
  • style
  • subscribed links
  • subscription
  • subversion
  • summer of code
  • Sundar Pichai
  • SVG
  • sxsw
  • syndication
  • targeted spyware
  • tasks API
  • Team Drives (new)
  • techmakers
  • Technical Writing
  • technology
  • templates
  • TensorFlow
  • tensorflow dev summit
  • TensorFlow Lite
  • TensorFlow Research Cloud
  • tensorRT
  • Test Lab
  • testing
  • text embedding models
  • Tez
  • TF Lite
  • tfdevsummit
  • TFLite
  • themes
  • thought leadership
  • tool
  • Toolkit
  • tools
  • topp
  • TPU
  • TPU Dev Board
  • training
  • Traits
  • tranparency
  • transit
  • translate
  • translation
  • tutorials
  • tv
  • ubiquitous computing
  • ubiquity
  • ubucon
  • ubuntu
  • Udacity
  • UI
  • Ukraine
  • UN
  • UNDP
  • UNICEF
  • unicode
  • unit test
  • Unity
  • universal
  • Universal App Campaigns
  • University
  • unix
  • Update
  • updates
  • url
  • url shortener
  • URLs
  • UX
  • verification
  • video
  • videos
  • Vim
  • virtual keyboard
  • virtual reality
  • visualization
  • voice
  • voice kit
  • voice user interface
  • VR
  • VUI
  • wattpad
  • Wearables
  • Weave
  • web
  • web animations api
  • web apps
  • web components
  • web design
  • web designer
  • web development
  • web exponents
  • web fonts
  • web performance
  • web platform docs
  • web registry
  • webfonts
  • webgl
  • webmaster
  • WebP
  • website optimizer
  • websites
  • webVR
  • weekly roundup
  • WhiteHouse.gov
  • Who's at Google I/O
  • win
  • windows
  • windows programming
  • Winter of Code
  • women developers
  • Women in Tech
  • Women Tech Makers
  • women techmakers
  • WomenTechmakers
  • writing
  • wtm
  • xauth
  • yahoo
  • young developers
  • Young Makers
  • youtube
  • zlib
  • zurich
  • ZXing


Archive


  •     2021
    • Feb
    • Jan
  •     2020
    • Dec
    • Nov
    • Oct
    • Sep
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2019
    • Dec
    • Nov
    • Oct
    • Sep
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2018
    • Dec
    • Nov
    • Oct
    • Sep
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2017
    • Dec
    • Nov
    • Oct
    • Sep
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2016
    • Dec
    • Nov
    • Oct
    • Sep
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2015
    • Dec
    • Nov
    • Oct
    • Sep
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
  •     2014
    • Dec
    • Nov
    • Oct
    • Sep
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2013
    • Dec
    • Nov
    • Oct
    • Sep
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2012
    • Dec
    • Nov
    • Oct
    • Sep
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2011
    • Dec
    • Nov
    • Oct
    • Sep
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2010
    • Dec
    • Nov
    • Oct
    • Sep
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2009
    • Dec
    • Nov
    • Oct
    • Sep
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2008
    • Dec
    • Nov
    • Oct
    • Sep
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2007
    • Dec
    • Nov
    • Oct
    • Sep
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2006
    • Dec
    • Nov
    • Oct
    • Sep
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2005
    • Dec
    • Nov
    • Oct
    • Sep
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
Subscribe
Visit Google Developers for docs, event info, and more.
  • Google
  • Privacy
  • Terms