How Netflix Open Connect Delivers 15% of the World’s Internet Traffic: The Complete Technical Deep Dive

The Invisible Infrastructure Powering Your Friday Night Binge

Every evening, roughly 230 million paid subscribers across 190+ countries press play on a Netflix title. What most of them never see—what nobody is supposed to see—is the staggering engineering feat happening in the milliseconds between that button press and the first frame appearing on screen. Netflix doesn’t simply stream video from a centralized data center the way a small website serves pages from a single server. Instead, it relies on a proprietary, globally distributed content delivery infrastructure called Netflix Open Connect, a system so efficient and so massively scaled that it accounts for approximately 15% of all downstream internet traffic worldwide during peak hours, according to data from Sandvine’s Global Internet Phenomena Report and corroborated by multiple network measurement studies.

To put that figure into perspective: Netflix’s Open Connect moves more data across the planet than the entire combined downstream traffic of YouTube, Facebook, Instagram, and every major news website in several regional markets. It is, by virtually every measurable metric, the single largest consumer-facing content delivery operation ever constructed by a private company. And unlike traditional Content Delivery Networks (CDNs) such as Akamai, Cloudflare, or Fastly—which are multi-tenant platforms serving thousands of clients—Open Connect is a single-purpose, vertically integrated delivery network designed exclusively to move Netflix video from storage to screen with minimal latency, minimal buffering, and minimal cost.

This article dissects every layer of that system: the custom hardware, the FreeBSD-based software stack, the encoding pipeline, the routing architecture, the ISP peering relationships, the predictive content-placement algorithms, and the protocol-level decisions that collectively allow Netflix to push exabytes of video data across the global internet while making it feel, to the end user, as effortless as turning on a faucet.

Why Netflix Built Its Own CDN Instead of Renting One

When Netflix completed its migration from DVD-by-mail to streaming in the early 2010s, it initially relied on third-party CDNs—primarily Akamai and Limelight Networks—to distribute video to end users. The arrangement worked at first, but Netflix’s traffic growth was exponential and showed no signs of plateauing. By 2011, Netflix was already consuming a measurable slice of North American bandwidth, and the per-gigabyte transit costs charged by traditional CDN providers were becoming economically unsustainable at Netflix’s scale.

More critically, Netflix’s engineering team, led by VP of Content Delivery Dave Temkin (who had previously architected content delivery at YouTube), identified a fundamental architectural mismatch. Traditional CDNs are designed for generality: they cache web pages, software downloads, API responses, and video for thousands of different customers. That generality introduces overhead—multi-tenant scheduling, generalized caching logic, and routing decisions optimized for diverse workloads. Netflix’s workload, by contrast, is remarkably uniform: large video files, read-heavy, with predictable demand patterns driven by a curated catalog. A purpose-built system could exploit that uniformity to extract performance and cost efficiencies that a general-purpose CDN simply could not.

In October 2012, Netflix publicly launched Open Connect. The initial deployment was modest by today’s standards, but the architectural thesis was clear: build custom hardware, run custom software, place the hardware as close to the end user as physically possible (inside ISP networks and at Internet Exchange Points), and eliminate every unnecessary hop, cache lookup, and protocol overhead between the stored video file and the viewer’s device.

The Open Connect Appliance: Custom Silicon for a Custom Problem

At the heart of Open Connect sits the Open Connect Appliance (OCA), a custom-designed server that Netflix builds in-house and ships to partner ISPs and IXPs around the world. Netflix does not use off-the-shelf Dell or HPE servers for this purpose. The OCA is purpose-engineered from the motherboard up, and understanding its design reveals a great deal about how Netflix thinks about the storage-to-streaming pipeline.

Storage Density and Tiered Architecture

The earliest OCAs were configured with large-capacity HDDs optimized for storing vast libraries of encoded video. As Netflix’s catalog and encoding quality grew—particularly with the introduction of 4K UHD, HDR, and Dolby Atmos audio tracks—storage requirements per title increased dramatically. Netflix responded by evolving the OCA hardware through multiple generations. Modern OCAs use a tiered storage architecture: high-performance NVMe SSDs hold the most popular titles (the “hot” content layer), while high-capacity HDDs store the long tail of the catalog. This tiering is not arbitrary; it is driven by Netflix’s internal demand-forecasting models, which predict which titles will be requested in which geographic regions over the coming hours and days.

A single OCA can store tens of terabytes of encoded video, and Netflix deploys these appliances in configurations ranging from a single box at a smaller ISP to clusters of dozens of appliances at major IXPs like DE-CIX in Frankfurt, AMS-IX in Amsterdam, or Equinix exchanges in Ashburn, Virginia. Netflix has publicly stated that it operates thousands of OCA locations across the globe, and the total number of individual appliances numbers in the many thousands.

