Jare.io, touted as a free Content Delivery Network (CDN), is essentially a wrapper over Amazon’s CloudFront. It can be used for quickly trying out a CDN for low traffic situations when the hassle of configuring CloudFront outweighs the benefits.
CloudFront is not free, but the company behind Jare.io’s creator, teamed.io pays for the CloudFront usage. The CDN domain for Jare, cf.jare.io points to CloudFront distribution domains. When a request reaches CloudFront for the first time on cf.jare.io, CloudFront forwards it to the Jare.io server, which acts as the ‘origin’ or the server from which the content originates. Jare.io in turn fetches the content from the actual origin and that has to be specified as part of integrating jare.io.
Some of the points that matter while choosing a CDN include
- Number of Points of Presence (POPs) across the globe
- Protection against Distributed denial-of-service (DDOS) attacks
- Content invalidation and propagation time
- API support
- Support for HTTPS
Content Delivery Networks maintain global POPs so that static content can be served to users from a location which is closer to them, thus minimizing latency. The measurement of closeness can be either geographic, the number of network hops, or the round trip time (RTT) between the user and the POP. The content is cached at the POPs after fetching it from the origin. InfoQ reached out to some of the major CDN vendors to ask about their technology.
CDN vendors use one of DNS Unicast or Anycast routing to ensure that the user’s request is served from the nearest location. The user’s request is typically for a custom domain like cdn.infoq.com, which is mapped to the CDN vendor’s hosts. When Unicast is used, the DNS server is responsible for returning the address of the CDN node closest to the user.
With Anycast, multiple nodes can have the same IP address. When a request is made, DNS resolves the domain name to an IP address, and routing takes care of sending the request to the node that is topologically nearest to the user. Topologically nearest may not translate to geographically nearest. Anycast can be used for both DNS (locating the nearest name server) and HTTP (locating the nearest POP with the content).
In case of HTTP Anycast, the DNS server returns the same IP address for all users, and the Border Gateway Protocol (BGP) takes care of routing the user to the nearest server with that IP address. BGP is a standard protocol used to exchange routing information on the internet.
Vendors like MaxCDN use a combination of Anycast and DNS routing. Verizon, which acquired EdgeCast in 2013, uses Anycast for both DNS and HTTP. HTTP Anycast is also used by Fastly and Google. Akamai has a more complex setup with DNS Anycast.
In recent years there have been various efforts to make the internet (or rather the World Wide Web) faster. The key protocol of the Web - HTTP - has recently seen an upgrade - HTTP/2. Only a few CDNs support it at the moment but it should increase in the coming months as most browsers have added support for it. Vendors like Verizon and Fastly are working towards supporting it.
Another improvement that has been around for a while has been to increase the initial congestion window (initcwnd) in the TCP protocol. The initcwnd setting controls the maximum number of packets sent out by a server that can remain unacknowledged (before it can send out more). The default value in older versions of operating systems including Linux was very low. A low value impacts how fast browsers receive the response from the server irrespective of how high the bandwidth available is. First proposed in a Google paper in 2010 and later as an RFC in 2013, an increased value has been adopted by most major CDN vendors.
While Akamai leads the pack in terms of maximum points of presence, most of the other CDN vendors are not behind in terms of features offered.
