Loading
Note di Apprendimento
Study Reminders
Support
Text Version

Flusso di controllo, URL & protocollo HTTP

Set your study reminders

We will email you at these times to remind you to study.
  • Monday

    -

    7am

    +

    Tuesday

    -

    7am

    +

    Wednesday

    -

    7am

    +

    Thursday

    -

    7am

    +

    Friday

    -

    7am

    +

    Saturday

    -

    7am

    +

    Sunday

    -

    7am

    +

Ciao, benvenuto nello sviluppo di applicazioni moderne. Nelle sessioni precedenti abbiamo discusso CLI, e le app della GUI. E abbiamo visto come evolvere quelle app in un'app web utilizzando un programma CGI. Per cominciare, analizzeremo come abbiamo fatto l'evoluzione e ottenere un'idea chiara delle modifiche del flusso di controllo e dell'architettura interna delle applicazioni. Dopotutto, ci muoveremo per avviarepensando agli URL come programmatori piuttosto che come utenti. Anche se, tutti conoscono URL come oggetti che vengono utilizzati quotidianamente per varie applicazioni web.
Di solito ci abbiamo pensato come utenti piuttosto che come programmatori e come vedrete, abbastanza unpochi dettagli tecnici arrivano quando si pensa a loro come oggetti rilevanti per la programmazione. Il nostroprossimo passo sarà quello di guardare il protocollo HTTP e studiare gli strumenti che ci permettono di ispezionare ciò che èin corso quando viene utilizzato HTTP. Infine, studieremo web browser Devtools che sonostrumenti fondamentali per qualsiasi programmatore web.Durante questa sessione, effettueremo diverse demo e dovreste avere i seguenti programmipronti: potete utilizzare una distribuzione come XAMPP che ha cose come Apache e MySQL e quindiforth, che potreste aver già installato per la sessione precedente. In caso contrario, è possibile provare a fareche ora. Gli altri programmi di cui abbiamo bisogno saranno quelli come SOCAT, NSLOOKUP e cURL.Questi sono disponibili sulla maggior parte Linux o su Windows, sicuramente tramite Cygwin e in alcuni casi potrebbero essere disponibili le versioni native.
In questa sessione andremo a superare le idee fondamentali che sottendono il programma web. Questeidee costituiscono una massa di dettagli e ci vorrà del tempo per far conoscere queste ideeorganizzate insieme, ma rimanete con essa, perché queste idee sottendono gran parte di quello che verrà. Comesviluppiamo la nostra app, inizierai a vedere come queste idee giocano la loro parte in diversi pezzi dell'applicazione. Per aiutarti a organizzarlo, voglio sottolineare la grande visione della foto che tudovresti tenere a mente, e poi alloggiare queste idee in diverse parti del quadro più grande mentre andiamo avanti.
Il tema principale è che ci sono tre componenti chiave le cui interazioni definiscono le infrastrutture webe di conseguenza, definire anche il comportamento delle applicazioni. Questi tre componenti sono:il browser, il protocollo HTTP e il server. Vediamo come funzionano queste tre cose con ognialtro.
Così, a destra sono tutti gli elementi e le interazioni che andiamo a studiare in questa sessione.Sappiamo tutti qual è l'idea complessiva:
• Abbiamo un URL, come nptel.ac.in e viene dato al browser come URL• Il browser in qualche modo si capisce dove si trova il server. È qui che il browserinteragisce con il sistema dei nomi a dominio che converte il nome host in un indirizzo IP.• Una volta che ha l'indirizzo IP, stabilisce una connessione TCP e esegue una richiesta HTTP.Quindi, sta accadendo qualcosa di insolito qui, la connessione è in un protocollo e un protocollodiverso viene in cima. Quello che succede esattamente qui è quello che andremo a capirein questa sessione. Così che, entro la fine di questa sessione, questo diagramma sarà significativo perte.• Dopo di che abbiamo richiesta e risposta HTTP e ci sono piuttosto pochi dettagli intricatiche devi avere ragione in ordine per questi comportamenti di richiesta e risposta per aiutare a mettere
insieme il web in modo scalabile. Come per tutta la programmazione, sebbene il quadro più grande siaragionevolmente chiaro tagliato, è nei dettagli che le cose si fanno interessanti.(Fare Slide Time: 04.35)
Nella prima parte di questa sessione rivederemo come abbiamo cambiato l'app CLI all'app della GUI al'app web CGI, guardando ai dettagli di quali modifiche abbiamo apportato all'architettura interna comebene come il flusso di controllo tra diverse parti del sistema.(Fare Slide Time: 04.59)
Così, iniziamo con l'app CLI standard. Qui, abbiamo tre parti della CLI:• User• Program• Database store
E come tutti sappiamo, è una cosa abbastanza semplice l'utente mette al comando, argomenti oinput standard, il programma fa il suo calcolo, arriva con la risposta e lo stampa. Itsi sente esattamente come una funzione chiamata a noi e anzi l'architettura interna del codice è anche moltosimile.
È semplicemente una serie di chiamate di funzione che eseguono elaborazioni e salvataggio dei dati. Al massimo se ci sonopiù comandi, poi ci gireremo sopra. Inoltre, notiamo che per quanto riguarda la lingua shell, la CLI appare esattamente come una chiamata di funzione. Noi programmatori possiamo pensaredi esso come chiamata di funzione, ma gli utenti normali la penseranno come un comando.
 
Il passo successivo nella nostra discussione è il programma GUI. Nel programma della GUI abbiamo fatto un bel po' dimodifiche. In particolare, il programma doveva essere suddiviso in una parte di vista, che mostra a quale partel'utente vede, e il modello in cui avviene il calcolo. Queste due parti sono collegate da
gestori che, nella maggior parte dei casi come abbiamo visto, sono semplici riferimenti che raccontano parti della vistache parti del modello da cambiare.Il flusso di controllo qui, come abbiamo visto, ora dovrebbe essere familiare a noi. Quando si esegue l'app,l'app mostra la vista; c'è un loop di eventi, che guarda le presse del pulsante poi si raccolgono i dati del campoe si esegue qualunque comando il pulsante ha chiesto di aggiornare il modello einfine, aggiornare la vista e mostrare qualunque sia il risultato che potrebbe essere.(Fare Slide Time: 06.58)
Internamente, l'architettura cambia come abbiamo discusso di seguito. Quello che succede è che il programmaviene suddiviso in parti piuttosto distinte. Una parte è responsabile interamente per gli sguardi e l'altro peril calcolo e le due parti sono collegate utilizzando gestori più il loop dell'evento che prende il lavorodi tenere il programma in funzione, ascoltando le richieste degli utenti e rispondendo fino a quando l'utentedecide di terminare il programma. Da questi due programmi abbiamo costruito il programma web.
Così mettiamo a confronto quello che sembra relativo ad un programma GUI, proprio come c'è una vista e un modelloin un programma web. Ci sono i due componenti; il browser e il server per un programma web. Questa volta, invece di gestori che collegano la vista e il modello, il protocollo HTTPconnette il browser e il server. L'analogia tra vista e modello in un'unica applicazioneversus la distinzione dei server del browser è ragionevolmente accurata per le applicazioni semplici.Ma come abbiamo discusso in precedenza, nella sessione della GUI, l'analogia può diventare abbastanza complicata comela complessità dei programmi del browser e dei server aumenta, ma questo è per un secondo momento. Ainizia con, questa analogia è molto utile per capire cosa sta accadendo qui.
 
