Necessita una risposta più tecnica per una domanda di intervista su come funziona Internet dall'inizio alla fine [chiuso]

Ho avuto interviste con 5 persone separate nelle ultime due settimane e tre di queste cinque mi hanno posto questa domanda: Spiega cosa succede tra colpire "Google.com" e la pagina che appare sullo schermo. Fondamentalmente, come funziona Internet. Immagino dopo tre volte che sarò meglio prepararmi se mai avessi di nuovo questa domanda.

Conosco alcune cose, ma non sono del tutto convinto che la mia risposta sia abbastanza buona. Fondamentalmente, menziono che il server DNS traduce "google.com" in un indirizzo IP. Ho un po 'di lucentezza su TCP / IP, quindi parlo del server web che serve letteralmente le pagine richieste che vengono rimandate al browser che il browser quindi interpreta e visualizza.

Come ho detto prima, non sono convinto che la mia risposta sia abbastanza tecnica. Quali sono i passaggi che sto lasciando fuori?

Per quello che vale, due di queste tre volte sono state con la stessa compagnia e mi richiamano per una terza intervista con loro, quindi non posso averlo bombardato troppo .

1. Il tuo browser ha innanzitutto l'aspetto del sistema operativo nel suo file "hosts" per una voce che tradurrà il nome di dominio in un indirizzo IP. Questa è una funzionalità legacy ereditata da ARPANET, quando era possibile per un singolo file di testo contenere nomi intelligibili per ogni computer accessibile tramite ARPANET e per ogni computer ad esso collegato avere una copia relativamente recente. Aveva un certo valore rimanente in piccole reti di computer che non avevano NetBIOS o protocolli di denominazione dei nodi simili, ma al giorno d'oggi è altrettanto probabile che sia un bersaglio per gli hacker (che possono usarlo per bypassare il DNS e indirizzare il tuo computer verso i siti controllano) come avere un uso legittimo a un computer client o al suo utente / proprietario.
2. Supponendo che il tuo computer non abbia una voce HOSTS per questo dominio, il tuo browser invia una richiesta UDP al server DNS configurato nelle impostazioni Internet del sistema operativo per la connessione in uso, passando il "nome host" noto anche come nome di dominio della richiesta (tutto tra "http: //" e i primi due punti o la barra in avanti seguendo quello che verrà dopo, ad esempio "www.google.com"). Questo server DNS appartiene in genere alla tua azienda o al tuo provider di servizi Internet locale.
   • UDP sta per "Universal Datagram Protocol" ed è un protocollo "livello di trasporto" nella stessa classe di TCP (sopra il protocollo IP "livello di rete", sotto i protocolli "livello applicazione" come HTTP, FTP, SMTP ecc. ). Mentre TCP offre molte funzionalità di controllo degli errori e di tolleranza agli errori (aggiungendo dati extra e aumentando così il sovraccarico), UDP adotta un approccio molto più leggero, aumentando la larghezza di banda dei dati netti; il compromesso è che il protocollo non supporta le funzionalità disponibili in TCP come la suddivisione di dati di grandi dimensioni in più pacchetti (quindi i messaggi devono essere piccoli) o il reinvio di pacchetti persi durante il trasporto. È utile per messaggi piccoli e semplici (come DNS) e streaming, dati di tipo telemetrico in cui non importa se un pacchetto viene perso.
3. Questo server DNS saprà una delle tre cose: come tradurre quel nome di dominio direttamente in un indirizzo IP (nel senso che è il "server dei nomi autorevole" o ANS per quel dominio); l'indirizzo IP dell'ANS o un suo genitore; o il proprio nameserver principale che è più probabile che sappia come raggiungere l'ANS. Se il server non traduce la richiesta stessa, inoltrerà la richiesta "down" verso un ANS noto o "up" al suo NS padre e questo processo si ripete in modo ricorsivo.
   • La "radice" di questa struttura ad albero è un singolo server che non fa altro che inoltrare le richieste che riceve a uno dei numerosi "domini di primo livello" o server TLD. Esiste, ad esempio, un nameserver ".com", che sa come trovare l'indirizzo IP di qualsiasi dominio ".com" sul pianeta (inoltrando queste richieste ai server dei nomi a livello di ISP). Questi TLD inoltrano richieste per i server dei nomi di dominio che non sono noti a nessun DNS all'interno di uno specifico "ramo" di Internet appartenente a un ISP.
