We could talk about Google Instant, but there really isn’t much to say about that product; you type a search query and Google pulls up results before you finish typing. Google Instant increases the number of search queries that hit Google servers by a factor of between five and seven, and will save people 350 million hours over the course of the year. The time savings assumes, of course, that people will not spend those hours testing out Google Instant, or programming instant editions of other web applications, such as Google Maps or iTunes.
Going back to the topic at hand, a savvy user might notice that downloads from Apple’s iTunes store practically fly over the Mines network, allowing a student to download TV shows and iTunes U lectures as quickly as their wireless or wired connection will allow. On the other hand, in my experience Comcast and Qwest connections are exceptionally bad at downloading iTunes content at a decent rate of speed, with Comcast being the worst offender. The nation’s largest ISP actually can’t seem to be able to download at more than twenty percent of its advertised speed from iTunes, though connectivity to other locations is more than adequate. But why?
iTunes uses a content delivery network, or CDN, to serve up files from iTunes. The idea behind a CDN is that you can serve files faster from several locations, each of them sporting a cluster of servers that is geographically close to the user downloading the content. From there, approaches diverge.
Apple’s CDN of choice is Akamai, which has been the gold standard for CDNs for years. Their modus operandi is to place clusters of servers on ISP networks in various locations, eliminating potential slowdowns due to crossing network borders. Akamai then works with ISPs so that when a user requests a file at an Akamai-powered address, the ISP’s DNS (Domain Name Service) servers return the IP (Internet Protocol) address of the cluster that is nearest them. If the cluster has cached the file that the user is requesting due to a previous download, downloads proceed very quickly. If not, the local cluster pulls the file from elsewhere as the user downloads it. The second scenario creates a bit of a performance hit, but unless you are connected via wireline on-campus the performance hit is negligible.
The above works well as long as each cluster has plenty of capacity to serve up files to its target user base, that target user base is using their ISP’s standard DNS servers and the number of uncached files is small. However if one or more of the above conditions are not met then download performance falters. If someone chooses to use the Mines DNS server while at home, for example, Akamai-based sites will try to pull from the Akamai cluster connected to the FRGP, with suboptimal results. If you use OpenDNS, results are similarly subpar. Even if the “expected” DNS server is chosen, internet routing, network congestion and a lack of cached content may render a download painfully slow, at least in relation to the capacity of the internet connection being used.
Other CDNs use a technique known as “anycasting,” where multiple servers in different locations share the same IP address. ISP routers pick the server that they think is closest to the user, and downloads continue from there. Anycasting is a relatively new technology, and the concept has issues of its own, but DNS issues are not one of them. Will Apple change to a CDN that uses anycasting rather than DNS-based cluster resolution technology? Probably not; Akamai is a name brand. That said, an alternate technology certainly exists, which is a good thing for everyone else wanting to push content to users at high speeds.
Where does that leave Comcast (and maybe Qwest) users who want to download a TV episode in less than forty-five minutes? At the whim of Apple, Akamai and their ISP to be honest. However there is some comfort in knowing that the problem is not on your side.
'Tech Break: Why is iTunes so slow?' has no comments
Be the first to comment this post!