Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Building fast.com

techblog.netflix.com

Post reply on HN
Print view View original

101–110 of 180 posts

Re: Building fast.com

#101

Post by rhino369 »

virtuallynathan wrote: post #88
Citrus2fizz wrote: post #74

Hows this for a discrepancy https://i.imgur.com/7SX2Wro.png

This is a bit of an unfair test, as it is not in Netflix's best interest to provision enough CDN capacity for any user to hit 1Gbps, especially at peak times. Netflix wants to buy/provision just enough capacity so that users don't complain. Depending on the distribution of the users in the area, this could 5Mbps per user, or 15Mbps per user for a large amount of 4K streamers. Netflix pushes their CDN nodes to the lim…

If they aren't going to act like a speed test server, they shouldn't advertise it. Not that netflix is the only potential weak link between the person and fast.com.

Re: Building fast.com

#102

Post by jlgaddis »

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

They could block or override the A RR for fast.com so that a client can't connect.

Re: Building fast.com

#103

Post by brazzledazzle »

Citrus2fizz wrote: post #74

Hows this for a discrepancy https://i.imgur.com/7SX2Wro.png

That's pretty dramatic. I wonder if they throttle, won't increase peering bandwidth and won't allow them to deploy an OCA within their networks like Verizon is/did? Could be that the connection is simply tapped out and they're trying to play hardball with Netflix. It is hosted on exactly the same infrastructure and served over the same network links after all.

Re: Building fast.com

#104

Post by JoshTriplett »

a1k0n wrote: post #94
douglasfshearer wrote: post #44

Earlier quoted context omitted.

YouTube also put the byte range in the URL rather than using a range request header. Perhaps it mitigates against proxies stripping the headers, or it simplifies caching.

I tried to use the Range header feature to resume downloads in an autoupdating app once, and it worked beautifully...for about 90% of users; the others had all kinds of weird issues thanks to transparent proxies and caches not handling the Range header correctly. This was years ago, but I'm not surprised they chose to be safer than sorry.

> I tried to use the Range header feature to resume downloads in an autoupdating app once, and it worked beautifully...for about 90% of users; the others had all kinds of weird issues thanks to transparent proxies and caches not handling the Range header correctly.

One of many reasons to use HTTPS: prevent tampering with your requests and responses.

Re: Building fast.com

#105

Post by shoyer »

virtuallynathan wrote: post #88
Citrus2fizz wrote: post #74

Hows this for a discrepancy https://i.imgur.com/7SX2Wro.png

This is a bit of an unfair test, as it is not in Netflix's best interest to provision enough CDN capacity for any user to hit 1Gbps, especially at peak times. Netflix wants to buy/provision just enough capacity so that users don't complain. Depending on the distribution of the users in the area, this could 5Mbps per user, or 15Mbps per user for a large amount of 4K streamers. Netflix pushes their CDN nodes to the lim…

FWIW, I just clocked in at 780 Mbps on fast.com.

Re: Building fast.com

#106

Post by brazzledazzle »

jsnell wrote: post #75
kbenson wrote: post #65

Earlier quoted context omitted.

> The actual benchmark file is served over HTTPS from, but there are still multiple simple ways to distinguish the current speedtest testcase from normal streaming. Do you mind explaining the details you are aware of that lead you to think they are not emulating streaming traffic in at least some portion of their test (since they are testing multiple sessions and types of traffic)? I may have missed a portion of this…

Sure. One example is that someone doing a speedtest will have accessed fast.com before starting a download of video streams. This can be detected despite the the encryption, e.g. via looking at the SNI of the requests. It doesn't matter what the video stream looks like, since those separate TCP flows can be cross-correlated.

Netflix could load something from fast.com on each Netflix navigation right?

Ultimately if they're playing cat to Netflix's mouse how much does each mitigation strategy cost them relative to Netflix? I wonder if it's more cost effective to process that much traffic through shapers than it is to increase bandwidth between peers or allow Netflix to drop their boxes within their networks.

Re: Building fast.com

#107

Post by brazzledazzle »

greenspot wrote: post #26
greenspot wrote: post #11

First, I thought why another speed test, then I saw that they link their results directly to speedtest.net (the reference) and finally, I realized that fast.com is so much faster in detecting the download speed (but lacks upload and ping). Not bad. EDIT: And they secured a fantastic domain.

Since they took this precious domain, I was wondering about the purchase price and if it was worth to buy this awesome domain—we are talking here about a mid six digit at least, rather seven digits. Then, I checked how much traffic speedtest.net is getting on SimilarWeb: wow, 150m visits per month, I didn't know that speed testing can be so popular. Conclusion: Yes, it was right to buy this domain and if fast.com get…

They also have a pretty simple way to show end users that their ISPs are either throttling them or being uncooperative with Netflix. I'm not sure what it will do to monopolies, if anything, but it could apply significant indirect pressure to a lot of ISPs.

Re: Building fast.com

#108

Post by chrissnell »

Citrus2fizz wrote: post #74

Hows this for a discrepancy https://i.imgur.com/7SX2Wro.png

You're on Centurtlink Fiber I see. I had a very similar experience with them. I switched back to biz class Comcast, which was far superior/faster in almost every area, even though ostensibly slower.

Re: Building fast.com

#109

Post by corobo »

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.

That'd actually be great. The moment there's any evidence towards that happening I'm adding a cron script to visit fast.com every 15 minutes.

Re: Building fast.com

#110

Post by corobo »

jlgaddis wrote: post #102
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...

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.
Post reply on HN