Nginx (pronunțat „engine-x”) este serverul web open-source de înaltă performanță, reverse proxy-ul și load balancer-ul care alimentează peste o treime dintre cele mai vizitate site-uri de pe internet. Creat inițial în 2004 de inginerul rus Igor Sysoev pentru a rezolva celebra problemă C10K (gestionarea a peste 10.000 de conexiuni TCP concurente pe un singur server fizic), Nginx a transformat radical arhitectura web eliminând modelul tradițional concurent bazat pe procese/fire dedicate per conexiune (specific serverelor vechi precum Apache prefork) în favoarea unei arhitecturi asincrone, non-blocante și conduse de evenimente (Event-Driven Architecture).
În infrastructurile moderne de producție, Nginx servește ca prim punct de contact (Edge Ingress) pentru traficul web: realizează terminarea criptografică SSL/TLS (HTTPS, HTTP/2 și HTTP/3 QUIC), filtrează atacurile malițioase prin Rate Limiting și antete de securitate (HSTS, CSP), distribuie încărcarea către backend-uri prin Load Balancing inteligent și accelerează timpii de răspuns prin microcaching agresiv și compresie modernă (Gzip, Brotli).
# Nginx nu creează un fir de execuție separat pentru fiecare vizitator!
# În schimb, utilizează un model modular cu procese asimetrice specializate:
# 1. PROCESUL MASTER (Master Process - rulează ca root):
# - Citește și validează fișierele de configurare (nginx.conf, sites-available).
# - Deschide și leagă porturile privilegiate de rețea (80, 443).
# - Gestionează ciclul de viață al proceselor lucrătoare (Worker Processes):
# la 'nginx -s reload', pornește un nou set de workers cu noua configurație
# și îi oprește treptat pe cei vechi fără a întrerupe nicio cerere pe fir (Zero Downtime)!
# 2. PROCESELE WORKER (Worker Processes - rulează neprivilegiat ca 'www-data' sau 'nginx'):
# - Configurat de regulă cu: worker_processes auto; (1 worker per nucleu CPU fizic).
# - Fiecare worker rulează o buclă continuă de evenimente non-blocantă (Single-Threaded Event Loop).
# - Folosește mecanismul nativ de notificare de mare viteză al nucleului Linux: 'epoll'
# (sau 'kqueue' pe FreeBSD/macOS).
# - Un singur worker procesează simultan mii de cereri de rețea multiplexate: în loc să aștepte
# răspunsul lent de la disc sau de la baza de date, worker-ul trece instantaneu la următoarea
# cerere gata pe socket-ul de rețea!
# 3. PROCESELE DE CACHE (Cache Manager & Cache Loader):
# - Cache Loader: Încarcă metadatele cache-ului de pe disc în memoria RAM partajată la pornire.
# - Cache Manager: Curăță periodic elementele de cache expirate sau care depășesc dimensiunea alocată.
Algoritmul Strict de Potrivire a Blocurilor Location
Una dintre cele mai mari surse de confuzie și erori de configurare în Nginx este ordinea în care sunt evaluate blocurile location. Nginx nu le evaluează pur și simplu de sus în jos în fișier, ci aplică o regulă strictă de prioritate matematică:
Tehnologia Zero-Copy: sendfile, tcp_nopush și tcp_nodelay
Pentru a servi fișiere statice (imagini, video-uri, arhive, CSS/JS) la viteza maximă pe care o permite placa de rețea fără a irosi cicluri de procesor, Nginx utilizează mecanismele Zero-Copy din nucleul Linux:
# În contextul http din /etc/nginx/nginx.conf:
# 1. SENDFILE (Zero-Copy):
# În mod tradițional, datele fișierului sunt copiate: Disc -> Buffer Kernel -> Memorie Nginx -> Buffer Socket -> Rețea.
# Directiva 'sendfile on' instruiește nucleul să transfere datele direct din Page Cache în placa de rețea,
# ocolind complet copierea în spațiul de memorie al procesului Nginx!
sendfile on;
# 2. TCP_NOPUSH:
# Forțează Nginx să trimită antetele HTTP și începutul pachetului de date într-un singur pachet TCP complet
# de mărime maximă (MSS), optimizând lățimea de bandă:
tcp_nopush on;
# 3. TCP_NODELAY:
# Dezactivează algoritmul Nagle pentru conexiunile active (keep-alive). Esențial pentru microservicii și API-uri,
# trimițând pachetele mici imediat fără o întârziere artificială de 200ms:
tcp_nodelay on;
# 4. OPEN_FILE_CACHE:
# Memorează în memoria RAM descriptorii de fișiere (file descriptors), dimensiunile și permisiunile,
# eliminând mii de apeluri de sistem lente de tip stat() pe disc pentru resurse accesate frecvent:
open_file_cache max=10000 inactive=30s;
open_file_cache_valid 60s;
open_file_cache_min_uses 2;
open_file_cache_errors on;
Cele 11 Faze Interne de Procesare a Cererilor HTTP
La fiecare cerere primită pe un port TCP, Nginx execută un lanț modular strict compus din 11 faze succesive:
NGX_HTTP_POST_READ_PHASE: Punctul inițial de citire a antetelor cererii din socket.NGX_HTTP_SERVER_REWRITE_PHASE: Executarea directivelorrewritedefinite în bloculserver.NGX_HTTP_FIND_CONFIG_PHASE: Algoritmul de căutare a bloculuilocationpotrivit.NGX_HTTP_REWRITE_PHASE: Executarea directivelorrewritedefinite în interiorul bloculuilocationales.NGX_HTTP_POST_REWRITE_PHASE: Verificarea numărului de rescrieri interne (previne ciclurile infinite de redirect, limitate la 10).NGX_HTTP_PREACCESS_PHASE: Verificări preliminare de limitare (directivalimit_reqșilimit_conn).NGX_HTTP_ACCESS_PHASE: Securitate și autentificare (directivaallow/deny,auth_basic,auth_request).NGX_HTTP_POST_ACCESS_PHASE: Verificarea satisfacției cerințelor de acces.NGX_HTTP_PRECONTENT_PHASE: Modulul de filtrare a imaginilor sau streaming MP4/FLV.NGX_HTTP_CONTENT_PHASE: Generarea răspunsului efectiv (citire fișier static,fastcgi_passcătre PHP-FPM sauproxy_passcătre Node/Python/Go).NGX_HTTP_LOG_PHASE: Înregistrarea detaliilor înaccess_logdupă finalizarea trimiterii datelor către client.