Apache 1

Acest conținut face parte din seria:

Aveți grijă de articole noi din această serie.

Un scenariu comun, care implică, pe de o parte - un utilizator cu un browser, pe de altă parte - un server web la distanță, este format din următoarele evenimente: un utilizator face clic pe browser-ul dvs. link-ul trimite o cerere către un server web, care extrage documentul specific și returnează conținutul acestui document clientului la distanță.







1. Arhitectura Apache 1.x

Solicitarea clientului trece în mai multe faze în Apache:

Fiecare fază este controlată de propriul modul Apache.

Apache 1

Apache 1

Pentru fiecare cerere, kernelul Apache creează un obiect structură request_rec, pe care apoi trece la rândul său la modulul corespunzător și îl primește într-o versiune modificată.

În figura următoare, arhitectura Apache este prezentată mai detaliat. Există mici module funcționale - ap, regex, care sunt utilizate atât de kernel, cât și de alte module de bază. Un modul de operare separat implementează Apache cross-platform.

Apache 1

Apache 1

După examinarea mai detaliată a arborelui sursă, devine clar:

  1. Toate anteturile sunt grupate în directorul inclus.
  2. Kernel-ul se află în directorul principal (libmain.a).
  3. Modulele de bază se află în directorul de module (libstandard.a).
  4. Implementarea cross-platform este în directorul os, care include subdirectoarele corespunzătoare, fiecare cu os.h. (Libos.a).
  5. O componentă separată a bibliotecii pentru lucrul cu expresii regulate este în directorul regex (libregex.a).
  6. O componentă separată se află în directorul ap și include un set de diferite funcții (libap.a).
  7. O componentă separată se află în directorul de suport și include scripturi și coduri pentru utilitarele auxiliare ale Apache, cum ar fi rotirea fișierelor jurnal, manipularea fișierelor de parolă și așa mai departe.
  8. Directorul de ajutor include script-urile folosite la compilarea lui Apache.

Aproape toate funcțiile au prefixul ap_, acesta a fost introdus în versiunea 1.3 pentru a evita conflictele de nume la trecerea de la versiunea 1.2.

2. Arhitectura nucleului Apache 1

Codul kernelului se află în directorul principal. Kernelul a fost dezvoltat ținând cont de faptul că oricine dorește să extindă funcționalitatea Apache, dacă este posibil, nu a atins codul kernel-ului, care include deja toate posibilitățile pentru o astfel de extensie. Singura componentă internă a kernelului care poate fi modificată este implementarea protocolului HTTP.

Apache 1

Apache 1

3. Module Apache

Modulele implementează funcționalitatea Apache. Modulele pot comunica direct cu kernelul, dar nu pot comunica direct între ele. Fiecare modul este de fapt un set de handlers pentru diferite faze ale unei cereri HTTP. Figura următoare prezintă o prezentare detaliată a arhitecturii modulului. Un modul este o colecție de funcții de handler numite de kernel. Fiecare modul are o structură proprie numită modul, care stochează pointerii la manipulatori, iar fiecare modul transmite obiectul acestei structuri către kernel.

Apache 1

Apache 1

Fiecare modul trebuie inițializat de către kernel. În mod teoretic, orice modul poate folosi comenzile pe care utilizatorul le prescrie în fișierul de configurare. Kernel-ul citește fișierul, care apoi îi cartografiază în tabelul de comenzi primite de la modulul din structura modulului. Fiecare linie din acest tabel constă dintr-o pereche: tipul de conținut este un indicator pentru handler, în cazul în care tipul de conținut este tipul MIME.

Persoanele care manipulează trimiterea directă a datelor către client se numesc agenți de procesare a conținutului sau agenți de răspuns. Fiecare tip de obiect are propriul handler.

În Apache, toate modulele sunt grupate în directorul modulelor. Modulele standard sunt grupate în subdirectorul standard. implementarea proxy este în directorul proxy. Un modul demo cu un singur handler este în directorul de exemple.

Toate modulele standard sunt încărcate statice, deși este posibilă încărcarea dinamică: pot fi legate de kernel și așa mai departe și așa mai departe. Când Apache este instalat, atunci când porniți configurarea, se creează un fișier numit modules.c, care definește 2 matrice de indicii pentru structuri modulare:







În acest caz, toate modulele listate pot fi împărțite în următoarele grupuri:

4. Paralelismul

La pornire, Apache creează (furcă) implicit 5 procese principale, acesta fiind cel mai mic număr posibil de procese. Fiecare proces poate, la rândul său, să susțină cel puțin 50 de fire (fir - dacă suportul multistrat este suportat de sistemul de operare). Fiecare cerere de client este alocată unui proces. Există o structură specială - tablou de bord - care stochează starea tuturor proceselor. Numărul proceselor posibile simultan este de la 5 la 10. Numărul maxim de astfel de procese este de 256. Există, de asemenea, o coadă specială pentru cererile de așteptare, care până acum nu are niciun loc în tabloul de bord. Lungimea maximă a unei astfel de coadă este de 511.

Numărul maxim posibil de conexiuni client simultan este de 100.

5. Structurile de date

Figura următoare prezintă schema de sincronizare a diferitelor faze ale solicitării clientului, în timp ce lucrarea principală se realizează în kernel, în fișierul http_request.c.

Apache 1

Apache 1

Atunci când un apelant este chemat, fiecare modul primește aceeași structură publică, request_rec, ca parametru. În acest caz, starea diferitelor domenii ale acestei structuri se poate schimba. Persoanele responsabile cu returnarea returnează conținutul clientului. De asemenea, manipulatorul poate executa o altă sub-interogare. Structura request_rec poate include un pointer către o altă structură request_rec în cazul în care are loc o redirecționare, iar în cazul unei sub-interogări, pointerul poate să se îndrepte spre el însuși. Redirecționarea înseamnă apelarea unui manipulator de imagini în interiorul unui document sau a unui script CGI. Aceasta apelează handlerul ap_internal_redirect, care creează un nou obiect request_rec. Un astfel de obiect poate fi plasat în lista de solicitări request_recs.

Structura request_rec conține următoarele câmpuri:

  • pointeri la alte request_rec;
  • pointerul către bazinul de resurse;
  • solicitați obiecte:
    • URI
    • nume de fișier
    • cale
  • informații despre conținut:
    • tip de conținut
    • codare
  • Anteturi MIME;
  • solicitați informații:
    • protocol
    • metodă

Următoarea este o reprezentare exemplară a structurii request_rec cu cele mai frecvent utilizate câmpuri:

Apache utilizează un grup de resurse - pool - o structură de date care stochează o listă cu toate resursele alocate pentru interogare. Când se termină procesarea cererii, toate resursele cheltuite pentru această cerere sunt eliberate. Modulele pot avea bazine proprii pentru nevoile lor.

După cum am menționat deja, kernelul stochează o tabelă de comenzi de configurare. De asemenea, fiecare modul poate avea propriul tabel de comandă. Fiecare comandă reprezintă obiectul structurii command_struct și include:

  • numele echipei;
  • pointer la funcția de manipulare;
  • argumentul a trecut;
  • condiții de inițializare;
  • tipul și numărul de argumente;
  • o descriere a argumentelor;

Structura tabloului de bord păstrează o listă de cereri procesate. Starea solicitării și id-ul acesteia sunt stocate. Pentru fiecare proces nou, se adaugă o înregistrare în tabloul de bord, care este șters după procesarea solicitării. Starea procesului în această structură este modificată de procesul în sine. Starea solicitării poate obține următoarele valori:

6. Operatorul de răspuns

Rezultatul majorității procesatorilor este redus la o schimbare banală a valorii câmpurilor structurii request_rec sau la returnarea unor coduri speciale. Același handler trimite date reale către client. Inițial, clientului i se trimite un antet HTTP utilizând funcția send_http_header. Dacă cererea are o etichetă header_only, atunci clientul nu trimite nimic mai mult. În caz contrar, clientul este trimis mesajul în sine, în acest scop sunt folosite primitive speciale rputc, rprintf, send_fd. Următorul cod arată procesarea solicitării GET și trimiterea datelor către client:

Această funcție poate reveni fie la un cod de eroare, fie la un OK, în cel de-al doilea caz, o redirecționare este apelată la un alt handler folosind funcția internal_redirect.

Principala problemă rezolvată cu ajutorul bazinului este prevenirea scurgerilor de memorie.

Piscina din Apache este proiectată astfel încât eliberarea tuturor resurselor - memorie, descriptori etc. - apare automat după finalizarea procesării cererii clientului. Fiecare astfel de cerere este alocată propriei piscine reprezentată de structura bazinului. După procesare, acest grup este șters.

Când porniți Apache, este selectată o piscină specială - piscina de configurare. Când serverul este repornit, acest pool este de asemenea șters.

Memoria este alocată folosind palloc, care este mai rapid decât malloc. Această funcție are 2 argumente - indicatorul pentru piscină și cantitatea de memorie alocată:

Funcția pfree nu este prezentă, deoarece memoria este eliberată automat atunci când piscina este eliberată. Există funcții speciale de aplicație care alocă memorie. de exemplu, în următorul exemplu, funcția pstrcat alocă memoria pentru un modul de șir de octeți:

În mod similar, fișierele sunt deschise:

Spre deosebire de lucrul cu memoria, există o funcție corespunzătoare de închidere pfclose.

Dezavantajul comun al acestui model de alocare a memoriei este piscinele încorporate. Puteți simula o situație în care bazinul părinte este eliberat în fața bazinului de copii, în care poate apărea o scurgere de memorie pentru acesta din urmă. De exemplu, puteți cita un exemplu de listă de catalog de servere cu un nivel ridicat de cuibărire. În acest caz, trebuie să utilizați make_sub_pool pentru a crea sub-grupuri.

Piscina poate fi, de asemenea, eliberată în orice moment cu clear_pool sau destroy_pool.

În cazul subdotărilor, destroy_sub_request este folosit pentru curățarea în siguranță a memoriei.

8. Configurarea

Primul Apache a fost dezvoltat cu scopul de a maximiza compatibilitatea cu predecesorul său - serverul web NCSA 1.3 - în ceea ce privește citirea fișierelor de configurare. Sarcina a fost de a profita la maximum de funcționalitatea de la kernel la module. În acest scop, a fost creat un tabel de comandă special în kernel. Definițiile tipului de fișier de către sufix se fac pe baza directivelor de configurare AddType și DefaultType.

Lucrul cu sistemul de fișiere se realizează prin intermediul directivelor Aliases și Redirect.

Lucrul cu fișierele de configurare imbricate se efectuează pe baza fișierelor .htaccess.

Când serverul citește o directivă în fișier , creează o structură mime_dir_config:

Comenzile AddType și AddEncoding sunt de obicei prezente în .htaccess.

Pentru a crea o astfel de structură, aveți nevoie de 2 parametri - grupul și numele directorului:

Dacă în directorul nostru de servere, pe care tocmai l-am citit, există un subdirector și există propriul .htaccess, trebuie să combinăm două structuri:

concluzie

Arhitectura primul Apache are caracteristicile - toate funcțiile au se face ap_ punerea în aplicare prefix de cross-platform pe baza unor module individuale, modulele nu pot comunica între ele, dar numai cu miez, toate modulele pot fi grupate în șapte grupe majore: Broadcast, autentificare, MIME, repara -ups, generatoare de conținut, logare, proxy. Administrarea memoriei este implementată pe baza fondurilor. Configurația sistemului are o gamă largă de opțiuni pentru configurarea preconfigurabilă a serverului.

Descărcați resurse

Subiecte conexe







Articole similare

Trimiteți-le prietenilor: