Interesting, I was expecting to see something about QUIC/UDP and was pleasantly disturbed by something different entirely.
First takeaway: SSL is optional? Let's the games begin! Better pay your ISPs on time, or God knows what they will accuse you of, extralegally or not, to get encryption turned off here.
Second takeaway: our company had major problems with upstream link from a local ISP to VPN across the Atlantic to the link on the other end and egress traffic out of our main office. It is really more than one, but you get the idea. The ISP in the US mentioned "caching problems" when we had many users with irritably high latency for Google servers: slow page loads, terribly syncing, crappy IMAP, but only for Google services we use. This data compression stuff seems limited. Does Google have boxes on-prem for ISPs a la Netflix that do the same thing or is improperly configuring this for an ISP enough to do damage?
We got ours delivered about 6 months ago. It usually works fine but once in a while google services will act up, but most of the time the issue is at ISP end because even the GGC nodes needs BW to pull non-cached content, but if your ISP is overselling BW it will really hamper the performance on the GGC nodes. The GGC nodes themselves have capacity limitation, our 3 nodes has a total capacity of 19gbps, I am guessing if we were to saturate that throughput then the services will be affected.
That's interesting, mind expanding on your problems?
I know that as a BT (uk) ISP customer mostly I can ping google.com and it returns in 6ms from a BT IP, which would indicate they're using GGC. Sometimes it resolves to a Google IP in 12 ms.
Last month however it started resolving all the way to Amsterdam and subsequently to the US with a corresponding increase in ping time. Was this their way of saving energy by shutting down DCs, or was it a bigger problem like capacity or an outage? Either way despite the latency issues the fact it always works in a plus for their infrastructure team.
I am sorry I cant get in to specifics. But Routing for GGC is controlled by Google, it is not out of ordinary for your google traffic to not come directly from the GGC node of you ISP. Any internal routing change by your ISP might also cause your Google traffic not coming from your ISP GGC node.
There are too many variables its hard to tell what exactly caused your issues.
But generally speaking GGC nodes are very reliable, their support is responsive and knows what they are doing very well and most importantly it saves us insane amount of money (cause BW is expensive here), and our users are getting better service.
Yes of course, the main traffic is youtube bw, which I think its 95% of the total traffic going through ggc nodes. But the don't have a breakdown of their traffic on GGC dashboard. We know it because we know our traffic before we had GGC and after we had GGC.
You might still get content from closer to home, because YouTube might redirect the heavy HTTP request back to an edge node. (Check the source of the actual many megabyte response.)
This seems to be an improvement. You trust Google's network, and you get a HTTP/2 proxy. (Or if 443 is blocked, it falls back to HTTP/1.1.) Much better than browsing plain HTTP on a shared (corporate or not) wifi.
"Because requests to destination websites are sent from Google's servers, the IP address of the client making the connection will reflect the location of Google's servers, not the user. The DCP sends the IP address of the client in the X-Forwarded-For header with each request, for example: X-Forwarded-For: 74.125.239.111"
Web servers shouldn't blindly respect this X-Forwarded-For header coming from any random server.
Websites should use the X-Forwarded-For header to determine the IP address of the client for the purpose of IP geolocation.
I don't think they're suggesting you just assume that the IP is correct, only that if you are doing some kind of regional customisation that you can use that X-Forwarded-For header to help.
Yeah honestly. You'd naively think that with increased bandwidth, we'd be playing fewer backwards games. But you'd be wrong, because more traffic actually means it's more enticing for providers to engage in such "optimization".
We're at the point where the end-to-end principle really requires strong crypto to resist economic attacks such as this one.
So how hard would it be for a user to bypass a network block on encryption? Just redirect the URL given to a server that returns the right page (or doesn't exist)?
I would like to self-host something like this (plus ad-blocking) to minimise my mobile traffic consumption, any recommendations for a lightweight Linux VPS system?
First takeaway: SSL is optional? Let's the games begin! Better pay your ISPs on time, or God knows what they will accuse you of, extralegally or not, to get encryption turned off here.
Second takeaway: our company had major problems with upstream link from a local ISP to VPN across the Atlantic to the link on the other end and egress traffic out of our main office. It is really more than one, but you get the idea. The ISP in the US mentioned "caching problems" when we had many users with irritably high latency for Google servers: slow page loads, terribly syncing, crappy IMAP, but only for Google services we use. This data compression stuff seems limited. Does Google have boxes on-prem for ISPs a la Netflix that do the same thing or is improperly configuring this for an ISP enough to do damage?
https://openconnect.netflix.com/