The Operating System: FreeBSD, Not Linux

One of the most technically distinctive choices Netflix made for Open Connect is the operating system. OCAs run FreeBSD, not Linux. Netflix engineers have explained this choice in multiple conference talks (notably at BSDCan and Netflix Tech Blog posts). FreeBSD’s networking stack, its mature TCP implementation, its kernel-level network interface handling, and its permissive BSD license (which allows Netflix to modify and redistribute the OS without open-sourcing proprietary additions) made it the ideal foundation. Netflix maintains its own FreeBSD-derived image, tuned specifically for the OCA workload: high-throughput sequential reads from storage, TLS termination, and TCP/QUIC delivery over high-speed network interfaces.

The web server layer on top of FreeBSD is a heavily customized build of Nginx, modified by Netflix’s engineers to handle the specific streaming patterns of Open Connect—range requests for segmented video, connection management under extreme concurrency, and integration with Netflix’s internal health-checking and telemetry systems.

Network Interfaces and Throughput

OCAs are equipped with high-speed network interface cards, typically 100 GbE (100 Gigabit Ethernet) in current-generation deployments, though earlier generations used 10 GbE and 40 GbE. The goal is to ensure the appliance is never the bottleneck. At peak evening hours, a heavily loaded OCA at a major metro IXP can saturate its uplinks, which is precisely why Netflix deploys multiple appliances in parallel and uses sophisticated load-balancing across them.

Placement Strategy: Inside the ISP and at the Exchange Point

Where you physically put a server determines how many network hops, how much latency, and how much inter-carrier transit cost stand between that server and the viewer. Netflix’s placement strategy for OCAs is a two-pronged approach, and it is arguably the single most important factor in Open Connect’s performance and economics.

Embedded OCAs at ISPs

Netflix negotiates agreements with Internet Service Providers—cable operators, telcos, fiber providers, and mobile carriers—to physically install OCAs inside the ISP’s own network, often in the same facilities where the ISP’s edge routers and aggregation switches reside. When a Netflix subscriber on, say, Comcast or Deutsche Telekom requests a video, the traffic can be served entirely within the ISP’s network, never traversing a paid transit link or crossing an inter-carrier peering boundary. This is called embedded deployment, and it is the gold standard for delivery efficiency. The viewer’s request travels from their home router through the ISP’s access network directly to the OCA sitting in the ISP’s data center, often just a few network hops away.

Netflix offers these appliances to ISPs at no cost. The ISP provides rack space, power, and a network port; Netflix provides the hardware, the software, and the content. The ISP benefits because serving Netflix traffic locally reduces the bandwidth it must purchase from upstream transit providers. Netflix benefits because it eliminates transit costs and reduces latency. It is a symbiotic arrangement, and Netflix has publicly stated that the vast majority of its traffic is served from embedded OCAs.

IXP-Based OCAs

In regions or with ISPs where an embedded deployment is not feasible—either because the ISP declines the partnership or because the ISP is too small to justify a dedicated appliance—Netflix serves traffic from OCAs installed at Internet Exchange Points (IXPs). IXPs are neutral facilities where multiple networks interconnect and exchange traffic via BGP peering. By placing OCAs at major IXPs, Netflix can serve multiple smaller ISPs simultaneously through a single peering port, dramatically reducing per-ISP deployment overhead while still keeping the traffic path short.

Netflix is consistently one of the top traffic contributors at major IXPs worldwide. At exchanges like DE-CIX, Netflix’s Open Connect traffic regularly appears among the top five sources by volume.

The Encoding Pipeline: From Master File to Adaptive Bitrate Ladder

Before a single byte of video ever reaches an OCA, it passes through one of the most sophisticated encoding pipelines in the entertainment industry. Netflix does not simply encode a movie at one resolution and one bitrate. It encodes every title into a ladder of renditions—multiple resolutions, multiple bitrates, multiple codec choices—so that the player on the viewer’s device can dynamically select the best version for the current network conditions.

Per-Title Encoding and Shot-Based Encoding

In 2015, Netflix introduced Per-Title Encode Optimization, a technique that abandons the traditional one-size-fits-all bitrate ladder. Instead of assigning, say, 5 Mbps to every 1080p stream regardless of content, Netflix’s encoding system analyzes the visual complexity of each title individually. A quiet dialogue drama with static camera shots requires far fewer bits than an action sequence with explosions, fast panning, and particle effects. Per-title encoding adjusts the bitrate ladder per title, reducing bandwidth for simpler content and allocating more bits where the visual complexity demands it.

