Det här blogginlägget är ett GRATIS kapitel från boken Jump Start PHP Environment av Bruno Skvorc.

Det är viktigt att förstå de grundläggande koncepten och processerna för webbprogrammering innan du går in i snygga-grotta detaljer om kodning i PHP. som detta kapitel åstadkommer.

Innan vi presenterade texten från kapitlet ställde vi Bruno några frågor.

HostAdvice: Vad fick dig att skriva den här boken?
Bruno Skvorc: Jag ville skriva en bok som tar upp det som förhindrar de flesta att komma igång med PHP – installationen som kommer före den faktiska koden. Vilken programvara behöver du? Varför? Varför inte X och varför Y istället? Hur uppnår du en identisk inställning när du distribuerar din app live och vad du ska använda för att matcha saker i hela teamet. Jag ville i princip förklara "infrastruktur" av PHP i allmänhet och PHP-appar, på ett sätt som rensar upp saker och sätter upp en solid grund för att starta kodning på rätt sätt.

HostAdvice: Vilken ny kunskap fick du när du skrev boken?
Bruno Skvorc: Jag lärde mig att tekniska böcker blir föråldrade ännu snabbare än jag ursprungligen förutsåg. Genom att svara på frågor om installationsproceduren som kom upp på grund av mikroförändringar i den programvara som användes, fick jag veta att instruktionerna måste vara så breda och universella som möjligt, samtidigt som jag bibehåller tydlighet och fokus. Det var den svåraste delen – att göra instruktionerna tidlösa med tanke på hur tidskänslig programvaran vi använder är. Jag håller för närvarande på att förbereda en uppdatering av boken som hanterar de flesta av dessa förändringar permanent.

HostAdvice: Alla andra råd för våra läsare?
Bruno Skvorc: Med tanke på att jag täcker några värdmetoder i boken och sätt att få servrar att fungera för dig istället för tvärtom, tror jag att den här boken skulle vara en utmärkt resurs för Hostadvice-besökare – särskilt eftersom jag förklarar varför delad hosting (även om jag använd det för vissa saker också) är inte riktigt ett anständigt alternativ i dag. Detta är särskilt sant eftersom jag täcker alla de mest grundläggande Linux-färdigheterna i den här boken och lär människor att göra vissa grundläggande serverunderhåll själva. Beväpnade med dessa färdigheter kan användarna enkelt ställa in en mycket kraftfullare maskin än en delad värddator och köra någon form av programvara på det – inga begränsningar som företaget du betalar för att köra saker åt dig.

Webbfråganas anatomi

Innan vi går in i det snygga att skapa en bra PHP-miljö, behöver du en förståelse för hur webbegäran faktiskt fungerar. I detta kapitel förklaras vad som händer när du stänger en webbadress i din webbläsare och får ett resultat. Vi’Undvik att vara för teknisk ― där’du behöver inte förklara muttrar och bultar, eftersom det troligen bara skulle förvirra dig. Istället kommer det att vara en nybörjningsvänlig förklaring på hur alla olika aspekter av webbutveckling och webbkonsumtion samlas och skapar webben du känner och älskar. Huvudsyftet med detta kapitel är att lära dig var ditt programmeringsspråk du väljer (i detta fall PHP) spelar in, och vilka delar av den mystiska webbbegäran det påverkar.

Om du känner till det väsentliga på webben och känner till villkoren som nämns i föregående stycke, känn dig gärna till nästa kapitel.

Klienten och servern

Du måste ha hört talas om villkoren “klientsidan programmering” och “programmering på serversidan,” åtminstone i jobbannonser. I den här delen, vi’Jag förklarar dem kort innan du går vidare med detaljerna.

Vad är en klient?

EN klient är din webbläsare.

I samband med webben, medan du tekniskt är klienten i det konventionella
känslan av ordet (du gör begäran och betjänas av programvara), webbläsaren anses vara den klientprogramvara brukade fråga servern om något.

När den har fått detta “något” (som oftast är ett gäng text), det avgör hur det ska presentera det för dig, den ultimata klienten.

Vad är en server?

Liknar klienten, a server har också två betydelser:

  1. ett program som svarar på frågor som ställs av klienten
  2. en dator (en fysisk maskin) som serverprogrammet är installerat på

I den här boken, och i samband med webbutveckling, menar vi i allmänhet den förra.

