40 odabranih Nginx intervju pitanja👍

Chenmo Wang Er4777 reči16 minuta

Jednog dana, moj učenik Xiao Er se potajno zaputio na intervju u jednu firmu, ali se vratio i rekao mi da je pao na Nginx pitanjima i pitao me šta da radi.

Prvo sam ga bez oklevanja kritikovao — kako može iza leđa svog vođe da ide na intervjue? Ali, videvši njegovo tužno lice, ipak mi je bilo žao, pa sam mu pripremio 40 Nginx intervju pitanja u nadi da će mu pomoći.

Šta je Nginx?
Koje prednosti ima Nginx?
Koja su scenariji upotrebe Nginxa?
Kako Nginx obrađuje zahteve?
Kako Nginx postiže visoku istovremenost?
Šta je forward proxy?
Šta je reverse proxy?
Koje su prednosti reverse proxy servera?
Koja je struktura direktorijuma Nginxa?
Koje module i atribute ima konfiguracioni fajl nginx.conf?
Razlika između cookie i session?
Zašto Nginx ne koristi više niti?
Razlika između nginx i apache
Šta je razdvajanje dinamičkih i statičkih resursa?
Zašto raditi razdvajanje dinamičkih i statičkih resursa?
Šta je CDN servis?
Kako Nginx radi razdvajanje dinamičkih i statičkih resursa?
Kako je implementiran algoritam za balansiranje opterećenja u Nginxu? Koje strategije postoje?
Kako rešiti problem CORS-a na front-endu pomoću Nginxa?
Kako konfigurisati virtuelne hostove u Nginxu?
Koja je uloga location direktive?
Kako se radi ograničavanje protoka (rate limiting)?
Da li poznajete leaky bucket i token bucket algoritme?
Kako konfigurisati visoku dostupnost Nginxa?
Kako Nginx određuje da određena IP adresa ne može da pristupa?
U nginxu, kako sprečiti obradu zahteva koji koriste nedefinisano ime servera?
Kako ograničiti pristup iz pretraživača?
Šta su Rewrite globalne promenljive?
Kako Nginx implementira proveru zdravlja (health check) pozadinskih servisa?
Kako Nginx uključuje kompresiju?
Koja je uloga ngx_http_upstream_module?
Šta je C10K problem?
Da li Nginx podržava kompresiju zahteva ka upstream serverima?
Kako dobiti trenutno vreme u Nginxu?
Kako objasniti svrhu opcije -s na Nginx serveru?
Kako dodati module na Nginx server?
Kako u produkciji postaviti broj worker procesa?
Nginx status kodovi

Šta je Nginx?

Nginx je lagani/visoko-performantni reverse proxy web server, koji se koristi za HTTP, HTTPS, SMTP, POP3 i IMAP protokole. On implementira veoma efikasan reverse proxy i balansiranje opterećenja; može da obradi 20.000-30.000 istovremenih konekcija, a zvanično se navodi da podržava 50.000 istovremenih. Danas mnogi korisnici web sajtova u Kini koriste nginx, na primer: Sina, NetEase, Tencent itd.

Koje prednosti ima Nginx?

Višeplatformski, jednostavna konfiguracija.
Neblokirajući, visoka istovremenost konekcija: obrađuje 20.000-30.000 istovremenih konekcija, zvanično podržava 50.000.
Mala potrošnja memorije: 10 pokrenutih Nginx procesa zauzima samo 150M memorije.
Niska cena, i open source.
Visoka stabilnost, veoma mala verovatnoća pada servera.
Ugrađena funkcija provere zdravlja: ako jedan server padne, obaviće se provera zdravlja, i zahtevi se više neće slati na taj server. Zahtevi će biti preusmereni na druge čvorove.

Koja su scenariji upotrebe Nginxa?

HTTP server. Nginx je http servis koji može nezavisno da pruža http uslugu. Može se koristiti kao statički web server.
Virtuelni host. Omogućava da se na jednom serveru kreira više virtuelnih sajtova, na primer za lične sajtove.
Reverse proxy i balansiranje opterećenja. Kada broj poseta sajtu dostigne određeni nivo, jedan server više ne može da zadovolji zahteve korisnika, pa je potrebno koristiti klaster od više servera — Nginx se može koristiti kao reverse proxy. Više servera može ravnomerno da podeli opterećenje, izbegavajući situaciju u kojoj jedan server pada zbog prevelikog opterećenja dok drugi stoji neiskorišćen.
U Nginxu se takođe može konfigurisati upravljanje sigurnošću, na primer može se koristiti za izgradnju API gateway-a, gde se vrši intercept-ovanje svakog API servisa.

Kako Nginx obrađuje zahteve?

server {         # Početak prvog Server bloka, predstavlja nezavisnu virtuelnu host stanicu
   listen       80; # Port koji pruža uslugu, podrazumevano 80
   server_name  localhost; # Domen odnosno ime hosta koji pruža uslugu
   location / { # Početak prvog location bloka
     root   html; # Koreni direktorijum stanice, ekvivalentan instalacionom direktorijumu Nginxa
     index  index.html index.html; # Podrazumevana početna datoteka, više njih razdvoji razmakom
} # Kraj prvog location bloka

Prvo, pri pokretanju, Nginx analizira konfiguracioni fajl i dobija portove i IP adrese koje treba da sluša, a zatim u Master procesu Nginxa inicijalizuje taj Socket za slušanje (kreira Socket, postavlja addr, reuse i druge opcije, vezuje za zadatu IP adresu i port, a zatim sluša).
Zatim se fork-uje (postojeći proces može pozvati fork funkciju da kreira novi proces — novi proces kreiran fork-om se naziva child proces) više child procesa.
Nakon toga, child procesi se takmiče da prihvate (accept) nove konekcije. U tom trenutku, klijent može da uspostavi konekciju sa nginx-om. Kada klijent i nginx završe three-way handshake i uspostave konekciju, neki child proces će uspešno izvršiti accept, dobiti Socket te uspostavljene konekcije, a zatim kreirati nginx-ovu enkapsulaciju konekcije, odnosno ngx_connection_t strukturu.
Zatim se postavljaju funkcije za obradu read/write događaja, i dodaju read/write događaji kako bi se vršila razmena podataka sa klijentom.
Na kraju, Nginx ili klijent aktivno zatvara konekciju, i time jedna konekcija završava svoj životni ciklus.

Kako Nginx postiže visoku istovremenost?

Ako jedan server koristi model u kojem jedan proces (ili nit) odgovara za jedan zahtev, onda je broj procesa istovremeno i broj istovremenih konekcija. Očigledno, mnogi procesi bi bili u stanju čekanja. Šta čekaju? Najviše verovatno mrežni prenos.

Nginx-ov asinhroni neblokirajući način rada upravo iskorišćava to vreme čekanja. Kada treba čekati, ti procesi postaju slobodni i spremni. Zato se dešava da mali broj procesa rešava veliki broj istovremenih zahteva.

Kako to Nginx radi? Jednostavno rečeno: sa istih 4 procesa, ako se koristi model jedan proces po zahtevu, onda kada dođu 4 zahteva, svaki proces obrađuje jedan sve dok se sesija ne zatvori. U tom periodu, ako dođe 5. zahtev, ne može se blagovremeno odgovoriti jer sva 4 procesa još nisu završila; zato obično postoji proces za raspoređivanje koji, kad god stigne novi zahtev, otvara novi proces za obradu.

Setite se, da li BIO ima ovakav problem?

Nginx ne radi tako. Za svaki pristigli zahtev, jedan worker proces preuzima obradu. Ali ne obradu od početka do kraja — do koje tačke? Do mesta gde može doći do blokade, na primer prosleđivanje zahteva ka upstream (pozadinskom) serveru i čekanje na odgovor. Taj worker neće glupo čekati; nakon slanja zahteva, registrovaće događaj: „Ako se upstream vrati sa odgovorom, obavesti me da nastavim". Zatim odlazi na odmor. Ako u tom trenutku stigne novi zahtev, može brzo da ga obradi na isti način. A kada se upstream server vrati, okida se taj događaj i worker preuzima obradu, pa zahtev nastavlja dalje.

Zato se kaže da je Nginx zasnovan na modelu događaja (event model).

Zbog prirode rada web servera, veći deo životnog veka svakog zahteva je u mrežnom prenosu, a vreme provedeno na samom serveru je kratko. Tu leži tajna kako nekoliko procesa rešava problem visoke istovremenosti. Drugim rečima:

Web server je upravo tip mrežno IO-intenzivne aplikacije, a ne CPU-intenzivne.

Asinhronost, neblokirajući rad, upotreba epoll-a, i mnoge optimizacije u detaljima — to je tehnički temelj koji čini Nginx onim što jeste.

Šta je forward proxy?

To je server koji se nalazi između klijenta i originalnog servera (origin server). Da bi dobio sadržaj sa originalnog servera, klijent šalje zahtev proxy-ju i navodi cilj (originalni server), zatim proxy prosleđuje zahtev originalnom serveru i vraća dobijeni sadržaj klijentu.

Samo klijent može da koristi forward proxy. Ukratko o forward proxy-ju: proxy koji zastupa klijenta. Na primer: OpenVPN i slični alati.

Šta je reverse proxy?

Reverse Proxy je način rada u kojem proxy server prihvata konekcione zahteve sa interneta, zatim prosleđuje zahtev serveru na internoj mreži i vraća rezultat dobijen sa tog servera klijentu koji je tražio konekciju sa interneta — u tom trenutku proxy server se prema spoljašnjem svetu pojavljuje kao reverse proxy server.

Ukratko o reverse proxy-ju: proxy koji zastupa server.

Koje su prednosti reverse proxy servera?

Reverse proxy server može da sakrije postojanje i karakteristike izvornog servera. On deluje kao srednji sloj između interneta (oblaka) i web servera. Ovo je dobro sa aspekta bezbednosti, posebno kada koristite web hosting usluge.

Koja je struktura direktorijuma Nginxa?

tree /usr/local/nginx
/usr/local/nginx
├── client_body_temp
├── conf                             # Direktorijum svih konfiguracionih fajlova Nginxa
│   ├── fastcgi.conf                 # Konfiguracioni fajl za fastcgi parametre
│   ├── fastcgi.conf.default         # Originalna rezerva fastcgi.conf
│   ├── fastcgi_params               # fastcgi parametri
│   ├── fastcgi_params.default       
│   ├── koi-utf
│   ├── koi-win
│   ├── mime.types                   # Medija tipovi
│   ├── mime.types.default
│   ├── nginx.conf                   # Glavni konfiguracioni fajl Nginxa
│   ├── nginx.conf.default
│   ├── scgi_params                  # scgi parametri
│   ├── scgi_params.default  
│   ├── uwsgi_params                 # uwsgi parametri
│   ├── uwsgi_params.default
│   └── win-utf
├── fastcgi_temp                     # fastcgi privremeni podaci
├── html                             # Podrazumevani direktorijum stanice Nginxa
│   ├── 50x.html                     # Fajl za elegantnu zamenu stranice greške, npr. pri 502 grešci
│   └── index.html                   # Podrazumevana početna stranica
├── logs                             # Direktorijum logova Nginxa
│   ├── access.log                   # Log pristupa
│   ├── error.log                    # Log grešaka
│   └── nginx.pid                    # pid fajl; nakon pokretanja, Nginx upisuje ID svih procesa ovde
├── proxy_temp                       # Privremeni direktorijum
├── sbin                             # Direktorijum Nginx komandi
│   └── nginx                        # Komanda za pokretanje Nginxa
├── scgi_temp                        # Privremeni direktorijum
└── uwsgi_temp                       # Privremeni direktorijum

Koje module i atribute ima konfiguracioni fajl nginx.conf?

worker_processes  1;                                   # Broj worker procesa
events {                                                  # Početak bloka događaja
    worker_connections  1024;                           # Maksimalan broj konekcija po worker procesu
}                                                        # Kraj bloka događaja
http {                                                   # Početak HTTP bloka
    include       mime.types;                           # Biblioteka medija tipova koje Nginx podržava
    default_type  application/octet-stream;            # Podrazumevani medija tip
    sendfile        on;                                  # Uključi efikasan režim prenosa
    keepalive_timeout  65;                              # Timeout konekcije
    server {                                            # Početak prvog Server bloka, predstavlja nezavisnu virtuelnu host stanicu
        listen       80;                                 # Port koji pruža uslugu, podrazumevano 80
        server_name  localhost;                          # Domen odnosno ime hosta koji pruža uslugu
        location / {                                    # Početak prvog location bloka
            root   html;                              # Koreni direktorijum stanice, ekvivalentan instalacionom direktorijumu Nginxa
            index  index.html index.htm;                 # Podrazumevana početna datoteka, više njih razdvoji razmakom
        }                                                  # Kraj prvog location bloka
        error_page   500502503504  /50x.html;            # Pri odgovarajućem http status kodu, koristi 50x.html za odgovor klijentu
        location = /50x.html {                          # Početak location bloka, pristup 50x.html
            root   html;                                 # Zadaje html kao odgovarajući direktorijum stanice
        }
    }  
    ......

Zajedničko:

Čuvanje korisničkih informacija. Format čuvanja: key-value format, par promenljive i njenog sadržaja.

Razlika:

Čuva se u klijentskom pretraživaču
Svaki domen ima svoj cookie, ne može pristupati cookie-ju drugog domena
Korisnik može da pregleda ili izmeni cookie
Postavlja se preko http response poruke pretraživaču
Ključ (za otvaranje katanca na pretraživaču)

session:

Čuva se na serveru (fajl, baza, redis)
Čuvanje osetljivih informacija
Katanac

Zašto Nginx ne koristi više niti?

Apache: kreira više procesa ili niti, i svaki proces ili nit dobija svoj CPU i memoriju (niti su znatno manje od procesa, pa worker podržava veću istovremenost od prefork), pa previsoka istovremenost može iscrpiti resurse servera.

Nginx: koristi jednu nit da asinhrono i neblokirajuće obrađuje zahteve (administrator može konfigurisati broj worker procesa glavnog Nginx procesa) (epoll), ne dodeljuje CPU i memoriju svakom zahtevu, štedi mnogo resursa, a takođe smanjuje veliki broj CPU context switch-ova. Zato Nginx podržava veću istovremenost.

Razlika između nginx i apache

Lagani dizajn — za istu web uslugu zauzima manje memorije i resursa od apache-a.

Otpornost na istovremenost — nginx obrađuje zahteve asinhrono i neblokirajuće, dok je apache blokirajući; pri visokoj istovremenosti nginx održava niske resurse, nisku potrošnju i visoke performanse.

Visoko modularan dizajn, pisanje modula je relativno jednostavno.

Najvažnija razlika je u tome što je apache sinhroni multiprocesni model — jedna konekcija odgovara jednom procesu, dok je nginx asinhron — više konekcija može deliti jedan proces.

Šta je razdvajanje dinamičkih i statičkih resursa?

Razdvajanje dinamičkih i statičkih resursa znači da se u dinamičkom sajtu, prema određenim pravilima, razdvoje resursi koji se ne menjaju od onih koji se često menjaju. Nakon ovog razdvajanja, možemo na osnovu karakteristika statičkih resursa izvršiti keširanje — to je suština razmišljanja o statifikaciji sajta.

Ukratko, razdvajanje dinamičkih i statičkih resursa je: razdvajanje dinamičkih od statičkih fajlova.

Zašto raditi razdvajanje dinamičkih i statičkih resursa?

U razvoju softvera, neki zahtevi zahtevaju obradu na pozadini (npr. .jsp, .do itd.), dok drugi ne moraju da prođu kroz pozadinu (npr. css, html, jpg, js fajlovi). Fajlovi koji ne zahtevaju obradu na pozadini nazivaju se statički, a ostali dinamički.

Zato pozadina može da ignoriše statičke fajlove. Neko će reći — pa zar ne mogu samo da ignorišem statičke fajlove na pozadini? Naravno da možete, ali time se broj zahteva ka pozadini znatno povećava. Kada su nam važni brzi response resursa, treba koristiti strategiju razdvajanja dinamičkih i statičkih resursa, gde se statički resursi (HTML, JavaScript, CSS, img fajlovi) razdvoje od pozadinske aplikacije, čime se povećava brzina pristupa statičkom sadržaju i smanjuje opterećenje pozadinske aplikacije.

Ovde statičke resurse stavljamo u Nginx, a dinamičke zahteve prosleđujemo Tomcat serveru.

Naravno, pošto su danas CDN servisi kao što su Qiniu, Alibaba Cloud itd. veoma zreli, glavna praksa je da se statički resursi keširaju na CDN servisu, čime se povećava brzina pristupa.

U poređenju sa lokalnim Nginx-om, CDN server ima više čvorova u Kini pa može ostvariti korisnikov najbliži pristup. Osim toga, CDN servis može obezbediti veći propusni opseg, za razliku od naše aplikacije čiji je propusni opseg ograničen.

Šta je CDN servis?

CDN, odnosno Content Delivery Network (mreža za isporuku sadržaja).

Njegov cilj je da, dodavanjem novog sloja mrežne arhitekture na postojeći internet, sadržaj sajta objavi što bliže korisniku, na mrežnoj ivici, tako da korisnik može uzeti željeni sadržaj sa najbliže lokacije, čime se povećava brzina pristupa sajtu.

Uglavnom, pošto su danas CDN servisi prilično uobičajeni, gotovo sve kompanije koriste CDN servise.

Kako Nginx radi razdvajanje dinamičkih i statičkih resursa?

Dovoljno je navesti direktorijum koji odgovara putanji. Location može koristiti regularne izraze za match-ovanje, i navesti odgovarajući direktorijum na disku. Na primer: (sve operacije su na Linuxu)

location /image/ {
    root   /usr/local/static/;
    autoindex on;
}

Koraci:

# Kreiraj direktorijum
mkdir /usr/local/static/image
 
# Uđi u direktorijum
cd  /usr/local/static/image
 
# Otpremi sliku
photo.jpg
 
# Restartuj nginx
sudo nginx -s reload

Otvori pretraživač, unesi server_name/image/1.jpg i možeš pristupiti toj statičkoj slici.

Kako je implementiran algoritam za balansiranje opterećenja u Nginxu? Koje strategije postoje?

Da bi se izbegao pad servera, koristi se balansiranje opterećenja za raspodelu pritiska. Više servera se organizuje u klaster; kada korisnik pristupi, prvo pristupa serveru za prosleđivanje, koji zatim distribuira pristup serverima sa manjim opterećenjem.

Nginx implementira sledećih pet strategija balansiranja opterećenja:

1. Round robin (podrazumevano)

Svaki zahtev se po redosledu pojavljivanja dodeljuje različitim pozadinskim serverima; ako neki pozadinski server padne, automatski se izbacuje iz sistema.

upstream backserver { 
 server 192.168.0.12; 
 server 192.168.0.13; 
}

2. Weight (težina)

Što je veća vrednost weight, to je veća verovatnoća dodele; koristi se uglavnom kada performanse pojedinačnih pozadinskih servera nisu ravnomerne. Takođe se koristi za postavljanje različitih težina kod master-slave konfiguracija, radi racionalnog korišćenja resursa servera.

# Što je veća težina, veća je verovatnoća pristupa; u gornjem primeru to je 20% i 80%.
upstream backserver { 
 server 192.168.0.12 weight=2; 
 server 192.168.0.13 weight=8; 
}

3. ip_hash (IP vezivanje)

Svaki zahtev se dodeljuje na osnovu hash rezultata IP adrese pristupa, tako da posetioci sa iste IP adrese uvek pristupaju istom pozadinskom serveru, što efikasno rešava problem deljenja sesije kod dinamičkih stranica.

upstream backserver { 
 ip_hash; 
 server 192.168.0.12:88; 
 server 192.168.0.13:80; 
}

4. fair (third-party plugin)

Mora se instalirati upstream_fair modul.

U poređenju sa weight i ip_hash, fair je inteligentniji algoritam balansiranja opterećenja koji na osnovu veličine stranice i vremena učitavanja inteligentno vrši balansiranje, dajući prioritet onima sa kraćim vremenom odgovora.

# Koji server ima brže vreme odgovora, njemu se dodeljuje zahtev.
upstream backserver { 
 server server1; 
 server server2; 
 fair; 
}

5. url_hash (third-party plugin)

Mora se instalirati Nginx-ov hash softverski paket.

Zahtevi se dodeljuju na osnovu hash rezultata URL pristupa, tako da se svaki URL usmerava na isti pozadinski server, čime se dodatno povećava efikasnost pozadinskih keš servera.

upstream backserver { 
 server squid1:3128; 
 server squid2:3128; 
 hash $request_uri; 
 hash_method crc32; 
}

Kako rešiti problem CORS-a na front-endu pomoću Nginxa?

Koristite Nginx za prosleđivanje zahteva. API-je koji izazivaju CORS napišite kao pozive lokalnom domenu, a zatim ih prosledite na pravu adresu zahteva.

Kako konfigurisati virtuelne hostove u Nginxu?

Virtuelni host na osnovu domena — razlikuje virtuelne hostove preko domena. Upotreba: spoljašnji sajtovi.
Virtuelni host na osnovu porta — razlikuje virtuelne hostove preko portova. Upotreba: interni sajtovi firme, administrativna pozadina spoljašnjih sajtova.
Virtuelni host na osnovu IP adrese.

Konfiguracija domena na osnovu virtuelnog hosta

Potrebno je kreirati /data/www /data/bbs direktorijume; u windows lokalnim hosts datotekama dodati rezoluciju domena za IP adresu virtuelne mašine; u direktorijum odgovarajućeg domena dodati index.html fajl.

# Kada klijent pristupa www.lijie.com, sluša port 80, i direktno prelazi na fajlove u direktorijumu data/www
server {
    listen       80;
    server_name  www.lijie.com;
    location / {
        root   data/www;
        index  index.html index.htm;
    }
}

# Kada klijent pristupa bbs.lijie.com, sluša port 80, i direktno prelazi na fajlove u direktorijumu data/bbs
 server {
    listen       80;
    server_name  bbs.lijie.com;
    location / {
        root   data/bbs;
        index  index.html index.htm;
    }
}

Virtuelni host na osnovu porta

Koristi port za razlikovanje; pretraživač pristupa preko domena ili IP adrese:port.

# Kada klijent pristupa www.lijie.com, sluša port 8080, i direktno prelazi na fajlove u direktorijumu data/www
 server {
    listen       8080;
    server_name  www.lijie.com;
    location / {
        root   data/www;
        index  index.html index.htm;
    }
}

# Kada klijent pristupa www.lijie.com, sluša port 80 i direktno prelazi na pravu IP adresu servera 127.0.0.1:8080
server {
    listen       80;
    server_name  www.lijie.com;
    location / {
         proxy_pass http://127.0.0.1:8080;
        index  index.html index.htm;
    }
}

Koja je uloga location direktive?

Uloga location direktive je da na osnovu URI-ja korisničkog zahteva izvrši različite aplikacije, odnosno da na osnovu URL-a sajta koji korisnik traži vrši match-ovanje, i kada je match uspešan izvrši odgovarajuću operaciju.

Da li znate sintaksu location direktive?

Napomena: ~ označava slovo koje sami unosite

Location primeri sa regularnim izrazima

# Prioritet 1, tačno match-ovanje, korena putanja
location =/ {
    return 400;
}

# Prioritet 2, počinje određenim stringom, počinje sa av, match-uje ovde, razlikuje velika i mala slova
location ^~ /av {
   root /data/av/;
}

# Prioritet 3, regex match sa razlikovanjem velikih i malih slova, match-uje /media***** putanju
location ~ /media {
      alias /data/static/;
}

# Prioritet 4, regex match bez razlikovanja velikih i malih slova, svi ****.jpg|gif|png idu ovde
location ~* .*\.(jpg|gif|png|js|css)$ {
   root  /data/av/;
}

# Prioritet 7, opšti match
location / {
    return 403;
}

Kako se radi ograničavanje protoka?

Nginx rate limiting ograničava brzinu korisničkih zahteva, štiteći server od preopterećenja.

Postoje 3 vrste ograničavanja:

Normalno ograničavanje frekvencije pristupa (normalan protok)
Ograničavanje burst frekvencije pristupa (burst protok)
Ograničavanje broja istovremenih konekcija

Nginx-ovo ograničavanje protoka je zasnovano na leaky bucket algoritmu.

Implementacija tri algoritma ograničavanja

1. Normalno ograničavanje frekvencije pristupa (normalan protok):

Ograničava zahteve koje jedan korisnik šalje — koliko često Nginx prihvata jedan zahtev.

Nginx koristi ngx_http_limit_req_module modul za ograničavanje frekvencije pristupa; princip je zasnovan na leaky bucket algoritmu. U nginx.conf fajlu mogu se koristiti limit_req_zone i limit_req komande za ograničavanje frekvencije obrade zahteva jednog IP-a.

# Definiše dimenziju ograničenja — jedan zahtev jednog korisnika u minuti, višak se odbacuje
limit_req_zone $binary_remote_addr zone=one:10m rate=1r/m;

# Vezuje dimenziju ograničenja
server{
    
    location/seckill.html{
        limit_req zone=zone;   
        proxy_pass http://lj_seckill;
    }

}

1r/s znači jedan zahtev u sekundi, 1r/m znači jedan zahtev u minuti. Ako Nginx u tom trenutku još uvek obrađuje zahteve drugih, odbijaće da obradi taj korisnički zahtev.

2. Ograničavanje burst frekvencije pristupa (burst protok):

Ograničava zahteve koje jedan korisnik šalje — koliko često Nginx prihvata jedan zahtev.

Gornja konfiguracija u određenoj meri ograničava frekvenciju pristupa, ali postoji problem: ako burst protok premaši ograničenje, zahtevi se odbijaju i ne mogu se obraditi za vreme aktivnosti. Kako dalje postupiti u tom slučaju?

Nginx pruža burst parametar u kombinaciji sa nodelay parametrom koji rešava problem burst protoka — omogućava podešavanje dodatnog broja zahteva koji se mogu obraditi iznad postavljenog ograničenja. Možemo dodati burst i nodelay parametre u prethodni primer:

# Definiše dimenziju ograničenja — jedan zahtev jednog korisnika u minuti, višak se odbacuje
limit_req_zone $binary_remote_addr zone=one:10m rate=1r/m;

# Vezuje dimenziju ograničenja
server{
    
    location/seckill.html{
        limit_req zone=zone burst=5 nodelay;
        proxy_pass http://lj_seckill;
    }

}

Zašto se dodaje burst=5 nodelay? Ovo znači da će Nginx za korisničke zahteve odmah obraditi prvih pet, a višak će se polako prolivati; ako nema zahteva drugih korisnika, obradiće tvoje, a ako ih ima — Nginx će ih odbaciti i neće prihvatiti tvoje zahteve.

3. Ograničavanje broja istovremenih konekcija

Nginx-ov ngx_http_limit_conn_module modul pruža funkciju ograničavanja broja istovremenih konekcija; mogu se koristiti limit_conn_zone i limit_conn direktive za konfiguraciju. Hajde da vidimo jednostavan primer:

http {
    limit_conn_zone $binary_remote_addr zone=myip:10m;
    limit_conn_zone $server_name zone=myServerName:10m;
}

server {
    location / {
        limit_conn myip 10;
        limit_conn myServerName 100;
        rewrite / http://www.lijie.net permanent;
    }
}

Gornja konfiguracija ograničava maksimalan broj istovremenih konekcija jednog IP-a na 10, i maksimalan broj istovremenih konekcija celog virtuelnog servera na 100. Naravno, broj konekcija virtuelnog servera se broji tek nakon što server obradi header zahteva. Kao što je pomenuto, Nginx je zasnovan na principu leaky bucket algoritma, a opšte uzevši ograničavanje protoka je zasnovano na leaky bucket i token bucket algoritmima.

Da li poznajete leaky bucket i token bucket algoritme?

Leaky bucket algoritam

Leaky bucket algoritam je jednostavan: vodu posmatramo kao zahteve, a leaky bucket kao maksimalnu procesnu moć sistema. Voda prvo ulazi u leaky bucket, a zatim ističe određenom brzinom. Kada je brzina isticanja manja od brzine uliva, pošto je kapacitet kofe ograničen, višak vode se prevri i izlije se (zahtevi se odbijaju), čime se ostvaruje ograničavanje protoka.

Token bucket algoritam

Princip token bucket algoritma je takođe prilično jednostavan — možemo ga zamisliti kao prijavu za pregled u bolnici: tek kada dobijete broj možete biti pregledani.

Sistem održava bucket tokena (token); u kofu se tokeni dodaju konstantnom brzinom. Kada pristigne zahtev koji želi da bude obrađen, prvo mora iz kofe uzeti jedan token. Kada u kofi nema više tokena, taj zahtev će biti odbijen. Token bucket algoritam kontroliše zahteve putem kapaciteta kofe i brzine izdavanja tokena.

Kako konfigurisati visoku dostupnost Nginxa?

Kada upstream server (server za stvarni pristup) prestane da radi ili ne odgovara na vreme, treba odmah preći na sledeći server, obezbeđujući visoku dostupnost.

Nginx konfiguracioni kod:

server {
        listen       80;
        server_name  www.lijie.com;
        location / {
            ### Navodi upstream server za balansiranje opterećenja
            proxy_pass http://backServer;
            ### Vreme timeout-a između nginx i upstream servera (servera za stvarni pristup) — timeout konekcije ka pozadinskom serveru, vreme čekanja na odgovor nakon handshake-a
            proxy_connect_timeout 1s;
            ### Timeout za slanje od nginx ka upstream serveru (serveru za stvarni pristup)
            proxy_send_timeout 1s;
            ### Timeout za primanje od nginx od upstream servera (servera za stvarni pristup)
            proxy_read_timeout 1s;
            index  index.html index.htm;
        }
    }

Kako Nginx određuje da određena IP adresa ne može da pristupa?

  # Ako je IP adresa pristupa 192.168.9.115, vraća 403
 if  ($remote_addr = 192.168.9.115) {  
     return 403; 
 }

U nginxu, kako sprečiti obradu zahteva koji koriste nedefinisano ime servera?

Dovoljno je definisati server koji odbacuje zahteve na sledeći način:

Ime servera se zadržava kao prazan string; on match-uje zahteve koji nemaju Host header polje, a vraća se poseban ne-standardni nginx kod koji prekida konekciju.

Kako ograničiti pristup iz pretraživača?

## Ne dozvoljava pristup preko Chrome pretraživača; ako je Chrome, vraća 500
if ($http_user_agent ~ Chrome) {   
  return 500; 
}

Šta su Rewrite globalne promenljive?

$remote_addr        // IP adresa klijenta
$binary_remote_addr // IP adresa klijenta (binarno)
$remote_port        // Port klijenta, npr. 50472
$remote_user        // Korisničko ime provereno kroz Auth Basic Module
$host           // Host header polje zahteva, inače ime servera, npr. blog.sakmon.com
$request        // Informacije o zahtevu korisnika, npr. GET ?a=1&b=2 HTTP/1.1
$request_filename   // Putanja fajla tekućeg zahteva, formirana od root/alias i URI request, npr. /2013/81.html
$status         // Statusni kod odgovora zahteva, npr. 200
$body_bytes_sent        // Broj bajtova body-ja poslatih u odgovoru. Čak i ako se konekcija prekine, ovaj podatak je tačan, npr. 40
$content_length        // Jednako vrednosti „Content_Length" u liniji zahteva
$content_type          // Jednako vrednosti „Content_Type" u liniji zahteva
$http_referer          // Referentna adresa
$http_user_agent      // Informacije o agentu klijenta, npr. Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.76 Safari/537.36
$args            // Isto kao $query_string — parametri URL-a (GET), npr. a=1&b=2
$document_uri        // Isto kao $uri — ova promenljiva označava URI tekućeg zahteva bez parametara (vidi $args), npr. /2013/81.html
$document_root       // Vrednost korene putanje za tekući zahtev
$hostname        // npr. centos53.localdomain
$http_cookie        // Cookie informacije klijenta
$cookie_COOKIE      // Vrednost cookie promenljive COOKIE
$is_args    // Ako postoji $args parametar, ova promenljiva je „?", inače je prazna, npr. ?
$limit_rate // Ova promenljiva može ograničiti brzinu konekcije, 0 znači bez ograničenja
$query_string       // Isto kao $args — parametri URL-a (GET), npr. a=1&b=2
$request_body      // Beleži POST podatke
$request_body_file  // Privremeno ime fajla sa informacijama o telu zahteva klijenta
$request_method       // Akcija zahteva klijenta, obično GET ili POST, npr. GET
$request_uri          // Originalni URI sa parametrima zahteva, bez imena hosta, npr. /2013/81.html?a=1&b=2
$scheme            // HTTP metod (npr. http, https), npr. http
$uri            // Ova promenljiva označava URI tekućeg zahteva bez parametara (vidi $args), npr. /2013/81.html
$request_completion // Ako je zahtev završen, postavlja se na OK. Ako nije završen ili nije poslednji u nizu, prazno (Empty), npr. OK
$server_protocol    // Protokol koji zahtev koristi, obično HTTP/1.0 ili HTTP/1.1, npr. HTTP/1.1
$server_addr        // IP adresa servera, može se utvrditi nakon jednog sistemskog poziva
$server_name        // Ime servera, npr. blog.sakmon.com
$server_port        // Port servera na koji zahtev pristiže, npr. 80

Kako Nginx implementira proveru zdravlja pozadinskih servisa?

Način 1: iskoristiti ugrađene Nginx module ngx_http_proxy_module i ngx_http_upstream_module za proveru zdravlja pozadinskih čvorova.

Način 2 (preporučeno): iskoristiti nginx_upstream_check_module modul za proveru zdravlja pozadinskih čvorova.

Kako Nginx uključuje kompresiju?

Kada se uključi Nginx gzip kompresija, veličina statičkih resursa kao što su web stranice, css, js se znatno smanjuje, čime se štedi velika količina propusnog opsega, povećava efikasnost prenosa i korisniku se pruža brže iskustvo. Iako se troše CPU resursi, vredi radi boljeg korisničkog iskustva.

Konfiguracija za uključivanje je sledeća:

Gornju konfiguraciju stavite u http{ … } čvor u nginx.conf.

http {
  # Uključi gzip
  gzip on;
 
  # Minimalna veličina fajla za gzip kompresiju; fajlovi manji od ove vrednosti se ne kompresuju
  gzip_min_length 1k;
 
  # Nivo gzip kompresije 1-10 
  gzip_comp_level 2;
 
  # Tipovi fajlova koji se kompresuju.
 
  gzip_types text/plain application/javascript application/x-javascript text/css application/xml text/javascript application/x-httpd-php image/jpeg image/gif image/png;
 
  # Da li dodati Vary: Accept-Encoding u http header, preporučuje se uključivanje
  gzip_vary on;
}

Sačuvaj i restartuj nginx, osveži stranicu (da izbegneš keš, uradi force refresh) i videćeš efekat. U Chrome pretraživaču, preko F12 pogledaj response header zahteva:

Možemo prvo uporediti veličine fajlova pre nego što smo uključili zip kompresiju, kao što je prikazano:

A sada, nakon što smo uključili gzip kompresiju, evo veličine fajlova:

I kada pogledamo response header, videćemo gzip kompresiju kao što je prikazano:

Uporeda gzip kompresije pre i posle: originalna veličina jquery je 90kb, nakon kompresije samo 30kb.

Iako je gzip koristan, sledeće tipove resursa se ne preporučuje kompresovati.

1. Tip slike

Razlog: Slike poput jpg i png su već kompresovane, tako da nakon uključivanja gzip-a nema velike razlike u veličini pre i posle kompresije — uključivanje samo uzalud troši resurse. (Savet: možeš probati da kompresuješ jpg sliku u zip i primetićeš da veličina nije mnogo promenjena. Iako su zip i gzip algoritmi različiti, vidi se da kompresija slika nema veliku vrednost.)

2. Veliki fajlovi

Razlog: Troši mnogo CPU resursa, a efekat nije nužno primetan.

Koja je uloga ngx_http_upstream_module?

ngx_http_upstream_module se koristi za definisanje grupa servera koje mogu biti referencirane putem fastcgi_pass, proxy_pass, uwsgi_pass, memcached_pass i scgi_pass direktiva.

Šta je C10K problem?

C10K problem se odnosi na nemogućnost istovremenog rukovanja velikim brojem klijentskih (10.000) mrežnih socket-a.

Da li Nginx podržava kompresiju zahteva ka upstream serverima?

Možete koristiti Nginx modul gunzip za kompresiju zahteva ka upstream serverima. gunzip modul je filter koji može dekompresovati odgovore sa „Content-Encoding: gzip" za klijente ili servere koji ne podržavaju „gzip" metodu kodiranja.

Kako dobiti trenutno vreme u Nginxu?

Da biste dobili trenutno vreme Nginxa, morate koristiti SSI modul i promenljivu date_local.

Proxy_set_header THE-TIME $date_gmt;

Kako objasniti svrhu opcije -s na Nginx serveru?

Koristi se za pokretanje Nginx -s parametra izvršne datoteke.

Kako dodati module na Nginx server?

Tokom kompilacije, Nginx moduli se moraju odabrati jer Nginx ne podržava izbor modula u toku rada (runtime).

Kako u produkciji postaviti broj worker procesa?

Ako imate više CPU-ova, možete postaviti više worker-a; broj worker procesa može biti jednak broju jezgara CPU-a. Ako na jednom CPU-u pokrenete više worker procesa, operativni sistem će vršiti raspoređivanje između njih, što smanjuje performanse sistema. Ako imate samo jedan CPU, dovoljno je pokrenuti samo jedan worker proces.

Nginx status kodovi

499:

Server predugo obrađuje zahtev, a klijent aktivno zatvara konekciju.

502:

(1) Da li je FastCGI proces pokrenut

(2) Da li broj FastCGI worker procesa nije dovoljan

(3) Da li FastCGI predugo traje

fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;

(4) FastCGI Buffer nije dovoljan — nginx kao i apache ima ograničenje front-end bafera, mogu se podesiti parametri bafera

fastcgi_buffer_size 32k;
fastcgi_buffers 8 32k;

(5) Proxy Buffer nije dovoljan — ako koristite Proxying, podesite

proxy_buffer_size 16k;
proxy_buffers 4 16k;

(6) PHP skripta se predugo izvršava

Promenite 0s u php-fpm.conf u odgovarajuće vreme

Nakon što je pročitao ovih 40 Nginx intervju pitanja, Xiao Er je bio neizrecivo zahvalan, oduševljen bez merenja. Tapnuo sam ga po ramenu i utešio ga: „Drži se, budućnost je tvoja."

Izvorni link: blog.csdn.net/wuzhiwei549/article/details/122758937, obradio: Chenmo Wang Er