Kérelmek feldolgozása apache-ban
Az Apache architektúrája egy egyszerű kernelt, egy platformfüggő réteget (APR) és modulokat tartalmaz. Az Apache alkalmazásai - még a legegyszerűbbek is, az Apache "alapértelmezett" oldaláról tárgyalva "Működött" - több modulot használ. Apache felhasználóknak nem kell tudás, de a fejlesztő programot, hogy értik a API modul és az Apache modul a legfontosabb, hogy együttműködik az Apache. A legtöbb, de nem minden, modul kapcsolódik a HTTP-kérelem feldolgozásának különböző aspektusaihoz. Ritkán a modulnak a HTTP minden aspektusával együtt kell működnie: például httpd (Apache). Az előnye, hogy a moduláris megközelítés az, hogy lehetővé teszi, hogy összpontosítson a készüléket egy adott feladat, figyelmen kívül hagyva más szempontból HTTP, nem kapcsolódik erre a problémára.
Ebben a cikkben az Apache kérés feldolgozásának architektúráját írjuk le, és megmutatjuk, hogyan képes a modul lekapcsolni a lekérdezés feldolgozási ciklusának különböző részeit.
A webszerver legegyszerűbb megfogalmazása olyan program, amely a HTTP kéréseket vár, és a kérések kézhezvételekor visszaküldi a válaszokat. Ez a fő feladat az Apache-ban, a webszerver úgynevezett magjával. Minden HTTP-kérelemnél el kell indítani a tartalomgenerátort. Egyes modulok regisztrálni generátorok tartalmi meghatározása funkciók linket egy kezelőt, hogy lehet beállítani, vagy AddHandler irányelvek SetHandler a httpd.conf. Azokat a lekérdezéseket, amelyekhez a modul generátorát nem biztosítja, olyan szabványos generátor dolgozza fel, amely egyszerűen visszaadja a kért fájlt közvetlenül a fájlrendszerből. Az egy vagy több tartalomgenerátort végrehajtó modulok tartalomgenerátorok vagy feldolgozó modulok.
Íme néhány kérés feldolgozási fázis a tartalom generálása előtt. Ellenőrzik és esetleg megváltoztatják a kérés fejlécét, és meghatározzák, hogy mit kell tenni a lekérdezéssel. Például:
A kérelem URL-jét össze kell hasonlítani a konfigurációs adatokkal annak meghatározásához, hogy melyik tartalomgenerátort kell használni.
Meg kell határozni a kérés URL-jén hivatkozott fájlt. Az URL egy statisztikai és CGI-parancsfájlhoz is hozzáférhet, vagy bármi mást, amely tartalmat generálhat.
Ha a tartalom elérhető, a mod_negotiation megtalálja az erőforrás verzióját, amely a leginkább megfelel a böngésző beállításainak. Például az Apache súgóoldala megjelenik azon a nyelven, amelyen a kérést megkapta a böngészőből.
A modulok elérésére és azonosítására vonatkozó szabályokat a kiszolgálói hozzáférési szabályok betartásával ellenőrzik, és meghatározzák, hogy a felhasználónak joga van-e megkapni a kérését.
A mod_alias vagy a mod_rewrite módosíthatja az URL-t a kérésben.
Ezenkívül van egy kérésnapló fázisa is, amelyet a tartalomgenerátor a böngészőre küldött válasz után hajt végre.
A modul saját kezelőit beágyazhatja bármelyik ilyen horgonyba. Azok a modulok, amelyek a tartalom generálása előtti szakaszokban feldolgozzák az adatokat, metaadat-moduloknak nevezik. Azok, akik a naplózással dolgoznak, ismertek naplózási moduloknak.
A fentiek lényegében bármely webkiszolgáló architektúrája. Az egyetlen különbség a részletek, de a kérelem feldolgozásának fázisa: metaadat-> tartalomgenerátor-> naplózás gyakori.
Az Apache 2 legfontosabb újdonsága egy egyszerű webszerver (például az Apache 1.3 és mások) átalakítása egy erőteljes platformra, amely egy szűrési lánc. A kérelem feldolgozás tengelyére merőleges adat tengelyként ábrázolható. A kért adatok feldolgozhatók a bemeneti szűrőkkel a tartalomgenerátor előtt, és a kiszolgáló válaszát a kimeneti szűrők feldolgozhatják, mielőtt elküldenék az ügyfélnek. A szűrők lehetővé teszik az előszűrést és a feldolgozási adatok hatékonyabb megjelenítését, elkülönítve ezeket a fázisokat a tartalom generálásától. Példa a szűrőkre: kiszolgálóoldali (SSI), XML és XSLT feldolgozás, gzip tömörítés és titkosítás (SSL).
A lekérdezés / adatfeldolgozás bármely szakaszában a modul végrehajtásának megvitatása előtt egy ponton éljünk, ami sokszor zavart okoz az Apache modulok korai fejlesztői között: a feldolgozás sorrendje.
A kérelem feldolgozási tengely lineáris: a fázisok szigorú sorrendben következnek be. De az adat tengelyen zavar keletkezik. A maximális hatékonyság érdekében a megrendelés változik, így a generátor és a szűrők nem kerülnek végrehajtásra szigorúan meghatározott sorrendben. Tehát például általában semmit sem tudsz átvinni a bemeneti szűrőre, és elvárják, hogy a generátorban vagy a kimeneti szűrőkben fogadják.
A feldolgozó központban egy tartalomgenerátor, amely felelős a bemeneti szűrőkészletből származó adatok megszerzéséért, és az adatokat a kimeneti szűrőcsomóba helyezi. Ha a generátor, vagy a szűrőt kell a kérelem teljesítését teljesen, akkor meg kell tennie, mielőtt az adatokat le a láncot (vagy a generátor kimeneti szűrők), vagy vissza adatokat vissza a bemeneti szűrőt.
Most van egy általános elképzelésünk a kérelem feldolgozásáról az Apache-ban, és továbbra is beszélhetünk arról, hogy a modulok hogyan válnak a feldolgozás részévé. Az apache modul szerkezetét több (opcionális) adatmező és funkció írja le:
modul AP_MODULE_DECLARE_DATA my_module = <
STANDARD20_MODULE_STUFF,
my_dir_conf,
my_dir_merge,
my_server_conf,
my_server_merge,
my_cmds,
my_hooks
>;
A modul feldolgozó funkciója, amely létrehozza a kérés feldolgozó kampókat, az utolsót ebben a struktúrában:
statikus void my_hooks (apr_pool_t * pool) / * létrehozza a szükséges horgokat a lekérdezés feldolgozásához * /
>
Attól függően, hogy a lekérdezés mely részei érdeklik a modulunkat, létre kell hoznunk a megfelelő kampókat. Például egy tartalomgenerátort (kezelőt) implementáló modulnak olyan kezelői horogra van szüksége, mint például:
ap_hook_handler (my_handler, NULL, NULL, APR_HOOK_MIDDLE);
Most a my_handler lesz meghívva, amikor a kérés feldolgozása eléri a tartalom létrehozási fázist. Az egyéb lekérdezési fázisok horgjai hasonlóak; Ismét használhatja az alábbiak egyikét:
ap_hook_post_read_request Az első alkalom arra, hogy a kérést elfogadása után feldolgozzák.
ap_hook_fixups Az utolsó lehetőség a kérelem feldolgozására a tartalom generálása előtt.
ap_hook_log_transaction Naplózó kampó.
A post_read_request és a javítások között több más, speciális célra létrehozott hurok is létezik: például a hozzáférési és a hitelesítési modulok hozzáférési ellenőrző kampókkal rendelkeznek. Minden horognak pontosan ugyanolyan megjelenése van, mint a horogfeldolgozás. További információ: http_config.h
Minden fázis processzorának prototípusa:
statikus int my_handler (request_rec * r) <
/ * kérés feldolgozása * /
>
request_rec az apache fő adatszerkezete, amely tárolja az összes HTTP kérésadatot.
A my_handler visszatérési értéke lehet:
rendben
my_handler sikeresen kezelte a kérelmet. A feldolgozási fázis teljes.
CSÖKKENTEK
a my_handler nem érdekli a lekérdezés. Hagyja, hogy a többi kezelő foglalkozzon vele.
Néhány HTTP-kód
Hiba történt a kérelem feldolgozása során. Ez megváltoztatja a kérés feldolgozásának módját: a normál feldolgozás megszűnik, és a szerver visszaküldi a hibaüzenetet.
A szűrők a my_hooks függvényekben is regisztráltak, de az API kissé eltér:
ap_register_output_filter ("my-output-filter-name", my_output_filter,
NULL, AP_FTYPE_RESOURCE);
ap_register_input_filter ("my-input-filter-name", my_input_filter,
NULL, AP_FTYPE_RESOURCE);
a következő szűrőfunkciók prototípusával
statikus apr_status_t my_output_filter (ap_filter_t * f, apr_bucket_brigade * bb) / * Az adatblokk olvasása, feldolgozása és elküldése a következő szűrőbe * /
vissza APR_SUCCESS;
>
statikus apr_status_t my_input_filter (ap_filter_t * f, apr_bucket_brigade * bb,
ap_input_mode_t mód, apr_read_type_e blokk, apr_off_t nbytes) <
/ * a blokk blokkolása a következő szűrőből, feldolgozás, a blokk visszatérése bb * /
vissza APR_SUCCESS;
>
A szűrőfunkciók visszaadják az APR_SUCCESS parancsot, ha minden rendben van, vagy kifejezetten, mint a fenti, vagy visszatérési kódként a következő szűrőből ap_pass_brigade vagy ap_get_brigade híváson keresztül. Az API-dokumentáció az util_filter.h fájlban található.
A HTTP kérést leíró központi struktúra kérés_rec. Ez akkor jön létre, amikor az Apache elfogadja a kérést, és a kérés feldolgozás minden funkcióját ellátja, amint az a my_handler prototípusban látható. A tartalomszűrőben a request_rec elérhető f-> r formájában.
request_rec egy hatalmas struktúra, amely közvetlenül vagy közvetve tartalmazza a kérelem feldolgozásához szükséges összes adatot. Bármely metaadatkezelő a kérdőívek mezőinek megszerzésével és megváltoztatásával működik; így a tartalomgenerátor és a szűrők működnek, továbbá további I / O folyamatok és a naplózáskezelő viselkednek. A teljes leírást a httpd.h.
Ezt a cikket a request_rec használatával röviden tárgyaljuk. Meg kell nézni az API-t vagy más cikkeket is, amelyek leírják a struktúra használatának részleteit.
A gyakran feltett kérdésekre adott válaszok rövid listája:
A kérelem pool r-> pool rendelkezésre áll minden létrehozott erőforrás számára, és rendelkezik a kérés élettartamával.
A kérés és a válasz fejlécek r-> headers_in és r-> headers_out állnak rendelkezésre. Apr_table_t típusúak, apr_table függvények, például apr_table_get és apr_table_set kezelik.
A kezelő mező határozza meg, hogy melyik kezelő jelenleg működik. A tartalomgenerátoroknak ellenőrizniük kell, és azonnal vissza kell térniük, ha nem illeszkednek.
Az input_filter és output_filter mezők I / O leíróként használhatók, csak a szűrőmodulban. A magas szintű I / O (az apache 1.x-ből átvitt) tartalom generátorokhoz, de nem szűrőkhöz.
konfigurációs direktívák állnak rendelkezésre a területen per_dir_config, és lehet beszerezni felhasználása révén ap_get_module_config (szintén ap_set_module_config, bár meg kell teljesen alkalmatlan cc kérelem feldolgozása).
Más rendszermag-adatstruktúrák elérhetők r-> kapcsolatként (kapcsolatszerkezet), r-> szerverrel (szerver struktúrával) és így tovább. Konfigurációik kérésre is rendelkezésre állnak.
Az opcionális request_config konfigurációs mező frissítésre kerül minden egyes kérelemhez, és tárolja a kérelemadatokat az aktuális kérés feldolgozási fázisai között.