Live data from Hacker News

Building fast.com

techblog.netflix.com

131–140 of 180 posts

Re: Building fast.com

#131
post #124
post #123

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.

List of supported ciphers is unencrypted and very UA-specific.

Re: Building fast.com

#132
post #120

Earlier 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…

"There's no such thing."

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

#133
post #110

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

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

Re: Building fast.com

#134
post #3

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

Try https://github.com/apenwarr/blip - built by google fiber guys for exactly this.

Re: Building fast.com

#135
post #62

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

Can you set range headers from javascript? Can you set them from random video player SDKs?

> Can you set range headers from javascript?

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

#136
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.

Re: Building fast.com

#137
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.

That would work for speed tests, but users will still get full HD streams suddenly (and reliably) downgrading to 320p after 20 minutes. That's still more likely to reflect negatively on the ISP than Netflix, I strongly suspect ;)

Re: Building fast.com

#138
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 may also just unthrottle for the first x MB of video.

Re: Building fast.com

#139

What's stopping ISPs from slowing down other speedtests at the same rate as netflix to eliminate your ability to have a 'control'?

Wouldn't your results show as being dramatically lower than your purchased speeds, then? That would backfire in a hurry :)

Re: Building fast.com

#140
post #71

Looks 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…

Chances are you are not running native IPv6. Most customers who "have access to IPv6" are running through IPv4 -> IPv6 conversion which adds immense overhead and is not a real indication of IPv6 to come. For all such customers, their pseudo-IPv6 will always be slower than IPv4. Most ISPs do not run any form of native IPv6 yet.
Post reply on HN