4. Una volta trovato il server dei nomi autorevole e tradotto il nome di dominio in un indirizzo IP, questo indirizzo viene restituito al client e al suo browser. Se non è possibile trovare un ANS entro il "tempo di vita" della richiesta (TTL; il numero massimo di volte in cui la richiesta deve essere inoltrata tra server, per evitare cicli infiniti tra server non configurati), il nodo restituisce un errore al client che la richiesta "scade" (o il nodo che è il server autorevole per il dominio ma che non è in grado di tradurre il prefisso di dominio specifico).
5. Il browser, per una connessione HTTP, invia quindi una richiesta "TCP SYN" all'indirizzo IP e alla porta specificata (o la porta HTTP predefinita 80) per stabilire una connessione. Questa è una richiesta a livello di protocollo, sovrapposta all'intestazione IP "a livello di rete", che contiene informazioni come la porta di risposta preferita del client (la "porta di origine"), le preferenze per la comunicazione TCP come dimensione del segmento, scala della finestra e utilizzo delle funzionalità del protocollo opzionale.
6. La richiesta viene instradata a "livello di collegamento" (che regola il modo in cui i circuiti elettrici effettivi vengono manipolati per trasmettere i dati contenuti nella rete, nei livelli di trasporto e di applicazione) attraverso la struttura di Internet; in genere i dati viaggeranno lungo un filo o una fibra verso il "Central Office" di casa o della tua attività (questo è chiamato "l'ultimo miglio" ed è in genere il circuito che rappresenta il più grande collo di bottiglia per la larghezza di banda) che è più o meno il "onramp" per l'autostrada dell'informazione. Il CO ha quindi accesso alle pipe ad alta larghezza di banda (T-carrier, SONET, ecc.) Che trasmettono la tua richiesta, insieme a miliardi di altri, attraverso il globo al CO della destinazione, che la inoltra al server o alla rete di destinazione.
   • Questo "routing IP" funziona in modo concettualmente simile alla risoluzione DNS; Agli ISP di "livello superiore" vengono assegnate intere reti IP di "classe A" (ogni indirizzo possibile dato un primo byte noto) da ICANN, e altri ISP sanno chi possiede quella rete di classe A e come ottenere i dati sul fronte " porta ", utilizzando le informazioni in una" tabella di routing ". Questo ISP di livello superiore affitta quindi blocchi di indirizzi, alcuni agli ISP locali, altri direttamente agli utenti aziendali, e questi ISP e società dispongono di router che utilizzano l'indirizzo IP (e le proprie tabelle di routing) per determinare se inviare pacchetti ad altri circuiti vicini, lateralmente ad altri router ISP locali o fino a trunk e router di livello superiore.
