Nginx

What is Nginx?

Nginx (pronounced "engine-x") is a high-performance open-source HTTP server, reverse proxy, and load balancer. Originally created by Igor Sysoev in 2004 to solve the C10K problem - the challenge of handling ten thousand concurrent connections on a single server - Nginx is now one of the most widely deployed pieces of web infrastructure in the world.

Unlike traditional thread-per-connection servers, Nginx uses an event-driven, asynchronous architecture that allows a small number of worker processes to handle a very large number of simultaneous connections with minimal memory. This design makes it exceptionally efficient under high concurrency - a property that translates directly to RFID and IoT deployments where many readers or devices connect at the same time.

Nginx is available as a free open-source project and as a commercial Nginx Plus distribution that adds advanced load balancing, active health checks, live activity monitoring, a dashboard, and official support. In RFID and IoT infrastructure, Nginx commonly acts as an API gateway fronting RFID middleware, a reverse proxy for reader REST endpoints, and a WebSocket proxy for real-time tag data dashboards.

How it works

Event-driven async architecture

Nginx starts a small, fixed pool of worker processes - typically one per CPU core. Each worker runs a non-blocking event loop using OS primitives such as epoll (Linux) or kqueue (BSD/macOS). When a connection arrives, the worker registers it with the event loop and moves on. When data is ready to read or write, the event loop notifies the worker. No connection ever blocks a worker thread waiting for network I/O.

This means that a single worker process can hold thousands of open connections simultaneously without consuming significant CPU or memory. For RFID deployments where hundreds of readers or IoT devices maintain persistent connections to a central gateway, this is a critical architectural advantage over fork-on-accept or thread-per-connection servers.

Upstream proxying

When Nginx acts as a reverse proxy, incoming requests from clients (readers, applications, browsers) are forwarded to one or more upstream servers - the actual backend services running the RFID middleware, API, or application logic. The client never connects directly to the backend; it talks only to Nginx. This decouples the public interface from internal service topology and allows backends to be replaced, scaled, or restarted without clients noticing.

Nginx buffers the upstream response before forwarding it to the client (by default), which protects backends from slow clients holding connections open. For streaming responses and WebSocket upgrades, buffering is disabled so data flows through continuously.

Load balancing algorithms

When multiple upstream servers are defined, Nginx distributes requests across them using a configurable algorithm:

• Round robin (default): Requests are distributed in sequence across all healthy upstream servers. Simple and effective for stateless RFID API endpoints where any backend can handle any request.
• Least connections: Each new request goes to the upstream with the fewest active connections. Better for workloads where individual requests vary in processing time, such as complex RFID event queries.
• IP hash: The client's IP address determines which upstream server handles all requests from that client. Provides session affinity without application-level session tokens - useful when RFID middleware maintains per-reader state.
• Least time (Nginx Plus only): Routes to the upstream with the lowest average response time and fewest active connections combined. Ideal for latency-sensitive RFID API deployments.

TLS termination

Nginx handles TLS handshakes on behalf of backend services, decrypting incoming HTTPS traffic at the proxy and forwarding plain HTTP to upstream servers over the internal network. This centralises certificate management and offloads the computational cost of TLS from application servers. For RFID deployments, TLS termination at Nginx means individual RFID middleware components do not need to manage certificates - Nginx handles renewals (via Certbot/ACME), cipher suite configuration, and TLS version enforcement in one place.

Nginx also supports mutual TLS (mTLS), requiring clients to present a valid certificate before a connection is accepted. This is a key pattern for authenticating RFID readers and IoT devices at the network layer, described further in the RFID deployments section below.

Nginx in RFID and IoT

API gateway for RFID reader REST endpoints

Enterprise RFID readers expose REST APIs for configuration and control. Placing Nginx in front of these endpoints provides authentication enforcement, rate limiting, and access logging without modifying the reader firmware or middleware. A single Nginx instance can front dozens of reader management APIs, presenting a uniform HTTPS interface while routing to each reader's internal API based on URL path or virtual host.

Reverse proxy for RFID middleware

RFID middleware platforms - applications that aggregate reads from multiple readers, apply business rules, and push events to ERP or WMS systems - are typically deployed as internal services not exposed directly to external networks. Nginx acts as the reverse proxy that accepts inbound connections from external applications or cloud platforms, terminates TLS, applies rate limiting, and forwards requests to the middleware over the internal network. This keeps the middleware simple while Nginx handles all cross-cutting infrastructure concerns.

WebSocket proxying for real-time dashboards

Real-time RFID dashboards and live tag stream viewers use WebSockets to push tag read events from a server to connected browsers without polling. Nginx proxies WebSocket connections by passing through the HTTP Upgrade handshake and then treating the connection as a persistent tunnel. The proxy_http_version 1.1, proxy_set_header Upgrade, and proxy_set_header Connection "upgrade" directives enable this. Once upgraded, Nginx forwards frames between the client and the upstream WebSocket server with minimal overhead.

TLS termination for reader-to-cloud communication

Fixed RFID readers at warehouses, retail sites, or manufacturing floors often lack built-in certificate management capabilities. A Nginx instance deployed at the site edge or in the cloud terminates TLS from readers, handles certificate lifecycle via Let's Encrypt or an internal CA, and forwards decrypted data to backend processing services. This pattern separates TLS complexity from the reader hardware and centralises cipher policy enforcement.

