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
Most likely to make sure it works everywhere (browsers, proxies, etc)
Building fast.com
61–70 of 180 posts
Re: Building fast.com
#62It'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?
Re: Building fast.com
#63Fast.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.
It likely depends where the netflix servers are relative to you versus those used by other speed tests. For example, at my workplace in a big US city, I get about ~500Mpbs down from dlsreports, speedtest.net, and xfinity speedtest, because they are all using servers based in this city. Speedof.me and fast.com are not from what I can tell and give me download speeds between 200-300Mbps.
Re: Building fast.com
#64Earlier quoted context omitted.
I think the point was they conduct the speed test from the same servers that deliver video content. So ISPs can't throttle video streaming without it showing up in this speed test.
Makes sense but wouldn't they then use the netflix domain? Something like netflix.com/fast? I could image that if providers throttle it would be a mix of IPs and domain.
If you look they aren't using fast.com as the domain they are downloading files from. That's just the domain that hosts the page. It doesn't matter if it gets throttled because it only serves up a few kb of html.
Re: Building fast.com
#65Earlier quoted context omitted.
> It'd still be easy to selectively apply traffic shaping to streaming but not to the speedtest traffic. That presumes they aren't fully emulating streaming traffic to test speed. Not only is this the correct thing to do from a video streaming company that wants to test connection speed for their services (the quantity and size of packets can affect the delivery through different mediums and devices), but it also mak…
> That presumes they aren't fully emulating streaming traffic to test speed. It's not really a presumption, it's the actual facts on the ground. 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.
> 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 article or some other source that outlined this.
It would fairly trivial to send sample content of actual video content for the test, and emulate a streaming client on the tester side, so I'm not sure how an ISP would distinguish traffic in that situation.
Re: Building fast.com
#66You can also run fast.com from the command-line: https://github.com/sindresorhus/fast-cli
This is cool; just ran it, but I couldn't tell that it was doing anything. Maybe adding some soft of indicator/throbber that lets you know it's processing. fast | cat 860 Mbps
It shows an animated spinner if you don't redirect the output.
Re: Building fast.com
#67This 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...
Wow, I hadn't thought of that before! That really is genius.
Re: Building fast.com
#68It'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
Not that odd if you are trying to represent a chunk of a file with a single url, which would be desirable if you were serving video manifest/playlist files like m3u8 (HLS) or f4m (HDS). IIRC Netflix is using HDS.
Edit: not sure what format they are using, probably several depending on the client... But one url per chunk makes sense for multiple delivery formats as well.
Re: Building fast.com
#69I seem to be unable to view the blog post in Firefox, it automatically goes to https which doesn't load. Maybe netflix messed up their HSTS settings at some point in the past?
I'm also experiencing the same (also using HTTPS everywhere). Disabling the extension doesn't seem to work.
If you get a solution, please let me know.
Re: Building fast.com
#70I see this as a tool for netflix to immediately raise concerns about ISP neutrality. The link to another speed test (using some minor server) is there not by chance. If speed test is far better than netflix fast.com the ISP is clearly limiting the customer.
I wish that my ISP (Comcast) would throttle Netflix in the evening. My internet bandwidth gets reduced to 200 kbps during prime time (roughly 9 to 11 PM). It makes it challenging to work, especially if I need to stay connected to a VPN.