Earlier quoted context omitted.
The DNS-Query or IP could be used to identify somebody accessing fast.com.
That still doesn't allow the ISP to tell the difference between e.g. wget and a browser via a current User-Agent-String, thanks to HTTPS. The domain is exposed over various ways, yes, but that's the point of the idea to connect to fast.com regularly to trick theoretical shaping based on it.
Building fast.com
131–140 of 180 posts
Re: Building fast.com
#132Earlier quoted context omitted.
Notice how speedtest.net selects a server geographically close to you? Well many ISPs work directly with speedtest.net (and other similar services) to ask them to put servers in their own networks, so that traffic avoids going through potentially saturated peering links. So you are really testing the bandwidth of the last mile to your house and the ISP's internal network, which is not representative of your real netw…
That's how it's supposed to be. Speedtest is measuring essentially that you're getting what you paid for. If you have 50/50 Fios, you're paying for a 50mbps connection to the Verizon network. > So you are really testing the bandwidth of the last mile to your house and the ISP's internal network, which is not representative of your real network bandwidth to the rest of the Internet. There's no such thing. If you were…
Yes there is. The Internet is not an abstract cloud with unlimited bandwidth everywhere. Your ISP runs their own network, peered with other bandwidth providers or other ISPs. You may have a 50 Mbps downlink from your ISP, but it doesn't mean the real-world usable bandwidth to all hosts on the Internet will be 50 Mbps, because your packets will be going through these peering links when they leave your ISP's network.
"How would your ISP have anything to do with that?"
Well, simply put some ISPs have terrible peering and/or intentionally throttle. So speedtest.net will show you awesome numbers, but in practice anything you download will be at much lower speeds. This matters, this is precisely why fast.com was built, and this is why the GGP is seeing different bandwidths when testing with speedtest.net vs. fast.com.
Re: Building fast.com
#133Earlier quoted context omitted.
They could block or override the A RR for fast.com so that a client can't connect.
The only times I use my ISP's DNS servers are when I initially set up a computer and forget to change the settings.
Re: Building fast.com
#134Testing for speed is great and all but is there an app or something that can monitor my Mac's end-to-end connectivity to an internet source? Like, I feel like my connectivity is spotty but am not sure if it's Wifi, Comcast or other.
Re: Building fast.com
#135It's a little odd that they elected to invent their own way of requesting just a range of bytes in a file. It's built into HTTP: https://tools.ietf.org/html/rfc7233
Can you set range headers from javascript? Can you set them from random video player SDKs?
Yes, see http://stackoverflow.com/questions/15561508/xmlhttprequest-2...
> Can you set them from random video player SDKs?
Good point, probably not.
Re: Building fast.com
#136This is beautiful. By using Netflix's actual CDN and requesting actual video files over HTTP, they're preventing ISPs from whitelisting fast.com without also whitelisting Netflix itself. Of course there'll be a game of cat-and-mouse with DPI, but it's a super-neat way of making it much harder for the ISPs to misrepresent actual video download speed...
Re: Building fast.com
#137This is beautiful. By using Netflix's actual CDN and requesting actual video files over HTTP, they're preventing ISPs from whitelisting fast.com without also whitelisting Netflix itself. Of course there'll be a game of cat-and-mouse with DPI, but it's a super-neat way of making it much harder for the ISPs to misrepresent actual video download speed...
Yeah right. Just wait until a user visits fast.com and unthrottle their connection for 20 minutes. I strongly suspect some ISPs already do that with speedtest.net.
Re: Building fast.com
#138This is beautiful. By using Netflix's actual CDN and requesting actual video files over HTTP, they're preventing ISPs from whitelisting fast.com without also whitelisting Netflix itself. Of course there'll be a game of cat-and-mouse with DPI, but it's a super-neat way of making it much harder for the ISPs to misrepresent actual video download speed...
Yeah right. Just wait until a user visits fast.com and unthrottle their connection for 20 minutes. I strongly suspect some ISPs already do that with speedtest.net.
Re: Building fast.com
#139What's stopping ISPs from slowing down other speedtests at the same rate as netflix to eliminate your ability to have a 'control'?
Re: Building fast.com
#140Looks like I've hit a case of IPv4 vs. IPv6. I recently noticed that fast.com starting showing me at about half my connection speed, 50Mbps. I only just now realised while looking at the traffic that it was doing it over IPv6. Disabling IPv6 in my network gets me a reported speed of 120Mbps on fast.com, which sounds about right for a 100/100 subscription + some burst. My ISP hasn't even officially announced any IPv6…