Netflix pushed this further with Shot-Based Encoding, which analyzes individual shots within a title and adjusts encoding parameters at the shot level. A two-hour film might contain hundreds of shots, each with different motion characteristics, color complexity, and detail density. By encoding each shot optimally, Netflix reduces the overall file size without perceptible quality loss—a critical advantage when you are delivering at the scale of 15% of global internet traffic.

Codec Support: H.264, HEVC, VP9, and AV1

Netflix supports multiple video codecs to maximize compatibility and efficiency across devices:

• H.264/AVC: The baseline codec, supported by virtually every device manufactured in the last 15 years.
• HEVC (H.265): Roughly 40-50% more efficient than H.264 at equivalent quality. Widely supported on modern smart TVs, streaming sticks, and mobile devices.
• VP9: An open, royalty-free codec developed by Google, supported primarily on Android devices and Chrome/Firefox browsers.
• AV1: The newest codec in Netflix’s arsenal, developed by the Alliance for Open Media (of which Netflix is a founding member). AV1 offers roughly 30% better compression than VP9 and HEVC at equivalent quality. Netflix has been aggressively expanding AV1 encoding across its catalog, and it now serves a substantial and growing percentage of streams in AV1, particularly on smart TVs, Android devices, and supported browsers.

Netflix also encodes audio in multiple formats, including AAC, Dolby Digital Plus (E-AC-3), and Dolby Atmos for supported titles and devices.

The Encoding Infrastructure

The encoding itself is performed in Netflix’s cloud infrastructure, primarily on AWS (Amazon Web Services). Netflix has been one of AWS’s largest customers for over a decade. When a new title is ingested—whether it is a Netflix Original or a licensed film—it is uploaded to cloud storage, processed through the encoding pipeline, and the resulting hundreds or thousands of segmented video files are then distributed to OCAs worldwide based on the demand-forecasting algorithms.

Content Placement and Demand Forecasting

Netflix does not simply replicate its entire catalog to every OCA on the planet. The catalog is enormous—thousands of titles, each encoded into dozens of renditions—and the storage on any single OCA, while large, is finite. Netflix’s content placement algorithms decide which titles and which renditions are stored on which appliances, and these decisions are driven by predictive models.

These models take into account:

• Regional viewing trends: A Korean drama trending in Seoul will be prioritized on OCAs embedded in Korean ISPs. A Spanish-language series popular in Mexico will be pre-positioned on Mexican and Latin American appliances.
• Time-of-day patterns: Netflix knows when peak viewing hours occur in each time zone and can pre-stage content accordingly.
• New release schedules: When a major Netflix Original drops (a new season of Stranger Things, for example), the system anticipates a massive surge in demand and ensures the title is available on OCAs in every relevant market before the release time.
• Device and codec distribution: If a particular region’s subscriber base skews heavily toward older smart TVs that only support H.264, the placement algorithm ensures H.264 renditions are prioritized on the OCAs serving that region.

The result is a proactive, predictive caching model rather than a reactive one. By the time a viewer in Mumbai presses play on a newly released film, the encoded segments are already sitting on an OCA inside their ISP’s network, perhaps just two or three router hops away. There is no need to fetch the content from a distant origin server. The latency is measured in single-digit milliseconds.

Routing, Peering, and the BGP Layer

At the network layer, Open Connect relies on standard internet routing protocols, but Netflix’s implementation is carefully engineered.

Each OCA or cluster of OCAs is assigned IP address space, and Netflix announces these prefixes via BGP (Border Gateway Protocol) to the networks where the OCAs are deployed. For embedded deployments inside an ISP, the OCA’s IP prefix is typically announced within the ISP’s own routing domain, making the OCA appear as a local resource. For IXP-based deployments, Netflix announces its prefixes to the IXP’s route servers and to individual peers.

Netflix also employs anycast routing for certain control-plane and DNS functions, though the actual video delivery from OCAs is typically unicast—the viewer’s device connects to a specific OCA IP address determined by Netflix’s DNS and traffic-steering systems. When a Netflix client app initiates playback, it contacts Netflix’s backend services, which return the URL of the video segments. Those URLs point to a specific OCA selected based on the client’s network location, the OCA’s current load, and the health of the network path.

Netflix operates its own DNS infrastructure and uses sophisticated traffic steering logic to direct clients to the optimal OCA. If an OCA becomes overloaded or experiences a hardware fault, traffic is automatically redirected to the next-best appliance. This failover is seamless to the viewer.

The Streaming Protocol Stack: From TCP to QUIC

