Fred på localhost och brutna illusioner
När jag gick i skolan var hela min värld localhost. Även om jag installerade något som XAMPP och skapade en anslagstavla med PHP, var det en värld som bara kördes på min dator.
När jag började på företaget hade jag turen att vara huvudansvarig för front-end-underhåll. Det var en adminsida baserad på Quasar (Vue.js), och uppgiftens svårighetsgrad var inte hög. Allt jag behövde göra var att rätta till stavfelet eller ringa API:et som mina seniorer redan hade skapat bra med axios.get() och visa det på skärmen.
På den tiden var axios som en trollstav för mig. Även om jag inte kan de komplicerade principerna, skrev jag bara in URL:en och datan hämtades snabbt. Jag hade också en fräck tanke: ”Det finns inget speciellt med att kommunicera mellan front-end och back-end, eller hur?”
Men freden varade inte länge. Detta beror på att jag var en ”living-style full-stack”-utvecklare på ett litet och medelstort företag som saknade arbetskraft.
Snart kom ögonblicket då jag var tvungen att skapa mitt eget API för en ny funktion, istället för att modifiera skärmen. Jag startade en server med Spring Boot, som jag snabbt lärde mig från YouTube, och skickade en förfrågan från användargränssnittet. Men allt som visades på min skärm var röda CORS-fel och Timeout-fel, inte data.
”Det fungerade bra när jag skickade det som en lokal variabel, men varför kan jag inte bara använda nätverket?”
Att flytta variabel A till variabel B på min dator (Localhost) var en 100 % garanterad säker metod. Men världen utanför LAN-kabeln var annorlunda. Det var som en korsning med ett trasigt trafikljus, och min data var en lastbil som körde på den farliga vägen. Hela den här tiden lastade jag bara lastbilen och skickade den, men jag hade ingen aning om vilken väg lastbilen tog eller hur den var uppdelad.
Leveranssystem i digitalt logistikcenter
Låt oss utöka vår världsbild av ”digitalt logistikcenter”. Nu måste vi leverera artiklarna (data) tillverkade i vår fabrik (dator) till kunder (servrar) långt borta.
1. Paket: Standardförpackning
Oavsett hur stor data vi vill skicka (t.ex. en video på 1 GB), kan den inte skickas på en gång. Det beror på att vägarna är smala och att lastbilarna är små. Så vi skar upp data i mycket små bitar och placerade dem i standardiserade lådor. Detta är ett ”paket”.
2. IP (Internet Protocol): Adress och navigering
Vad kan jag göra om jag bara har en låda? Du måste veta vart du ska gå.
3. TCP/UDP: Skillnader i leveransmetoder
Nu måste vi bestämma vilken lastbil vi ska skicka lådorna till.
[Kodverifiering] HTTPs verkliga ansikte är bara text
Den HTTP vi vanligtvis använder är faktiskt bara ”brevets innehåll” som transporteras på en lastbil som heter TCP. Låt oss prata med Naver-servern på det mest primitiva sättet (Socket) utan webbläsare eller bibliotek. Du kommer att se hur enkelt HTTP är, bara en bit text.
import socket
# 1. Skapa TCP-socket (lyft luren)
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
# 2. Anslut till Naver-server (223.130.195.200) pa port 80 (ring numret)
# Navers IP kan andras (kontrollera med 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. Skriv HTTP-forfragan (skriv vad du vill saga)
# Renaste formen av en HTTP-forfragan
request = "GET / HTTP/1.1rnHost: [www.naver.com](https://www.naver.com)rnrn"
# 4. Skicka (prata)
sock.send(request.encode())
# 5. Ta emot svar (lyssna)
response = sock.recv(4096)
print(response.decode())
# 6. Stang anslutningen (lagg pa)
sock.close()
Exekveringsresultat (delvis):
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>
Analys: Detta är allt som händer internt när vi anropar axios.get().
HTTP är ingen speciell teknik, det är bara ett löfte som gjorts om att ”utväxla texter med detta protokoll (protokoll) när vi kommunicerar.”
Avvägning i praktiken: tillförlitlighet eller hastighet
I praktiken, särskilt back-end-utveckling, kommer det en tid då du måste välja mellan TCP och UDP. (Självklart använder de flesta TCP-baserad HTTP)
HTTP/3, som ofta ställs i de senaste intervjufrågorna, är produkten av denna avvägning. Internet vi använder (HTTP/1.1, HTTP/2) har körts på TCP. Eftersom data aldrig ska förstöras.
Men tiderna har förändrats. Folk vill titta på 4K-video utan avbrott. TCP:s noggranna verifieringsprocess (Handshake) och funktioner som ”Stand in line (Head of Line Blocking)” har nu blivit frustrerande.
Så tyckte Google. ”Hej, låt oss bara använda UDP. Vi kan bara ta hand om oroligheterna på ansökningsnivå. Det är viktigt att skicka det snabbt!”
Detta är QUIC-protokollet och är grunden för HTTP/3. Det är en trend av modern teknik som övergav ovillkorlig stabilitet (TCP) och valde överväldigande hastighet (UDP) även om det innebar att ta vissa risker.
Stängning: Föreställ dig en osynlig väg
Nu vet vi hur data delas upp (paket) och på vilken lastbil (TCP/UDP) den färdas.
När en API-begäran misslyckas på frontend, tänk inte bara ”Är servern död?” som tidigare. ”Åh, misslyckades 3-vägshandskakningen? Tappades paketet av routern i mitten? Eller hittade inte DNS adressen?” Om du kan föreställa dig ett nätverkslager som detta är du inte längre ”bara en kodare”
Nu har varorna från vår fabrik kommit fram säkert till kunden. Men hur tar en kund emot den här artikeln, packar upp den och visar den på skärmen? Hur kommer HTML-koden vi skickar att visas i webbläsaren?
Nästa gång kommer vi att prata om slutdestinationen för webbutveckling, principerna för webbläsarrendering.