Building fast.com • Hacker News Board

Re: Building fast.com

#161

Post by kev009 » Wed, Aug 10, 2016, 6:41 AM UTC

IshKebab wrote: post #73

nippoo wrote: post #60

This 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.

As someone who works on multi-terabit networks, this would be very difficult for most network operators to handle. Don't overestimate the competence for malice here. Usually the tactics of shitty ISPs are much more simple, such as not lighting up peering ports that their eyeball customers are in effect paying for.

Re: Building fast.com

#162

Post by toxik » Wed, Aug 10, 2016, 7:31 AM UTC

donavanm wrote: post #153

zackbloom wrote: post #40

It'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

As others have mentioned "ranges" are put in the uri stem & query string for two reasons; evading mangling proxies and simpler access from browsers/clients. From memory notable implementarions are MPEG DASH, action script/flash, icecast, and various proprietary "services". The formats that send time ranges instead of bytes ranges are the worst. In that case the server/cdn has to retrieve & read the manifest, decode t…

I mean I see the benefit, but any semi-competent proxy already caches based on the Vary header, and also the range header (per the HTTP 1.1 specification.) It shouldn't be a problem. Also query strings are per definition part of the URL.

Re: Building fast.com

#163

Post by timlyo » Wed, Aug 10, 2016, 7:52 AM UTC

cocoflunchy wrote: post #20

Fast.com is a lot slower than both speedtest.net and http://speedtest.dslreports.com/speedtest for me... I get 78mbps on fast.com and 350 on the other two. Not sure what's going on? Maybe they don't have servers near me, I'm in Paris, France.

Try google's and see what you get from them.

https://encrypted.google.com/search?hl=en&q=speed%20test

Re: Building fast.com

#164

Post by Morpheus79 » Wed, Aug 10, 2016, 8:06 AM UTC

Nice and I think they really benefit on their existing infrastructure.

But tests shows 5mbits for me and all other 30+ (real). So not really a great help till now.

Re: Building fast.com

#165

Post by dboreham » Wed, Aug 10, 2016, 8:22 AM UTC

IshKebab wrote: post #73

nippoo wrote: post #60

This 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.

They don't need to : they just host a speedtest.net server on their own network, which the client will select by default.

Re: Building fast.com

#166

Post by olejorgenb » Wed, Aug 10, 2016, 8:33 AM UTC

levbrie wrote: post #136

nippoo wrote: post #60

This 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...

It is beautiful, and even if it weren't harded to misrepresent video download speeds, it's a significant step up from speedtest.net. And now there's no need to leave the command line, which is even better. That said, perhaps "making it slightly harder... to misrepresent... video download speed" is more like it.

https://github.com/sivel/speedtest-cli

Re: Building fast.com

#167

Post by corobo » Wed, Aug 10, 2016, 10:14 AM UTC

staunch wrote: post #133

corobo wrote: post #110

Earlier quoted context omitted.

The only times I use my ISP's DNS servers are when I initially set up a computer and forget to change the settings.

Yeah but unless you tunnel your DNS traffic they can modify responses very easily. Not that this is super common yet.

At a certain point if they're going out of their way to mess with the connection I'm paying for I'll stop paying for it and go elsewhere.

Re: Building fast.com

#168

Post by corobo » Wed, Aug 10, 2016, 10:18 AM UTC

zeristor wrote: post #159

IceyEC wrote: post #56

Earlier quoted context omitted.

The files that fast.com has you download ARE chunks of video files :)

Does anyone know which video the test file is? Perhaps it's encrypted, or a Netflix promo piece. Wouldn't there be copyright issues to use their actual streaming licences content?

If you have a Netflix subscription it's probably this or something like this [1]. For non-flixers it's a calibration video similar to [2]

[1] https://www.netflix.com/watch/80103278

[2] https://www.youtube.com/watch?v=cGgf_dbDMsw

Re: Building fast.com

#169

Post by MertsA » Wed, Aug 10, 2016, 11:33 AM UTC

scrollaway wrote: post #119

jdavis703 wrote: post #117

Earlier quoted context omitted.

Make sure you update your user agent string to the latest Chrome every couple of weeks too. (I'm assuming any ISP doing this is already doing all kinds of sneaky things).

Since fast.com is https, the headers are encrypted. Correct me if I'm wrong, but unless the ISP has the CAs private keys they wouldn't be able to tell your user agent.

The CAs private keys can't be used to decrypt https. All the CA does is sign your public key in a certificate that shows validity and the domain name.

Re: Building fast.com

#170

Post by MertsA » Wed, Aug 10, 2016, 11:36 AM UTC

dingo_bat wrote: post #143

IshKebab wrote: post #73

Earlier quoted context omitted.

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.

We need a speedtest website hosted on tor :D Then ISPs won't be able to know when you visit the site.

Tor is over an order of magnitude too slow for this to work. You might get a result, but that doesn't tell you much about the speed of your internet connection.