The transport protocols used by Open Connect have evolved significantly over the years.

HLS and DASH

Netflix delivers video using adaptive bitrate streaming protocols, primarily MPEG-DASH (Dynamic Adaptive Streaming over HTTP) for most devices and HLS (HTTP Live Streaming) for Apple devices. In both cases, the video is segmented into small chunks (typically 2-10 seconds each), and the client player downloads these chunks sequentially over HTTP(S). Between chunks, the player measures the available bandwidth and buffer depth and selects the appropriate rendition for the next segment. If the network degrades, the player drops to a lower bitrate; if the network improves, it steps up. This is why Netflix video quality can visibly shift during a stream—it is the adaptive algorithm responding in real time.

TLS Encryption

All traffic between the OCA and the viewer’s device is encrypted using TLS (Transport Layer Security), typically TLS 1.2 or TLS 1.3. Netflix was an early and aggressive adopter of TLS 1.3, which reduces the handshake latency and improves connection setup times. The encryption is terminated at the OCA itself (not at a separate load balancer), which minimizes processing hops.

TCP vs. QUIC

Historically, Netflix has used TCP as the transport protocol for video segment delivery. TCP’s reliability and congestion control are well-suited to large sequential file transfers, and Netflix has invested heavily in tuning TCP parameters on its FreeBSD-based OCAs—adjusting buffer sizes, congestion window behavior, and pacing algorithms to maximize throughput without causing network congestion.

More recently, Netflix has been exploring and deploying QUIC, the UDP-based transport protocol developed by Google and standardized by the IETF as the foundation for HTTP/3. QUIC offers several advantages for streaming: faster connection establishment (0-RTT resumption), built-in encryption, multiplexing without head-of-line blocking, and improved behavior on lossy or high-latency networks (such as mobile networks). Netflix engineers have discussed their QUIC experimentation in public talks and blog posts, signaling a gradual transition toward QUIC for at least a portion of their delivery traffic.

Scale by the Numbers

The sheer scale of Open Connect is difficult to overstate, and Netflix has shared select figures over the years:

• Netflix accounts for approximately 15% of global downstream internet traffic during peak hours, per Sandvine and similar network analytics firms. In some individual markets, that figure has exceeded 30-40%.
• Netflix delivers hundreds of billions of hours of video per year.
• The Open Connect network spans thousands of locations across 190+ countries.
• Netflix’s encoding pipeline produces hundreds of renditions per title, and the total stored content across all OCAs represents exabytes of data.
• During major release events (a new season of a flagship series, a high-profile film premiere), Netflix’s traffic can spike by double-digit percentages within hours, and the Open Connect infrastructure is designed to absorb these spikes without degradation.

How Open Connect Differs from Traditional CDNs

It is worth explicitly contrasting Open Connect with commercial CDNs, because the differences are architecturally profound.

Feature	Netflix Open Connect	Traditional CDN (e.g., Akamai, Cloudflare)
Purpose	Single-tenant, Netflix video only	Multi-tenant, serves thousands of clients
Hardware	Custom-built OCAs	Commodity or semi-custom servers
OS	FreeBSD (custom image)	Typically Linux
Placement	Embedded inside ISPs + IXPs	Primarily at IXPs and colocation facilities
Cost model	Netflix provides hardware free to ISPs	CDN charges per GB or per request
Content type	Video only (large files, sequential reads)	Web pages, APIs, downloads, video, etc.
Caching logic	Predictive, demand-forecast driven	Reactive, request-driven
Encoding	Done in-house by Netflix	Done by the content provider

The single-tenant design is the key differentiator. Because Open Connect serves only Netflix video, every layer of the stack—hardware, OS, file system, network stack, application logic—can be tuned for exactly one workload. There is no need to handle dynamic web requests, API calls, or small-object caching. The entire system is optimized for one task: read a large video file from local storage and stream it over the network as fast and efficiently as possible.

The ISP Relationship: Economics and Controversy

Netflix’s relationships with ISPs have not always been smooth. The most public dispute occurred in 2014, when Netflix experienced significant quality degradation for subscribers on Comcast and Verizon networks in the United States. Netflix accused the ISPs of allowing interconnection links to become congested as leverage in peering negotiations; the ISPs argued that Netflix’s traffic was causing the congestion and that Netflix should pay for direct interconnection. Netflix ultimately signed paid peering agreements with several major US ISPs, but the public backlash and regulatory scrutiny (the dispute unfolded during the FCC’s net neutrality proceedings) pressured ISPs to improve interconnection capacity.