7. Il server riceve questa richiesta (a condizione che non venga rifiutata a un livello di astrazione inferiore come il socket o un firewall) e se decide di accettare la connessione invierà un passaggio di richiesta-risposta "SYN-ACK", entrambi riconoscendo il richiedere e specificare le proprie preferenze (comprese le preferenze dei clienti che possono accogliere, ma modificando quelle che non possono o che non sono state specificate).
8. Se il client supporta la comunicazione utilizzando l'opzione impostata dal server, invierà una risposta ACK e ora la connessione è "stabilita".
9. Successivamente, il browser invia una richiesta "HTTP GET". La richiesta include l'URI completo della risorsa richiesta dal browser (anche se sappiamo che stiamo parlando con www.google.com, inviamo quella stringa come parte della richiesta in modo che il server possa, se lo desidera, interpretare ulteriormente il nome di dominio per indirizzare la richiesta). Questa richiesta può includere "cookie"; dati archiviati sul client che possono essere dati al server per facilitare l'elaborazione della richiesta in modo efficiente e conveniente (come identificare le preferenze dell'utente).
10. Il server riceve la richiesta GET e decide prima se desidera onorarla (il server potrebbe aver ascoltato le richieste alla porta TCP 80, ma aspettandosi messaggi da un diverso protocollo di applicazione come FTP o VoIP; questo è raro per la porta 80 ma più comune per altri tipi di porte). Supponiamo che lo accetti; il server restituisce quindi una risposta HTTP contenente la risorsa richiesta (in questo caso, l'HTML per la pagina predefinita che è la pagina di ricerca onnipresente di Google). La risposta può anche includere "cookie", che il server chiede al client di memorizzare (il cliente può o meno farlo).
11. L'HTML viene digerito dal browser e reso per disegnare la pagina nella finestra del browser. Mentre ciò accade, più richieste HTTP GET per Javascript, fogli di stile, immagini e altri dati necessari per visualizzare tutto il contenuto della pagina nel modo prescritto dall'HTML vengono inviate dal client e i dati risultanti vengono forniti dal server.
12. In un'epoca passata, Google si basava su moduli statici; hai digitato ciò che volevi cercare nella casella di testo e premi "Cerca" (o "Mi sento fortunato"). Quando si esegue questa operazione, una richiesta POST HTTP viene inviata dal client al server; la richiesta contiene l'ubicazione, specificata dal cliente, a cui devono essere inviate le informazioni e, naturalmente, le informazioni stesse. Queste informazioni vengono digerite dal server, che le usa per trovare i risultati della ricerca e il server crea una pagina di questi risultati che ti invia. Oppure può trasformare i termini di ricerca in una "stringa di query" e rispondere con un "reindirizzamento"; una richiesta per il browser di inviare un'altra richiesta a un diverso URI specificato nel messaggio. Il browser lo farà, quindi il server costruirà e trasmetterà quella pagina.
13. Nei tempi moderni, la prima pagina di Google è molto più dinamica. Durante la digitazione, JavaScript che viene eseguito sul lato client all'interno del browser invia ciò che stai digitando a Google lungo un "canale laterale" (utilizza gli stessi protocolli per la comunicazione, ma perché non è il browser stesso che invia richieste per intere pagine , la schermata del browser non viene cancellata completamente e rielaborata). Per la prima pagina, viene utilizzato per fornire suggerimenti per le query (suggerimenti per il completamento automatico delle cose che potresti cercare perché altre persone lo hanno fatto di recente); nella pagina dei risultati, fa la stessa cosa ma può anche essere utilizzato per fornire risultati di ricerca in tempo reale e ridisegnare completamente la pagina, senza richiedere un ricaricamento completo della pagina dal browser. Questi tipi di trucchi rientrano nell'intestazione generale di AJAX (JavaScript asincrono e XML,

Questo film , che è quello che hanno mostrato alla mia matricola "Introduzione all'IT" al college, ha le basi illustrate in un formato amichevole e analogo. Non è affatto tecnico, ma offre una buona panoramica concettuale dei pezzi di questo puzzle.

Tralasciando le menzioni di cookie e firewall sarebbe un paio di cose mancanti qui. C'è qualcosa da dire per i cookie inviati in modo che "Google.com" possa riconoscere un utente e pubblicare una pagina che potrebbe essere diversa per qualcuno che non ha effettuato l'accesso a Google. C'è anche la domanda su dove si trovi la persona: smartphone, tablet o computer normale (laptop o desktop)?

Mi chiedo se potrebbero esserci alcune domande secondarie che dovevi porre, ma non potrebbe essere un fattore qui. Questa è più una questione di come il Web funziona come Internet sarebbe un po 'più ampio e includerebbe e-mail e altre cose che penso.

La mia ipotesi è che sia stato più un test delle tue capacità di comunicazione. Puoi prendere una domanda piuttosto tecnica e scomporla in modo che sia tecnica che non tecnica la capisca? Che tipo di domande risponderesti quando ti verrà chiesto di spiegare a qualcuno che apre la home page di "Google.com" sul suo browser? Fai un mucchio di ipotesi o fai le domande? In un certo senso lo vedo come un parallelo a una domanda sulla lavagna bianca in cui le cose sono lasciate abbastanza vaghe da farle fare delle domande in modo da poter dare una risposta corretta e precisa o fare delle ipotesi nel dare una risposta.