Pace su localhost e illusioni infrante
Quando ero a scuola, tutto il mio mondo era localhost. Anche se avessi installato qualcosa come XAMPP e creato una bacheca utilizzando PHP, era un mondo che funzionava solo sul mio computer.
Quando sono entrato in azienda, ho avuto la fortuna di essere principalmente responsabile della manutenzione front-end. Era una pagina di amministrazione basata su Quasar (Vue.js) e la difficoltà del compito non era elevata. Tutto quello che dovevo fare era correggere l’errore di battitura o richiamare l’API che i miei superiori avevano già creato bene con axios.get() e visualizzarla sullo schermo.
A quel tempo, axios era per me come una bacchetta magica. Anche se non conosco i principi complicati, ho semplicemente inserito l’URL e i dati sono stati recuperati rapidamente. Ho anche avuto un pensiero sfacciato: “Non c’è niente di speciale nella comunicazione tra il front-end e il back-end, giusto?”
Ma la pace non durò a lungo. Questo perché ero uno sviluppatore “full-stack” in un’azienda di piccole e medie dimensioni priva di manodopera.
Presto è arrivato il momento in cui ho dovuto creare la mia API per una nuova funzione, invece di modificare lo schermo. Ho avviato un server utilizzando Spring Boot, che ho imparato rapidamente da YouTube, e ho inviato una richiesta dal front-end. Tuttavia, tutto ciò che appariva sul mio schermo erano errori CORS rossi ed errori Timeout, non dati.
“Ha funzionato bene quando l’ho passato come variabile locale, ma perché non posso semplicemente usare la rete?”
Spostare la variabile A nella variabile B sul mio computer (Localhost) era un metodo sicuro garantito al 100%. Ma il mondo al di fuori del cavo LAN era diverso. Era come un incrocio con un semaforo rotto e i miei dati erano un camion che percorreva quella strada pericolosa. Per tutto questo tempo mi sono limitato a caricare il camion e a spedirlo, ma non avevo idea del percorso seguito dal camion o di come fosse diviso.
Sistema di consegna nel centro logistico digitale
Espandiamo la nostra visione del mondo del “centro logistico digitale”. Ora dobbiamo consegnare gli articoli (dati) realizzati nella nostra fabbrica (computer) a clienti (server) lontani.
1. Pacchetto: scatola di spedizione standard
Non importa quanto siano grandi i dati che vogliamo inviare (ad esempio un video da 1 GB), non possono essere inviati tutti in una volta. Questo perché le strade sono strette e i camion sono piccoli. Quindi tagliamo i dati in pezzi molto piccoli e li inseriamo in scatole standardizzate. Questo è un “pacchetto”.
2. IP (Protocollo Internet): indirizzo e navigazione
Cosa posso fare se ho solo una scatola? Devi sapere dove andare.
3. TCP/UDP: differenze nei metodi di consegna
Ora dobbiamo decidere a quale camion spedire le scatole.
[Verifica del codice] Il vero volto di HTTP è solo testo
L’HTTP che usiamo comunemente è in realtà solo il “contenuto della lettera” trasportato su un camion per le consegne chiamato TCP. Parliamo con il server Naver nel modo più primitivo (Socket) senza browser o libreria. Vedrai quanto è semplice HTTP, solo un pezzo di testo.
import socket
# 1. Crea socket TCP (alza la cornetta)
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
# 2. Connessione al server Naver (223.130.195.200) sulla porta 80 (componi il numero)
# L IP di Naver puo cambiare (verifica con nslookup [www.naver.com](https://www.naver.com))
target_host = "[www.naver.com](https://www.naver.com)"
target_port = 80
sock.connect((target_host, target_port))
# 3. Scrivi il messaggio di richiesta HTTP (prepara cosa dire)
# Forma piu grezza di una richiesta HTTP
request = "GET / HTTP/1.1rnHost: [www.naver.com](https://www.naver.com)rnrn"
# 4. Invia (parla)
sock.send(request.encode())
# 5. Ricevi la risposta (ascolta)
response = sock.recv(4096)
print(response.decode())
# 6. Chiudi connessione (riaggancia)
sock.close()
Risultati dell’esecuzione (parziali):
HTTP/1.1 200 OK
Server: NWS
Date: Mon, 01 Jan 2024 00:00:00 GMT
Content-Type: text/html; charset=UTF-8
...
<html>...</html>
Analisi: questo è tutto ciò che accade internamente quando chiamiamo axios.get().
HTTP non è una tecnologia speciale, è solo una promessa fatta di “scambiare testi utilizzando questo protocollo (protocollo) quando comunichiamo”.
Compromesso in pratica: affidabilità o velocità
In pratica, soprattutto nello sviluppo back-end, arriva il momento in cui devi decidere tra TCP e UDP. (Ovviamente, la maggior parte utilizza HTTP basato su TCP)
HTTP/3, che viene spesso posto nelle domande delle recenti interviste, è il prodotto di questo compromesso. L’Internet che utilizziamo (HTTP/1.1, HTTP/2) funziona su TCP. Perché i dati non dovrebbero mai essere distrutti.
Ma i tempi sono cambiati. Le persone vogliono guardare video 4K senza interruzioni. Il meticoloso processo di verifica (Handshake) di TCP e funzionalità come “Stand in line (Head of Line Blocking)” sono ormai diventati frustranti.
Così ha pensato Google. “Ehi, usiamo UDP. Possiamo occuparci del disagio a livello di applicazione. È importante inviarlo rapidamente!”
Questo è il protocollo QUIC ed è la base di HTTP/3. È una tendenza della tecnologia moderna che ha abbandonato la stabilità incondizionata (TCP) e ha scelto la velocità travolgente (UDP), anche se ciò significava correre dei rischi.
Chiusura: immagina una strada invisibile
Ora sappiamo come vengono suddivisi i dati (pacchetti) e su quale camion (TCP/UDP) viaggiano.
Quando una richiesta API fallisce sul frontend, non pensare semplicemente: “Il server è morto?” come prima. “Oh, l’handshake a 3 vie non è riuscito? Il pacchetto è stato lasciato cadere dal router nel mezzo? Oppure il DNS non ha trovato l’indirizzo?” Se riesci a immaginare un livello di rete come questo, non sei più “solo un programmatore”
Ora la merce proveniente dalla nostra fabbrica è arrivata sana e salva al cliente. Ma come fa un cliente a ricevere questo articolo, a disimballarlo e a mostrarlo sullo schermo? Come verrà visualizzato nel browser il codice HTML che inviamo?
La prossima volta parleremo della destinazione finale dello sviluppo web, i principi del rendering del browser.