Google has an open peering policy subject to a few
technical, commercial and legal considerations. As a general statement, we will agree
to offer peering, so long as it's consistent with our peering policy.
Please see the Google (AS15169) entry in PeeringDB for Internet Exchanges we are connected
to, along with private peering facilities.
Google will optimize delivery of content to users by considering a number of
components including latency, quality of user experience, capacity constraints within
Google and in other networks, and other factors.
Google aims to deliver as much traffic as possible via Google Global Cache and
peering, as this will generally provide the optimal user experience and lowest cost
delivery for both the operator and Google. However, there may be reasons why this is
not the case and some traffic may flow over indirect paths. Please contact us to
discuss traffic delivery options for your network.
In some locations, part of Google's content delivery network is also reachable
through AS 36040. This ASN serves a subset of eligible of Google content. Due to the
unique nature, AS36040 does not have the same peering policy.
If you do not already peer with Google, please contact your Google peering
coordinator to discuss connecting with AS15169 and/or AS36040
AS43515 is a subset of Google's backbone network. It is not possible to peer with
AS43515. If you are receiving traffic from AS43515, please contact us to discuss your
Google Global Cache
There are certain legal limitations to doing businesses in some countries, but as a
general statement, we will agree to offer GGC to qualified ISPs, so long as it's in
an area where there are no restrictions, and so long as it's consistent with our
GGC was designed for eyeball-heavy networks with greater than 1Gbps peak Google
traffic. Google encourages networks with less than 1Gbps peak traffic to Google to
join a local Internet Exchange, where combined traffic levels from multiple ISPs are
sufficient to support the deployment of a cache node.
Cache hit rate will vary by network based on the number of users served by the cache,
their usage patterns, the size and type of GGC node, and the number of nodes deployed
in your network. We have typically seen hit rates of 70% to 90%.
Typically, a majority of the traffic routed through the GGC node is static content
such as YouTube videos and Android Market downloads. Other Google web services, such
as Google Search, may also be proxied and/or cached based on a number of factors,
including legal requirements, available capacity and expected improvement in
performance for end users. These services could include (but are not limited to):
Google Maps (including map tiles and street view)
Picasa Web Albums
DoubleClick by Google
Note: Exact services cached and/or proxied by GGC will vary based on Google's legal
and commercial requirements, and Google's discretion on possible performance impact
of serving traffic through the node. Please understand that Google's intent is to
serve users from the best possible location for each service, which may or may not be
the local GGC node.
The local cache is filled on a read-through basis when content is requested by the
end user. If the GGC node already has the requested content in its local cache, it
will serve the content via your network to the end user, improving the user
experience and saving bandwidth. If the content is not stored on the GGC node, and
the content is cache-eligible, the node will retrieve it from Google, serve it to the
user, and store it for future requests. Otherwise, the request will be served from
the nearest upstream node which has the content. No content is pre-loaded.
No, users do not have to make any changes to take advantage of the GGC node. Requests
are routed to the node automatically by Google's servers. If the GGC node is
unavailable for any reason, user requests will be sent to another node or directly to
Google does not ask for preferential treatment of Google traffic. GGC is a way of
bringing content closer to the end user and bringing delivery costs down for
Yes, Google works with operators during node activation to set the maximum bandwidth
level for each GGC node deployed in an operator's network. This process takes into
account the node's configuration and network capacity available to the GGC node. This
is generally ramped up over several days. After activation, this maximum can be
changed by contacting the GGC Operations team.
No. Non-Google caching on shared infrastructure is currently forbidden for most
requests by Google's HTTP response headers (we set Cache-Control: private,
max-age=6h). This indicates "that all or part of the response message is intended for
a single user and must not be cached by a shared cache." As such, in-browser caching
is allowed for up to 6 hours, while shared-caching is never allowed. According to
RFC2616, Cache-Control headers "MUST be obeyed by all caching mechanisms along the
request/response chain," so any shared caching mechanism intercepting Google content
is not standards-compliant, and not conforming to our published policy towards
Google optimizes the content delivery path to users based on a number of metrics,
including observed network path latency and quality of experience for the end user.
Google does not recommend relying on ping time to google.com [or any other Google
service] as a measure of the actual user performance of Google services:
ICMP ping traffic can be discarded or delayed en-route
The termination point of the TCP session with Google may not represent the full
network path between a user and the service
User content may often be served from other locations (possibly closer to the
user) than the destination of a ping request
Google uses complex load balancing and content delivery platforms. An individual IP
address may serve multiple Google services, and the services served from that IP
address may change over time without notice, as may the IP addresses used to serve
specific Google services. Also, our content delivery platforms are both inside and
outside our network, so at times certain Google services may appear to be served from
outside IP address space allocated to Google. Exceptions include: