Hur en webbserver fungerar. Databaseserviceserver

All utrustning, inklusive serverutrustning, börjar ibland fungera oförutsägbart. Det spelar ingen roll om den här utrustningen är ny eller om den har varit i full belastning i flera år.

Det finns många fall av misslyckande och felaktig användning, och diagnos av problemet blir ofta ett fascinerande pussel.

Nedan kommer vi att prata om några intressanta och icke-triviala fall.

Felsökning

Registreringen av problemet sker oftast efter att kunderna har kontaktat teknisk support via biljettsystemet.

I händelse av en begäran från en klient som hyr dedikerade servrar med en fast konfiguration från oss, utför vi diagnostik för att ta reda på att problemet inte är av programvarukaraktär.

Kunder löser vanligtvis programvaruproblem på egen hand, men i alla fall försöker vi erbjuda hjälp av våra systemadministratörer.

Om det blir uppenbart att problemet är hårdvara (servern ser till exempel inte en del slumpmässigt åtkomstminne), så har vi i det här fallet alltid en liknande serverplattform i reserv.

Om ett hårdvaruproblem identifieras, överför vi skivorna från den misslyckade servern till backupen och efter en liten omkonfigurering av nätverksutrustningen startar servern. Således går inte data förlorad och stilleståndstiden överstiger inte 20 minuter från åtkomstmomentet.

Exempel på problem och hur man åtgärdar dem

Nätverksfel på servern

Det finns en möjlighet att nätverket på servern slutar fungera efter att ha flyttat skivorna från den misslyckade servern till säkerhetskopian. Detta händer vanligtvis när du använder Linux-operativsystem som Debian eller Ubuntu.

Faktum är att under den första installationen av operativsystemet registreras MAC-adresserna för nätverkskort i en speciell fil som finns på: /etc/udev/rules.d/70-persistent-net.rules.

När operativsystemet startar, mappar den här filen gränssnittsnamnen till MAC -adresser. När servern ersätts med en säkerhetskopia matchar nätverksgränssnittens MAC -adresser inte längre, vilket leder till att nätverket inte fungerar på servern.

För att lösa problemet måste du ta bort den angivna filen och starta om nätverkstjänsten eller starta om servern.

Operativsystemet, som inte hittar den här filen, genererar automatiskt en liknande och mappar gränssnitten till nätverkskortens nya MAC -adresser.

Det finns inget behov av att konfigurera om IP-adresser efter det, nätverket kommer att börja fungera omedelbart.

Flytande frysproblem

En gång fick vi en server för diagnostik med ett problem med slumpmässiga frysningar under drift. Vi kontrollerade BIOS- och IPMI-loggarna - tomma, inga fel. Vi satte det på stresstestning, laddade alla processorkärnor med 100%, med samtidig temperaturkontroll - det frös hårt efter 30 minuters drift.

Samtidigt fungerade processorn normalt, temperaturen överskred inte standardvärdena under belastning och alla kylare fungerade bra. Det blev klart att problemet inte var överhettning.

Vidare var det nödvändigt att utesluta eventuella fel i RAM -moduler, så vi satte servern på ett minnestest med den ganska populära Memtest86 +. Efter cirka 20 minuter frös servern, som förväntat, ut och gav fel på en av RAM -modulerna.

Genom att byta ut modulen mot en ny satte vi servern på testet igen, men vi fick ett fiasko - servern hängde igen och utfärdade fel för en annan RAM -modul. Bytte den också. Ännu ett test - återigen lade på luren, återigen gav fel i RAM. En noggrann inspektion av RAM-platserna avslöjade inga defekter.

Det återstod en möjlig boven till problemet - den centrala bearbetningsenheten. Faktum är att RAM -styrenheten är placerad exakt inuti processorn och det var han som kunde misslyckas.

Efter att ha tagit bort processorn fann vi en katastrof - en stift i uttaget bröts i den övre delen, den trasiga spetsen på stiftet fastnade bokstavligen på processorkontaktdynan. Som ett resultat, när det inte fanns någon belastning på servern, fungerade allt tillfredsställande, men när processortemperaturen ökade bröts kontakten, vilket stoppade den normala driften av RAM-kontrollern, vilket orsakade frysningar.

Slutligen löstes problemet genom att byta ut moderkortet, eftersom vi tyvärr inte kan återställa det trasiga uttaget, och detta är redan en uppgift för servicecentret.

Tydlig serverfrysning under OS -installation

Ganska roliga fall uppstår när hårdvarutillverkare börjar ändra hårdvarans arkitektur och överger stöd för gammal teknik till förmån för ny.

En användare kontaktade oss med ett klagomål om serverns frysning när han försökte installera operationsrummet Windows -system Server 2008 R2. Efter att ha startat installationsprogrammet slutade servern svara på musen och tangentbordet i KVM -konsolen. För att lokalisera problemet anslöt vi en fysisk mus och tangentbord till servern - allt är detsamma, installationsprogrammet startar och slutar svara på inmatningsenheter.

På den tiden var denna server en av de första på basis av X11SSL-f moderkortet tillverkat av Supermicro. V BIOS-inställningar det var ett intressant Windows 7 -installationsobjekt som är inaktiverat. Eftersom Windows 7, 2008 och 2008 R2 distribueras på samma installationsprogram, ställde vi in ​​det här alternativet till Aktivera och mirakulöst nog fungerade musen och tangentbordet äntligen. Men detta var bara början på det episka med installationen av operativsystemet.

Vid tidpunkten för val av en disk för installation, visades ingen disk, dessutom utfärdades ett fel som krävde installation ytterligare förare... Operativsystemet installerades från ett USB -minne och snabbsökning på Internet visade att denna effekt uppstår om installationsprogrammet inte kan hitta drivrutiner för USB -styrenhet 3.0.

Wikipedia rapporterade att problemet löses genom att inaktivera USB 3.0 (XHCI controller) stöd i BIOS. När vi öppnade dokumentationen för moderkortet väntade en överraskning på oss - utvecklarna bestämde sig för att helt överge EHCI (Enhanced Host Controller Interface)-kontrollern till förmån för XHCI (eXtensible Host Controller Interface). Med andra ord är alla USB-portar på detta moderkort USB 3.0-portar. Och om du inaktiverar XHCI -styrenheten kommer vi också att inaktivera inmatningsenheterna, vilket gör det omöjligt att arbeta med servern och därmed installationen av operativsystemet.

Eftersom serverplattformarna inte var utrustade med CD / DVD -enheter var den enda lösningen på problemet att integrera drivrutinerna direkt i operativsystemets distribution. Endast genom att integrera USB 3.0-styrenhetens drivrutiner och bygga om installationsavbildningen kunde vi installera Windows Server 2008 R2 på den här servern, och det här fallet inkluderades i vår kunskapsbas så att ingenjörer inte slösade tid på fruktlösa försök.

Ännu roligare, det finns tillfällen då kunder tar med oss ​​utrustning för att vara värd och det beter sig inte som förväntat. Detta är exakt vad som hände med Dell PowerVault -diskhöljet.

Enheten är ett lagringssystem med två skivkontroller och nätverksgränssnitt för drift via iSCSI -protokollet. Förutom dessa gränssnitt finns det en MGMT -port för fjärrkontroll.

Bland våra tjänster för värdutrustning finns en specialtjänst "Extra port på 10 Mbit / s", som beställs om det är nödvändigt att ansluta medel för fjärrserverhantering. Dessa fonder har olika namn:

• ILO från Hewlett-Packard;
• IDrac från Dell;
• IPMI från Supermicro.

Deras funktionalitet är ungefär densamma - övervakning av serverns status och åtkomst till fjärrkonsolen. Följaktligen behöver de inte en hög kanalhastighet - 10 Mbps är tillräckligt för bekvämt arbete. Det var denna tjänst som beställdes av klienten. Vi har lagt lämplig kopparöverkoppling och konfigurerat porten på vår nätverksutrustning.

För att begränsa hastigheten är porten helt enkelt konfigurerad som 10BASE-T och kommer i drift med maxhastighet vid 10 Mbps. Efter att allt var klart anslöt vi MGMT-porten på diskhyllan, men klienten rapporterade nästan omedelbart att ingenting fungerade för honom.

Efter att ha kontrollerat switchportens status fann vi en obehaglig inskription "Fysisk länk är nere". En sådan inskription indikerar att det finns ett problem med den fysiska anslutningen mellan omkopplaren och klientutrustningen som är ansluten till den.

Dåligt krympad kontakt, trasig kontakt, trasiga kärnor i kabeln - det här är en liten lista över problem som leder till att det inte finns någon länk. Naturligtvis tog våra ingenjörer omedelbart en twisted pair -testare och kontrollerade anslutningen. Alla kärnor var perfekt ringade, båda ändarna av kabeln krympades perfekt. Dessutom, genom att ansluta en testdator till den här kabeln, fick vi en 10 Mbit / s -anslutning som den borde vara. Det blev klart att problemet var på klientens hårdvarusida.

Eftersom vi alltid försöker hjälpa våra kunder att lösa problem, bestämde vi oss för att ta reda på vad som exakt orsakar bristen på en länk. Vi undersökte noggrant MGMT-portkontakten - allt är i sin ordning.

Vi hittade den ursprungliga bruksanvisningen på tillverkarens webbplats för att klargöra om det är möjligt från programvarusidan att "släcka" den här porten. En sådan möjlighet tänktes dock inte - hamnen lyftes automatiskt i alla fall. Trots att sådan utrustning alltid ska stödja Auto -MDI (X) - med andra ord är det korrekt att avgöra vilken kabel som är ansluten: normal eller crossover, vi komprimerade experimentellt crossover och kopplade den till samma switchport. Vi försökte tvinga duplexparametern på switchporten. Effekten var noll - det fanns ingen länk och idéer tog redan slut.

Vid denna tidpunkt uttryckte en av ingenjörerna ett helt kontraintuitivt antagande om att utrustningen inte stöder 10BASE-T och bara fungerar på 100BASE-TX eller till och med 1000BASE-X. Vanligtvis är vilken port som helst, även på den billigaste enheten, kompatibel med 10BASE-T och först avfärdades ingenjörens antagande som "fantasi", men av förtvivlan bestämde de sig för att försöka byta porten till 100BASE-TX.

Vår förvåning kände inga gränser, länken gick upp direkt. Anledningen till bristen på 10BASE-T-stöd på MGMT-porten är fortfarande ett mysterium. Ett sådant fall är mycket sällsynt, men det har en plats att vara.

Klienten var inte mindre förvånad än vår och tackade mycket för att lösa problemet. Följaktligen lämnade de porten i 100BASE-TX, vilket begränsade hastigheten på porten direkt med hjälp av den inbyggda hastighetsbegränsningsmekanismen.

Kylturbinfel

När en klient kom till oss ombedd att ta bort servern och ta den till serviceområdet. Ingenjörerna gjorde allt och lämnade honom ensam med utrustningen. En timme gick, den andra, den tredje - klienten startade / stoppade servern hela tiden och vi frågade vad problemet var.

Det visar sig att servern som tillverkades av Hewlett-Packard misslyckades med två av de sex kylturbinerna. Samtidigt startar servern, ger ett kylningsfel och stängs av omedelbart. Samtidigt finns en hypervisor med kritiska tjänster på servern. För att återställa den ordinarie driften av tjänster krävdes en brådskande migration virtuella maskiner till en annan fysisk nod.

Vi bestämde oss för att hjälpa klienten på följande sätt. Vanligtvis inser servern att allt är bra med kylfläkten genom att bara läsa antalet varv. Samtidigt gjorde naturligtvis Hewlett-Packards ingenjörer allt för att förhindra att den ursprungliga pumphjulet bytte ut mot en analog-en icke-standardkontakt, en icke-standardiserad pinout.

Originalet till en sådan del kostar cirka $ 100 och du kan inte bara gå och köpa den - du måste beställa den från utlandet. Lyckligtvis hittade de på Internet en krets med en original pinout och fick reda på att en av stiften bara är ansvarig för att läsa antalet motorvarv per sekund.

Resten var en teknikfråga - de tog ett par ledningar för prototyper (av en slump var de till hands - några av våra ingenjörer är förtjusta i Arduino) och kopplade helt enkelt stiften från de angränsande arbetsturbinerna med kontakterna som var ur beställa. Servern startade och klienten kunde äntligen migrera de virtuella datorerna och få tjänsterna igång.

Naturligtvis gjordes allt detta enbart under kundens ansvar, men i slutändan gjorde ett sådant icke-standardiserat drag det möjligt att minska stilleståndstiden till ett minimum.

Var är skivorna?

I vissa fall är orsaken till problemet ibland så otrevlig att det tar mycket lång tid att hitta det. Och så hände det när en av våra kunder klagade över oavsiktliga skivor och serverfrysning. Hårdvaruplattform - Supermicro i ett 847 -fodral (4U -formfaktor) med burar för anslutning av 36 enheter. Servern innehöll tre identiska Adaptec RAID-kontroller, var och en med 12 anslutna diskar. Vid tidpunkten för problemet slutade servern se ett slumpmässigt antal skivor och hängde. Servern togs ur produktion och startade diagnostik.

Det första vi lyckades ta reda på var att diskarna bara ramlade av på en kontroller. Samtidigt försvann "tappade diskar" från listan i det inbyggda Adaptec-hanteringsverktyget och dök upp där igen först när servern stängdes av helt och sedan återanslutes. Det första jag kom på var controllerprogramvaran. Alla tre styrenheterna hade lite olika firmware, så det bestämdes att installera samma firmwareversion på alla styrenheter. Klart, vi körde servern i maximala belastningslägen - allt fungerar som förväntat. Efter att ha märkt problemet som löst skickades servern tillbaka till klienten till produktion.

Två veckor senare, behandling med samma problem igen. Det beslutades att byta ut styrenheten mot en liknande. Fullbordat, blinkat, anslutet, testat. Problemet kvarstod - efter ett par dagar ramlade alla diskar på den nya handkontrollen ut och servern lade på säkert.

Vi installerade om kontrollen i en annan plats, bytte ut backplanet och SATA -kablarna från controller till backplane. En vecka med tester och igen föll hårddiskarna - servern frös igen. Att kontakta Adaptecs support misslyckades - de kontrollerade alla tre kontrollerna och hittade inga problem. Vi bytte moderkortet och byggde om plattformen nästan från grunden. Allt som orsakade det minsta tvivel ersattes med ett nytt. Och problemet dök upp igen. Mystik och inget annat.

Problemet löstes av misstag när de började kontrollera varje disk separat. Vid en viss belastning började en av skivorna slå i huvudet och gav en kortslutning till SATA -porten, medan det inte fanns någon larmindikering. Samtidigt slutade handkontrollen att se några av skivorna och började igen känna igen dem först efter återanslutning med strömförsörjning. Så här tog en enda dålig disk ut hela serverplattformen.

Slutsats

Naturligtvis är detta bara en liten del av de intressanta situationer som löstes av våra ingenjörer. Vissa problem är svåra att "fånga", särskilt när det inte finns några tips i loggarna om kraschen. Men alla sådana situationer stimulerar ingenjörer att i detalj förstå strukturen för serverutrustning och hitta en mängd olika lösningar på problem.

Det här är några roliga fall i vår praktik.
Vad har du stött på? Välkommen till kommentarer.

Som regel förknippar en vanlig användare begrepp som "webbserver" eller "värd" med något helt obegripligt. Samtidigt finns det inget komplicerat i den här frågan. Låt oss försöka förklara vad en webbserver är, varför den behövs och hur den fungerar, utan att gå in på tekniska detaljer, utan så att säga på fingrarna. Låt oss bo separat om frågan om hur man skapar och konfigurerar en sådan server på en hemdatorterminal eller bärbar dator.

Vad är en webbserver?

Det viktigaste i denna fråga är att förstå att en server av denna typ inte är något annat än en dator på Internet med lämplig programvara installerad.

Men det betyder inte alls att du inte kan skapa din egen konfiguration hemma. Eftersom Windows -operativsystem är vanligare i vårt land kommer frågor om hur man skapar en webbserver på Ubuntu (Linux) inte att övervägas.

Vad är webbservrar för?

Mycket information lagras på servrar av denna typ på Internet. Samtidigt vänder sig samma antivirus till dem för att uppdatera sina egna databaser. Användaren är också direkt relaterad till sådana servrar, fyller i förfrågningar i webbläsaren (söker information, hänvisar till en sida, etc.).

Så det visar sig att alla sidor som finns på Internet lagras exakt på webbservrar, som å ena sidan gör en användarförfrågan eller överklagande installerat program, och å andra sidan returneras resultatet av samma server till vilken man försöker komma åt.

Hur fungerar det hela?

Alla användare är vana vid att för att ange en resurs på Internet (webbsida) som innehåller information av en viss typ, läggs prefixet www (eller http) och det efterföljande namnet helt enkelt in i adressfältet. Men ingen tänker på hur webbservern förstår begäran och producerar resultatet.

Faktum är att här måste du skilja mellan begreppen server och klient. I vårt fall sparas sidan på Internet exakt på Fjärrserver... Användardatorn fungerar som en klient från vilken begäran görs.

För att komma åt Internet används program som kallas webbläsare. De översätter användarens begäran till en numerisk kod som kan kännas igen av webbservern. Servern behandlar den och ger ett svar i lämplig kod, och webbläsaren omvandlar redan miljontals nollor och enor till en normal form med text, grafik, ljud eller videoinformation som placeras på sidan.

Mest populära webbservrar

Av all serverprogramvara anses Apache och Microsoft IIS vara de vanligaste. Den första är mer populär och används mest i UNIX-liknande system, även om den kan installeras i Windows-miljö... Dessutom är Apache -servern helt gratis programvara och kompatibel med nästan alla kända operativsystem... Som nämnts är denna programvara dock främst avsedd för professionella programmerare och utvecklare.

En mjukvaruprodukt från Microsoft är utformad för den genomsnittliga användaren som kan installera och konfigurera en sådan webbserver för Windows utan ytterligare hjälp från en kvalificerad specialist.

Baserat på officiell statistik använder Apache -programvaran dock cirka 60% av alla befintliga servrar, så vi kommer att överväga frågan om att installera och konfigurera den ursprungliga konfigurationen med hjälp av sitt exempel.

Hemmawebbserver: installation

För installation måste du ladda ner ett speciellt serverpaket, förkortat som WAMP, som innehåller tre huvudkomponenter:

• Apache - programvara skal en server som kan arbeta självständigt, men bara om det inte finns något dynamiskt innehåll på de värdbaserade sidorna.
• PHP är ett programmeringsspråk som används av tillägg för att hantera servrar med dynamiskt innehåll som WordPress, Joomla, Drupal.
• MySQL är ett enhetligt databashanteringssystem som används igen när du skapar webbplatser med dynamiskt innehåll.

Installationen kan göras från WampServer -paketet. För att göra detta är det tillräckligt att följa instruktionerna i "Wizard", som i ett av stadierna kommer att erbjuda att välja en webbläsare som kommer att användas som standard.

För att göra detta måste du gå till mappen med webbläsarens körbara fil (om det inte är Internet Explorer finns det vanligtvis i katalogen Program Files). Längs vägen bör webbläsaren själv läggas till i listan över undantag från Windows -brandväggen. I det sista skedet sätts en bock framför det omedelbara startobjektet, varefter motsvarande ikon visas i systemfältet, som du måste klicka på och ändra för att välja lanseringen av den lokala värden (localhost).

Om allt görs korrekt visas serverns hemsida. Därefter uppmanas du att installera ytterligare komponenter (om detta inte görs kommer systemet att generera ett fel). I grund och botten gäller installationen ytterligare tillägg, element och komponenter som kommer att användas av servern i framtiden.

Exempel för att konfigurera och testa en server

Att sätta upp en webbserver är lite mer komplicerat. Först, i systemfältets meny, väljer du övergången till WWW-mappen (platsen för lagring av tillägg eller HTML-filer). Efter det skriver du följande text i Anteckningar:

Hallå!

"; ?>

Du kan bara kopiera texten till Anteckningar och spara filen under namnet index.php i samma WWW -mapp (även om du kan klara dig utan det, eftersom detta steg endast används för att kontrollera den lokala värden). Istället för en hälsning kan du infoga vilken annan text eller fras som helst.

Sedan måste du uppdatera sidan (F5) i webbläsaren, varefter innehållet visas på skärmen. Men sidan kommer inte att vara tillgänglig för andra datorer.

För att öppna åtkomst måste du ändra httpd.conf -filen genom att skriva i avsnittet som börjar med följande rader:

Beställ Tillåt, Förneka

Istället för ett efterord

Naturligtvis, när det gäller att förstå kärnan i funktionen eller inställningarna för en hemwebbserver, ges endast den mest grundläggande och korta informationen så att säga för en allmän förståelse. Faktum är att alla processer är mycket mer komplexa, särskilt när det gäller att konvertera förfrågningar och utfärda svar, för att inte tala om att ställa in servern hemma. Om användaren har en önskan att förstå dessa frågor, kan man inte göra utan åtminstone grundläggande kunskap om samma WordPress-tillägg och PHP-språk. Å andra sidan kan du använda denna initiala information för att publicera primitiva sidor som till största delen innehåller endast textinformation.

Vad är en webbserver? Från lekmannens synvinkel är detta en slags svart låda som behandlar webbläsarförfrågningar och utfärdar webbsidor som svar. Teknikern kommer att bombardera dig med massor av oklara termer. Som ett resultat kan det vara svårt för nybörjare webbserveradministratörer att förstå alla olika termer och tekniker. Faktum är att området för webbutveckling utvecklas dynamiskt, men många moderna lösningar är baserade på grundläggande teknologier och principer, som vi kommer att prata om idag.

Om du inte vet var du ska börja måste du börja om. För att inte bli förvirrad i alla olika moderna webbtekniker måste du vända dig till historien för att förstå var det moderna Internet började och hur teknik utvecklades och förbättrades.

HTTP -server

I början av Internetutvecklingen var webbplatser ett enkelt arkiv med specialmärkta dokument och några relaterade data: filer, bilder etc. För att dokument ska kunna hänvisa till varandra och relaterade data föreslogs ett speciellt hypertextmarkeringsspråk HTML, och för åtkomst till sådana dokument via Internet, HTTP -protokollet. Både språket och protokollet, som utvecklas och förbättras, har överlevt till denna dag utan betydande förändringar. Och bara börjat byta ut HTTP / 1.1 -protokollet som antogs 1999, bär HTTP / 2 -protokollet drastiska förändringar med hänsyn till kraven i ett modernt nätverk.

HTTP-protokollet implementeras med hjälp av klient-server-teknik och fungerar på en tillståndslös begäran-svar-princip. Syftet med begäran är en viss resurs, som bestäms en enda resursidentifierare - URI (Uniform resursidentifierare), använder HTTP en av URI-smakerna - Url (Uniform Resource Locator) - Universal Resource Locator, som förutom information om resursen också bestämmer dess fysiska plats.

HTTP-serverns uppgift är att behandla klientens begäran och antingen utfärda den nödvändiga resursen till den, eller rapportera omöjligheten att göra detta. Tänk på följande diagram:

En användare via en HTTP -klient, oftast en webbläsare, begär en URL från HTTP -servern, servern kontrollerar och skickar motsvarande URL -fil, vanligtvis en HTML -sida. Det resulterande dokumentet kan innehålla länkar till relaterade resurser, till exempel bilder. Om de behöver visas på sidan så begär klienten dem sekventiellt från servern, förutom bilder kan även stilmallar, skript som körs på klientsidan etc. begäras. Efter att ha fått allt nödvändiga resurser webbläsaren kommer att behandla dem enligt koden för HTML -dokumentet och presentera en klar sida för användaren.

Som många redan har gissat, under namnet på en HTTP -server, innehåller detta schema en enhet som idag är mer känd som en webbserver. Webbserverens huvudsakliga syfte och uppgift är att behandla HTTP -begäranden och returnera deras resultat till användaren. Webbservern vet inte hur man skapar innehåll på egen hand och fungerar bara med statiskt innehåll. Detta gäller också för moderna webbservrar, trots all sin rikedom.

Under en lång tid räckte en webbserver för att implementera en fullvärdig webbplats. Men i takt med att Internet växte blev det mycket svårt att använda statisk HTML. Ett enkelt exempel: varje statisk sida är självförsörjande och måste innehålla länkar till alla resurser som är kopplade till den. När du lägger till nya sidor måste länkar till dem läggas till befintliga sidor, annars kommer användaren aldrig att kunna komma till dem .

Den tidens webbplatser såg inte alls ut som moderna, till exempel nedan ser en av pionjärerna på det ryskspråkiga internet, webbplatsen för Rambler-företaget:

Och övergången till någon av länkarna i allmänhet kan leda en modern användare till förvirring, det är inte möjligt att gå tillbaka från en sådan sida, förutom genom att trycka på knappen med samma namn i webbläsaren.

Ett försök att skapa något mer eller mindre liknande en modern webbplats blev mycket snart ett allt större arbete med att göra ändringar på befintliga sidor. När allt kommer omkring, om vi har ändrat något i den allmänna delen av webbplatsen, till exempel logotypen i rubriken, måste vi göra den här ändringen till alla befintliga sidor. Och om vi ändrade sökvägen till en av sidorna eller raderade den, då måste vi hitta alla länkar till den och ändra eller ta bort dem.

Därför var nästa steg i utvecklingen av webbservrar att stödja tekniken serversidan inkluderar - SSI (Server -sida ingår). Det gjorde det möjligt att inkludera innehållet i andra filer i sidkoden, vilket gjorde det möjligt att återge upprepande element som sidhuvud, sidfot, meny etc. i separata filer och kan enkelt inkluderas under den sista monteringen av sidan.

För att ändra en logotyp eller ett menyalternativ måste ändringar göras i bara en fil istället för att redigera alla befintliga sidor. Dessutom tillät SSI att visa lite dynamiskt innehåll på sidor, till exempel det faktiska datumet och utföra enkla förhållanden och arbeta med variabler. Detta var ett viktigt steg framåt, vilket gjorde det enklare för webbansvariga och förbättrade användarupplevelsen. Men denna teknik tillät fortfarande inte att förverkliga en verkligt dynamisk webbplats.

Det är värt att notera att SSI används aktivt idag, där det är nödvändigt att infoga en del statiskt innehåll i sidkoden, främst på grund av dess enkelhet och kravlösa resurser.

CGI

Nästa steg i utvecklingen av webbteknik var framväxten specialprogram(skript) som hanterar användarförfrågningar på serversidan. Oftast är de skrivna på skriptspråk, till en början var det Perl, idag håller PHP handflatan. Så småningom uppstod en hel klass av program - innehållshanteringssystem - CMS (Innehållshanteringssystem), som representerar fullfjädrade webbapplikationer som kan tillhandahålla dynamisk bearbetning av användarförfrågningar.

Nu viktig poäng: webbservrar kunde inte och vet inte hur man kör skript, deras uppgift är att servera statiskt innehåll. Här kommer en ny enhet in på scenen - en applikationsserver, som är en tolk av skriptspråk och med vilka webbapplikationer som skrivs i dem fungerar. För att lagra data används vanligtvis DBMS, vilket beror på behovet av att få åtkomst till en stor mängd sammankopplad information.

Applikationsservern vet dock inte hur man arbetar med HTTP-protokollet och bearbetar användarförfrågningar, eftersom detta är webbserverns uppgift. För att säkerställa att deras interaktion utvecklades gemensamt gateway -gränssnitt - CGI (Gemensamt gateway -gränssnitt).

Det bör tydligt förstås att CGI inte är ett program eller ett protokoll, det är bara ett gränssnitt, d.v.s. en uppsättning sätt för interaktion mellan applikationer. Blanda inte heller ihop begreppet CGI med begreppet CGI -applikation eller CGI -skript, vilket betecknar ett program (script) som stöder arbete via CGI -gränssnittet.

För att överföra data används vanliga input-output-strömmar, från webbservern till CGI-applikationen överförs data via stdin tas tillbaka genom stdout, för att skicka felmeddelanden, använd stderr.

Låt oss överväga processen för ett sådant system mer i detalj. Efter att ha mottagit en begäran från användarens webbläsare bestämmer webbservern att dynamiskt innehåll begärs och genererar en särskild begäran som den skickar till webbapplikationen via CGI -gränssnittet. När den tar emot den startar applikationen och kör en begäran, vilket resulterar i HTML -koden för den dynamiskt genererade sidan, som skickas tillbaka till webbservern, varefter programmet avslutas.

En annan viktig skillnad mellan en dynamisk webbplats är att dess sidor inte fysiskt existerar i den form som presenteras för användaren. Det finns faktiskt en webbapplikation, d.v.s. en uppsättning skript och mallar, och en databas som lagrar webbplatsmaterial och tjänstinformation, statiskt innehåll finns separat: bilder, java-skript, filer.

Efter att ha mottagit begäran hämtar webbapplikationen data från databasen och fyller i den mall som anges i begäran. Resultatet skickas till webbservern, som kompletterar sidan som sålunda bildas med statiskt innehåll (bilder, skript, stilar) och ger det till användarens webbläsare. I det här fallet sparas inte själva sidan någonstans, utom i cacheminnet, och när en ny begäran tas emot genereras sidan igen.

Fördelarna med CGI inkluderar språk och arkitektoniskt oberoende: en CGI -applikation kan skrivas på alla språk och fungera lika bra med vilken webbserver som helst. Med tanke på standardens enkelhet och öppenhet har detta lett till en snabb utveckling av webbapplikationer.

Men förutom fördelarna har CGI också betydande nackdelar. Den viktigaste är de höga omkostnaderna för att starta och stoppa processen, vilket innebär ökade krav på hårdvaruresurser och inte hög produktivitet... Och användningen av standard I/O-strömmar begränsar skalbarhet och hög tillgänglighet genom att webbservern och applikationsservern måste vara på samma system.

För närvarande används CGI praktiskt taget inte, eftersom det ersattes av mer avancerad teknik.

FastCGI

Som namnet antyder var huvudmålet med att utveckla denna teknik att förbättra prestanda för CGI. Som ytterligare utveckling är FastCGI ett klient-server-protokoll för interaktion mellan en webbserver och en applikationsserver, vilket ger hög prestanda och säkerhet.

FastCGI eliminerar huvudproblemet med CGI - att starta om webbapplikationsprocessen för varje begäran, FastCGI-processer körs ständigt, vilket avsevärt sparar tid och resurser. För att överföra data istället för standardströmmar används UNIX-uttag eller TCP / IP, som låter dig vara värd för webbservern och applikationsservrarna på olika värdar, vilket ger skalbarhet och/eller hög tillgänglighet för systemet.

Vi kan också köra flera FastCGI -processer på en dator, som kan behandla förfrågningar parallellt eller ha olika inställningar eller versioner av skriptspråket. Till exempel kan du ha flera versioner av PHP för olika webbplatser samtidigt och rikta deras förfrågningar till olika FastCGI -processer.

Processhanterare används för att styra FastCGI -processer och lastbalansering; de kan antingen vara en del av en webbserver eller separata applikationer. Populära webbservrar Apache och Lighttpd har inbyggda FastCGI-processhanterare, medan Nginx kräver en extern chef för att arbeta med FastCGI.

PHP-FPM och spawn-fcgi

Från externa chefer för FastCGI-processer används PHP-FPM och spawn-fcgi. PHP-FPM var ursprungligen en uppsättning PHP-patchar från Andrey Nigmatulin, som löste ett antal problem med FastCGI-processhantering, från och med version 5.3 är det en del av projektet och ingår i PHP-distributionen. PHP-FPM kan dynamiskt hantera antalet PHP-processer beroende på belastningen, ladda om pooler utan att förlora förfrågningar, nödstart av misslyckade processer och är en ganska avancerad hanterare.

Spawn-fcgi är en del av Lighttpd-projektet, men ingår inte i webbservern med samma namn; som standard använder Lighttpd sin egen, enklare processhanterare. Utvecklarna rekommenderar att du använder den i de fall du behöver hantera FastCGI -processer som finns på en annan värd, eller när du behöver avancerade säkerhetsinställningar.

Externa chefer låter dig isolera varje FastCGI -process i sin chroot (ändra programmets rotkatalog utan möjlighet att komma åt utanför den), annorlunda än både chroot för andra processer och chroot för webbservern. Och, som vi redan sa, tillåter de att arbeta med FastCGI-applikationer som finns på andra servrar via TCP / IP, i fall lokal åtkomst du bör välja UNIX-socket access som en snabb anslutningstyp.

Om vi ​​tittar på diagrammet igen kommer vi att se att vi har ett nytt element - en processhanterare, som är en mellanhand mellan webbservern och applikationsservrarna. Detta komplicerar schemat något, eftersom du måste konfigurera och underhålla stor kvantitet tjänster, men öppnar samtidigt bredare möjligheter, så att du kan konfigurera varje element på servern tydligt för dina uppgifter.

I praktiken, när du väljer mellan en inbyggd chef och en extern, bedömer du situationen ordentligt och väljer exakt det verktyg som passar dina behov bäst. Till exempel, om du skapar en enkel server för flera platser på standardmotorer, kommer användningen av en extern chef att vara klart överflödig. Även om ingen tvingar din synvinkel på dig. Linux är så bra att alla, som från en konstruktör, kan sätta ihop exakt vad de behöver.

SCGI, PCGI, PSGI, WSGI och andra

När du går in på ämnet webbutveckling kommer du säkert att stöta på ett omnämnande av olika CGI -tekniker, de mest populära som vi har listat i titeln. Du kan bli förvirrad av en sådan sort, men om du noggrant läser början av vår artikel vet du hur CGI och FastCGI fungerar, och därför kommer det inte att vara svårt för dig att hantera någon av dessa tekniker.

Trots skillnaderna i implementeringarna av en eller annan lösning grundläggande principer förbli vanliga. Alla dessa tekniker ger ett gateway -gränssnitt ( Gateway-gränssnitt) för att kommunicera mellan webbservern och applikationsservern. Gateways låter dig koppla bort webbservern och webbapplikationsmiljöer, så att du kan använda valfri kombination utan att tänka på eventuella inkompatibiliteter. Enkelt uttryckt spelar det ingen roll om din webbserver stöder en specifik teknik eller ett skriptspråk, huvudsaken är att den kan arbeta med önskad typ av gateway.

Och eftersom vi har listat en hel massa förkortningar i titeln kommer vi att gå igenom dem mer detaljerat.

SCGI (Enkelt gemensamt gateway -gränssnitt) - enkelt gemensamt gateway-gränssnitt- designad som ett alternativ till CGI och liknar på många sätt FastCGI, men lättare att implementera. Allt som vi pratade om i förhållande till FastGCI är också sant för SCGI.

PCGI (Perl Common Gateway -gränssnitt) - ett Perl -bibliotek för att arbeta med CGI -gränssnittet, länge sedan var huvudalternativet för att arbeta med Perl -applikationer via CGI, det har bra prestanda (så långt det är tillämpligt för CGI) med blygsamma resurskrav och bra överbelastningsskydd.

PSGI (Perl Web Server Gateway Interface) är en teknik för interaktion mellan en webbserver och en applikationsserver för Perl. Om PCGI är ett verktyg för att arbeta med ett klassiskt CGI -gränssnitt, så är PSGI mer som FastCGI. PSGI Server tillhandahåller ett ramverk för att köra Perl -applikationer som ständigt körs som en tjänst och kan kommunicera med webbservern via TCP / IP- eller UNIX -uttag och ger Perl -applikationer samma fördelar som FastCGI.

WSGI (Webbserver Gateway -gränssnitt) är ett annat specifikt gateway -gränssnitt utformat för interaktionen mellan en webbserver och en applikationsserver för program skrivna i Phyton.

Det är lätt att se att alla teknologier vi har listat i en eller annan grad är analoger av CGI / FastCGI, men för specifika användningsområden. De data som vi ger kommer att räcka tillräckligt för en allmän förståelse av principen och mekanismerna för deras arbete, och en djupare studie av dem är meningsfull endast vid seriöst arbete med den angivna tekniken och språket.

Applikationsserver som Apache -modul

Om vi ​​tidigare talade om en sorts abstrakt webbserver, nu kommer vi att prata om en specifik lösning och poängen här ligger inte i våra preferenser. Bland webbservrar intar Apache en speciell plats, i de flesta fall när de pratar om en webbserver på Linux -plattformen och om en webbserver i allmänhet, kommer Apache att avses.

Vi kan säga att detta är en slags "default" webbserver. Ta vilken masshosting som helst - Apache kommer att finnas där, ta vilken webbapplikation som helst - standardinställningarna är gjorda för Apache.

Ja, ur teknisk synvinkel är Apache inte kronan på teknologier, utan det är han som representerar den gyllene medelvägen, enkel, tydlig, flexibel i miljöer, universell. Om du tar dina första steg i byggandet av webbplatser är Apache ditt val.

Här kan vi bebrejdas att Apache länge har varit inaktuellt, alla "riktiga killar" har redan installerat Nginx, och så vidare. etc., så låt oss förklara detta ögonblick mer i detalj. Alla populära CMS ur förpackningen är konfigurerade för användning i kombination med Apache, detta låter dig fokusera all uppmärksamhet på att arbeta med en webbapplikation, exklusive webbservern från en möjlig källa till problem.

Alla forum som är populära bland nybörjare betyder också Apache som en webbserver och de flesta tips och tricks kommer att relatera till det. Samtidigt kräver alternativa webbservrar vanligtvis en mer subtil och grundlig konfiguration, både från webbserverns sida och från webbprogrammets sida. Samtidigt är användare av dessa produkter vanligtvis mycket mer erfarna och typiska problem för nykomlingar i deras miljö diskuteras inte. Som ett resultat kan en situation uppstå när ingenting fungerar och det inte finns någon att fråga. Detta kommer garanterat inte att hända med Apache.

Vad gjorde egentligen Apache -utvecklarna som gjorde att deras hjärnskap kunde ta en speciell plats? Svaret är enkelt: de gick sin egen väg. Medan CGI föreslog abstraktion från specifika lösningar, med fokus på en universell gateway, gjorde Apache en annan sak - de integrerade webbservern och applikationsservern så mycket som möjligt.

Om vi ​​kör applikationsservern som en webbservermodul i ett gemensamt adressutrymme får vi ett mycket enklare schema:

Vilka är fördelarna med detta? Ju enklare kretsen och färre element i den, desto lättare och billigare är det att underhålla och underhålla den, desto färre felpunkter har den. Om detta kanske inte är så viktigt för en enda server, så är det inom ramen för hosting en mycket viktig faktor.

Den andra fördelen är prestanda. Återigen kommer vi att göra Nginx-fans besvikna, tack vare arbetet i ett enda adressutrymme kommer Apache + mod_php applikationsserverprestanda alltid att vara 10-20% snabbare än någon annan webbserver + FastCGI (eller annan CGI-lösning). Men det bör också komma ihåg att webbplatsens hastighet inte bara beror på applikationsserverns prestanda, utan också på ett antal andra villkor där alternativa webbservrar kan visa betydligt bättre resultat.

Men det finns en till, ganska allvarlig fördel, detta är möjligheten att konfigurera applikationsservern på nivån för en enskild webbplats eller användare. Låt oss gå tillbaka lite: i FastCGI / CGI -scheman är applikationsservern en separat tjänst, med sina egna, separata inställningar, som till och med kan köras på uppdrag av en annan användare eller på en annan värd. Från en enskild serveradministratörs eller något stort projekts synvinkel är detta bra, men inte särskilt bra för användare och värdadministratörer.

Utvecklingen av Internet har lett till att antalet möjliga webbapplikationer (CMS, skript, ramverk etc.) har blivit mycket stort, och den låga inträdetröskeln har lockat ett stort antal personer till webbplatsbyggande utan speciella tekniska kunskap. Samtidigt kan olika webbapplikationer kräva olika konfigurationer av applikationsservern. Hur man är? Kontakta support varje gång?

Lösningen hittades helt enkelt. Eftersom applikationsservern nu är en del av webbservern kan du delegera den senare för att hantera dess inställningar. För att hantera Apache -inställningar användes förutom konfigurationsfiler traditionellt httaccess -filer, vilket gjorde det möjligt för användare att skriva sina direktiv där och tillämpa dem i katalogen där den här filen och nedan, om inställningarna där inte överlappar deras httaccess -fil. I mod_php -läge tillåter dessa filer också att ändra många PHP -alternativ för en enskild webbplats eller katalog.

För att acceptera ändringarna behöver du inte starta om webbservern, och i händelse av ett fel kommer bara den här webbplatsen (eller en del av den) att sluta fungera. Dessutom kan även oförberedda användare göra ändringar i en enkel textfil och lägga den i en mapp på webbplatsen och är säker för servern som helhet.

Det är kombinationen av alla dessa fördelar som har gett Apache en så omfattande användning och status som en universell webbserver. Andra lösningar kan vara snabbare, mer ekonomiska, bättre, men de kräver alltid anpassning för uppgiften, därför används de främst i målprojekt, Apache dominerar i massegmentet.

Efter att ha pratat om fördelarna, låt oss gå vidare till nackdelarna. Några av dem är helt enkelt den andra sidan av myntet. Det faktum att applikationsservern är en del av webbservern ger fördelar i prestanda och enkel konfiguration, men begränsar oss samtidigt ur säkerhetssynpunkt - applikationsservern körs alltid för webbservern och i systemets flexibilitet, vi kan inte sprida webbservern och applikationsservern till olika värdar, vi kan inte använda servrarna med olika versioner skriptspråk eller olika inställningar.

Den andra nackdelen är högre resursförbrukning. I CGI -schemat genererar applikationsservern en sida och ger den till webbservern och frigör resurser, Apache + mod_php -paketet håller applikationsserverresurserna upptagna tills webbservern ger sidens innehåll till klienten. Om klienten är långsam, kommer resurserna att vara upptagna under hela sin tjänst. Det är därför som Nginx ofta placeras framför Apache, som spelar rollen som en snabb klient, detta gör att Apache snabbt kan ge upp sidan och frigöra resurser, flytta interaktionen med klienten till den mer ekonomiska Nginx.

Slutsats

Täck hela spektrat i en artikel modern teknik omöjligt, så vi fokuserade bara på de viktigaste, avsiktligt lämnade några saker bakom kulisserna och använde också betydande förenklingar. Utan tvekan kommer du att behöva en djupare studie av ämnet när du börjar arbeta inom detta område, men för att uppfatta ny kunskap behöver du en viss teoretisk grund, som vi försökte lägga med detta material.

I denna artikel kommer jag att försöka beskriva så brett som möjligt scheman för drift av webbservrar. Detta hjälper dig att välja en server eller bestämma vilken arkitektur som är snabbare utan att förlita dig på ofta partiska riktmärken.

I allmänhet - artikeln är en global översikt över "vad som händer". Inga siffror.

Artikeln skrevs baserat på erfarenhet av servrar:

• Apache, Lighttpd, Nginx (i C)
• Tomcat, Jetty (i Java)
• Twisted (Python)
• Erlang OTP (Erlang språk)
• och fungerar Linux -system, FreeBSD

Men principerna är tillräckligt generella för att de i någon form ska gälla för Windows OS, Solaris och ett stort antal andra webbservrar.

Syftet med webbservern

Målet med en webbserver är enkelt - att betjäna ett stort antal klienter samtidigt och få ut det mesta av hårdvaran. Hur man gör det - det här är huvudproblemet och ämnet för artikeln;)

Arbetar med anslutningar

Var börjar förfrågningsbehandling? Uppenbarligen - från att acceptera en anslutning från användaren.

För att göra detta använder olika operativsystem olika systemanrop. Den mest kända och långsam på ett stort antal anslutningar - välj... Mer effektiva är poll, kpoll, epoll.

Moderna webbservrar fasar ut urval.

OS -optimeringar

Redan innan du accepterar en anslutning är optimeringar på OS -kärnnivå möjliga. OS -kärnan, som har fått en anslutning, stör till exempel inte webbservern förrän en av händelserna inträffar.

• tills data kom (dataready)
• tills hela HTTP-förfrågan kommer (httpready)

När detta skrivs stöds båda metoderna i FreeBSD (ACCEPT_FILTER_HTTP, ACCEPT_FITER_DATA), och endast den första stöds i Linux (TCP_DEFER_ACCEPT).

Dessa optimeringar gör att servern kan leda mindre tid på att vänta på data, vilket förbättrar den totala driftseffektiviteten.

Anslutning accepterad

Så anslutningen accepteras. Nu ligger huvuduppgiften på axlarna på servern - att behandla begäran och skicka ett svar till besökaren. Vi kommer här att överväga endast dynamiska frågor, som är mycket mer komplexa än att returnera bilder.

Alla servrar använder ett asynkront tillvägagångssätt.

Den består i det faktum att behandlingen av begäran skjuts någonstans "till vänster" - den ges till hjälpprocessen / tråden för exekvering, och servern fortsätter att arbeta och accepterar och skickar alla nya anslutningar för exekvering.

Beroende på implementeringen kan "arbetar"-processen skicka tillbaka hela resultatet till servern (för efterföljande leverans till klienten), den kan bara skicka resultatbeskrivningen till servern (utan att kopiera), eller så kan den returnera resultatet till klienten själv.

Grundläggande strategier för att arbeta med arbetare

Att arbeta med arbetare består av flera element som kan kombineras på olika sätt och få olika resultat.

Arbetstyp

Det finns två huvudtyper - en process och en tråd. För att förbättra prestandan används ibland båda typerna samtidigt, vilket skapar flera processer och en massa trådar i varje.

Bearbeta

Olika arbetare kan vara processer, i det här fallet interagerar de inte med varandra, och data från olika arbetare är helt oberoende av varandra.

Flöde

Trådar, till skillnad från processer, har gemensamma, delade datastrukturer. I arbetarens kod måste åtkomstsynkronisering implementeras så att samtidig skrivning av samma struktur inte leder till kaos.

Adressutrymme

Varje process, inklusive servern, har sitt eget adressutrymme som den använder för att separera data.

Inuti servern

När han arbetar inuti servern har arbetaren tillgång till serverdata. Det kan ändra alla strukturer och göra olika otäcka saker, särskilt om det är skrivet med fel.

Fördelen är frånvaron av dataöverföring från ett adressutrymme till ett annat.

Utanför servern

Arbetare kan lanseras i allmänhet oberoende av servern och ta emot data för bearbetning med ett speciellt protokoll (till exempel FastCGI).

Naturligtvis är detta alternativ det säkraste för servern. Men det kräver ytterligare arbete för att skicka förfrågan - resultatet mellan servern och arbetaren.

En arbetares födelse

För att hantera många anslutningar samtidigt måste du ha ett tillräckligt antal arbetare.

Det finns två huvudstrategier.

Statik

Antalet arbetare kan fast fastställas. Till exempel 20 arbetsflöden totalt. Om alla arbetare är upptagna och den 21:a begäran kommer, utfärdar servern koden Temporary Unavailable.

Dynamik

För en mer flexibel resurshantering - arbetare kan uppstå dynamiskt beroende på belastningen. Algoritmen för lekarbetare kan parametreras, till exempel (Apache förgaffel), så här:

• Minsta antal gratisarbetare = 5
• Maximalt antal lediga arbetare = 20
• Totalt antal anställda högst 30
• Initialt antal arbetare = 10

Städning mellan förfrågningar

Arbetare kan antingen initiera sig själva mellan förfrågningar, eller så kan de helt enkelt behandla förfrågningar en efter en.

Rena

Före varje förfrågan rensar den vad som var innan, rensar upp interna variabler osv.

Som ett resultat finns det inga problem och fel i samband med att använda variablerna som är kvar från den gamla begäran.

Beständig

Ingen statlig sanering. Resultatet är resursbesparingar.

Analys av typiska konfigurationer

Låt oss se hur dessa kombinationer fungerar på exemplet med olika servrar.

Apache (pre-fork MPM) + mod_php

För att behandla dynamiska förfrågningar används php -modulen, som fungerar i serverkontexten.

• Bearbeta
• Inuti servern
• Dynamik
• Rena

Apache (MPM -arbetare) + mod_php

För att behandla dynamiska förfrågningar används php -modulen, som fungerar i serverkontexten.

Samtidigt, eftersom php fungerar i adressutrymmet på servern, skadas data som delas av strömmarna regelbundet, så paketet är instabilt och rekommenderas inte. Detta beror på buggar i mod_php, som inkluderar PHP -kärnan och olika php -moduler.

Ett fel i modulen, tack vare ett adressutrymme, kan ta ner hela servern.

• Flöde
• Inuti servern
• Dynamik
• Rena

Apache (händelse mpm) + mod_php

Event MPM är en arbetarstrategi som endast Apache använder. Allt är exakt samma som med vanliga streams, men med ett litet tillägg för att hantera Keep-Alive.

Keep-Alive-inställningen används så att klienten kan skicka många förfrågningar i en anslutning. Skaffa till exempel en webbsida och 20 bilder. Vanligtvis avslutar arbetaren bearbetningen av förfrågan - och väntar en stund (håll livstid), om ytterligare förfrågningar kommer att följa i detta sammanhang. Det vill säga att det bara hänger i minnet.

Event MPM skapar en extra tråd som tar över väntan på alla Keep-Alive-begäranden, vilket frigör arbetaren för andra användbara saker. Som ett resultat minskas det totala antalet arbetare avsevärt, eftersom ingen väntar på kunder nu, men alla arbetar.

• Flöde
• Inuti servern
• Dynamik
• Rena

Apache + mod_perl

Det speciella med Apache -paketet med mod_perl är möjligheten att ringa Perl -procedurer medan Apache behandlar en begäran.

På grund av det faktum att mod_perl fungerar i samma adressutrymme med servern kan den registrera sina procedurer via Apache -krokar i olika stadier av serveroperationen.

Till exempel kan du arbeta i samma skede som mod_rewrite genom att skriva om url:n i PerlTransHandler-kroken.

Följande exempel beskriver omskrivning från / exempel till / godkänt, men i perl.

# i Apache-konfigurationen med mod_perl aktiverat PerlModule MyPackage :: Exempel PerlTransHandler MyPackage :: Exempel # i filen MyPackage / Example.pm package MyPackage :: Exempel använd Apache :: Constants qw (DECLINED); använda strikt; underhanterare (min $ r = skift; $ r-> uri ("/ godkänt") om $ r-> uri == "/ exempel" return AVKAST;) 1;

Tyvärr är mod_perl ganska tungt i sig, så att använda det bara som omskrivningar är väldigt dyrt.

Till skillnad från mod_php är pärlkornmodulen ihållande, det vill säga att den inte initierar sig själv varje gång. Detta är bekvämt eftersom det tar bort behovet av att ladda om ett stort gäng moduler före varje begäran.

• Process / tråd - beror på MPM
• Inuti servern
• Dynamik
• Beständig

Vriden

Denna asynkrona server är skriven i Python. Dess särdrag är att webbapplikationsprogrammeraren själv skapar ytterligare arbetare och ger dem uppgifter. # exempelkod på servern vriden # lång funktion, bearbetning av en begäran def do_something_big (data): .... # medan en begäran behandlas d = deferToThread(do_something_big, "parametrar") # binda återuppringningar till resultatet do_something_big d.addCallback (handleOK) # .. och till ett fel vid exekvering av do_something_big d.addErrback (handleError)

Här använder programmeraren vid mottagandet av begäran deferToThread -samtalet för att skapa en separat tråd som har till uppgift att utföra do_something_big -funktionen. När do_something_big har slutförts kommer handlingsOK -funktionen att köras, vid fel - handleError.

Och den aktuella tråden kommer att fortsätta med normal anslutningsbehandling vid denna tidpunkt.

Allt händer i ett enda adressutrymme, så att alla arbetare kan dela till exempel samma array med användare. Därför är det lätt att skriva applikationer med flera användare av chattyp i Twisted.

• Flöde
• Inuti servern
• Dynamik
• Beständig

Tomcat, Servlets

Servlets är ett klassiskt exempel på streaming webbapplikationer. En enda Java -programkod körs i flera trådar. Synkronisering är obligatorisk och måste göras av programmeraren.

• Flöde
• Inuti servern
• Dynamik
• Beständig

FastCGI

FastCGI är ett gränssnitt för kommunikation mellan en webbserver och externa arbetare, som vanligtvis körs som processer. Servern överför miljövariabler, rubriker och förfrågningsinställningar i ett speciellt (icke-HTTP) format, och arbetaren returnerar ett svar.

Det finns två sätt att skapa dessa arbetare.

1. Integrerad med servern
2. Separat från servern

I det första fallet skapar servern själv externa arbetarprocesser och hanterar deras nummer.

I det andra fallet används en separat "spawner" för att leka arbetarprocesser, det andra, en extra server som bara kan kommunicera med hjälp av FastCGI -protokollet och hantera arbetare. Vanligtvis skapar spawner arbetare som processer, inte trådar. Dynamik / Statisk bestäms av spawnerns inställningar, och Pure / Persistent bestäms av arbetsflödets egenskaper.

Sätt att arbeta med FastCGI

Det finns två sätt att arbeta med FastCGI. Den första metoden är den enklaste, Apache använder den.

ta emot en begäran -> skicka in för behandling i FastCGI -> vänta på svar-> ge ett svar till klienten.

Den andra metoden används av servrar som lighttpd / nginx / litespeed / etc.

ta emot en begäran -> skicka in för behandling i FastCGI -> behandla andra kunder-> ge ett svar till klienten när den kommer.

Den noterade skillnaden gör att Lighttpd + fastcgi kan arbeta mer effektivt än Apache gör, för medan Apache -processen väntar har Lighttpd tid att betjäna andra anslutningar.

FastCGI -driftlägen

FastCGI har två driftsätt.

• Svarare - normalt läge när FastCGI accepterar en begäran och variabler och returnerar ett svar
• Authorizer - läget när FastCGI tillåter eller nekar åtkomst som ett svar. Praktiskt för övervakning av stängda statiska filer

Båda lägena stöds inte på alla servrar. Till exempel i Lighttpd -server - båda stöds.

FastCGI PHP vs PERL

PHP -tolkaren rengör sig själv varje gång innan manuset bearbetas, och Perl behandlar helt enkelt begäranden en efter en i en slinga så här:

Anslut moduler; medan (begäran kom) (bearbeta det; skriv ut svar;) Därför är Perl-FastCGI mycket effektivare där hjälpmoduler innehåller det mesta av körtiden.

Sammanfattning

Artikeln diskuterar allmän struktur förfrågningshantering och arbetartyper. Tittade också på Apache Event MPM och hur man arbetar med FastCGI, tittade på servlets och Twisted.

Förhoppningsvis kommer denna översikt att fungera som en utgångspunkt för att välja en serverarkitektur för din webbapplikation.

Om en dator som är ansluten till nätverket används varje dag, om Internet också är anslutet till en mobil gadget, kommer varje användare då och då över ordet - "server". Dessutom kan detta ord hittas i olika kombinationer, och inte alla användare förstår vad i fråga... Vad är dolt före ordet "server", och varför behöver användare det?

Termen "server" kan betyda en hårdvaruenhet och programvara för den (hårdvara och virtuell). En hårdvaruserver är en separat dator. Det behövs för att säkerställa driften av andra datorer och kontorsutrustning. En virtuell server är programvara. I det här fallet kombinerar en viss server dessa två typer.

Det första du ska komma ihåg är att dess uppgift är att underhålla nätverket och användarna, inte att hantera nätverket. Användare ställer in uppgifter på servern själva, och det löser dem snabbt. Ju bättre servern, till exempel HP -servrar, desto bättre utför den sina uppgifter.

Det är svårt att föreställa sig arbetet med stora företag med mycket elektronisk utrustning utan att kombinera alla dessa enheter i ett nätverk. Servern i företaget låter dig fjärrstyra kontorsutrustning och låter datorer interagera med varandra.

Serverkrasch eller fel kan leda till katastrof

I företag kan servrar optimera alla avdelningar. Men också i Vardagsliv vi står ofta inför servrarnas arbete. I synnerhet använder kassörer vid kassa och banker en server för att skriva ut dokument och göra betalningar. Servern stöder arbetet med alla utskickare, sociala nätverk och kommunikationshanterare.

Servern ger åtkomst till nätverket. Alla webbplatser lagras på servrar. Detta tillhandahålls av delad hosting. Denna tjänst tillhandahålls av värdföretag.