The Open Connect embedded-deployment model was, in part, Netflix’s long-term answer to these interconnection disputes. By placing the content inside the ISP’s network, Netflix eliminates the interconnection bottleneck entirely. The traffic never crosses a peering link. The ISP gets the content locally, and Netflix avoids transit costs. It transformed a contentious peering negotiation into a mutually beneficial infrastructure partnership.

Today, Netflix has embedded OCA partnerships with hundreds of ISPs globally, including major operators like Comcast, Charter, Deutsche Telekom, BT, Jio, and many others. Netflix publishes an ISP Speed Index and maintains an Open Connect Partner Program with detailed technical documentation for ISPs interested in hosting OCAs.

Observability, Telemetry, and Chaos Engineering

Operating a global content delivery network at Netflix’s scale requires extraordinary operational discipline. Netflix’s engineering culture, famously shaped by its chaos engineering practices (epitomized by tools like Chaos Monkey), extends to Open Connect.

Netflix continuously monitors the health of every OCA: disk I/O performance, network interface throughput, CPU utilization, temperature, power supply status, and software process health. Telemetry data is streamed back to Netflix’s central operations infrastructure, where automated systems detect anomalies, predict hardware failures, and trigger remediation—often before a viewer notices any impact.

Netflix also conducts controlled failure experiments on Open Connect infrastructure, deliberately taking OCAs offline or degrading their performance to verify that traffic steering and failover mechanisms work as designed. This proactive approach to reliability is a significant reason why Open Connect outages are exceedingly rare, even given the enormous scale of the deployment. However, when ‘black swan’ events occur—such as unprecedented, simultaneous global traffic spikes tied to massive cultural moments like a highly anticipated game launch—the network’s limits can be tested, occasionally resulting in highly publicized, albeit temporary, service disruptions. These rare events provide invaluable telemetry data that Netflix engineers use to further harden the edge.

The Future: AV1, QUIC, and Beyond

Netflix shows no signs of slowing its infrastructure investment. Several developments are shaping the next phase of Open Connect:

AV1 ubiquity: As AV1 hardware decode support becomes standard across smart TVs, mobile SoCs, and streaming devices, Netflix will shift an increasing share of its encoding and delivery to AV1, reducing bandwidth requirements by 20-30% compared to HEVC at equivalent quality. This directly reduces the load on OCAs and on the internet backbone.

QUIC and HTTP/3 adoption: Netflix’s ongoing QUIC experimentation points toward a future where a significant portion of Open Connect traffic rides on HTTP/3 over QUIC, improving performance on mobile and high-latency networks.

Higher dynamic range and frame rates: As Netflix expands its library of Dolby Vision, HDR10+, and high-frame-rate content, the per-title storage and bandwidth requirements will increase, driving further OCA hardware evolution.

Edge compute and personalization: Netflix is exploring whether future OCA generations could incorporate lightweight compute capabilities for tasks like thumbnail generation, trailer pre-caching, or even localized recommendation pre-computation, pushing more of the application logic closer to the viewer.

Why Open Connect Matters Beyond Netflix

Netflix Open Connect is not merely a corporate infrastructure project. It is a case study in what happens when a single company’s traffic becomes so large that it reshapes the economics and architecture of the global internet. Netflix’s decision to build rather than rent its CDN forced the company to become a hardware manufacturer, an operating system maintainer, a network operator, and a peering-policy stakeholder. In doing so, Netflix demonstrated that at sufficient scale, vertical integration of the delivery stack is not just technically superior but economically essential.

For network engineers, Open Connect offers a masterclass in workload-specific system design. For ISP operators, it presents a pragmatic model for managing the traffic of hyperscale content providers without adversarial peering disputes. For policymakers, it raises ongoing questions about infrastructure investment, net neutrality, and the balance of costs between content providers and access networks.

And for the 230 million subscribers who simply want to watch the next episode of their favorite show without a buffering spinner, Open Connect is the reason the experience feels like magic. Fifteen percent of the world’s internet traffic, delivered through thousands of quiet, humming boxes sitting in ISP data centers and exchange points on every continent, engineered to do one thing exceptionally well: get the video from the disk to your screen, as fast as physics allows.

That is Netflix Open Connect. And it is, by any reasonable measure, one of the most impressive engineering systems ever deployed at global scale.

FAQs

This article was researched using Netflix’s official engineering blog (netflixtechblog.com), public presentations by Netflix engineers at BSDCan, IETF meetings, and industry conferences, Sandvine Global Internet Phenomena Reports, Internet Exchange Point traffic statistics (DE-CIX, AMS-IX, Equinix), and technical documentation from the Netflix Open Connect Partner Program. Figures cited reflect the most recent publicly available data at the time of writing.