The TCP/IP stack at the heart of modern internet communication has deep BSD roots. The 4.2BSD release from UC Berkeley in 1983, largely written by Bill Joy and Sam Leffler, contained the first widely available, freely distributable TCP/IP implementation. Before it, TCP/IP lived mostly in ARPANET research systems. After it, virtually every commercial Unix vendor shipped BSD networking code, and the propagation continued well past the Unix era.
Forty years later, FreeBSD is still extending that codebase with kernel TLS, a modular TCP stack, and networking work funded by Netflix to serve video at 800+ Gbps per server. The Dragas article that sparked a 500-point Hacker News discussion last week is about the personal experience of using FreeBSD, and that angle is worth reading. But the networking history underneath it is what gives the system its weight.
From Berkeley to Every Commercial Unix
The 4.2BSD TCP/IP implementation was funded by a DARPA contract to Berkeley’s Computer Systems Research Group. The explicit goal was a freely available, production-quality implementation of the Internet protocols. The BSD license made adoption straightforward, and it was immediate. Sun Microsystems built SunOS on 4.2BSD. DEC built Ultrix on it. HP-UX and Sequent DYNIX followed. By the mid-1980s, BSD networking code ran on essentially every serious Unix workstation.
When Microsoft built Windows NT in the early 1990s, they needed a TCP/IP stack. Microsoft licensed networking code from BSDI (Berkeley Software Design, Inc.), a commercial Unix vendor whose product descended directly from 4.4BSD-Lite. The resulting stack, shipped as TCP/IP for Windows NT, carried BSD DNA throughout. This is not widely publicized, but it is well-documented in the licensing history of both companies.
Apple’s Darwin kernel, which underlies macOS, iOS, tvOS, and watchOS, descends from NeXTSTEP, which was built on Mach with a 4.4BSD-Lite userland. The BSD socket API runs on every iPhone. When you call connect() on an iOS app, the code path traces back to Berkeley. Juniper’s JunOS is a FreeBSD derivative. Sony’s Orbis OS on the PlayStation 4 and 5 is FreeBSD-based. The inheritance has compounded in a way that is difficult to fully account for.
Kernel TLS and the Netflix Contribution
FreeBSD has built substantially on that foundation. The most technically significant contribution of the last decade is kernel TLS. When Netflix needed to serve encrypted video at hundreds of gigabits per second, TLS encryption in user space became a measurable bottleneck. The solution, developed by Netflix and FreeBSD engineers working in the same codebase, is ktls: after the TLS handshake completes in user space using OpenSSL, the kernel takes over the actual record encryption and decryption.
On NICs that support TLS offload, such as Chelsio T6 and Mellanox/NVIDIA ConnectX adapters, the encryption is handled entirely in hardware with no CPU involvement. The mechanism integrates with sendfile(2), FreeBSD’s zero-copy file-to-socket transfer syscall, so a streaming server can serve a video segment directly from the page cache, through the kernel TLS layer, and onto the wire without copying the data into user space:
/* Application sets up TLS context normally */
SSL_CTX *ctx = SSL_CTX_new(TLS_server_method());
SSL_CTX_set_options(ctx, SSL_OP_ENABLE_KTLS);
/* After handshake, kernel handles record encryption */
SSL_write(ssl, buffer, len);
/* For file serving, sendfile() passes through ktls automatically
when the socket has ktls enabled */
sendfile(fd, sockfd, offset, len, NULL, &sbytes, SF_NODISKIO);Linux gained ktls support in the kernel around 4.13, and OpenSSL 3.x enables it by the same SSL_OP_ENABLE_KTLS flag. FreeBSD had production-grade kernel TLS serving real traffic years before that, because the Netflix engineers who needed it could contribute directly to the project rather than routing changes through a distribution maintainer.
Netflix has published measurements of 400+ Gbps sustained throughput per Open Connect Appliance server. The hardware is high-end, but the performance numbers depend on kernel-level optimizations that are available to anyone who downloads FreeBSD.
The RACK TCP Stack
The second major networking contribution from the Netflix collaboration is the RACK (Recent ACKnowledgment) TCP implementation. Traditional TCP loss detection uses duplicate ACKs to infer packet loss, which is slow and inaccurate when packet reordering is common on long-haul paths. RACK uses timing information from recent ACKs to detect loss without relying on duplication, which reduces recovery time on paths with variable reordering.
FreeBSD ships RACK as an alternative TCP stack that can be selected per-connection or globally:
# Select RACK as the default TCP stack
sysctl net.inet.tcp.functions_default=rack
# Or select per-socket in application code
struct tcp_function_set tfs;
strlcpy(tfs.function_set_name, "rack", sizeof(tfs.function_set_name));
tfs.pcbcnt = 0;
setsockopt(s, IPPROTO_TCP, TCP_FUNCTION_BLK, &tfs, sizeof(tfs));The ability to load different TCP implementations as kernel modules and select them at runtime is the kind of architecture that emerges when a single team maintains kernel and networking layer together with a multi-year view. It also made it possible for Netflix to test RACK in production gradually, comparing behavior per-connection before committing to a default.
pf: When OpenBSD Builds It and FreeBSD Ships It
Not everything in FreeBSD’s networking stack was written by FreeBSD developers. The pf firewall was created by Daniel Hartmeier at OpenBSD in 2001, as a replacement for IPFilter after its licensing became problematic. OpenBSD shipped pf in version 3.0; FreeBSD ported it in 5.3 (2004). Apple replaced the ipfw firewall in macOS with pf in OS X 10.7 Lion.
The rule syntax is considerably more legible than iptables or nftables:
# pf.conf -- NAT and basic stateful filtering
ext_if = "em0"
int_if = "em1"
int_net = "192.168.1.0/24"
set skip on lo0
scrub in all
nat on $ext_if from $int_net to any -> ($ext_if)
block in all
pass in on $ext_if proto tcp to ($ext_if) port { 22, 80, 443 }
pass in on $int_if from $int_net to any keep state
pass out all keep statepfSense (now Netgate TNSR) and its fork OPNsense are both FreeBSD-based and use pf as their firewall engine. Both are deployed widely in business and home networks. Their commercial success comes directly from FreeBSD’s permissive license and pf’s combination of clarity and performance under load.
netmap: Beyond the Kernel Stack
For scenarios where kernel TCP overhead itself is the bottleneck, FreeBSD has netmap, a framework for high-speed packet I/O that gives applications memory-mapped access to NIC ring buffers with a thin kernel shim handling synchronization. Overhead per packet is in the tens of nanoseconds rather than microseconds.
netmap underlies vale, a fast software switch included in FreeBSD, and tools like pktgen for packet generation at line rate. DPDK, the dominant Linux framework for equivalent use cases, achieves comparable throughput but requires dedicating CPU cores to busy polling. netmap’s integration with the FreeBSD kernel allows it to interoperate with the standard network stack in a way that pure kernel-bypass approaches cannot.
The Contribution Model
The practical point underneath all of this is that the FreeBSD networking codebase is where a meaningful amount of serious systems networking work has happened over the last decade, and it is available under a license with no copyleft obligations. When Netflix engineers found the networking stack insufficient for their use case, they contributed fixes upstream rather than maintaining a private fork. Their ktls work, RACK implementation, sendfile improvements, and NIC driver work are in the mainline tree.
That pattern, a company with a commercial interest in performance contributing to the public codebase, is what the permissive BSD license and the unified development model enable. The networking improvements are infrastructure, not product differentiation, so contributing them does not cost Netflix a competitive advantage. The result is a publicly available networking stack with production validation at a scale that almost no other open-source project can point to.
The discussion on Hacker News around the original FreeBSD appreciation post is largely about the system as a coherent whole: the unified codebase, ZFS in the base system, jails, and the overall consistency of the experience. Those are real advantages. The networking history is what explains why the coherent whole has accumulated so much engineering investment worth caring about.