text: For example, until recently, Varnish did not offer native HTTPS termination, which is a no-go, but has long offered a separate TLS proxy, Hitch, which is a standalone service that sits in front of Varnish. In most cases this provided (and still provides) exceptional performance (up to 100Gbps) and additional benefits running as a separate process from Varnish itself, having its own address space in memory separate from the Varnish process.
  Another very common alternative for Varnish Cache users is to add NGINX to the mix as a TLS terminator in front of Varnish as a backend web server.
  Problems with NGINX as alternative SSL/TLS terminator
  NGINX is sometimes used to cache content, but it isn't NGINX's main focus or strength. But because many users choose NGINX for HTTPS traffic, and have installed it in front of Varnish Cache to perform HTTPS to HTTP decryption conversion as needed, this is often the alternative users find when they search for TLS termination solutions for Varnish. Introducing a third-party technology into the setup adds an unneeded layer of architectural and network complexity and reduced efficiency.
  Figure 1: TLS termination before built-in TLS - Extra layer or third-party tool required for TLS support (Hitch, NGINX or other)
  Introducing in-process TLS in Varnish Enterprise
  We've introduced a complete, in-core, native TLS solution to the latest Varnish Enterprise release, resulting in a simplified setup for better HTTPS throughput and lower latency. In the face of growing high-resource traffic demands, stripping an architecture down to streamline it for its greatest efficiency by eliminating the "middleman" TLS terminator is just what high-speed content delivery, particularly in the telecoms and media streaming sectors, demands.
  Figure 2: TLS supported directly in the core of Varnish Enterprise
  With this new release, you no longer need an external TLS terminator. Of course, we'll continue to support the Hitch TLS proxy because for many users, it's the right choice, and 100Gbps via Hitch that they achieve is still a high-performance result that matches their needs. Yet as we charge forward into an era in which high performance alone isn't enough, it is more a matter of deciding what architecture best meets your needs.
  Performance at scale with in-process TLS
  Video dominates internet traffic, and video use cases call for future-proof high-speed content delivery to very large, often global, audiences, including HD video. Performance - speed and latency - is key, and certain use cases require extreme performance at scale. They also require a much higher level of resource-use efficiency, achieving more with less.
  Gaining a competitive edge for content providers in this demanding environment depends on constant speed and latency gains (well in excess of 100Gbps) that go hand in hand with optimal resource use, efficiency and simplicity. Taking a middleman TLS solution out of the equation streamlines the process, leading to extreme performance enhancements at scale. The extra layer between the content request and the cache inevitably adds latency. In a video delivery situation, for example, we can ill-afford that delay.
  Our initial testing of built-in TLS in Varnish Enterprise, as well as external testing, indicates that in-process TLS delivers 150Gbps or more from a single server with dual 100 Gbps interfaces, up from 100 Gbps with an external TLS process.
  Go native: Making the switch
  If you're using Varnish Cache and are seeking a more efficient, high-powered content delivery solution, you can easily switch to Varnish Enterprise to go native with your TLS. TLS is a part of the Varnish Enterprise package and is ready to use from the moment you install Varnish Enterprise. Install, configure and avoid third-party workarounds to get the fastest, most resource-efficient solution on the market. Get in touch to find out more.
  Topics: TLS/SSL, HTTPS, caching for web performance, cache encryption, cache control, low-latency, Varnish Enterprise 6, in-process TLS