Il passo successivo che, andiamo a guardare l'architettura interna di come è che costruiamo il programma server, e nel nostro caso, abbiamo realizzato quello che è essenzialmente un ibrido. Abbiamo preso il programma di rigadi comando, riepurarlo e lasciare che il server venga eseguito. Quindi, lasciate che i cali passino attraverso la sequenza di quello chesuccede qui. Il browser presenta la UI iniziale che viene scritta in HTML e ascolta le azioni dell'utentee registra i dati degli utenti.
Il browser poi converte i dati degli utenti in un modo che si adatta ai requisiti del protocollo HTTP, il serverconverte quindi i dati di protocollo in informazioni sull'ambiente per il programma CGI bin. Seconfronta il bidone CGI versus il programma della riga di comando, ciò che notiamo è che, sono da egrandi gli stessi tranne che il modo in cui si collegano all'ambiente in cuiesegui, differisce.Così, invece di ricevere input da solo la riga di comando, il programma CGI ottiene il suo input dalle variabili di ambienteoltre che standard in e dopo che lo si fa stampi il suo risultato all'output standardche è, a sua volta, letto dal server. Il server quindi lo formatta in un form che funziona peril protocollo HTTP e lo invia al browser. Il contenuto deve essere tale che il browser possainterprearlo e visualizzare la risposta pronta per il ciclo successivo.
Cos' è il romanzo oltre la suddivisione nella parte modello e vista parte è che il browser e il servere il programma database possono esistere su macchine separate. Quindi, è come se ci fosse una sorta di efficienteche va dall'architettura della GUI all'architettura del programma web e alcuni aspettidel programma della riga di comando possono essere conservati in questa vista.
Quindi, quello che abbiamo è un programma che è fondamentalmente una sorta di ibrido come CLI, per quanto riguarda la parte di calcolo, è essenzialmente lo stesso ciclo dato che viene messo a produrre output come la GUI; l'esperienza utente come servizio continuamente disponibile. Ma perché abbiamo introdotto un modelloe una vista, si ottengono alcuni aspetti di un'esperienza utente continua anche se il programma sottostanteè molto simile a un programma di riga di comando.
 
Il nostro prossimo programma, però, sarà molto più GUI come. La nostra confezione iniziale CLI ci ha datosolo la separazione della vista modello ma diversamente da un programma GUI, non ci sono interazioni basate sul pulsante.Ma prima di andare avanti a quel programma, prima - studieremo il protocollo HTTP che connette il browsere il server e vedremo cosa fa per i programmi che abbiamo scritto finora.
Facciamo in sintesi quello che abbiamo visto del flusso di interazione finora:• CLI ha una funzione come il flusso senza accesso di memoria attraverso i richiami tranne comememorizzata nel database.• In una GUI, si conserva una certa cronologia in memoria e otteniamo l'importante nuova abilità perl'interazione dell'utente da dipendere da &ldalo come l'utente ha interagito finora.• Il nostro programma ibrido fornisce un'interazione continua senza alcuna conservazione della memoria.Perché tutta la conservazione avviene o dovrebbe avvenire sul lato server ma il modo in cui è scritto il programma CGI, è essenzialmente solo un reimballaggio del programma della riga di comando. Sull'altra manoqualcosa di importante è già stato raggiunto, perché abbiamo spostato il nostro programma sul'infrastruttura web. Lo troveremo molto più semplice in seguito, anche se tenessimo il programma giustocome CGI bin per aggiungere più strutture come più utenti e la possibilità per gli utenti distribuiti di condividerequesto programma, come tutti sappiamo, dalle app web.Così, oltre alla GUI come il comportamento, questa è l'altra cosa importante che l'infrastruttura webci dà. E nei programmi successivi vedremo che è possibile recuperare la capacità della GUI di conservare la cronologiautilizzando cookie e altri indicatori di sessione con modi per ricordare i dati di sessione sulato server distinti dai dati computazionali.Ma quelle sono cose che arriveremo in seguito. Per ora ci dirigeremo a studiare URL eprotocollo HTTP. Ecco, questa è la prossima parte della nostra sessione.
 
In questa parte, porteremo uno sguardo ai componenti dell'URL, in particolare le stringhe di query e altri aspetticome porte e host locali. Questi sono dettagli che inizieranno a maturare quando iniziamo a pensaredi URL come una sorta di interfaccia a un'applicazione web.
Quindi, pur avendo familiarizzato con loro dall'uso quotidiano, dobbiamo capirli insieme comeinterfacce componentate più partecipanti al protocollo HTTP. Un protocollo è una serie di regole che
è implicito in ogni due entità che comunicano se si tratta di persone o computer e i dettaglidi come quella comunicazione avviene anche in tutta la programmazione web.
Un URL è l'acronimo per il localizzatore di risorse universali. Si tratta, come dice, di un localizzatore un indirizzo per una risorsa. La struttura di un URL è del form protocollo barra barra porta nome barra porta barrapercorso. Questa struttura ha due parti importanti; una è l'hostname e la porta che identifica il server, il percorso che identifica la risorsa all'interno del server e il protocollo, che per la maggior parte degli utilizzi comunisi rivela sia HTTP o HTTPS.Ad esempio: in http://nptel.ac.in/noc, il protocollo è HTTP. Il nomehostname ènptel.ac.in e il percorso è noc. Possiamo pensare a questo come un localizzatore di risorse ma al browserfunzioni come una serie di istruzioni. Quando al browser viene chiesto di recuperare un URL, ci voglionoi seguenti passaggi: Prima ricerca il server e il nome &ld'nptel.ac.in che è poiposizionato sotto forma di (quello che viene chiamato) indirizzo IP. Alcuni di questo si potrebbero già conoscerecon.
Ma, ripeterò queste cose in dettaglio per chi non lo è. La mappatura da questo nomeall'indirizzo IP viene effettuata da qualcosa chiamato DNS (Domain Name Server), che noidiamo brevemente uno sguardo in seguito. Poi la parte successiva dell'istruzione al browser è quella di avere
posizionato il server, il browser dovrebbe utilizzare il protocollo HTTP per parlarne. Come parte di parlare conil server, invia il percorso noc al server e poi il server riprende.
Il browser ora attende solo che il server restituga il contenuto dell'URL ed ecco cosail server fa accanto, riceve l'URL e lo interpreta come la seguente sequenza di istruzioni: prima, verificare che il server debba agire come il server chiamato nptel.ac.in. Questo èfatto tramite configurazione che è nota al server. Il passo successivo è quello di prendere la risorsaal percorso noc, che sa individuare di nuovo tramite varie configurazioni.Poi leggere il contenuto e inviarlo al browser. La risorsa qui è solo quello che possiamopensare come un sacchetto di byte. Di solito si tratta di un documento HTML, ma anche come sappiamo, PDF e videoe vari altri formati di dati sono disponibili anche come risorse. Il componente del percorso dell'URL èchiamato anche URL di richiesta. Riassumiamo queste terminologie tecniche come la risorsalocator, hostname e protocollo, etc., in seguito, ma quelle sono più familiari a noi.Come programmatori, è la nuova insolita terminologia come richiesta URL che diventa importante indiscutere esattamente come programmiamo il web. Gli URL come nptel.ac.in/noc sono il tipo di URL più semplice. Ci sono molti URL più complicati che dovremo dare un'occhiatain un minuto. Quindi, iniziamo da noi.
Il prossimo tipo di URL più comune è quello che viene chiamato URL con una stringa di query. Prova ilseguente: vai a qualsiasi pagina su Wikipedia, diciamo “ en.wikipedia.org/MadhavaofSangamagrama ” e poi in alto a destra, vedrai una casella di ricerca. Ora digita URLnella casella di ricerca e hit entra. E poi guarda l'URL nel browser, vedrai un URL complicatodel modulo mostrato di seguito. E ora cerchiamo di identificare le parti dell'URL.In questo caso vedremo che il percorso o quello che si chiama URL di richiesta, è questa parte che sonoad evidenziarlo è /w/index.php. La parte dopo il punto interrogativo è chiamata stringastringa e nell'esempio corrente ha cose come ricerca e titolo e così via. E andiamo avanti fino ala fine di questi personaggi speciali. Quindi, è possibile questa parte dopo che il punto interrogativo si chiama la stringa di query. Si può pensare a questo come una sintassi diversa per le parti di funzione.I nomi dei parametri della funzione sono cose come il titolo di ricerca e la parte dopo ogni &ld'uguale di ugualeè il valore del parametro. È possibile digitare direttamente URL, come en wikipedia.org, ecc. e inserire un termine di ricercadirettamente nel browser. E avrà lo stesso effetto di fare la ricerca dalla scatola,anche senza alcuni parametri estranei che arrivano dalla scatola. Quindi proviamo questo.
Ok, proviamo a provare il caso appena visto. Eccoci alla pagina di Wikipedia perMadhava di Sangamagrama. E qui abbiamo la casella di ricerca con URL scritto in esso. (VideoStarts: 20.07) Se colpiremo subito qui, possiamo vedere l'URL con una stringa di query che contiene
cose come ricerca e titolo e ricerca full text, che ci racconta di aver chiesto a Wikipedia, adi guardare praticamente tutto con la parola URL in esso, soprattutto quelle che contengono il titolo dil'URL dato.E come ho detto, ora possiamo andare alla stringa della query e rimuovere la parte URL e inserire HTTP. Eora vedrete che qui stiamo ricevendo tutto su HTTP, ad esempio, hypertexttransfer protocol, HTTPS, etcetera, etcetera sono un comportamento alquanto diverso se sirimuovere i parametri estranei e provare solo HTTP. Ora, perché c'è una pagina unicadesiderata. Andiamo dritti alla pagina HTTP e ci accorgiamo che l'URL, sebbene l'abbiamo digitato come nel modulo di stringa della query, è cambiato in un normale URL di aspetto. (Video Ends: 21.15) Vediamo ulterioricomportamenti interessanti una volta che si inizia a diventare consapevoli di come il motore di ricerca URL.
Per esempio, se si cerca la stringa di spazio della query della frase nella casella di ricerca, si vedrà chel'URL del browser si trasforma in una stringa più stringa. Ad esempio, nel caso Wikipedia, abbiamosearch uguale query plus string seguita dagli altri parametri di ricerca. Per vari motivi,caratteri come spazi vuoti si trasformano in sequenze codificate speciali. Un motivo per questo è che lesequenze di caratteri non spaziali sono spesso più facili da lavorare con i programmi.Ma ci sono altri motivi storici per cui certe codifiche esistono. Ci sono molti dettagli insoliticome questo che contano nella programmazione web. Come programmatore web spesso si impara questi come si va
su ma devi essere consapevole che esistono. Un motivo per cui ci sono delle regole così strane è cheil web crebbe alquanto come un organismo biologico per 25 anni o così. E di conseguenza ha un agglomeratodi ogni sorta di regole peculiari che sono state create quando persone diverse hanno apportato modificheal web per motivi diversi. E il web che vediamo oggi è in realtà un risultato di tutti quei cambiamentiche accadono attraverso molti anni.
Quindi, come affrontiamo queste radici peculiari? La maggior parte di queste radici sono state create, come ho detto, perragioni che erano buone quando sono state inventate, ma ora sono state semplicemente assorbite inl'ecosistema. Di tanto in tanto vi segnalo questi tipi di cose a voi e dovresteanche tenere la vostra lista di cose che noterete. Per me dopo tanti anni, molte di questecose sono diventate seconda natura.Ma per voi che vi incontrate per la prima volta fare una lista è forse la cosa miglioreche potete fare. Alla fine, ti diventeranno familiari. E sarai in grado di guardare i siticome Stackoverflow e Wikipedia come necessario per le idiosincrasie che le persone abituate a conoscere a un puntonel tempo ne parlavano. E fortunatamente per noi, sono disponibili per noi da imparare. In tutta questasperimentazione è essenziale.
Si dovrebbero costruire piccoli siti web di prova sulla propria macchina, dove si sperimenta le regole ele capiscono nel dettaglio. Fortunatamente, a differenza degli scienziati o di altre persone che hanno bisogno di lavorare concose fisiche, i nostri esperimenti non hanno bisogno di molte risorse. Hanno solo bisogno di tempo e pazienza.
Il prossimo componente a cui pensare è una porta URL. Oltre al nome server per URL puòavere una porta esplicita nella forma, diciamo 8080. Questo URL in realtà non esiste, ma il sitoexample.org esiste. Example.org è stato un sito creato nei primi giorni del web, per il solo scopodi essere, come dice, un esempio. E in un nome breve come example.org, la porta 80 èeffettivamente assunta.Potete mettere in pausa questo video ora e andare a visitare example.org per vedere cosa dice. Il numero di portaperché è comune per la maggior parte degli URL quando è 80 non è mai, non è menzionato dal browser.Si potrebbe aver notato che i browser oggigiorno nascondo persino protocolli come HTTP, sebbene ad unavolta non siano mai abituati a fare cose del genere. Quindi, qual è un numero di porta? Il numero di porta per un serverè associato ad un determinato servizio.Ad esempio:• il protocollo HTTP utilizza la porta 80.
• HTTPS utilizza 443.• FTP usa 20 e 2.
Se un indirizzo IP di un server è come il numero di telefono di un ente, il numero di porta è come l'estensionenumero per l'ufficio di qualcuno in quella istituzione e l'indirizzo completo per una persona nel casodell'ufficio sono entrambe parti. Analogamente, l'indirizzo completo per un servizio è il nome del serverseguito dal nome della porta.Quando si esegue il proprio server web per esempi di pratica, spesso è utile avere più diun server web in esecuzione su porte diverse come 8080, 8000, 8001 ... ecc. I numeri di porta sotto1024 sono risultati per molti scopi. Quindi le porte del sito di pratica sono spesso correlate per motivi storicipuoi usare qualsiasi nome vuoi, qualsiasi numero vuoi, e non fa differenza. Quindi, vediamocome sembra eseguire più servizi host locali sulla tua macchina.
Come abbiamo visto dalla sessione precedente, i server web e le macchine di sviluppo possono essereindirizzati utilizzando lo speciale hostname localhost. Per il server web locale, possiamo utilizzarehttp://localhost, o https://localhost. Di solito, oggigiorno un server web comeapache sarà configurato per presentare endpoint sia HTTP che HTTPS. E l'indirizzo IP avrà anchelavoro invece che hostname.
Ad esempio, per l'host locale è possibile utilizzare “ 127.0.0.1 ”. E sul web server sulla tua macchinapuoi provare a iniziare ad apache nei diversi porti. Per farlo devi essere in grado di modificarela configurazione per apache o qualsiasi altro server web che utilizzi. Per qualunque server web tuutilizzi, cerca sul web con una query, come come eseguire apache sulla porta 8080. E di solito la prima rispostavi dirà esattamente cosa cambiare nella configurazione.
Bene, ora che abbiamo visto abbastanza pochi dettagli sugli URL, riassumiamo. Gli URL sonoindirizzi di risorse, dove una risorsa è un dataset di qualche tempo. Di solito i dati in una risorsasono in formato HTML, ma altri come PDF, JavaScript, JPG, ... etc. sono comuni. L'URL è composto dadi un protocollo, il nome host, un numero di porta, un percorso, chiamato anche URL di richiesta epossibilmente una stringa di queryUn URL può includere caratteri speciali come la linguetta dello spazio, il punto interrogativo barra, ecc. inmodi diversi. Una stringa di query è come una chiamata di funzione. Ha nomi di parametri e valori che sonoseparati da caratteri uguali. Ma la porta aiuta una singola macchina ad offrire più servizi. Questa terminologiaè così comune che avremo esami e assegnazioni che assicurano che voiimparate bene questa terminologia.
Ok, così ora siamo fatti con URL. E il nostro prossimo passo sarà quello di guardare i dettagli dei protocolli.