Key features

• Reverse proxy: Forwards client requests to upstream backends, decoupling public endpoints from internal services. Supports HTTP, HTTPS, HTTP/2, gRPC, and WebSocket upstream proxying.
• Load balancing: Distributes traffic across upstream server pools using round robin, least connections, IP hash, or (Plus) least time. Passive health checks remove failed upstreams automatically; active health checks available in Nginx Plus.
• SSL/TLS termination: Centralised TLS handling with support for TLS 1.2 and 1.3, SNI, OCSP stapling, session caching, and automatic certificate reload without downtime.
• Rate limiting: The limit_req module enforces request rate limits per IP, per URI, or per any variable. Protects RFID APIs from tag read floods or credential stuffing attacks without application code changes.
• Caching: Nginx can cache upstream responses to disk or memory, serving repeated identical requests without hitting backend services. Useful for slowly changing RFID inventory snapshots or product lookup responses.
• WebSocket upgrade: Transparent proxying of HTTP Upgrade requests, enabling real-time bidirectional streams between browsers and RFID backend services.
• Health checks: Passive health checks (detecting upstream failures from error responses) are built into the open-source version. Nginx Plus adds active health checks that probe upstreams on a schedule and remove them from rotation before clients experience failures.

Nginx vs Apache vs cloud API gateways

Advantages

• Extremely fast: Nginx consistently tops HTTP server benchmarks. Its event-driven model avoids the context-switch overhead of thread-per-connection servers under high concurrency.
• Low memory usage: Memory consumption is predictable and does not scale linearly with connection count. Running thousands of simultaneous RFID reader connections adds minimal memory overhead.
• Handles massive concurrency: Designed from the ground up for the C10K problem. A single Nginx instance routinely handles tens of thousands of concurrent connections on commodity hardware.
• Battle-tested: Nginx powers a large share of the world's busiest websites and APIs. Its stability and reliability in production are extensively proven over two decades.
• Huge ecosystem: Broad module ecosystem, deep integration with Certbot/Let's Encrypt for automated TLS, first-class support in Kubernetes (Ingress controllers), and extensive tooling for monitoring and configuration management.
• Zero-downtime reloads: Configuration reloads and certificate updates apply without dropping existing connections, essential for always-on RFID infrastructure.
• Flexible deployment: Runs on bare metal, VMs, containers, and as a Kubernetes Ingress controller with identical configuration semantics across environments.

Limitations

• Configuration complexity: Nginx configuration syntax is powerful but non-obvious. Directives behave differently depending on context (http, server, location blocks), and subtle inheritance rules cause hard-to-debug behaviour. Getting TLS, mTLS, and WebSocket proxying correct requires careful reading of the documentation.
• No built-in API management: Nginx open source lacks the developer portal, API key lifecycle management, request transformation, monetisation, and analytics features of cloud API gateways. These require Nginx Plus, Kong, or a separate API management layer on top of Nginx.
• Active health checks require Plus: The open-source version only detects upstream failures passively (after clients receive errors). Active probing - which removes failed RFID middleware instances before clients are affected - is a Nginx Plus feature.
• Dynamic reconfiguration requires reload: Adding or removing upstream servers requires a config reload. While zero-downtime, this differs from platforms like Envoy or cloud load balancers that support fully dynamic upstream updates via API without any reload.
• No native service discovery: Nginx does not integrate natively with service registries (Consul, Kubernetes DNS) in the open-source version. Static upstream blocks must be updated manually or via templating; Nginx Plus adds DNS-based dynamic upstream resolution.
• Limited observability out of the box: Access logs and stub_status metrics are basic compared to the rich telemetry available from cloud gateways or commercial proxies. Meaningful observability requires integrating with Prometheus exporters or an ELK stack.

Common RFID deployments

• Fronting RFID middleware APIs: Nginx sits in front of RFID middleware (such as Impinj Octane, Zebra FXConnect, or custom Java/Python middleware), terminating TLS and providing a single stable HTTPS endpoint for upstream ERP, WMS, and cloud integrations. The middleware can be restarted or updated without changing any upstream client configuration.
• Load balancing across reader gateways: In large warehouses or fulfilment centres with dozens of fixed readers, multiple RFID gateway instances run in parallel to handle aggregate read volume. Nginx distributes inbound connections across the gateway pool using least-connections balancing, removing failed instances from rotation via passive health checks.
• WebSocket proxy for live tag streams: Real-time RFID dashboards showing live inventory counts, conveyor belt tag reads, or dock door events use WebSocket connections from the browser to a backend event server. Nginx proxies these connections, handling the Upgrade handshake and tunnelling the persistent stream through the same HTTPS port used by REST API traffic.
• mTLS for reader authentication: RFID readers at high-security sites (pharmaceutical serialisation lines, airport baggage systems, access control installations) are provisioned with client certificates. Nginx validates the reader's certificate against an internal CA on every connection, refusing connections from readers without a valid cert. The reader's certificate subject or serial is available as a variable for logging and routing, providing cryptographic device identity without application-level API keys.

Related