Faktum är att vi i hela denna bok’Jag får veta hur vi enkelt kan installera ett serverprogram på vår egen dator “falska Internet” och låta datorn tänka på webbplatsen vi’återutveckling är online och tillgänglig för alla.

Låta’s titta på den första punkten lite mer: hur svarar ett program på frågor?

I ett nötskal väntar en server på en fråga som “ge mig texten till blogginlägget
från 14 februari” och svarar med endera “OK, här: [lite HTML, som innehåller texten ofta inlägget i fråga]” eller “Tyvärr, det kan jag’t finner det där’s ingenting under 14 februari.” Visst, jag’mparaphrasing, men det’s mer eller mindre vad som händer.

jag’har illustrerat det i figur 1.1.

Webbfråganas anatomi Figur 1.1. En förenklad förfrågan till servern och dess svar

Webbutveckling är i själva verket en relativt enkel fråga om att få kunden att ställa rätt frågor och lära servern att ge rätt svar. Redo att gå lite djupare in i kaninhålet?
Här kommer …

Grunder för webbbegäran

Medan webbbegäran har en mycket specifik betydelse, det används ofta som en filtterm för kommunikationen mellan klienten och servern. Hela kommunikationsprocessen förklaras snyggt i figur 1.2, en söt komiker av VladStudio.

Webbfråganas anatomiFigur 1.2. Hur fungerar internet av VladStudio

Hur det fungerar

Låta’s bryta komiken i figur 1.2 ner.

Du är användaren ― du är kungen. Du ger ut kommandona och webbläsaren lyder glatt. Som användare är det här din medvetenhet om processen slutar och nästa gång du’som medvetet behandlas är i den näst sista bilden av komiken. Hela processen däremellan är osynlig för dig, utom när du’är en utvecklare; sen du’är en magisk trollkarlkung som kan se allt där’händer, men mer om det i senare kapitel.

Webbläsaren går igenom en brandvägg, som vanligtvis tas för givet. Du har antagligen någon form av brandvägg på din dator just nu eller i din router / modem. Webbläsaren vet hur man går igenom det eftersom du’Vi sa till vakten att webbläsaren är okej och borde släppas igenom.

Sedan kommer en del vi’har ännu inte nämnt: DNS (Domain Name System) servrar – en del som är så mystisk och oåtkomlig för de flesta, den stora majoriteten av internetanvändare (och utvecklare, till och med!) tar det för givet, accepterar att det finns och försök att inte oroa sig för det för mycket. Den allmänna konsensus verkar vara att, precis som frågor om livets mening, frågor om tid och rymds ursprung och den andra världsliga läckraheten med jordnötssmör och banankombo, vissa saker ― som ursprung och syfte för DNS-servrar ― bättre vänster utan tvekan. Om du fortfarande vill veta vad de är kommer de att förklaras i det avsnitt som heter “För dem som vill ha mer” i slutet av detta kapitel närmare.

Sammanfattningsvis fungerar det så. Varje domän på Internet (som “example.com”) är bunden till en specifik IP-adress (representerad av siffrorna på skylten i seriens tredje ram). En IP-adress är en uppsättning nummer som identifierar en given server; IP-adresser berättar webbläsaren hur man navigerar på Internet
hitta datorn (servern) den’s letar efter.

Kommer du ihåg longitud och latitud från geografikurser? De definierar specifikt en geografisk punkt på planeten Jorden och är kompatibla över hela landet, vilket innebär att vem som helst kommer att veta hur man hittar en plats om du ger dem värden på latitud och longitud; Men vi har också en mänsklig vänlig beskrivning för de mest populära koordinaterna.

Till exempel är namnet på staden jag gick på universitetet i Rijeka. Inte många kommer att veta var de kan hitta den på en karta, men om jag ger dem koordinaterna (45.3167 ° N, 14.4167 ° E), kan de enkelt hitta den. En DNS-server är en översättare, en guide. Denna server vet vilka IP-adresser som matchar vilket domännamn, och berättar webbläsaren vart den ska gå nästa.

När den har omdirigerats till en specifik IP-adress, knackar webbläsaren på dörren till värdservern. Den här servern nämndes i föregående avsnitt, och vi hänvisar bara till den som “servern.” Webbläsaren tar med sig den information som användaren begärde och ber servern om ett svar på frågan “google.com?”

Servern svarar: “Ja, under google.com säger filen …” och ger svaret. Webbläsaren återgår till användaren (kungen) och förmedlar informationen. Den här delen är vad’är viktigt för oss utvecklare ― berätta för servern vilket svar att ge för en specifik fråga. Kom ihåg den här delen.

Front-end och Back-end

den’det är dags att definiera ytterligare två termer du måste ha hört minst en gång. Front-end utveckling (även kallad utveckling på klientsidan) fokuserar på arbete med klientprogramvaran back-end utveckling (även kallad utveckling på serversidan) hanterar serverprogramvaran.

När en server returnerar text till din webbläsare (i figur 1.2 är det texten som’upprepas till kungen i den näst sista bilden) och din webbläsare presenterar den för dig, hur den texten ser ut och på vilka sätt du kan interagera med den är front-end (eller klientsidan)
programmering. När du öppnar en webbplats och en länk är fet och en annan färg än resten av texten, uppnåddes den förändringen i utseendet med programmering på klientsidan (HTML plus CSS). När du kan dra ett element runt på skärmen eller initiera animationer eller ljud, gör det’s uppnås också med klientsidan-programmering (specifikt HTML och CSS åtföljd av JavaScript).

Programmering på serversidan, eller back-end-utveckling, är åtgärden för att konfigurera serverdatorn och programmet (se avsnittet som heter “Vad är en server?” för en förklaring av denna dualitet) för att återge lämplig information till webbläsaren när du blir frågad. Detta betyder vanligtvis programmering på ett serversidespråk som PHP. PHP kommer att göra några beräkningar eller hämta data från en databas, förvandla den till
text som kan ges till webbläsaren, och webbläsaren tar den och visar den för användaren.

Även om allt innehåll som returneras till webbläsaren för leverans till användaren faktiskt lagras på servern, kallar vi CSS och JavaScript “klientsidan” eftersom deras beräkningar sker i webbläsaren. Om jag till exempel ber om JavaScript att animera en fyrkant som förvandlas till en cirkel kommer matematiken bakom beräkningen att ske i webbläsaren. Servern kommer endast att tillhandahålla formeln och berätta för webbläsaren: “När du tar tillbaka detta till din kung, säg det så här …” Å andra sidan innebär programmering på serversidan att all logik, beräkningar, formler och så vidare händer på servern, bara returnerar slutresultatet. Om jag till exempel har en webbplats som räknar antalet bilder som laddas upp av en användare (som Facebook räknar antalet bilder i ditt album) kommer den här beräkningen att göras på servern och endast det slutliga numret ges till webbläsaren när den ber om denna information.

För att sammanfatta: frontend är när du skriver kod som körs i webbläsaren (HTML, CSS, JavaScript), medan backend är när du skriver kod som körs på servern innan det slutliga resultatet överförs till webbläsaren. PHP, serversidan JavaScript, serversidan Dart, Ruby, Python och andra programmeringsspråk passar räkningen.

Dags att gå ännu djupare in i kaninhålet.

Språk på serversidan

Denna bok fokuserar på att förbereda en utvecklingsmiljö för programmering på serversidan. Vi vann’t handlar med HTML, CSS eller JavaScript; det finns gott om böcker om dem där ute, och att skapa ett utvecklingsflöde på klientsidan är tillräckligt komplicerat på egen hand. Istället vi’Jag kommer bara att ta itu med förberedelser på serversidan’Det är väldigt lätt att börja fel. Precis som en fläck på en ballong kommer att växa till en stor fläck när den fylls med luft, så kan också ett misstag i början av en programmeringskarriär växa till en långvarig skadlig vana.

Som du kanske redan vet inkluderar exempel på serversidan språk PHP, Ruby och Python. De sitter som program på serverns dator och som serverprogrammet. Dessa språk tar vissa kommandon från serverprogrammet och skickar resultatet av dessa kommandon tillbaka till det. Det är denna utgång som ges till webbläsaren när en användare ber om ett svar på en viss fråga. I ett nötskal, genom att berätta
servern “Kör den här filen via PHP när en begäran kommer till webbplatsen example.com”:

Språk på serversidan

… vi har gett det ett sätt att ge ett svar för klienten. PHP-filen körs sedan och innehållet “Hej världen” genereras och skickas tillbaka till serverprogrammet, som sedan ges till webbläsaren. Webbläsaren tar tillbaka den till användaren och upprepar helt enkelt “Hej världen.” Webbläsaren slutar inte skicka om resten av filens innehåll; php-taggen <?php och nyckelordet eko hoppas över i utgången. Detta beror på taggen <?php berättar servern till “Kör den här filen via PHP” och sedan, när jag kör filen via PHP, berättar ekot för den “Skriv ut följande fras på skärmen.”

Om du’om du har problem med att ta tag i detta, se figur 1.3, som expanderar i figur 1.1.

Språk på serversidanFigur 1.3. Servern ber PHP om svaret om det’kan inte hitta en

I figur 1.3:

■ digramen representerar insidan av den fysiska datorn i figur 1.1
■ Nginx är ett webbserverprogram installerat på den här maskinen
■ Nginx får input från klienten i form av en fråga (blogg för 14 februari)
■ Nginx kontrollerar om det finns’s en sida för blogg / feb / 14
■ Eftersom det inte finns någon, kontrollerar Nginx vägarna mot PHP-filer
■ Nginx upptäcker att den måste köra blog.php-skriptet via PHP
■ skriptet blog.php ansluter till databasen och skickar tillbaka texten för det givna datumet
■ PHP-motorn skickar detta resultat till servern
■ Nginx skickar tillbaka det till klienten

För att sammanfatta: PHP är en svargenerator för servern så att den vet vilka svar att ge till webbläsaren’s frågor. På detta sätt gör servern det inte’t behöver veta svaren, det vet bara att PHP gör det och frågar det, och vidarebefordrar sedan svaret till webbläsaren. Föreställ dig en “Hej ditt namn” sida; den’det är omöjligt att generera sidor för varje befintligt namn, men vi kan låta PHP be om ett namn på en sida och sedan
generera svaret som ska ges till servern på en annan sida.

Vad’Det är viktigt att förstå här är kommunikationsflödet mellan klient och server, och server- och serversidan språk. Hela kommunikationen passar in i den femte och sjätte bildrutan i serien i figur 1.2. I själva verket skulle den del där serverprogrammet pratar med PHP-programmet hända helt och hållet i den sjätte ramen.

Generera svar med språk på serversidan

Den sista och djupaste nivån i vårt kaninhål är den faktiska konversationen mellan serverprogrammet och ett serversidan språk ― i vårt fall (och alla framtida fall), PHP. Vi behandlade detta till en del i föregående avsnitt, men låt’s titta på ett annat exempel nu med en situation där ett svar inte kan hittas.

Låta’s säger att servern ombeds följande av klienten: “Kan du skaffa mig vad du har arkiverat under example.com/user/id/54?” Så här händer:

  1. Servern kontrollerar om det finns’s något som redan är förberett under rutten: / user / id / 54. Om det inte finns några filer att hitta där, det’s konfigurerad för att fråga PHP.
  2. Servern frågar PHP: “Hej, kan du hitta allt under / User / id / 54?”
  3. PHP aktiverar och tittar igenom dess rutter. Se och se vägen / User / id / 54 säger “aktivera filen user.php med parameter-ID för värde 54.”
  4. PHP kör filen (filens faktiska logik ligger bredvid punkten och utanför ramen för detta kapitel) och får ett resultat. Kanske är resultatet e-postadressen för den 54: e användaren i databasen. Den här e-postadressen ges sedan tillbaka till servern: “Visst, jag hittade något under den vägen. Svaret är: [email protected]”.
  5. Servern svarar med “Tack!” och vidarebefordrar detta meddelande till klienten, som sedan presenterar det för slutanvändaren – du.

Men vad händer om det’Är inget arkiverat under den rutten? Till exempel finns det en skrivfel när klienten begär det example.com/urer/id/54 (hellre än “användare”). Här’vad händer:

  1. Servern kontrollerar om det finns’är någonting redan förberett under rutten: / Fact UReR / id / 54. Om inga filer hittas, det’s konfigurerad för att fråga PHP.
  2. Servern frågar PHP: “Kan du hitta något under / Fact UReR / id / 54?”
  3. PHP aktiverar och tittar igenom sina rutter, men misslyckas med att upptäcka någonting. Den returnerar a “404 Sidan hittades inte” fel till servern (som i figur 1.1, nedre vänstra resultat). Som du förmodligen är medveten om är 404 en kod som är vanlig i webbteknologier och betyder att det du letar efter inte kan hittas där du tror att det kan vara. Många sådana statuskoder finns, men det finns ingen anledning att känna dem alla i denna fas av din karriär.
  4. Servern tar emot 404-meddelandet och tänker “Hmm, PHP lyckades. Tja, det har ingenting, jag har ingenting, bättre skicka tillbaka en sida till klienten som säger att vi inte lyckades.” Webbläsaren får sedan en 404-sida, som vanligtvis bara är en textvarning som t.ex. “Oj, du försökte en fel länk!” men kan också vara så intrikata som du vill att det ska vara.

Jag litar på att detta kapitel var tydligt med de koncept som det presenterade och hjälpte dig att få
dina lager i termer av var du är (eller kommer att vara) i PHP: s stora plan
programmering. I avsnittet som följer, du’Jag hittar mer teknisk information
på webbförfrågningar och DNS-servrar.

För dem som vill ha mer

DNS-servrar

Som nämnts tidigare är varje domän (som exempel.com) på Internet bunden till en specifik IP-adress (t.ex. 93.184.216.34). En IP-adress är en uppsättning nummer som identifierar en given server. Med andra ord, IP-adresser berättar webbläsaren hur man navigerar på Internet för att hitta den dator (server) den letar efter. En DNS-server (även känd som bara namnserver) vet vilka IP-adresser som matchar vilket domännamn och berättar webbläsaren vart den ska gå nästa.

När du försöker ta reda på vilken IP-adress som matchar ett domännamn, kontrollerar webbläsaren först sin egen cache― En sparad lista över tidigare besökta domäner. Varje webbläsare behåller denna lista och uppdaterar den med jämna mellanrum. Om den hittar domän-IP-kombinationen i sin egen cache, laddas webbplatsen snabbare eftersom det finns’du behöver inte be DNS-servern om den. Om domänen inte är’t cache, frågar webbläsaren ett program som heter resolver (som är inbyggt i ditt operativsystem) för att kontrollera värdfilen på datorn’s installerat på. Värdfilen är där användaren faktiskt kan definiera vilken webbplats som kartar till vilken IP-adress. (Vi’Lär mig att använda den här filen i senare kapitel.) Om nödvändig information inte är’Där kontrolleras DNS-cachen på routern (routrar har vanligtvis också en) och om det’hittas inte heller ISP-företaget’s DNS-server ställs.

Fram till det sista steget hände allt på din egen dator, eller som vi säger lokalt. Nu när det’det är dags att besöka internetleverantören’är inte längre en lokal fråga ― det’s fjärrkontroll. Om ISP’s DNS-server är utan post för domänen, den tar reda på och berättar för webbläsaren, och cachar sedan resultatet för framtida frågor. Hur ser det ut? Det dissekerar domännamnet från höger till vänster.

www.example.com är uppdelat i fragment. .Com-delen, kallad TLD eller toppnivån domän, är först. Det finns många DNS-servrar världen över, ofta konfigurerade på ett sådant sätt att flera datorer fungerar som en. Detta är så att om en dör, andra ser till att tjänsten är oavbruten. Den högsta nivån av dessa servrar är root-servrar, som vet var man ytterligare kan leta efter detaljer om en domän på en given TLD. Rotservern med lämpliga poster för .com kommer att veta att det är en dot com, så kommer du att skicka en fråga längre i XYZ ― XYZ är en annan namnserver som känner till exemplet. Ytterligare fortfarande www-delen (även känd som underdomän) kommer att spelas in och registreras på en specifik namnserver också i denna förvirrande kedja med namn och servrar. När alla fragment (även känd som etiketter: .com, exempel och www) har lösts till en IP-adress skickas resultatet tillbaka.

Om du’d vill veta mer om rotnamnservrar och vill ta reda på hur hela Internet’s smidiga funktion beror på tretton huvuddatorer (ja, kluster av datorer), titta på rotnamnserversidan på Wikipedia, eller kolla in några otroligt omfattande svar på Super User.

Vad händer när du skriver …

En vanlig fråga om programmeringsjobbintervju är “Vad händer när du skriver google.com i din webbläsare’s adressruta och tryck på enter?” Medan vi delvis förklarade detta tidigare (om än på ett förenklat sätt), kolla in Alex Gaynor’s utmärkt beskrivning om du’d vill veta exakta detaljer, från hårdvara till slutprogramvara. den’är ett extremt omfattande men väldigt välskrivet inlägg. Observera att denna nivå av detaljerad kunskap inte är nödvändig för att vara en bra utvecklare.

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me