Az nginx 1.18.0 kiadása

Egy év fejlesztés után bemutatva új stabil ágja a nagy teljesítményű HTTP szervernek és a többprotokollos proxy szervernek nginx 1.18.0, amely magába foglalta az 1.17.x fő ágában felhalmozott változásokat. A jövőben az 1.18 stabil ágban végrehajtott minden változtatás a komoly hibák és sebezhetőségek megszüntetésével lesz kapcsolatos. Hamarosan kialakul az nginx 1.19 fő ág, amely keretében folytatódik az új lehetőségek fejlesztése. Az átlagos felhasználók számára, akiknek nincs szüksége a harmadik féltől származó modulokkal való kompatibilitás biztosítására, ajánlott az alapág használata, amely alapján háromhavonta elkészülnek a kereskedelmi termék, az Nginx Plus kiadásai.

A következő nyilatkozattal összhangban áprilisi jelentés alapján a Netcraft cég szerint az nginx a aktív webhelyek 19,56%-án használják (ez egy évvel ezelőtt 20,73%, két évvel ezelőtt 21,02%), ami a második legnépszerűbb helyet jelenti ebben a kategóriában (az Apache részesedése 27,64%, a Google — 10,03%, a Microsoft IIS — 4,77%). Ezen kívül, ha minden weboldalt megvizsgálunk, az nginx megőrzi a vezető pozíciót és 36,91%-os piaci részesedéssel bír (ez egy évvel ezelőtt 27,52%), míg az Apache részesedése 24,73%, a Microsoft IIS-é 12,85%, a Google-é 3,42%.

A világ egymillió leglátogatottabb weboldala között az nginx részesedése 25,54% (ez egy évvel ezelőtt 26,22%, két évvel ezelőtt 23,76%). Jelenleg körülbelül 459 millió weboldal működik nginx alatt (ez egy évvel ezelőtt 397 millió volt). adatok W3Techs szerint az nginx a leglátogatottabb egymillió weboldal 31,9%-án használják, tavaly áprilisban ez 41,8% volt, tavalyelőtt pedig 38% (a csökkenés oka a Cloudflare külön HTTP-szerverének nyilvántartásba vétele). Az Apache részesedése egy év alatt 43,6%-ról 38,9%-ra csökkent, míg a Microsoft IIS részesedése 8,6%-ról 8,3%-ra csökkent. Oroszországban az nginx használják a leglátogatottabb weboldalak 78,9%-án használják (ez egy évvel ezelőtt 81% volt).

A 1.17.x fő ág kialakítása során hozzáadott legszembetűnőbb fejlesztések:

• Hozzáadva egy direktíva limit_req_dry_run, amely aktiválja a próbafuttatási üzemmódot, amelyben nem alkalmaznak korlátozásokat a lekérdezések feldolgozásának intenzitására (rate limit nélkül), de a korlátokat túllépő lekérdezések számát továbbra is nyomon követik a megosztott memóriában;
• Hozzáadva egy direktíva limit_conn_dry_run, amely az ngx_http_limit_conn_module modult próbaüzemre tereli, ahol a kapcsolatok száma nem korlátozódik, de nyilvántartásra kerül;
• Hozzáadva az „auth_delay“ utasítást, amely lehetővé teszi, hogy késleltetést állítsunk be a 401-es válaszkódú jogosulatlan kérésekhez a jelszók brute force támadásának csökkentéssel és a védelmével kapcsolatban attacks, amelyek időmérés manipulációjával (timing attack) foglalkoznak a rendszerhez való hozzáféréskor, amelyet jelszóval korlátoznak jelszóval, a lekérdezés eredménye vagy JWT (JSON Web Token);
• Változók támogatása került hozzáadásra a „limit_rate” és „limit_rate_after” direktívákhoz, valamint a stream modul „proxy_upload_rate” és „proxy_download_rate” direktíváihoz;
• A direktívában grpc_pass támogatás került hozzáadásra egy változó használatára a cím meghatározó paraméterében. Ha a cím domain név formájában van megadva, akkor a nevét a leírt szervercsoportok között keresik, és ha nem található meg, a resolver segítségével határozzák meg;
• Új változók lettek hozzáadva $proxy_protocol_server_addr és $proxy_protocol_server_port, amelyek tartalmazzák a PROXY protokollból származó szerver címét és portját;
• A modulban ngx_stream_limit_conn_module hozzáadva a változó $limit_conn_status, amely tárolja a kapcsolatok számának korlátozásának eredményét: PASSED, REJECTED vagy REJECTED_DRY_RUN;
• A modulban ngx_http_limit_req_module hozzáadva a változó $limit_req_status, amely tárolja a kérésérkezési sebesség korlátozásának eredményét: PASSED, DELAYED, REJECTED, DELAYED_DRY_RUN vagy REJECTED_DRY_RUN;
• Alapértelmezés szerint biztosított a modul összeállítása ngx_http_postpone_filter_module;
• Változók támogatásának hozzáadása a névvel ellátott blokkok „location” váltásához az $r->internal_redirect() módszer segítségével, amelyet a beépített Perl interpreter biztosít. Ez a módszer mostantól az URI-k escaped karakterekkel történő feldolgozását is magában foglalja;
• Az „upstream” beállítási blokkban használt „hash” direktívával a terheléselosztás ügyfélhez kötésére, ha az kulcsának üres értéket adunk meg, mostantól az egyenletes terheléselosztási üzemmód (round-robin) aktiválódik;
• Támogatás került hozzáadásra az ioctl(FIONREAD) hívásához, ha az elérhető, hogy elkerüljük a hosszú ideig tartó olvasást egy gyors kapcsolatból.

Forrás: opennet.ru