The purpose of an origin server is to process and respond to incoming Internet requests from Internet clients. The concept of an origin server is typically used in conjunction with an edge server or caching server. At its core, an origin server is a computer running one or more programs that are designed to listen for and process incoming Internet requests. An origin server can take on all the responsibility of serving up the content for an Internet property, such as a website, provided that the traffic does not extend beyond what the server is capable of processing and latency is not a primary concern.
The physical distance between an origin server and a client making a request adds latency to the connection, increasing the time it takes for an internet resource such as a webpage to be loaded. The additional round-trip time (RTT) between the client and origin server required for a secure Internet connection using SSL/TLS also adds additional latency to the request, directly impacting the client’s experience requesting data from the origin. By using a content delivery network (CDN) round-trip time can be reduced, and the number of requests to an origin server is also able to be reduced.
What is the difference between an origin server and a CDN edge server?
CDN edge servers are computers placed in critical junctures between significant Internet providers in locations across the globe to deliver content as quickly as possible. An edge server lives inside a CDN on the “edge” of a network and is specifically designed to process requests quickly. By strategically placing edge servers inside of the Internet exchange points (IxPs) between networks, a CDN can reduce the time it takes to get to a particular location on the Internet.
These edge servers cache content to take the load off one or more origin servers. By moving static assets like images, HTML, and JavaScript files (and potentially other content) as close as possible to the requesting client machine, an edge server cache can reduce the time it takes for a web resource to load. Origin servers still have an essential function when using a CDN, as necessary server-side code, such as the database of hashed client credentials used for authentication, is typically maintained inside an origin server.
Here’s a simple example of how an edge server and an origin server work together to set up a login page and allow users to log in to a service. A straightforward login page requires the following static assets to be downloaded for the webpage to render correctly:
- An HTML file for the webpage
- A CSS file for the webpage styling
- Several image files
- Several JavaScript libraries
These files are all static files; they are not dynamically generated and are the same for all visitors to the website. As a result, these files can be cached and served to the client from the edge server. All these files can be loaded closer to the client machine and without any bandwidth consumption by the origin.
Next, when the user enters their login and password and presses “login,” the request for dynamic content travels back to the edge server and then proxies the request back to the origin server. The origin then verifies the user’s identity in the associated database table before returning the specific account information.
This interplay between edge servers handling static content and origin servers serving dynamic content is a typical separation of concerns when using a CDN. The capability of some CDNs can also extend beyond this simplistic model.
Can an origin server still be attacked while using a CDN?
The short answer is yes. A CDN does not render an origin server invincible, but when used properly it can render an origin server invisible, acting as a shield for incoming requests. Hiding the actual IP address of an origin server is an essential part of setting up a CDN. As such, a CDN provider should recommend that the IP address of the origin server be changed when implementing a CDN strategy to prevent DDoS attacks from going around the shield and hitting the origin directly.
